Support parsing <Stick> elements in VSK

[jslee02]

Parsing VSK is addressed by #561, but the parser ignores <Stick> elements. Sticks are just visual objects and have nothing to do with dynamics simulation, but it would be useful to understand the structure with sticks.

I think, in the current API, a possible class for a stick is Entity, but Entity might not the best. To compute the line segment of a stick, we need the global positions of two markers the stick is attached, whereas, Entity serves for objects that exist within a single frame.

That being said, a new class would be necessary to represent these objects. Also, I'm considering to add external actuator that acts on interconnected bodies such as a spring connected to two different bodies. The new class would work for this external actuator as well. I haven't thought about the API for this class or even a name for it so it's fully open. I welcome any ideas on this.

[mxgrey]

I think it would make sense to create an extension to the Node class which supports being connected to multiple BodyNodes simultaneously. I can think of several ways of implementing something like this.

I believe the most reasonable way would be to have multiple Nodes, each one attached to one of the connected BodyNodes. Each of these Nodes would contain a std::shared_ptr to the connecting class (such as the Actuator or Stick).

We could implement a version that has a master/slave relationship between the distributed Nodes and a version where all the distributed Nodes are treated as equals. Ideally the connector class (e.g. Actuator or Stick) can also be treated as a Node itself so that you can call Skeleton::getNode<Stick>(stickName) to retrieve the shared connector class directly (instead of one of the distributed Node classes), but this may require some slight modifications to the current Node design.

[mxgrey]

This class would also be good for encoding closed loop constraints into the Skeleton, rather than having those constraints solely stored in the ConstraintSolver class.

[psigen]

I like this as an idea, but I'm not sure if I like the idea of the connector class having to float around.

Would it possible to have each node contain a shared pointer to some internal data structure that links them, and have all of the nodes themselves contain factory methods to make other connected nodes and accessors to shared properties?

[psigen]

Also, this seems like its own API discussion, perhaps we can open a new issue for "Closed-chains and other multi-node structures" and link to this? That would make it easier to track this discussion for anyone who isn't familiar with this specific API issue.

[mxgrey]

I agree with everything in your last two posts.

[jslee02]

:+1: to the idea of creating a separate issue for API discussion.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.