So, Nanite

Today Epic announced a system that can render a near unlimited number of micropolygons that will blow all other render engines out of the water - is there going to be an alternative solution coming to Unity?

 

Good question. This new Unreal Tech is insane...

 

Considering there new pricing strategy and these new features, I really hope unity has something up their sleeve, I really like using unity but this demo really looked next-gen, and unity always has been catching up to unreal engine,well, the gap just increased by a lot for us, and even the new DOTS framework is far from being stable right now

 

Yeah, they bought Bolt and then continued to charge for it!

Checkmate!

 

Don't forget they also bumped the subscription prices ;D

 

Yea i don't wan't to learn C++ xD Hope Unity catches up Unreal.

 

I actually quite like C++, it's just the UE4 API I find horrible.

 

Also their global illumination realtime bounce lighting, lighting in Unity is slow and cumbersome and still not able to do as good a job as Unreal. Watching that tech vid is making me reconsider investing time and money into Unity's HDRP system...which is still miles off. Not too mention quixel megascans library would be handy

 

Please calm down and wait until testing the actual release in 2021. Do not run into every PR speaking. (At the same time that also applies to Unity.) But nevertheless:

It's true HDRP lacks a modern Realtime GI at the moment. Atleast there is a new branch on GitHub for a Screen Space GI approach for HDRP.
Also, Unity has access to the same hardware realtime raytracing tech as Epic has, so why not ...
But you're right that Unity is slow and late regarding that point. But atleast they offered Enlighten for free since years when Unreal did not!

I don't see why Unity will be not able to render the exact same amount of polygons. I mean Unity already has heavy instancing with the Hybrid renderer, the tech is proved with the "Mega City" demo. Also the quality heavily depends on the assets. So with the same mega scans assets, you will probably achieve and equal look. But can you made them or pay for them yourselves? Unity already prove with "Book of the Dead" that they can handle mega scans ...
Also megascans from "Book of the Dead" are free to use. It was a study on a realistic forest. So yes, no fancy temple assets because it was not the demo's theme.

Nevertheless, Unreal are tied to the same limits of user hardware and current state of art as any other game engine in the solar system, so please do not overreact. Fast react time and high quality bounce GI will require an expensive hardware setup. Probably Unity got access from Sony to the same API tech for PS5 as Epic already has ...
Unity rasied the subscription by 5$, probably they need money to invest in the high demanding user base requesting high quality features but at the same time, everybody is ranting about the higher asked price. But you know, features cannot be developed by air and love, they need money.

Obviously Epic has the money, for pumping everything into expensive scanned assets. It's because they charge you 5% of your earnings you know and they are lucky by milking Fortnite. So somebody has to pay for the costs of free high quality assets and overworked graphics and lighting developers. Are Unity devs willing to pay in order Unity can invest more? Probably most of the user base want to have many as free as possible ...

While I like the demo from Unreal 5, it's nothing new. Already showed by the Uncharted series (Naughty Engine !) and Havok Physics (which you can also use in Unity). So they pushed the graphics, because PS5 can do with realtime raytracing cores and faster speed due to SSD, so what?

Sorry guys, some posts are just PR advertisement without any arguments. Are you even real developers capable of an argument based discussion?

 

Regarding realtime GI, look at what just popped up on the HDRP repository:



More details on the implementation in this commit:
https://github.com/Unity-Technologies/Graphics/commit/997cfabcb91c390a0387323816edc1b3bdb6b043

Seems like it'll be ready soon. But we have to see how much of an "initial implementation" it is

 

They had a screenshot of the SSGI in the previous srp repo.

 

I do hope it handles bounce/ambient light better than that, and not just emissive light, but yeah this pic is most likely from a much earlier version. Or maybe the picture doesn't show it properly enough... but some of those darker areas look pitch black

 

GI:
The unreal solution is an hybrid of voxel based tracing for large scale, distance field for medium scale and screen space for details, basically a combination of all technique they used so far (vxgi, distance field ambient and shadow, ssgi). According to the eurogamer interview that is. Unity would need some tooling to catch up, especially non rtx like updating and sign distance field.

Nanite:
It's probably using Geometry image as per the Brian Karis blog, which allow for virtualization in the form of sparse texture, so there is no (traditional vertice based) mesh, it's images, and the eurogamer interview tells you it's a SOFTWARE RASTERIZATION done in compute, unity won't have that for a while because that mean changing the whole pipeline.

