Seems you guys are right
1 Like
Highly doubt. Tech demos still use same engine. They are âtech demoâsâ after all. Some of the tech may not make it to the final game due to performance constraints but if they did it on video, it means it is working.
Now, there seems to be a great misunderstanding, just because Nanite does not support it, does not mean you canât use traditional UE4 workflow. So they could be using traditional UE4 style snow, they could be modifying landscape in real time, they could be using voxel plugin for snow, they could be using their own plugins for snow.
from what Iâve tested the RVT doesnât update fast enough for anything useful in terms of dynamic reactive changes.
you can still however have your regular deformation rendertarget applied as height on top of the RVT.
just because things are baked into the RVT doesnât mean one is limited to using the RVT as a final output. anything can be added on top on the respective material
2 Likes
Which brings up more questions:
Lumen does not support Landscape currently so I am wondering if the Landscape contributed to the lighting for the snow scene.
Also Virtual Height mesh currently does not support collision so maybe they have some sort of tech behind the snow deformation or they do not need collision to get the snow deformation to work?
I am wondering if we can be able to add virtual height mesh to very large static meshes that cover a large area rather than using Nanite especially if you have some sort of uv setup with multiple uvsets for those very large static meshes.
It was definitely nice to hear from the devs on how they did the snow among other things.
youâd still have the Landscape for the collision
If you guys look at how snow deformation is done in UE4 youâll realize you have everything you need. itâs not a mystery how Black Myth -could be- doing it if theyâre actually displacing the meshes (could be a very elaborate POM with PDO, which is what TLOU2 does)
- The snow deformation only seems to happen on the Landscape. Static Meshes seem unchanged and their snow is only an up-vector blend with no extra thickness. hence Naniteâs limitations are out of the equation
- Your typical snow deformation procedure is done onto a RenderTarget, which only writes the snow thickness (not the absolute landscape height)
- Draw your Landscape with Virtual Heightfield Mesh using RVT height
- On the material pass after the RVTâs are applied, pass the snow thickness RT as extra WPO. itâs the same as UE4 except it goes into WPO instead of Displacement
- Add enough render subdivisions to the VHM so the snow isnât low poly. this could kill the VHM performance though
From
People are really impressed with the snow, in particular, with the way it deforms around charactersâ feet as they walk and run through it. Can you delve into how youâve achieved that?
Wenyong: We used Unreal Engineâs Virtual Heightfield Mesh (VHM) to create dynamic snow. VHM itself could help add more details to terrain. Coupled with high-quality textures made by our colleagues, we are able to make a relatively realistic snow scene. Considering VHM is currently at an experimental stage, there are still some unsolved problems left. But overall, we think this feature is worthy of further study.
I tried finding peopleâs (developers) takes on it but thereâs nothing really exciting, just âwowâ reactions. I donât think the levels are designed too big for the performance to really matter. If you notice in the trailer it seems all enclosed areas where it happens so I doubt you could do this on a grand scale without A.I. based LOD of some sort. Maybe for example you could make it on a grand scale but thereâs so much âfogâ from the snow storm that it makes the tessellation invisible after so much distance and the player wouldnât know better that it was removed and loaded as needed. It would probably have to be saved/loaded like minecraft does whenever it renders new cells of the world.
Iâm pretty sure I know how virtual heightfield meshes work, Unity is doing the same thing and in fact sponsored the original research. Itâs fully scaleable to large sizes and should have a relatively constant runtime cost, just like nanite. There are a handful of scale considerations to it, but nothing an ok-ish sized open world game would be bothered by, and those problems could be overcome with some effort to get to nigh arbitrarily large scales.
Itâs also possible to apply this to arbitrary meshes. Itâs just a software version of tessellation thatâs crack free and has a fairly smooth and continuous transition. Long term, if Epic dedicates the resources to it, it could be a full replacement for tessellation, including programmable materials and displacement maps and etc. It can even do catmull-clark subdivision, though Epic has stated they donât want to work with non standard modelling tools like that.
1 Like
That is true.
It would. Hopefully, it will be very much improved when the full release is made next year. But the devs didnât seem to show much interest in VHM the last time they did a livestream about Nanite some months back.
You have a point about the areas not being that vast or large. That would be a smart way to improve performance.
+1 for VHM to be able to be used with static meshes but I think they may even get rid of VHM and landscape all together since Nanite would be able to handle all other aspects like foilage, spline meshes, animated or deformable meshes in future. Not sure about hair in Ue5 and Nanite.
Maybe we might be getting distance based displacement with Nanite for very large static meshes? Because from what you have mentioned, I am thinking why use Nanite when you can use VHM and itâs tessellation is distance based if it worked with static meshes?
This would be disaster if they would remove landscape system because landscape as system is heart of design. From generation landscape from world height data to sculpt design of terrain. Better would be if landscape adopts dynamic resolution cells so you could even create simple trench with just a landscape without needing meshes for detailed trench walls for example.
Hmm interesting. I have been experimenting with it a bit but canât get it to run properly. âOlder methodsâ do work fine though. So I guess waiting for full release.
Thanks for the headsup, I hadnât worked with vhm/rvt before so although this made sense to me I figured it was worth trying to prove it to myself (or anyone else who has doubts)
Works great. Chaos on the other hand has some issuesâŚ
6 Likes
This is really cool. Thanks for posting.
Anyone know if it is possible to apply VHM to static meshes. If so, how can this be done?
âapply vhm to static meshâ what does this mean? what are you trying to accomplish??
Found this:
Seems VHM can be applied to static mesh, RVT as well. This should be natively possible in ue5 imho. Personally, I feel 3dartists should have a choice to chose between landscape and using static mesh for large areas.
Kudos to whoever made this1.
1 Like
trying this myself in unreal 4, but while I get trails, the updates seem very laggy. any chance you can share how you did this?
Using the ray wenderlich tutorial: Creating Snow Trails in Unreal Engine 4 | raywenderlich.com
Rendertarget and what is working fine, but updates to the vhfm seem laggy. They show, but are chunky/batchedâŚ
I did pretty much exactly as @Chosker described above. I set up the landscape/rvt/vhm as normal, and then in the main section of landscape material I use WPO to displace the vertex positions according to a mask generated by a Render Target.
If youâre getting slow updates I can only assume youâre trying to apply the render target to the runtime virtual texture output, which is not what you want.
For what its worth, I used that exact tutorial for the snow trails as well, and I donât recall doing anything special.
1 Like
Might be this, will check. thanks for the quick update. This is like the very very very last thing in a long line of âcan I make all this work togetherâ. Thanks.
Sooo that didnât work for me! LOL, but I still managed to fix it, and wouldnât have found it if not for your direction leading me to noodling around some more.
WPO did move the height of my landscape and heightmesh, I was already using it to update collision using WPO for muh dude but it never seemed to update dynamically off WPO. SAME math, just plugged into the WPO vs WorldHeight out to the RVT and the data just wouldnât flow throughâŚ
So I dropped back to my previous setup where updates were flowing if at least janky⌠Happened across this setting on the RT (was previously unchecked), and viola! On my 2k x 2k heightmap/landscape, full, constant updates with the RT feeding/modding the height-math into the WorldHeight out of the RVT:
FYI, this is on UE4 if it matter, assume it works the same in UE5. Donât really test until Lumen catches up to landscapes.
EDIT: so I actually turned that setting off and it still works⌠I ended up reimporting a new landscape, resetting associations, rebuilding RVTs, etc. Seems to be working, no idea. To be clear I am NOT using output from the RT in the WPO pin, itâs being routed to the WorldHeight output to the RVT, so what I wanted in the beginning but, functionalâŚ
Anyways, PoC is itâs working.
Thatâs interesting, glad you got it working. My project is built in UE5 so maybe there are differences between the implementations.
I desperately try to do that with UE5. I get that VHM is involved but not sure how to play it to create the displacement, is there any resource or tutorial that you guys can suggest for a VHM noob?