I am not sure if anyone mentioned this but this video can serve as a tutorial on how to use 2 different approaches that replace the need for Tasselation in Landscapes: Unreal Engine 5 - Footprints In the Sand (Landscape Displacement) - YouTube
Theres never been a “need” for tessellation in landacapes.
Being lazy and using the unreal landscape tool is exactly that - being lazy.
Anyone working a professional project wouldn’t care about it, or even use the landacape system over the billion issues using it poses…
I’d really like to be able to agree with you, but for that you need to answer me two questions:
-
What am I supposed to use on skeletal meshes? in UE4 tesselation worked great on skeletal meshes. Nanite doesn’t support skeletal meshes.
-
What am I supposed to use on procedurally generated geometry? In UE4 I used the procedural mesh component or runtime mesh component, and then add tesselation, and that worked great. Nanite geometry can’t be created at runtime.
Reading through this thread, I am simply walking away learning one thing:
Tessellation has use-cases. Just because you don’t utilize them or can comprehend fringe approaches, doesn’t give you some authority to chime in and tell everyone off, flame about Epic being evil, etc. That’s toxicity with precision, and it shows.
Keeping in tessellation would have been a better solution, for those of us in the industry that have projects with large amounts of assets that use tessellation for various effects. For example, a client project with lots and lots of cloth specific scenes, with custom materials linked to utilizing tessellation for a finger-on-the-pulse quality control via MPCs at runtime in the HUD. That whole can of worms has to be tackled a different way now.
Heads in the industry have always gone against the grain and achieved effects by doing something someone else will talk crap on. That’s how new techniques are born and potentially become “standard” approaches. To sit in this thread and bark at others, seems to shine light on the idea that one is trapped on rails and isn’t capable of thinking outside the box. How lame and bullyish.
At any rate, this dust will eventually settle concerning tessellation and the new way of doing things. Hopefully we’ll see something with a few nods and checkboxes, but that seems unlikely.
2 Likes
Reading through this thread, I’m walking away learning that other “developers” on here are 100% […]. Particularly if they believe that the person writing continuous streams of stupidity on here isn’t just the same trolling idiot registering new accounts and attacking the same people…
1 Like
My .02: I’m trying to put together a simulation for ocean, and the Water plugin, so far, ain’t cuttin’ it. The Fluid Flux plugin looks great, but they’re limited to a 1024x1024 static mesh that gets displaced by fluid height. From the author of the Flux plugin:
“The geometry of fluid is rendered using a static mesh plane displaced by fluid height. The system uses a huge plane (1024×1024) for rendering the water surface without any dynamic tessellation. This method has a lot of quality flaws. Try to avoid using huge simulation resolution because you will run out of memory very fast, 1024×1024 seems like a good compromise for now.”
Which leads me to wonder if Tessellation would really improve the situation: would dynamic tessellation not take up extra memory? If so, that’s an iron-clad reason for keeping it in the framework.
Maybe they have something amazing in store for oceans, including storms, large wave geometries, foam, wind interaction, etc. But, if you try to do too much, you’re taking the agency from the developers and enforcing a singular aesthetic to the work. Realism is certainly a good standard, but what if that’s not the vision of the developer?
I think the answer is to give the developers all the tools they need to create expansive games / experiences, provide as much heavy lifting as you can (as Unreal), and let the developers take what they want to build upon.
5.2 added displacement for Nanite.
It would, and it would cost even more because theres the tris rendering on top of it.
Realistically it doesn’t change a single thing if they keep or remove the tessellation when you build your assets properly.
The only somewhat valid point is that you can’t rely on other peoples work without it, wereas with tessellation you could modify the mesh at runtime without having to use an external dcc or geometry tools.
For fluids that are performant you can try fluid ninja. Not sure its factually better thoug. Perfoemance of fluid is expensive…
I used a HISM with a bunch of instances of a single 10x10 mesh. I didn’t notice any seams or quality issues, and the whole thing is scalable. As long as they use the same WPO maths, they should all work together w/o seams.
I have spent numerous hours trying to identify the cause of this drastic drop in performance, but unfortunately, I have been unable to find a solution. It seems that the integration of Nanite and Lumin into my game has somehow impacted its rendering capabilities adversely.
I have thoroughly reviewed my code, tweaked various settings, and experimented with different approaches, but none of them have yielded any significant improvements. It is frustrating to witness the game’s performance plummet from a smooth 160 FPS to a rather sluggish 60 FPS.
In order to address this issue, I have consulted with fellow developers, scoured through forums, and even reached out to the technical support of Nanite and Lumin. Sadly, their insights and suggestions have not been fruitful either. It appears that this drop in performance may be an inherent limitation when utilizing these cutting-edge technologies.
Im not quite sure how or why you’d share this within this topic since its got nothing to do with tesselation really.
However it does have everything to do with the current state of the engine, off topic as that may be.
You see, over the years the epic team has made it clear " we don’t care about performance " is their message.
Lately, it’s also become " we don’t care how things look at runtime " - with lumen and all, but lets still give them the benefit of doubt on that.
Afterall the change is rather raw/alpha still, with just 1 year of people testing it for them free of charge and all (Curiously though, PysX/Nvidia noticed this trend around the time of ray tracing’s debut, and started releasing their own fixed up versions of the engine… Jee I wonder why?).
An adbridged/summarized story of the past 4 years of forum topics on the subject:
The epic team has made it very clear in the past.
The engine is to only render 800x600 at decent speeds. If you do anythinng else its you doing it wrong, not the engine.
So nvidia answered that with upsampling algorythms and then epic was like “see? Its you not us”.
Nevermind the fact these didn’t even exist back when Kite was released. That’s pointless detail! “The engine works, and its always been the best™”.
I’d like to point out the fact that a broken clock also works at least twice a day. The engine has become only slightly better than this…
Anyway, there is absolutely nothing cutting edge about the engine or the new additions. Its a dull edge. As dull as a spherical rock really.
The cutting edge resides in the baseline techniques which epic is still trying to implement into their engine, and the papers behind them.
Some - like voxel based raytracing - are also copywrite protected, so they can’t necessarily steal them like they often do for things in Fortnite (which suprisingly people don’t complain more about / sue epic for).
With that in mind,
The performance cut over the past 4 years has been devastating.
Each engine release since 4.18 or so has seen an often brisk drop on overall FPS/MS perfoemance.
.25 was a net 20% frame loss compared to .24.
There were constant complaints about this across the forums. All questions about it unanswered, ignored, censored, deleted. If you (or anyone) still believes that epic and its employees arent aware of it you are dreaming.
Scolling down to .27, they made performance even worse. But since by then the 4090 was out their excuse was “hey, your hardware is out of date stfu”.
.26/.27 is right around the start of covid/ray tracing mainstream and the pascal driver update allowing older gfx to render ray traced btw. To give some context over the engine version’s dating.
So, their modus operandi is:
Develop something that doesnt work.
Blame the customer for doing things wrong.
Wait for someone else to fix the problem.
In the case of Lumen/etc that someone else is probably going to be the gen after the current next gen videocard.
For posterity, current gen is 4090.
Using nanite fixed my issue for my rail tracks
2 Likes
Tessellation should have stayed in. Even just for visual quality setting for players with weaker gpu’s. I’d use it to generate mesh from shader, it would be easy, but if I’m not mistaken, now I can only spawn mesh.
It appears you were always mistaken if you thought utilizing tessellation would do anything for “weaker GPUs”. Old GPUs take time to render triangles. You want to randomly add more triangles.
Generating geometry from a material shader is still possible, if you utilize the correct tools for the job. The tessellation option was never the right tool, and it never generated anything.