| |
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
|
|
Message has 1 Reply:
Message is in Reply To:
 | | 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)
|
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
|
|
|
|
