Graphics Nano Tech - Similar to Nanite - High detailed rendering for HDRP / URP and Built-In RP

Why didn't you just use patreon ?

 

Can you work on this too https://forum.unity.com/threads/vector3-and-other-structs-optimization-of-operators.477338/
& https://github.com/ehakram/FrameRateBooster
It says we can get more fps in the game.

 

Hi,
not sure what you mean, I know these little optimization tricks for C# code, often if you try to avoid creating "new" objects like new Vector3, the code runs faster. There are a lot of these tricks, e.g. using local transforms ( if possible) in your code will also be faster because it does not have to check the hierarchy of the world transforms.

Maybe I will still make a patreon, but normally you also have to offer content for the supporter and at the moment I can't give away anything. But if you want you can support me with a github subscription, which is basically the same as patreon, actually it's even better because I don't have to pay percentages to github :

https://github.com/sponsors/Christian-Kahler

 

The forum poster have given optimisation tricks for Vector3 and he has said that more can be done for Bounds, Matrix4x4, Plane, Rect, RectInt, etc...

Can you work on other strucs also to get a little fps boost. ( by removing new constructor)..

also he has said "

• Make FRB compatible with Android builds. I guess that means making the optimizer unpak the apk file, apply the optimizations on its assemblies, then repack it."

You can work on Android builds also if possible.

It would be great if you work on this as well so that we may get a little fps boost.

 

Why don't you have a go with this, I'm already busy...

I finished the DAG system and managed to get the partitioning running already quite fast. I tested it with a 6 million triangles mesh and managed to partition it in 40 seconds, there is still space for optimizations. I'm working now on the mesh simplifier too to boost speed and quality. I'm still working with C# and the job system, but I want to try shifting parts of the process to the Gpu which will result in an even faster algorithm.

 

If you are still doing this in C#, you will get way better performance just doing this in C++ as a native plugin, especially since Mono in the editor is particularly slow.

Nice work on your system btw.

 

This isn't really true anymore if you properly use the job system and newer low-level C# features that promote vectorization and give direct control of memory. The code is also burst compiling to a very optimized C++ in the end.

 

Yes that is true for what can be put into jobs (I forgot it got compiled down), but not everything can be neatly put into a format that is optimal for jobs. Also there are some low level memory functions that you get with C that afaik aren't available with jobs. Also it's not that hard to write a C++ plugin, so for big tasks, it has always been worth it to me to just write a plugin.

 

Most of what would be involved in a Nanite-type system is going to be jobifiable or Burst/Mathematics accelerable, anything left is unlikely to be the performance critical sections of the code for something like this.

But regardless, with the advent of more modern C# features like Span<T>, Memory<T>, ArrayPool<T> and the various functionality surrounding them like low-level copying memory from one region to another and slicing so you can copy just a section of memory to another section of memory, stackalloc for creating short-lived data on the stack to avoid heap allocations, ref reassignment, nullable/ref value types, function pointers, unsafe mode actual pointers... and much more...

The days of "C# is much slower than C++" are fading. But it takes time to change people's minds on this when it's been constantly reiterated forever, and for people to actually properly get accustomed to and utilize these features. It's easy to just say "you need to use C++" because it's been the norm and truth for a long time, but technology changes, tech advances and we have to be willing to try new approaches that can speed up and ease our workflows

And on top of that, Unity exposes the ability to use their own Native data interop containers without having to use Jobs and has exposed functions for a lot of data now that returns these native collection pointers.

Adding on to that the ease of development and iteration time from simply working inside Unity with C# instead of externally working through your C++ code and interop pains is important to think about as well.

Now I'm not trying to claim C# is completely on par with everything C++ allows you to do at low-level yet, but I believe for the majority of cases and more isolated systems like this you can now write comparably performant code with less work and more automatic hardware optimizations.

 

If you want some more updates about NanoTech and our other Assets, you can join our discord server:
https://discord.gg/wN8k3dua
(I think the link is time limited)

 

Dear Mr. Kahler,

What is the hard drive/disk space cost of a Nano Tech model vs regular model; say this model above, in regular fbx format and then Nano Tech applied to it;

From what I gather; it is like Nanite that you must 'pre-convert' the model, to Nano Tech format, to work with the tech?
Or, is it a switch you turn on and Nano Tech is applied 'in real time/on the fly' on the regular fbx models..

