Hi Jakob,
Thanks for posting those samples - they are useful for the discussion! Two questions:
1. What would be the purpose of having a -shared- spec for rigid bodies + constraints or movements? If the usage of this data is different in different applications, the rigid body and movement spec would represent only part of the user's work.
For example: a physics simulator can build a model with rigid bodies and movements, but it needs physics data (torques, friction, etc.) to make the model move.
The model is then moved to an editor that supports animation. The rigid bodies and movements are available but there are no poses or key frames to make the model move.
I think you are correct that -some- pieces of movement data (rigid bodies and very simple movement) are common to a lot of applications. But if this represents only part of the program's "document", what are we hoping to accomplish with an interchange format?
2. You specifically mentioned hierarchy, and this is an interesting requirement:
- Some programs may -require- a movement hierarchy for their models to run. For example, an IK solver might require a hierarchy.
- Some programs may -require- cyclic graphics (e.g. not a true tree). For example, a physics simulator for the oil derek model needs cyclic graphics in order to be able to describe all constraints.
Does requiring a hierarchy leave out some use cases? Are there programs for which a hierarchy is mandatory?
(In my example of hierarchies in the animation world of games, a hierarchy is a very common, but so is "pose" data. The game industry solution to the oil derek is to make it a tree by breaking one of the constraints, but saving pose data so that the removed constraint is never violated in any given pose. In other words, the extra constraint is "pre-processed" and saved as pose data.)
Finally, a comment on deformable parts: cables and tubes are deformable in the real world, but we don't have a direct representation of them in LDraw. It is not useful to be able to "skin" in a modeling format unless you can skin different parts of a triangle differently. Since .ldr compositions reference parts atomically ("this is where the brick is") there's no logical way to specify skinning. We'd need new core modeling primitives in the .ldr format before we could utilize skinning at the animation level.
(LSynth sort of solves this problem by creating an LDraw readable proxy for the deformable part via a large number of other parts. If the individual constraints are animated, an ambitious program could re-generate the LSynth output per-frame based on the new animated locations of the constraints.)
cheers
Ben
Thanks for posting those samples - they are useful for the discussion! Two questions:
1. What would be the purpose of having a -shared- spec for rigid bodies + constraints or movements? If the usage of this data is different in different applications, the rigid body and movement spec would represent only part of the user's work.
For example: a physics simulator can build a model with rigid bodies and movements, but it needs physics data (torques, friction, etc.) to make the model move.
The model is then moved to an editor that supports animation. The rigid bodies and movements are available but there are no poses or key frames to make the model move.
I think you are correct that -some- pieces of movement data (rigid bodies and very simple movement) are common to a lot of applications. But if this represents only part of the program's "document", what are we hoping to accomplish with an interchange format?
2. You specifically mentioned hierarchy, and this is an interesting requirement:
- Some programs may -require- a movement hierarchy for their models to run. For example, an IK solver might require a hierarchy.
- Some programs may -require- cyclic graphics (e.g. not a true tree). For example, a physics simulator for the oil derek model needs cyclic graphics in order to be able to describe all constraints.
Does requiring a hierarchy leave out some use cases? Are there programs for which a hierarchy is mandatory?
(In my example of hierarchies in the animation world of games, a hierarchy is a very common, but so is "pose" data. The game industry solution to the oil derek is to make it a tree by breaking one of the constraints, but saving pose data so that the removed constraint is never violated in any given pose. In other words, the extra constraint is "pre-processed" and saved as pose data.)
Finally, a comment on deformable parts: cables and tubes are deformable in the real world, but we don't have a direct representation of them in LDraw. It is not useful to be able to "skin" in a modeling format unless you can skin different parts of a triangle differently. Since .ldr compositions reference parts atomically ("this is where the brick is") there's no logical way to specify skinning. We'd need new core modeling primitives in the .ldr format before we could utilize skinning at the animation level.
(LSynth sort of solves this problem by creating an LDraw readable proxy for the deformable part via a large number of other parts. If the individual constraints are animated, an ambitious program could re-generate the LSynth output per-frame based on the new animated locations of the constraints.)
cheers
Ben