Adding simple mechanic tags as a recommendation to standard

[Jakub Trznadel]

All,

I've spent quite a lot of time recently working on my webgl viewer/robot simulator. While creation on robot simulator targetted at children is my primary goal, I made ldraw viewer as it was neccessary to create rendering backend. I am not very good at creating objects in CAD, being rather a programmer. Frankly, I would not succeed without having such a great resource as ldraw.org library is. Thank you!

The reason I write here is because CAD files does not contain any hints about mechanical nature of models. While some movements are definetly too dificult to model with simple description language, there are plenty of situations which can be modelled by rotation/shift axis and min/max values for movement.

I tried to check other applications to figure out if there is any format that I could reuse for my needs. But I havn't found anything suitable. That is, my best understanding is that:
- ld4dstudio - uses information in higher-level files,
- ldcad - uses LDCAD-extensions (0 !LDCAD ... ) to define LDCAD-specific GROUP, plus lua language to control it,
- brigl - uses BRIGL-extensions to define animation (0 SIMPLEANIM )
- sr3d - seems to be most suitable, but I do not have sr3d license to try animation. As far as I understand new tags are added to describe scene.
- my viewer - added my-specific-extension to define engine rotation group, color/distance sensor position, and scene (0 MOTOR_AXLE), plus NXT-inspired graphical language to control (not really mature yet).

Not sure if this list is complete. My question is: is there interest to create common standart to define simple mechanics? Or at least: common groups that are connected without any movement possiblity?

For example:
- I would like to add something that could describe crane and wheels rotations to small crane model.
( for example: 4838 model. )

- I would like to add groups to techincs/mindstorms models that have gears: couple of groups with one control (+scale).
( for example: 8464 model )

- I would like to have mindstorms-engine part with description that some part of the model does rotations.
( for example: my industrial - the orange part of engine does not rotate )

- It could be nice to have minifig-rotations inside minifig models.


I have a feeling that instead of implementing my own-incompatible way, it could be reasonable to define some common standartized extension so each project could (at least: partially) reuse models created for other. Also, I do not want to implement CAD on my own.

I am looking forward for any feedback on this idea

Thank you,
Jakub

[Roland Melkert]

This kind of information is essentially an extension of part snapping information as it describes the level of freedom something can rotate/move.

Which brings use to the often discussed inclusion of such snap info into the official library. Which would be great but is very hard to get off the ground standardization wise, as it would take loads of time and effort to setup a spec and add all that info to the parts.

And also I'm still not sure it's even possible to do a universal snap info spec as the kind of data needed depends heavily on it's purpose within the software using it.

So the official spec/info would (imho) ether end up as

• very basic (some tools still need to (re)define extra info in order to do what they want). Although this is of course better then nothing at all.
  
• or extremely complicated making it very hard to implement.
  

Or did I misunderstand you and do you only want to setup a general / standardized way for defining groups (including e.g. rotational freedom params etc) within LDraw files?

[Jakub Trznadel]

I was thinking of something basic, but common and standarized. Please find rough idea below:

---[ simplest version ]---

0 ANIMATION_GROUP <group_id>
// elements belonging to particular animation group. another animation_group can be nested.
// Need some special "magic" group id value (like color 16) for referenced elements like engine rotor.
0 ANIMATION_END

---[ extension1: more complete version - the one I would like to have ]---

// movement: rotate or move. Has to be defined for each group_id:
0 ANIMATION_ROTATE <group_id> <variable_id> <x_point> <y_point> <z_point> <x_axis> <y_axis> <z_axis> <scale>
// or
0 ANIMATION_MOVE <group_id> <variable_id> <x_axis> <y_axis> <z_axis> <scale>
// not sure if it is neccessary to have another "combo" or "matrix" ?

// optional constraints: doors in the cars, steering wheel, etc.
0 ANIMATION_CONSTRAINT <variable_id> <min> <max>

