+- Obi Official Forum (https://obi.virtualmethodstudio.com/forum)
+-- Forum: Obi Users Category (https://obi.virtualmethodstudio.com/forum/forum-1.html)
+--- Forum: Obi Rope (https://obi.virtualmethodstudio.com/forum/forum-4.html)
+--- Thread: Problem with movement of ObiRopeAttachment (/thread-4130.html)
Problem with movement of ObiRopeAttachment - Alnik - 13-03-2024
Hello everyone!
I have the following problem: I am trying to control the same crane with two clients that connect to a server via FishNet. As long as no player connects to the crane, the ObiSolver remains disabled and the spreader is simply dragged along as a child of the crane.
As soon as a player connects to the crane, the parenting of the spreader is changed and the ObiSolver is enabled so that the spreader is now only attached to the crane by the ropes. It should be noted that the ropes themselves are attached to a SpreaderAttachmentGO in a cabin GO that can be moved.
If you now move the cabin, the spreader also moves with it, as the SpreaderAttachment, just like the VCam, is attached to the cabin. If the first client now disconnects from the crane, the ObiSolver is disabled again. If the second client then connects to the crane, the VCam is packed to the position left by the first client, but the ropes spawn at the original position in the centre of the crane, i.e. as if the cabin movement had not taken place before. You can see this in the attached video.
What confuses me now is that in the SceneView (also in the video) you can see that the object on which the ropes are actually hanging is in the correct position, but for some reason the ropes themselves are hanging down vertically from the centre.
I was previously able to reproduce this behaviour independently of the network, i.e. in single player, but this was not always successful. The same behaviour can also be observed when the crane is moving. The ropes also spawn at the crane's point of origin.
Does anyone know what could be the reason for this? Does the position of the SpreaderAttachment have to be updated somehow in the ObiSolver? Could the alternating enable/disable of the ObiSolver lead to such behaviour? Originally I installed these changes because the performance was severely affected by the rendering of 60 different ObiSolvers for all cranes at once.
In the video, I also included the settings for the ObiSolver and for one ObiRope as an example.
Many thanks in advance!
Best regards,
Alexej
RE: Problem with movement of ObiRopeAttachment - josemendez - 18-03-2024
(13-03-2024, 02:42 PM)Alnik Wrote: If you now move the cabin, the spreader also moves with it, as the SpreaderAttachment, just like the VCam, is attached to the cabin. If the first client now disconnects from the crane, the ObiSolver is disabled again. If the second client then connects to the crane, the VCam is packed to the position left by the first client, but the ropes spawn at the original position in the centre of the crane, i.e. as if the cabin movement had not taken place before.
What confuses me now is that in the SceneView (also in the video) you can see that the object on which the ropes are actually hanging is in the correct position, but for some reason the ropes themselves are hanging down vertically from the centre.
Hi!
If I understood your description of the issue correctly, the problem is that you're assuming that moving a rope via attachments will modify the rope's transform, but that's not the case. Moving any particle-based actor will only move its particles, the transform remains at the position/rotation where the asset was instantiated. This is because transforms only work for rigid objects: you can't uniquely determine the pos/rot/scale of an object using a single affine matrix if the object is allowed to deform/bend/stretch.
So once you move the crane, disable the client and connect a second client, the rope will respawn where its transform is: where it was before the crane was moved, since moving the crane does not modify the rope's transform.
The solution to this is to sync the rope's start/end positions over the network, or recalculate the position of the transform yourself.
kind regards,
RE: Problem with movement of ObiRopeAttachment - Alnik - 21-03-2024
(18-03-2024, 07:37 AM)josemendez Wrote: Hi!
If I understood your description of the issue correctly, the problem is that you're assuming that moving a rope via attachments will modify the rope's transform, but that's not the case. Moving any particle-based actor will only move its particles, the transform remains at the position/rotation where the asset was instantiated. This is because transforms only work for rigid objects: you can't uniquely determine the pos/rot/scale of an object using a single affine matrix if the object is allowed to deform/bend/stretch.
So once you move the crane, disable the client and connect a second client, the rope will respawn where its transform is: where it was before the crane was moved, since moving the crane does not modify the rope's transform.
The solution to this is to sync the rope's start/end positions over the network, or recalculate the position of the transform yourself.
kind regards,
Hello!
I see, thank you very much for your reply, I will try that when I am back at work
Best regards,
Alexej