Going too far from the center of the world

[Ats]

Hello

In Omeganaut, the player ship was staying at 0 on the z axis, and everything was moving towards him: enemies, buildings, planets... This was a weird choice inherited from the very first demo I made so many years ago.

A few days ago, I started inverting all that. Now, the player and the camera flies on the z axis. This is handy for avoiding updating the physics of non-moving objects on each and every frame.

But now I have a few questions:
Big boy engines such as Unity and Unreal gets weird when the objects are too far from the center of the world: physics, animations, lights... So I was wondering if this could be an issue in ZGE?

And if it is the case, at which distance could things start to break?
And how could I retrieve each and every object currently alive to teleport them to the center of the world, let's say, at the end of each stage:
Is there a function for that? Or should I store everything manually in an array?

Thanks

[Kjell]

Hi Ats,

Big boy engines such as Unity and Unreal gets weird when the objects are too far from the center of the world: physics, animations, lights... So I was wondering if this could be an issue in ZGE?

Same thing in ZGE ( since it also uses 32-bit floating point values for most things ).

And if it is the case, at which distance could things start to break?

Depends on what you consider "to break". The loss of precision increases gradually as your values grow bigger. Here's a table with some numbers:



For more information you can read this article.

And how could I retrieve each and every object currently alive to teleport them to the center of the world, let's say, at the end of each stage:

I guess the least intrusive way would be to just use the "getModels()" function and iterate through all category numbers you're using in your project.

K

[Ats]

Thanks, that article was very helpful.

I totally forgot about getModels. I'll have to clean those category numbers before using it
(Just a little reminder for me, why the categories are important: http://www.emix8.org/forum/viewtopic.ph ... ory#p10239)

[Ats]

Fun fact:
I inverted the whole thing to avoid using zbtSetPosRot(CurrentModel.Obstacle_Body, CurrentModel.Position, CurrentModel.Rotation); in OnUpdate for all the non-moving objects. But it turned out that I still have to use it, otherwise colliding bodies would just get out of the ground if the object are planted into it. And since I don't move objects based on their colliding bodies, I had a hard time discovering why I was hitting invisible walls above some specific objects

But the game runs even smoother now, so it was worth it!

[Kjell]

Hmm,

But it turned out that I still have to use it, otherwise colliding bodies would just get out of the ground if the object are planted into it.

Can't you adjust the colliders so you don't have objects that sit on / in the ground don't penetrate the floor collider? That would save you the physics solver calculations for those objects. Or otherwise use a separate collision group for the floor and don't have it interact with the colliders that penetrate it .. seems a bit silly to push colliders back into the floor because the physics engine is pushing them out every frame.

K

[Ats]

Then there must be something I don't get with those bitmasks, because COL_OBSTACLE keeps colliding with itself...

For starters, is 00100000 = 0x20 or 0x32???
(Both doesn't work)

Code: Select all

// Collision groups

int COL_PLAYER = 0x1;      // 00000001
int COL_LASERPLAYER = 0x2; // 00000010 Doesn't collide with Player and EnemyLaser
int COL_OBJECT = 0x4;      // 00000100 Moving Object
int COL_ENEMY = 0x8;       // 00001000 Same as COL_OBJECT but doesn't trigger Visor
int COL_LASERENEMY = 0x10; // 0x10 0x16 ? // 00010000
int COL_OBSTACLE = 0x20;   // 0x20 x32 ? // 00100000 Ground and non moving objects, can go beneath ground

// Collision masks = things the group is supposed to collide with

int	MASK_PLAYER = COL_OBJECT | COL_ENEMY | COL_LASERENEMY | COL_OBSTACLE;
int	MASK_LASERPLAYER = COL_OBJECT | COL_ENEMY | COL_OBSTACLE;
int	MASK_LASERENEMY = COL_OBJECT | COL_PLAYER | COL_ENEMY | COL_OBSTACLE;
int	MASK_OBJECT = COL_PLAYER | COL_LASERPLAYER | COL_OBJECT | COL_ENEMY | COL_LASERENEMY | COL_OBSTACLE;
int	MASK_ENEMY = COL_PLAYER | COL_LASERPLAYER | COL_OBJECT | COL_ENEMY | COL_LASERENEMY | COL_OBSTACLE;
int	MASK_OBSTACLE = COL_PLAYER | COL_LASERPLAYER | COL_OBJECT | COL_ENEMY | COL_LASERENEMY;

[Kjell]

Hi Ats,

For starters, is 00100000 = 0x20 or 0x32???

A binary value of 00100000 is 20 in hexadecimal and 32 in decimal, so 0x20 is correct. If you're having trouble with hexadecimal and binary i'd recommend keeping a calculator that has a programmer mode handy ( like the default one in Windows ).

Then there must be something I don't get with those bitmasks, because COL_OBSTACLE keeps colliding with itself.

Why is COL_OBSTACLE 0x64? That looks like a mistake ( check out the binary value )



K

[Ats]

Thanks.

Sorry, the 0x64 was a mistype. It's definitely 0x20. But it doesn't work either. The ground, which is an obstacle is still picking the objects out of it.

I remember I already had problems with 0x20 bitmask not working as expected. I'll make a strip down example when I'll get back home.

[Ats]

After a lot of tests, the groups and masks are working, but not in my game. That might be coming from the order of creation / position / physics. I'll have to dig that when I'll have some time.