| |
Ok, this post took me a long time to get through...
> > > For the intial scene, the LDraw
> > > parts (LDR files, or an MPD file and specific part) would be
> > > referenced and given object IDs in the top level of the file. The
> > > parts object would also include enough information to optionally
> > > override the default origin or orientation - which may make animating
> > > some components easier.
> >
> > Yes! I talk about overriding default origin here:
> > http://james.magnusviri.com/lego/animatable_models/
>
> Yes - I read that guide, and agree. The only awkward thing, which
> would apply to this technique, is that it may make building steps a
> little unnatural. Though you might be able to get it to look good in
> LPub...
Ah. I've never cared for instructions... I didn't take that into account when I
wrote the article...
> > > Keyframes would then be created as objects to which nodes along the
> > > paths or graphs may be assigned. The nodes themselves are a collection
> > > of objects inside the path container objects. The actual keyframe
> > > objects would store the timecodes, and once read into an API, probably
> > > have backrefs to the nodes that are assigned to it.
> > ...
> >
> > I'm lost. I've been reading about MEL, and I was VERY surprised to see that
> > MEL
> > uses a clock just like POV-Ray. It makes me wonder if the 2 systems aren't
> > that
> > different.
>
> How do you mean? All of the formats I know about use a clock...
I was only familiar with POV-Ray (well, I'm starting to be familiar with others
now that I'm reading) and I thought others were different, mainly because I've
read apologies for POV-Ray's clock, like it was a bad way of doing animation.
> <keyframe keyframeobjectid=1 timecode="000000">
> <!-- If you consider the length along a path segments as a floating
> value between 0 and 1,
> then, depending on your floating point precision - you can
> represent any point along that
> path with said value which we will call pathpoint. It is often
> mathematically known as t-->
> <node pathid = 1 pathpoint = 0.0 model = 1/>
> <node pathid = 3 pathpoint = 1.0 model = 2/>
> </keyframe>
> <keyframe keyframeobjectid=2 timecode="002400">
> <node pathid = 1 pathpoint = 0.5 model = 1/>
> <node pathid = 3 pathpoint = 0.2 model = 2/>
> </keyframe>
> <keyframe keyframeobjectid=3 timecode="003500">
> <node pathid = 3 pathpoint = 0.8 model = 2/>
> </keyframe>
> <keyframe keyframeobjectid=4 timecode="010000">
> <node pathid = 1 pathpoint = 0.7 model = 1/>
> </keyframe>
Ok. This all makes sense.
> An additon to this would be the 2d graphs for manipulating properties
> - like rotation, which are simply a special case of a 2D only path, an
> object/property reference as opposed to just the model ref, and still
> have a current t.
Not sure what you mean by this.
> Now, where Damien was probably going was the addition of formulae and
> functions - for example describe t in terms of : t<path1> =
> sine(somekeyframevalue).
Yes, this is what I want too: a way to specify acceleration, a way to specify t
so that more is available besides a linear change.
> This would be an additional XML block describing the actual function,
> and then a different nodetype inside a keyframe plugging values into
> the functions. The functions should be created so that they can take
> an input in terms of t - which it can internally reference an
> graph/path or some other function with. What the function actually
> does, and what setup an instance of a function needs is the functions
> own business. In that sense - it is a little like a callable class.
>
> This class idea would mean that even the basic object along path node
> is actually just a predefined function - and would give some sort of
> uniformity to the description.
>
> Now you get Damiens flexibility in real programming in the funtions,
> and the simplicity of the XML referencing them. It is not a bold step
> to reference function libraries. A UI would gloss this, so you could
> import a library with particularly useful functions and a UI widget,
> then build graphs or keyframes to provide inputs to the functions, and
> even gloss over building the simplest functions. However - more
> serious programmers could open up the code (still just XML and plain
> text), and do something really fancy.
A little confused here. For example, I'm not sure how I would specify a simple
acceleration between 2 keyframes. Here is an attempt:
<keyframe keyframeobjectid=3 timecode="003500">
<node pathid = 1 pathpoint = 0.0 model = 1>
<acceleration value=t*t>
</node>
</keyframe>
<keyframe keyframeobjectid=4 timecode="010000">
<node pathid = 1 pathpoint = 1.0 model = 1/>
</keyframe>
That isn't a very good guess, I know. This is what I haven't been able to
figure out at all. But this is the closest I've seen anything come up with
something useful!
Another example of modifying t. How do I say between keyframe a and b the model
is only located at t = 0.0 until keyframe 2 is reached? This type of modifying
t is what I really need to flush out.
Moving on.
Another thing to add to this is how to modify the model depending on what t is
as well. For example, a car's wheels should rotate as it moves. So the model
needs to be able to take t as a variable and have some way of changing itself
based on t.
Another example is my minifig macro. It takes the path and divides it into
points where the feet are going to land. Then as the minifig moves along the
path, the rotation of the legs are calculated so that the feet land on the
points and the whole body movement is smooth. So the actual location of the
minifig is not the value of t. Also, the feet landing points are calculated by
the sharpness of the turn. A straight path has large steps and the points are
far apart. A sharp turn has smaller steps and the points are closer together.
So the location of the minifig is nowhere near t.
See it in action:
http://www.antonraves.com/animations.php?actie=2&no=12&start=0&teller=13
Now this has nothing to do with acceleration I spoke about above. Of course
acceleration would affect this all, but they are independent. The movie example
has a 0 acceleration. The t is linear. But because of the other variables
(step length around turns) the actual minifig does slow down and speed up. If t
had acceleration, then the walk would start out slow, proceed like it does, then
slow down and stop. So you see they are independent: t and the actual location
of the model.
I'm not sure how to plug this in also. This could be left up to the rendering
engine to implement. In other words, send the rendering engine instructions.
Like I would put in POV-Ray commands and pass t as the controlling variable.
Then all the walk smarts is performed by my good old minifig macro. Or I could
even put in MEL commands if I were going to use Maya. Etc.
James
|
|
Message has 1 Reply:
 | | Re: My humble opinion about LDraw animation
|
| Hi James, whew - this is getting to be a big mail, but I will try and answer in situ... (...) I suppose I consider it part of the concept, so then I, or others can build what I built, although given the original LDraw file, some may be able to work (...) (19 years ago, 15-Sep-05, to lugnet.cad, lugnet.cad.ray, lugnet.animation)
|
Message is in Reply To:
61 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
