Subject:
|
Re: My humble opinion about LDraw animation
|
Newsgroups:
|
lugnet.cad, lugnet.cad.ray, lugnet.animation
|
Date:
|
Thu, 15 Sep 2005 13:04:37 GMT
|
Reply-To:
|
(orionrobots@gmail.com)avoidspam()
|
Viewed:
|
239 times
|
| |
|
|
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
|
|
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
|
|
|
|