One developer on the Unreal side, said that Nanite made the models be 10 times bigger than regular models; in terms of weight/space disk demand...I heard other people who said that there was some 'compression' put on the models with Nanite so that they were Smaller than the regular fbx/obj models...yet, this dev said that no, your game explodes in space disk demand by nanite models...? Your Nano Tech Googl/github demo..is 2GB...so I mean, it's a couple of high-resolution/HD models; millions of polygons; and this makes 2GB weight...what will happen with a Full game of models? I understand that most models will not be millions of polygons, but the Total of All the models, if they are higher resolution could make 100+ GB games and more; which, I have notthing against; it's sjust that we often hear : ''the game takes too much hard drive space''; I mean today I don't believe that, when there 10 TB disks available..it's just people don't buy them and buy SSDs drive with not even 1 TB on it (because much more expensive SSDs drives than old mechanical SATA HDs)...if your game takes 100GB you eat in it....and that's when they complain the game is too space demanding; because 1 single game could eat 1/10th of their entire disk...1 single game. So they have to play 'delete games...uninstall...reinstall...choose/pick..between big games; because disk space-limited'. I mean, you can force them to do so, it's just that some people won't buy the game because they don'T have a big enough hard drive and will not buy one...just to play/fit, your game on it.

The dev said, a 10 GB game...Nanit-ized would go to 100GB or somehting, which I find exaggerated but could be partly true that the model become Bigger after nanite conversion of them. Not smaller?...

But, if your Nano Tech makes them smaller in disk space; or exactly stay the Same size...that's great,

if they become bigger ni space disk size, that's a big worrying because a very Big Game (with Thousands of HD quality 3D models, like ones on Quixel scans) would explode in space demand..after doing the Nano Tech conversion (if there is one; unless there is none, and it's just ON/OFF script).

In any case, it'S an incredible tech and good luck on it. Thank you very much.

 

The approach to a Nanite type system is that you're basically trading disk space for efficiency and level of detail. If you're going from a game-optimized model to Nanite, there will pretty much always be a size increase from the decimation and patch-based LOD system.

Many of these demos are also trying to simply show off what it's really capable of, not necessarily what you would want to try and ship currently due to size constraints. But as storage space becomes cheaper, as it will continue to do so for quite some time, the power of systems like this will really start to shine as we can afford to trade that disk space then.

