So, Nanite

I mean, they sell pixyz.

 

To be entirely honest, most Unity tools are lacking and internally an area of focus for future versions. The package manager was supposed to be a core part of solving these issues but all it's really revealed is how Unity Technologies has exceptionally long dev cycles and, to be honest, incredibly lacking quality control in a lot of cases.

 

Yes and Pixyz is a hell of a lot more than just an LOD system, that's the least of it's purpose and provides an entire pipeline for CAD users and product design that takes away a lot of the work for them.

Before the days of the package manager Unity's feature-set was much simpler. Without it we would have seen even more massive and buggier dev cycles during these past few years of major change Unity has been putting itself through.
The package manager was also meant to help reduce builds and improve editor performance by allow you to section out large parts of Unity, which it has achieved.

Unity's dev cycles feel long because they're actually public about it when they are early in progress. Whereas Unreal keeps things under wraps until they're just about ready to be used, their dev cycles are just as long if not longer due to the absolute mess their engine code is (ask any serious long-time C++ Unreal developer).

Unity has made a lot of mistakes in the past few years from exploring optimal routes and that has obviously caused delays and bugs along the way. But it's quite clear we're now starting to come out the other side of this transitionary phase as major features are finally starting to wrap up, including DOTS production release in the coming year. So I don't think it's helpful to judge the future of Unity's progression based on the past few year's, due to the unique circumstances of that major rework of so many systems. It was a rework that needed to be done to create a better foundation going forward.

 

We’ve been hearing that since Unity 5.x

I don’t believe there is anyone left at the company able to execute any sort of vision. (With the exception of the light mapping team for which I have a soft spot) All the people I respected have left Unity.

How are they going to produce good tools and features when they think Cinemachine and Timeline are good tools?

Or when they’ve (said they) made it a priority to improve editor iteration and from major version to major version it is still getting slower?

I don’t understand where this optimism comes from, that after DOTS is finished everything will fall into place because…?

 

I am well aware of the size of Unity's feature set and I have long said that a good deal of those problems are, in fact, the fault of Unity constantly chasing back of the box features for the engine. I am also well aware of software development cycles.

Another thing I am aware of, however, are things like the Terrain Tools package leaving preview but still throwing out constant errors if you try and use any of the tools without changing a particular parameter and then changing it back. I am also aware of things like ProGrids having been a preview package that has received no updates for over two years now. The same can be said for multiple preview packages.

The scriptable render pipelines shipped without having feature parity with BiRP and were said to be production ready while missing key features. I already mentioned that problem in this very thread. The major issue here is that none of these are new problems, but problems that we have been experiencing since the 5.x release cycle began, problems we can now see directly.

 

I think it would be more honest if you mention that ProGrids basically got pulled back into the engine. Practically there is no need of any update of the package.

Please help me understand, what should have been the proper procedure? Keep it secret until you think it has feature parity with the Built-In? So all of those who could use URP in the mean time wouldn't have the opportunity? All of the rest of you could use Built-In regardless.
So please, tell me, what is the negative effect here, exactly? I'm honestly asking, because in my opinion maximizing the possibilities is better than keep things under wraps and releasing things with a bang (like both Unreal and Unity did for years and everybody hated them for it, rightfully).

 

Unless you need the axis control placement, which has not been.

UT should have spent more time consulting with the community and they should have been kept in prerelease much longer instead of being released as production ready tools as early as they were. I literally said that after the part you cut off.

 

That they abandon previous features (built in in this case) and then give you replacement features that don’t really replace the old ones and go “well here you go”.

They did this with the animator and animation (with the promise that the animator will get as fast for simple cases, which it never did), they did it with with the lightmapper, enlighten wasn’t intended for fully baked and after a lot of pressure it got a half assed mode and even PLM doesn’t have feature parity with beast and they did it with built in and the SRPs.

The way to handle this is to not stop developing the old solutions until the new ones are ready, so the people who make games now are not trapped with features that cannot get anything above trivial bugfixes. But Unity does not want to do that, so they release the new features EARLY and then go “here, the replacement has arrived, you can’t complain about us stopping the development of the old feature, right, RIGHT?”. Also the new features have a tendency of never reaching parity with the old ones (maybe because they are considered “ready” early?).

 

If Unity actually listened to the community once in a while, that would be nice. Because the general impression I've been getting for past years was that most of the time community is simply ignored.

 

What do you mean under this exactly? (I tried to check pro grids documentation, there is no mention of this term, at least I haven't found it). The only thing I know haven't been implemented is the ability to show all 3 grids. Which is a shame I used it in progrids a lot, but it was a conscious decision, apparently not many people used it.

Ah, so you're angry about the label. I see. I partly see the problem, but on the other hand I also don't see that gigantic problem as it is always depicted on the forums.

Forum users != the community. And in my experience Unity is listening to the community.

Otherwise Unity would never make such utterly stupid decision as what happened to the package manager...

 

That's literally what I mean and if it's a conscious decision, the package should be deprecated, not left to languish in preview. That's literally what deprecation is for.

When URP came out of preview it didn't even have camera stacking and was called "production ready."

 

This I can agree with. But this is different, then what was mentioned at first.
(Yeah, I was complaining about the missing 3-way grid /I also loved that feature/ view when they moved the features over into the editor UI itself, they said they didn't do it because they found not many users were using it)

Also: they specifically told that camera stacking is deliberately missing, and the method to do similar effects using the scriptable part of the Scriptable Render Pipeline. Since camera stacking is not the most performant thing to put it mildly.

I guess I'm just more forgiving towards change than most of the forum-dwellers. Or I can choose the old feature over the new one if there is something I definitely need and it's not present in the new stuff.

 

Yeah, and then, after much pushback, it was added back in because

and this should not shock anyone

nobody wanted or even knew how to apply specific matrix transformations to meshes to replicate the primary functions of camera stacking, a feature that was used constantly because it was the easiest way to accomplish many things that are extremely common in games. Rather than include anything that replicated this functionality, functionality that was not the only thing missing, they stripped it out entirely and said it was ready to go.

That is a bad thing to do. That is pushing out something before making sure that the use cases of the old system were covered. That is not something that you should be doing while also claiming it is production ready. That's the problem. That's the problem that has been discussed to death about how Unity handles things.

 

The problem with URP is it's lacking even when compared to built-in, and it's been years.
When it was labeled production ready it still didn't have point light shadows, decals, light cookies, depth prepass (open world w vegetation? goodbye performance), a deferred renderer, light layers,

it still doesn't have LOD crossfade, so enjoy painful LOD popping. And no shadow cascade blending, so same thing there.

No TAA, or SSR. Worst yet SSR isn't planned or in progress, so who knows when it'll show up or if.
And of course, all assets broke, so most assets you used to make your game look good don't work on URP, so what the community relied on (the asset store) is in shambles.

Then, after all that, it still has the same limitations. Reflection probes, same limitations. most features are of the same or lower quality than built-in.

SSAO visuals aren't great, but even worse is it's performance. It is literally 3x more expensive than HDRP's SSAO, even though the former is supposed to be the fast one focused on scalability.

Then we have the shader variant issues.. and switch performance.

 

As far as I remember the recommended method to do what we used to do with camera stacking when URP first released was “uhhh, let me get back to you”.

It would be fine if there was an easy alternative on how to do something equivalent in URP and clear instructions on how to convert your existing work, but there wasn’t.

Here’s an old thread https://forum.unity.com/threads/glitching-with-multiple-cameras-lwrp.592477/

 

To be fair, in the meantime since at least a year, the vast majority of new assets are aiming at URP or HDRP.

 

Only recently did they start showing up, but the issue is that some important assets still have no replacement and URP doesn't provide an equivalent.
For example, Next-Gen Shadows.

 

I've submitted bunch of suggestions, there were no responses to almost all of those. While expecting that anyone is going to ever respond to me may be wishing for too much, the lesson that I can learn from there is that there's no point in submitting feedback and nothing is ever going to improve. For all practical purposes unity devs may be sitting at some sort of cloud where they're unable to hear voice of mere mortals.

Meaning if you see something that can be improved and point it out, you will not be heard.

https://forum.unity.com/threads/more-letters-in-two-panel-project-view.1125734/
https://forum.unity.com/threads/awful-android-build-experience.1168022/
https://forum.unity.com/threads/ugui-system-feedback.1174805/
https://forum.unity.com/threads/unable-to-use-camera-setstereoviewmatrix-in-instanced-mode.1217127/
https://forum.unity.com/threads/properly-loading-libc-_shared-so-in-app-with-native-plugins.1240987/
https://forum.unity.com/threads/improve-custom-function-workflow.1229547/
https://forum.unity.com/threads/blender-import-pipeline.1239607/

The alternative is even less performant, because you'll need to render onto a render target, then blit it, and then worry about depth test, and for the depth test you'll need a custom shader.

The point of the engine is to provide CONVENIENT method for something a user might be trying to do, even if that something is not performant.

 

In some ways, they've gone full circle with the package manager. The wild west in the beginning was a bit too nuts but they've once again over-corrected and now packages that ship with the engine are also rated for specific engine releases, making the package manager pretty much redundant.

Even if a package has no hard dependencies on the new Unity version, it's still rated only for a new release and is not available for download via package manager on older versions of the engine which forces you to update Unity to get a package bugfix. One can force the update by manually editing the manifest.json but this, of course, is not supported by Unity. And now we're back to the same pre-package manager problems.

At least it's semi decent for 3rd party stuff available via UMP.

 

Didn’t they block 3rd party stuff from hooking into the package manager?

 

I'm not well versed into tech side of package manager but stuff like OpenUPM hook into it somehow. And Install via GIT URL for correctly configured assets also adds them as full-blown packages, for example, UniTask and EsotericSoftware's Spine runtimes. Nothing 3rd party is directly available in the package manager, that's true.

 

Ekhem, I'm working with UE4 since before it was publically released in 2014 and I don't see this "absolute mess" in the engine code.
I do a lot of reading or customizing engine code, and it's usually clean and readable code. Old code is constantly refactored, i.e. rendering updated to Render Graph.

Code leftovers are obviously left as deprecated for a few engine releases, this ensures that engine upgrades are smooth as possible. (it's rarely smooth for integrating large rendering changes, as rendering changes a lot)

Even if there would be any significant, new gameplay/animation systems are usually totally new codebases, enclosed in isolated plugins. Actually, new systems tend to make engine more modular, reducing monolithic code in the core, resulting in less mess. It's easier to cut off entire systems.

The gameplay framework itself (around Player Controller) is just complex by design, due to supporting multiplayer and different control variants out of the box. I'd agree that might be judged as "mess" though if someone doesn't need all of that. Especially there was never extensive official docs on that

---------
That being said, dev cycles of any properly designed systems for general-purpose engines have to be long. If it has to work for thousands of developers on very different projects on a multitude of platforms. It also needs to be done this way that doesn't break our projects or assets, unless really necessary.

When upgrading a Unity project to a new engine release it's normal that a lot of asset references break because some system was updated. It doesn't almost happen with Unreal upgrades. They even upgraded Sequencer evaluation to ECS-style framework and users (both programmers and non-programmers) didn't even notice. I bet that requires a significant engineer's time.

Research on Nanite started a decade ago.
Niagara was first prototyped for Paragon so many years ago, but making it ready for general VFX needs took another few years. It was actually refactored a few times to meet expectations.
Chaos physics? The functional destruction demo was shown 2 years ago, it's how long takes to make the default physics engine. Although there are still areas that need as fast as PhysX 3.4.


Of course, totally agree that Epic often shows new toys once they have an impressive presentation on them.

 

The way it usually goes is that surveys like this are run by someone in marketing and then they present the results in PowerPoint format to a group of executives or high level managers and hope they will care...

 

Jokes aside, Katamari Damacy is actually a very good use case for something like Nanite. If you make heavy use of texture atlases to make different meshes share the same material, the entire world could be rendered in just a couple draw calls while keeping a large variety of meshes.

It's also a perfect fit for the "growing" mechanic: large objects like furniture and houses can be very detailed when you are small enough to walk inside them and seamlessly transition into low polygon LODs as the katamari becomes larger.

 

Thanks for the info!

 

Maybe i'm wrong but, URP was never intended to be equal to build-in

 

I mean it was, maybe not when it was named LWRP, but when it got renamed to URP, that was the intention:



But I'm interested to see how it looks from your viewpoint. If URP was never meant to replace built-in (and HDRP certainly is a completely different beast than built-in), then what can replace built-in?

If the answer is "nothing", then built-in should have never been abandoned.

 

It was/is, it's suppose to be the replacement for built-in, capable of high end graphics and scaling down

 

Meanwhile, URP also has features that are not available in BRP, e.g. decals. Since I'm a programmer, I'm not very well versed in this area, and I don't know what features are still missing.

 

Equal is an impossible word in programmer circles, but I take you to mean equal in intents and purposes, in which case Unity has repeatedly communicated that URP will eventually be replacing Built-in.

It is the replacement and covers the feature set of Built-in, just URP-ified (equal intents and purposes). It's actually already past Built-in if you want to count features.

The people struggling are the people who prefer to code in surface shaders or people porting with the same settings (even though it's effectively a different engine).

Sorry I replied to an oldie like you with the obvious like this, but just making it clear for readers who might not be realising Unity's intent.


--- General thoughts ---

Some things URP is plain better at that Built-in doesn't do natively (check roadmaps for more):

• Application Spacewarp / VR optimisations
• Various spot-optimisations for hardware (awareness)
• Decals / Flares
• Forward+ rendering
• Cached realtime shadows
• Greatly, massively increased perf with hybrid renderer*

* Hybrid Renderer isn't something you need ECS or fancy code for. You can still integrate it and let it render most of your game in subscenes with streaming, brand new dynamic culling and absolutely jaw dropping performance.

Really, forget Built-in on any new games you're planning and remember DOTS is not all or nothing but now a proper citizen that you can take from what you need without the baggage you don't.

 

Dylan Browne on Twitter: "Apparently Nanite is not only working (kind of) with WPO it also seems to be working with masked materials now as well! Not sure when this made it into the engine but this is exciting! Look its a moving Nanite Tree! #UnrealEngine #UnrealEngine5 #UE5 #Shader #Gamedev https://t.co/mS7A2fXnAb" / Twitter Seems like nanite now supports vegetation...

 

Are you posting from the future? Cached shadows for URP is still "under consideration", forward+ is still in development with no ETA, and hybrid rendering does have a hard dependency on the ECS package and the convoluted GameObject conversion pipeline, which is still firmly in the experimental purgatory (plus it requires compute shaders, so it's no good for low end mobile).

Also, the shader variants explosion is still a big problem with URP. There are regular threads over the Nintendo forums with devs having nasty issues getting their URP games to work properly on Switch.

 

I am unfortunately posting from the future. You will probably get this stuff at the end of the year or when it is done (tm). You are demonstrating you haven't used entities 0.50.

I simply selected some scene object, right clicked and converted to subscene. It was then streaming with all the goodies.

That does not seem convoluted to me.

Dependencies aren't a problem. Regular UnityEngine still has plenty that you don't use but would like gone also.

 

Glad to hear the conversion process has improved. But I still don't like having to depend on a very experimental package that isn't even fully compatible with the latest LTS.

 

Ok. i thought URP was intented for low-end hardware like phones and switch for example...

 

I agree. But really it's 1.0 in progress, has 1.0 features. It's 0.50 release is because they wanted to bail out people stuck on 2020 LTS, and also unblock releases again, so it's looking pretty good. I'm in full investigation mode these days with it. The biggest problem it has is probably documentation at this point.

DOTS is already mature: Jobs and Burst have been ready since 2018, and form most of what DOTS is. ECS is not required for that stuff as you know.

Yeah but it scales these days. Back in LWRP days it was for lightweight projects.

 

"Maybe i'm wrong but, URP was never intended to be equal to build-in"

Well that wasn't the impression given years ago, can think of a few third party assets that went with URP because that was meant to be the equivalent to built in.. only years later it still isn't feature complete with built in.. if it is, bugs and regressions.. I'm wondering when it will support proper shadows and transparency as Built in did..

https://forum.unity.com/threads/urp...-even-supported-anymore.1045252/#post-7015153

"Meanwhile, URP also has features that are not available in BRP, e.g. decals. Since I'm a programmer, I'm not very well versed in this area, and I don't know what features are still missing. "

half dozen assets for decals with built in.. some still better than the URP decals.

Problem with URP/HDRP nonsense is the this new theme of assets package updates and constant upgrade costs to support newer versions, where they still don't actually get things working for an LTS you can stay on because every improvement roadmap is stretched out across bloody years or gets delayed.. or something doesn't get back ported. Frankly the render pipeline splitup and the mess caused by that in asset packages not always supporting a render pipeline out of 3 different versions just leaves alot of mess to do deal with on top of the already janky useless package manager system and the broken way that still works.

I would literally have cut my losses with Unity and ditched it for UE if it wasn't for the preference to use C#... at this point I'd say the only thing working in Unity's favour is UE5 never just supported C# as scripting engine alternative to blueprints. While Cryengine, Godot and Unigine may someday be good alternatives, for now I'm pretty much tired of the nonsense updates Unity makes. It's just a lot more apparent the slow progress with URP/HDRP year on year and asset upgrades that are tied to that nonsense more now than ever before... not even getting into other areas of the engine/editor that just leave one wondering wth is going on or not going on I should say

 

Yeah but see, you're just looking for greener grass because Unity made a pigs ear of communicating what they were doing, and how far along they were in progress. This means you got caught between a rock and a hard place. Many of us did, and that's 100% Unity's fault.

But doesn't make modern URP bad. Esp paired with hybrid. I love what I'm doing with this stuff, today.

 

so does this improve performance and perform the BRG and GPU culling out of the box???

 

Jobs and Burst are, by far, the best thing Unity did since surface shaders, and I routinely use both to get Unity ports to run at all on consoles without having to resort to offloading logic to native plugins as in the old days.

Unfortunately it's the furthest thing from a "free performance boost" as it can be as it does take skill, experience, and time to refactor code to take advantage of it. It also has a hard limit whenever the thing you want to do involves manipulating game objects and components.

 

There is a new video from that guy who is making something similar to nanite in unity, looks very cool but i want to know, is this real? fake?
I do not why but i think is fake, he is also making some tests on phones! that is why i think is fake, but it looks very cool

 

it runs on mobile because its not nanite its something similar to it !!

 

Virtual Geometry techniques are not that slow and will probably have a place in most engines along with Virtual Texturing.

But Lumen is probably the framerate killer for most, along with object management still, and that is not demonstrated on mobile phones.

 

That is literally what i said XD

 

The unity demo of Nanite like is probably only part of the tech, not te whole stack.

Also the stated purpose of Nanite wasn't performance per see, it was workflow improvement, like don't spend time authoring or checking automatic lod with round trip in 3 different DCC, just drop yo Zbrush and the free quixel we gave you and we'll handle it like a pro. Ie stop caring about mesh and polycount and do your damn work. "Performance" is incidental to that (ie gobble million polygon like a champ).

On the hand the problem of unity can be sum up as "overpromised, underdelivered", they are basically making demo for themselves, not for a market vision, Enemy is pretty, but how do you see yourself using that in your project vs metahuman? Epic had the nerve to drop "democratizing game dev" in their engine presentation. They are going for the jugular. They have unity to thanks for becoming that competitive.

 

I'm firmly in the camp that Unity needs to really get good with the CPU side of things. From there, improvement will flow.

 

They don't position Enemies as MetaHuman alternative though. People assume that all over the place but it's likely targeted at non-gamedev industries where Unity is now growing the fastest like film and visualisation. In which case, it's likely reaching the intended audience and is effective for its purpose.

Unity are increasingly positioning the engine as a real time platform for just about everything, not just games. So not everything that comes along is in direct competition with Unreal engine. Unity are doing their own thing.

 

I remember that video, was a good surprise when they dropped that
If I remember there were a few videos that dropped that line, only could find one though.

 

i do not understand why everybody thinks enemy is an alternative to metahuman.
Yes unity is growing in those areas but for me enemies is more targeted to AAA game devs.

Yes i think the same in fact for me is very obvious but is also obvious that Unity team is listening to the community when we ask for something based on what we saw in UE (sorry for my english)

 

Unity attempting to break into the AAA space is just more of Unity trying to be everything to everyone with no real focus in any real way that benefits the people who actually use the engine, instead attempting to chase more and more people outside of that space. It just makes the engine more of a sloppy mess.