There is a lot we can infer from that, in how it's done, it mean they probably unified the whole structure, as the voxel is probably octree used to serve the virtual paging, occlusion culling, GI, etc ... Ie each leaf contain a distance field and a geometric image.

For the rasterization they probably sort data as screen tile sorted front to back, which mean they can use the voxel octree to just serve a list of potential image geometric patch, then reading the geometric image, they can discard per pixel backfacing and frustum culling, and have a cache that keep track of tile coverage to stop patch processing when it's fully covered on screen.

Mesh are automatically LOD by subsampling the geometric image, and since it's using a virtual paging, only the right size of image is served at the right distance. It's also bypassing the inefficiency of small triangle per pixel that plague hardware rasterizer.

 

Evidently not...apparently. I suppose anybody who dares to come into the Unity Forum to casually discuss issues can expect a near instantaneous snide, condescending reply. I guess all the issues we thought we were having...like terrain not having any detail shaders for grass/foliage or needing to buy 3rd party assets to have any chance at baking a complex light map under 12 hours, dont exist or we are just too amateur to understand that they aren't problems at all.

Your point about Mega-City and the future of ECS/DOTS and HDRP's 'poly' count limit is relevant, so is the SSGI ...however none of these are as ready of production or stable as Unreal's and a few people are getting tired/concerned that Unity will not be giving these the attention desired or that they may never eventuate at all. In which case, there will reach a point where no amount of store bought assets or subscriptions would beat Epics 5% type policy.

The irony of making a PR post in a forum where everybody clearly already likes and uses Unity over Unreal currently is pretty dense.
Did you have anything you wanted to discuss regarding Nanite/Unreal tech...or did you just want to insult their user-base?

 

That is quite interesting! I will have to check that out in more detail.

 

Hmm yeah, but i don't think you can get much from a screen space technique

 

By production ready you mean YOU have already gone in production with Unreal 5 and PS5? I like to see your production ready result with that ...
I also like to see your not production ready result you got with Hybrid Rendering.
My problem is, when you blaming one engine and advertising another engine with no valid tech arguments is not casual talk. Users come here because they expect a discussion to get some value that is helping them with game development. What is then the point of the discussion? Spread some lies that Unity sucks? No way.

I highly doubt a constantly 5% fee is way cheaper than buying an Unity subscription. Also buying assets heavily depends on the studio and the skills of their team. You know there are a lot of skilled devs around that are capable of making their own features and assets. So unless you have a valid example of a game studio saved money from switching from Unity to Unreal. I cannot stand advertisement from Epic trying to lure devs into their fee policy. It can be a great financial risk.

You basically answered yourself. If they like their engine, they probably just be in their forum and just develop their games instead of making false comparisons on another game engine's board. And yes, I did, by mentioning the arguments above.

 

I think SSGI can work pretty well, but the main limitation being that if you're in a room illuminated solely by a very bright emissive red neon sign, and you look away, suddenly there's no more light in the room. Probably best to use it in more evenly-lit scenes, or at least scenes that have actual lights and not just emissive materials

 

You do realize Epic just changed the UE licensing to be 100% free for the first $1million in gross revenues for the title. After that you pay 5% for amount that goes over 1 mil. You need to have a really big hit to get to a point with this model where Unity is actually cheaper

 

As for SSGI, Unreal recently added this feature as well.

 

Again, how did you want to know without made ever a product with Unity HDRP and Unreal 5 on a PS5?
You basically just saying Unreal 5 is better without any valid experience and valid comparison test. Again, unprofessional and it will nobody help to decide which engine to use. It just makes false promises luring people from Unity to Unreal. That's my problem with your kind of posts. Therefore I tried to give an overview about the actual state of Unity that is not as simple to say: "So we have Unreal 5, now what?".

But I get the point that some users are actually not interesting in exchanging knowledge about game development and tech at all. Only because HDRP did not worked for you. But guess it worked for others.

 

There's always issues with hype train. For UE5 features I'd suggest people to wait till they actually get their hands on the product and see how well they work.

 

Thanks, that is basically what I suggest about features of EVERY engine. Epic had also false promises about their new Realtime GI in Unreal 4 (Light propagation volume). So yes, we wait how the new Unity GI will work and then we can compare to Unreal 5. Then we have valid data to compare and decide.

In a video trailer, every looks great and sounds like "It's working, let's do it!".

About the new license model. You basically get it "for free" because of the reasons I mentioned above. They took the money milked from children playing Fortnite and the money milked from game studios with the old license. So yes, somebody paid for it. Some people will save money because some people lost the money, sounds not so great for me. It's not as easy as writing "Unreal 5 will be free". Also, don't you think it's too easy to say "Now we are the engine with the best price". Because they just released their new license and surprised the market. Other engine now need time to adjust their prices as a reaction. But you're right, that Unity did not milked so much money as Epic.

 

It's not this black and white though. I hate overpriced microtransactions as well but then again, Unity enables this type of market way more aggressively than Epic does.

This is kinda pointless argument here, a ton of people and companies have paid for Unity too in past and still pay for it. Unity even charges for dark editor theme in year 2020.

You try to frame Epic as some grand evil here. Whether you like Epic or not has nothing to do with this discussion.

 

While Unity makes their money from milking kids with the asset store and tutorials.

I’ve also heard Unity’s engine monetization strategy is called internally “PAY ME, OR I’LL TELL EVERYONE YOU’RE USING UNITY”, working title “NICE GAME YOU GOT THERE, IT WOULD BE A SHAME IF PEOPLE KNEW YOU WERE USING *whispers* UNITY”

As such, the next steps are obviously:

-Make the forced splash screen even uglier, force it for at least 10 seconds
-Have it write “we’re sorry the developers of this game are such cheapskates and are making you wait”.
-Then quadruple sub prices...

They’ll make billions.

 

Megacity was just using existing instancing api's there was nothing special about the rendering there at all. It was the whole being able to move so many things around efficiently using DOTS.

The only real change in instancing is SRP batcher which megacity wasn't using. Which optimizes the cpu/gpu pipeline. But what it does precisely is nothing new, it's basically playing catchup to where AAA has already been for years. And most of that you could already do with instanced indirect, although there is some new compute buffer uploads that are faster in 2020.1. It also simplifies culling via BatchRendererGroup where you can now handle it in jobs instead of on the gpu, which works pretty well until you hit lol scales.

 

Please remain civil when enquiring about feature requests!

I am sure the HDRP team (some of the most talented people I have ever, ever read) do know how nanite works. In fact just a year ago I chatted on these forums with them about per tri culling via compute and other means - exotic stuff you know... and of course Seb already know about these techniques!

He probably even had optimisations in mind and similar ideas. But time is the enemy of us all.


(HDRP is still my favourite renderer though I am definitely going to check out nanite like everyone else here)

 

Many of curious users tagged @SebLagarde in various forum posts about technologies unity will use on different areas like water, cloud, or whatever unreal technologies used to render millions of poligons. However, As far as I can see Sebatian Lagarde only replies to bug threads. İt is really bad and I should criticize him in this manner. Please everybody respects your opions on graphics and wants some answers from you...

 

I'm so very much looking forward to rasterize and compress a few trillion tris on my ~2013-or-so i7, which I'm still happily using. In fact, I think I'll start stashing ssds right now to set up a raid4 to test.

Heck, I'll start saving up money too, because Epic will be charging for the compute servers, should I decide to use my trusted i7 for the few months while it's processing my test scene, which, in fact I plan to capture this very summer, byt spending it in the forests, taking some half a million photos or so.

Meanwhile, I still have no idea how people keep making money off some low poly styled games that probably took a few months for a tiny team to make. When my nanite game comes out in 2030, it's gonna subdivide those to dust!

 

Can you get some for me too? Collaborate is checking for changes for 3 minutes every 10 minutes and by the time UE5 gets out, I think it will be something like 9 and a half minutes every 10 minutes, so maybe if I throw a ton of hardware at it I can get a few extra seconds of work every 10 minutes.

 

And what started happening - it doesn't support Commodore 64, 2070 Super - minimum, NVMe SSD - minimum etc. etc. At the release time, it may be will require quantum PC as a minimum, maybe you will need to buy some company which own render farm...
https://www.tweaktown.com/news/7257...MrzUTWaBhWqxW1AYSdXjcRyLZyE-1vJF1QmFY2zQnvwuo

 

Can you explain how can you like C++ specially compered to C# i really wan't to understand your point of view on C# vs C++?

 

Biggest diff between unity c# and unreal c++ is that you have to use headers and pointers for almost everything. And compile times.

One major thing that UE4 c++ programmers tend to complain a lot is the UE4's macros, but I don't honestly see that as an issue. They are there to reduce boilerplate and Unity actually have similar kinds of codegen on new systems. I'm all for less boilerplate in general and in UE4, you learn the macro usage quite quickly still.

Unreals c++ api docs however... they are really bad, always been. They cover the very basics but it's this same common issue with autogenerated docs we see everywhere now - including most new Unity's packages scripting api docs (which are mostly 100% useless if you need to figure out how to use the thing).

 

I like the the amount of control over everything you get with C++ that you don't get with C#, from whether you want to pass something by reference or by value, down to how you want to handle moving or copying objects and what should happen when an object goes out of scope, plus templates. Generics are great for fast iteration because they allow for quicker build times, but templates are a zero-cost abstraction. This makes a lot of sense performance-wise even if it is a pain for recompiles.

That said, I do like C#, probably mostly because it feels so C++ inspired, it's like a way better version of Java (from allowing for custom stack objects to allowing function overrides).

 

Yeah, the macros are a bit annoying but I'd say it's mostly down to the bad API documentation and that their naming convention smells ever so slightly of the Hungarian notation, plus, well, it feels a bit verbose really, and needlessly so.

 

I also doubt UE5 lets users get rid of old naming baggage.. Like F prefix (used to indicate float type). Now we also see things like FVector2D, FVector, FVector4 which are Vector 2, 3 and 4 using floats. If we use their integer variants, they would be FIntPoint, FIntVector, FIntVector4 for int 2, 3 and 4 vectors .

 

Unity, please add a Nanite-like system to the roadmap, the time saving and visual quality increase are just too good not to have.

 

Unity's added a lot of stuff. Maybe it would be nice to finish things. Unity also removed stuff but then added it back again like Enlighten.

I don't think Unity should be your focus if you're interested in what nanite is actually solving, because Unity requires a finished DOTS to even manage that kind of data. Then there's the entire toolchain that will be required to use it and documentation.

It's suicide for users and the company to chase something that's been effectively, 10 years in development from their competitors.

 

Well, first we'll have to take a look at their roadmap talk this year to see what they have internally planned for next year, most probably it's going to be DOTS related because if it's not DOTS is going to lose a lot of momentum and developers developing using it IMO

 

Has any of their roadmaps panned out? Last year they talked about faster iteration and stability and not much has changed on that front.

DOTS stuff feel at least a couple of years away from anything resembling “ready”.

 

If we talking in term of graphics and visual i would prefer they working on HDRP performance improvement and stability, and for new features i prefer if they would work on Probe Volume, maybe next they make it realtime update, who knows ¯\_(ツ)_/¯

 

That's especially true if they are aiming to make it the default way to use unity and make it as intuitive as MonoBehaviors.

 

A lot of the problems with HDRP are not HDRP team's fault. It's because it was bolted onto an engine that was not designed for it, and they were told to support legacy stuff / backward compatibility even mid-dev, so the HDRP team have their hands tied in many ways.

The staff working on that are 10/10 though.

 

I don't have any interest in coding in dots the way it looks right now. The reason for this is because it's just unfinished and lacks supporting features, components and so on that it does need for someone to invest years of their lives in making a game in.

So I would prefer the tech just speed up existing Unity where possible, and I will remain with C# classic until such a day it's rational to code in, for my situation.

 

you mean like it's still piggybacking legacy render pipeline and components?

 

Surprised nobody brought up in here that Nvidia had already showed off a similarly performing system many years ago that became part of the D3D12_2 and Vulkan spec recently, called a Mesh Shader (and intrinsics and hardware features that come along with that).

Going down this route would open up a lot more freedom for technical artists in Unity versus the more custom solution that Nanite is. The main downside being it's only supported on Turing/RDNA2 and up and current gen Xbox (and sort of PS5 through their custom implementation).

So, potential HDRP feature candidate for the nearish future I'd hope.

 

Quite interesting that a lot of people were like "meh, no, it has nothing to do with mesh shaders, nanite is a completely different tech" while so far it looks like the closest thing to mesh shaders. Chunks of geometry seem to be streamed swapped and occluded very similarly to meshlets in mesh shaders.

 

That it may be, but the authoring itself is the most exciting part. We get to build without consequence and the consequences of that will translate to incredibly rich environments from small teams.

 

This. . . it mostly on the workflow

 

Why does everyone talk about DOTS in this context? Isn't DOTS just for efficient computing and not for rendering high-res geometry?