So, Nanite

I think there is a scenario for someone creating a new kind of terrain engine with this in Unity. That could fly. It's a contained problem-space. They won't need to convert any meshes, just heightmaps that could be splatted in any direction rather than just from above.

That kind of rationale also means no conversion process is needed from mesh->texture, and the quality control issues that would be endless with mesh conversion.

This way, you could conceivably leverage the tech without the tooling and engine backing pain. You could have arches, overhangs, caves, all kinds of things where you're essentially projecting a texture the tech knows all about and can control what kind of data is being fed in.

I have a high degree of confidence for general terrain rendering with no mesh conversion.

 

I've explored this idea outside of the context of Nanite 'em ups and honestly, this idea for terrain generation is kinda too messy to really be practical from an implementation standpoint. Really, the best idea in this context isn't to use some sort of direction map but instead sparse voxel octrees that, well, already exists. Even the tools that would accomplish creating this on the user side would be functionally identical.

Let's say you have a terrain like this:

This can be represented with a single heightmap, sure, so let's make it more complex.


So Dog Face Mountain here can be represented by two height maps, sure, one that goes from Y 0-1, and now we have another one that extrudes off the X axis, that would have to have some amount of coordinate data attached to it, as well as a bit more data to make sure it accounts for everything involved.

The main issue that arises from this is that, as the terrain increases in complexity as far as overhangs and other complicated concavity increases, you'd have to store more and more terrain texture data to keep editing when data structures like sparse voxel octrees already exist, are considerably more robust, are considerable faster, and have underlying data structures that are easier to maintain. You can even have it dynamically generate mesh data for stuff that would fall out of the SVO itself if the subdivision gets too small.

This is the sort of thing I mean when I say "sure, you could do this with Nanite or similar, but alternatives already exist that are already battle tested and shown to be working."

 

And then you add another Dog Face Mountain placed on the X-axis behind the first one, and one more height map is no longer enough. And then you end up needing voxels.

Honestly, the slides Riyah linked explicitly mentioned that nanite is not good for "porous" materials. Meaning no serpinsky carpets or Menger sponges.

 

Initially, and probably theoretically, because the big flex of the matrix demo for people who would meh at a city (we got plenty of those already, see megacity demo from unity), was the metallic fence (ie the worse case) being fully polygonal especially up close, which is probably a first in real time video game.

I mean worse case for octree voxel is also checkerboard pattern like the serpinsky, but then you can compress it into a DAG anyway.

It's funny because that part of nanite is almost just that, but optimized, it's a DAG of triangle cluster, so you assertion is right, alternative already exist and it is EXACTLY nanite...



People against or even for nanite think it's pixie dust, it's not.

Where does the anxiety come from? All necessary information are out there.

Spoiler: BTW unity proposed a new terrain renderer that use a new graph

 

Sure, if you mean "carries superficial similarities." I dunno how to explain to you that tree based culling systems have long predated Nanite and have multiple implementations and use cases that excel where Nanite does not, notably:

Again, this is all "new tool effect." I am talking about things that have tested examples and use cases, some of which I have implemented myself.

 

How it is superficial similarities when the "culling system that long predated Nanite" IS nanite, it's literally just a collection of old techniques, which is my argument, if I start pulling historical comparison and make a wall of text, I'll be accused of derailing.

You are arguing that nanite is something that's it's not, it's a good old bag of old technique made to work together with the spicy new compute rasterizer that took care of the micro triangle bottleneck, and even that isn't exactly new, it's good old software scanline rasterizer.

It's not new, it's the ultimate convergence of old tricks and tools. That's what's surprising about it! Which is why I'm baffled at the resistance.

New tools would be NERF (neural radiance field) or any light field renderer, which isn't proven, Nanite (and lumen) are the exact opposite in everyway to that! You would have said voxel rendering like tearaway or sdf thingy like ps4 Dream, that's not nanite, nanite is "basic" as hell.

edit:
check here (2015 slide in tweet)
https://twitter.com/sebaaltonen/status/1402951008830070790?lang=en

 

You are trying desperately to push this narrative that Nanite is not fundamentally new implementations of things and it's not working. You're also trying desperately to push the narrative that Nanite is a fundamental paradigm shift, which is also not working. The reason these things are not working is because you're trying to treat it as both more and less than the sum of its parts.

This is exactly how the New Tool Effect works.

 

