Recoding Unity's Coordinate System

I want to rid Unity of the stupid floating point errors. But I don't know of anyways to manipulate how the coordinate system works in Unity. Is it possible to re code the coordinate system from inside the editor?

 

Exactly what problem is it you're trying to fix? Floating point errors aren't an issue with Unity, they're fundamental to the nature of how numbers are represented in binary formats.

 

When creating procedural and infinite universes floating point numbers loose their accuracy resulting in the jitter, which looks bad and causes random things to happen. What I am wondering is if there is a way to "turn off" the traditional system and write my own from within the editor.

 

Yes, floating point numbers become less accurate the further from 0 you go. You can't change that fundamental issue, especially in any way that will help with an "infinite universe". You need to use different strategies to nullify the impact of the inaccuracy, eg: recentering as the player moves around so that their local vicinity is closer to 0.

What you're suggesting is re-writing Unity's scene graph, which you can't do without a source license. Even with that you could only create a partial solution anyway, and if you want to do anything "infinite" you'll end up having to pursue another strategy on top of it in any case.

 

The way transforms work is kind of fundamental to the engine. Redoing this would require rewriting the entire engine.

Still, there are valid work arounds. The most common is floating origin. Google it.

Kerball also did a video at one of the Unites a couple of years ago showing how they dealt with floating origin. Again, google it.

 

I know of a way to fix it permanently angrypenguin, well to a point where it wouldn't even matter anymore, but I didn't even know there was a source licence. And BoredMormon I know how Kerbal Space Program, I have watched that Unite conference already before posting this thread. The big issue with doing floating origin is that I don't think it works with multiplayer situations, unless I am mistaken. But overall thanks for the responses!

 

you could do floating origin on a multiplayer game, you'd just have to translate the difference in coordinates between clients. And that differencing information would be stored with a higher precission data type.

 

Floating origin would totally work in multi player. The key to remember is that each client should implement its own floating origin. My origin might be at world zero. Your origin could be 200 km away.

That does pose an interesting question, is the game really multiplayer when players can be far away enough from each other that floating point precision matters?

 

Okay but what if you have 1000 stars, 100 players and 500 ships. Now the problem is when you set the main player back to 0, you also have to move every other object at the same time. This would create tremendous amounts of lag, and utterly kill a server or game.

 

I can see it, if you were playing a massively multiplayer space battle sim game.

Thing is all of that wouldn't be loaded up on any individual client. That'd be ridiculous. Each relative location would only be loaded up. And really... none of those would need such large scale.

Instead you'd just be like "I'm in sector 7 of the andromeda blah blah blah" (which could be the floating origin value really), information about a client in sector 80 doesn't matter... it's not like you'd actually need to move things across that space. You wouldn't load that. The idea of that sector would just be stored in memory (in whatever data format you want, no 'float' restriction at all).

 

How fast do you move around this entire world? Why do you need all of this stuff loaded up at their relative VAST coordinates? Why don't you just have loaded that which is near you?

100 players in the same relative location??? OK, they ALL have the same floating origin (like my previous post, you have sectors that you all are in).

Or are you saying you have 1 player 1 million light years away from another? Well, why are they both loaded on eachothers client? If Joe is a million lightyears away, I don't need his GameObject, model, and specific location on my machine... I just have a small packet of data that represents Joe and his general location, and I don't load it until either he flies over near me, or I near him.

 

This is going to get ugly fast with a lot of colliders as none of this supports origin shifting so you'd probably have to endure periodic stalls.

 

I'm saying that if you have 100 players near enough to each other that you need to move all of them. Also a solution to the problem would be setting up sectors, but I don't know of a way that would make sectors work because of the hard coded coordinate system. And like hippocoder said about the periodic stalls you do experience these stalls in Kerbal Space Program. And KSP isn't moving 100 or even 500 things at the same time.

 

Allow the camera to float around relative to the local client, it's not really a floating origin in the traditional sense... it's a floating origin for the server.

You get some coordinate to base all your positions off of in your local space. If you move to far away from the local space, you readjust that coordinate (example: travel to a new sector, a sector could be something like 10,000x10,000 units for instance). This moment when you sync is when you could also load up any new data you need, and dump any data you no longer need because it's so far away.

Each client will have their own general local space.

This way, any stutter only comes once in a while, when you resync your origin, which only happens if you fly a long distance.

All other clients do this on their own system, so you don't really care about their syncing.

 

The number of moving objects is irrelevant. In fact, the number of static (non-moving) colliders is likely to contribute more to the stalls, because they're stored in a data structure designed for fast read at the cost of slow modification. To the dynamic colliders I suspect that a recenter is just like any other move. But to static colliders? Recentering is moving every single one of something that's never meant to move.

For what it's worth, I believe that the new version pf PhysX in Unity 5 does support recentering.

I can also think of ways to "fix" it, but they'd all introduce other drawbacks. This is an issue that many experts in computer science have spent a lot of time on, and something that everyone in the field of game engine development has thought about. It's possible that you've got a new, unique solution that nobody before you has thought of, but I don't consider it to be likely.

The simple "solution" would be to switch from single- to double-precision floating points, though for an "infinite" world that's still only going to get you so far. You're still going to end up needing something like sectors and recentering at some point.

And of course recentering can work in multiplayer. The server and clients don't have to use the same scene tree, the same data types, or even the same coordinate system. As long as you can translate between whatever the server is using (which can be anything) and whatever the client is using (which can be anything else, but is probably something like Unity's default system) you're fine. (Heck, your different clients don't even have to use the same systems as long as they can all understand the server.)