| |
On 05/09/05, James Reynolds <james@magnusviri.com> wrote:
> > Right - now to James' question:
> >
> > To animate, you should probably use paths. Consider the format as
> > objects, which are stored as XML.
>
> Ok, you lost me. Are you talking about paths as lines and curves or paths as
> in
> parent.child.grandchild? Because you mention XML and objects, I'm confused
> (could mean XPath or OO...).
I did mean paths as in lines and curves, as I hope became apparent later on.
>
> > 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...
>
> > The paths would be a collection of line
> > segment objects which may be lines, arcs, splines/b-splines, and for
> > the sake of interpolation, should be represented internally in
> > parametric terms. Each part can then be assigned to follow a path.
>
> I'm pretty sure you means paths as lines and curves, but I'm having a hard
> time
> visualizing what you are describing.
Yes - a single path (which may be closed or open), would basically be
a sequence of straight or curved lines. I was just describing the man
fancy ways which curves can be generated - which can allow you a lot
of freedom.
>
> > A simpler graph would be used to represent each axis of rotation -
> > which could be viewed as a graph, or the object simply rotated in the
> > UI at certain keyframes. Rotations can get complicated - most 3D
> > people are aware of gimbal lock
>
> Ah. So that is what it is called. Yes, I've gone crazy because of it.
Gimbal lock gets animators and game coders tearing their hair out. It
is one thing that quarternions are good for dealing with, although
quarternions are fairly complex mathematical constucts - while more
powerful than a simple Euler matrices, but they have a steeper
learning curve. They are however what the professionals use. The UI
and API of course, are free to hide this away. In the UI - a nice
little rotation widget please...
>
> > 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...
>
> Anyway, so I think I know what you mean by nodes and objects. I know Maya has
> history nodes. Does it also use keyframe nodes? Is that what you are
> referring
> to?
A keyframe node here is an object which ties a certain point along a
path to a timecode, and an object on that path at that time (multiple
objects might follow a path!).
>
> What would your description actually look like formated as XML? Here is my
> guess:
>
> <model objectid=1>
> <part color=bla origin=bla orientation=bla pathid=1 />
> </model>
> <path objectid=1>
> <segment type=arc otherinfo=bla>
> <node objectid=1keyframeid=1 />
> </segment>
> </path>
> <keyframe objectid=1 timecode=bla />
close - but not quite:
<model modelobjectid=1>
<part color=bla origin=bla orientation=bla pathid=1 />
</model>
<path pathobjectid=1>
<segment type=arc otherinfo=bla/>
<segment type=spline otherinfo=bla>
<controlpoint cpobjectid="1" x="1.0" y="blah" z="blah" otherinfo=blah/>
...(spline control points)...
</controlpoint>
</segment>
</path>
<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>
Okay - explaining this xml mouthful:
The first section describing the object is as you put it, that is
ideal. I have added one here, skipping others for conciseness.
In the second section, I describe a path - note I have given the
objects longer ID tags, this is only so people do not get confused and
think they are using a model ID in the pathid.
Note also, after the line seg, I have put a spline segment, just to
show that a path may consist of different types of line segments. I
have also skipped them, but imagine there are a few more paths....
Now the keyframes are where it gets interesting.
The first keyframe sets the initial scene, and which models are where
on which path in the first frame of the animation. The first keyframe
would be a requirement (something for the DTD?).
I put a comment in to describe pathpoint, a position along the path in
terms of t - a very useful method to describe travelling along a path
indeed, as it makes interpolation a lot simpler, you only need
interpolate t, then pass that into the path calculation functions
which will position your items. This says that in the first frame,
model1 starts at the beginning of path1, and model 2 starts at the end
of path 3.
Now on the next keyframe, say 24 seconds in, model 1 is now halfway
along path 1 - so the interpolation would mean at each second between
frame 1 and this keyframe, t is 0.5/24t along. Model2 is now however
one fifth along path 3, which means it has moved backwards four
fifths, so at each second, thats a variation (in terms of t) of
0.8/24t - depending on the relative lengths of path1 and path3, the
object on path3 will have moved furthar.
In keyframe 3, we only describe the bahaviour of model 2, at 35
seconds. This means that object 1 is not affected /at all/ on this
keyframe, and will be interpolated using the next keyframe that it is
referenced in. model 2 has now changed direction along its path, and
will have moved (0.8 - 0.2)/(35 -24) = 0.6/11 t/s along path3.
In keyframe 4, which for this example, we will only describe model 1
at 50 seconds. Since this is the last frame, and there is no furthar
infor,mation to interpolate for model2 on path3, then it is assumed
that it will remain stationary on 0.8t. However, model 1 has now moved
to 0.7t along path 1, and is interpolated from keyframe 2 - at 0.5t.
So the movement per second is now (0.7 - 0.5)/(50-24) = 0.2/26 t/s.
Now the beauty of this is that while I have now described the movement
along the paths, I have completely left out the actual frame numbers -
this means a render could be done with different frame rates, and when
played back, still be the same length, just smoother/coarser. This
means you could preview at 10fps and then render at 50fps.
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.
Now, where Damien was probably going was the addition of formulae and
functions - for example describe t in terms of : t<path1> =
sine(somekeyframevalue).
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.
OrionRobots
--
http://orionrobots.co.uk - Build Robots
|
|
Message has 1 Reply:
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
|
|
|
|