Not necessarily.
Nanite successfully combines a lot of known things, very well combined, delivered with tooling simple to use. Fixed up the biggest issues. In other words, making such a concept production-ready for a general audience. A viable new system.
The end result is a paradigm shift for artists and world designers.

Quoting Aaltonen from that Twitter thread, in Ubisoft's implementation:
"The biggest achievement in Nanite is the way they combine all of this tech together. Great ideas collected in a single well optimized product. Their automatic cluster LOD is a massive improvement. Their software triangle raster beats hardware by 3x for small triangles."
"We had GPU-driven LOD solution. Choose a set of clusters for each instance based on distance. Artists had to manually author LODs and the tech demanded very good LODs. Nanite is much better here. They have an innovative per-cluster seamless LOD solution. And automatic LOD authoring."

They were close in 2015 but didn't actually reach the maturity of Nanite. Perhaps simply because of relatively short development cycles.

Another example from above. Adding chain to a bicycle after 70 years. The elements were old, but the configuration was something new!

I don't see any narrative here, just conversation on innovation. What makes system X a viable innovation? While something using similar elements isn't a noticeable innovation. This is a common thing with technology and inventions "Does it impact our life or work? Does it really solve underlying problems or just provide a limited workaround? Does it work at least 90% of the time or are we gonna apply 20 different workarounds to just make it work at all?"

 

But what is your arguments against? you state bluntly things and you don't substantiate them. I mean I'm saying it's old stuff applies in new concept, that's a pretty standard and proven way to make innovation. I'm also very precise in my example, coming up with historical precedent, so i'm not pulling opinion from my ass.

I say it's "old", I show you at least one example actually dated (2015) that does the same thing, I can probably show more example and do an history of all the technique. Yet you still handwave with generic assertion, I mean if the onus of proof is on me, at least criticize the proof, don't just use random judgement value out of nowhere. Also even if I'm under such nasty thing like the new tools effect, it's irrelevant to the quality of such tools, so it's not the argument you think it is. And I'm not even saying it's magical pixie dust, I have been arguing both for and against many assertion in this very thread, linking back to actual fact, about what it does well and what it does not:

Ie not really a performance improvement (except if take into account polygon density, but it's a true workflow enhancer, even easy solution like decimation take more step than just clicking "make nanite mesh" and there is many video bench mark to prove it, BUT it's currently lock into an engine and ecosystem, so aplicability is de facto limited, AND I said people will not copy nanite, just the lesson.

Anyway I'm out of this specific discussion and will stay into providing facts (and accept corrections, like Ryjiah's, when I make mistake) to assertion because i'm just a nerd, I can't help it.

 

...i just wanna a volumetric nav system

 

Hi, you don't have to derail threads on an important topic, because I am actually learning a lot of things from the discussion and resources posted here. You can try making a new thread to get new information about how to tackle and solve this issue.

But I suggest that you refer to my previous post Volumetric Navigation Solution, there is an instant solution, and DIY solution you can make yourself by just learning some tutorials on vectors. Its not a deep subject, and should be a good start to your game-dev journey, which is mostly about learning and applying new things for every new challenges you have.

Or you can hire someone to make a great solution for you. Any decent programmer should be able to come up with a nice solution with your specifications in no time. The good side is that you can learn a lot from their work if you are just starting out. Its killing two birds with one stone, its practically both paying for education and work at the same time.

Spoiler: Psst..

There are a lot of devs which can reallocate their time spent on forums for implementing useful things. You can spot the ones that replies quick for every new posts.

 

You'd be lucky to find that integrated into any engine outside of CryEngine. Honestly though, implementing an octree (again, octrees are great for 3d spatial mapping) and greedy A* will get you 90% of the way there.

 

UE5 is not open source. You can't just use it as reference material to develop your own solution.

 

I am not a programmer (I use GameCreator to make my games work). I am just an artist and to be honest yes, nanite is a strong attractor, it looks like magic to those who don't know all the backend and their almost instant (compared to Unity) global illum looks pretty good too. The though of being able to pull in assets from zbrush or Blender at fully sculpted resolution (or even decimated a smidge) would be awesome! The best part would be (if I am understanding this correctly) no need to setup LOD's. For creators... having limitations on what we can put in the world is truly disheartening. Example: Artist: "I want to put this really awesome Pillar in the scene, but to make it look right it has to be 1.5 million polys. Oh what's that? We don't have the budget for that... Fine.. here is a 1,500 poly version that looks like crap..." LOL.
I am currently working on VR project and I was reading that UE5 just released their vr channel. But, they said that nanite and the global illum does not work in the vr. Just though how amazing it would be to build highly detailed worlds in which you could manipulate in vr. Maybe someday... But, if Unity could do something like nanite that would decrease the number of people wanting to test it out. So, I have read some of the posts here and thought well if others can come up with at way that they could.. why not share an example of your idea with them and see if they can implement it? Or, if you can make an asset that could do something like it would be fine too.

 

