Not sure what you mean Gael.
JMonkey needs to be capable of loading and saving config - expectation would be to get back to a reasonable state ... same as all config.
I'm not done with it - but each model potentially will have a possible mapping, a transform and a rotation.
I don't expect it will take too much time to work out the kinks.
I had noticed that if I would adapt mappings for my real robot, VinMoov would also be following those mappings which caused it not to be able to do the gestures correctly while my real robot could.
I got what the problem was ... I was apply a unit vector to rotation, while I should have just set the default rotation axis.
So it worky I think in the sense that it will load the appropriate models, set the nodes desired rotation, and set mappers as the current i01.startSimulator() does.
As I would expect if I call start config more than one time - more than one model will load.
So this InMoov Durga is not unexpected ;)
InMoov2 doesn't need JMonkey config to work - but I felt it was an appropriate task to get started on, as it gives users the ability to configure and manipulate models, their axis, and their mappings without having to do it in Java or Python.
So this
can potentially replace this Java (or Python)
it can be "tweaked" - then re-loaded without compiling or knowing the necessary Python bindings
Heh .. I haven't looked at your Servo Tuto for a while ;)
This is the entire jmonkey config file for the intro virtual servo
Getting back to InMoov2 - as I said doesn't need it, since the values are hardcoded.
But I think now I can start looking into the peer state information .. ie if its started or is not part of the registry
Hello Grog,Ouch that seems
Hello Grog,
Ouch that seems to be painful !
I am not sure saving config should affect virtual InMoov.
Adjusting the OUT mappings of a servo shouldn't affect Virtual InMoov, maybe only the IN mappings could eventually do.
If InMoov config is loading with "rest" as default like I really think it should be, we don't need to go through this.
Saving the "last position" could in fact create trouble on Virtual InMoov.
Not sure what you mean
Not sure what you mean Gael.
JMonkey needs to be capable of loading and saving config - expectation would be to get back to a reasonable state ... same as all config.
I'm not done with it - but each model potentially will have a possible mapping, a transform and a rotation.
I don't expect it will take too much time to work out the kinks.
I had noticed that if I would
I had noticed that if I would adapt mappings for my real robot, VinMoov would also be following those mappings which caused it not to be able to do the gestures correctly while my real robot could.
I got what the problem was
I got what the problem was ... I was apply a unit vector to rotation, while I should have just set the default rotation axis.
So it worky I think in the sense that it will load the appropriate models, set the nodes desired rotation, and set mappers as the current i01.startSimulator() does.
As I would expect if I call start config more than one time - more than one model will load.
So this InMoov Durga is not unexpected ;)
InMoov2 doesn't need JMonkey config to work - but I felt it was an appropriate task to get started on, as it gives users the ability to configure and manipulate models, their axis, and their mappings without having to do it in Java or Python.
So this
can potentially replace this Java (or Python)
it can be "tweaked" - then re-loaded without compiling or knowing the necessary Python bindings
Heh .. I haven't looked at your Servo Tuto for a while ;)
This is the entire jmonkey config file for the intro virtual servo
Getting back to InMoov2 - as I said doesn't need it, since the values are hardcoded.
But I think now I can start looking into the peer state information .. ie if its started or is not part of the registry
Yes it makes a difference in
Yes it makes a difference in which order local transforms is applied because I have built them upon one center part.Starting from lowStom if I recall.