So, Nanite

https://mobile.twitter.com/SebAaltonen/status/1399350400822743047
If this and nanite are similar than it is not locked to UE5 it can come to unity or any other engine out there.... If the tech is really game changer than I am 100% sure unity and other competitors will surely add something similar to it but we don't know when?? And there are also many other approaches to achieve infinite polygon systems.. not necessary to add something similar to nanite

 

Unity is not able to speculate because they are a public company now.

 

Cool, give some reasons why then, since both of your comments have basically just been "package manager bad, you're wrong, the end".

 

My intention was to state my disagreement and attempt to end the discussion there without dragging the thread further off topic. But here we go:

With verified packages being tied to very specific Unity versions, the package manager has no meaning IMO.

Newer packages with fixes etc never make it to older Unity versions. The original concept was that you would stay, say, on LTS, but you could potentially get *some* updates / fixes through the package manager. That almost never happens. (the only times I have seen it happen was with TextMesh Pro and Timeline, both of which were better served by the Asset Store).

Verified means "this is the package version you're supposed to use with your Unity", and while that's nice because it reduced the headache of having to figure out the random packages that will play well together, having a very rigid set of verified packages is more or less the same as them coming built in.

Also, the editor doesn't really become leaner, if anything the package manager has been used numerous time as an excuse for why the editor has become slower, and it's not like you can easily get rid of a lot of packages with the natural dependency hell that comes from using a package manager.

On top of all that, moving to the package manager has resulted in a ton of wasted man-hours, I know the Collaborate devs stated that moving Collab to the package was a big effort and was used as an excused for delayed of actual fixing of things (fixes that never came, but that's another story).

 

I think Package Manager was the right direction but the another issue came with as well. More like exposing the problem rather than a new one.

It is that Unity devs have much lower output returns vs the time spent. I am not sure whether this is bad hiring/management or other tech companies being just better. Either way, the verified package thing is a complete joke at this point as it means nothing.

I recently got into a conversion regarding Virtual Textures implemented in HDRP, and I wrote a comprehensive feedback on the forum (look it up in HDRP forum) and pointed out that one crucial and mostly basic feature is missing. I don't think the dev took it well. He never came back to reply. Just said "did u look into XXX API?" while my response was "yeah, but that API is not good enough". If I summarize the whole thread. The documentation was not complete either. But he never replied again so...I don't know. Maybe he is busy or just felt no need to discuss it any further.

 

Thx for drawing attention to the tweet - also here is the code(written in rust plus you can also check pdf on the same page which explains technique) - so gpu culling similar to nanite - https://github.com/sebbbi/rust_test

 

Unity faces a big problem: effective retopology and lod making takes a lot of production time and money. This is very expencive. If Unreal cuts those costs and makes it prettier at the same time, it becomes economically infeasable to choose Unity, at least from art production standpoint.

And all the "NativeCollection" stuff starts to smell like manual memory management with extra steps, so C# argument also starts to look shaky. Editor interation times get longer and longer, LTS versions crash on reload like crazy, SRP feels restrictive and useless. I really don't want to jump ship, because it's a ton of my expertise time (8 years with unity), but is this really just marketing or is this the time to fix time loses and move?

 

I mean, UE4 already had automatic HLOD. Nanite is an evolution of that. Unreal took a leap in an area where Unity just refuses to offer anything (not counting PIXYZ).

 

People keep taking about Unity being good for mobile, but the Nanite tech is about automatic lod and culling system, that perfectly shows only parts of the models that you need to draw with "resolution" you need to draw it. It's general purpose and will scale to mobile. soon enough. You pre-bake assets anyway, so your baker will just produce more crude meshlets for mobile. But if you can discard a bunch of stuff before you draw it, maybe you don't even need to make it too curde. Modern mobiles are capable enough.

 

Correct me if I am wrong but nanite does not work on mobile

 

I think that unity never added an auto LOD system because creating LODs in 3d modelling software is easier and u have more control over it... But I just don't get why unity never added an imposter tool... it makes rendering huge scenes faster and is really an important tool for all types of games of any platform... and every engine has it....so requesting unity to add an imposter tool...
I feel that SRPs have made the job easier and faster for me

 

I think even godot has octahedral impostor and it would be really nice addition to Unity

 

Not quite. Compute performance is still lower on mobile (compared to fragment/vertex performance), and Nanite relies on relatively modern GPU/driver features which may or may not work (or work well) on mobile Metal/Vulkan, specially on Android where there's more driver variance.

Again, Nanite is about more than just LOD streaming. Their visibility buffer implementation boosts rendering performance for low polygon meshes as well, because it can render all meshes with the same material in one draw call (even if they are different meshes) while also nearly eliminating "overshading" at the triangles' edges.

 

Does Unity not already have assets for automatic LODs? Or is Unreal's LOD system so much better?

Edit: Well there's Amplify Imposters which seems good so far.

 

Has there been any official response to the UE5 technology announcements?
I really would like to know what the Unity team is going to do to stay competitive in the high end space.

I mean Unreal Engine 4 was always a bit ahead of Unity, but since Epic Games acquired Megascans and released Meta Human Creator it's really been expanding its lead in huge leaps.

If i am totally honest, i'd rather would want to see Unity focus more on mobile and lower end devices (mobile VR headset for example), because it doesnt make sense to play catch up when you're that far behind. You'll just waste a lot of resource and still be massively behind (judging from the last few years of Unitys progress).

But i guess if they'd announce a direction change like this it would be pretty bad for their stocks. The way i see it Unity is now completely unviable for AAA, Visualization and Movie industry (with the last two being critical in terms of future growth potential).

I think one of the best things Unity could do atm is to finally release source code access to everyone and try to involve the community to advance the development of the engine.

Anyways unitl i hear a confidence inspiring plan from Unity for future development, i will start to relearn Unreal Engine to improve my hiring chances and stay competitive in the Job Market. I t Unity staying so quiet about the reveal of Unreal5 and the release of the preview, really shows that they got caught with their pants down and don't have the means to compete against it.

Did i miss something critically here in my analyzation? I really would love to see Unity succeed, but after 5 years of working professionally with it and following its developments, i sadly don't see its future very positive at the moment.

 

Unity management made a huge mistake by allocating a lot of resources towards the DOTS development. I never understood this. Zero risk management whatsoever. While it looks like they scaled down a bit on DOTS, a lot of damage has been done already. Hopefully they will get their priorities straight. Time will tell.

 

I agree with everything you've said, just wanted to add one thing. It's possible that what you wish will come to us through custom SRPs made by the community. I've already seen one custom SRP in developement with some advanced stuff like Virtual textures, Stochastic SSR, SSGI and etc. And I know another developer of a couple of quite famous assets who also plans to create his own SRP. Maybe there are others, who knows. So, it's probable that after SIGGRAPH 2021, when papers on Nanite and Lumen are released, these techniques will be adopted by some custom user pipelines. Meanwhile, I feel like Unity's official guideline will be "use DX12 stuff". Mesh shaders (they're next on the roadmap) for geometry instead of Nanite, RTGI for GI instead of Lumen, RT Shadows instead of Virtual Shadows, plus some features like VRS and Virtual Textures on top.

 