But really, how much LOD do indies do in current games? Half of them don't. It's a matter of tool for job. If your job is going to be doing a platformer like Hat in Time, then nanite saves you a little bit of time and dramatically reduces how many devices you can sell the game on.

If you're an artist wanting to make a showcase presentation with a lot of environment props, then I think currently, Unreal is hard to beat. But for practical indie games, the hardware required for nanite still means you'd lose money, at this point in time.

Eventually the minimum hardware (mobile, mobile VR, nintendo handhelds) will be perfectly OK running this stuff. But right now, it's just going to lose people money if they're shipping inside 2 years.

And it's a no-brainer that allowing artists to focus on art instead of the preparation of it, is the way forward for everyone.

 

The Matrix Awakens demo is one of the most demanding scenes we've seen with the tech and it's very much playable at 1080p (50% upscale setting) on medium with a GTX 1060 6GB which is the most popular card on Steam. That and all the faster NVIDIA cards add up to more than half the reporting user base.

Spoiler: Matrix Awakens - GTX 1060 6GB

 

Yeah but this is on a desktop. It still isn't on switch, never will be on a whole range of mobiles and mobile VR. So it becomes useful for markets which will not include those. And that's considerable for some.

It seems pretty CPU sensitive as well, at least it chugged on my 6 core Ryzen (the GPU is a 2070S)

 

Which generation of Ryzen CPU? It's important because the original 1600 while being a fantastic budget CPU for the time is at best only on par with a 5000 series Intel CPU while the 3600 is equivalent to a 9000 series and the 5600 is equivalent to an 11000 series. It's a massive difference in only a few generations.

Epic has said that it isn't supported in VR but there are videos of people trying it out anyway and it's working albeit with some occasional crashes. Seeing that UE 5.1 is already getting foliage working in Nanite I'm not going to write off any of the platforms you listed until we know for certain.

 

Oculus does already run on Vulkan, and Vulkan already supports Nanite, so...

 

The Radeon R5 series supports DirectX 12 but that doesn't exactly mean it supports it well.

 

This is a technique that requires a baseline of memory bandwidth that simply isn't there on mobile, AFAIK.

Nanite is a "do work A to save on work B" technique. Depending on the hardware and what resources are involved on each type of workload, it might be that the cost of A doesn't compensate the reduction in B.

Deferred shading is one such technique: it reduces the cost of many aspects of lighting in exchange for increased memory bandwidth usage during rasterization. But on certain GPUs (like mobile) the increase in used memory bandwidth can be such a bottleneck in itself there's no budget left for anything else.

Nanite only works with deferred shading right now: it's uncertain if the micropolygon rendering is even viable in forward, and the screen-space materials do require intermediate buffers regardless. Epic recommends using UE forward shading on mobile, Switch and VR, so it's understandable why it's not officially supported on those.

 

But shadows and lumen is disabled.... No doubt that nanite works well on all graphics card but u still not all types of games need it, like side scrollers or a top down game or a game with small sections don't need LODs and most importantly not all meshes need LODs especially the small ones like grass and rocks which can be directly culled and again generating LODS is not that time consuming especially for things like big rocks... And currently in unity u can get nanite like optimizations with hybrid renderer which has subscenes and BRG which perform batching and culling and might give you big performance gains ... I don't mean that nanite is useless, i really find nanite time saver when building big worlds with only modular pieces like in valley of the ancient demo and matrix and no polycount limits is really great in artist point of view and everything just works out of the box
EDIT- The matrix demo didn't even open on a 1650 HDD 8GB ram laptop
And also the demo was using TSR which doubles the frame rate so i expect 40-30fps without it....

 

Neither of which are the topic of this discussion.

This isn't the fault of Nanite and it certainly isn't the GPU's fault. It's the low amount of system memory. You can't expect modern AAA games to run well or at all in some cases with less than 16GB RAM. For reference I checked Elden Ring. It requires 12GB and recommends 16GB.

 

Free performance, ladies and gents

 

Is nanite supported on mobile??

The setup seems very problematic to me??! Has anyone tried to do it... He keeps talking about textures instead of polygons

 