// plus additional tag to make it possible for referenced object to move its moving part (NXT engine)
0 ANIMATION_REFERENCE <variable_id>
1 .... nxt_motor.dat

---[ extension2: complicated version that can be hard to implement ]---
// define mathematical equation to calculate one variable based on another one.
0 ANIMATION_CALCULATE <variable_id1> = complicated_interpreted_math_formula_in_unknown_language( <variable_id2> );

---

Where:
<variable_id> - is a variable. It can have minimal and maximal value defined as a constraint.
<group_id> - is same group blocks will move together. Can be number or string. String prefered.
<scale> - is a number.

Some additional thoughts:
- Probably ANIMATION_GROUP is slighly similar to !LDCAD GROUP_NXT tags.
- ANIMATION seems to be bad word to define mechanical interaction. MODEL is better and precise, but more people will understand ANIMATION
- There is lack of :
-- way to define pneumatic interaction,
-- way of defining movement behaviour (car, plane, tank, bike, ship, etc.)
-- standarized way to define NXT sensors location (but some group_id's can be reserved for it)
-- more complicated constraints.
-- mechanics (force, mass, rotational moments, spring, collision, torque etc.)
-- animation, despite tag name

For most objects it is enought to have extension1. Exceptions that I have in mind at the moment:
- cardan joint (non-linear movement),
- rack and pinion steering mechanism (only works for small angles),
- mechanisms from 8248.mpd (probably?)


In my opinion, having common standarized version even of the simplest version will make interoperability easier.
Extension1 shall be enough for most objects, while extension2 can be problematic to implement.

I am looking forward for any comments

Regards,
Jakub

[Roland Melkert]

This seems very specific to me, and there for not something to be standardized.

You probably better of defining your own extensions using eg "0 !WGLDV ....." prefixes in ldr/mpd's only (using wrapper ldr for single .dat's when needed).

That way you keep full control of the parameters. Although I suggest you make them forward compatible to prevent the problems we now have with the type 1..5 lines (unable to add extra info).

(sorry but) I'm also not completely sure what you want to do with the meta's, are they to describe the animation sequence itself. or only the skeleton system through group like metas, keeping the sequence (blocks) info stored somewhere else.

If you just describing the skeleton system I would be interested in sharing/developing the definition together so I could also use it in my LDCad as I too am looking into a more gui oriented approach of creating skeletons to animate using groups.

[Jakub Trznadel]

Defining my own way is definetly the way I would like to avoid (if possible). I would love to share

I prepared some graphics to show the idea. First is animation groups: I want to define objects that does not move in relation to each other in one group.



By defining the name or number for each group, I can pick them with my prefered language (lua/nxt/other) with ease. This is what I do propose with simplest version. Nothing more.

---

First extension of my proposal is to define how animation groups move with relation to each other.
Lets take rotational movement as an example:



I can define animation group 2 position as a rotation in relation to group 1, having rotation axis and rotation point (ANIMATION_ROTATE).

But there is problem with group 3, that does rotate in relation to group 2. Thus my statement: animation groups can be encapsulated with each other (which solves group 3).

Similar mechanism can be defined for linear movement, where only linear vector have to be defined. (ANIMATION_MOVE)

---

Next thing is that some animation groups can be connected with gears. They do rotate around different rotation axis/point, but with same proportional speed. This is why I do introduce <variable_id> and <scale> - variable will connect animation groups. And this is variable that shall be exposed to scripting language (lua/nxt/other)

---

The last thing is most complicated - when only part of referenced object will rotate (like NXT engine rotor). This requires mechanism similar to color 16/24 that can be inherited by referenced object.

---

I do believe that this fits into 'skeleton system' definition. And I would love to use LDcad for complete definition of my models, without using notepad-way :-)

Best regards,
Jakub Trznadel

[Nicola]

It look like you're trying to define an animation system and a "kinematic solver", where you define some interactions between parts (ie gears, pistons, etc) and the whole system get in motion, or am i wrong?

As for brigl, it works by identifying "rigid groups" (your animation group, IIUC) with submodels. This way i didn't have to invent something new, and you can easily define the center of rotation of a submodel by placing it relatively to the origin (0,0,0).
I then tag animable submodels with the "ANIMATED" command which also gives a name to the group. Then at top level i define some animations, which are transformation on ANIMATED parts that can be chained, or in parallel, etc.
See an example here (mpd source)

This is a solution for animations only, i designed it to be able to show the "play feature" of my models. It doesn't deal with connectivity, mechanics, etc.

As i said, i used submodels to define a "tree" of subassemblies in relation with each other. This becouse the ldraw file format define a "flat list" of parts without the possibility to define a hierarchy. My solution of course have some problems, first of all it interferes with building instructions (BI submodels don't always coincide with Animation submodels).

If i'm not wrong, brigl animations looks similar to your "extension1", the difference being that in brigl animations are predefined, meant to be "started" with a button and watched, while your proposal define a range of possible movements and the user would be able to interact with them.

[Jakub Trznadel]

The solution I currently have is also very similar to yours - only one tag defines start & end of rigid group. Rotation matrix and rotation point is taken from element that immediately follows it. ( industrial.mpd )
You are right that I want to define "kinematic" with a "proportional solver" for most common and simplest things. And I also want it to not interfere with STEPs.

Problems I encountered with my applicatiion made me thinking of making something more universal and ... err... common than I did.

That is:
- rigid groups may be different than building steps as you noticed. Thus I propose to add another grouping mechanism,
- some parts have both static and rotating parts (NXT motor),
- things connected with gears shall have one variable to control it,
- some element does not rotate, but move straight.

If I understand correctly, your SIMPLEANIM ANIMATION does define:
- minimum and maximum constraint (by defining animation, not straight),
- rotation axis. rotation point is given by object that immediately follows ANIMATED tag (similar to my current MOTOR_AXLE)
- sequence of things to happen that defines animation,
- .. and it allows nesting.

If we could share common way of defining these, I could use your model and control it with NXT-inspired way
And you could take mine to define animation on mindstorms model I am most interested in developing.
Good standard design could define separately animation and kinematic parameters. For example:

0 SIMPLEANIM ANIMATION Deploy 1500 ENABLED CHAIN Tip DEF [cannon ROTATE 1 0 0 -1.000 Cubic.InOut]
will become
0 RIGID_ROTATE cannon cannon_angle 1 0 0 //<optionally: x0,y0,z0>
0 RIGID_ANIMATION Deploy 1500 ENABLED CHAIN Tip cannon_angle -1.000 Cubic.InOut
( and optionally: )
0 RIGID_CONSTRAINT cannon_angle 0 1.5708

and ( due to rigid groups shall not interfere with steps paradigm )

0 SIMPLEANIM ANIMATED tip1
1 8 20 -22 -200 1 0 0 0 1 0 0 0 1 tip1.ldr
will become
0 RIGID_GROUP tip1
1 8 20 -22 -200 1 0 0 0 1 0 0 0 1 tip1.ldr
0 RIGID_GROUP_END

I do not have final solution implemented, so I am very open for discussing any details/changes

Best regards,
Jakub Trznadel

[Roland Melkert]

Not interfering with step (and mpd structure) is why I choose the somewhat more complicated solution with LDCad.

It doesn't have the start end metas for grouping things because it also preserves the listing order of items in a group and as items might belong to more then one group (for use in different animations for example) I decided to only support a group_nxt meta.

The setup also allows for grouping of items located in different files through recursion. As a result you can create groups completely independent of the file structure and part placement order.

You then manipulate these groups through lua scripts, but I too would also like to offer a more gui approach for setting up group relations in order to do more event triggered animations without having to write complicated group placement scripts.

So I would be very open to an open/universal set of metas for describing group relations.

[Roland Melkert]

I see,

The rotation center could (should) be part of the groups it self. Leaving the relations between group to a new (set of) meta's.

maybe something like

0 !JOINT [name=main] [group=someGrpId]
0 !JOINT [name=arm] [group=someOtherGrpId] [parent=main] [from=0 0 0 1 0 0 0 1 0 0 0 1] [to=0 0 0 1 0 0 0 1 0 0 0 1] [rotVec=0 0 1] [rotLimits=-30 30]
etc

This is basically how I did things in LD4DStudio but instead of groups it used submodels and the info was stores in xml not the ldraw file it self.

[Jakub Trznadel]

I have spent some time looking at ldcad examples trying to catch up the current implementation. And I have some questions.
- you want to preserve order of elements within a group. Why?
- I am confused by an idea that one element belongs to more than one group, but I understand that one group can be nested within other (like in my example with animation groups 1,2,3). If this is different, could you share/describe animation example based on some existing model for me to catch this idea?
- ... and what is GID

Small off-topic:
I have a feeling that writing animation in lua scripts by defining position matrices mades this functionality available only to small group of individuals feeling comfortable with university-level algebra and programming. Wouldn't it be better in lua to write something like:
ldc.setAngle( 'steering_wheel', 30 /*deg*/);
ldc.setShift( 'steering_plate', 15 /*mm*/);
?


Regards,
Jakub Trznadel

[Steffen]

as far as I can see, defining the animation groups should be your smallest problem.
you simply need to put them each into its own .ldr file.
when doing this, you can freely choose where the origin in that file is.
your whole scene then simply would be a composition of these separate files
(which, of course, can reference each other).
This way you completely get rid of the necessity to invent a new syntax for animation groups.
And you also completely get rid of finding a syntax to name them: their name is simply their filename.

Which leaves open the animation scripting task, to which I cannot write here yet more because I have not thought enough about it yet...

[Jakub Trznadel]

Steffen,

Putting animation group into .ldr is a good idea and very simple. This way is used by brigl and ld4d as far as I understand, but not in mine webgl viewer and not in LDCad. There are some problems with definition of animation groups together with .ldr:
- STEP commands. Not always every element within .ldr shall move, so I can either use .ldr for building steps or for defining animation groups,
- Engines. When I want to use NXT motor part, its rotor does rotate, but the rest - not. No way to express that.
- Gears. IMHO it would be good to define parts connected with gears in one 'animation variable', consisting of couple of animation groups.

My current syntax (just one tag with one parameter) in important aspects works as you have described (without depending on .ldr, but could use it). And it fails with "engine rotor" and "step" problems (but handles gears).

I spend some time analysing other formats that are in use, namely: brigl, ld4d, ldcad, and took a look at sr3d. All defines the same thing (ANIMATION GROUP) in different way. All defines rotation axis in their way. This is something that can be shared between as a common format.

Regards,
Jakub Trznadel

[Jakub Trznadel]

My feeling is that it seems to be very close to what common format shall contain.

I do not fully understand 'from' and 'to' 4x3 format. Is this a way to express linear movement?

Regards,
Jakub

[Roland Melkert]

you want to preserve order of elements within a group. Why?

Two main reasons really the first element in a group is used as it's center point, and second I wanted it to be possible to do 'fun' things with the items in a group combined with loops in scripts (e.g. hiding parts in a certain order over time).

I am confused by an idea that one element belongs to more than one group

For example group1 in model A uses some recursive items from model B, but model B has also a local group which uses some of those same items. This is possible because you could use model B without loading model A to do some very different animation needing different group configurations. The format even allows for different group configurations in the same model which is needed by a new feature in the upcoming 1.5 version.

and what is GID

GID is the global id (pseudo GUID), needed because user given group names might not be unique across the whole model tree, as so could also load just a sub branch of the bigger recursive model.

I have a feeling that writing animation in lua scripts by defining position matrices.....

Current animation stuff is very low level as I'm hoping to add more and more layers to the system, so future versions might also have gui only animations but internally it will (if needed) generate those lua scripts for you, while leaving the option for more advanced users to do everything them selves to maintain full control.

[Roland Melkert]

those 4x3 ldraw matrix lines tell how to connect the two groups together. You could do with only a position if you decide to always work in the top level model's workspace and take the model's state as the actor/skeleton's resting state but I like to leave options

[Ben Supnik]

Hi Jakob,

I fear the term 'animation' is a little bit confusing in this context, because there are a number of different use cases for "movement tree structures", and the game industry already uses them with a very specific meaning and calls it "animation".

I think here are a few separate problems here:

We can take a big pile of bricks and group them into rigid groups. We can also define how the rigid groups are constrained (e.g. this point rotates relative to this group).

There are two very different approaches to this.
- Physics engines define the linkage between rigid groups via _constraints_. The constraint indicates what relative motion of the rigid groups are legal and illegal. Imagine a crane with a pneumatic cylinder that "lifts" an arm by changing the length of one side of a triangle. The cylinder doesn't lend itself well to a parent-child relationship. Rather the cylinder has two constraints - each constraint ties one end of the cylinder to a fixed point on some part of the crane - the two ends of the cylinder are not connected to the same group.

- Animation engines typically just define the hierarchic relationship, e.g. the hand is a child of the arm, the arm is a child of the body, etc.

Physics engines need the more complex constraint network so that they can -determine- what motion is possible from first principles by applying forces.

Animation engines typically have all legal motion _pre-calculated_. In a game animation engine, if you want to animate the crane, one end of the cylinder is a child of the crane, and then an animator creates the data to manually "pose" the other end of the cylinder so that it looks like it is attached.

(In real life the guy doing your animator may have a very expensive 3-d program that will do the physics for him and save the results as an animation. The animator describes the cylinder as connected on both ends, and the animation program calculates the poses so that the model "stays together". The game engine then just repeats the animation that was saved.)

The problem we face as app developers is that users almost certainly want the first functionality, but the second functionality is much, much easier to implement.

A few comments on both problems...

PHYSICS

From what I have researched, if you want to be able to derive the possible motions of a model completely from modeling, you would need:

1. Connectivity data on parts. This has been done by several models already and I think a "snapping" system is adequate. Bounding boxes for collisions are also needed if you want to block illegal motion. Your app would have to use the connectivity to build:
- The rigid groups and
- The constraints that link them. (E.g. if two groups are linked by a 1x2 hinge, you can build a constraint to solve this).
2. A physics engine to help derive legal motion. The good news is that there are several open source options here. I looked briefly at bullet and ODE (open dynamics engine) - there are others too but I was lazy and only looked at the ones with the best web docs. :-) Anyawy, they all let you do more or less the same thing:

- model your rigid bodies.
- model constraints between them.
- apply forces.
- time step a simulation to "see" what happens.

If your goal is to simulate robots, this might be everything you want to do - e.g. the physics engine is going to drive your robot.

ANIMATION

If the goal is to make "playability" of models, it would be useful to be able to _save_ the derived motion that the physics engine "figured out". Here the game industry provides some standard solutions. This is a summary of the common features of model animation from a bunch of 3-d game engines.

1. The "rigid bodies" in the system are called bones - think of the bones in a skeleton.
2. Bones are organized in a tree structure so that bones moving relative to bones 'just works'.
3. The relationship between bones is described by a transformation matrix, so that combinations of rotation and translation are possible. The fine print of the 3-d engine describes what interpolation will be used (interpolating between matrices isn't necessarily as simple as interpolating each of 12 components).
4. Each vertex of the model is attached to one _or more_ bones. (This last feature is called "skinning" - by having a vertex that follows an average of multiple bones, soft mushy features like skin on people can be modeled cheaply. I think this feature is relatively unimportant for legos, particularly since we do not have -deformable- parts.*) In our case, we could live with each rigid group being attached to a bone.
5. A "pose" is a set of specific values for the transformation matrix that "moves" the model (or _part_ of the model) into a certain position. For a game, a monster model might have a "sitting" pose and a "standing" pose.
6. A time-based sequence of poses is an animation - thus the animator can model walking by specifying 5 or 6 poses and letting the engine fill in between them.
7. The engine typically has some logic for blending between poses, e.g. if the game engine wants to have the monster walk AND swing its sword, those can be two animations - the blending logic decides (for each bone-to-bone matrix) which animation sequence overrides. Blending of animations gets pretty specific to the particular engine.

Reading some of the proposals here, a lot of them look like the animation system we have in X-Plane. This is a little bit scary to me because I built that animation system 10 years ago, with no awareness of what the rest of the game industry was doing, and we've really its limits. At a minimum please consider:

- Separating the bone hierarchy from the model itself - "attach" the model to the skeleton, don't built the skeleton _out of_ the model.
- Keep the representation of animations relatively generic, e.g. key-framed transform matrices, rather than inventing an operation for every kind of motion we want.

These things would keep the _data representation_ very generic. Apps that play back animation can implement the spec once and apps that -create- the animation can do whatever they want and then save in this representation.

I hope that made some sense!

Jakub, for what it's worth, I'm starting to look at motion in Bricksmith and, like you, I'd like to see something that has wider scope than "app-specific".

Cheers
Ben

* E.g. there's no information in the sail parts describing how the interior of the part moves as the corners are pulled in different directions.

[Jakub Trznadel]

Ben, All,

I certainly want to provide users with 'second' functionality (physics), with NXT-inspired language to play with. At the moment it is possible to run line-follower simulation (and couple of other simulations) within my viewer :
http://trybikowo.pl/ldraw/index.html?leg...omabot.mpd

The thing that I believe can be shared as a extension to standard is 'first' functionality - rigid groups (bones) definition, maybe with declaration of rotation and shift movement axis in relation to each other (kind of constraint), in some kind of tree. This allows animations like this one: (I've used this one as a demonstration of robot kinematics at children university, sorry for polish language )
http://trybikowo.pl/ldraw/index.html?leg...boarms.mpd

Some animations cannot be expressed with such approach, and require complicated calculation (similar to your cylinder example):
http://trybikowo.pl/ldraw/index.html?leg...oilrig.mpd

Regarding deformable parts: I believe that cables can be consired a deformable part. I am unsure if your point 4 (skinning) is strong enough to model them properly - probably not.

I am not interested in "pose"-based modelling right now, but they could be used to model lego figures walking sequence, or happy/sad switch.

I think that bone hierarchy shall be contained within model file in similar manner as (for example) lpub stores its extensions. This approach is used by (at least) ldcad, brigl, any my viewer. (ld4dstudio uses external definitions). I prefer to store it internally within file for maintenance reasons - if I want to change the model, I can do this in CAD and it will preserve the bones definitions.

For my needs I need 2 movements: shift and rotation. They can be considered as a constraints. Other parts (physics, NXT-program) are not a part of model file in my case.

I do have problem to define bricks where some part of brick moves in relation to another part - like NXT engine rotor vs body. While - sure - I can use brick 'subparts' to define proper animation, at the same moment I am breaking possibility to use this model in lpub.

---

So my proposal is to define _only_ rigid groups and possible movements: rotation and move - in hierarchical structure. This is similar to definition of bones as I understand them.

I do not want to define the application for which they will be used. They can be:
- simple animation (as in brigl),
- complex animation (ldcad, sr3d),
- robot simulator/mechanic education (my goal),
- movie creation (ld4dstudio),

Whatever the app is, all needs to define rigid groups (bones) and basic movement structure. This can be shared.

Ben, thank you for all the description/comments you wrote; I really appreciate them

Regards,
Jakub

[Ben Supnik]

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

[Jakub Trznadel]

Ben, All,

1.
If I want to make animated model, I have to:
- make a model in a CAD,
- hand-edit it in text mode to add my specific tags for rigid group definition,
- write some script (in my nxt-inspired way).

It is not that I do not like to hand edit text files... but I would prefer to do this in CAD. And - then - I could use this model either for my own needs or do some movie, or do anything else without adding app-specific tags.

Also, I see that LDCAD, brigl, my own viewer are having more-or-less similar systems for rigid definitions. LDCAD also stores animation separately as a LUA script, while rigid definition is stored internally in a file. No one tries to achieve universal physics engine as far as I know - animation/physic is left to some scripting or hardcoded. (I do not have sr3d, so I cannot comment on it).

That is, in my case I model most of engines as a first order inertia. Other behaviours ( car, tank, slip, etc.) are defined separately in simulator. I do not believe that they can be shared.

2.
What I mean by hierarchy is to be able to express models like SCARA arm. It does require hierarchy.

Models like oil derek either require making cycle in hierarchy (and IK solver), or expressing the constrain as a rather complicated math formula. Currently I am using second option, but I'm not enthusiastic about it. I guess that it somewhat fits "pose data" definition that was mentioned.

3.
I agree about lsynth and deformable parts.

Regards,
Jakub

[Jakub Trznadel]

Roland, all,

Sorry for late reply, I had to study, experiment a little bit and rethink it first;

I am still confused about idea of element in two groups... do you have some real example of it to share?


---
I do also use first element in a group to define its center point (and rotation axis etc.). However, in my case I use first element after rigid definition.
Most of the time it works, but sometimes I have to do something like:

// rigid start
0 MOTOR_AXLE 3 1
1 0 0 0 -50 0 0 1 -1 0 0 0 -1 0 noop.ldr
1 0 40 0 -100 0 0 1 -1 0 0 0 -1 0 32270.dat
....
// rigid end
0 MOTOR_AXLE -1
...
//and at the end of the file:
0 FILE noop.ldr
// empty

...in order to maintain possibility to use same model for lpub - rotation axis is not always the first element in building instruction.

Regards,
Jakub

[Roland Melkert]

I am still confused about idea of element in two groups... do you have some real example of it to share?

Well you might need it when you want to make multiple animations using the same model, where each animation needs a completely different set of groups (whom can have overlap).

Groups will also probably overlap when you want to create a motion animation and a building instructions animation using the same mpd/ldr tree. e.g. a steering arm and it's wheel etc (BI sub assemblage), which will be a single group in the BI but multiple ones when you want to animate the steering mechanics.

[Ben Supnik]

Hi Roland,

The alternative to multiple group sets is:

The "most atomic" groups are specified. So if two groups (in your model) have a subset of common parts, in my model _three_ rigid groups are defined: the common parts, and the unique parts for each group. Each of your groups is a set of groups in my model.

The advantage to your model is the groups are bigger and there are fewer of them - animations that are not used once the model is complete do not make the model more complex.

But I would argue that if there are different animations using different overlapping groups, then the real model simply has a more complex potential set of actions than either animation describes. We would not say that a minifig does not have moving legs just because we are only animated its head moving. :-)

Building the model is a different and trickier problem, because a set of parts might have reasonable motion in one step but not another. For example, you build a quad out of technic bricks and pins. It has four rigid bodies and two degrees of freedom.

Then in a later step you apply a diagonal brace. The whole structure is locked and it is a single rigid body. My model does not handle this case well.

I think building instructions are a particular case where we might want to consider an extension particular to "build by animation" (e.g. a model where something is built in one position and moved later) - the motions are really 'edits' to the model that fundamentally change it.

cheers
Ben