Pls help me ordering my thoughts how to fight precision loss

Hello,



I was thinking occassionally about preventing precision loss for some time now and have some trouble finding the right solution.

I’m using a client-on-top-of-server architecture.

I read here that the problem is not as severe if you have your objects ordered logically and not only in the scene graph (let me give an example: You have the class UserEntitie. This class owns a position in double and a node containing the model (at least the hitboxes for the different limbs)).

I need this Node to take advantage of JME’s animation system and to do raycasting and intersection tests.

Here comes the poblem in my understanding: The animation should move the hitboxes correctly because locally it’s near/at the origin but when I want to do any raycasts then I assume that the position has to be calculated into world coordinates which then kills precision. Is that right so far?

Even if that wouldn’t be true then the problem arrives when I move the object logically with it’s double variables and then translate the node accordingly. I would not lose as much as when just using float everywhere but it is still possible that this will cause significant position shifts.

If I think about this it seems to me that the only way out is to split up the world into different sectors. But that could be quite difficult when 2 or more players are close but not very close together (so doing things together but being at the edge of a sector and crossing it often while fighting for example. Maybe a big overlapping will prevent from that…).



To the client side: For the client I read the advice to let the character stay at the origin. That would mean that for every movement the player makes I have to translate everything else every loop cycle. Is that right? (And is that ok concerning performance and bullet? (On the client I want to use “real” physics))



Thank you for reading so far :wink:

Is the extra accuracy you are trying to achieve actually going to be visible to a human player? Unless you are doing some sort of scientific sim where accuracy is extremely important I’d be surprised if floats can drift enough to be a problem…

@zarch said:
Is the extra accuracy you are trying to achieve actually going to be visible to a human player? Unless you are doing some sort of scientific sim where accuracy is extremely important I'd be surprised if floats can drift enough to be a problem...


It can definitely be visible.

@enum I eventually came to the solution of partitioning my world into smaller sectors, but you're right in that the edges can he difficult to deal with. My advice is to try a few solutions and see what you like :)
1 Like

Thanks sbook. It was not the answer I was hoping for but now I can at least start doing something.

Do you shift the world on client side whenever the the user enters a new area or do you use the “stays in origin” tactic?

I personally try to fix my world so it winds up inside the acceptable range. That is before objects start shaking and looking weird when moving. But honestly I’ve been thinking of translating the whole thing to “moving around the origin”. More involved though. A lot more. Still uncertain what I’ll do in the end.

Physics may be the only issue. Other than that, translating the world or translating the camera is equally difficult (ie: not very). Especially if your game objects are already in their own world coordinates, etc. and then transmuted to the view. (tried to use a different word other than ‘translate’ or ‘transform’ since those are ambiguous and overloaded in this case)

1 Like
@enum said:
Thanks sbook. It was not the answer I was hoping for but now I can at least start doing something.
Do you shift the world on client side whenever the the user enters a new area or do you use the "stays in origin" tactic?


I let the camera roam around the scenegraph rather than having the world come to it. It was more a matter of convenience, inertia, and deadlines than anything technical :)
1 Like
@sbook said:
I let the camera roam around the scenegraph rather than having the world come to it. It was more a matter of convenience, inertia, and deadlines than anything technical :)

I would add that, in my case, it was ignorance. 8O

As we’re making a space game where players will be able to travel through a star cluster (or even a galaxy) we’re dealing with vast distances and it quickly became apparent in our early tests that precision loss would be a major problem.

Looking through possible solutions we found the “player at the origin” (keeping the player at 0,0,0 and translating all other objects relative to the player depending on their game positions) technique to be the most stable and flexible option and it has worked very well for us.



As we still want the player to be able to see things that are far away, where there normally would be precision loss, we also make use of a technique where we distribute far away objects at distances that are closer to the player than they should be and instead scale them accordingly, so they look to be farther away. This scales very well and avoids precision loss for a game of our type.



We have our own physics calculations, so I can’t tell how bullet would work with this setup.



As for partitioning, we make use of one partitioning system for game positions (each box-shaped partition centred on 0,0,0 for its local coordinate system) which allows for a large game world (on the server). We also use a partitioning system for object registration and loading, where each player has (currently 179) sectors around them that define their “local view”. Server objects are registered to these sectors (with some exceptions for e.g. stars that should be seen from anywhere) and when a player’s “view bound” moves to include a sector with registered objects those can be sent to that player. Well, it seems I’m now rambling, so I’ll stop. :slight_smile:

1 Like
Well, it seems I’m now rambling, so I’ll stop. :)


I read everything with great interest ;)
The problem with precision loss on view distance will not occur to me as I'm creating an RPG and you sould not be able to leave the ground (maybe with the exception of some minor flying).

So I guess I will try the player at origin and see if that works out with Bullet. Maybe @normen can say something about his?

For you who don't have the player at the origin: Do you tell the client when the user entered a new sector serverside and let it then recalculate positions in respect to the new sector?