Has Unity Considered a 64 bit floating point upgrade?

Except that they're already making their move to supporting 64-bit.

 

In fact, I know quite a few good games of times when 3D video chips only started appearing that had never seen popularity just because most hardware didn't support it at that time and manufacturer's driver support was hayware. Are you sure it won't be same with engines?

 

I mean unity specific.

method 1:

-iterate over all objects
-set their parent to the player
-move player to origin
-iterate over all objects
-unparent them from player

method 2:

-iterate over all objects
-calculate their position relative to the player
-move the player to origin
-iterate over all objects
-move all objects to the player's position + their relative offset

How minor is the performance difference between these two "origin shift" approaches?

 

Pardon me but I'm new to game development. What is "origin shifting"? Am I correct in assuming that means recalculating the position of every active object in a new reference frame?

 

Once you go a reasonable distance away from origin some aspects of the engine start to encounter problems due to the limited precision of floating point numbers. Origin shifting (aka floating origin) basically shifts the world back to origin again centered around the player.

There is an example script for it on the Unify Wiki.

http://wiki.unity3d.com/index.php?title=Floating_Origin

 

Either no difference or setting parent will be slower, because in both cases you'll need to iterate through every object, but having a parent means one more object.

However, setting origin to player position is likely to be a bad idea, because you'll need to maintain some sort of structure to optimize collision queries. And in that case it will be better to have origin that doesn't move.

Also, IIRC unity encounters problems when physics-controller object is parented to something that can move.

 

Several years I have been using Unity, I can think of at least two projects 32-bit world was a problem...

So yes, I do support it, will cast my Vote.

 

Not just for Unity, also for us. There would likely be a lot of people who want to scale their world. But there is no easy switch from 32 bit to 64 bit numbers that doesn't cause a major headache. The possibility to switch between those two is far more complicated in my opinion than a radical cut to only support 64 bit numbers.

 

Darn, alright

Well literally everything is moving, so how could the player collide with anything else?

 

That's not it. All rigid bodies stored in 3d space will be stored in some sort of optimized structure that allows you to QUICKLY find out if there's something in this or that axis-aligned box without iterating through every body in the system. Also, bodies that do not move, freeze and are no longer processed.

So, the moment, someone get the idea of moving EVERYTHING in naive fashion, the collision query optimization structure most likely will need massive update, and every rigidbody might unfreeze.

I think I mentioned that about 5 times in this thread already?

It depends on physics engine internals, though. Sweep-and-prune would handle massive move fairly well, unless you also decide to ROTATE everything (which is a bad idea. DON'T rotate the world around origin). In case of something else you may get more expensive operation. Basically, you'll want physic system to support moveable origin. Otherwise there may be a lot of workarounds.

 

You sure did. Next time you can also mention it's called spatial partitioning or space partitioning. I couldn't find any docs on what methods PhysX uses for that though. Maybe octree?

 

Is this it?

http://docs.nvidia.com/gameworks/content/gameworkslibrary/physx/guide/Manual/Broadphase.html

 

Um... Nope. That's regions you can manually add/remove. A tool for manual optimizations I'd say. What we, are talking about is how they are made internally. Imagine those regions having 1000 objects each. Will you check each of them against each? Of course that would give you no performance. Also note phrase "The maximum number of regions is currently limited to 256.".

 

Bah. I sorta forgot the proper term, probably because sweep and prune doesn't actually partition anything and just maintains sorted lists instead.

 

@Teravisor: I'm aware of what you're describing. I just don't keep up to date on the terms. Only one I recognize is oct-tree.

 

Mostly, yes.

 

Well, IMO it is best to shift origin whenever user is interacting with the UI, be it pause menu or something different, like inventory screen. I mean, in any reasonably-sized game that would require this and is not a techdemo, player is bound to use UI sooner or later, so I'd do it this way:

- When user press whatever key is bound to GUI screen (say, map or inventory), shift origin
- Open menu in question afterwards

From player's point of view this would be just a slight lag while opening the menu that most likely he won't notice. And in most games, baring outliers like KSP, player will open menu or other GUI well before he'll reach 10km mark (or 5k mark, when starting position is at the center).

 

Quick question is a FLOP for single or double precision floating point. It is used a lot to refer to the maths power of CPU's, GPU's and even super computer clusters.

But I presume we have had 16, 32, 64 and even 128 bit precision floating point operations as technology has progressed.

So which do we use when we measure a systems FLOP's?

 

FLOP = floating operation. FLOPS = floating operations per second. Usually, it's float(32 bit) but it can depend on what's measured, what's in head of the one who wrote, etc. In the beginning everyone measured floating(16 bit) point operations per second. Now it's not in fashion. And it depends on architecture: in some it's same as using doubles, in others it's not. Most processor developers like to measure it how it's benefical for them(all want to write more flops than they have in reality) so it doesn't mean a thing usually as it's in perfect conditions (like no if statements, preemptive preprocessor always working, etc).

 

OK Enough talk anyone up for a Massive world challenge? http://forum.unity3d.com/threads/massive-world-or-space-challenge.384581/

If you can make a massive world with only 32 bit then prove it but better yet share it and show off your skills.

 

Couldn't you just make the rigidbody kinematic or disable it?

Of course I'm interested, I just don't have the time with work

 

Large world coordinates (double precision) is now enabled by default in Unreal Engine. Details here: Large World Coordinates in Unreal Engine 5 | Unreal Engine 5.0 Documentation.

On the CPU position is represented as a vector of native 64-bit floats. On the GPU, they are passing position as two 32-bit Vector3 values. The first is a position within a grid, and the second for a position within the grid.

 

Why you necroing, offtopic and hijack +6 years old post, just to write about Unreal?

 

It's important to talk about the competition. Unity is clearly not invested in improving things for game developers so SOMEONE has to do it.

But hey, don't worry! We're gonna get yet another cinematic video in a few months! Hooray!

 

Agreed. I think it's easy to say large coordinate support isn't needed today but looking at the kinds of experiences developers want to create now and in the future (contiguous large worlds, sprawling metaverse), it is definitely going to become an integral feature. In other words, it's not a matter of if, but when. We can debate how far into the future that day comes.

Had other engines not lead by example and shown what is possible, it is highly likely naysayers would still be insisting it isn't possible.

 

Except this thread is about 64 bit support, not 32 bit x2 support, it's about Unity, not Unreal, and it's nearly seven years old, and the person who necroed it made their own thread.

This is a pointless, off-topic necro.

 

The thread is clearly about double precision coordinates. Please stop.

 

It literally never was.

 

Pointless necro, off-topic. Please check dates before responding.