I never said I want virtual geometry support. There are a lot of posts in this very thread letting us know how it isn’t all rosy.
I only said if a rendering pipeline features RTX, then it should also feature mesh shaders because both go hand in hand else you only have a half-assed incomplete implementation. Both RTX and Mesh Shaders are 2019 Tech revealed during the very same Nvidia presentation.
And let’s not pretend in the same way that Unreal Engine 5 relies on TAA to mask all artifacts and imperfections, that you can get a decent framerate in HDRP when enabling RTX without the reliance on DLSS.
EDIT: It goes without saying, that Mesh Shaders are not virtual geometry but closer to the Meshlet implementation from Assassin’s Creed Unity back in 2015: https://advances.realtimerendering.com/s2015/aaltonenhaar_siggraph2015_combined_final_footer_220dpi.pdf
HDRP is already a GPU driven rendering pipeline with heavy reliance on compute shaders that makes use of a tile/clustered shading, hence they might as well go all out and also apply the same approach to meshes by making use of mesh cluster rendering itself.
I can definitely get behind that - as RTX is already a proprietary add-on - but to be honest I think mesh shaders are quite underutilized by games nowadays.
Not only that. It is one of Unity’s greatest blunders “or self-owns” because Epic only revealed “Nanite” as a marketing stunt as the first comment on the Mesh Shaders video would let you know:
It is a joke.
You got handed the ultimate solution on a platter to make HDRP ultra-competitive in front of Nanite very early back in 2019 when the HDRP final spec wasn’t even in place and they could have easily integrated disruptive tech like this. But they chose not to, even though for anyone paying attention it was always common sense that if you are implementing RTX and you have a GPU-driven pipeline, then it is a no brainer to also implement Mesh Shaders right there natively.
If you implement Mesh Shaders, then nobody can pester you about Virtual Geometry while you keep the engine free of that pest that ends up pervading all systems in the rendering pipeline in order to try making something useful out of it.
In fact, there is no reason for RTX to be an HDRP only feature. It should be there for URP along Mesh Shaders too because “they are something external”, not something that you really have to implement deeply into the engine core, but an extra feature for those wishing to rely on pure hardware acceleration as their rendering core.
it’s worth noting RTX isn’t really properly implemented in any engine as far as i know which is why the performance is often rough and scale much smaller. Like it’s kind of insane cyberpunk can trace a whole city and perform very well, but games like Elden Ring can barely raytrace 10 ft in front of the player. And even the Engine for Doom the Dark Ages suffers from BVH issues mega geometry could solve.
Like the NVidia build of UE5 is so far ahead of anything in base UE5 it’s kind of ridiculous (there’s performance issues, but that’s with infinite reflections, something otherwise impossible!).
There’s plenty of non-proprietary stuff nvidia makes thats amazing like Restir that could benefit everything everywhere but almost nothing supports it (except now Htrace which shows why it needs to be more common).
But platform specific stuff for these things is seemingly going to continue to be a thing, like even AMD is getting into it cause they have no ray reconstruction, and nvidia won’t need theirs.
I think what is “common sense” for you is not common sense for the majority of Unity’s users or Unity as a company. Facts are 1) that relatively few Unity users use HDRP (compared to say URP), and 2) for various reasons even fewer use HDRP’s RTX features, 3) like most companies in the industry Unity’s resources are strained these years and we must focus, 4) user feedback suggests the majority wants us to do fewer things better instead of “supporting everything”, and 5) GPU Resident Drawer is currently not ready to exploit Mesh Shaders, more work is needed (in addition to actually adding mesh shaders).
Naturally, this is just a small subset of the things we need to consider when evaluating whether to invest in a particular feature. The actual list of much longer.
I agree that Mesh Shaders would be valueable and I think we should invest in them eventually. But with the above in mind, I hope you can at least sympathize with the view point that investing in Mesh Shaders is probably not how we generate the most value for the majority of our users right now.
Does this mean dynamic meshes receive light only, or contribute to light, too? Because it was stated somewhere else that bvh of dynamic meshes don’t get updated automatically in new system.
The details are not yet fully set in stone, but we want to enable the user to make this decision. For example, dynamic objects may receive + contribute by default, but for performance or other reasons, the user can opt-out of that per object.
For dynamic objects like opening doors you quite obviously want to be able to have this contribute to the indirect light.
that’s good, and would be consistent with how it’s handled in HDRP / RTX at the moment (per mesh, select static, dynamic, or dynamic geometry, which changes the BVH update modes).
It’s probably the same reason a lot of studios don’t even use the hardware RT mode in UE5, which as a gamer is annoying cause I hate SSR with a passion.
I also think the setup is a problem, you don’t have “RT shadows on” you have RT shadows per light, wit the same limitations. The current implementation in most engines feels like duck-taping the features on.
I do wanna say I would GLADLY have RT as an option if it was possible in URP. It’s an easy win for a game with a mobile version to make the PC version stand out more.
I agree that the RTX implementation in Unity feels unfinished, and that’s probably main reason for low adaption.
Things that come to my mind (there is probably much more):
DX12 in Unity still not on par with DX11 from performance
Raytraced shadows can’t have rasterized fallbacks for stuff which is not in the BVH (for a variety of reasons, e.g. hair from the hair package does not provide appropriate geometry)
difficult to set up shaders (e.g. materials workflow in shadergraph with fallbacks, not being able to use certain features in shader graph)
overall performance of raytraced effects, e.g. GI, especially if weighted against the provided fidelity
no state of the art denoiser for AO / GI (e.g. ReSTIR)
Missing a real time Path Tracer
It might be similar with HDRP adaption; HDRP feels unfinished and left behind, so users seeking fidelity in 3D tend to leave to UE.
That being said, I can fully understand priorities with limited resources. Better HDRP and RTX is just wishful thinking.
You’d be dismissing the timeline Unity was pushing RTX all over the place back in 2019 and we made an assumption that they’d keep up to date with all advancements, until they didn’t. Some of us have been hard into HDRP since its very conception keeping up with every single change.
When you talk about resources spreading thin, didn’t HDRP and URP department have their own separate department each that did not cannibalize on one another’s development resources?
Are they both now working on URP exclusively?
I’d say It is common sense for the highly intensive graphics pipeline that barely anybody uses because of said performance requirements, to go all out on graphics features so it it has a place in the market or else what would even be the point of HDRP. The R&D on implementing RTX with Mesh Shaders is much lower than Unity having to create their own Realtime GI and Virtual Texturing solution if the current SSGI implementation in HDRP is anything to go by.
You could give us the thing out there developed and maintained by Nvidia while you work on yours and keep all user discontent calm in the meantime.
Good you mention H-Trace WSGI, it is an asset in HDRP which solves most GI needs as long as you properly set it up from the beginning of the project making sure all of your shaders support its very specific approach of instancing. Problem is it cannot take advantage of any of the aforementioned hardware acceleration features in this thread so you can feel the performance hit. But I still use it. I will use anything as long as I do not have to use Unreal
Part of the reason I posted in this thread was seeing HDRP getting none of the love while URP already has solutions like this for those willing to spend:
I use HDRP for long-term development PC games and URP for short-term development mobile games and I’d say URP is already perfect for any game seeking high runtime performance, so why not allow HDRP to be that pipeline with no concern of performance, only features. Then you optimize from that baseline. Right now HDRP is the pipeline of no concern for performance, but also missing features. A lot of them. It feels like it is starting to get abandoned tbqh.
Goes without saying RTX won’t make or break a game, but it can certainly add a lot of value among the high graphics enthusiast crowd who are always hunting and checking out games based on their RTX implementation. It is just something we throw in there, as a checkbox, after we finish developing our game, carefully developing the game to account for it at every stage of the graphics spec.
So I can perfectly understand in which way it is only nothing but a gigantic a waste of resources.
But that won’t suddenly bury under the rug that the current RTX implementation is dead in the water until the proper adjustments are made in place to the HDRP graphics pipeline foundations (which, mind you, you should also use to make adjustments in URP considering RTX is rendering pipeline agnostic tech).
It is not like some of us got into HDRP thinking “Unity will add RTX!” but rather “HDRP is the graphics pipeline built for features like RTX from the ground up” and all that entices. It was a rendering pipeline for the future, but it is stuck in 2019 or 2020 if we are being generous. You incur UE5 performance cost for none of the graphics features.
Can this realtime GI system pickup bloom from VFX and Mesh Shaders?
With the Unified renderer system being planned, does that mean this system will also work with the HDRP water? (slightly different tint near surface of water/changing color of caustics)
For very bright lights (explosion) can this GI system change the Volumetric Clouds?
I actually wished Unity leaned more into baked lighting workflows (apv is a good start).
I’m not interested in making a Unity game look almost as good as an Unreal Engine game running on an RTX 4080.
I’m interested in Unity games that look like a console game but run on a Nokia flip.
Currently I bake all my lighting in Blender and use a custom shader to apply them in Unity. I wish I could also import blender radiance fields to Unity, but Unity decided to use their own weird standard for Probes that have no scripting API.
The teams being separate was a serious flaw that made the two pipelines too different and as a result unable to share things even on a basic level that they should have easily shared.
Now largely the HDRP team remains, and they’re unifying the two. So URP is largely playing catch up while they clean things up.
I think it’s less that URP is getting more love and more that HDRP can’t really evolve until URP lines up more. Like unifying the RT implementations, hopefully sky and water and such.
Personally I disagree, SSR is a severe limitation to game visuals atm, and no other solution really helps. Even software lumen is still limited by SSR.
There’s so much devs simply don’t do cause SSR makes it look horrible. Making third person games have a lot of artifacts or limiting cinematic scenes cause you can’t have an occluder infront of a large SSR surface.
This comparison only scratches the surface of how bad SSR is even in the best case scenario.
Like all games realistic and otherwise suffer from this problem. Like SSR should be the compromise not the standard. A lot of games just avoid this by making things a lot more matte in general, or avoiding surfaces with clear reflections.
It’s less an issue for GI, but since we’re already there with RT reflections using RTGI just makes sense. IMO these things should be unified in their execution.
Personally i think blenders radience fields are a lot worse than APV but maybe I just haven’t used it enough to not get terrible results lol.
Honestly they probably are, I would just like a bit more editor support for baked probe data. It’s just kind of a globe that you have to hope doesn’t get corrupted. Light probes themselves to me, are the answer to baked global illumination, it’s just that the support for them makes them really hard to use effectively.
I downloaded the carnival demo which uses the nvidia branch of UE, and it’s crazy how important ray reconstruction can be. And it sucks it’s just not an option on unity for all this time even if it’s platform specific.
(ignore the FPS i had two instances of the game running accidentally plus recording lol)
