So, Nanite

XYZ originate from cartesian coordinate system and that one predates first computers by about 3 hundred years. So it is reasonable enough idea to use concepts that has been around for centuries instead of boldly inventing your own for no good reason.

"i" likely stands for "iterator".

You know, like coding standards. Otherwise we could also take all letters of english alphabet and replace them with emojis, for example. Because those were also arbitrarily chosen.

There is also ijk when dealing with quaternions, but that one's a bit different as it refers to imaginary number algebra specifically and not pure coordinates.

Spoiler

ijk comes with specific multiplication rules.
i^2 = j^2 = k^2 = ijk = -1

So it makes sense to use ijk when you want those rules to apply, as normal xyz notation is not subject to them.

*sighs*

The car is pointing east. And not north.

The point is that the engine is supposed to be comfortable to use and shouldn't needlessly break away from convention just for the heck of it. Unity is comfortable after past coding experience with DirectX/OpenGL. Unreal isn't.

 

It takes like five minutes of getting used to and some mild stumbling at most for me. All my internal stuff is X+ right, Y+ up, Z+ forward but that's just personal preference more than anything. Origin starts at bottom left as god intended.

But I can adapt pretty quick. Blender being a core part of my workflow makes it pretty trivial.

 

8 bit scanline crowd says hi.

 

Exactly. Though, I always thought the reason was simply because we naturally move forward & backward more than we do left & right, and we naturally move left & right more than we do up & down, so, alphabetically, it would be x, y, z; this makes sense for 2D, as well.

 

This is a thread about Nanite, right?

Just checkin', don't mind me.

 

You know they've changed, right? And in a lot less than 300 years. Once upon a time we kept variable names short, with single letter variable names common all over the place, for reasons which were decent enough at the time. These days, aside from some fairly specific cases, it's not only common but regularly encouraged to have variable names which are multiple words in length. And that's good, because it helps us to understand what's going on more easily.

My suggestion was to apply exactly the same thinking here. People will endlessly debate what x and y and z should each mean. Despite the fact that they're arbitrary many people are highly attached to specific mappings, for whatever reason. "It was ok 300 years ago" is not a good reason to keep doing something today. "Lots of people are used to it" would be a good argument, if not for the equally as valid counter-argument of "lots of people aren't, otherwise we wouldn't be having this conversation".

Zero people would be confused if we just called a spade a spade. And I understand why we don't (the cost of change in any established ecosystem would be far more than the cost of change in the individuals who use it), but pretending that there's any other reason to keep things how they are is fooling yourself.

If we willfully ignore the half of your example where it is pointing in other directions, yes, it is.

I don't think it does. That engine has been around for a long time, and I hazard a guess that it either stuck to the convention from some other tool in use when it was first being made, or there wasn't a convention to follow because OpenGL / Direct3D hadn't successfully imposed de-facto standards at that time.

Obviously it's very important that Nanite's internal data representations adhere to some specific interpretation of an arbitrary mapping from 300 years ago. Things just wouldn't be right, otherwise!

 

That means it makes sense to change unreal coordinate system. After all, things change and are supposed to improve, therefore there's no means to stick with legacy uncommon convention from the olden days of early unreal.

In no particular order:
* 3dsmax back in the day allowed user to select their coordinate system.
* The issue with unreal convention is that everywhere x-axis normally is pointing RIGHT, regardless of how everything else is going. 3dsmax, blender, maya, directx, opengl, doesn't matter. unreal is the only one with x forward.
* both OpenGL and DirectX predate unreal engine. OpenGL is the oldest one.
* The point of any changes is to solve some problem. Renaming axes to arbitrary names, like you proposed, does not solve anything, and instead makes it harder to communicate with everybody else who does not follow the convention you invented.

Spoiler

This is probably a reason why common lisp never took off, as every programmer was inventing a dialect.

* Both of your examples feel a lot like strawmen, which is unlike you. Is everything alright?

 

To quote Tim Sweeney, "Sorry y’all I was young and this coordinate system stuff was confusing".

https://twitter.com/TimSweeneyEpic/status/952661474501111808?s=20

Unreal Engine development started in 1995. DirectX was released in September 1995 but Direct3D wasn't released until June 1996.

https://en.wikipedia.org/wiki/Unreal_Engine#First_generation
https://en.wikipedia.org/wiki/DirectX#Version_history

We wouldn't need to pick arbitrary names though because we already have names for them: height, width, and depth.

 

To steer the thread back on topic, here's a stylized indie game in development that uses both Nanite & Lumen: https://www.indiedb.com/games/under-a-rock. They said using Nanite "is a blessing" and that it "makes it possible to have a procedural open world with amazing view distance," and mention they have no more bugs that come with view distance limits.


One thing to consider is that this game allows players to build their own bases, so the engine has to be able to handle user-generated content, too.

 

Arbitrary? I'm suggesting calling right... "r[ight]", and up... "u[p]", and forwards... "f[orward]". Given that this is for use in APIs which are already otherwise written in English this is literally as non-arbitrary as it can get.

