| |
In lugnet.cad.ray, Miguel Agullo wrote:
> In lugnet.cad.ray, Tore Eriksson wrote:
>
> > I'm not a very skilled programmer, so I just develop the syntax and a very
> > simple interface. If I suceed to make demos impressive enough, I hope some more
> > skilled programmer(s) will make better GUI's and import filters and so on.
>
> Hi Tore,
>
> Congrats on your recent work.
Thank you, Miguel.
> The idea is that the TLAS user will build "scenes" by placing ldr / dat files
> into a "track". For Ldglite visualization (and other potential purposes), the
> program is now able to export the track contents as a single MPD file. In the
> future, it will also "import" complete scenes that way, breaking down the MPD
> file into its models. Further down the road, there are plans for more
> sophisticated uses (i.e. combinations of scenes, meaning combinations of model
> file with submodels which already have animation built into them, like a car
> with turning wheels).
As discussed earlier, I am now convinced of the animation potentials of MPDs.
As a (not very active, but yet...) member of the LDraw Standards Commitee, I am
also convinced of the benefits we all would enjoy if all existing minifig
generators would tag the parts similarly.
When it comes to wheels, I have been thinking of creating new or revised
shortcuts for all common wheel assemblies, to the convenience for all LDraw
builders, and with radius information for the animation programs.
> But I am getting ahead of myself. What I wanted to show you is how a TLA file
> looks like. And it looks like this:
Regular Windows ini files is a very good idea! It's a well established standard
and all programming environments have build-in functions that makes it easy to
handle them. It looks like, unaware of it, I was inspired by the ini file
structure when I created LDA's "RAM stringlist" as I call it. The only big
difference is that I can "lock" a value by using '!' instead of '='. This means
that I am able to use a standard animation for the pizza boy by just locking his
right arm at -90 deg's or prevent an object from returning to its initial values
when the animation script is re-read.
Now to my matter. It would be great if we, as far as it is possible, give
objects and properties the same names. If I got it right, my static Scene
corresponds to your Stage. I like my Scene better, but am willing to change it
to Stage if we mean the same and if it is a better term for the sake of
standardization.
As my built-in minifig generator currently makes obsolete code, I don't have any
name for Actor anymore. For the moment, it's up to the user to name it. And
anyway I like Actor better. Minifigs are Minifigs, but Actors could be Maxifigs,
Technic figures Fabufigs, large or small robots, animals or whatever we consider
more than vehicles or moving objects. So I will use the term Actor right away.
One problem is that I think your Actor's main object is its torso, and mine is
the hips part. One thing I've learned from studying other animation systems is
that the hip region is the main object by default. I find it more logical and
easier to work with, too.
Could your Step_Length correspond yo my FramesPerLoop? "Loop" is btw an
unfortunate term, because looping is just one of three planned for animation
modes. Loop, Once, and Ping-Pong. I think they are quite self-explaining.
I am willing to change my LeftArm into L_arm if this becomes the standard. Or
maybe we could both submit to the (IMO) leading MLCad.ini term LARM?
I don't understand L_arm_initial=0. Initial value of what? Angle? Position?
Clock or Progress? Not amplitude either.
> [Files]
> Stage=D:\3d\pov\LM\models\stage.ldr
> ACTOR1=D:\3d\pov\LM\models\fire.ldr
> ACTOR2=D:\3d\pov\LM\models\aviator.ldr
> [ACTOR1]
> Loop_Steps=1
> Step_Length=40
> Pitch=0
> Yaw=0
> Roll=0
> X_pos=-20
> Y_pos=0
> Z_pos=60
> Head_initial=0
> Head_amplitude=3
> Hips_initial=0
> Hips_amplitude=7
> R_hand_initial=0
> R_hand_amplitude=0
> L_hand_initial=0
> L_hand_amplitude=0
> R_arm_initial=0
> R_arm_amplitude=15
> L_arm_initial=0
> L_arm_amplitude=15
> R_leg_initial=0
> R_leg_amplitude=25
> L_leg_initial=0
> L_leg_amplitude=25
> [ACTOR2]
> Loop_Steps=1
> Step_Length=0
> Pitch=0
> Yaw=270
> Roll=0
> X_pos=30
> Y_pos=0
> Z_pos=0
> Head_initial=0
> Head_amplitude=0
> Hips_initial=0
> Hips_amplitude=0
> R_hand_initial=0
> R_hand_amplitude=0
> L_hand_initial=0
> L_hand_amplitude=0
> R_arm_initial=0
> R_arm_amplitude=0
> L_arm_initial=0
> L_arm_amplitude=0
> R_leg_initial=0
> R_leg_amplitude=0
> L_leg_initial=0
> L_leg_amplitude=0
>
> TLA files are regular windows ini files which hold a scene description and
> animation parameters. I don't want to get into too deep into specifics because
> the format is likely to change quite a bit (it will suport non-animation
> parameters such as L3p settings and the animations will eventually go beyond
> cycle-based minifig walks, which means more animation settings to go into the
> TLA file). But I know you've played with the latest available GUI-based version
> of LMM and the parameters above relate to the settings of that program.
>
> Anyway, I hope all this is useful to you and - at the very least - that knowing
> that a GUI-based app that will (somehow) support LDA2006 adds to your project's
> tremendously positive energy.
>
> Cheers
Finally, I wish to emphasize that I don't see any rivalry between our systems;
some people may "think POV", while others (like me) "think LDraw". It may be a
very good idea to develop both ways. But of course, let's try to make them as
harmonized as possible.
/Tore
|
|
Message is in Reply To:
18 Messages in This Thread:
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
