| |
On 30/08/05, James Reynolds <james@magnusviri.com> wrote:
> > Usability was a key issue - coders are coders, and designers/animator
> > rarely want to dive in to the low-level guts of a system. Those
> > wanting to animate here - should not have to either. If they want to
> > do advanced animations - then yes they do want to understand paths and
> > a little about splines, but they also be able to place a part at point
> > A in a gui, then go to the next keyframe and place it at point B - and
> > the software be able to handle something simple enough to interpolate
> > between those two keyframes. That should not require any scripting on
> > a users part, or a description language - it should be just point and
> > click.
>
> How are keyframes internally structured and saved to disk? Are they
> arrays, hashes, and how is the interpolation between keyframes
> usually handled? I haven't had time to research it myself, and I'm
> not sure I would even be able to find the answer anyway. I'm very
> interested in learning because POV-Ray doesn't support keyframes and
> if I could just write a simple script to parse an array/hash that
> would probably make what I do easier on me.
>
> James
First I should apologise if I sounded harsh - I have spent the last
few months of my day-job dealing with a nightmare UI built by other
coders with absolutely no end-user consultation. So I recognised
similar patterns and had already gotten the hump.
I am not trying to belittle peoples ideas, but prevent mistakes I have
seen made being made again, especially with something like this. I
want to make it clear that I would be extremely keen to see a Lego
animation format, and to contribute to and use it.
Right - now to James' question:
To animate, you should probably use paths. Consider the format as
objects, which are stored as XML. 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. 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.
The UI would create a simpler path when an object was dragged between
keyframes, but the user would be able to specify complicated ones by
building the paths then assigning objects to follow them.
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, and internally they maybe better
represented using quarternions as opposed to simpler euler matrices.
These graphs could quite happily use objects similar to paths, but
constrained to two dimensions. The graphs might also be used to
represent other varying data in the system - an example I can think of
might be lighting conditions if you want light intensities to change.
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.
All of this complication should be hidden from the user, with an
interface with which they simply draw the segments, and constrain
them. The graphs would be accessible as graphs, as well as specific UI
widgets for their use (like a volume slider drawn beside a light, or a
cone for a cameras FOV. The camera would just be considered a part
along the others - so it can be manipulated in the same way. This
would mean that an editor app could visualise the camera tracking a
path from a fixed view during editing.
I am sure I could think of more given time - but this would be a start.
OrionRobots
--
http://orionrobots.co.uk - Build Robots
|
|
| |
> 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...).
> 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/
> 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.
> 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.
> 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.
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?
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 />
James
|
|
| |
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
|
|
| |
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
|
|
| |
Hi James, whew - this is getting to be a big mail, but I will try and
answer in situ...
On 14/09/05, James Reynolds <james@magnusviri.com> wrote:
> 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...
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 it out themselves.
>
> > > > 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.
Hmmm - I am not sure about this. Maybe the concept is that instead of
having a clock, to use t-values for the timecode instead of
seconds/minutes, and that would mean you could time-stretch the
animation easily as well...
>
> > <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.
Okay, the basic path describes the translation of an object, but, as
you would in POV or other animation systems, there are other things
you would vary, such as rotation, colours, texture choices and so on.
Each of these could be described with a graph that is continuously
varying and interpolated like the paths. There may also be cases for
descretes, but even then, a fader/slider use of the graph may make
sense. These graphs may also be used to feed values for functions.
>
> > 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.
Absolutely, and it may not merely be acceleration, but a function
could produce any number of interesting results. Again, by specifying
the start value for t (which regardless of which graph or function is
the required magic variable here), and end value for t, then the
software is left to interpolate those. So we may want to (for more
complex usage) modify the keyframe like so (I am going to get strict
with those XMl quotes now, we are going to need them):
<keyframe keyframeobjectid="4" timecode="010000">
<node pathid = "1" pathpoint = "sin(t) + 3 * t" t = "1.0" model = "1"/>
</keyframe>
Now the problem here is how to manage changes of functions between
keyframes, Ie for the first 20 seconds it follows that sine path, and
then it follows another. We may have an outgoing function (the one we
have been following), and a new function starting - or something to
declare that in the keyframe, as well as the final t value for the
outgoing function, and the initial t-value for the next function.
Though here, you would hope that there is a way to ensure that the
transition between functions is smooth, and does not jump - that may
be down to the user.
> > 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!
Again - taking a look above, this example could be served int he
following way. The starting point of the acceleration, and the end
point would be interpolated in terms of t. As we didnt specify a new
pathpoint function (ahah - now it is function interpolated in terms of
t, and not merely a constant), then on the outgoing final frame, it
uses the same one.
<keyframe keyframeobjectid="3" timecode="003500">
<node pathid = "1" pathpoint = "t * t" t="0.0" model = "1">
</node>
</keyframe>
<keyframe keyframeobjectid="4" timecode="010000">
<node pathid = "1" t="1.0" model = "1"/>
</keyframe>
If keyframe 4 is a transition, maybe something like the following
would work (this might be ugly - sorry):
<keyframe keyframeobjectid="4" timecode="010000">
<node pathid = "1" int="1.0" outpathpoint="1.0" model = "1"/>
</keyframe>
Again - this might be refactored, but i will explain. since we have
specified the incoming function in the previous frame, we should not
have to respecify it, on the value of t it will have at this end. That
is specified by the "int" attribute. As we are starting a new
function, we can then specify an output pathpoint "outpathpoint" and a
value t as "outt". Now we could say that if only a single constant is
put in the pathpoint, we do a simple linear interpolation and do not
need a seperate t attribute - however for consistency, although it is
a little more verbose, we might be better to make all pathpoints
specified in terms of t, even if there value is only "t". The latter
would certainly make it easier for both generator and editor software
as well as programmers although more verbose- its a defensive
technique, as it would be a bit too much to identify and interpolate
all the constants in the function, where simply assigning t in it is
much simpler, and having two methods could mean someone easily
slipping up and expecting a different result.
>
> 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.
If you mean the value t is stationary at 0.0, and then jumps to a new
value at exactly frame 2, then maybe this concept I have introduced of
incoming and outgoing values would be the solution. Again - it might
be something that could be tidied up, and I am not entirely happy with
it.
>
> 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.
This was the concept (that confused you a little) of the 2D graphs -
simply a path that is used to determine the value of the wheels
rotation, or a path that feeds a function of t that specifies the
rotation.
>
> 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.
Now - the first thing is to remember that not every model is acted on
with every keyframe, other models/objects continue to be interpolate
to the next keyframe that specifies them. Next is that you could use
functions here to take the value of t along the path, and calculate or
use another path to work out where the feet should be placed. For
stuff involving legs and feet, I would maybe want to specify a
function library to handle bones and IK, so I can specify as
parameters to setup functions the origin, length, minumu and maximum
angles etc of the bones. This is complex stuff, but by having a
function library, which supplies functions the renderer can use
(python again? you are talking about an IK object, and I think we now
need variables to store those objects in!) as well as accompanying
code to help add plugin widgets to the UI to manipulate the functions.
Of course, a porgammer could also import and specify by hand the
parameters to those.
Have you played with Inverse Kinematics and similar stuff in MAX or maya?
>
> 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.
Now we could use some sort of subreffing on our model to specify stuff
in relation to the current position of the origin of the model (which
if you remember the initial XML contained any number of PARTS), so
while the minifig takes a linear path, functions supplied to the
parameters (position, rotation, or IK values if we ue that route)
would be independant of that. To allow for the subreffing, we should
probably add an ID to the part, and we should also allow a model (as
an assembly of parts) to be embedded inside another model. The
subreffing syntax should be nice and concise, although numeric IDs
begin to become a little hard to see now - so maybe we need to name
them, in an OO style fashion.
Something like
...model = "minifig1.leg.lowerleg.foot"...
in the node tags, where the relationships are dependant upon where
things are joined, so the leg is joined to the minifig and oves with
that, and lowerleg is part of the leg and moves with that, and the
foot is joined to/part of the lowerleg and moves with that, as well as
each level possible getting its own path or function follow.
>
> 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.
My goal with this format is that it can deal with the smarts itself,
and by allowing function libraries and objects with variables from
python, it would be a very, very versatile system. However, it would
also be able to hide most of the really deep stuff from the user, kind
of like a very well written UI. I get the feeling python and xml
together could be a really neat combination, especially (AFAIK) there
are not many syntactic clashes between them, so embedding python in
the XML for specifying functions should be simple.
Maybe we could treat the parameters (the translation, rotation,
scaling or the path it is on and its current t value etc) of one model
as simply variables, to be reffed with the dot syntax.
The other amazing thing about these functions, and the joints here, is
that we start to be able to use this not merely for animation, but
also for simulation. Imagine that you have a module that knows how to
deal with the torque and RPM of a motor, or how to deal with a number
of technic gears, where it can begin to at least calculate which way
and at what speed they will turn, and possibly if they are impeded.
Imagine an extreme module library which allowed you to specify an NQC
file and then using the timecode through a python RCX simulator did
stuff there - I know this might seem way of the scale, but it would
not be impossible.
My interest in this is not simply animation you see, I am a Lego
builder and software engineer, but first and foremost I am a robot
builder, and being able to simulate Lego interactions as well as
animate would be a huge benefit to me.
Thanks for anybody who got this far - this is deep stuff, and we still
have to start somewhere a little more humble than RCX simulations, but
by thinking ahead, and planning for extensibility, there is a huge
mileage in this.
Danny
--
http://orionrobots.co.uk - Build Robots
|
|
| |
Ok. So this is exactly the reason I didn't want anyone to invent a
new animation scripting language for Legos! It is something new and
is in danger of: being a sucky 1.0 release (or worse, never reaching
1.0), and not getting widespread use and so it falls by the the
wayside and turns out to be a big waste of time. Isn't there stuff
out there that already does all of what we are talking about? If
yes, why shouldn't we just use it? If no, well, let's keep going!
This is great stuff! :)
> > > 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.
>
>
> Okay, the basic path describes the translation of an object, but, as
> you would in POV or other animation systems, there are other things
> you would vary, such as rotation, colours, texture choices and so on.
> Each of these could be described with a graph that is continuously
> varying and interpolated like the paths. There may also be cases for
> descretes, but even then, a fader/slider use of the graph may make
> sense. These graphs may also be used to feed values for functions.
Bingo! This is exactly what I want! And I think it can be used to
solve the acceleration problem too.
Linear graph:
<graph graphid="1" function="t" />
Acceleration:
<graph graphid="2" function="t*t" />
Climbing wave:
<graph graphid="3" function="sin(t) + 3 * t"" />
etc etc.
> <keyframe keyframeobjectid="4" timecode="010000">
> <node pathid = "1" pathpoint = "sin(t) + 3 * t" t = "1.0" model
> = "1"/>
> </keyframe>
Doesn't that get confusing to have the pathpoint be variable?
Shouldn't it be a constant since it is used to determine what the
start pathpoint is for the start of the keyframe?
> Now the problem here is how to manage changes of functions between
> keyframes, Ie for the first 20 seconds it follows that sine path, and
> then it follows another. We may have an outgoing function (the one we
> have been following), and a new function starting - or something to
> declare that in the keyframe, as well as the final t value for the
> outgoing function, and the initial t-value for the next function.
> Though here, you would hope that there is a way to ensure that the
> transition between functions is smooth, and does not jump - that may
> be down to the user.
How about this. I believe we intend to use 2 keyframes to declare
the start and stop of an action:
<keyframe keyframeobjectid="4" timecode="010000">
<node model = "1"/>
</keyframe>
<keyframe keyframeobjectid="5" timecode="020000">
<node model = "1"/>
</keyframe>
That will apply to model 1 from 010000 to 020000. I'm wondering if
it would be good to allow a start and stop timecode in one keyframe
declaration:
<keyframe keyframeobjectid="5" starttimecode="010000"
endtimecode="020000">
<node model = "1"/>
</keyframe>
And allow a startpathpoint and endpathpoint for nodes. These next 2
code examples are identical (and both allowed):
Short version:
<keyframe keyframeobjectid="4" starttimecode="010000"
stoptimecode="020000">>
<node pathid="1" startpathpoint="0.5" endpathpoint="0.75"
graphid="3" model="1"/>
</keyframe>
Long version:
<keyframe keyframeobjectid="4" starttimecode ="010000">
<node pathid="1" startpathpoint="0.5" graphid="3" model="1"/>
</keyframe>
<keyframe keyframeobjectid="5" starttimecode ="020000">
<node startpathpoint="0.75" model="1"/>
</keyframe>
[The reason I left pathid and graphid off of keyframe 5 is because
those 2 attributes apply to the *next* set of frames, not the
previous set. So in keyframe 5, if I specified a pathid and graphid
they would apply until the next keyframe for model 1 or the end of
the animation.]
So both examples are enough to figure out everything that happens to
model 1 from 010000 to 019999.
So at 010000, the location of model 1 is calculated like this:
x,y,z = pathid[1](graphid[3](0.5))
And at 019999, the location of model 1 is calculated like this:
x,y,z = pathid[1](graphid[3](0.75))
Actually the value passed to to graphid[3] would be a tiny bit less
than .75 because at 020000 it is .75. But at 020000 it will be using
a different path and graphid... So the stoptimecode really specifies
the next timecode. Maybe it should be named nexttimecode...
The output of graphid[x](0) should always be 0. The result of graphid
[x](1) should always be 1. The graph is intended to only modify
acceleration. But because t is always suppose to be between 0 and 1,
the output of graphid is also between 0 and 1.
> > Another example is my minifig macro. It takes the path and
> > divides it into
> > points where the feet are going to land.....
>
>
> Now - the first thing is to remember that not every model is acted on
> with every keyframe, other models/objects continue to be interpolate
> to the next keyframe that specifies them. Next is that you could use
> functions here to take the value of t along the path, and calculate or
> use another path to work out where the feet should be placed. For
> stuff involving legs and feet, I would maybe want to specify a
> function library to handle bones and IK, so I can specify as
> parameters to setup functions the origin, length, minumu and maximum
> angles etc of the bones. This is complex stuff, but by having a
> function library, which supplies functions the renderer can use
> (python again? you are talking about an IK object, and I think we now
> need variables to store those objects in!) as well as accompanying
> code to help add plugin widgets to the UI to manipulate the functions.
> Of course, a porgammer could also import and specify by hand the
> parameters to those.
I'm thinking for starters just passing the parameters to the povray
code and not trying to implement it in the script yet.
> Have you played with Inverse Kinematics and similar stuff in MAX or
> maya?
Aha. Another one of those "oh, that is what it is called" moments.
I haven't played with IK in MAX or Maya, but I have tried to write my
own in POV-Ray. I had to get help, but I have done some IK for a
complex leg (not a minifig) on one plane. Adding the other planes
proved to be too much and remains unfinished.
> My goal with this format is that it can deal with the smarts itself,
> and by allowing function libraries and objects with variables from
> python, it would be a very, very versatile system. However, it would
> also be able to hide most of the really deep stuff from the user, kind
> of like a very well written UI. I get the feeling python and xml
> together could be a really neat combination, especially (AFAIK) there
> are not many syntactic clashes between them, so embedding python in
> the XML for specifying functions should be simple.
My goal is to make my povray animations easier. I probably have a
bit of a different slant also. As with my minifig macro, I intend on
having my models already built in povray. So my <model></model>
stuff will pretty much be empty but refer to the povray model name.
Also, I don't know Python. I just need an excuse to learn it
though. But I do know Perl well.
> Maybe we could treat the parameters (the translation, rotation,
> scaling or the path it is on and its current t value etc) of one model
> as simply variables, to be reffed with the dot syntax.
Yup.
> The other amazing thing about these functions, and the joints here, is
> that we start to be able to use this not merely for animation, but
> also for simulation. Imagine that you have a module that knows how to
> deal with the torque and RPM of a motor, or how to deal with a number
> of technic gears, where it can begin to at least calculate which way
> and at what speed they will turn, and possibly if they are impeded.
> Imagine an extreme module library which allowed you to specify an NQC
> file and then using the timecode through a python RCX simulator did
> stuff there - I know this might seem way of the scale, but it would
> not be impossible.
>
> My interest in this is not simply animation you see, I am a Lego
> builder and software engineer, but first and foremost I am a robot
> builder, and being able to simulate Lego interactions as well as
> animate would be a huge benefit to me.
Yes, I wanted this too! But that is way over my head. I do think it
would be cool to plan that in.
James
|
|
| |
In lugnet.cad, James Reynolds wrote:
> Ok. So this is exactly the reason I didn't want anyone to invent a
> new animation scripting language for Legos!
IMHO there is no reason why someone can't invent something new.
Especially as anything new would be still compatible with LDraw standards
(otherwise the author would have to reinvent the wheel, the LDraw library and
the existing Lego-Cad tools which would require several human lives).
> It is something new and
> is in danger of: being a sucky 1.0 release (or worse, never reaching
> 1.0), and not getting widespread use and so it falls by the the
> wayside and turns out to be a big waste of time.
Is something is new then:
* if it never reaches 1.0 it's died (no consequence for you)
* if it's sucky 1.0 it dies (no consequence for you)
* if it's a waste of time and effort (for its author) then no consequence for
you
* if it's not getting widespread use that means it's mitigated success, meaning
the tool is useful for some people and lays the bases for future and better
tools that will appeal to more people. you can't underestimate laying the bases,
when thing are uttermost complex (and animation-scripting really is), then
laying some bases is already a great achievement. succeeding the first time is
not always possible, failure or semi-failure is a premise for success.
> Isn't there stuff
> out there that already does all of what we are talking about? If
> yes, why shouldn't we just use it? If no, well, let's keep going!
> This is great stuff! :)
If something is new and doesn't do better than what exists then it dies (again,
no consequence).
> It is something new and
> is in danger of:
Where is the danger? Do we look so dangerous? My opinion is that you are
overreacting because you anticipate much too far. You anticipate the community
is splitting. That's not what i see, what i see here everyday is friendly people
exchanging many exciting ideas. May be 1% of these will see the light of day, so
you don't need to overreact just because the other 99% are crappy. You simply
can't have the 1% good ideas implemented if anyone can't express their 99%
foolish dreams.
There is this forum to discuss anything.
There are commitees to define and protect the standards.
None of the 2 is a danger, there are just complementary, they balance innovation
and the protection of the user time-investment.
Both are necessary.
Regards,
- damien
web page: http://perso.wanadoo.fr/alphablock/
|
|
|