Unity is focusing on every platforms and trying to expand in every field..
Because of UE5 this is the state of every other engine not just unity..... Unity can catch up within 2-3 years if they properly manage things, don't give up any tool, bug fixing and prioritize things properly

DOTS is the future unity should focus more on it.. it won't damage instead repair the engine

 

DOTS is in fact the only reason why I didn't switch to UE5.
If Unreal had something similar in the works, I would jump ship in a split second.

 

Without dots Unity cannot compete unreal - dropping dots would be like activating self destruct button imho so i think there is zero possibility that to happen. Also Unity already has a way(api) to process meshes on gpu(using compute shaders) also their employee who works on hybrid renderer wrote a paper about techniques similar to nanite(plus he wrote in rust proof of concept available on github) so it would be extremely surprising(I mean their greatest competitor is challenging them) if Unity doesnt experiment with nanite like technology(probably its in early stage though) already - but the main question is when will they expose results to the community ... I want to believe

 

Mainly this, i do believe unity team are capable. The main question is when will it be delivered, i'm still waiting for the hybrid renderer

 

DOTS has its place for performance critical situations, like particle systems. Other then that it adds complexity and strain to the developer. While I like DOTS, Unity has failed to prioritize the roadmap properly. Unity is far from feature complete and is still missing a competing terrain system.

 

I don't believe that unity would really catch up on high end realistic rendering , even if they would implement something like nanite. The amount of time you can save with megascans and metahuman and the high quality results you can achieve, make a strong case for unreals economics. I think for small to mid size studios this situation helps immensely in cutting cost and minimising risk and will increase the graphical expectations of customers as well. That's not such a huge issue for stylized and retro graphics though. So I'd rather would like unity to focus more on delivering great features for projects built for lower end hardware. I do hope though that they'll suprise me with something unexpected. Maybe some amazing procedural + ai powered tools for production or realtime ai style transfer as a post process <3

 

