| |
1. .DAT Praises
The DAT file and the possibility to use Type 1 lines in DAT files to call on
other DAT files is so versatile, so brilliant, so LEGO. It's the foundation
that has made LDraw The standard for virtual LEGO. There are details that
weren't fully developed when JJ passed away, but it doesn't matter that much,
compared to the possibilities the DAT standard brings at hand.
2. .DAT Under Attack
For different reasons, but mainly because the LDraw format wasn't perfected as
mentioned above, it has been "under attack" by new standards. We now have .LDR
extension, the .MPD format, and some META-statement, unknown to original LDraw.
(No, I'm not complaining; most changes and additions are great advantages). But
the disadvantage is leaving the original simplicity behind and thus creating
confusion.
3. The Three Paths to LEGO Animation
As far as I can see, there are 3 ways to create LEGO animations.
* Stop-motion using a digital [web] camera. So far, the most popular. We already
have hundreds of "Brickfilms" on the Net, and in this very moment, it is very
likely that many people are producing more.
+ Everything is ready to start making stop-motion Brickfilms. All you need is a
digital camera, some lighting, Lego props, and lots of time.
- If you don't own them, you need to purcase the parts needed for the film.
- It must be extremely time-consuming.
- If you get an idea of an improved detail while shooting the 295th frame,
you'll have to shoot all again from frame 001.
* CGI working with POV-ray code. I get the impression that this is what most
LDraw animtors use right now.
+ POV has a very strong build-in math engine.
+ It's powerful.
- Most things in the world of computers that are powerful, are also extremely
complicated, with a steep learning treshold, and the applications seldom behave
the way users expect.
* CGI working mainly with LDraw files. That's what I do, knowing that I'm in
minority. I believe this can turn out to be the fastest and most user-friendly
way to create CGI animations based on LDraw models. What you need is a PC with
the LDraw library, L3P, POV-ray, and software that joins a series of pictures
into video format. And you also have to fully understand the LDraw Type 1 line
format, because so far, this has to be manipulated by hand.
+ I think it has the potential to become the quickest and easiest way to animate
Lego models.
- I may be the only one to think so(?)
- There may come a day when we need to change the LDraw format to support
animation programs. That is, yet another "attack"...
- The key to the real breakthrough is still not yet invented. See next
paragraph.
4. The Missing Link (of LDA)
What I look for - what I need is preferably something like the .DAT format and
the Type 1 line to link all the ideas together into a working concept.
The LDraw Type 1 line has all information needed for the purpose it fills:
* A Color attribute
* x,y,z position
* Rotation matrix
* File reference to model/sub-model/part/sub-part/primitive/whatever LDraw
object
Simple and very effective.
Now, what additional information is required for animating an LDraw object?
And what would be the best format to store that information?
If we start with a minifig (keeping in mind that there are other objects apart
from minifigs that need to fit in the format!), what are the proprties we need
to work with?
* Of cousre, first we need to define the minifig. So far, LDA has created the
minifigs with the Create... button, but I want to be able to pick an existing
minifig model, or even extrude minifigs from larger model files. I think the
present LDraw .ldr format is perfect for this. All that needs to be added are
some REMs that indicate that next line is the RightLeg child object and so on.
If any minifig generator application already makes these remarks, I could
implement them into LDA and suggest them as a standard.
* Then comes the hardest problem: Defining the movement and storing it into a
file. So far, I have the <object>.DeltaX, <object>.DeltaY, and <object>.DeltaZ
commands in the script .txt file to define an object's linear movement relative
to its parent and the hard-coded movement <object>.MFWalk:
if GetRAM(sss+'.MFWalk', '<none>') <> '<none>' then
begin
/// CODE SNIPPED ///
Progress := FrameI / FramesPerLoop;
if Progress > 0.25 then ii := 1 else ii := 0;
if Progress > 0.75 then ii := 2;
case ii of
0: v := 2.7925 * Progress;
1: v := 1.3963 - 2.7925 * Progress;
2: v := -2.7925 + 2.7925 * Progress;
end;
sn := NFormat(GetIndex(GetRAM(sss+'.Name','GetRAM Error')+'.LeftLeg'));
PutRAM(sn+'.E', FTS(cos(v)));
PutRAM(sn+'.F', FTS(sin(v)*-1));
PutRAM(sn+'.H', FTS(sin(v)));
PutRAM(sn+'.I', FTS(cos(v)));
sn := NFormat(GetIndex(GetRAM(sss+'.Name','GetRAM Error')+'.RightArm'));
PutRAM(sn+'.E', FTS(cos(v)));
PutRAM(sn+'.F', FTS(sin(v)*-1));
PutRAM(sn+'.H', FTS(sin(v)));
PutRAM(sn+'.I', FTS(cos(v)));
... and so on, defining a minifig and its child objects' movement relative to
itself.
If only I could replace that hard-coded MFWalk with key frames with clock
information into an LDraw style file, I think that animation party could really
begin!
Here's the Master ldr file of a little animation I made a couple of weeks ago:
http://web.telia.com/~u66203131/LDA2005/@a01a.gif
(An apllication with support for STEP and CLEAR would have produced a series of
pictures from this Master model) And here's the result of this humble test
script:
http://web.telia.com/~u66203131/LDA2005/a01a.avi
What I mean is that the GIF file from the Master gives a good idea of how the
animation will look like when rendered. And so could an animation definition
file in the LDR format also work.
Or maybe the best way would be to let the LDA script call another LDA script?
Just like DAT files are able to call other DAT files! (I just had this idea
while I wrote it!) Well, the script format does not support that clock and
Trigometric functions yet...
So, how would the final syntax look like when that missing link is found?
Minifig01.Import scene.ldr c x y z a b c ... h i mffile.ldr
and:
Minifig01.Animate MFwalk40.ldr (if using the LDR format)
or:
Minifig01.Animate MFwalk40.txt (if using the LDA Script format)
Yes, I think one of those two options might work!
What do you think? Can you follow my reasoning? Any ideas?
/Tore
|
|
Message has 2 Replies:
 | | Re: Thoughts on File Format for LDraw Animation
|
| One more thing I forgot to mention: I am a lowsy programmer, so don't judge the LDA project by looking at its interface. It it primarly for testing my theories to see if they work. Just like I don't think anyone uses original LDraw anymore, I really (...) (19 years ago, 25-Oct-05, to lugnet.cad.dev)
| | | Re: Thoughts on File Format for LDraw Animation
|
| (...) <snip> (...) One of the weaknesses of the LDraw file format is that part instances do not have names. This makes it impossible to modify attributes about the part instance. The closest thing we have to date is named groups provided by MLCad. (...) (19 years ago, 25-Oct-05, to lugnet.cad.dev)
|
30 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
