 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi all!
I've got a little spare time at my hands and am toying with the idea of
making another short. I want to take it one step at a time. Last time I
animated non-animated objects (a jet and a flying saucer, no moving parts,
really), this time I want to take it a small step ahead and do some moving
parts. As is a must for quick and efficient workflow, things should work and
animate by itself.
Thus I present my first step: a small set of macros to animate, yep, rolling
balls. It's still a WIP, but basically, they are supposed to get a starting
position, then you feed them a new position for every frame, and the macros
take care of calculating the rolling (how much along which axis) and keeping
track of everything.
AFAIK, Rune did something like this in a AI-POV-Game of his years ahead of
me, but as always, I do things myself, easier to customize (and good for
learning efforts). :-)
If it isn't expected, the heroes of my next short will move about on balls,
how exactly I don't know yet. ;-)
Regards,
Tim
--
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Post a reply to this message
Attachments:
Download 'rolling.mpg' (383 KB)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi Tim!
That's some nice rollin'.
I think the AI-POV-Game you're referring to is the PushBall game I made in
2000 (http://runevision.com/3d/anims/#34). I can't remember the technical
details, but I think I did the rolling by storing two vectors representing
two local axis for the rolling ball (like the x and y axis) and whenever the
ball moved in a direction d, I'd rotate the two vectors around an axis
perpendicular to d and parallel to the ground. I'd calculate the third local
axis from the first two, and apply the three to the ball in the form of a
matrix transform.
If you've done it some different way, I'd be curious to hear how. :)
Rune
--
3D images and anims, include files, tutorials and more:
rune|vision: http://runevision.com
POV-Ray Ring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> If you've done it some different way, I'd be curious to hear how. :)
Nope, looks like I'm doing it much the same way, though I store all three
axis' and the position of the ball in an external file. I could use that
technique you mentioned with using just two axis and generating the third to
save some filespace, but then again, it just is convenient to have it
accessible right away. The file also stores the radius of the sphere.
My macro also requires an "up"-vector to generate the axis around which the
matrix will be rotated, as I want to allow balls to roll up and down hills
etc. I'm planning on some macros that'll take, for example, an array of new
positions with up-vectors and apply these in succession, so that I can have
a more detailed "simulation" from frame to frame.
I'm not yet sure how to pull it off, but I also want to script some
functionality to have balls stay in a relative global position of the
original rolling sphere (like always on top), but roll as if moved by the
parent. One idea I had for a robot-like character was to have the main
sphere's upper hemisphere covered with some metallic surface, and in these I
set several such smaller spheres that are supposedly electromotors or such
to move the big sphere. Just neat little stuff that can animate by itself
and make the character look more alive and interesting. :-)
Regards,
Tim
--
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tim Nikias wrote:
>> If you've done it some different way, I'd be curious to hear how. :)
>
> Nope, looks like I'm doing it much the same way, though I store all
> three axis' and the position of the ball in an external file.
Sure, not much difference if you store two vectors or all three. I also
stored the information in an external file of course, being the only way to
transfer data from frame to frame. :) Btw. I think it's a good idea to once
in a while (or just in every frame to make it simpler) force the three
vectors to be perpendicular to each other to prevent accumulated precision
errors to slowly skew the matrix.
> I'm not yet sure how to pull it off, but I also want to script some
> functionality to have balls stay in a relative global position of the
> original rolling sphere (like always on top), but roll as if moved by
> the parent. One idea I had for a robot-like character was to have the
> main sphere's upper hemisphere covered with some metallic surface,
> and in these I set several such smaller spheres that are supposedly
> electromotors or such to move the big sphere.
So if the big sphere is not just a ball but also a vehicle, then you'd need
to store vectors for the vehicle's alignment as well as for the ball's, the
difference being that the vehicle keeps having an up-vector that corresponds
to the up-vector of the ground, and a forward-vector that is the direction
the vehicle moves in (typically). This, along with the position, which is
the same as for the ball, could be used to get the transformation for the
vehicle's upper hemisphere etc., which stays fixed regardless of the ball's
rotation. From this, it should be no problem to calculate global points that
are in a fixed relative position to the vehicle.
Your project sound very interesting. I'm looking forward to see the
progress. :)
Rune
--
3D images and anims, include files, tutorials and more:
rune|vision: http://runevision.com
POV-Ray Ring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Sure, not much difference if you store two vectors or all three. I also
> stored the information in an external file of course, being the only way
to
> transfer data from frame to frame. :) Btw. I think it's a good idea to
once
> in a while (or just in every frame to make it simpler) force the three
> vectors to be perpendicular to each other to prevent accumulated precision
> errors to slowly skew the matrix.
Yeah, those are things I still need to implement. I just wanted to show
that the initial stuff was working properly. :-)
> So if the big sphere is not just a ball but also a vehicle, then you'd
need
> to store vectors for the vehicle's alignment as well as for the ball's,
the
> difference being that the vehicle keeps having an up-vector that
corresponds
> to the up-vector of the ground, and a forward-vector that is the direction
> the vehicle moves in (typically). This, along with the position, which is
> the same as for the ball, could be used to get the transformation for the
> vehicle's upper hemisphere etc., which stays fixed regardless of the
ball's
> rotation. From this, it should be no problem to calculate global points
that
> are in a fixed relative position to the vehicle.
Well, as for fixed relative's position, I simply thought I'd place the
machine
on top of the sphere. What I'm after is actually a way to calculate the
rotation-
matrix for small spheres which always stay on a fixed location of the
machine.
So when the big sphere moves forward, a smaller sphere touching it would
have to roll backward appropriately. Depending on position and angle to the
actual rotation-axis, a small sphere has to turn more or less.
> Your project sound very interesting. I'm looking forward to see the
> progress. :)
Good to know, though I'm not quite sure how fast I will get along with
things.
Even with spare time I've got some work to do, especially considering that
lots of my colleagues are away over the holidays and the remaining staff has
to work double because our bosses didn't rememember to hire new staff
early enough... In the end, that's just more money for me though. :-)
Regards,
Tim
--
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
