With nanite, since everything is run through that singular rendering paradigm, the effort to run tessellation, as well as maintain over time is much reduced. As well since it’s part of the stack that runs on the GPU can be run much-quicker vs the previous effort.
Well Nanite has garbage performance, requires blurring that destroys the detail and requiring more expensive VSMs.
This is a somewhat disingenuous/condescending way to frame the issue. I don’t think any reasonable person is questioning that Tessellation had these problems.
The issue is that Nanite ruined the smooth pipeline of 3D modelling > Texturing > Engine by moving the dense geometry from the In-engine stage all the way back to 3D modelling stage, meaning your geometry has to be dense from the start…and if you have an issue with an asset in this way after it’s already in-engine, it means you are going back to the start of that Pipeline rather than solving the issue in-engine (affecting every stage of development in-between and the people who work on those steps). It is extremely counter-productive.
In any case…Dynamic Nanite Tessellation and displacement is back on the forward looking roadmap so I don’t see why this keeps coming up when the feature is already making a Nanite-compatible return.
How so?
Restating what Epic has been stating for some time?
Or is it just-stating something you don’t want to be?
We get all of this (essentially) free, until we make money. Condescension is taking free and demanding something in return.
No one here owes anyone anything else let alone Epic. I could play with this the rest of my life and I’m not bowing down to the altar of anything, but I don’t have to throw a single currency-unit their way either. If I choose to dip my toe in the current of commerce, they want a slice since they helped me get there. Otherwise, given I’m taking what I can get (as are most of use)…it’s not that we don’t have a right to complain or advocate for what we want, but until any of us are (re)writing the fundamental technologies that enable our creative outputs, who are we to demand anything?
I want what I want, but hubris?
How so?
Here, this may help you educate yourself so that you can perform some fruitful self-reflection:
That only works for static environment meshes. This is not the only use case for tessellation.
You have nanite tesselation for static geo, WPO geo, and skinned meshes. What else do you have in mind?
It was added for static meshes initially because we’re still in the process of porting the entirety of the rendering pipeline to the GPU. Static meshes are easier to work with owing to their static-ness.
Skeletal-mesh support for Nanite is now available, and more to come.
Patience, child.
Nanite displacement is similar.
I find it hilarious:
148 posts in this thread; around 90% seem to be from the same people moaning about something that was rightfully removed.
This, while around 95% of the engine is bricked and unusable for 100% of the user base…
@Frenetic
I think you misunderstand how tessellation is supposed to work - because it was completely useless.
But at the same time it really doesn’t matter; With Nanite you are correct: The engine is already doing wetf it wants to your scene tris. It makes absolutely no difference how you split the tris, and you should be able to direct the algorhytm to use more tris in a particular zone instead of another.
The only real problem you will have is the gigantic pile of dudu that the engine has become - and the fact that even on a 4090 (soon to be 5090) you can’t get the engine to render over 20fps at 4k.
And PS:
The fact anyone wants or needs tessellation on skeletal meshes is perhaps the brilliant example of why the engine should have never re-introduced anything called “tessellation” ever again…
I’d have seriously re-labeled it: “use this if stupid or lazy” > and thus would probably have prevented quite a few from just using it since they’d have put some thinking into why it said that…
I think you misunderstand how tessellation is supposed to work - because it was completely useless
Then you haven’t seen games that use it intelligently. It’s absolutely helpful for many effects, that why Epic made a big deal when it came to nanite.
Games that use HW tessellation run faster than games using nanite.
Even if you wanted to optimize a scene with LODs and have a few objects nanite enabled for tessellation support (I’ve seen multiple people suggest this), Nanite’s overhead from simply being enabled in the project is more than properly used tessellation.
Epic took tHW essellation out so they didn’t have to pay their engineers to account for its existence in the engine when new things are introduced.
Just because Nanite is trash does not automatically mean that hardware tesselation was ever a good idea or that it brought any benefit prior to Nanite being a thing.
Epic simply removed it because of the fact that it’s a trash option which gets overused by inexperienced and silly noobs along with some complete lazy excuse of a company (including epic) who tend to make Bad AAA games.
We no longer live in an era where a system can only render 8 faces on a ploygon. As such tessellation (or the ability to change your whole game to add more polygons) hasn’t been needed in anything for over 15 years.
Anyone - and I do mean anyone - with a modicum of brains would already have created models with the specific geometry they require to do the common things you would think of - water, snow, or sand for instance… and the kicker is that they work much better than tessellation ever did (because it wasn’t designed to do that anyway).
Kind of agree with you (minus attitude).
Almost every indie project i joined, had idea man that immediately bought multiple packages from marketplace, made huge open world map (flat with nothing on it), then started adding really unoptimized meshes, landscape texture, day/night cycles and weather. Then had pikachu face when everything ran at 20fps.
It is really hard to hammer in some people that their PC is not infinite rubber balloon that can fit every single thing they want in game. And then on top of it all: “game should run on average steam potato PC”, nowadays its even better, “lets have nanite everywhere”, then week later “we will make it all run perfectly on steam deck”
And yes unreal is more of “investor engine” than “game engine” (full of systems with cool buzzwords, that nobody but investors use). But nanite is not one of those systems, however imo. it is also not good system for games. Gamers do not really care if its nanite or not (if models are nice levels have quality etc), it is devs that care about nanite, because they can be lazy.
Thats another thing I don’t get:
For indy - maybe - but being lazy at a huge studio is just silly;
They waste 4 hours of the day or more screwing around, work minimally, and they also want to not have to work to get the models right?
Anyway, Nanite isn’t going to work fast for at least another 3 years.
Just like the engine was going to be an unstable mess for at least 3, and we are approaching year 4…
Having a mass of geometry all the time is better than where it’s needed? 
It was commonly used on skeletal meshes. That was one of it’s intended uses. It had a lot of legitimate uses and basing anything on the supposed misuse is a ridiculous attitude.
First of, there are 0 legitimate uses.
And secondly. Since it is no longer 1999, yes. It is better to just have more geometry/tris where the scene requires than to mess with subdivisions which is wholly unreliable.
However, I am really curious about what you think legitimate uses on a skeletal mesh would be…
This is the problem.
These new tools made the asset pipeline easy enough for non-experts to get into UE. Those non-experts then don’t have the domain knowledge to make everything else work.
Do you mean like the workview of animating on a subD cage and then using a displacement map+subD to get final pixel detail without animators having to deal with a super unresponsive mesh?