Hello,
I 'm building a space level, and I moved an object ( primitive cube) in C# rolling ball template through properties to z=8000, also the player entity (the ball) moved to z=8001
At that point the collision between objects didn't work any more !!
See video at 8:23 to watch that behavior.
https://www.youtube.com/watch?v=jF0iJgu-piI
Using Cryengine 5.3.4 build 47
Thanks
PB
Re: Physics abnormal behaviour at z=8000
#2Outside the map boundaries? Not sure if physics are enabled by default outside the boundaries.
Check if p_check_out_of_bounds = 3
Check if p_check_out_of_bounds = 3
Re: Physics abnormal behaviour at z=8000
#3Yes, p_check_out_of_bounds = 3 at the project when I move objects at z=8000.
Is there anything that I can do to ensure physics at that z?
Thanks,
PB
Is there anything that I can do to ensure physics at that z?
Thanks,
PB
Re: Physics abnormal behaviour at z=8000
#4How far away is your setup from terrain? Enable terrain so can see it then drag everything directly above the terrain with some elevation. No matter how high up from terrain your setup is aslong as its within terrain boundry edges.Yes, p_check_out_of_bounds
-regards
Re: Physics abnormal behaviour at z=8000
#5Hi, its a level without terrain ( space level ) ,and I have just 2 objects : the player ( ball from template Rolling ball ) and primitive cube . These 2 objects are at z=8000, at z=34 for example this works well.
But I tried with terrain and with terrain elevation at z=8000 and the player ( ball ) collide with terrain, but it did not collide with primitive cube!!!!
It's easy to replicate, just create a c# project based on template rolling ball without terrain, add entity player (ball) and primitive cube, test at z=34 for example and then move to z=8000, try physics.
PB
But I tried with terrain and with terrain elevation at z=8000 and the player ( ball ) collide with terrain, but it did not collide with primitive cube!!!!
It's easy to replicate, just create a c# project based on template rolling ball without terrain, add entity player (ball) and primitive cube, test at z=34 for example and then move to z=8000, try physics.
PB
Re: Physics abnormal behaviour at z=8000
#6If you're going for a space level you'll probably have to loop the position of your player so you're never too far away from the center. If you continue until infinity you'll not only run into issues with physics, but also with floating point precision in general.
Re: Physics abnormal behaviour at z=8000
#7this happens because for preliminary checks, the physics stores bbox z coordinates quantized and cropped to 16-bit signed ints. an engine change will be needed to fix that. a quick patch would be to increase zGran in the entity grid initialization in physicalworld. now it's 1/16m, meaning that i'd actually expect it to misbehave starting at +-2k range. increasing zGran (and decreasing rzGran correspondingly to 1/zGran) will increase the range proportionally. however, a better solution would be to use cyclic 16-bit arithmetic for z. we will probably add it in upcoming releases.
incidentally, the engine already supports cyclic bboxes for x and y, though the flag is not exposed in the sandbox GUI currently. it is in fact recommended to use that setting for large sparse levels, such as space-based ones.
incidentally, the engine already supports cyclic bboxes for x and y, though the flag is not exposed in the sandbox GUI currently. it is in fact recommended to use that setting for large sparse levels, such as space-based ones.
Re: Physics abnormal behaviour at z=8000
#8Would be great if Crytek could add cyclic 16-bit arithmetic for z. Several space games in the works on CRYENGINE already.this happens because for preliminary checks, the physics stores bbox z coordinates quantized and cropped to 16-bit signed ints. an engine change will be needed to fix that. a quick patch would be to increase zGran in the entity grid initialization in physicalworld. now it's 1/16m, meaning that i'd actually expect it to misbehave starting at +-2k range. increasing zGran (and decreasing rzGran correspondingly to 1/zGran) will increase the range proportionally. however, a better solution would be to use cyclic 16-bit arithmetic for z. we will probably add it in upcoming releases.
incidentally, the engine already supports cyclic bboxes for x and y, though the flag is not exposed in the sandbox GUI currently. it is in fact recommended to use that setting for large sparse levels, such as space-based ones.
Re: Physics abnormal behaviour at z=8000
#9ok i added it to the current code base, it should be reflected on github/main after some time
Re: Physics abnormal behaviour at z=8000
#10This problem has existed since CE3, but not in CE2.
I just did some tests in 3.58, and objects lose solidity at a height of just over 2000 meters.
p_check_out_of_bounds works a treat when x and y far exceed the map size, but it doesn't help in the vertical direction.
If possible, I would suggest that p_check_out_of_bounds be extended so it also works in the z direction.
Some years ago I developed a spaceflight system that allowed the entire solar system to be recreated in Sandbox.
It works by offsetting the player spacecraft to the Sandbox origin. All other spacecraft and planets have the same offset applied. Planets and moons are moved towards the player so they are around 10 km distant , they are then scaled so that they have the correct apparent size.
Because the player is at the Sandbox origin (when in space), there is no vibration caused by low FP accuracy. You can pilot your spacecraft all the way out to Pluto, and it is completely smooth.
However, the simulator only supports CE2 and CE3.
Regards,
Chris
Hi lavizh,
I couldn't post several screenshots due to the very small file size limit. Any chance this can be fixed?
Many thanks,
Chris
I just did some tests in 3.58, and objects lose solidity at a height of just over 2000 meters.
p_check_out_of_bounds works a treat when x and y far exceed the map size, but it doesn't help in the vertical direction.
If possible, I would suggest that p_check_out_of_bounds be extended so it also works in the z direction.
Some years ago I developed a spaceflight system that allowed the entire solar system to be recreated in Sandbox.
It works by offsetting the player spacecraft to the Sandbox origin. All other spacecraft and planets have the same offset applied. Planets and moons are moved towards the player so they are around 10 km distant , they are then scaled so that they have the correct apparent size.
Because the player is at the Sandbox origin (when in space), there is no vibration caused by low FP accuracy. You can pilot your spacecraft all the way out to Pluto, and it is completely smooth.
However, the simulator only supports CE2 and CE3.
Regards,
Chris
Hi lavizh,
I couldn't post several screenshots due to the very small file size limit. Any chance this can be fixed?
Many thanks,
Chris
- Attachments
-
- ScreenShot4092.jpg (167.48 KiB) Viewed 9748 times
-
- ScreenShot3912.jpg (95.01 KiB) Viewed 9748 times
-
- ScreenShot3910.jpg (129.48 KiB) Viewed 9748 times