Results 1 to 3 of 3

Thread: [Feature Request/Suggestion/Re-Implementation] Displacement Sewing (Source 1 feature)

  1. #1
    Basic Member Toyoka's Avatar
    Join Date
    Oct 2013
    Location
    Current position co-ordinates non-tracable. Unknown space.
    Posts
    833

    Lightbulb [Feature Request/Suggestion/Re-Implementation] Displacement Sewing (Source 1 feature)

    TL;DR version at the bottom

    I've been working on a particular map on and off for some weeks, trying to find out a way to get displacements to paint smoothly around most of the map (without performance loss or issues with holes in displacements). Here's the base map without most/all the entities (basically just the underlying terrain). The issues I ran into:

    Displacing individual tiles creates holes between the tiles. In other words, the displacement tool doesn't "sew" the tiles like the tool did with displacements in the previous version of Hammer (unless I'm missing an option somewhere in the current version). Example. Face selection example. As you can see, the only set of faces affected by the tool are the ones that the displacement tool started painting on (ie. on one of the two tiles). As you can imagine, this is quite difficult to fix manually (or rather, almost impossible on the scale I'm working on). Which brings me to the next issue;

    I decided to merge multiple tiles so that I could displace more at once (you can see in my previous screenshot that indeed, multiple tiles were merged, though not all of them, for performance purposes). In fact, at first I made the choice to merge all the meshes I wanted to displace. This ended up being all of the tiles which occupied some shape or form of a hill or inclination (slopes, etc.), which was almost half-the-map-worth in tiles. At the time, this seemed like a good idea. Well, displacing was literally impossible as each paint/displacement took almost 15 seconds to process (that is, for each mouse movement 15 seconds would need to go by to show one pass of the displacement brush). So, my next decision was to split the large mesh into several smaller pieces to work with. This was somewhat better performance-wise (though it was still a bit process-intensive/took some seconds to render the paints/displacements and wasn't smooth enough to work with consistently), but the issue of tiles not sewing is of course, still present. So my simple request is this: re-implement the displacement sewing feature that was somewhat prominent in creating proper displacements in the previous version of Hammer! Perhaps the method to creating large displacements is different now (in which case, I would definitely like to know!), but it seems a to be a strange change to remove the old method with sewing, which was quite easy to utilize and wasn't performance-intensive.

    Edit: I experimented further by creating prefabs out of the several pieces of the map that would be displaced, and there was no change in performance (good or bad) when attempting to displace these prefab-ed displacements that were each in their own isolated vmap. It seems the issue is tied to how the tool processes the mesh when it's being displaced. This issue would be non-existent if sewing displacements was an option (instead of merging meshes).


    TL;DR version: Bring back the displacement sewing feature from the previous version of Hammer!
    Last edited by Toyoka; 09-19-2014 at 03:33 PM.

  2. #2
    Valve Developer
    Join Date
    Aug 2014
    Posts
    98
    Thanks for the suggestion. There is definitely still some unfinished work in relation to displacements. It looks like what you are trying to do is higher poly-count than what we have been using displacements for internally. Our typical workflow with displacements is to keep any of them we want to be contiguous as part of the same mesh as you mention, but it is true there does come a point where that can be a performance problem. Being able to modify multiple meshes within a single displacement operation (brush stroke) and stitching displacements without merging meshes are both features we hope to implement in the future to solve these types of problems. Unfortunately I can't make any promises about when we will get around to implementing those features, but your interest in them is noted.

  3. #3
    Basic Member Toyoka's Avatar
    Join Date
    Oct 2013
    Location
    Current position co-ordinates non-tracable. Unknown space.
    Posts
    833
    Thanks karlw, good to know! Yea, perhaps I shouldn't be using the default terrain created by the tile editor, as those tiles are quite high in polygon count already. In the mean time, I'll try some alternative methods for terrain displacement such as using my own meshes from scratch as the base.

    PS: Do you know if there will be better support for tablet-based camera movement within Hammer, similar to how Modo (and perhaps other modeling suites) handles tablets? I know this is probably asking too much but I thought I'd shed some light onto it considering it could streamline the workflow somewhat (at least while on the topic of displacement modification).

    Your replies are much appreciated

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •