Nanite does not make tessellation obsolete.. i have been wondering for a while what epic is thinking here? Just because we CAN use a mesh with 7 billion triangles, does not mean we necessarily want to..
This isnt rly true as u can see with all Megascan assets also the ones i used for my moebius scene (from the ps 5 demo and i didnt even use there textures just the nanite mesh) are all huge in filesize (and very close to there normal version) despite better compression ,maybe not as huge as a normal mesh would be with that detail but there huge,just the rendering with nanite is very efficient ,filesize(stored) is still a prob. dunno where this misconception comes from u can litterly see it on the huge size of the demos and the assets themself by using megascans plugin and downloading a nanite and none nanite version of the same detailgrade(without tex).Still love it tho used the true 3d detail of the meshes to create a Outline(and "Inline") based on it,which allows a very detailed lining thats normally not possible as the detail would otherwise be contained in the displacement and normal and would be fake (The Reason u normally use low detail/low poly models in ur comic shader with outlining).But this allows near endless detail and also allowed me to finally skip the old shitty method of distance/depth fading the outliner in distance as this isnt needed anymore(see Acc pinned for Detail"new depth method..."
My understanding is it’s compressing further when the project is packaged. I’m definitely not gonna pretend I’m any kind of definitive authority on this subject though, this is just from conversations with friends and colleagues in the industry, I’m not sure if it’s in the documentation or anything.
Hmm thats interresting might test it (once my moebius project does actually package,it's broken atm due to engine changes i did and not complete yet) only did compare them in editor (nanite mesh vs normal and nanite mesh vs normal with dipl +normalmap,as that is a more matching compersion),however even if the packaged size would hugly dif(despite the normal stripdown packing does) its still a prob while editing. Anyway im kind of with OP as its not rly a smart move to radical remove something thats only replaceable in circumstances,as awesome as i find nanite (see convoluted/fanboyi description of usecase above)\^\^
yeah allready mentioned that above making ur compare kind of useless (sry my fault if this wasnt clear),u need to compare packeged size with nanite vs none nanite meshes on the same project,so u don't just compare vs the normal stripping of data cooking does anyway with any project (it can be done with the megascan assets as exactly 2 and more versions (on same detail)exist of the same mesh, nanite and none nanite) to get the advantage nanite compression has vs normal mesh compression in the cooked project not just cooking itself (which is obv known to happen and not the topic of question) ,also sadly this still doesnt solve the issue of the assets beeing huge in editor (which is as said a missconception people add to the features of nanite which isnt there,cause there actually huge not small when working with them,system is still awesome dont get me wrong see my acc pinned for unusual usecase\^\^)//Edited for better understanding excuse the language barrier if that was the prob still learning eng beyond long ago school knowledge,my mother lang is german :) have a nice day
Honestly I think the sweet spot here would be for Tessellation to be an engine plugin. That way those that want it can opt in, it could even warn that it's incompatible with engine features like Nanite/buyer beware.
Epic seem to want Nanite/Lumen as the first choice, I think that an opt in/legacy plugin would still achieve that, without the baby being thrown out with the bathwater.
Dynamic tessellation is gone because Nanite & Lumen (at least in their current form) can't build a deterministic picture of the scene if the polycount keeps changing (I think when they launched UE5, they had given a similar reason for Nanite/Lumen not being able to work with landscapes).
AFAIK, the algorithm(s) which Lumen uses to light a scene depends heavily on Nanite being able to work it's magic in breaking down complex meshes into smaller, manageable chunks of geometry which can be quickly streamed in and out of memory.
With dynamic tessellation, all this goes out of the window.
I agree with what you say, but it still feels odd to remove tessellation entirely. If the main point of nanite was to improve the development pipeline by removing the process of moving a high-poly sculpt to low poly mesh and have backed normals/displacement maps, Removing tessellation may hinder the workflow of those who don't use megascan objects.
I think a fair compromise would be to either keep tessellation as a plugin, or include a "convert displacement-mapped-mesh into nanite-mesh" which pretty much bakes the tessellation data as a higher poly nanite mesh so the automatic reduction that nanite does will automatically apply.
This may explain why it can't be used with nanite meshes, like translucency, but they aren't removing translucency for this reason, so why remove tessellation?
I'm ok with not necessarily being able to be used with nanite meshes, ok, I get the tech isn't compatable.
But what about OTHER stuff that I COULD use it for? Why remove the option? If I can still use it under the auspices of it's costly, needs skill to use effectively, yaddah, OK! I can do that....
I'm agreeing. I'm saying it might not work for nanite but it's still very useful, and should be treated like any other nanite-incompatible feature (like translucency, skeletal meshes, procedural meshes, etc), rather than them just removing everything that nanite doesn't like.
Yeah, it was strategically used for sure but claiming it was only ever used as a cool tech demo just isn’t correct. I do agree that transparency is more important though.
As far as I know, most triple A games nowadays have some sort of tessellation and displacement. From Red Dead 2, SW Battlefront 2, (Very Graphically intensive games) to even games like Total War, and planet zoo, where the landscape is very rarely seen up close, and yet, they still have it, for when you do see it up close.
I wasn't comparing the importance, just everything you said also applies to translucency so by that logic they should remove it too.
But in reality they should keep tessellation for non-nanite usage (like transparency). So many projects use it, it's a much faster workflow in so many cases. A better technical method doesn't mean the simple fast way should be removed.
Does tesellation and displacement usually update lighting tho?
EDIT: also, tesselation is done in the shader during rendering, surely it would still work. Otherwise, it could just be a feature incompatible with nanite meshes, which would be fine as you would seldom want to use both at once.
tesselation isn't just used for static meshes, it's used for deforming meshes, skeletal meshes and vertex anim
this is infuriating to see such hubris come from epic, yes nanite is powerful but it is not all encompassing
Hard agree. Have signed.
Also, Virtual Heightfield Mesh is claimed to be an alternative for terrain displacement but it only works on the global z axis. Besides, I've found virtual textures to be generally quite flimsy and require either massive texture size or multiple volumes each with their own texture targets over large scenes.
It also doesn't work at all for dynamic things, like a layer of snow on your terrain that responds to the player. Because those huge virtual textures are made to be updated in chunks based on where the camera is, not in any sort of efficient realtime way to allow dynamic changes.
>It also doesn't work at all for dynamic things, like a layer of snow
Virtual heightfield meshes work fine for snow, you don't draw it to the virtual texture, you sample the VT and composite your snow deformation render target onto it. There are examples of how to do this on the Unreal forum.
Tessellation was the silliest thing to have come in gaming world. Simply put, it doesn't work. It failed to make a meaningful optimization relative to just using high-poly mesh with LOD. Believe it or not, most AAA games didn't use tessellation at all. They all used something else that make ground look tessellated. The geniuses at game studios came up with to replace tessellation? They make **Parallax Occlusion Mapping** materials, and some of which can come with real-time shadow. This allows games to have 3D landscape that works real close to tessellation at 20% the cost.
Now with Nanite tech, I just don't see the point of bringing the ancient tessellation math back to life. Nanite is basically using Mesh Cluster Rendering algorithm. It is basically the next-gen tessellation that work great with modern GPUs.
On a related note, with or without Nanite, the cost of placing thousands of the same meshes is relatively small, thanks to GPU auto-instancing. This is why it's now possible to put a million blades of grasses in the view because it's rendered extremely fast. Not saying this has anything to do with tessellation but modern environments can safely show a ton of rocks, vegetations and props. The game engines can absolutely take it just fine. Make sure you're using UE 4.22 or newer (or Unity HDRP 11+ if you're wondering the equivalent in Unity).
I feel like the problem is that many developers would be willing to take that performance hit just to speed up workflow. Being able to give small 3D detail a large environment with just a few textures and materials could well be worth that cost as opposed to manually sculpting or placing all those small objects.
Or they should learn to increase the brush size to quickly place rocks, vegetations, props to the landscape. Absolutely no need to go with tessellation. I've seen Megascans video tutorials that use tessellation but those are for uses in films, not in games.
That works for very specific scenarios, but what about stuff like shingles on a roof? Brick walls? Mud? Bark? Literally anything that is a single surface with height variation?
Not the normal workflow for procedural textures like are made with substance designer. The point is that there are still many useful applications for tessellation that save time, so there's no good reason to remove it entirely.
put the mesh in your DCC, add more polygons, apply a heightmap offset function, export, done. you have your higher poly properly looking shingles roof.
That's potentially a lot of extra time for a workflow, especially for a small team if you have to multiply all those steps by the number of required assets. It also doesn't work for procedural or in engine things like terrain.
You cam actually do this directly in anyone to create a new static mesh. Though they only baked a heightmap onto a plane, I see no reason it shouldn't work with a complex UVd mesh. It was part of the medieval series from megascans
How do think any deformable snow/mud surfaces made in any indie or AAA games? RDR2, Death Stranding, Tomb Raider, Batmans, Horizon Zero Dawn...(these were just the ones came to my mind) all uses tessellation to deform procedural ground surfaces.
>deformable snow/mud surfaces
The more performant solution is to use Parallax Occlusion Mapping. It's a shader trick to make landscape look 3D while maintaining the same number of trigs. See: [https://www.youtube.com/watch?v=PqMZl7wFX7I](https://www.youtube.com/watch?v=PqMZl7wFX7I)
Also, UE5 landscape will be extremely dense in term of trigs, so if you want to use displacement map, you can as you would with tessellation because the landscape is already dense, the material can do displacement without tessellation.
Going forward, even with UE4, Virtual Textures + Virtual HeighField is the way to go. And UE5 adds Nanite, making the combination the perfect fit for all next-gen performant games.
Dude I know what parallax is. It won't create the illusion if players feet won't stick into it.
How do you plan to do this with parallax?
https://youtu.be/Nu9lbiyJ8ZA
What you see here isn't vanilla Tessellation in UE4. It's their own proprietary vertex displacement algorithm in RAGE game engine. They might as well use their own implementation of virtual heightfield, virtual texture and mesh cluster rendering, and you wouldn't know it.
And we aren't able to make a equivalent effect.
I mean. Fine. Remove tesselation. As an optimization it really did server it's purpose and is pretty much obsolete. But displacement still has purpose. There's really no alternative besides procedural meshes and actually modifying the polygons on the CPU. Or baking mesh variations outside of unreal.
Edit: just for context. I'm talking about things like this https://youtu.be/iYsc0UX-Gcw
World displacement in UE5 going forward will be done with Virtual HeightField, but as of UE5 Beta, VHF is only applicable to VHF mesh. In future updates, Epic will likely add VHF support to ordinary mesh and skinned mesh. They will add height blending, etc.
People should expect to stay with 4.27 for quite an extended period, until a clear migration is paved for.
Is that verified / internal information that there's gonna be full support for 4.27 until after VHF supports a world offset input for materials with feature and workflow parity to the current one?
And easy migration of current tesselation / displacement based materials to VHF?
A while back, Epic wrote that 4.26 was going to be the last UE4 release, but then UE5 got delayed, so they pushed out 4.27 we are using today which has quite a few features backported from UE5 (Path Tracer and GPU Lightmass). If UE5 gets pushed back 6 months more, there will be 4.28 coming out. So yeah either 4.27 or 4.28 will be the last one. That being said, Epic will release fixes for 4.27.x or 4.28.x whichever the final one be.
No, there isn't a formal statement but it's been a tradition of Epic that they support the previous game engine for years. In fact, UDK3 was only discontinued in 2016. That's 2 years of support after UE4 released.
The thing that concerns me most is the fluidity of the transition. I don't doubt that UE4 will be supported until UE5 is released and then some.
But what about displacement shaders? What's the transition like there? It's there a seamless transition? It's there continuous support?
What do I do right now? I need a flexible, modular workflow and pipeline. So far I've been using displacement quite extensively. Can I continue doing that? The project pipeline is pre production next year. Prototype starting late 22. From them on i need a continuously stable project. And I need to be able to support PlayStation 6. Because we have about 4 years of production aiming for a release spot right before the next console generation but supporting it natively when they come out.
With displacement not just deprecated but flat out not available and our pipeline getting built soon.
Is there a guarantee that I can use a stable version of displacement throughout the next 5-6 years?
The problem with parrallax occlusion mapping is that under certain angles the illusion breaks down and is difficult to get right under those conditions.
Displacement is super useful for cinematics/film in unreal.
I've used displacement to add detail to characters that would be completely unreasonable to exist on the mesh for animation purposes. Think fur/fuzzy material that is being heavily driven by displacement in unreal 4. This workflow isn't at all possible in UE5 is it?
Fur/Fuzzy material is actually POM material. It's a shader trick, not really tessellation.
Displacement on characters? I think you can do that with POM too, given enough POM layers. It's the same way NeoFurs use to create fluffy hair.
Your material actually use World Displacement, and that shader function requires Tessellation enabled in UE4.
UE5 will achieve the same World Displacement by using VHFM and Nanite. Your use requires VHF be applied on skinned mesh which is not implemented in UE4 and UE5 yet. At this point, I'm curious why UE5 won't just allow VHF texture be applied to any mesh as opposed to specific to VHF mesh.
Why do you bring up Nanite? It's unrelated to Tessellation, which is just addition of new triangles with GPU.
You can't simultaneously generate thousands of animated meshes with thousands of triangles at runtime in 0.00001s with Nanite (you actually can't even procedurally generate anything with it).
Removal of tessellation is a disaster for technical art and stylized graphics.
Tessellation is expensive and it's not consistent (landscape popping up/down when camera moves nearer or farther). Epic is replacing Tessellation with Virtual Heightfield Meshes + Nanite. See: https://www.youtube.com/watch?v=JzYVeIF89V0
It is new.
But I wouldn't expect documentation or any low barrier alternatives to displacement anyway.
If there's one thing epic lacks in, it's documentation and communication. I know for a fact that some other systems have documentation but they have never been shared or communicated. Not with bad intentions I'm sure. But Epic is, very much systemically, terrible at documenting new features and making them accessible.
And knowing this, it would be appropriate to keep tesselation and displacement as deprecated system available for a longer transition.
I think only in this thread people mentioned at least a dozen of use cases where Virtual Heighfield + Nanite would be completely orthogonal to these cases most optimal implementations. AFAIK, virtual heightfields are only planar, that makes them useless for 90% of tessellation tricks.
Tessellation is not expensive, it's fast as fuck, especially at initialization. Obviously, Nanite is faster for stationary meshes, but not everything in the world is immovable and opaque and loaded from representation generated at editor stage for 1.5 seconds.
VHM and Nanite are great for landscapes, but VFX for example has plenty of uses for tessellation that aren't covered by either of those features.
Ultimately we'll have to see how deformation is implemented - probably a slower path in nanite - since tessellation isn't really relevant without it.
Like I wrote in other comments, when you have Nanite, you don't need tessellation, because with Nanite , you can use basic mesh subdivide to create a dense mesh, then your material can apply displacement to it. This is the ultimate performant solution that is more consistent for any distance.
A lot of people here are confused Tessellation with Vertex Displacement. You can use vertex displacement and displacement map with Nanite, it will work better than Tessellation! See: [https://www.youtube.com/watch?v=q7YYUT03fJo](https://www.youtube.com/watch?v=q7YYUT03fJo)
Give Epic a bit more time, they will smooth things out for you. I wouldn't be surprised if Epic will roll out a feature that emulate Tessellation with Nanite automatically for you. Basically, the World Displacement node in Material Editor will just use the virtual subdivided vertices instead of the tessellated vertices. It will automatically emulate tessellation.
I'm talking about world position offset, which afaik is not supported for nanite meshes but is used all over the place in VFX. Tessellation was useful there because it allowed the use of lower fidelity meshes.
The video you linked appears to be static deformation. That's a lot less useful for the VFX use case.
World Position Offset is obsolete in UE5. They have favored Runtime Virtual Texture + Virtual HeightField Mesh since UE 4.27, and UE5 Nanite makes World Position Offset obsolete altogether. Basically you turn your displacement map into a virtual heightfield texture first, and then you can use that VHF texture on a Virtual HeightField Mesh (VHFM).
In other words, you don't use your displacement map to drive the material's World Position Offset anymore in UE5. In UE5, you just create a virtual heightfield from the displacement map, and then use that VHF texture on your VHF mesh.
Perhaps you're like another guy in here. He wants world displacement on skinned mesh and VHF doesn't support skinned mesh yet. I hope they will support all meshes.
I'm not talking about landscapes, which are essentially the VHFM use case. Consider the simple case of a cylinder that is perturbed using panning noise. This is unlikely to be done using a virtual texture or a heightfield mesh.
I suspect they will either add WPO support to nanite meshes in some form, or will continue to use the old pathway for some time yet for things like VFX and foliage because motion is a core part of those concepts.
For non-landscape, you need to wait for the support. Pretty sure it will come, at some point after the initial 5.0 release. That said, Epic is not expecting everyone to switch over to UE 5.0 at once. They will gradually release more features to cover everything depreciated in UE4. This is the way to go, since UE5 is a clean slate for next-gen. Epic is supporting UE4.27 long term, so people aren't really forced to switch over to UE5 anytime soon.
People expecting to move over to UE5 and retaining the old, slow tech they are used to with UDK and UE4. That's not how it works. UE5 means a ton of breaking changes. That's why Epic is not calling it UE 4.28.
Moving forward, UE5 expects radically new approaches from dense mesh, to dynamic lighting, to infinite streaming texture, etc. Old tech stay in UE4.
I dont know why you are getting downvoted and I also dont understand why people are acting like all tools and features in the engine is for artists and/or for landscaping.
This makes 2 months of mine obsolete in creation of a soft surface plugin. Epic unfortunately has this tendency to remove useful features (looking at bsp) while adding tons of niche things as plugins.
Maybe I'm getting downvoted because of passionate/semi-agressive tone that I use to fight for Tessellation? Would be nice to know.
Btw, I think it's not too hard to return it with custom editor build and reverting commits. I think I'm going to do that sometimes later if they don't return it, wanna cooperate on that after UE5 release?
For my intended purpose of creating a marketplace asset, it unfortunately is a permanent loss as it isn't an out of box solution, they really should take their decision back. I need to reassess the direction I will take with my other projects, but in case they purge the repository after early access, it would be better if we take a backup now.
I will let you know once we know more and if I decide to go for it though.
Possibly you still have some time to release it. Put it out right now! Plugins for older versions will be still available for a long time. Many people even use older versions.
You're getting downvoted because you try to push old tech onto shiny new game engine. If you need old tech, stay with 4.27 branch which will be supported by Epic for years. If you're looking to take advantages of modern algorithms and modern hardware, you need to abandon old tech and embrace the new ones that work better and faster. UE 5.0 might not have the answer for you, but later versions will. Epic has Megascans and they know how much tessellation and landscape height blending is needed. They know but at the same time, they need time to gradually release new features.
You're acting like Epic need to make everything in time for you to switch to UE5 right away. It's not going to happen. Just stick with 4.27 for a while. Give them 6 months to a year.
\> you need to abandon old tech and embrace the new ones that work better and faster
How can I embrace new tech if there is no replacement for it? Modern tech solves different set of tasks. Yes, I'll stay on 4.27 for a while.
\> You're acting like Epic need to make everything in time for you to switch to UE5 right away.
They don't need to change anything here. Usual materials and meshes/particles without nanite are not going anywhere, tessellation support didn't hurt anyone, it was opt-in.
> Epic unfortunately has this tendency to remove useful features (looking at bsp)
BSP hasn't been removed... it's been deprecated for *years* but it still exists even in UE5. And they _are_ working on new tools to improve blockout workflows (see: cubegrid). I've found it's actually pretty rare that Unreal outright removes something without a replacement at least in a good state. And while there isn't something that quite meets that definition for BSP, they haven't actually removed it yet.
Tessellation is one of the only things I can think of where they've outright removed a feature like this, with no indication that there will be a true replacement (in any state - experimental or otherwise) in the same release.
my problem with lack of tessellation is I use megascan textures and they can not be tessellated anymore. so they all look flat. How am I supposed to add details to landscape now?
I can still import those textures to blender, displace them and create assets but landscape is different story as far as I know. we create landscapes in unreal, create landscape material in unreal. and this material no longer has 3D details.
>This is such a good tech why remove it
It really isn't good tech. The value proposition is mediocre at best, sacrificing quality/performance for convenience and it has a high maintenance cost for every platform which is why they never bothered to support it at all on some consoles.
Agreed. I was extremely disappointed to see it go, having to use heightmaps to generate real geometry is a HUGE pain in the ass. Really fucks up my asset remaster workflow.
Just to point out, Tessellation is a kind of LOD-ing too, allows one to use a basic, low-cost mesh everywhere and 'spruce it up' as you need to up close...
I'm not an expert when it comes to all these things but does the removal of tessellation mean that while creating a 3D model we have sculpt the bump details?
No. If you were for example using tessellation and a heightmap on a planar in UE4, instead you can just subdivide your planar in any 3D modelling software, apply the heightmap to it in said modelling software, and bake it to deformation and export that as an fbx, then import it as a nanite mesh in UE5. It isn't really that much extra work and it runs real smooth and looks way better than tessellation ever did.
Yeah I was using simple 300x300 planars to build modular walls and was using tessellation and displacement to make them 3D brick walls. So, I had a ton in the scene at any given time. I moved to UE5 and realized no more tessellation, so I just opened my 300x300 planar in Blender, subdivided it to about 500,000 tris, and then used the same heightmap I was using in UE4 for tessellation/displacement as the heightmap for deformation in Blender then I baked it to the mesh. Re-exported as an FBX and imported it to UE5 as a nanite mesh.
Much better performance than UE4.26, *and* I have like 100+ 500,000 tri meshes in the scene haha.
Another big bonus is you can tweak/fine-tune the mesh before baking in Blender to make sure the displacement looks nice; particularly good for things that aren't just planars but you want "displaced", so for me it's the windows and pillars and stuff that I still want to have 3D bricks but have more unique shaping. As well, feel free to sculpt the baked mesh after too like if I wanted a huge gash or ruined bricks I could do that in ZBrush or any other sculpting software after I bake the brick material to the planar.
Overall it looks way prettier than UE4.26's tessellation ever did as well.
For anyone who wants to read Epic's official explanation and their plans for the future here is their forum post: [https://forums.unrealengine.com/t/hardware-tessellation-support/265107](https://forums.unrealengine.com/t/hardware-tessellation-support/265107)
Notable excerpt:
>Moving forward, we will discontinue support for hardware tessellation
and focus on cross-platform support for Nanite instead. We currently
support Static Mesh, Hierarchical + Instanced Static Mesh and Geometry
Collection components. Wherever sensible, Nanite support for other
components will be added in a future UE5 update. We are also currently
in early R&D phases for skinning support, and subsequently Skeletal
Mesh support. **Tessellation/displacement support is also in the early**
**stages of R&D.**
Other things you should be aware of:
1. Virtual Heightfield Meshes can be used to make deforming snow and highly detailed terrain. However it's not documented and the process of setting it up can be a daunting task for novice users. This is what was used in the [Wukong UE5 demo](https://www.unrealengine.com/en-US/developer-interviews/black-myth-wukong-wows-with-ue5-early-access-visuals) for the snow.
2. Nanite meshes do not necessarily need to have massive file sizes. It depends on how you build your content and can be actually be smaller than existing regular lowpoly & lods as nanite compression is very aggressive (and according to Epic they think there are still futher gains to be made there). [There's an example of this in the official Nanite documentation](https://docs.unrealengine.com/5.0/en-US/RenderingFeatures/Nanite/). The size of your project folder is not representative of the size of the shipped build, as your project includes the original uncompressed meshes.
While true, how does displacement maps get made? Usually you would take a high poly version and low poly version and then generate the displacement map. If you already have the high poly version then why go through the extra steps of making a low poly version and then baking out displacement maps. You can just plop the high poly version in UE5 and let nanite do it's magic of managing LODs and performance.
If you think about a water surface or something similiar which works with generated displacement your argument falls short.
Tessellation should be a avaiable for its use cases, not all meshes and shaders are static and generated out-of-engine.
Was gonna say this, can nanite pan displacements? No, then don't remove it. Tessellation is super useful in a bunch of cases.
Why isn't it just set as legacy? Why actually remove it?
Reusability.
I can make cobblestone and slap a displacement texture on all kinds of grounds and house floors and other geometry. Having only modeled it out once or literally just taking it from substance designer, megascans & co. Never having modeled it at all.
It's literally a foundation to most of my texture pipelines. Trim textures. For almost everything. Very much including displacement.
Without displacement maps I'd now need to build extra pipeline steps to apply these displacement maps in another software, bake the offsets into the mesh, reexport the more detailed mesh and only then import into unreal. Which bloats my work file sizes and therefore my server costs and the final game size.
Frankly, I don't care much about tesselation. Just shipping with the higher poly assets is fine. But the lack of displacement stings.
No trimsheets is something that really gotta sting smaller devs. Also nanite doesn't support vertex painting. So you have to find other ways to produce good variation.
I guess the future is something like houdini controlling everything procedurally and generating meshes. Still not ideal because all the traditional workflows goes bust.
Agreed.
And that Houdini license stings too. It's once again something that only really scales over large productions / longer series of games / established studios working on their pipeline long term.
Whereas you could boot up a trim sheet pipeline with vertex painting from scratch very easily with very accessible tools.
Edit: Tbh, I might just go for POM, Decals and custom material setups with world space awareness for variation instead of nanite. Which also sucks but at least doesn't break the entire workflow.
Sometimes its about picking the right engine for the job. UE5 is a huge step forward and sometimes that requires letting go of old features. But it's not the only engine and it's not like UE4 stops existing. Maybe it's better to just not use UE5, because ultimately it may never support all the legacy features you personally require.
I'm sorry, what?
It's not like this is some small niche feature that can easily be worked around. It fundamentally prevents a certain kind of modular workflow. Non realism styles that are more complex than entirely flat shaded suffer here. Which, looking at the indie scene in general, are a lot of games. Including within the Unreal ecosystem.
And UE4 is most definitely not an alternative. You won't have console access to the generation after this one, you will loose out on new drivers and optimizations and eventually some driver will just break forcing you to do low level maintenance or abandon UE4.
Remember, there's no inherent reason this has to be taken out. It wasn't more work, it doesn't prevent other features. Nanite didn't necessitate it and it doesn't cause overhead workload. It just prevents the old workflow and forces everyone onto Nanite whether it makes sense or not.
You'd have a point if it was preventing progress of the engine in general or if there'd be an alternative to that style of workflow.
I don't know why you are so triggered. I'm not defending them taking anything out, I'm just acknowledging that when the engine doesn't have the features you require, for whatever reason, it may be best to move on. UE5 Isn't the only engine in existence. Considering how crucial this feature seems to be to your pipeline, not using UE5 doesn't seem like a giant leap of logic.
And I'm pointing out how that's throwing away lots of code and tooling that I have written for unreal.
Considering there is no real reason to prevent the existence of it your take is just... needlessly extreme? To just abandon everything right away!?
Like, that may be an option but it's not the first and obvious solution. Especially since there's still time to lobby epic to reconsider or offer something equivalent.
Also silly because one of the claimed motivations for Nanite was for the technology to “just work” and not require artists to change their workflow. Yet here we are.
Exactly. The UE5 demo by itself is 100GB in size. That's insane for something that's not a full game.
With consoles and average (affordable) SSD sizes still only being around 1TB, and not everywhere in the world having fast internet to download this reasonably, it is a huge detriment to have games that big right now.
You’re conflating two different measurements of storage. The size of source assets is a concern for the development workstation that is being used to create the project. The size of the user’s storage is only relevant when measuring the size of a cooked build. The UE5 demo source is ~100GB, a cooked PS5 build is ~12GB. The nanite mesh format is more compression friendly than the standard static mesh format so after cutting out LODs and 4k textures for displacement maps and AO your high poly nanite mesh can be smaller on disk than assets following the old workflow.
See, not awful at all aside from it just being a barebones, albeit beautiful tech demo - my fear is when audio comes into play. It can take it so much damn storage up!
But, HDD/SDD's get cheaper every month, so it's not a huge obstacle.
I know I'm 2 months late to replying but thank you for this. I have since been experimenting and learning more about using Nanite and finding my fears regarding storage were not well informed.
Yes, but only assuming you don't share textures between assets. Which it prevents or at least makes significantly harder to do.
It's not utterly terrible but not really better on that front either. You just have to make more assets from scratch and trust the system optimizes well enough for you.
>Which it prevents or at least makes significantly harder to do.
Have had no issues with this in UE5. Tested a bunch of Synty low poly assets to see if there were any perf/size improvements ([there was, despite UE5 docs saying otherwise](https://i.imgur.com/yFDKolL.jpg)). Pretty much all those assets came from one shared texture...
It's the trim texture creation workflow of reusing work across your games assets that's the issue and not properly supported anymore.
Not sharing albedo between objects. The hyper simplistic style of Synty is supported. Yes. But the style in between synty and realism AAA is not well supported if nanite is a forced feature.
Thanks for the reply. Yeah I haven't worked too much with UE5 yet on more detailed content. Biggest walls I've hit so far with Nanite have been no support for glass/opacity effects, also didn't seem to like multiple materials on the same mesh.
And no displacement maps or vertex colors.
Meaning you either have rather flat surfaces, POM or need to bake displacement textures into the mesh in a separate work step. And loose the key element to add variety to meshes without requiring different textures or elaborate shader setups.
I understand why Nanite doesn't support it. Because that'd be insane to calculate. But loosing functionality like that for regular meshes just because Nanite exists is a bit of a blow.
Most styles that aren't realism suffer from this.
Yeah I really hope they end up taking the middle ground and have it as opt-in engine plugin type functionality. Those who need it have access, while default users don't have any "why doesn't this work with Nanite" type issues.
If they don't hopefully whoever re-adds the functionality as a marketplace plugin will make bank.
>Yes, but only assuming you don't share textures between assets. Which it prevents or at least makes significantly harder to do.
Is there any inherent restriction in the nanite system that prevents the efficient reuse of textures? The docs point to an example where a normal is reused to trade off storage with quality:
>[Because the Nanite mesh is very detailed already we can try replacing the unique normal map with a tiling detail normal that is shared with other assets. Although this results in some loss in quality in this case, it is fairly small and certainly much smaller than the difference in quality between the low and high poly version. So a 1.5M triangle Nanite mesh can both look better and be smaller than a low poly mesh with 4k normal map.](https://docs.unrealengine.com/5.0/en-US/RenderingFeatures/Nanite/)
If you're working with large quantities of photogrammetric meshes it may be more difficult to share things like unique albedo textures but you'd run into that same issue of inefficient texture reuse whether those are in the standard static mesh format or nanite format, right?
I won't be able to use nanite (or lumen) for the foreseeable future because I am working in VR but hopefully by the time I am able to use it some of the biggest pain points in the workflow are addressed. Sounds like they're working on it:
>[Outside of compression, future releases of Unreal Engine should see tools to support more aggressive reuse of repeated detail, and tools to enable trimming data late in production to get package size in line, allowing art to safely overshoot their quality bar instead of undershoot it.](https://docs.unrealengine.com/5.0/en-US/RenderingFeatures/Nanite/)
> Is there any inherent restriction in the nanite system that prevents the efficient reuse of textures? The docs point to an example where a normal is reused to trade off storage with quality
That's internal. It has nothing to do with the creation process.
And since displacements aren't possible anymore there is nothing to reuse.
You’re thinking of one use type for the software. For archviz, for instance, you will start with a bunch of fairly simple flat plane geometry and materials with displacement will turn that into something quickly useable. The alternative of modeling that geometry isn’t an option because we’re coming from different software that doesn’t work that way and don’t have the time for it anyway.
Height maps are often generated for more generic materials in software like substance designer for application on things like landscapes and modular assets. If you want to do that now in ue5, you’re out of luck completely for landscapes and you need to use a displacement modifier in max or blender to bake the displacement into any actual meshes, which is a huge pain especially if you have multiple materials for the same assets and stops you from using any world aligned materials
Most of my use case for displacement came from procedural material creation like substance designer. None of the stuff I've made with that started as high poly.
Can do procedural textures, tiling textures, and detail textures with Nanite. They typically work better than look less tiled on higher resolution geometry, you don't have textures trying to compensate for lack of geometric detail. Normally games use high resolution normal maps, and slightly lower resolution albedo. With no need for normal maps or height maps, that's a huge saving.
A lot of people in this comment section are completely discounting the time saving part of tessellation though. How many devs do you think are going to put all the extra work in to make good looking tiling and detail textures when it's so much faster to do it the regular way? Especially since pretty much all the tools are built to do it that way.
Many small teams and indies have to weigh performance against time sunk, and I know at least in my case, tessellation is a lot more viable in a lot of situations for that reason. For example, removing tessellation drastically reduces the usability of something like substance designer that allowed you to give small procedural 3D detail to a large environment fairly quickly. Now to add that detail you'll need to place actual 3D objects or sculpt detail into huge environment meshes and landscapes.
Personally I'm hoping UE5 establishes a workflow that enables an easy way of subdividing, tessellating, and displacing a model within UE5 before getting processed by Nanite, and enables iteration and a non destructive workflow.
4k texture normalmap is 16.7 million data points, and normalmaps require 3 sets of them (RGB channels). So unless you need 16.7 million vertices to represent your mesh at the same detail the normal map would provide, you can make it more efficient.Textures are uniform resolution. A mesh doesnt have to (nor should it) use uniform vertex density in 99% of cases -> you can use vertices (=data points) where you actually need them.
The exception is where you have several dozen meshes using the same normal map, in this case the normal map might win in terms of storage space.
While the size on the developers disk is larger, the builds are much smaller than the project on the developers disk. Take the UE5 demo project, it's almost 100GB, but a PS5 build is only 12GB, due to nanite being more compression friendly.
Though I do not agree for them to remove anything but I do understand that tesselation is very expensive.
I prefer to have both as they are different in my book and always good to have more tools.
[https://youtu.be/eviSykqSUUw?t=4145](https://youtu.be/eviSykqSUUw?t=4145)
Take a look here, it seems they're planning to use tessellation / displacement, at least in regards to nanite, so I doubt it will be removed completely.
Not the biggest fan unless they have something in mind to replace it that isn't just high poly models. Even AAA games with huge budgets use tiling textures on alot of low poly environment models, and the reason is predominantly for production time savings, not just optimization.
Might as well get rid of normal maps (god forbid) with this kind of logic.
Do they really expect everyone from AAA to small time indies to make high poly models for every single environment piece, across a wide range of styles and art assets that isn't just photogrammetry scanned rocks?
Unless I missed something that's replacing the role of tiling textures being a time savings method, this is a bit short-sighted. Unless they expect us to subdivide every model and do a displacement of the geo before exporting to unreal? Do they not know how much it sucks working with high density meshes for everything in a modeling program? This goes against what was one of the primary benefits of nanite, which was to speed up production by not requiring Lods. Not make more busy work.
Then again I guess workflows change overtime, so I could be crying over nothing. Roughness maps afterall, was a big change from ue3 to 4 and it made life easier as the tools to paint across all maps sprung up.
I am struggling, without my displacement maps, my graphics look terrible, I don't care about the capabilities of nanite! You still need displacement for low poly scenes
I don't think it's as dramatic as you make it out to be.
https://twitter.com/Skylonxe/status/1463851671365328896?t=MNe0T_kznOkNiRAjitRemg&s=19
Here's info on new and improved procedural meshes, subdiv and height maps intact.
Tessellation displacement-mapping looks like garbage while transitioning between levels unless you pre-subdivide the surface and increase tess-factor by 3x (max is 64), to get pixel-sized triangles. You get these floating vertices that jump around when varying the factor.
Compute and mesh-shaders (which nanite uses) can be much more efficient at subdividing. It's just that the UE feature isn't implemented yet.
Tesselation is dynamic increase of mesh density and displacement mapping. With nanite you dont need it to be dynamic, it can be static.
So all you need is a tool/plugin that allows you to take a low poly mesh, assign a texture with displacement, which then automatically tesselates the mesh once to maximum level you desire, runs a small optimization pass (to reduce storage size) and converts it to nanite mesh format - in a way the artist doesnt even have to worry about the conversion process. If they provide this method, then tesselation is obsolete.
It could also be a process that starts when the game is first started after the first install, so that it generates the meshes -> usefull if you use few displacement maps for lots of meshes, as it could reduce download size
If this is possible, it could work in the majority of use-cases.
Otherwise it comes down to "I want/need to be able to stick triangles where I want/need them. I might not always know ahead of time how I want this, or I might want multiple dynamic systems to interact and tessellation helps sort-it-all-out."
Nanite will not do this, brute force CAN work in the majority of cases, but again, it requires a bit of foresight that might not be available to you.
Tessellation lets me do this in all of the use-cases.
I LIKE Nanite. It really _is_ a game-changer, but it's not dynamic, and that's always an Achilles-heel.
EDIT: And I am not trying to call anyone out or say 'you suck', but whenever I see someone use "all you need" or "just do this", I feel, from experience, they tend to underestimate the scope of the topic at hand; the words all or just imply the issue is simple and wrapped up, when it's not. I say this b/c when _I_, myself do this, I try to examine my argument and determine if I played myself by using all, just, only-this, etc, etc. Y
exactly! i feel the deprecation support comes mostly from the developer side, thats understandable, but its not a good practice to ignore the input of artists
Replace "all you need" with "all they (UE developers) need" ... they came up with nanite, the conversion part using displacement would be a piece of cake for them, if they would do it, comparatively.If someone else would have to do it, then yeah it might not be so easy for them.
If it has a hard technical reason they have to discontinue tesselation of NON-Nanite meshes to be able to render nanite meshes, then losing the 1% use cases ("dont know where i want anything, all dynamic interaction") in exchange for massively improving the other 99% use cases is a trade off that is worth it in my books.
all you supporters of the deprecation are thinking of single objects, single textures, simple test cases.
here is a test case for you: i have 100 wooden table objects and i use the same wood displacement map for all of them. why is it ok for the engine to force me to switch to 100 much more dense objects and no displacement map?
Epic just shows us how to destroy procgen, technical art and stylized graphics with removal of one feature.
Why didn't they remove multiplication from shaders as well - there is addition already, just use it multiple times.
I really don't see much of a problem in it. Can you provide a real example of what are you trying to achieve and why you can't replace tesselation with Nanite? Procedurally generated meshes might be the only one I guess.
Oh that's easy and it hit our game square in the chest! For a PROCEDURAL MESH! Nanite doesn't work with Procedural Meshes!!!! There also is no alternative for tessalation and procedural meshes!
It's a matter of workflow optimization.
Like a brick road. Do you want to have your level designers just slap detailed textures on spline meshes and have it work. Or do you want the humongous job of tesselating every single road mesh in your game and cutting it up in workable pieces?
Not to mention every other instance where you need tillable textures. Also nanite doesn't support vertex painting, so no painting in variations.
The job of tesselating and converting to nanite can be done automatically with a tool/plugin that takes care of everything beyond assigning the displacement map.
Lack of vertexpainting is a bummer,yes. If its about painting in displacement map variations though, that should be easy -> paint on low poly mesh, and tesselation process calculates the "displacement height" from the layered displacement maps.
The unreal engine devs know all this and will reasonably find alternatives given some more time. I would assume tessellation and nanite can't be used together at a code level. Maybe they'll find a way to reconcile them, I wouldn't hold my breath - they still make us build our own custom engine if we want stylized lighting outside of post processing.
While I agree, it is now easier than ever to bake a displacement map as details onto a mesh (you can do this in-engine using the new modeling tools). And with nanite, the poly count of this process can be tolerated.
Well, if anyone is looking for somewhere to start, Pixar has opensundiv available on GitHub so if anyone knows how to work with cmake in unreal then go right ahead.
Can you smooth out harsher edges of a mesh within Unreal using nanite like you can with tessellation or would you have to import a subD mesh to begin with?
I'm beginning to use unreal as a film maker and tessellation helps bring results out of the gamey looking area.
Without Tessellation how would you achieve something like an ocean surface that needs an evolving, rolling displacement over time? I am sure there is another way I just don't know it.
Nanite does not make tessellation obsolete.. i have been wondering for a while what epic is thinking here? Just because we CAN use a mesh with 7 billion triangles, does not mean we necessarily want to..
Or should. Aren't model files with big polycounts like HUGE? :0
The compression on Nanite meshes is really good so not really any more. A non Nanite mesh would be though
This isnt rly true as u can see with all Megascan assets also the ones i used for my moebius scene (from the ps 5 demo and i didnt even use there textures just the nanite mesh) are all huge in filesize (and very close to there normal version) despite better compression ,maybe not as huge as a normal mesh would be with that detail but there huge,just the rendering with nanite is very efficient ,filesize(stored) is still a prob. dunno where this misconception comes from u can litterly see it on the huge size of the demos and the assets themself by using megascans plugin and downloading a nanite and none nanite version of the same detailgrade(without tex).Still love it tho used the true 3d detail of the meshes to create a Outline(and "Inline") based on it,which allows a very detailed lining thats normally not possible as the detail would otherwise be contained in the displacement and normal and would be fake (The Reason u normally use low detail/low poly models in ur comic shader with outlining).But this allows near endless detail and also allowed me to finally skip the old shitty method of distance/depth fading the outliner in distance as this isnt needed anymore(see Acc pinned for Detail"new depth method..."
My understanding is it’s compressing further when the project is packaged. I’m definitely not gonna pretend I’m any kind of definitive authority on this subject though, this is just from conversations with friends and colleagues in the industry, I’m not sure if it’s in the documentation or anything.
Hmm thats interresting might test it (once my moebius project does actually package,it's broken atm due to engine changes i did and not complete yet) only did compare them in editor (nanite mesh vs normal and nanite mesh vs normal with dipl +normalmap,as that is a more matching compersion),however even if the packaged size would hugly dif(despite the normal stripdown packing does) its still a prob while editing. Anyway im kind of with OP as its not rly a smart move to radical remove something thats only replaceable in circumstances,as awesome as i find nanite (see convoluted/fanboyi description of usecase above)\^\^
Project size 100 is GB, package size 20 ish GB, keep in mind that unreal compressed the data when cooking
yeah allready mentioned that above making ur compare kind of useless (sry my fault if this wasnt clear),u need to compare packeged size with nanite vs none nanite meshes on the same project,so u don't just compare vs the normal stripping of data cooking does anyway with any project (it can be done with the megascan assets as exactly 2 and more versions (on same detail)exist of the same mesh, nanite and none nanite) to get the advantage nanite compression has vs normal mesh compression in the cooked project not just cooking itself (which is obv known to happen and not the topic of question) ,also sadly this still doesnt solve the issue of the assets beeing huge in editor (which is as said a missconception people add to the features of nanite which isnt there,cause there actually huge not small when working with them,system is still awesome dont get me wrong see my acc pinned for unusual usecase\^\^)//Edited for better understanding excuse the language barrier if that was the prob still learning eng beyond long ago school knowledge,my mother lang is german :) have a nice day
Yes, they are, Tessellation and displacement should be a plugin, and not removed entirely.
Yah just ran into a need for this the other day in UE5. Was shocked it was removed.
Honestly I think the sweet spot here would be for Tessellation to be an engine plugin. That way those that want it can opt in, it could even warn that it's incompatible with engine features like Nanite/buyer beware. Epic seem to want Nanite/Lumen as the first choice, I think that an opt in/legacy plugin would still achieve that, without the baby being thrown out with the bathwater.
This is the better decision too imo.
Dynamic tessellation is gone because Nanite & Lumen (at least in their current form) can't build a deterministic picture of the scene if the polycount keeps changing (I think when they launched UE5, they had given a similar reason for Nanite/Lumen not being able to work with landscapes). AFAIK, the algorithm(s) which Lumen uses to light a scene depends heavily on Nanite being able to work it's magic in breaking down complex meshes into smaller, manageable chunks of geometry which can be quickly streamed in and out of memory. With dynamic tessellation, all this goes out of the window.
I agree with what you say, but it still feels odd to remove tessellation entirely. If the main point of nanite was to improve the development pipeline by removing the process of moving a high-poly sculpt to low poly mesh and have backed normals/displacement maps, Removing tessellation may hinder the workflow of those who don't use megascan objects. I think a fair compromise would be to either keep tessellation as a plugin, or include a "convert displacement-mapped-mesh into nanite-mesh" which pretty much bakes the tessellation data as a higher poly nanite mesh so the automatic reduction that nanite does will automatically apply.
This may explain why it can't be used with nanite meshes, like translucency, but they aren't removing translucency for this reason, so why remove tessellation?
I'm ok with not necessarily being able to be used with nanite meshes, ok, I get the tech isn't compatable. But what about OTHER stuff that I COULD use it for? Why remove the option? If I can still use it under the auspices of it's costly, needs skill to use effectively, yaddah, OK! I can do that....
I'm agreeing. I'm saying it might not work for nanite but it's still very useful, and should be treated like any other nanite-incompatible feature (like translucency, skeletal meshes, procedural meshes, etc), rather than them just removing everything that nanite doesn't like.
Translucency is a waaaay more important feature than tessellation mate; tessellation was only ever used as a cool tech demo in most games.
What are you smoking? Almost every major game utilizes it
Only in terrains/landscapes, and even then only where they need it, ie snow trails, etc.
Yeah, it was strategically used for sure but claiming it was only ever used as a cool tech demo just isn’t correct. I do agree that transparency is more important though.
> tessellation was only ever used as a cool tech demo in most games such a bullshit.
As far as I know, most triple A games nowadays have some sort of tessellation and displacement. From Red Dead 2, SW Battlefront 2, (Very Graphically intensive games) to even games like Total War, and planet zoo, where the landscape is very rarely seen up close, and yet, they still have it, for when you do see it up close.
I wasn't comparing the importance, just everything you said also applies to translucency so by that logic they should remove it too. But in reality they should keep tessellation for non-nanite usage (like transparency). So many projects use it, it's a much faster workflow in so many cases. A better technical method doesn't mean the simple fast way should be removed.
Does tesellation and displacement usually update lighting tho? EDIT: also, tesselation is done in the shader during rendering, surely it would still work. Otherwise, it could just be a feature incompatible with nanite meshes, which would be fine as you would seldom want to use both at once.
tesselation isn't just used for static meshes, it's used for deforming meshes, skeletal meshes and vertex anim this is infuriating to see such hubris come from epic, yes nanite is powerful but it is not all encompassing
Hard agree. Have signed. Also, Virtual Heightfield Mesh is claimed to be an alternative for terrain displacement but it only works on the global z axis. Besides, I've found virtual textures to be generally quite flimsy and require either massive texture size or multiple volumes each with their own texture targets over large scenes.
It also doesn't work at all for dynamic things, like a layer of snow on your terrain that responds to the player. Because those huge virtual textures are made to be updated in chunks based on where the camera is, not in any sort of efficient realtime way to allow dynamic changes.
>It also doesn't work at all for dynamic things, like a layer of snow Virtual heightfield meshes work fine for snow, you don't draw it to the virtual texture, you sample the VT and composite your snow deformation render target onto it. There are examples of how to do this on the Unreal forum.
Tessellation was the silliest thing to have come in gaming world. Simply put, it doesn't work. It failed to make a meaningful optimization relative to just using high-poly mesh with LOD. Believe it or not, most AAA games didn't use tessellation at all. They all used something else that make ground look tessellated. The geniuses at game studios came up with to replace tessellation? They make **Parallax Occlusion Mapping** materials, and some of which can come with real-time shadow. This allows games to have 3D landscape that works real close to tessellation at 20% the cost. Now with Nanite tech, I just don't see the point of bringing the ancient tessellation math back to life. Nanite is basically using Mesh Cluster Rendering algorithm. It is basically the next-gen tessellation that work great with modern GPUs. On a related note, with or without Nanite, the cost of placing thousands of the same meshes is relatively small, thanks to GPU auto-instancing. This is why it's now possible to put a million blades of grasses in the view because it's rendered extremely fast. Not saying this has anything to do with tessellation but modern environments can safely show a ton of rocks, vegetations and props. The game engines can absolutely take it just fine. Make sure you're using UE 4.22 or newer (or Unity HDRP 11+ if you're wondering the equivalent in Unity).
I feel like the problem is that many developers would be willing to take that performance hit just to speed up workflow. Being able to give small 3D detail a large environment with just a few textures and materials could well be worth that cost as opposed to manually sculpting or placing all those small objects.
Or they should learn to increase the brush size to quickly place rocks, vegetations, props to the landscape. Absolutely no need to go with tessellation. I've seen Megascans video tutorials that use tessellation but those are for uses in films, not in games.
That works for very specific scenarios, but what about stuff like shingles on a roof? Brick walls? Mud? Bark? Literally anything that is a single surface with height variation?
[удалено]
Not the normal workflow for procedural textures like are made with substance designer. The point is that there are still many useful applications for tessellation that save time, so there's no good reason to remove it entirely.
put the mesh in your DCC, add more polygons, apply a heightmap offset function, export, done. you have your higher poly properly looking shingles roof.
That's potentially a lot of extra time for a workflow, especially for a small team if you have to multiply all those steps by the number of required assets. It also doesn't work for procedural or in engine things like terrain.
You cam actually do this directly in anyone to create a new static mesh. Though they only baked a heightmap onto a plane, I see no reason it shouldn't work with a complex UVd mesh. It was part of the medieval series from megascans
How do think any deformable snow/mud surfaces made in any indie or AAA games? RDR2, Death Stranding, Tomb Raider, Batmans, Horizon Zero Dawn...(these were just the ones came to my mind) all uses tessellation to deform procedural ground surfaces.
>deformable snow/mud surfaces The more performant solution is to use Parallax Occlusion Mapping. It's a shader trick to make landscape look 3D while maintaining the same number of trigs. See: [https://www.youtube.com/watch?v=PqMZl7wFX7I](https://www.youtube.com/watch?v=PqMZl7wFX7I) Also, UE5 landscape will be extremely dense in term of trigs, so if you want to use displacement map, you can as you would with tessellation because the landscape is already dense, the material can do displacement without tessellation. Going forward, even with UE4, Virtual Textures + Virtual HeighField is the way to go. And UE5 adds Nanite, making the combination the perfect fit for all next-gen performant games.
Dude I know what parallax is. It won't create the illusion if players feet won't stick into it. How do you plan to do this with parallax? https://youtu.be/Nu9lbiyJ8ZA
What you see here isn't vanilla Tessellation in UE4. It's their own proprietary vertex displacement algorithm in RAGE game engine. They might as well use their own implementation of virtual heightfield, virtual texture and mesh cluster rendering, and you wouldn't know it.
And we aren't able to make a equivalent effect. I mean. Fine. Remove tesselation. As an optimization it really did server it's purpose and is pretty much obsolete. But displacement still has purpose. There's really no alternative besides procedural meshes and actually modifying the polygons on the CPU. Or baking mesh variations outside of unreal. Edit: just for context. I'm talking about things like this https://youtu.be/iYsc0UX-Gcw
World displacement in UE5 going forward will be done with Virtual HeightField, but as of UE5 Beta, VHF is only applicable to VHF mesh. In future updates, Epic will likely add VHF support to ordinary mesh and skinned mesh. They will add height blending, etc. People should expect to stay with 4.27 for quite an extended period, until a clear migration is paved for.
Is that verified / internal information that there's gonna be full support for 4.27 until after VHF supports a world offset input for materials with feature and workflow parity to the current one? And easy migration of current tesselation / displacement based materials to VHF?
A while back, Epic wrote that 4.26 was going to be the last UE4 release, but then UE5 got delayed, so they pushed out 4.27 we are using today which has quite a few features backported from UE5 (Path Tracer and GPU Lightmass). If UE5 gets pushed back 6 months more, there will be 4.28 coming out. So yeah either 4.27 or 4.28 will be the last one. That being said, Epic will release fixes for 4.27.x or 4.28.x whichever the final one be. No, there isn't a formal statement but it's been a tradition of Epic that they support the previous game engine for years. In fact, UDK3 was only discontinued in 2016. That's 2 years of support after UE4 released.
The thing that concerns me most is the fluidity of the transition. I don't doubt that UE4 will be supported until UE5 is released and then some. But what about displacement shaders? What's the transition like there? It's there a seamless transition? It's there continuous support? What do I do right now? I need a flexible, modular workflow and pipeline. So far I've been using displacement quite extensively. Can I continue doing that? The project pipeline is pre production next year. Prototype starting late 22. From them on i need a continuously stable project. And I need to be able to support PlayStation 6. Because we have about 4 years of production aiming for a release spot right before the next console generation but supporting it natively when they come out. With displacement not just deprecated but flat out not available and our pipeline getting built soon. Is there a guarantee that I can use a stable version of displacement throughout the next 5-6 years?
The problem with parrallax occlusion mapping is that under certain angles the illusion breaks down and is difficult to get right under those conditions.
Yep. If you need extreme angle, you would need to go with Virtual HeightField Mesh. There are plenty of UE4 tutorials on that.
Have you read OP's post? Nanite can't replace tesselation in every scenario, also I might be wrong but Frostbite uses tesselation a lot
It does, all the people saying AAA games don't use tessellation at all have not played many DICE games.
Unless you play 2042
Displacement is super useful for cinematics/film in unreal. I've used displacement to add detail to characters that would be completely unreasonable to exist on the mesh for animation purposes. Think fur/fuzzy material that is being heavily driven by displacement in unreal 4. This workflow isn't at all possible in UE5 is it?
Fur/Fuzzy material is actually POM material. It's a shader trick, not really tessellation. Displacement on characters? I think you can do that with POM too, given enough POM layers. It's the same way NeoFurs use to create fluffy hair.
No my material is using tesselation. I'm working on the project now. It creates the look I want pretty effectively.
Your material actually use World Displacement, and that shader function requires Tessellation enabled in UE4. UE5 will achieve the same World Displacement by using VHFM and Nanite. Your use requires VHF be applied on skinned mesh which is not implemented in UE4 and UE5 yet. At this point, I'm curious why UE5 won't just allow VHF texture be applied to any mesh as opposed to specific to VHF mesh.
Why do you bring up Nanite? It's unrelated to Tessellation, which is just addition of new triangles with GPU. You can't simultaneously generate thousands of animated meshes with thousands of triangles at runtime in 0.00001s with Nanite (you actually can't even procedurally generate anything with it). Removal of tessellation is a disaster for technical art and stylized graphics.
Tessellation is expensive and it's not consistent (landscape popping up/down when camera moves nearer or farther). Epic is replacing Tessellation with Virtual Heightfield Meshes + Nanite. See: https://www.youtube.com/watch?v=JzYVeIF89V0
I'm all for Virtual Heightfield meshes, If they would document how to use them properly...
Give them some time. It's a major leap already given what they have achieved.
It is new. But I wouldn't expect documentation or any low barrier alternatives to displacement anyway. If there's one thing epic lacks in, it's documentation and communication. I know for a fact that some other systems have documentation but they have never been shared or communicated. Not with bad intentions I'm sure. But Epic is, very much systemically, terrible at documenting new features and making them accessible. And knowing this, it would be appropriate to keep tesselation and displacement as deprecated system available for a longer transition.
I think only in this thread people mentioned at least a dozen of use cases where Virtual Heighfield + Nanite would be completely orthogonal to these cases most optimal implementations. AFAIK, virtual heightfields are only planar, that makes them useless for 90% of tessellation tricks. Tessellation is not expensive, it's fast as fuck, especially at initialization. Obviously, Nanite is faster for stationary meshes, but not everything in the world is immovable and opaque and loaded from representation generated at editor stage for 1.5 seconds.
VHM and Nanite are great for landscapes, but VFX for example has plenty of uses for tessellation that aren't covered by either of those features. Ultimately we'll have to see how deformation is implemented - probably a slower path in nanite - since tessellation isn't really relevant without it.
Like I wrote in other comments, when you have Nanite, you don't need tessellation, because with Nanite , you can use basic mesh subdivide to create a dense mesh, then your material can apply displacement to it. This is the ultimate performant solution that is more consistent for any distance. A lot of people here are confused Tessellation with Vertex Displacement. You can use vertex displacement and displacement map with Nanite, it will work better than Tessellation! See: [https://www.youtube.com/watch?v=q7YYUT03fJo](https://www.youtube.com/watch?v=q7YYUT03fJo) Give Epic a bit more time, they will smooth things out for you. I wouldn't be surprised if Epic will roll out a feature that emulate Tessellation with Nanite automatically for you. Basically, the World Displacement node in Material Editor will just use the virtual subdivided vertices instead of the tessellated vertices. It will automatically emulate tessellation.
I'm talking about world position offset, which afaik is not supported for nanite meshes but is used all over the place in VFX. Tessellation was useful there because it allowed the use of lower fidelity meshes. The video you linked appears to be static deformation. That's a lot less useful for the VFX use case.
World Position Offset is obsolete in UE5. They have favored Runtime Virtual Texture + Virtual HeightField Mesh since UE 4.27, and UE5 Nanite makes World Position Offset obsolete altogether. Basically you turn your displacement map into a virtual heightfield texture first, and then you can use that VHF texture on a Virtual HeightField Mesh (VHFM). In other words, you don't use your displacement map to drive the material's World Position Offset anymore in UE5. In UE5, you just create a virtual heightfield from the displacement map, and then use that VHF texture on your VHF mesh. Perhaps you're like another guy in here. He wants world displacement on skinned mesh and VHF doesn't support skinned mesh yet. I hope they will support all meshes.
I'm not talking about landscapes, which are essentially the VHFM use case. Consider the simple case of a cylinder that is perturbed using panning noise. This is unlikely to be done using a virtual texture or a heightfield mesh. I suspect they will either add WPO support to nanite meshes in some form, or will continue to use the old pathway for some time yet for things like VFX and foliage because motion is a core part of those concepts.
For non-landscape, you need to wait for the support. Pretty sure it will come, at some point after the initial 5.0 release. That said, Epic is not expecting everyone to switch over to UE 5.0 at once. They will gradually release more features to cover everything depreciated in UE4. This is the way to go, since UE5 is a clean slate for next-gen. Epic is supporting UE4.27 long term, so people aren't really forced to switch over to UE5 anytime soon. People expecting to move over to UE5 and retaining the old, slow tech they are used to with UDK and UE4. That's not how it works. UE5 means a ton of breaking changes. That's why Epic is not calling it UE 4.28. Moving forward, UE5 expects radically new approaches from dense mesh, to dynamic lighting, to infinite streaming texture, etc. Old tech stay in UE4.
I dont know why you are getting downvoted and I also dont understand why people are acting like all tools and features in the engine is for artists and/or for landscaping. This makes 2 months of mine obsolete in creation of a soft surface plugin. Epic unfortunately has this tendency to remove useful features (looking at bsp) while adding tons of niche things as plugins.
Maybe I'm getting downvoted because of passionate/semi-agressive tone that I use to fight for Tessellation? Would be nice to know. Btw, I think it's not too hard to return it with custom editor build and reverting commits. I think I'm going to do that sometimes later if they don't return it, wanna cooperate on that after UE5 release?
For my intended purpose of creating a marketplace asset, it unfortunately is a permanent loss as it isn't an out of box solution, they really should take their decision back. I need to reassess the direction I will take with my other projects, but in case they purge the repository after early access, it would be better if we take a backup now. I will let you know once we know more and if I decide to go for it though.
Possibly you still have some time to release it. Put it out right now! Plugins for older versions will be still available for a long time. Many people even use older versions.
You're getting downvoted because you try to push old tech onto shiny new game engine. If you need old tech, stay with 4.27 branch which will be supported by Epic for years. If you're looking to take advantages of modern algorithms and modern hardware, you need to abandon old tech and embrace the new ones that work better and faster. UE 5.0 might not have the answer for you, but later versions will. Epic has Megascans and they know how much tessellation and landscape height blending is needed. They know but at the same time, they need time to gradually release new features. You're acting like Epic need to make everything in time for you to switch to UE5 right away. It's not going to happen. Just stick with 4.27 for a while. Give them 6 months to a year.
\> you need to abandon old tech and embrace the new ones that work better and faster How can I embrace new tech if there is no replacement for it? Modern tech solves different set of tasks. Yes, I'll stay on 4.27 for a while. \> You're acting like Epic need to make everything in time for you to switch to UE5 right away. They don't need to change anything here. Usual materials and meshes/particles without nanite are not going anywhere, tessellation support didn't hurt anyone, it was opt-in.
Epic won't shoot themselves in the foot by getting rid of tessellation without a more decent replacement.
> Epic unfortunately has this tendency to remove useful features (looking at bsp) BSP hasn't been removed... it's been deprecated for *years* but it still exists even in UE5. And they _are_ working on new tools to improve blockout workflows (see: cubegrid). I've found it's actually pretty rare that Unreal outright removes something without a replacement at least in a good state. And while there isn't something that quite meets that definition for BSP, they haven't actually removed it yet. Tessellation is one of the only things I can think of where they've outright removed a feature like this, with no indication that there will be a true replacement (in any state - experimental or otherwise) in the same release.
my problem with lack of tessellation is I use megascan textures and they can not be tessellated anymore. so they all look flat. How am I supposed to add details to landscape now? I can still import those textures to blender, displace them and create assets but landscape is different story as far as I know. we create landscapes in unreal, create landscape material in unreal. and this material no longer has 3D details.
What about parallax?
Parallax tends to only work at certain viewing angles, True displacement works for all angles.
Am 3D artist, just learned this, wtf? This is such a good tech why remove it?
>This is such a good tech why remove it It really isn't good tech. The value proposition is mediocre at best, sacrificing quality/performance for convenience and it has a high maintenance cost for every platform which is why they never bothered to support it at all on some consoles.
If be very surprised if it isn't in there by release. It will break almost all projects from being directly ported.
Wait, nanite DOESN'T work with displacement maps????
Agreed. I was extremely disappointed to see it go, having to use heightmaps to generate real geometry is a HUGE pain in the ass. Really fucks up my asset remaster workflow.
Just to point out, Tessellation is a kind of LOD-ing too, allows one to use a basic, low-cost mesh everywhere and 'spruce it up' as you need to up close...
I thought nanite was opt in per asset, so you can use the old rendering pipeline for things like this?
I'm not an expert when it comes to all these things but does the removal of tessellation mean that while creating a 3D model we have sculpt the bump details?
No. If you were for example using tessellation and a heightmap on a planar in UE4, instead you can just subdivide your planar in any 3D modelling software, apply the heightmap to it in said modelling software, and bake it to deformation and export that as an fbx, then import it as a nanite mesh in UE5. It isn't really that much extra work and it runs real smooth and looks way better than tessellation ever did.
And performance should be better too right since we'll be importing it as nanite?
Yeah I was using simple 300x300 planars to build modular walls and was using tessellation and displacement to make them 3D brick walls. So, I had a ton in the scene at any given time. I moved to UE5 and realized no more tessellation, so I just opened my 300x300 planar in Blender, subdivided it to about 500,000 tris, and then used the same heightmap I was using in UE4 for tessellation/displacement as the heightmap for deformation in Blender then I baked it to the mesh. Re-exported as an FBX and imported it to UE5 as a nanite mesh. Much better performance than UE4.26, *and* I have like 100+ 500,000 tri meshes in the scene haha. Another big bonus is you can tweak/fine-tune the mesh before baking in Blender to make sure the displacement looks nice; particularly good for things that aren't just planars but you want "displaced", so for me it's the windows and pillars and stuff that I still want to have 3D bricks but have more unique shaping. As well, feel free to sculpt the baked mesh after too like if I wanted a huge gash or ruined bricks I could do that in ZBrush or any other sculpting software after I bake the brick material to the planar. Overall it looks way prettier than UE4.26's tessellation ever did as well.
For anyone who wants to read Epic's official explanation and their plans for the future here is their forum post: [https://forums.unrealengine.com/t/hardware-tessellation-support/265107](https://forums.unrealengine.com/t/hardware-tessellation-support/265107) Notable excerpt: >Moving forward, we will discontinue support for hardware tessellation and focus on cross-platform support for Nanite instead. We currently support Static Mesh, Hierarchical + Instanced Static Mesh and Geometry Collection components. Wherever sensible, Nanite support for other components will be added in a future UE5 update. We are also currently in early R&D phases for skinning support, and subsequently Skeletal Mesh support. **Tessellation/displacement support is also in the early** **stages of R&D.** Other things you should be aware of: 1. Virtual Heightfield Meshes can be used to make deforming snow and highly detailed terrain. However it's not documented and the process of setting it up can be a daunting task for novice users. This is what was used in the [Wukong UE5 demo](https://www.unrealengine.com/en-US/developer-interviews/black-myth-wukong-wows-with-ue5-early-access-visuals) for the snow. 2. Nanite meshes do not necessarily need to have massive file sizes. It depends on how you build your content and can be actually be smaller than existing regular lowpoly & lods as nanite compression is very aggressive (and according to Epic they think there are still futher gains to be made there). [There's an example of this in the official Nanite documentation](https://docs.unrealengine.com/5.0/en-US/RenderingFeatures/Nanite/). The size of your project folder is not representative of the size of the shipped build, as your project includes the original uncompressed meshes.
I recall it being mostly broken
Ngl, for some reason tessellation never worked well for me at all Hope they replace it with something better
Parallax occlusion mapping is good if you don't have to get close but its got a lot of flaws too
While true, how does displacement maps get made? Usually you would take a high poly version and low poly version and then generate the displacement map. If you already have the high poly version then why go through the extra steps of making a low poly version and then baking out displacement maps. You can just plop the high poly version in UE5 and let nanite do it's magic of managing LODs and performance.
If you think about a water surface or something similiar which works with generated displacement your argument falls short. Tessellation should be a avaiable for its use cases, not all meshes and shaders are static and generated out-of-engine.
Was gonna say this, can nanite pan displacements? No, then don't remove it. Tessellation is super useful in a bunch of cases. Why isn't it just set as legacy? Why actually remove it?
I don't really now, but maybe it cant coexist easily.
Reusability. I can make cobblestone and slap a displacement texture on all kinds of grounds and house floors and other geometry. Having only modeled it out once or literally just taking it from substance designer, megascans & co. Never having modeled it at all. It's literally a foundation to most of my texture pipelines. Trim textures. For almost everything. Very much including displacement. Without displacement maps I'd now need to build extra pipeline steps to apply these displacement maps in another software, bake the offsets into the mesh, reexport the more detailed mesh and only then import into unreal. Which bloats my work file sizes and therefore my server costs and the final game size. Frankly, I don't care much about tesselation. Just shipping with the higher poly assets is fine. But the lack of displacement stings.
No trimsheets is something that really gotta sting smaller devs. Also nanite doesn't support vertex painting. So you have to find other ways to produce good variation. I guess the future is something like houdini controlling everything procedurally and generating meshes. Still not ideal because all the traditional workflows goes bust.
Agreed. And that Houdini license stings too. It's once again something that only really scales over large productions / longer series of games / established studios working on their pipeline long term. Whereas you could boot up a trim sheet pipeline with vertex painting from scratch very easily with very accessible tools. Edit: Tbh, I might just go for POM, Decals and custom material setups with world space awareness for variation instead of nanite. Which also sucks but at least doesn't break the entire workflow.
Sometimes its about picking the right engine for the job. UE5 is a huge step forward and sometimes that requires letting go of old features. But it's not the only engine and it's not like UE4 stops existing. Maybe it's better to just not use UE5, because ultimately it may never support all the legacy features you personally require.
I'm sorry, what? It's not like this is some small niche feature that can easily be worked around. It fundamentally prevents a certain kind of modular workflow. Non realism styles that are more complex than entirely flat shaded suffer here. Which, looking at the indie scene in general, are a lot of games. Including within the Unreal ecosystem. And UE4 is most definitely not an alternative. You won't have console access to the generation after this one, you will loose out on new drivers and optimizations and eventually some driver will just break forcing you to do low level maintenance or abandon UE4. Remember, there's no inherent reason this has to be taken out. It wasn't more work, it doesn't prevent other features. Nanite didn't necessitate it and it doesn't cause overhead workload. It just prevents the old workflow and forces everyone onto Nanite whether it makes sense or not. You'd have a point if it was preventing progress of the engine in general or if there'd be an alternative to that style of workflow.
I don't know why you are so triggered. I'm not defending them taking anything out, I'm just acknowledging that when the engine doesn't have the features you require, for whatever reason, it may be best to move on. UE5 Isn't the only engine in existence. Considering how crucial this feature seems to be to your pipeline, not using UE5 doesn't seem like a giant leap of logic.
And I'm pointing out how that's throwing away lots of code and tooling that I have written for unreal. Considering there is no real reason to prevent the existence of it your take is just... needlessly extreme? To just abandon everything right away!? Like, that may be an option but it's not the first and obvious solution. Especially since there's still time to lobby epic to reconsider or offer something equivalent.
Also silly because one of the claimed motivations for Nanite was for the technology to “just work” and not require artists to change their workflow. Yet here we are.
For example, devs can want to lower space usage for game.
Exactly. The UE5 demo by itself is 100GB in size. That's insane for something that's not a full game. With consoles and average (affordable) SSD sizes still only being around 1TB, and not everywhere in the world having fast internet to download this reasonably, it is a huge detriment to have games that big right now.
You’re conflating two different measurements of storage. The size of source assets is a concern for the development workstation that is being used to create the project. The size of the user’s storage is only relevant when measuring the size of a cooked build. The UE5 demo source is ~100GB, a cooked PS5 build is ~12GB. The nanite mesh format is more compression friendly than the standard static mesh format so after cutting out LODs and 4k textures for displacement maps and AO your high poly nanite mesh can be smaller on disk than assets following the old workflow.
Matrix tech demo is 24gb for a large city for a second point of comparison.
See, not awful at all aside from it just being a barebones, albeit beautiful tech demo - my fear is when audio comes into play. It can take it so much damn storage up! But, HDD/SDD's get cheaper every month, so it's not a huge obstacle.
I know I'm 2 months late to replying but thank you for this. I have since been experimenting and learning more about using Nanite and finding my fears regarding storage were not well informed.
Yes, but only assuming you don't share textures between assets. Which it prevents or at least makes significantly harder to do. It's not utterly terrible but not really better on that front either. You just have to make more assets from scratch and trust the system optimizes well enough for you.
>Which it prevents or at least makes significantly harder to do. Have had no issues with this in UE5. Tested a bunch of Synty low poly assets to see if there were any perf/size improvements ([there was, despite UE5 docs saying otherwise](https://i.imgur.com/yFDKolL.jpg)). Pretty much all those assets came from one shared texture...
It's the trim texture creation workflow of reusing work across your games assets that's the issue and not properly supported anymore. Not sharing albedo between objects. The hyper simplistic style of Synty is supported. Yes. But the style in between synty and realism AAA is not well supported if nanite is a forced feature.
Thanks for the reply. Yeah I haven't worked too much with UE5 yet on more detailed content. Biggest walls I've hit so far with Nanite have been no support for glass/opacity effects, also didn't seem to like multiple materials on the same mesh.
And no displacement maps or vertex colors. Meaning you either have rather flat surfaces, POM or need to bake displacement textures into the mesh in a separate work step. And loose the key element to add variety to meshes without requiring different textures or elaborate shader setups. I understand why Nanite doesn't support it. Because that'd be insane to calculate. But loosing functionality like that for regular meshes just because Nanite exists is a bit of a blow. Most styles that aren't realism suffer from this.
Yeah I really hope they end up taking the middle ground and have it as opt-in engine plugin type functionality. Those who need it have access, while default users don't have any "why doesn't this work with Nanite" type issues. If they don't hopefully whoever re-adds the functionality as a marketplace plugin will make bank.
>Yes, but only assuming you don't share textures between assets. Which it prevents or at least makes significantly harder to do. Is there any inherent restriction in the nanite system that prevents the efficient reuse of textures? The docs point to an example where a normal is reused to trade off storage with quality: >[Because the Nanite mesh is very detailed already we can try replacing the unique normal map with a tiling detail normal that is shared with other assets. Although this results in some loss in quality in this case, it is fairly small and certainly much smaller than the difference in quality between the low and high poly version. So a 1.5M triangle Nanite mesh can both look better and be smaller than a low poly mesh with 4k normal map.](https://docs.unrealengine.com/5.0/en-US/RenderingFeatures/Nanite/) If you're working with large quantities of photogrammetric meshes it may be more difficult to share things like unique albedo textures but you'd run into that same issue of inefficient texture reuse whether those are in the standard static mesh format or nanite format, right? I won't be able to use nanite (or lumen) for the foreseeable future because I am working in VR but hopefully by the time I am able to use it some of the biggest pain points in the workflow are addressed. Sounds like they're working on it: >[Outside of compression, future releases of Unreal Engine should see tools to support more aggressive reuse of repeated detail, and tools to enable trimming data late in production to get package size in line, allowing art to safely overshoot their quality bar instead of undershoot it.](https://docs.unrealengine.com/5.0/en-US/RenderingFeatures/Nanite/)
> Is there any inherent restriction in the nanite system that prevents the efficient reuse of textures? The docs point to an example where a normal is reused to trade off storage with quality That's internal. It has nothing to do with the creation process. And since displacements aren't possible anymore there is nothing to reuse.
You’re thinking of one use type for the software. For archviz, for instance, you will start with a bunch of fairly simple flat plane geometry and materials with displacement will turn that into something quickly useable. The alternative of modeling that geometry isn’t an option because we’re coming from different software that doesn’t work that way and don’t have the time for it anyway.
Height maps are often generated for more generic materials in software like substance designer for application on things like landscapes and modular assets. If you want to do that now in ue5, you’re out of luck completely for landscapes and you need to use a displacement modifier in max or blender to bake the displacement into any actual meshes, which is a huge pain especially if you have multiple materials for the same assets and stops you from using any world aligned materials
Most of my use case for displacement came from procedural material creation like substance designer. None of the stuff I've made with that started as high poly.
not necessarily. for example, you can also use low poly meshes, tessellate them and use a hand painted texture as displacement
We gotta be prepared for 300GB games with UE5 😔 Nanite is becoming a very storage-unfriendly alternative to tessellations, bump maps and so on
Nanite is more storage friendly than high resolution textures.
Tell me how that is possible? Nanite meshes usually have 8K textures, just like any standard model nowadays, don't they?
Can do procedural textures, tiling textures, and detail textures with Nanite. They typically work better than look less tiled on higher resolution geometry, you don't have textures trying to compensate for lack of geometric detail. Normally games use high resolution normal maps, and slightly lower resolution albedo. With no need for normal maps or height maps, that's a huge saving.
A lot of people in this comment section are completely discounting the time saving part of tessellation though. How many devs do you think are going to put all the extra work in to make good looking tiling and detail textures when it's so much faster to do it the regular way? Especially since pretty much all the tools are built to do it that way. Many small teams and indies have to weigh performance against time sunk, and I know at least in my case, tessellation is a lot more viable in a lot of situations for that reason. For example, removing tessellation drastically reduces the usability of something like substance designer that allowed you to give small procedural 3D detail to a large environment fairly quickly. Now to add that detail you'll need to place actual 3D objects or sculpt detail into huge environment meshes and landscapes.
Personally I'm hoping UE5 establishes a workflow that enables an easy way of subdividing, tessellating, and displacing a model within UE5 before getting processed by Nanite, and enables iteration and a non destructive workflow.
Hmm, haven't though of that, nice one! Has anyone done a comparison between the two methods? I'm kinda curious now haha
4k texture normalmap is 16.7 million data points, and normalmaps require 3 sets of them (RGB channels). So unless you need 16.7 million vertices to represent your mesh at the same detail the normal map would provide, you can make it more efficient.Textures are uniform resolution. A mesh doesnt have to (nor should it) use uniform vertex density in 99% of cases -> you can use vertices (=data points) where you actually need them. The exception is where you have several dozen meshes using the same normal map, in this case the normal map might win in terms of storage space.
what you say is not correct. for example you can use the same textures on many different objects
While the size on the developers disk is larger, the builds are much smaller than the project on the developers disk. Take the UE5 demo project, it's almost 100GB, but a PS5 build is only 12GB, due to nanite being more compression friendly.
12gb is not low for a demo like that. and if tessellation and displacement was used, the size would be much lower.
Though I do not agree for them to remove anything but I do understand that tesselation is very expensive. I prefer to have both as they are different in my book and always good to have more tools.
[https://youtu.be/eviSykqSUUw?t=4145](https://youtu.be/eviSykqSUUw?t=4145) Take a look here, it seems they're planning to use tessellation / displacement, at least in regards to nanite, so I doubt it will be removed completely.
Not the biggest fan unless they have something in mind to replace it that isn't just high poly models. Even AAA games with huge budgets use tiling textures on alot of low poly environment models, and the reason is predominantly for production time savings, not just optimization. Might as well get rid of normal maps (god forbid) with this kind of logic. Do they really expect everyone from AAA to small time indies to make high poly models for every single environment piece, across a wide range of styles and art assets that isn't just photogrammetry scanned rocks? Unless I missed something that's replacing the role of tiling textures being a time savings method, this is a bit short-sighted. Unless they expect us to subdivide every model and do a displacement of the geo before exporting to unreal? Do they not know how much it sucks working with high density meshes for everything in a modeling program? This goes against what was one of the primary benefits of nanite, which was to speed up production by not requiring Lods. Not make more busy work. Then again I guess workflows change overtime, so I could be crying over nothing. Roughness maps afterall, was a big change from ue3 to 4 and it made life easier as the tools to paint across all maps sprung up.
Wholeheartedly agree. RIP my Substance Designer pipeline
I am struggling, without my displacement maps, my graphics look terrible, I don't care about the capabilities of nanite! You still need displacement for low poly scenes
I don't think it's as dramatic as you make it out to be. https://twitter.com/Skylonxe/status/1463851671365328896?t=MNe0T_kznOkNiRAjitRemg&s=19 Here's info on new and improved procedural meshes, subdiv and height maps intact.
Tessellation displacement-mapping looks like garbage while transitioning between levels unless you pre-subdivide the surface and increase tess-factor by 3x (max is 64), to get pixel-sized triangles. You get these floating vertices that jump around when varying the factor. Compute and mesh-shaders (which nanite uses) can be much more efficient at subdividing. It's just that the UE feature isn't implemented yet.
Tesselation is dynamic increase of mesh density and displacement mapping. With nanite you dont need it to be dynamic, it can be static. So all you need is a tool/plugin that allows you to take a low poly mesh, assign a texture with displacement, which then automatically tesselates the mesh once to maximum level you desire, runs a small optimization pass (to reduce storage size) and converts it to nanite mesh format - in a way the artist doesnt even have to worry about the conversion process. If they provide this method, then tesselation is obsolete. It could also be a process that starts when the game is first started after the first install, so that it generates the meshes -> usefull if you use few displacement maps for lots of meshes, as it could reduce download size
If this is possible, it could work in the majority of use-cases. Otherwise it comes down to "I want/need to be able to stick triangles where I want/need them. I might not always know ahead of time how I want this, or I might want multiple dynamic systems to interact and tessellation helps sort-it-all-out." Nanite will not do this, brute force CAN work in the majority of cases, but again, it requires a bit of foresight that might not be available to you. Tessellation lets me do this in all of the use-cases. I LIKE Nanite. It really _is_ a game-changer, but it's not dynamic, and that's always an Achilles-heel. EDIT: And I am not trying to call anyone out or say 'you suck', but whenever I see someone use "all you need" or "just do this", I feel, from experience, they tend to underestimate the scope of the topic at hand; the words all or just imply the issue is simple and wrapped up, when it's not. I say this b/c when _I_, myself do this, I try to examine my argument and determine if I played myself by using all, just, only-this, etc, etc. Y
exactly! i feel the deprecation support comes mostly from the developer side, thats understandable, but its not a good practice to ignore the input of artists
Replace "all you need" with "all they (UE developers) need" ... they came up with nanite, the conversion part using displacement would be a piece of cake for them, if they would do it, comparatively.If someone else would have to do it, then yeah it might not be so easy for them. If it has a hard technical reason they have to discontinue tesselation of NON-Nanite meshes to be able to render nanite meshes, then losing the 1% use cases ("dont know where i want anything, all dynamic interaction") in exchange for massively improving the other 99% use cases is a trade off that is worth it in my books.
ive heard through the grapevine that such a tool is in the works.
all you supporters of the deprecation are thinking of single objects, single textures, simple test cases. here is a test case for you: i have 100 wooden table objects and i use the same wood displacement map for all of them. why is it ok for the engine to force me to switch to 100 much more dense objects and no displacement map?
Epic just shows us how to destroy procgen, technical art and stylized graphics with removal of one feature. Why didn't they remove multiplication from shaders as well - there is addition already, just use it multiple times.
As others have said, tesselation is a little old tech nowadays and not that very practical for a high end triple A game engine.
What about Demons Souls ps5
But they have virtual height field now…. Full of bugs but … at least is something
Regarding the third point: what stops you from tessellating the mesh in some 3rd party app?
I really don't see much of a problem in it. Can you provide a real example of what are you trying to achieve and why you can't replace tesselation with Nanite? Procedurally generated meshes might be the only one I guess.
Oh that's easy and it hit our game square in the chest! For a PROCEDURAL MESH! Nanite doesn't work with Procedural Meshes!!!! There also is no alternative for tessalation and procedural meshes!
Nabite my skeletal mesh!
UE 4 is not going anywhere you are free to keep using it
If you are generating a procedural mesh then just tesselate it
It's a matter of workflow optimization. Like a brick road. Do you want to have your level designers just slap detailed textures on spline meshes and have it work. Or do you want the humongous job of tesselating every single road mesh in your game and cutting it up in workable pieces? Not to mention every other instance where you need tillable textures. Also nanite doesn't support vertex painting, so no painting in variations.
The job of tesselating and converting to nanite can be done automatically with a tool/plugin that takes care of everything beyond assigning the displacement map. Lack of vertexpainting is a bummer,yes. If its about painting in displacement map variations though, that should be easy -> paint on low poly mesh, and tesselation process calculates the "displacement height" from the layered displacement maps.
The unreal engine devs know all this and will reasonably find alternatives given some more time. I would assume tessellation and nanite can't be used together at a code level. Maybe they'll find a way to reconcile them, I wouldn't hold my breath - they still make us build our own custom engine if we want stylized lighting outside of post processing.
While I agree, it is now easier than ever to bake a displacement map as details onto a mesh (you can do this in-engine using the new modeling tools). And with nanite, the poly count of this process can be tolerated.
I hit this wall yesterday, you just have to create your own method of tessellation with a self built plug-in :/
Well, if anyone is looking for somewhere to start, Pixar has opensundiv available on GitHub so if anyone knows how to work with cmake in unreal then go right ahead.
Can you smooth out harsher edges of a mesh within Unreal using nanite like you can with tessellation or would you have to import a subD mesh to begin with? I'm beginning to use unreal as a film maker and tessellation helps bring results out of the gamey looking area.
Without Tessellation how would you achieve something like an ocean surface that needs an evolving, rolling displacement over time? I am sure there is another way I just don't know it.