World-Origin-Shifting: Ignore-Flag does not work for Landscapes

Hello,

we are using the world-origin-shifting feature by manually triggering the shift with “UWorld::RequestNewWorldOrigin”.
For several actors, we need the “bIgnoresOriginShifting”-flag to be set to “true”.

This works for all types of actors, but not for landscape-Actors.

As soon as I shift the origin (and have moved a reasonable distance), the heightfield-collisionshape disappears, thus the player falls through the level.

This happens in 4.7 and in 4.8.

Seems to be a bug ?

Thanks

Hi ThisGuy5234,

While I don’t have any experience with this specific code, you can try running the console command RecreateLandscapeCollision to see if that regenerates the collision. If not, please let me know and we’ll see what may be going on.

Hi ,

unfortunately that did not help. The console command “RecreateLandscapeCollision” is also not being autocompleted, so the code probably was never called ?

After some research, I have found out, that, after commenting out the if-condition in “ULandscapeHeightfieldCollisionComponent::ApplyWorldOffset”, the collision gets regenerated correctly for the heightfield, which should ignore shifting.

But, I assume this is a hack? I do not know if this would work for landscapes which should not ignore shifting, and is probably also bad performance-wise?

Hi,
It looks like there is a bug with how landscape collision handles bIgnoresOriginShifting flag. We will look into fixing this.
But in general you should avoid settings this flag for landscapes. PhysX library has a function PxScene::shiftOrigin that shifts all physics bodies in scene by a specified vector, which we use during origin shifting. When you set bIgnoresOriginShifting for an Actor engine should “transform back” those actors in physics scene, because PhysX has no API to ignore shifting for specific bodies. Landscape usually has a lot of physics bodies (one per component), so it’s very bad for performance.

Hi, allright, thank you.

I am not sure what the best solution for us would be, as I do not know if we can live with a short pause. Perhaps modifying the PhysX-API would be possible. Would it be perhaps wise to convert the heightfield into a static mesh and is this possible with the editor ?

I have thought about the bIgnoresOriginShifting flag again. If I would convert the heightfield into a static mesh, I would not gain any performance, because of the missing feature in the physx-api for all shape-types, correct ? So I guess the best for us would be to implement a timesliced approach for physx-origin-rebasing or implement the bIgnoresOriginShifting -feature into physx if possible ? Not a feature we would currently have time for, but the best approach I’d assume ?

bIgnoresOriginShifting has very specific usage in games. Mostly it should be used for global objects that should not shift, skybox for example. What kind of gameplay you have that requires origin shifting and at the same time wants landscape to not be affected by it?

We use the originshifting-feature to shift the universe around a static ship. The universe is being transformed and scaled into a “virtual-moving-spaceship-space” just before being rendered in the renderpipeline. Landscapes can be parts of landingsites, which have to be also in the “static-spaceship-space” in order to avoid float-precision issues. I must admit that this a very specific approach, but seems to work . I do not know, if at some time, we will take a completely different approach, though. Perhaps if the renderer will support multiple cameralayers. Currently the performance seems to be totally sufficient as soon as we need a shift - which is in certain trigger-situations. But it can be a problem if the spaceship grows later. For our prototype it does not seem to be a problem. Thank you for the possibilities we have now, btw :slight_smile: