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