What's holding back unity is the aging single threaded core backend, the sooner they get rid of it, the sooner they can start building actual improvements and not bashing themselves against a wall. So far a lot of initiatives fail because of that, Bethesda reflected on that when doing their mobile game. Unity is trying to cope by building helping module that move load around in multi threaded environments, but are still bottlenecks by the rigid main thread.

They should silently upgrade the core, then came back with proper implementations.

So far the only full engine rebuilding is tiny, but still held back by whatever is happening on the webassembly and webgpu certification. Did they finally agreed on how to do web multi threading?

 

I think the problem has been with Unity's execution over the past several years.

DOTS was amazing when they made a big deal of showcasing it at Unite LA in 2018. But it's now 2021, and DOTS is a mess. Sure, Burst is great and Jobs is solid, but the core of DOTS was ECS and that's nowhere near production ready. In fact, development for it is now locked to the 2020 LTS stream until further notice. They won't even commit to it being able to merge back to the 2022 stream. To top that off, it's been 6 months since a new ECS version was pushed. Previously the longest stretch was 2 months. I agree that DOTS has a lot of promise, but it's a lot less interesting if it's still 2-3 years away from being delivered.

Then there's the SRP mess. Don't get me wrong, in theory I love the flexibility to customize your own RP that the SRP offers. As a practical matter though, what I care about a lot more is having an RP that works out of the box. The URP is meant to be a replacement for the built-in RP, but even 2 years after being released it still doesn't have all of the features provided by the built-in RP. It just added deferred rendering with URP 12.0... in 2021! The HDRP is just a hot mess of bugs and undocumented functionality. And then you get to the headache Unity created for Asset creators by bifurcating (actually trifurcating) their engine into 3 separate, entirely incompatible RPs. If you're creating something for the Asset Store that touches the RP, you have 2 choices: (1) choose one RP as your target and hope that it's where your user base is going to be and learn to live with that fact that you'll miss out on all the potential customers who are using the other two RPs or (2) build and maintain 3 completely different implementations, one for each pipeline. You know, just build your product three times.

For me though, the pinnacle of all of this is the DOTS Hybrid Renderer. It is dependent on ECS, which is locked to Unity 2020 LTS. But it is also dependent on the SRP. Of course both HDRP and URP are being developed on the 2021 tech stream, so versions 11.0 and 12.0 require Unity 2021.x, which means they're incompatible with ECS and therefore incompatible with the Hybrid Renderer. If you want to do anything with ECS you're stuck on SRP 10.x, which means no deferred rendering in URP and you miss out on all the bugfixes that went into URP/HDRP as part of 11.0/12.0. And remember, Unity won't commit to when ECS will graduate from 2020 LTS, so it's unclear when the Hybrid Renderer might support anything beyond SRP 10.x.

So like I said, I don't think this is a question of Unity's lack of vision/message about how they're going to complete with UE5. Unity's problem has been their inability to successfully execute on the vision they've been pitching for the last 2-3 years and the fact that there aren't really any signs of that changing in the near term.

 

This is interesting unity gpu occlusion culling experiment(not exactly nanite ofc) :

and here is page with additional infos(all from 2018) : Unity GPU culling experiments – MPC (mpc-rnd.com)

 

I love this honest competition between game engines.
I remember Natalya Tatarchuk talking (presenting) a new Unity technology that the description was awesome and similar to Nanite. But I presume probably was before this (extremely expensive) PiYXZ.

 

One thing I am also missing in this Discussion about Nanite is the fact that in only works on static geometry. I think showing highly detailed static objects has not been an issue for game engines for quite a while now.
I'd be way more interested in it if they developed something similar that works on trees/grasses and all the other nice dynamic objects. I think in realistic open world nature scenes with a lot of plants you would not get a lot of benefits from Nanite. Lumen seems nice though, I wish we had something of that quality in Unity.

 

It's been addressed in the discussion, you underestimates the workflow saving nanite give for not having to make lod, and it does go beyond existing implementations by correlating geometry to screen pixel density, which mean details are now only a problem of storage space, and since the system is based on cluster of vertex, it makes streaming easier. Which mean you just pluck down and kitbash mesh without having to care about any details or optimizations. It also handles visual occlusions on almost a per pixel basis.

