I am still wondering why they didn’t just implement a very robust advanced distance based tessellation that works with static meshes that is texture driven rather than Nanite.
Nanite is great but with textures driving displacement like tessellation you have way more flexibility and a easier workflow.
Maybe we will get distanced based Nanite that is driven by textures in the material?
Modelling programs aren’t limited less than unreal engine, modelling programs can do way more but i agree with you here, it’s an uneeded headache with extra time waste
If you want meshes driven by textures and displacement it’s not that much work to setup Houdini to do exactly this and bake out meshes for what it’s worth.
I’ve setup some stuff to do this just to get nice Nanite meshes and it works pretty well.
For me, it’s not just about adding detail so much as dynamically doing so, melding/merging meshes, using WPO, Displacement, etc as critter-skin for cool effects like a busting pustule, etc.
Having direct, math’d/texture driven control over the surface of a mesh(es) allows much to be moved to the GPU and a lot more flexibility as it can be done within materials.
I use the modeling tools in unreal engine to subdivide and displace meshes because that way, the file size is kept very low. Import the mesh as low poly, convert to nanite, use modeling tools to subdivide and displace.
But we need to be able to use tiling textures to save time and make things easier so a distance based nanite might help so you can use very large static meshes. I have a feeling this won’t be possible so we will have to painstakingly build very large static meshes/terrain using smaller meshes.
“Just bake it” definitely isn’t an option for larger games. Material driven displacement is really, really small for disc size. An average nanite mesh might be 10-20mb. You start creating an instance for each of those models placed in game and suddenly you’re looking at hundreds of gigs or more for download and install. A large enough game could easily top a terabyte, uninstallable on consoles and most PCs.
?? I don’t think you understand what an instance is. Game engines are great at this. The entire Valley of Ancients project is kind of an overkill example and the models are only if i remember right like ~6 gigs. A 500k tris asset is less memory than a 4k height map and gives you much more flexibility in use imo
Completely agreed. All “solution” so far are just lazy excuses
What about all the other use cases? Like how the heck I’m supposed to add detail where so far you would simply tile the texture? For example; walls, roads, or big chunks of cliffs, or literally any huge surface with tiled textures, because I’m not going to subdivide all that, are you nuts?!
Don’t “subdivide all that”. Use instances of subdivided geometry.
And I’m supposed to build everything with “modular elements”? It’s the end of nighties mentality. When you are doing actually something serious, you don’t build your levels entirely in the engine, you want to bring a hell lot of unique elements from your 3d software. What the datasmith is for?
Yes? This is how the UE5 demos were made, and how games have been made for the better part of the last 20 years. In general this is what you should be doing in Unreal if only so you can generate more efficient mesh distance fields. Not to mention its required by Lumen for structural geometry.
Tessellation still works fine in UE4, if you’re not going to use Nanite or Lumen you may as well just stick with it until tessellation is supported in UE5.
So, just for the kids in the back (and my validation?).
Instead of making a single model of a metal bridge, say just tie-spans and bolts, with many triangles but oh-so-carefully-crafted to maximize performance, it’s better to just-make-the-bridge.
For example: make a tie-span and a bolt mesh, 2 distinct things, but put them everywhere. Since nanite will efficiently cull unseen clusters, our scenes are no longer limited by the sheer number of overall things we can draw atop on another but instead we’ll always be drawing just-about the number of pixels on the screen; bound by resolution vs brute-force-power of the card.
To that end, today, we make a single, or subdivided mesh in as efficiently a way as possible because we need to stay within a budget of work/power. With nanite we don’t really care that tie-beams or bolts overlap, we’re not concerned with the ‘elegant’ mesh that always has the hidden stuff taken away, etc.
Even better, detail wise, just scaling bolts up and down (for example), smaller-scaled meshes are going to generate smaller-scale (smaller resolution) distance fields, larger scale fields for larger things. Overall, the aggregate is that wherever you need it, the distance field is going to scale to the thing, so lighting will be detailed where it needs to be and large/gross where it can be.
So overall, just make the thing, don’t be sloppy, but you really can ‘assemble’ a thing and not need to be so concerned with the elegant/hyper-efficient lines you can’t cross. Be logical, put rocks where you need it, etc, and nanite will help save us from ourselves by making sure the engine only draws just-about what it needs to.
I don’t even know how to begin with this.
As I said, just stick to UE4 then. It doesn’t sound like you plan to leverage any of UE5s features so why bother?
Epic has stated they want to support material tessellation in the future via Nanite, but no one knows when that will happen. If tessellation is critically important to you then you can use UE4 until then.
Why UE5? The answer is very simple: LUMEN. And no more lightmap baking - and this alone is a reason to ditch UE4.
UE5 works great on my old Gtx 970 with Lumen enabled, and oh man it looks gorgeous!
Lumen is what we have been waiting for about two decades.
But enough of that, back to topic.
I really do hope Epic will add a feature that replaces tessellation entirely, but until they don’t have a full working solution they should not remove it, very simple.
This is what this thread is about… I don’t want to fight with you, but saying, “use nanite instead”, when it actually doesn’t even work on my machine and doesn’t cover all the previous possibilities, or “use UE4 if you don’t like it”, is just wrong.
I’m not alone asking for this feature back.
Lumen requires structural geometry (walls, specifically) be broken up into pieces… aka modular…
This is not the first time this has happened and it won’t be the last.
-Lumen requires structural geometry (walls, specifically) be broken up into pieces… aka modular…
Broken into pieces, DOES NOT MEAN modular.
-This is not the first time this has happened and it won’t be the last.
That’s why we are here disputing.
It’s fundamentally the same premise. You’re just not designing to reuse the pieces.
Well, yes, but that’s the point. We are used anyway to split walls into pieces for lightmap baking. But spliting and reassembling is a completely different story. From working hours to days of difference.