You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In fact, removing all the nodes from the cassie.xml file, changing the NODECOUNT in main.h to zero and applying perturbation with Ctrl+P runs nearly twice as fast as the less slow commit. The problem has nothing to do with rendering/visualization because there are no scene updates while IK is being solved (just mj_step is called) and changing the opacity to 0 for the nodes in nodes_recolor() has no affect on the slowdown.
A potential fix is to create a separate version of the executable which does not have the nodes as part of the model file and doesn't have a OpenGL window, and have this new executable solve IK on the main program's behalf as a child process.
Another potential fix could be to somehow temporarily change the number of bodies, geoms, and joints in the MjModel structure before trying to solve IK so that the model effectively doesn't have any joints while the solver is running.
The text was updated successfully, but these errors were encountered:
It was observed that the IK solver took about 10 times longer to solve the same perturbation when moving from this commit to this commit. Next, I isolated the problem, and found that doubling the nodes in the cassie.xml file was causing the solver's performance to deteriorate.
In fact, removing all the nodes from the cassie.xml file, changing the NODECOUNT in main.h to zero and applying perturbation with Ctrl+P runs nearly twice as fast as the less slow commit. The problem has nothing to do with rendering/visualization because there are no scene updates while IK is being solved (just mj_step is called) and changing the opacity to 0 for the nodes in nodes_recolor() has no affect on the slowdown.
A potential fix is to create a separate version of the executable which does not have the nodes as part of the model file and doesn't have a OpenGL window, and have this new executable solve IK on the main program's behalf as a child process.
Another potential fix could be to somehow temporarily change the number of bodies, geoms, and joints in the MjModel structure before trying to solve IK so that the model effectively doesn't have any joints while the solver is running.
The text was updated successfully, but these errors were encountered: