So, Nanite

this technique seems to work only when using raytracing but can greatly reduce memory consumption(for high lod meshes) - not nanite like ofc but also interesting achievement and also might be interesting for unity devs who work on nanite like tech(hopefully):

also pdf : Tessellation-Free Displacement Mapping for Ray Tracing (telecom-paristech.fr)

 

Unless every light source and occluder in the scene is static, this is not exactly viable for realtime applications.

 

agree

 

The gist of it is basically Parallax occlusion mapping applied to raytracing, before reading the paper, I did a bet, and that's exactly what they are doing: Compute height minmax in MIP for fast tracing (which translate into box primitive for the raytrace shader), compute box extension of the supporting mesh, trace the raytrace by retrieving teh box, extra shenanigan to have teh final result like a smooth mesh (the special sauce). That's clever.

Now will it replace nanite (i'm aware nobody asked)? Well nanite is rather complete, general and integrated, it handle occlusion, LOD, material decoupling and final rendering. Also so far rasterization is still faster than raytracing, might be complementary but not for game, IMHO, for a while (ray budget don't allow it). Also Nanite manage overhang details, while this can't, it's staight up extrusion from a surface.

 

That technique seems more about bringing POM to raytracing, and seems more suited for accelerating sculpting software and path tracers. Not a good fit for games, since rasterization is still way faster than raytracing for primary rendering.

 

Yeah it's basically just an accelerated renderman idea.

 

Cool, Nanite... and what ll do with it?

 

Give us a little write up

 

This is not Nanite, it is inside Unity, being developed by Chris Kahler

https://www.youtube.com/user/KahlerChristian/videos

 

Ok, but...and?

 

The tool made by Chris Kahler seems very interesting.

I want it!

 

I don't remember if I posted this here already, but I will cross post again, for a reference

https://forum.unity.com/threads/nano-tech-something-similar-to-unreal-nanite.1199371/

Reference thread is about Unity ninite-like tech, discussed earlier in this thread.

 

So Nanite is doing dynamic LODDing and not using imposters (2D sprites of distant objects) but how does it work?

Surely it can't use the CPU as the CPU/GPU bottleneck would get in the way of moving that amount of meshes to/from the CPU/GPU. Therefore it must be pre-calculated and loaded onto the GPU or dynamically changing the LOD on the GPU.

I'm guessing that it's probably using DX12 Shader Meshes technology to pull this off at the scales it does.

If my guesses are correct then CPU bound DOTS can't do this.

Maybe a GPU enabled DOTS could and is Unity even considering GPU DOTS?

Are there any in depth technical analysis of Nanite that will give us a deeper understanding of how it works?

 

It likely performs calculations that determine how much of the mesh is visible on the GPU and then determines surface coarseness to simplify geometry based on how much detail would actually be visible. It would have to do this on the fly due to the way the system inherently functions.

 

There's a lot of documentation. The last linked talk is an in-depth Siggraph presentation.

https://docs.unrealengine.com/5.0/en-US/nanite-virtualized-geometry-in-unreal-engine/
https://dev.epicgames.com/community...entials/vK2/introduction-to-nanite-essentials

 

Yeah nanite is cracked open by the creator, there is nothing to guess, except how to do what it doesn't yet (like foliage, etc ...)

 

It does not use dx12 mesh shaders, just regular compute. That's why it works on such old hardware and not just RTX2xxx and up.

 

So it sounds like the largest limit to Nanite could be GPU speed, memory size and speed.

Is it a technology that only works well on high end GPUs?

 

They said Maxwell and up, Maxwell is not high end.

 

I'd like to know how it will perform on actual lower end of Maxwell's GPU. Like GTX 750 Ti

 

My guess is "no" considering that card is over eight years old.

 

Somewhere in the documentation I also read that an SSD for the runtime is recommended for Nanite. For older PCs, Devices with slow storage or for someone like me who still has a large part of the games on HDD (due to lack of space on my SSD) this could have an impact on performance.

 

Apparently they run just fine on HDD because the virtualization lessen the load of data, which is how it get to these level of details. Virtualization is specifically designed to reduce load.

The thing is which part of nanite, you are talking about, it's actually a collection of technique working together:
- cpu Hi Z occlusion
- material un correlated with geometry
- mesh virtualization
- micro triangle software rasterizer

The reason it's costly on gpu is mostly features set and overhead (compute base), you need a powerful gpu for the overhead to be worth it.

I see no mesh virtualization in fortnite on switch, despite them shifting to unreal 5 for chapiter 3 (and perf are kinda worse).

It's all in the talk Brian Keris did.

 

Nanite's tech is super interesting and has some very pretty results; I've been playing around with it a bit and lining up all kinds of rock formations.

Personally, the types of games and projects I want to make in my spare time (which tend to be more visually abstract and obscure than high-end realism) don't seem to be part of the intended usage. Will keep an eye on it though!

(Edit, I bolded, italic'd and underlined 'Personally' before I get attacked by a dozen people )

 

It automatically handles LODs, occlusion culling, and batches draw calls for the same material. All of these benefits pretty much all visual styles, including low poly, as demonstrated by @Ryiah https://forum.unity.com/threads/no-unreal-5-thread.1265198/page-2#post-8039651

So writing it down as a high end realism thing only is a bit hasty.

 

Yeah, obviously, we all know that the proper way to handle LOD is to cover our eyes and ears and go "LALALALA LOD DOESN'T EXIST, EVERYONE THAT NEEDS LOD IS DOING IT WRONG (but please give us money for Pixyz)" and if someone else solves it, immediately misrepresent and diminish what it does.

 

When I can see it handle games that are 2D or look like Katamari then ill be interested.

Im happy to be proven wrong!

 

I have said this a billion times but there are better ways to solve LOD issues than to rewrite an entire renderer.

 

Online benchmarks of the Matrix demo on even high end gaming rigs are only getting 30-60 fps.

Modern gamers are after at least double that today and will probably want double that again in a few years (expected development time of a new big game 12-24 months).

Is this a case of tomorrows gaming technology today, or we just don't have the hardware to run it today?

 

This idea of "modern gamers" represents an absolutely tiny but incredibly vocal minority. Most people who buy and play games don't even notice if their games are running at non-native resolutions being upscaled to 1080p or 4K and will only notice framerate issues if they're dramatically inconsistent.

On top of that, this is running at 4K when 4K displays are still only somewhat common and only in televisions. On desktop, the only place where you'll find high end graphics cards, less than 2.5% of people are running 4K.

 

It seems pretty usable today to me: https://forum.unity.com/threads/no-unreal-5-thread.1265198/page-2#post-8039651

But again, as I've said previously, I don't think this is a feature that Unity should chase after. A proper fully automatic HLOD solution would be very beneficial for most games and should be the route they take.

Plus HLOD and auto lod generation are much more well research and documented by the graphics community, so it's more feasible that Unity can produce a decent solution, as opposed to something more bleeding edge which probably is beyond their reach.

 

HLOD is in the development track if their recent Pulse survey is anything to go by.

 

I wish I could believe that means anything.

 

Well, which are those?
The alternatives so far all are workarounds in a way. The Nanite renderer makes sure the Level-of-detail is actually exactly optimal. Higher detail (in data) would not be visible and less detail would be visible.
What other LOD tech can achieve both of that?

The Matrix demo was made to impress. Especially in videos and mass media. Obviously it will push the hardware to it's limit and we'll have to wait 2-3 years for that to become the norm at 120 FPS with medium hardware.
Similar as with Unity's "Enemies" demo (which has a quality level probably more likely found in interactive games 4-6 years away).

 

It is not optimal unless you want to, again, completely rewrite the entire renderer. It was even brought up before, but automatic hierarchical level of detail is a fine solution. Not only is it a fine solution, but there are multiple improvements that can be made to it without rewriting the whole renderer.

This is using a nuclear bomb for a job where you only need a hammer.

 

Nanite seems to be getting WPO/foliage support next based on commits, interesting stuff.
The thing I'm most impressed by is lumen, even my laptop GTX 1070 does pretty well with it on fairly complicated levels. the world was peaceful, but then the baking nation attacked...

Also, based on commits, seems that nanite will be DX12 only from 5.1 and after.
Although UE5 switched to DX12 by default, which actually is giving nice CPU gains compared to DX11 based on some comparisons I've seen.

 

Sounds good but remember not to let the discussion descend into UE5-support so any specific UE discussion should take place on their boards.

 

The RESULT is optimal.

Well, Melhem Sfeir and the people around him have spent up to 10 years doing that. Maybe it was not "absolutely necessary", but it was done and now the game industry can profit

Also Unity has written two new renderers the last 4 years, so..
And in a way, enabling things like those is exactly why they support custom scriptable renderers now.

Occasionally you have to break old stuff and it's actually impressive that this was achieved even without changing the hardware requirements - unlike all viable raytracing implementations for example.

 

Unity: the engine with a thousand renderers.

 

And each renderer supports exactly one hardware configuration. The renderers are completely incompatible with each other. Each one uses a different material convention.

There will be a specific one for Katamari-like graphics.

 

If we're talking about nuclear bombs, SRP wants a word

- If I remember correctly, I once saw an auto LOD project unity was making. Would create LODs for your mesh on import. I wonder what happened with that.

 

It’s stuck in experimental land after having fulfilled its purpose (the production of a blog post).

https://github.com/Unity-Technologies/AutoLOD

 

SRP could have been good if they literally listened to the community at any point during the development process and actually bothered to document it and make sure it had reached feature parity with BiRP before going "yeah, this is good to go." SRP was, in fact, one of my personal most anticipated features until they botched it literally every step of the way.

Nanite is not the be-all end-all of GPU driven rendering and I feel pretty confident stating this as a graphics programmer who is writing her own renderer.

 

We are literally talking about Nanite and the application of a specific analogue to it in Unity. This thread is about Nanite. It's in the name.

 

This is such a shame... This feels so odd, and we can see that all over the place with so many other "features"...

 

They wouldn't be surveying about it if there wasn't some intention to develop it. It was a survey that asked you to rank LOD techniques you want them to implement in order of importance.


At the very least we know they're considering it.

 

I haven't really seen much come from Pulse surveys, largely because Pulse is very new and Unity's dev cycle is very slow.

 

Intent to develop doesn’t necessarily result in a feature I can use though.

The surveys always seem like the result of a department that has little to do with development and is tasked to only run surveys. And they do. Which explains why some of them are really out of touch with the state of Unity

But best case scenario, let’s say after the conclusion of the survey Unity started the implementation of a LOD system, that means we’re still multiple years away from a completed solution.

 

Yes, I wasn't implying we'd see it by the end of this year. Just that there is intention there. I could see it show up in 2023.2 perhaps but probably 2024 if they are actually going through with it.

But I'm sure they're well aware that their LOD tools are lacking and internally it is an area of focus for future versions.