There is also the huge potential with procedurally generated or displaced content. Imagine you create your sub-d model with procedural detailing and displacement from something like Substance, and at runtime these textures are generated, model is divided, displaced and then baked to Nanite and cached in disk/memory while needed. So you would be able to display this crazy detail without actually needing much source assets on the disk. (Though I'm not sure if Nanite can do runtime creation of Nanite enabled meshes yet)

You can control the level of detail the system is able to display of course. It does not need to be quite as dense as the demos have shown, you could still keep the models fairly low res and rely on the texture maps as usual. It wouldn't be quite as disk space efficient as properly crafted models, but it's still a more efficient way to render the scene and would save development time to focus on creating better worlds.

 

Hmm, what are we talking here about? size factor x1.5 or x20?
Also are we really talking about disk space? It will surely not stream mass data from the user's drive when higher details are needed because the camera approaches, right? It has to be in VRAM.

 

If you're targeting the same general level of quality as the hand optimized version of a mesh, it entirely depends on the object type. For something very organic it might just be around 2-3x. But for something with a lot more hard surface there may be a lot of wasted virtualization detail that doesn't contribute much, exploding it 10-20x (but hard surface stuff you probably wouldn't gain much from using Nanite anyways).

The way Nanite stores the mesh data on disk though is very efficient, with just 5 bits a triangle, more than 1/3 the usual space, as they only need to store information about each subsequent vertex to make the next triangle using a smart offset value system.
The data is indeed streamed from disk, similar to how Texture Streaming works. Of course relevant data is kept in SYSRAM to then feed to the GPU though, but higher detail levels can be discarded as you move away and streamed back in from disk as you get closer. It's taking that same thought process, where you're trading some often visible low-res load-in if you move too fast for being able to ultimately display much more detail without blowing your memory budget.

https://advances.realtimerendering.com/s2021/Karis_Nanite_SIGGRAPH_Advances_2021_final.pdf

 

Hello,

Great work !!
Is it possible to have a new invititation link to the discord ?


It is no longer possible to participate in crowdfunding? It's tagged as closed on https://www.indiegogo.com/projects/the-unity-improver-nano-tech#/

 

Hi everyones

It seems very exciting, and we are looking forward to be able to beta-test it.
I've got a couple of question, to the owner of the project, but also to this community :

1 - Does anyone here have been already participate to the indigogo campaign, as a company ?
i mean, will we be able to have a bill, with VAT, if we participate ?
2 - What is the amount to give, if we want to become beta testers ?
3 - Do you really think the first version will come out this fall ? I mean in 2022 ?... Or latest beginning 2023 ?

We are working on a 3D project that would need this asset.

Cheers, and take care everyones.

Poco. ( From spain ).

And PS : if someone could invite us on the discord page, I would appréciate. The link proposed is out of date ;-((((. Big kiss.

 

hi please can i get a discord link , i am very interested in your project.

 

here's non-expiring discord link,
https://discord.gg/3rzVVDg65n

 

Is this dead and if it is not why not just make it and sell it on the asset store.

 

Do you think tech like this is done in a day?

 

You can follow his activity on Discord. It looks like we'll be able to try it out soon, but there doesn't seem to be a release date yet. At least as far as I know.

 

I think once released and done right (that is why it takes time) this is going to be a very useful tool! We will have all the good features of Unity combined with some unreal type features, which is awesome.

 

This looks very interesting, and I'm impressed with your motivation and determination to do it and not wait for someone else to make a Nanite-like scheme for Unity. Actually, I'm shocked that Unity doesn't have something similar in the works, but maybe they do. From info I've gleaned, it sounds like you've been working on this before Nanite was announced, so I assume you can avoid any legal issues from Unreal. I mean, do they have a patent on any aspect of Nanite/Lumen other than the brand name? Just curious how the crowdfunding effort is going and/or if you've attracted any interest from Unity itself. Of course, they just bought Weta who might already have something similar, who knows? Either way, you've made a very impressive effort here. Congrats. BTW, what's the current status of your endeavors?

 

Unreal does not have any patents for the Nanite-tech (afaik) because it's based on old tech papers, so nothing really original to patent. Unity seems to be interested in what I do, but I think they are still waiting... don't think they have something similar in their pipeline, if I look at the history Unity never had like these big reveals, they normally announce their future work on their roadmap page... also Weta used Unity for Previz stuff not actual movies, so their is not that interest in virtual geometry streaming, but I'm also just guessing here.
Current state of NanoTech is that I got all the basic parts working, so meshes can be converted to "NanoMeshes", which are clusters that now also get compressed nicely (~1KB per cluster), these clusters get rendered as one mesh using different compute shader techniques similar to Nanite. Also the geometry streaming and texture streaming is working, with these clusters. I'm now fixing the culling system, which is based on HZB, but at the moment it's still not optimal.
Another issue I encounter is the performance/time of building the NanoMeshes, I had it down already to a few minutes even with very high res meshes, but now with the new changes it takes too long, so these two issues (Culling and Mesh Building time) need to be fixed before I can release any alpha version.
Best,
Chris

 

Btw. here is a link of our discord if you want to stay up to date:
https://discord.gg/kKA9UyR4qg

 

Hi Chris, do you have any comparison in mesh-size between compressed Nano-Meshes and compressed GLTF meshes?
Also, how well are UVs retained for strongly reduced LODs? Will small UV-precission-ssues be recogniseable at all?

 

Could your solution actually be even better then the Unreal one, when it's ready?

 

Hey, thanks for the reply. I appreciate it. I'll join the Discord, and keep abreast of what you are up to. Meanwhile, good luck with everything. I think it's a worthwhile effort, for sure, and hopefully comes together as planned. Cheers!

M

 

Not to be a downer, he's not exactly funded by Fortnite now is he?

Who really knows what "when it's ready" actually means with these random people who make cool stuff.

Most (if not all) the people I see make something that could genuinely make them big $$$ usually fade into obscurity because they have "stuff" happening (life is it?)
or more common, their tech is bought for a tv show or something and never seen again.. heh

Unity on the other hand, it would be dead next year! I'm more optimistic in his success.

 

Who says it is worse or better, from what I see it is great looking.
By the sound of it you are not optimist at all, why would Unity be dead next year (start a new thread for that)?

 

No, you misunderstood me. I said if unity took a project like this on, their track record speaks for itself on the likelihood it succeeds. I was not saying unity itself will die next year. I'm more realistic than optimistic when it comes to unity anyway, so who knows.

 

Ok, no probs

 

Hi guys,
not really hanging out a lot in the forum, so sorry that I didn't reply, if you want quicker answers you can join the disord server here:
https://discord.gg/kKA9UyR4qg
I never tried GLTF so I can't compare, but the mesh-size between Nanite and NanoTech are very close, in some cases it's even less than what Nanite does, because I'm currently using 256 cluster-tris instead of 128. However this might change in the future, so it's hard to compare at the moment.
I'm still working on better UV results, they are not bad but I think they can be better. I will soon make a Nanite vs NanoTech comparison about these topics to get a better overview.

 

I hope so!

 

have you checked if there's anything in godot 4's source code that is useful to you? I know that they have something akin to unreal lumins. so who knows

 

Will this work with DXR? [Edit - I'm making a short film(s) and it would be nice to just build large sets without needing to think about culling so my perf in editor doesnt die ... however, I wouldn't want to lose DXR just for that!]

 

yep, same here!

 

DXR support will work, but there are still some issues with DX12 and DrawProcedural with Shader Graph, I could fix it manually but I'm hoping that Unity will fix it in the shader graph, as my fix is not a good solution.

 

Is there a beta of this available yet?

 

not yet.

new video is out, has current status info

*follow their discord for latest news

 

This tool could be the best tool in the asset store. definitely if you can make it to work, I would pay for something like this. definitely i will put an eye on it waiting for soon release on the store.

 

Is there a time frame for when this will have a beta?

 

current status from their discord (for the alpha version)


they have new video here,

 

Sick, hopefully it will be done soon I’ll definitely buy it.

 

just want to push an update, I HOPE