- This topic has 13 replies, 3 voices, and was last updated 4 years, 10 months ago by
.
-
Posts
-
Hello everyone,
I notice that the Geomagic Plugin and the example scenes have changed in v18.12 and it is different from v17.12.
A major issue is that the scene in v18.12 cancel the data binding between the Instrument state and the Omni proxy state. And I know that if the scene in v18.12 maintain the binding as it does in v17.12, it would not work properly.
But if the FPS is low, like 50Hz, due to some other compute-intensive reasons, it would cause a large delay between the Instrument state and the Omni proxy state.
It is the disadvantage compared with v17.12.
Can anyone solve this problem?
Wong
Hi,
could you just post the old scene with the data binding you are highlighting.
I will check if this is still possible or with another mechanism.The change in the scene were a consequence of changes in the constraint resolution API inside SOFA.
regards,
Hello @epernod,
You can see the change as the pictures shown below.
In v17.12, there is a data binding.
While in v18.12, the data binding is removed.
Wong
Ok, yes it is because the omni position is now gathered inside the Omni node where there is mechanicalStateController.
To link to the Instrument model, it uses VectorSpringForceField.Letting the first Data link was creating inconsistencies between the collision and controllerState nodes communicating using the VectorSpringForceField and the direct link inside the
<MechanicalObject name="instrumentState" template="Rigid" />
Anyway, normally the old method is still working, did you try running it, what is the result?Also did you try using the other rigid skull scene using RestShapeSpringsForceField?
regards,
Hello @epernod,
I have said that if this data binding is canceled, it will cause a large delay between the instrument state and the proxy state in a low FPS(say, 50Hz) scene.
And the old scenes do not work anymore in v18.12, even the one using RestShapeSpringsForceField. I have had all the tests.
Wong
Hello @Wong
ok I understand, the data binding has not been canceled. The code from the Geomagic didn’t changed.
But the API on how to solve the constraint changed to be more accurate. The delay is due to tool position computation regarding the constraint.When you speak about the 50 FPS, is it using the demo scene of the plugin or your scene?
Erik
Hello @epernod,
I just modified the liver example and made a comparison.
In v17.12, there is no delay at all between the instrument state and the proxy omni state, while in v18.12, there is not little delay, even at 130 FPS, let alone 50 FPS.
You can see the difference in the video from this link:
https://www.dropbox.com/s/094a4pl7ffv40nq/liver.rar?dl=0Wong
Hmm thank you for reporting this @outtt
I think need to investigate this. Changes where indeed made in the Geomagic plugin since 17.12.Hugo
Hi,
@outtt I see the delay in your video but I tested the liver18.12.scn on my computer and I don’t have the delay.
Could you tell me exactly which version of SOFA you are using. Is it the 18.12 from github that you compiled or a package?Are you able to test on an up to date version of SOFA? There might have been additional fixes not included in the 18.12.
@Hugo, this is not link to change in the plugin. The scene have been update and the position data link has been removed to follow change in the constraint resolution API.
If indeed we lost some performances we will need to come back and understand what has been broken by the lambda function changes.Erik
Hello @epernod,
Maybe you could not see the frame because I did a little modification about the Geomagic plugin.
I use just the v18.12.Try this new one:
https://www.dropbox.com/s/t5zazy8mwek4jly/liver-18.12.scn?dl=0Wong
Hi,
no sorry, I didn’t had time to check that and I have other deadlines for the moment.
I let you know if I make progress on that topic.Erik
- You must be logged in to reply to this topic.