Ask Unreal forum.

 

Their own manual says "no" (limited to PC with Maxwell architecture and up GPUs, Playstation 5 and Xbox Series S/X)

 

@hippocoder
For my games, I generally create my own game objects.. which I have used some asset tools to make some LODs, but that can be tricky sometimes based on the model. But, it LODs do help improve some performance... but, to make money I create scenes/animations for Arch and Engineering companies. Which generally have large scenes with great far distance clipping plane and no real use for culling objects behind others because they want to see the entire project not just a FP view. (see an example: Cleveland Animation Compile Example V1 1 26 2022 Noaudio 1 - YouTube) For these I try a lot of technics and use assets like imposters and optimize as best as possible with poly counts and draw calls. These are also usually quick turn arounds like 1 week to make the entire scene. So, optimization is hard to do when crunched for time. It is usually, throw it all in there and make the best with what you got as quickly as possible. LOL. It would be nice to just drag a bunch of assets in and not have 8 frames per second. I mean I have a really nice machine, but it still chokes on all the stuff I have to put in there (which is needed to make the scene look like what they want and half way decent). That is the only reason nanite really appeals to me. It would save me a lot of time not having to worry about it. That is if it works like it says it does. I haven't read much just watched the videos. I don't know how it handles textures and draw calls, or if really is just magic and makes my wildest dreams come true. Can you just drag in any and all things at high resolution textures and dense poly counts and it handles all the optimization for you?

I have seen this video... (say that it might be possible.. Nano Tech - Quick Test with Unity - I made something similar to Nanite - YouTube) or are they just messing with people. It doesn't show the "stats" so I don't know if it is doing the same thing or is it just 1 high meshed lod'ed model with one texture to have it look like it is doing the same thing.

Anyways, I dream of worlds without limitations on our imaginations. Ultra realistic worlds with nothing to stop it from running as smooth as real life. Someday.. maybe a full-dive SAO style would be the only way to achieve that. HAHA!

 

So apparently they had other videos for this "Nano Tech"
Nano Tech - Experimental Version 2 with One Billion Triangles Scene - YouTube
Nano Tech - Quick Mobile Test - Unoptimized, this is not Nanite! - YouTube
Don't know if it is the same.. seems like the streaming of polygon amounts are slightly choppy, but look pretty good.

 

We have all seen those videos, they've been shared in this thread even. What people seem to be missing, and this is something that absolutely blows my mind on a forum full of programmers, is that there are a billion steps between prototype and product.

This is a prototype.

 

That reminds me... does anyone remember Atomontage?

That's another "future tech" that has been brewing for a while. Those guys claim 20 years of R&D on this.

Spoiler

 

Oh my god that still exists? I thought that was vaporware based on how long its been

 

There was another tech like that, that went vaporware. It was "unlimited detail" from "Euclideon", I think.

 

I commend these Atomontage devs for at least getting some playable previews up. But they give off strong Don Quixote impression. To think that CG industry just cant wait to switch to voxels from polygons. Especially considering sorry state of what they're offering. Baked in lights and specularity in 2022, mad LOD popping.

 

Can I see any AAA game running on decent hardware with this mad LOD popping?

Since it seems to me you'd only experience "mad LOD popping" on something that isn't running well enough to run nanite to begin with, or a seedy little indie title cobbled together without good understanding of how to transition LODs.

 

Wasnt referring to Nanite

 

Regarding Atomontage demos, maybe my internet was a problem. Since I took it like it uses some voxel based analog of streaming video? In any case, objects never stayed in a good quality for long and constantly reverted to lowres voxel soup. Thats what I meant by lod popping

 

Same.

 

So this dude made a Nanite equivalent for Unity using the Unity's own new Renderer API, except afaik this one supports DX11 also - Nanite doesn't.

The scene has 60.000.000.000 active triangles running butter smooth. I support his work, and hope Unity notices it.
More info: https://forum.unity.com/threads/nano-tech-something-similar-to-unreal-nanite.1199371/ .

 

We have literally discussed this video and NanoTech repeatedly in this thread. We have discussed it on this same page, even.

 

DirectX 12 support goes as far back as 2010. Neither the CPUs or the GPUs of hardware prior to that would be able to handle a technology like this. We're talking cards like the GeForce 200s which would struggle to run games like Skyrim which don't even have modern features like PBR.

 

Oops sorry about that as didn't read all of the posts, but good to know it got recognition. Perhaps one day it will pass its prototype phase or so.