But also, to clarify, I'm not suggesting that we go ahead and do this now. I'm suggesting that if these things were written afresh now that would be the ideal way to go. Per the first response to Tim Sweeny's post linked by @Ryiah, the technical debt of the change would be crazy. I think the actual cost of an individual changing between environments may, in fact, be less than the cost of this for-fun conversation.

OpenGL does, and was said to be a nightmare to work with at the time because there wasn't standardisation or quality control in the supporting drivers. Unreal itself was initially developed with software rendering, and its development predates the release of Direct3D, which is the relevant part of DirectX. And it would have taken quite some time after that for it to have set a de-facto standard.

There's probably some misinterpretation somewhere, possibly by me. I'm good, thanks for asking, that's kind of you.

 

It's amazing to get this beautiful image without baking or messy settings.
Also, the beauty of antialiasing is often overlooked.

 

I read some articles that this system has major limitations, which of course they would not showcase, so seems like a bit experimental thing right now.

 

Source?

 

to me the biggest problem in game development is, "where should I focus?" as far as i can tell from watching many gdc presentations and reading post mortems, this seems to be the universal problem big and small developers face. only thing changes is scale.

if somebody is talking to me about winding orders and graphics engineer problems i just tune it out because that stuff has nothing to do with problems standing between now and finished game.
maybe it is a problem that naughty dog is having when they are pushing things to the limit for their next blockbluster but i dont think its a problem i will ever face or should ever face. If it is a problem for me, i'd take a hard look at if i am not trying to do things beyond scope of an indie developer.

in every software blue means up so why do i care what letter they assign it? Doesn't matter. if i import a thing and there is a problem then i adjust some checkboxes in the importer. Why would i spend any more time than needed to google the import options on a problem like that?

 

Wow, this looks amazing! Definetly giving me more hope in using Nanite for non hyper-realistic environments and something more toon-stylized.

 

there is also experimental build with nanite trees out now too

 

Some of us don't make games where we can arbitrarily decide to can certain calculations because they are too hard to figure out. If you really want to master your craft you should specifically know why gimbal lock occurs, how inverse kinematics is calculated and why orthogonally rotating a clients complex model to match the coordinate system is a royal PITA. Even in architectural models Z often points north allowing calculations to be made so that a directional light acting a a sun can produce proper shadowing for the architectural project. You might think..lemme just rotate this one axis positive by 90 degrees and yer good to go..Then you see the other two axes went to -90. Go ahead.. just add or subtract that 90 degrees and think yer good to go.

 

i know about gimbal lock and Ik. i just don't have problems working with it in any of the software i've used. these are problems solved by checkboxes. if i can get aroudn them with a few months of dev experience why should it be a bother for somebody with 20x more experience

 

this is so many words to just say, "old dog doesn't want to learn new tricks."

thats fine. dont see how its something worth arguing over. why quote my post which is an obvious, silly joke to bring up a needless off topic argument?

 

and who is paying for that time? master my craft means sell games, no get confused over a problem people already solved and is a 10 minute google search away

even if the engine doesn't include an easy-mode checkbox for conversions, it is known math. you can just look it up, plug in the numbers. if you spend less energy patting yourself on the back, you'll have more energy to do that sort of thing and keep being productive.

 

If only quaternion operations existed. Alas.

 

You don't get it. You cannot just pat yourself on the back and be done with it. If you know how something works, when it breaks you can ask the right questions. Yeah..and gimbal lock is not a problem..until it is. How did two joints become one or why the hell is the leg spinning in circles wth every step. As to who is paying for your time. You. If it only takes ten minutes to expand your ability to create and control game mechanics you would figure someone touting the word master and big time as a handle would have been on that like a duck on a june bug. Mind you, my ability to parse what drives the mindsets in this era to adopt their peculiar stances and acquisitions to decorate their personas with is well beyond this old school veteran to fathom.

 

that doesn't make any sense home dawg.

 

They do. If you use the Unity API they are expecting Z forward and Y up with many of their quaternion operations/helper methods. So if you want to make use of the API and not have a bunch of non-inspectable matrix math it really helps the time budget to have the axes coordinate systems synched. Knowing for example how the Quaternion LookRotation method works will assist you in avoiding dividing by zero and breaking the simulation.

 

"Coordinate systems are just so HARD" sure is a thing to read in a thread that is literally about managing the position and direction of millions of pixel sized polygons and the import process that generates the engine level data. It's like complaining about the direction of an automatic gear shift.

 

Unity implements quaternion multiplication, conjugation, slerp and sandwich product for rotating vectors via quaternions.
There are also helper functions for angleaxis conversion, lookat, rotate towards, etc.
That's pretty much everything you'd need.

Some animation curves are stored as quaternions, and rotations are stored as quaternions internally.

Now (AFAIK), for some bizarre reason built in unity animation editor does not expose quaternion curves to editor and insists on animating rotations (in clips created in unity editor) via euler angles only, which is insanity. But aside from that everything you'd need to use quaternions is in place.

