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