Instanced objects that are libloaded cause errors with rigid body collisions

[Feral3d]

If a scene has instanced physics objects, then rigid body physics behaves normally, like this:

However if that same scene is loaded from another blender file, this causes the physics for the instance objects to go crazy when they collide with rigid bodies. Like this:

When a scene is libloaded, any rigid body object that collides with an instanced, static object that has had physics "reactivated" will be launched quickly into space.

This is proving to be a game breaking issue for my game project, but I really would like to use the physics culling because it's so wonderful and perfect for my open world.

Here is a link to a folder where you can test the issue out for yourself.

Running the the file "car_test" works correctly, however if you run the file "load_car_test" the scene is loaded correctly, but now the rigid body physics of the vehicle will explode into space if it collides with any of the instanced rocks in the scene.

https://www.dropbox.com/s/rt9vkzfuuunt92d/Car_Test_Example.zip?dl=0

[Feral3d]

I would like to tag tag this correctly but I don't think I have access to the tagging abilities.

[Feral3d]

You can see after libload, obstacles near the center of the scene operate fine, but obstacles that are farther away from the world origin start to show this bug. The bug basically increases the farther you get from the world origin, to me this must mean that the main scene is not in sync with the scene that is "libloaded" in? Maybe the world origin is not being offset with physics culling.

[Feral3d]

Ok.... I have discovered the reason for the error, as well as the workaround.

Reason: In order to "libload" and merge a scene with another Scene, you must have physics active in the initial scene. This causes two bullet simulations to occur at the same time. One simulation in the newly appended scene "recognizes" the offset of the instanced object, while the initial scene, does not recognize the offset of an instanced object. The effects of this issue are exacerbated the farther you travel from the world center.

Solution/Workaround: Begin with an Initial scene that has No physics, immediately load a new background scene WITH physics, suspend the initial scene and merge the newly added background scene with your lib-loaded scene. Now physics for instanced objects will function properly and recognize offset.

It seems to be a little "messy" but it serves as a workaround. I thought I would make you aware of the issue. If there is a possibility to fix the issue, that would be great-- but as far as my current project is concerned, this is no longer an issue and I am moving forward.

[Feral3d]

I have distilled the issue to a simple solution!

If you try to set the worldTransform of an object, it is impossible. It seems the current build only allows me to set localTransform!

Take a look at this example file: https://www.dropbox.com/s/2clao00ufz7i9c6/Example_1_Works.blend?dl=0

Press "L" and you will see any attempt to set worldTransform with new matrix coordniates will default to localTransform.

The simple fix would be to allow users to once more set the worldTransform!

[Feral3d]

here you can see any attempt I make to set the worldTransform, defaults to localTransform Matrix. In this example you can see I am attempting to move an unparented object up 8 blender units on the Y axis while the game is running, however the worldTransform stays the same, and the localTransform is effected.

[lordloki]

I review the code involved and i didn't see any strange. I have to do more tests.