I think you meant DirectX 11 as DX12 debuted back in 2014 when the nVidia 800-900 series were out - if I'm not mistaken. Nonetheless, it was worth mentioning it.

- Regards.

 

While your point about the small difference in date is true, the point @Ryiah was getting at still stands. Why do you need to support 2014 spec devices in a game using nanite-like tech? Do you really think a large (or even significant) portion of playerbase for a game that would have graphics that require something like nanite, would have such hardware? Do you really expect something like a game using nanite etc to actually run on that hardware at all?

Its 2022 now, directx 11 support on nanite-like tech is like saying "my electric vehicle can plug into a 1910s power outlet!" - its basically useless.

 

Supporting older DirectX is actually limiting such tech, not offering any practical advantages
- DX12 is one of the new APIs providing engines (nomen omen) direct access to GPU, reducing driver overhead. There are a lot of performance gains here. High-fidelity 3D games can be released on DX12 by default. Nanite, or not
- DX12 supports Shader Model 6 and a lot, no apparent improvements. AFAIK that was the reason why Epic required Nanite to use DX12 in the final 5.0 release. It was working for a long time in the Early Access and even the Preview phase under DX11.
- I guess that new APIs can help to unlock Nanite support for the entire featureset. On ue5-main branch (developer branch for the next release) we see work on supporting masked material and World Position Offset under Nanite. Such things are much more important than supporting now absolute DX11. Obsolete since UE5 runs on DX12 by default.

 

Performance gains that go beyond simply rendering. One of the biggest advantages of direct access to the GPU is the new DirectStorage APIs which for anyone not familiar allow you to stream content directly from highspeed SSD storage into the memory of the graphics card.

Without DirectStorage you'll have to rely on slower approaches to streaming in content which will adversely affect how large the world is and how detailed its meshes can be. What good is it to be able to render the scene if you can't get the scene to load when you need it?

 

It's still worth mentioning Nanite don't require SSD to display that level of details, since that's the whole point of the virtualization, similar to virtual texture. Ie it allow to optimize details in a more or less fixed bandwidth and footprint, and that bandwidth is well within regular HDD limits.

Because it's tied to screen resolution and because it selects and culls fixed length "clusters LOD" base on their screen footprint, there is only so many pixels on screen, and materials are process is a kind of tile deferred so it doesn't over shade pixel.

HOWEVER, game dev being what they are, they will find new way to break that limit.

I'll take any of your guess of what you can blew up in the bandwidth and memory of the gpu when triangles and pixels throughput have a roughly known upper limits? I haven't look at what effect this can have on shade complexity. What about transparency and the so call small aggregate like foliage?

 

from the Nanite docs:

 

Okay, but so far the heaviest demo are supporting HDD flawlessly, I don't think it's contradictory, seems like some precaution for future proofing or something. Or maybe at edition time. All I'm saying is that the tech seems to support it, even though it's not recommended (old hardware are failure prone too). The original reveal told that poly were capping at 21M tris, game have done worse. BUT a SDD guarantee smoothness and no latency from seek time, so less error overall even if old HDD SEEMS to be supported by the base rate of the tech.

But thinking a bit more about it, there is more a to a scene than texture and mesh, how about the baked probe volume? I don't think everything will use lumen all the time with nanite.

 

I never said it needs to support DX11. I simply briefly said how it is made - using the new already-shipped Unity Renderer API, and what is the most significant difference to Nanite - which is supporting DX11. Simply to let the community know about it.
Nothing more and nothing less.

//
Now you asked my opinion if it is useless that the asset supports DX11. In summary, if it delivers approximately the same performance as Nanite, then I necessarily do not think so.
Use cases like driver compatibility issues forcing the software to run on an older DX - although the hardware is powerful, which happened to my laptop (and the majority of users of such laptop) and my own Unity project before (besides a number of video games). Or using DX11 on Linux, though I hope DX12 fully gets supported in the future.

Again, to be clear, IMO this is just a perk, not a must. In fact, I believe if such an asset is optimized enough to get such a result in an older tech, and if it could have been significantly better in DX12 using DirectStorage or so, then just writing it in that way would be obviously more reasonable and I'm all in for such a DX12 or even newer system for Unity without a doubt.
But these are my two cents so I cut it short here.
//

- Regards.

 

Outside of the Matrix Awakens City Sample every demo has had its characters moving along a fixed path which is one of the easiest things to optimize for. Of course even if it wasn't none of these demos have gameplay and all of the demand that gameplay adds to storage requirements.