 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I changed my bouncing algorithm to a rolling one. The result is below.
A one Mb 320 x 240 version is at:
http://members.xoom.com/_XMCM/gregjohn/animation.html#POV13
It's actually the most simple one to date. The particles do not actually
consider each other's presence (no collision avoidance or bouncing).
The acceleration of the particle is simply the x & z components of the
normal at the particle's location. If there's interest, I can make a
page with the algorithm like I did with the boids...
I think I know how to make a texture on the particles themselves rotate
properly for the motion they make across the surface. It think however
that my approach would be very inelegant and a real programming
headache. Any pointers?
Q: Is there an easy way in matrices to say:
I rotated <13,5,5>, then <14,4,2>, then,....
Can I just add these up somehow?
Post a reply to this message
Attachments:
Download 'bounceroll05.mpg' (455 KB)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hey, that's pretty cool. Do they slow down?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Can't help ya with that math stuff, but rolling those balls around on that
surface is definitely impressive.
Regards,
Dave
"Greg M. Johnson" <"gregj;-)56590\""@aol.c;-)om> wrote in message
news:396a80b4@news.povray.org...
> I changed my bouncing algorithm to a rolling one. The result is below.
> A one Mb 320 x 240 version is at:
>
> http://members.xoom.com/_XMCM/gregjohn/animation.html#POV13
>
> It's actually the most simple one to date. The particles do not actually
> consider each other's presence (no collision avoidance or bouncing).
> The acceleration of the particle is simply the x & z components of the
> normal at the particle's location. If there's interest, I can make a
> page with the algorithm like I did with the boids...
>
> I think I know how to make a texture on the particles themselves rotate
> properly for the motion they make across the surface. It think however
> that my approach would be very inelegant and a real programming
> headache. Any pointers?
>
> Q: Is there an easy way in matrices to say:
> I rotated <13,5,5>, then <14,4,2>, then,....
> Can I just add these up somehow?
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
that green ball that the camera follows should be invisible no?
--
Ian
Inkwell: Ian's Homepage
http://www.topcities.com/cartoon/inkwell/index.htm
Greg M. Johnson <"gregj;-)56590\""@aol.c;-)om> wrote in message
news:396a80b4@news.povray.org...
> I changed my bouncing algorithm to a rolling one. The result is below.
> A one Mb 320 x 240 version is at:
>
> http://members.xoom.com/_XMCM/gregjohn/animation.html#POV13
>
> It's actually the most simple one to date. The particles do not actually
> consider each other's presence (no collision avoidance or bouncing).
> The acceleration of the particle is simply the x & z components of the
> normal at the particle's location. If there's interest, I can make a
> page with the algorithm like I did with the boids...
>
> I think I know how to make a texture on the particles themselves rotate
> properly for the motion they make across the surface. It think however
> that my approach would be very inelegant and a real programming
> headache. Any pointers?
>
> Q: Is there an easy way in matrices to say:
> I rotated <13,5,5>, then <14,4,2>, then,....
> Can I just add these up somehow?
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ian Witham wrote:
> that green ball that the camera follows should be invisible no?
It doesn't have to be, it behaves like all the rest, I just picked one that
wasn't all by itself at the end..
Tony asks:
>Do they slow down?
This version had:
#declare actorv[n]=0.9975*actorv[n]+acceleration;
It's funny that at even 0.995* , the particles slowed down so quickly it was
boring.....
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Greg M. Johnson <gre### [at] my-dejanews com> wrote in message
news:396B023F.EE3F9891@my-dejanews.com...
> Ian Witham wrote:
>
> > that green ball that the camera follows should be invisible no?
>
> It doesn't have to be, it behaves like all the rest, I just picked one
that
> wasn't all by itself at the end..
Sorry, that's not what I mean- I'll try to explain... At first when I saw
the animation I was intrigued as to how you did the camera tracking, then I
noticed the green ball that wasn't moving relative to the frame. If the ball
that the camera follows kept all of it's propertys only it was made
invisible, the mystery of the smooth flowing camera work would be retained.
It was just a humble suggestion :-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Cool.
Ian Witham wrote:
> the mystery of the smooth flowing camera work would be retained.
> It was just a humble suggestion :-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi Greg,
nice animation, but a lot of questions arise !
But OK, I've selected only one question :
In your animation, what is the link between the surface and the position
of the spheres ? Well in other words, how do you know the height (z) of
the surface at a given (x,y) point ? Don't you need this to make any
spheres rolling and not flying over the surface ? In fact I'm looking
for a way, given a height_field object, to know what will be the height
(z axis) of a point given its coordinates (x,y). I suppose it would be
not so much simple to read the source picture used to make the
height_field (considereing the different format possible in use). I
haven't been able to find anything embeded in POV-Ray that let the user
access this value from a povray source file (within a macro in
particular), maybe I have missed it ?
Else, maybe the surface you are using is particular ?
Thank you for any answer !
Denis.
"Greg M. Johnson" wrote:
>
> Ian Witham wrote:
>
> > that green ball that the camera follows should be invisible no?
>
> It doesn't have to be, it behaves like all the rest, I just picked one that
> wasn't all by itself at the end..
>
> Tony asks:
> >Do they slow down?
>
> This version had:
> #declare actorv[n]=0.9975*actorv[n]+acceleration;
>
> It's funny that at even 0.995* , the particles slowed down so quickly it was
> boring.....
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Denis Corbin" <cor### [at] wanadoofr> wrote in message
news:396B8439.35FC4830@wanadoo.fr...
| Hi Greg,
|
| nice animation, but a lot of questions arise !
| spheres rolling and not flying over the surface ? In fact I'm looking
| for a way, given a height_field object, to know what will be the height
| (z axis) of a point given its coordinates (x,y). I suppose it would be
| not so much simple to read the source picture used to make the
| height_field (considereing the different format possible in use). I
| haven't been able to find anything embeded in POV-Ray that let the user
| access this value from a povray source file (within a macro in
| particular), maybe I have missed it ?
I'll let Greg answer too :-) but you obviously haven't heard about MegaPov,
or it's 'hf_height_at' keyword which allows you to find any points y
coordinate on the surface of a height field. HF is along x and z, not x and y
as you had said and the y value is it's height. Check at:
http://www.nathan.kopp.com/patched.htm
Bob
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Denis Corbin wrote:
> Hi Greg,
>
> nice animation, but a lot of questions arise !
>
> But OK, I've selected only one question :
>
> In your animation, what is the link between the surface and the position
> of the spheres ? Well in other words, how do you know the height (z) of
> the surface at a given (x,y) point ?
You need x,y,z at any given point AND the normal of the surface.
Here's the algorithm in a nutshell. Yes, it requires the mega pov patch. First I
define my Surface as an isosurface (I never liked heightfields (;-p ).
1. Particles have a starting velocity in x & z. and a starting position in x & z.
2. A trace function is called for the "new place".
#declare Downthere=trace(Surface,Oldplace+0.10*Oldvelocity+1000*y, -y, Norm);
3. The velocity is modified by adding the x and z components of the NORMAL of the
surface at the new place.
#declare Newvelocity=Oldvelocity+<Norm.x,0,Norm.z>;
4. The new place is modified by adding the NORMAL of the surface times the radius
of the ball.
#declare Placetostore=Downthere+Norm*ballradius;
Then I store the Placetostore for each ball.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