It doesn't work with foliage at all, ie no thin geometry, no alpha cut out and transparency, and no dynamic geometry like branch and grass swaying to wind.

You would still get benefit from nanite because static mesh occlusion.

 

@neoshaman I agree that there might still be a benefit of their data structure and of course the workflow is really nice, I actually think all game engines will be more like that soon, that the actual resolution of input assets won't matter, because LODs and streaming will be automated. I could automate such a thing today within unity with using regular meshes. And just like Nanite it would work perfectly well for static rocks and such and worse for trees.
I am just slightly against the hype statemets of however many polygons you can cram in, because geometric detail just does not matter that much for static things. You can already bake, precalculate occlusion, etc. most of the things that Nanite actually leverages are not new. But the only thing where polygon count still matters, at least for my game project, are dynamic objects.
More leaves on a tree could move 3D graphics closer to reality, more polys on a rock are mainly a waste of hard drive space, in my humble opinion.

 

Also physics and AI.

 

They matter because every expert in the industry noticed, it's more like a proof of concept that set the new state of the art to a new standard. So of course everybody will aligned, true it's not truly new, the new things is actually a novel combination of old technique optimized together, which is a feat in itself, it's like solving a puzzle and showing how it's done. The hype is very much deserved, because it tells you exactly what it does and no more. Also occlusion matter for geometric details of dynamic objects and for overdraw issues. Also all of it is dynamic, no need for baking, we can't stress enough how much of a workflow optimization that is.
It's possible it can be used for foliage if we use geometric details for them, instead of alpha cut out, which was itself an optimization for old standard, test need to be done to be sure about that. They are pursuing optimizations for all these case anyway, let see what they figure out.

Note: dynamic objects are taken into account, what we mean is specifically deforming mesh, such like skinned meshes and vertex animation.

 

@neoshaman yeah, i agree with you on a technical level. But I do understand the transformation of a mesh into Nanite representation as baking, for sure you don't need to do anything like that anymore within the scene context.
The first question i would have as a developer would be: can the conversion of a mesh to Nanite be triggered during runtime of a Unreal game? That would be very cool and would have great potential for modding and collaboration, basically everyone could throw together some archviz models and such and it would still become an optimized scene in the end, I see potential there.
I still think in a professional context it is of less use. I mean anything can be a workflow optimization depending on how bad your workflow was in the first place (no offense) but to me it sounds very similar to having one-click auto LOD for meshes and a streaming solution for runtime.
What I've seen from the unreal engine beta in terms of fps seems fine, but the file sizes from such high poly meshes would bother me. Imagine sending a billion polygon mesh to a colleague in an email or processing it in some third party tool, that wouldn't be ideal. If out of the order things like that would be counted to workflow, decently polygon-reduced meshes from the start would be easier to work with and can probably be done in any software that creates the mesh in the first place. I'd rather have ten different photogrammetry models in my game that have lost some polygon detail, instead of one that is super detailed, if that results in the same file size. But again, only because we talk about static objects, foliage would be a different story and I'm curious whether we get to see any good results from that.
If you say new things are a novel combination of old techniques optimized together, Nanite might be that, but for me it doesn't solve any problems I've had within gamedev (detail level on static objects), Lumen on the other hand and the problem of efficient global illumination, seems more of a worthwhile endeavor.

 

Okay let's go nitpicky about baking, it's baking on the mesh level, but not on the scene level, which makes it more flexible than other method. It allows for dynamic run time occlusion, that is the non deformable mesh cam move. It also allows decoupling of geometry and materials in a way similar to deferred. And ultimately it decouple lod from object toward scene. Dunno about real time creation of mesh, seems like a tree base structure that cluster fixed size length vertex buffer into a hierarchy, depends on the clustering algorithm.

Asset size isn't a problem when you consider they worked on compression of their format, and that they can skip texture details for geometric details, given that texture details is quadratic in size. And that you need to factor the lod size together too. Also nanite could be scene as a generalization, you don't need to work with high details mesh to get the sane benefit anyway. If size is an issue, use whatever decimate you need on the original mesh before exporting. Also one click is relative. For indie not having to care about huge chunk of the workflow without investing in third party or side tools is huge. Just export and the engine takes care of it.

To get the best out of lumen, you need to work on tandem with nanite. But lumen is also rather high end oriented more than nanite.

 

Whats the point when any Joe Blow amateur can just click a button and get instant AAA. This topic and graphics will be a non issue in the not too distant future.

 

nanite deep dive : http://advances.realtimerendering.com/s2021/Karis_Nanite_SIGGRAPH_Advances_2021_final.pdf

 

That's different that what I first imagined: some clever bucket-sorting of triangles by camera-relevant features like yaw/pitch/position/size to make them easy to filter.

 

Nanite in Unity would be amazing and would cut down time consuming LOD process. For lighting, it would be nice to optimize Enlighten for 8GB memory and 2GB VRAM GPUs.

 

You can grab a simplygon license and integrate it free if you're in an indie bracket, that goes rather far.

 

I feel like this thread has gone off topic and become more of a Unity vs Unreal thread than it should of. But I'm going to join in

After playing around with Unreal 5 myself I've found myself torn. Unity has nothing to compete with Nanite or Lumen. Full-stop, end of story. They do have answers to performance issues, sure. DOTS will hopefully be part of that answer, even if it's not in a usable state right now. But this comparison kinda compounds an issue that I've run into on Unity for the past year or so. They are missing a whole lot of stuff that should be standard. They don't have a proper first-party multiplayer solution. A good selection of high quality assets / materials similar to now Epic's Quixel. The many things that are missing from each of the render pipelines. Last time I checked grass on the terrains was still missing in HDRP.... These are just a few things I can think of off the top of my head, but everyone runs into a bunch of these and thinks why isn't this here.

It really is starting to feel like Unity is becoming a bare bones engine which you have to do everything yourself, while on the other hand Unreal Engine is screaming I've got everything. Blame this on Fortnite money and development adding features or whatever. But at the end of the day Unity is becoming more and more work to develop on compared to other engines (including the likes of Godot).

It kinda leaves me in this weird point. I choose to focus on Unity about 8 years ago now because it felt like it was the easiest to develop on out of the big engines of the time. Unity3D had decent selection of standard high quality (for the time) assets and was pretty feature rich. Now, 8 years later Unity is missing some of those basic features that were in the engine back then kinda boggles the mind a little.

So, even if Unity comes out with a solution to Nanite or Lumen, I think they've got much bigger issues at hand right now.
Personally, I think they need to make a definitive release. One with the features they've been promising, so that they can start building again. Unity has been going through years of changes, roadmaps and instability. It needs that stable base to build from again, not this disconnected mess where some of the "latest" features don't even work together.

 

Well, maybe it's just me, but now that Unreal is available, I'm sure the Unity team is studying Nanite. It can reverse engeneer way cheaper and faster than it took to develop it in the first place. I really think it should: Nanite sounds great. You not worrying about poly count, normal mapping, etc. and only using one drawcall to draw all the meshes; perfect transition between lods an not drawing more than you should. Obviously buying megascan so that any user can just drop the best assets on earth to the scene and have film quality in seconds, was a clever marketing idea, considering they already knew they had the tech to support it.
Still, that UE demo runs kind of slow on pretty good cards, lumen doesn't look as good on what users upload vs the UE demo (UE demos are always amazing, but always hard to reproduce), and for what I heard the demo is around 200GB. I don't even have that much free space in my machine right now LOL. I used Unreal in the past and it doesn't feel as natural to me as unity. So, I guess the idea of switching depends on what devices you are targeting. Most often I been thinking about switching to an open source solution than to Unreal. Still, this gives me seconds thoughts, obviously. Hopefully Unity will sort of catch up as it did with UE4.

 

This seems like an interesting approach as well, could be integrated in dots given surfels could be entities like structs:

 

this is also very interesting - cs rasterizer : https://tellusim.com/compute-raster/ (Unity buy this tech or create something similar )

 

We've built a proof of concept virtualized / quantized mesh renderer for Unity that is working well. We're speaking with Unity to try to buy the source so we can embed it closer to the core (we need more access than what is exposed to us right now).

 

Very cool - wish u and Unity success in this project - btw will we need the latest GPUs(like rtx 3000+ or rtx 2000+) for this to work - in another words have you tested your code on wider range of GPUs?

 

Hi, I have also been working on DenseLOD. Our approach does not rely on any fancy shader tech available in the latest DX12 Ultimate like Nanite does. This means that our approach works on every GPU which is modern enough to support HDRP.

 

Unity have been working on HLods like UE for 4 years now.
https://github.com/Unity-Technologies/AutoLOD

 

With a full year gap between commits, "working" is a bit of an overstatement
.

 

Maybe use another mesh to show off the vertex details? Can't really see the transition.