@Mr_Tea_Rexx
Thank you for an insightful alternative. Fascinating, it does give a displacement-like effect beyond that of a typical normal map. While true displacement found in UE4 has more mesh modifying ability, this emulation could be very useful. I very much appreciate you taking the time to forward that to us.
I also have to ask, did you have one like that for UE4-Tessellation’s edge smoothing?
As the original trolling was removed, those curious may be able to see responses in the edit history, however this post itself is no longer necessary.
Much like tessellation.
Are you going to keep ‘talking’ about tessellation for Skeletal Meshes, which are the 0.01% of tessellation uses? I think the attetion of the post is totally missed now, and no one (Epic-related, I mean) will read this (now).
They don’t generate any real revenue for Epic Games. They are pretty much only used by people making waifus, along with other degenerate things and mods for other games. All of which rarely generate even a penny for EG.
Again, if people want to continue using tessellation, stick with UE4. You had several years worth of heads up that it was going away with UE5.
A few thousand USD here and there is absolute chump change for EG. Literally, pennies in the couch. 4.27 is going to continue being supported for plenty of time to come, so people can stick with that if they need it.
Yes we did, for almost a year ahead of release. It was also highly evident when watching the original tech demo presentations.
Again, we had roughly 1.5-2 years of warning. It had been mentioned plenty of times that it was going to be depricated in the future. Tessellation only works on PC anyways and is extremely dated tech. We are far beyond the days of needing to limit a hero asset to 10k polys, where any form of tessellation would come into play.
Simply put: Make higher poly assets. The world isn’t going to implode if you have to import a 150k poly waifu.
The only real issue with the loss of tessellation is with landscapes that use displacement effects, but they seem to be working on swapping it all to a nanite solution soon.
Yeah I’ve brought that up already, but it comes with a large set of pros and cons. If they streamlined it more, it can definitely do the job. Combine that with nanite rendering and it would eventually be a full win.
We aren’t talking about lumen. But on 5.1, you can already play around with WPO materials and alpha masked materials on nanite meshes, so there’s room for all the various systems to grow. Though I imagine they will have a secondary nanite branch for things like animated WPO materials due to the large costs on the system each frame. It will probably need a lot of shortcuts and optimizations, but I’m positive they want it to eventually handle all foliage rendering(no more max grass/tree draw distances).
It’s probably easier to leave naniete out of wpo stuff.
The way nanite pretends to want to work is to modify your geometry on the run based on an analytical process.
The way WPO needs to work, the geometry has to be exact all the time.
Particulalry when using more complex things like vertex-to-texture driven animations.
If you mess with the geometry cache, or the index count, you throw everything off.
Either way, tessellation is going to stay gone.
Now, I don’t trust them one bit as they keep producing horrible work at best, but I could see some sort of analytical re-meshing happen in engine in some sort of a mesh parser…
Maybe as a part of the geometry tools.
Not at runtine.
Again, theres no need for any such function.
Umm… No… This has everything to do with nanite… You use higher poly meshes and then use WPO to do whatever you need to do, much like tessellation creating highly inefficient geometry to then be displaced. Only nanite handles high poly counts much more efficiently…
Not really… Still mostly the same workflow.
So it might be a regression for some obscure little indie game techniques on assets with like 2000 polys? They can stick to UE4 then if they are worried. Not like they’d really need nanite, VSMs and lumen anyways.
Exactly. In an ideal world, everyone would be pleased, but this is one case where the bandaid needed to just be ripped off for good. But I’ll leave it at that because I can see you’re just looking to argue with everyone anyways.
I don’t think you fully understand how world position offset can be used.
Have a look at the content examples, under PivotPainter.
Your idea that somehow the epic team can design a working system that can replicate that while modifying the geometry of the item - even if done by precomputation - is laughable.
And it is so not because of the objective, mind you.
It is laughable because the epic team can’t do much of anything right. Let alone properly make a system they design work right. They depend on outside help - so much so they hire outside help to do their job for them.
Can someone make a system as you suggest? Probably.
But no one is likely to as it offers 0 benefit when it comes to the final product.
This isn’t 1990 where you can only have around 3k tris on screen.
Most systems even a 1060 support around 3million tris before going under.
The budjet is high enough that you can probably keep that one LOD0 tree asset with 15k tris and a super nice custom animation without even eating a millisecond of render time.
In other words:
Unless there is a clear benefit, why would anyone work on it?
I did trial this for skeletal meshes, it does not actually function well in a moving scenario for a skeletal mesh. The parallax is unviewable and thus serves no advantage over a normal map, so it never serves the mesh modification feature that Tessellation and Displacement provided.
It likely is more functional on a terrain or background static prop, where parallax has more relevant viewability.
Use a finely divided mesh instead of tessellation. I think there was an opinion that Nanite would optimize it that way, but Nanite does not seem to support WPO. If neither Nanite nor tessellation can be used when creating something like ocean waves, what is the right thing to do?
Not knowingly use Beta technology without considering the fact it is Beta at best?
Aside from that, surely a system to exclude the rendering of meshes which require WPO is already in place.
Its sort of unthinkable that just by enabling a beta feature you end up loosing the ability to manipulate the verts.
It implies that any project using the same option won’t be able to have animated foliage, or support SpeedTree.
So either there already is a way to use both, or a way will eventually be made avaliable when the item is sligtly less “beta”.
Either way it doesn’t have much to do with tessellation itself.
Reviewing this topic in multiple discussions it becomes apparent there is a user sentiment sometimes that UE5 is so powerful it just made tessellation/displacement obsolete. But really Epic only said Nanite deprecated the mesh deformation part of Tessellation/Displacement, it never said it replaced the material animation part of Tessellation/Displacement. Because of this, other users who used this latter functionality in UE4 ask for it back in UE5.
But after testing the non-removed WPO, POM, and Bump Offset alternatives in UE5, it really appears more and more that UE5 wouldn’t be powerful enough to incorporate the more compute-heavy Tessellation and Displacement, with all their animatable material features, in all elements of its paradigm. So any mesh-altering overlap with Nanite would have made it an expedient reason to deprecate them.