Re: Physics abnormal behaviour at z=8000

#5
Hi, 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

Re: Physics abnormal behaviour at z=8000

#7
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

#8
cry-ak76 wrote: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.

Would be great if Crytek could add cyclic 16-bit arithmetic for z. Several space games in the works on CRYENGINE already.

Re: Physics abnormal behaviour at z=8000

#10
This 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
Attachments
ScreenShot4092.jpg
ScreenShot4092.jpg (167.48 KiB) Viewed 164 times
ScreenShot3912.jpg
ScreenShot3912.jpg (95.01 KiB) Viewed 164 times
ScreenShot3910.jpg
ScreenShot3910.jpg (129.48 KiB) Viewed 164 times

Who is online

Users browsing this forum: No registered users and 1 guest