![]() I can see where this is coming from - Tessellation was never efficient in UE4 and it probably conflicts with nanite. What about Skeletal Meshes (unsupported by Nanite) ? in practice I don’t know how often Tessellation is used for characters but they seem like a really good match.Īnd for shader effects that make use of displacement now we’ll have to do all of them in WPO, meaning we will forcefully need a dense enough base mesh to achieve anything. unless the new water plane rendering can be used outside of their water system I’ll assume the solution for Landscapes will be the new virtual heightfield, but is that enough for closeup detail?įor Water rendering I guess this means relying on actual dense meshes. What about Landscapes? people please don’t just say “make a mesh to use with Nanite” - just think it through. Nanite for such usage seems to rely on fast SSDs (we know is it was showcased on PS5 which is ~8GB/s), but is the adoption on other platforms there yet?įor a Megascans-UE4 workflow this means relying on the highpoly mesh entirely (very questionable), or having control by manually subdividing+displacing the lowpoly mesh with the displacement map and re-exporting (pretty horrible workflow IMO) multipurpose engines like Unreal should be about choices. In general I’m not a fan of getting the choice removed. I think it’s fair to be prudent about replacing the existing tech with Nanite when the rest of the supporting tech isn’t built for what it implies There’s Source Control bandwidth and disk usage. There’s Source Control upload/download speed. Most other 3D softwares can’t reasonably handle opening/saving/viewporting million-triangle meshes. There’s shader effects (snow buildup, footsteps and trails, etc).Īnd also think outside Unreal. There’s new in-engine mesh modelling/editing tools. There’s mesh destruction/slicing systems (good luck keeping those in memory). ![]() You still need to save the mesh file to disk from within the editor. Think of the other implications, everything needs to be 100+ times faster. ![]() Just how good can they come up with better compression and optimizations? is the new Zen loader really 100+ times faster? ![]() LOD0 is 706 kb at 16302 tris, while the Highpoly source is 115 mb at 1.999 million tris. I took a random Megascans mesh (rock_assembly_tazj1) to compare disk size of FBXs. In fact the game could even just pack the optimized (by the engine) version.Īs things stand, not only is the engine NOT capable of handling it, but things like floating point precision would cripple a mesh dense enough to require it. I’m saying that IF the engine is finally capable of handling it, then it should make little to no difference how dense the mesh you put in engine is. You can reduce that a lot via both dumping floating point precision as the engine already does, and compression. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |