Frenetic Pony
Veteran
Lot of potential differences, but Epic hasn't said what it's doing. So whatever difference there is, is generally speculation right now.
Direct3D Mesh Shaders
- Thread starter DmitryKo
- Start date
Lot of potential differences, but Epic hasn't said what it's doing. So whatever difference there is, is generally speculation right now.
Really depends on how you have coded the LoD and loading.
There should be nothing that prevents you to have meshlet based Lod, which starts from different 'static' LoDs or something different like having SDF and evaluate it to objects during runtime.
Last edited:
... until you realize your ideas break RT support
RT does sound like it always needs special consideration at the moment.... until you realize your ideas break RT support
BTW, how bad is custom intersections at the moment?
Perhaps one can RT the SDF directly.
Then you have LOD anymore. LOD means to have multiple levels of detail. Your proposal may boil down to using just one switch of two different methods, where RT HW works down til the 'coarse' meshlets, then doing custom solutions to refine detail further.BTW, how bad is custom intersections at the moment?
Perhaps one can RT the SDF directly.
This has two problems: 1. Missing a hierarchy of detail levels, how do you reduce detail for the fixed meshlet representation? 2. Switching between different methods of intersecting geometry within a ray adds too much divergence to be efficient.
So there are limitations, and those limits force you to make bad compromises and only partial solutions.
I'm considering such options at the moment, but seems better to wait for more flexibility... :/
... until you realize your ideas break RT support
It's possible to evaluate the TLAS-leaf analytically, if you don't have or like triangles. I wonder when NURBS are (finally) coming back ... Mr. Gouraud's ideas are out of favor, aren't they?
I guess you'd had a hard time convincing artists to work with NURBS. Whenever this topic comes up, everybody seems to hate them. For good reasons, i think:
They can only model human made stuff efficiently. Cars, guns, architecture. Not good for natural stuff like terrain or foliage. Subdiv modeling is a better compromise from the artists view, and less an 'engineering task' while working.
They can turn straight lines into curves, but they can't add topological detail, only displacement. Also, reducing detail of the control mesh is notoriously difficult to automate.
I don't think they'll come into games. Maybe for some military / SciFi shooter setting, but it's likely not worth to develop a complicated realtime NURBS engine just for that?
I also don't believe in realtime subdiv either anymore, although with mesh shaders the recursion problem could be solved efficiently now i guess.
I believe in 'import any crap at high detail, and convert it into whatever engine specific optimized geometry we need', though this misses the easy compression options of parametric surfaces.
Epic is on good track with exactly that promise. But while you no longer need to make manual LODs or bake normals, you now will spend even more time with generating very high detail in the first place. Does not really reduce costs i think.
What i want is to generate high detail mostly procedurally in the engine editor, not in external tools breaking a nondestructive workflow and being unable to shape out things in relation to the game world.
So i'm currently working on this, as the volumetric geometry processing tools i made to generate GI surfel hierarchy easily support things like CSG, geometry blending, or particle based modeling. I hope it's worth the extra time, but looks promising so far.
Output is quad mesh like from the remesher in ZBrush for example. That's an interesting geometry format because it supports seamless texturing and easy subdivision if needed, and instancing / blending of texture quads should help with compression.
You only need to prove them wrong.
I believe that, if we persue parameterizable surface representations - in the long term - we will gravitate towards hybrids (very great paper!). You should not think as a purist, that everything has to be made from one thing alone. Instead there probably will be layers of different expressions, suitable for each level of detail. Say vector displacements on top of these hybrids, or procedural layers (basically all kinds of free analytic formulas). Parameterization is, AFAICS, the only way out of the data-explosion and towards massive scalability (the gap between low end and high end is growing).
Frenetic Pony
Veteran
You only need to prove them wrong.
I believe that, if we persue parameterizable surface representations - in the long term - we will gravitate towards hybrids (very great paper!). You should not think as a purist, that everything has to be made from one thing alone. Instead there probably will be layers of different expressions, suitable for each level of detail. Say vector displacements on top of these hybrids, or procedural layers (basically all kinds of free analytic formulas). Parameterization is, AFAICS, the only way out of the data-explosion and towards massive scalability (the gap between low end and high end is growing).
Sounds complicated as hell and unweildy. Besides there's only 2 representations that matter. Where a solid continuous surface is likely to be wider than the sampled pixel (thus the sampled frustum) or smaller. First just needs some compact contiguous representation, SDFs are great here because they can just be mipmapped and that's cool. Second representation might be pre-computed statistical mapping to a volumetric representation of sub pixel geometry. Then you can do whatever with that, raymarch and gather, raymarch and use russian roullete for hit, etc.
The question mostly becomes that of memory representation and compaction. But displacement and texture maps still seem popular for artists and general workflow, and since you can reference the same material for that again and again that's one way to do memory compaction. Maybe map all a models curvature that can be stored in 2d and bake all that into displacement maps, leaving the base model lower entropy while having virtually lossless compression.
Things won't evolve towards simplicity. A 1.6 million line engine is complicated as hell² and very unweildy. To me that's not an argument. The focus starts to shift towards reliability and consistency, and not speed and hacks upon hacks upon hacks (preferable the garbage sampling types). Angelo observes, that we piled up so much approximations on top of another, we lost the ability to understand where in regards to some "optimality" we're standing. Look at what became of simple curved surface definitions: normal mapping, tangent space. It's so wrong and complicated and unweildy to get precise results, there's a severe lack of control. It's not clear, what happens when you skin a triangulated mesh with an semi-implicit tangent space. And all the linearities in the operations aren't helping either. The loss of correctness/controlability is fairly severe here.
I don't understand that, can you explain? To me analytical methods within the pixel's cone do matter.
I'm not a fan of point-sampling, signal quantization, piecewise linearity or brute force.
Right, that's what going to offer scalability, and implicit continous LODability. Regular displacement mapping won't cut it though IMO, should be vector based. Sculpting is picking up these ideas/features, and they are the information source. Why throw it all down the discretization drain? In one way or another I think this is what Nanite is doing. From the looks, they should have a parametric surface representation to produce their continous LOD + this and that on top.
Ok, i take it back. Ofc. nurbs can do plant branches and leafs, flowers etc. well.You only need to prove them wrong.
Interesting paper. Personally i lack experience with nurbs modeling or CAD in general. Tried it using Rhino, but somehow found it too hard to grasp.
For my own modeling tools i started with bezier patches, but switched to catmull clark later. For characters that's just more convenient and freedom. For cars nurbs would do better i guess.
Now, my argument is parametric surfaces are fine to increase detail, but they can't reduce it below the control mesh. But ofc. we can just switch to usual mesh models and reduce them for this purpose.
With procedural generation in mind, any surface representation sucks. It lacks a definition of volume, which is likely what we simulate, and the surface is only a result of this process.
Surface is also hard to edit because adjacency is complicated to manage, filtering it is hard because edge / patch layout is no longer ideal after changing the surface, and computers have a hard time optimizing this because missing understanding of shapes at all frequencies.
That's where particles make sense. Easy to simulate, then extract local curvature to get detailed surface. Easy to change - just repeat the surface meshing process.
It's useful because CSG or blending becomes easy, which is very hard using surface representation alone. Quality is restricted ofc., but can be increased using higher resolutions.
But i'm not a fan of using SDF at runtime. Static, a lot of memory, and brute force. Although it's attractive to have volumetric shells on the surface, e.g. to add diffuse detail we see in the woods. Cases where displacement mapping won't suffice.
Maybe it can help, but wouldn't this offload compression work to the artist, who then has to care about good parametrizations?
Thinking of nurbs, the engineering workflow really breaks the desired freedom and creativity. Though if modeling tools are good and give results faster, they might be fine with it. (I'm not up to date with current tools here)
I would not be optimistic to make good nurbs parameterizations automatically. Quad remeshing is already difficult but nurbs seems too hard. Maybe if we have a format which allows less perfect definitions than something like nurbs.
I heard ue5 is utilizing the primitive shader on ps5 to accelerate the original compute pass of nanite. I would assume primitive shader is the backend of the mesh shader on rdna2?
Nope. Primitive Shaders are from before RDNA2 architecture.
I mean sure rdna1 has the primitive shaders and that’s how metal3 implements it’s mesh shader. I’m using rdna2 here as the reference of the ps5/Xbox series machines
I’m not sure it is. I guess in many ways it’s so similar that it may represent a large fraction of a mesh shader, but it may not be; It may leverage the same hardware to perform the calculation but outside of that I don’t think there’s any guarantee. The mesh shader was developed with vendors to give developers control over replacing the front end of the 3D pipeline. On the other hand, primitive shaders are an AMD only development and I’m not even sure if there is an explicit api to develop using primitive shaders or if AMD just compiles into primitive shaders. The latter I know happens, I haven’t seen any documentation on the prior.
yes.
Ok, I’ve found the source of this piece of info. It came directly from Kris Brian, which goes
“On PlayStation 5 we use primitive shaders for that path which is considerably faster than using the old pipeline we had before with vertex shaders.”
I agree mesh shader is not exactly the same thing as the primitive shader. I also never find out a single documentation on how to write primitive shader on pc’s rdna cards.
However, with that being said, PS5 is an individual platform, and they would definitely develop their own graphics interface with AMD.
Apple’s latest metal3 api supports mesh shader, and the pc requirement is 5000 series gpus. Xbox series consoles, from my understanding, should have its gpu super similar to PS5’s, but it also has the mesh shader. Anyway, if this is really the case, we should see more coming on future GDC talks
Similar threads