You'll also want quaternions is you need to smooth jittery rotation data, for example.
https://forum.unity.com/threads/solved-quaternion-smooth-rotation.325444/#post-7863415

 

Ok, this hasn't been on topic in a while. Please keep it on the topic or we'll close the thread.

 

Well I dont use the system either to bring super high poly stuff to the scene, for me it just serves as a great seamless lod system. Epic says that actually if stuff can be converted to nanite...you should nanite

 

Nanite does have major limitations but it's still very much the case that you should be using it.

 

Thank you, thats good to know!

 

Would it be possible to use Burst to create something like Nanite streaming ?

 

Also it doubles as an automatic occlusion system for all nanite mesh, like nothing behind your mesh is send. So the benefits are multiples.

 

I just watch a recent Unite where they touch this issue.

See for yourself

 

Interesting, but would it be possible for gameobjects ? Burst and rendering would be in background.

 

Only limitations I can think of is it doesn't support deformable meshes (so rigged animations etc cannot be converted to nanite), doesn't support transparency (no transparent materials etc) and doesn't support older consoles like the Nintendo Switch (I think they recently added support for this?) and no support for mobiles (yet?).

 

As for transparent and alpha thingies, ppl test builds from dev branch having trees and foliage nanitized. There is also build with nanite terrain . So I guess by 5.2 or 5.3 most of the important things will be nanitized

 

Mobile support is unlikely for several years. One of the core benefits of nanite is the visibility buffer + screen-space materials, which only really works with deferred rendering and is something that is really bad on mobile GPUs and will continue being for quite a long time since memory bandwidth on mobile is usually the scarcest resource and increases very slowly over the years. Also, compute shader pipelines are still slower than pure graphics pipelines on most mobile GPUs.

 

Even if not, who cares? Complaints about the limitations are a classic case "perfect is the enemy of good".

It'll drastically optimise a huge amount of what's on screen at a given time for a trivially tiny development cost, but people are talking it down because it doesn't currently get the remainder. It's silly. The stuff it will do for you saves time you can spend on the rest of it.

 

Is there any chance Unity will hire this guy (https://www.indiegogo.com/projects/the-unity-improver-nano-tech/#/updates/all) and give him a team to work on nano-tech?

 

He said on his last video he'd rather not be hired, but of course everyone has their price.

Sadly though I doubt many people at Unity even know about this. Instead of improving the engine they'd rather spend millions on some "service" that no one will use and get shut down within 2 years.

 

Improving the engine is more than just slapping random features in. In fact, slapping more features in is the last thing Unity needs. Slapping more features in has caused more problems than it's solved.

 

What?

 

What about this is confusing? Unity doesn't need new features, Unity needs the features it has now to be brought up to proper functionality. URP and HDRP still suffer from numerous issues; some things have been in preview for ages without getting updates for months, sometimes years; Terrain Tools actually came out of preview while throwing errors if you tried to use them; Unity is full to the brim with examples of things like this.

There are too many things in the engine that are incomplete or buggy to go "you know what it needs? MORE STUFF."

 

It needs more stuff and previous stuff fixed.

 

I thought Nanite was mostly based on DX12 mesh shaders technology something that could potentially work amazingly well with a particle systems or DOTS?

 

The point is that it's futile to add more stuff if they continue the track record of releasing half assed features that they then abandon.

So first, they should somehow prove they can finish and mature features and give us a core set of features that works really well together and has some thought behind it.

(like make a piece of software that gives the impression that it had a plan behind it, that they then executed on)

The impressive thing about the Unreal 5 presentation, is that they showed a bunch of features that were meant to solve hard gamedev problems. You have nanite solving LOD, but how do you lightmap such geo? Here's Lumen! Cool, but how do you load so much data if I want a big world? Here's automatic world streaming.

(and let's not argue on whether they actually executed that, I'm talking about the intent)

"Let's half ass a nanite", that works in HDRP only and provides benefits only in very narrow specific circumstances, and doesn't work with lightmapping, and like needs a specific addressables hack to somehow stream data and the workflow is horrible, etc, is definitely within Unity's ability and ... temperament, and would make for a very exciting 3 minutes in their next unite keynote, but why would you want that?

 

So have you just forgotten how Enlighten was completely useless for years after release?

 

New features are useless when none of them work right or are production ready.

Unity has a track record of investing inordinate amount of time into something that in the end isn't quite stable.

 

No, Nanite is CPU and Compute based. Unreal specifically went this route so lots of existing hardware could still be supported. The person mentioned here is trying to take a similar approach as well.

Literally the last few main versions of Unity have primarily been about refining and improving the engine. URP and HDRP are finally getting to a nice stable point, Shadergraph is more broad and adaptable. DOTS is reaching a proper release version in the coming months. System to replace Surface shaders for the modern pipelines is in alpha now. Various core systems in Unity have been pushed towards more low-level and DOTS accelerated functionality and continue to do so with each major version. It's mostly just been fixing and refining things lately, not releasing a bunch of new stuff on top.

 

Unreal 5.1 brought further improvements to both nanite and lumen...

Unity really should try to do some catch up