Setting visual instance visibility causes it to snap at world origin when physics interpolation is enabled
Closed this issue · 2 comments
Godot version
Godot 3.5
System information
Windows 10 64 bits GLES3 GeForce GTX 1060 6GB/PCIe/SSE2
Issue description
I got noticed of various issues occurring in my terrain plugin when physics interpolation is on. While trying to workaround them, I found out if a visual instance is setup with the following calls:
var mi_rid = VisualServer.instance_create()
VisualServer.instance_set_transform(mi_rid, transform)
VisualServer.instance_set_base(mi_rid, mesh)
VisualServer.instance_set_scenario(mi_rid, get_world().scenario)
VisualServer.instance_set_visible(mi_rid, false)
VisualServer.instance_set_visible(mi_rid, true)It snaps to the origin. This is not expected, it should be where transform is.
On a side note, my terrain chunks are disrupted by physics interpolation running on ALL visual instances even when it doesnt make sense like here, causing flickers. It would be nice if interpolation could be turned off on specific instances, because unless I keep calling both instance_set_transform and instance_reset_physics_interpolation all the time, this feature seems to run on everything drawable by default, which I don't desire. It seems like a waste of resources as well.
Furthermore, I use VisualServer directly, and instance_reset_physics_interpolation is not exposed, so I can't workaround it.
Steps to reproduce
Test project:
PhysicsInterpolationNewMeshInstances.zip
Launch main scene, press Space. Meshes are supposed to be swapped with nodeless equivalents, instead they all get stacked at origin.
Minimal reproduction project
No response
You can turn physics interpolation off for any nodes or branches, if you go to the Node properties in the editor inspector, there is a physics_interpolation_mode property. Just switch this to off for a branch and it will be inherited in all children.
It is likely the problems you are getting are from using interpolation via the VisualServer directly rather than through MeshInstances etc. This is not yet fully supported yet, but I can have a look at binding the calls necessary for this to work. It may be that you would have to take more care in the ordering of calls in this scenario than would otherwise be the case, as physics interpolation is quite finicky to get right (I had to take some care with hiding / unhiding, particularly due to design constraints on the decision to put interpolation in the server).
I'll take a look at the project and come back with more info. 👍
EDIT: Yes this was basically a conscious decision not to bind physics interpolation functions in the VisualServer during the initial rollout. This is because once the API is fixed, then it needs to be maintained in terms of backward compatibility, and it was possible there might need to be changes, and given that people using the VisualServer directly is a small percentage of users, this was a sensible sacrifice.
I'm doing a simple PR to bind these functions, however I'm unsure whether it should be cherry picked to 3.5 until we have more feedback (for the exact reasons it wasn't bound initially).