Passing the model information to OInK tasks, constraints before computations

[sjahr]

This highlights a need to possibly have tasks accept the scene in their constructor so that information can be pre-allocated at construction time.

The same thing happens with FrameTask re: getting the frame_id value for the joint.

Although, I do like the solver doing its own thing so that the scene usage is consistent. Maybe then the best approach is to have a setup() method in these tasks/constraints that is automatically called by the solver? Or at least we can just call solver.setup() and that invokes it for all the tasks/constraints/barriers?

Originally posted by @sea-bass in #147

[sjahr]

Yes, good point @sea-bass. I originally wanted to keep the constructor as lean as possible and the struct not depending on the scene but looking at it now it makes sense to do that. What do you think about just adding the scene to the constructor? Wouldn't a setup step just complicate things?

[sea-bass]

It would... but I was thinking doing it this way would be a hazard for people to use different scenes in different task constructors. But maybe I'm overthinking it.

[sjahr]

You're right, but maybe that's a risk worth taking for simplicity sake. And maybe there's even a wild case we don't see where you actually want that 😅 🔥