Alright, I hope you assumed right! Have a nice day.
1 Like
I know there is work ongoing towards a Nanite landscape, but if that doesn’t hit then no WPO will not resolve the lack of landscape displacement in UE5.
The main reason is that landscapes currently are not dense meshes. The way UE4 resolves this is of course by first tessellating the mesh so that it can take advantage of displacement…but since tessellation was removed in 5.0.0 then we will either need Nanite Landscape or the Proprietary Nanite Tessellation they indicated they have been working on (which I think is cooler since it can potentially apply to all Nanite objects, not just landscapes).
So in UE5, even if landscapes support WPO, there will also need to be some solution that allows them to be more poly-dense first otherwise this alone will not solve the issue. However given that they are working on Nanite landscapes and Proprietary Nanite Tessellation then I imagine that this is the solution they have in mind here.
I haven’t looked at the 5.1 branch (github main branch) yet but it would be a shame if 5.1 shipped with WPO on Nanite assets without addressing this limitation for landscapes. I’ll also be curious to see what happens with landscapes from older engine versions.
i.e., would a landscape created in 5.0.3 need to be completely re-sculpted for 5.1 if it ships with Nanite landscape or will older landscapes be converted? This is something that someone who has looked at the current 5.1 build might be able to answer (if this is in there yet).
1 Like
The heighmesh might disagree, and moreso the heightmesh is the solution for the shortcomings of a landscape-proper. Having spent quite a bit of time working w/tessellation and landscapes, I can say, at least for my experience, the heighmesh is superior in almost every way: it’s more performant and more dense vs tessellation.
If Epic can push WPO and/or Nanite to this layer(s) then, yes, the newer tech would eclipse tessellation. Yes, there is going to be no xy-deformation because of how the heightmesh functions, but given you can crank the detail up to something FAR more than what tessellation could offer? Seems like a no brainer to me (and this is coming from someone that used to die on the hill that is tessellation).
1 Like
I would agree with you if it was more streamlined to use and set up with complex landscape materials, but VHFM is just kind of a mess to set up. It also has no collision, unlike Nanite proxies. It also has limits on the texture resolution because it requires virtual texture streaming, so it’s not appropriate for large landscapes unless you don’t care about texel density (epic cover this in one of their deep dive videos on it but afaik there is no progress on advancing this since then, and that was over a year ago). It’ also pretty buggy in its current state.
Maybe one day it will get there, but I don’t see why this would be the case given that Nanite Landscape is already under development.
Disagree. It was a bit wonky at the beginning when I didn’t understand how the parts work together, but today, yes, it’s series of steps but otherwise once instantiated, I’ve not had an issue with it except to need to rebuild the underlying RVT.
Collision was never intended. The heightmesh is simply the display layer, endlessly tessellating/subdividing, but to get that ability, we get z-only deformation (which can be ameliorated by increased RVT resolution) and we give up collision. The landscape can be used for collision since it’s effectively a lower-resolution vs the heightmesh (good tradoff).
As far as texel density, I’m not sure we have to worry? Granted I am self-taught, and more of a noodler, but for my tastes, since this is all texture driven, I can crank stuff up well past a point where I functionally care. Yes, I get there IS a limit, but is it really inside practicality, or outside what we can really care about? (Genuine question).
Now, I have other things like a blobby/slime material. It uses mesh-distance fields to help it stick to close-surfaces. This DOES use the hell out of tessellation and no, landscapes won’t suffice. So I don’t want to suggest heightmesh is the end all be all, just for (my needs) landscapes.
You’re welcome to disagree but I think you’ll be pleasantly surprised with what’s in 5.1 if you build it from source. ATM it looks like Nanite is a lot more functional and several of the main limitations are either gone or going away…Nanite landscape is sort of on its way in. Nanite meshes themselves also seem to be working with WPO…so there’s really zero reason to stay glued to VHFM. If Nanite Landscapes can take advantage of texture-driven displacement the same way other static meshes do, then this is the obvious answer I think for landscape displacement going forward.
1 Like
We can assume a high likelihood that Epic is going to introduce Tessellation and Displacement back into UE5, there are now increasing multiple user threads discussing and requesting this, and it actually winds up becoming a great marketing opportunity. No isolated discussion in one thread alone encapsulates that there is a vast user base that would enjoy the introduction of these tools into UE5, and that marketplace visits would inevitably increase per such introduction. Every marketplace developer should support this.
Looking at 5.1 build, there is no Nanite functionality for skeletal meshes still. Nanite’s abilities undoubtedly hold great promise for the future, but optimized usage of past assets are now being shown by the user-base to rely heavily on Tessellation and Displacement, as was available in UE4.
A couple dozen people talking about it is like a drop in the ocean. I don’t think it’s coming back.
No, they did not. The only thing that really used it was landscapes and even that was only really used on PC. I don’t think they even support HW tessellation on consoles or mobile. If you need tessellation on a skinned mesh, which is already a brutally inefficent idea, just subdivide it… The savings from the scene being nanite meshed will likely MORE than pay for whatever increased cost you’ll have with a character that has 4x the geometry.
2 Likes
This is the whole point of Nanite (clustering-tech). To make the cost of the screen be independent of object/triangle-count and make it a more fixed/consistent cost from frame to frame.
The benefit of which is that as complex as you might want to make a scene, nanite meshes will eventually ‘top out’ on cost, which can a) be used to use higher-fidelity assets at a fixed/reduced cost, and b) free up cycles to spend on other things like lighting or higher-quality non-Nanite meshes.
When mature, Nanite will (essentially) obviate the need for tessellation.
And this is coming from a guy that wanted to go all-in on tessellation and landscapes; it’s a boondoggle for the cost. Nanite will be much more performant.
2 Likes
That’s what I’m saying… For now, deformed/skinned meshes can just be subdivided for more geometry. The increase in cost for the non-nanite mesh, that had to be subdivided for more geometry since tessellation is gone, will still be trivial compared to the savings in static nanite geometry in the scene. In some cases, the performance might equal the same vs a UE4 version of the scene, but in most cases, you’d probably still come out ahead on UE5, assuming you don’t have dozens of 500k characters on the screen being rendered at LOD0.
2 Likes
I appreciate your concept, that for skeletal mesh, one just need subdivide and then you have the mesh you wanted. Now, this would be indeed be wonderful if one could in fact do this through UE5’s modeling mode, where it could be operated through Nanite, but you cannot. As such, you have to do this externally, leading to the following:
(1) you have to employ labor to reassign said mesh, or engage time to reassign the existing Epic-marketplace purchased mesh to one of higher poly fidelity. This entails bone calibration work, UV texturing calibration work, and a general “new mesh” troubleshooting process.
(2) This new HD mesh cannot merely be ‘swapped-into’ your old skeletal mesh’s Blueprint. The AnimBP, for example, needs to be assigned to a new skeleton, so this will now involve troubleshooting the AnimBP AnimGraph and EventGraph, which likely will not function with the new mesh due to it not having the exact mesh ‘layout’ as the lower poly one. Everything needs to be troubleshooted and re-assembled.
But yeah, I’m with you…If you could quickly subdivide your already existing skeletal mesh in UE5, so it could be handled by Nanite, this would be a win. But in absence of that, users are asking for Tessellation. It’s a huge cost saver.
Then use UE4. Maybe one day nanite will handle skinned meshes. You can always upgrade your project when that time comes. For right now though, you can’t have your cake and eat it.
1 Like
Well, you are correct to say that, we can still use it, or anything else. That won’t optimize a robust development of UE5 though in the meantime. Tessellation was already working as implemented, but Nanite doesn’t handle skeletal meshes yet, so it’s more labor, work, time, and cost now on everybody’s end. Users here want Tessellation in conjunction with Nanite, not versus Nanite - have the cake and eat it.
Here is a specific use case that an in-editor material Tessellation+Displacement can do, that Nanite, nor Parallax Occlusion Mapping (“POM”), cannot replicate - edge-deformed material animation.
This means there is a true irreplaceable “Loss of Function” in UE5 with the removal of in editor material Displacement and Tessellation.
Please look at this POM material on the sphere in UE5.
It is emulating the look of points protruding out from the sphere.
Now look at the edge to far left, right, bottom, and top. It is a smooth sphere surface. Meaning, you only get a pointy emulation looking straight at it.
Now whereas, with Tessellation + Displacement (ie in UE4), you could actually simulate the pointy mesh exterior, and it would look pointy on the mesh, with up and down spikes along the exterior. So it wouldn’t look spiky in the middle but not on the edges like POM, it would actually have a spiky middle AND a spiky exterior.
Now, one can say, just remodel the mesh with the detailed spiky points on the mesh and use Nanite to render. There are several issues with this:
(1) the mesh’s spikiness CANNOT be animated as part of a material, since it is not a material - loss of function
(2) said mesh’s spikiness CANNOT be applied to any other mesh instance you want, at whim, as each and every mesh must have this shape itself forged into it, so that Nanite can be utilized fully - loss of efficiency
Consider the workload to
(a) modify each and every mesh with that baked detail so that Nanite can be utilized to render it, as opposed to
(b) merely applying a Tessellation and Displacement texture that can then be used in any animated BP fashion you want, on any static scenery, or skeletal mesh, you want.
POM is a visual trick, as is Tessellation+Displacement. But importantly they can be animated - pulsed on a time scale, inverted, rotated, panned, increased in intensity, etc - and applied to any mesh instantaneously, or linked to any BP so that the material can be activated at any controlled, or random point, instantaneously. Whereas, Nanite is a mesh-rendering solution for high detail, and is not a material-animation component. In fact, with Tessellation/Displacement in UE5 you could theoretically animate a material having a combination of both POM and Tessellation/Displacement. Nanite plays no role in such a case, it merely allows for high-detail mesh rendering.
Since POM cannot simulate a mesh exterior deformation, and since there is no way to replicate the “material-animability” of in-editor material Tessellation+Displacement through Nanite, this is a true case of “Loss of Function” in UE5, since edge-deformed material animation cannot be replacted by Nanite, nor POM.
As such, for consideration, this material animation component is a genuine reason for the introduction of Tessellation+Displacement for material editor in UE5.
1 Like
Or just wait until 5.1 where you can use WPO+Nanite on a mesh with plenty of polygons… You can test it out right now on the ue5-main branch.
2 Likes
Thanks. Yeah, I agree, it’s what to try at this point. Everyone who ever used Tessellation+ Displacement and WPO knows WPO is lower-cost but gives way less detailed deformation, it’s not even close. To those who don’t know, this is because mesh deformation on WPO exists on the mesh poly level, whereas Displacement worked off of a texture map, which could be animated in a multitude of forms mind you, so you can see how much more detailed it could be, especially if you used a HD texture and tiled the map.
But anyway, reviewing more broadly, I now crossed the threshold of understanding, where I glean that if they could have given us Tess & Displacement, they would have. There must have been some serious issues that prevented them from doing it (ie conflicts with Lumen or Nanite), and it was cleaner just to axe them from UE5.
Because why is WPO even there anymore, or why is POM there anymore; they shouldn’t be, because just like Tessellation and Displacement, they are older more obsolete material mechanisms that can be replaced by Nanite, as far as mesh rendering goes. What puzzled me latest was that Tessellation and Displacement were able to be animated as a material BP component in so many ways, unlike Nanite, which is solely a rendering compute enhancement and not a material animation component. And so why would they have eliminated that material animation component, but then not POM and WPO, or Bump Offset even. And it has just dawned on me - they likely didn’t want to eliminate Tessellation and Displacement; as conflicts arose they probably had to.
There’s a UE 5.1 branch now on github it looks like as well. 
I’ll compile it this afternoon and see what we’ve got, but last time I built the main branch WPO worked for static meshes but not landscapes…which is a step in the right direction but still leaves a gap in feature parity from UE4. They have confirmed in the AMA though that they are working on some form of proprietary nanite tessellation, which is exciting - but I don’t think it will make an appearance in 5.1 unless it’s been added in the past few weeks since I last compiled from source
EDIT: I did compile the 5.1 build last night and it seems…ok. The shadows on nanite WPO are not currently working correctly (expected, given it’s not released yet) so although Nanite does work with displacement the shadows are bad enough that I’d currently avoid using it until those issues are resolved (hopefully in full release they will be). Example below.
It looks like nanite landscape is also sort-of in but the minimum tri size seems capped at pretty large for some reason, and it’s also not working well with WPO (also rebuilding nanite data on a landscape from 5.0.3 crashes the engine so I was not able to test how it works on existing landscapes…would be pretty disappointing if you were not able to use existing projects without rebuilding the entire landscape from scratch). If they are able to make this work though then that would be an ideal solution for landscape displacement.
The 60FPS target on consoles with Lumen (from the roadmap https://portal.productboard.com/epicgames/1-unreal-engine-public-roadmap/c/845-lumen-improvements) also seems pretty far off (I peaked at 50FPS on a 2070 but regular drops to 30-40 range), unless they meant 60FPS on a blank level :'D
1 Like
I think as of now this is probably more accurate to the reality of it, where 60FPS is a better/best-case-scenario, rather than the expectation under even the highest of computational stresses.
On topic of tessellation, I think there is a user-created sentiment sometimes that UE5 is so powerful it just rendered tessellation/displacement obsolete. But after testing WPO, POM, and Bump Offset alternatives, it really appears more and more that UE5 wouldn’t be powerful enough to incorporate Tessellation and Displacement, and all their animatable material features, in all elements of its paradigm. Thus any mesh-altering overlap with Nanite made it an expedient reason to deprecate them.
Unfortunately just like most things regarding Nanite, WPO only displaces the fallback mesh in 5.1.
Are you sure about that? You can Youtube plenty on the matter because people have been playing with it for a good portion of the year now… Here’s a quick timestamped video from months ago:
