LDraw.org Discussion Forums
Adding simple mechanic tags as a recommendation to standard - Printable Version

+- LDraw.org Discussion Forums (https://forums.ldraw.org)
+-- Forum: General (https://forums.ldraw.org/forum-12.html)
+--- Forum: Official File Specifications/Standards (https://forums.ldraw.org/forum-32.html)
+--- Thread: Adding simple mechanic tags as a recommendation to standard (/thread-14626.html)

Pages: 1 2 3


Adding simple mechanic tags as a recommendation to standard - Jakub Trznadel - 2014-11-17

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 Smile

Thank you,
Jakub


Re: Adding simple mechanic tags as a recommendation to standard - Roland Melkert - 2014-11-17

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?


Re: Adding simple mechanic tags as a recommendation to standard - Jakub Trznadel - 2014-11-18

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 Wink
- 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 Wink

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 Smile

Regards,
Jakub


Re: Adding simple mechanic tags as a recommendation to standard - Roland Melkert - 2014-11-18

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.


Re: Adding simple mechanic tags as a recommendation to standard - Jakub Trznadel - 2014-11-19

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

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.

[Image: groups.png]

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:

[Image: groups_rotation.png]

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


Re: Adding simple mechanic tags as a recommendation to standard - Nicola - 2014-11-19

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.


Re: Adding simple mechanic tags as a recommendation to standard - Jakub Trznadel - 2014-11-19

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 Wink
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 Smile

Best regards,
Jakub Trznadel


Re: Adding simple mechanic tags as a recommendation to standard - Roland Melkert - 2014-11-19

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.


Re: Adding simple mechanic tags as a recommendation to standard - Roland Melkert - 2014-11-19

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.


Re: Adding simple mechanic tags as a recommendation to standard - Jakub Trznadel - 2014-11-20

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 Smile

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