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