will i have to do lots of " if(x<clock<y) " to do their motion between
clock = x and y?, or is there another way? i plan on having the camera
move, so i cant loop the frames like ive done here.

(i know the balls are floating :)

-zac

Post a reply to this message

Attachments:
Download 'nballs.mpg' (236 KB)

It looks to me like you need to implement a sine wave to the motion of the
balls... so that they start of moving fast with the initial impact, and then
slow down to a stop before gravity accelerates them back towards the other
balls.  At the moment they seem to be travelling at a constant speed which
looks unrealistic.

--

Ian

Inkwell: Ians Homepage
http://www.topcities.com/cartoon/inkwell/index.htm
zwatts <zwa### [at] softhomenet> wrote in message
news:39609726.6F0C85FF@softhome.net...
> will i have to do lots of " if(x<clock<y) " to do their motion between
> clock = x and y?, or is there another way? i plan on having the camera
> move, so i cant loop the frames like ive done here.
>
> (i know the balls are floating :)
>
> -zac
>

Post a reply to this message

I agree.  Last time I did one of these I used a sine wave
and also duplicated the last frame at each end of motion.
It might not have been 100% realistic but the little pause
looked good (or perhaps I watch too many cartoons :-)

As for the original question I recommend you download
the clockmod include file from Chris Colefax.  It allows
you to overlay functions on the clock to produce several
new "clocks".  You can use these extra clocks to control
the motion of the balls, camera, etc.

For example you should be able to create a clock that is
stopped for most of the movie and then executes a single
sine wave before stopping again.  Sounds handy doesn't
it?

"Ian Witham" <ian### [at] hotmailcom> wrote in message
news:3960aa10@news.povray.org...
> It looks to me like you need to implement a sine wave to the motion of the
> balls... so that they start of moving fast with the initial impact, and
then
> slow down to a stop before gravity accelerates them back towards the other
> balls.  At the moment they seem to be travelling at a constant speed which
> looks unrealistic.
>
> --
>
> Ian
>
> Inkwell: Ians Homepage
> http://www.topcities.com/cartoon/inkwell/index.htm
> zwatts <zwa### [at] softhomenet> wrote in message
> news:39609726.6F0C85FF@softhome.net...
> > will i have to do lots of " if(x<clock<y) " to do their motion between
> > clock = x and y?, or is there another way? i plan on having the camera
> > move, so i cant loop the frames like ive done here.
> >
> > (i know the balls are floating :)
> >
> > -zac
> >
>
>

Post a reply to this message

"Spock" <spo### [at] nospamcom> wrote in message news:3960ae75@news.povray.org...
| the clockmod include file from Chris Colefax.  It allows
| you to overlay functions on the clock to produce several
| new "clocks".  You can use these extra clocks to control
| the motion of the balls, camera, etc.

The "J" type would be best to use I think.  The equation below is taken from
the ClockMod.inc:

 translate -y*DistDown // how far to lower the ball first
  rotate SwingAmount*(1 - pow(abs(clock * 2 - 1), 2))*z (-SwingAmount for left
end)
   translate x*DistOver // place at end of line of balls (-x for left end)

It produces a nice upswing toward the right.  Switch it around for the
opposite side.
Definitely get the ClockMod from Chris Colefax if you don't have it yet
though.

Bob

Post a reply to this message

Thanks for the comments, actually after i posted i went and downloaded the
include, i havent had time to play with it yet tho. I had a sin( ) in there
somewhere, tho it didnt seem to do a whole lot, but at 11pm i didnt feel like
doing calculations to see if it was :)

-zac

oh, one more thing, the mpeg seems a little big for less than 4 seconds, am i
doing something wrong with the encoding?

Spock wrote:

> I agree.  Last time I did one of these I used a sine wave
> and also duplicated the last frame at each end of motion.
> It might not have been 100% realistic but the little pause
> looked good (or perhaps I watch too many cartoons :-)
>
> As for the original question I recommend you download
> the clockmod include file from Chris Colefax.  It allows
> you to overlay functions on the clock to produce several
> new "clocks".  You can use these extra clocks to control
> the motion of the balls, camera, etc.
>
> For example you should be able to create a clock that is
> stopped for most of the movie and then executes a single
> sine wave before stopping again.  Sounds handy doesn't
> it?
>
> "Ian Witham" <ian### [at] hotmailcom> wrote in message
> news:3960aa10@news.povray.org...
> > It looks to me like you need to implement a sine wave to the motion of the
> > balls... so that they start of moving fast with the initial impact, and
> then
> > slow down to a stop before gravity accelerates them back towards the other
> > balls.  At the moment they seem to be travelling at a constant speed which
> > looks unrealistic.
> >
> > --
> >
> > Ian
> >
> > Inkwell: Ians Homepage
> > http://www.topcities.com/cartoon/inkwell/index.htm
> > zwatts <zwa### [at] softhomenet> wrote in message
> > news:39609726.6F0C85FF@softhome.net...
> > > will i have to do lots of " if(x<clock<y) " to do their motion between
> > > clock = x and y?, or is there another way? i plan on having the camera
> > > move, so i cant loop the frames like ive done here.
> > >
> > > (i know the balls are floating :)
> > >
> > > -zac
> > >
> >
> >

Post a reply to this message

"zwatts" <zwa### [at] softhomenet> wrote in message
news:3961357E.C38B1C98@softhome.net...
| oh, one more thing, the mpeg seems a little big for less than 4 seconds, am
i
| doing something wrong with the encoding?

I noticed what looked to be jittering going on in it.  Got to be sure to use
+j0.0 in the command-line dialog (or whatever) to keep jitter off.  Or at
least I've had to do so because it seems doing so in the INI with Jitter=off
doesn't actually turn it off.  Mpeg will pick up on variances like that, plus
the small checker pattern probably doesn't help file size either.  It should
have been 150KB +/- 50KB possibly, were it a flat color background especially.
But encoders do vary as well.
You know what, I just realized you might have been talking about doing more
than one cycle of ball bounces instead of just asking about the actual motion
involved.  Which I wasn't exactly correct about before anyhow, since I didn't
consider the opposing motions.
However, dealing with both things about that, you can at least use a
'#switch()' with '#range()' (and '#break' of course) to get a number of cycles
during the animation.  That's what it seems you really meant by "#if
(x<clock<y)" and doing a series of those, but I'm still not sure you did.  If
so, then all I know of is to do something with the range directive.  Example
follows:

#switch(clock)
#range(0,1/3)
// figure left swinging motion here
#break
#range(1/3,2/3)
// figure right swinging motion here
#break
#range(2/3,1)
// figure left swinging motion again here
#break
#end

This would be three swings total of 1/3 clock duration each.  And as I said
before, I believe the "J" or Jump 'clock_type' would be the best choice.  Then
also use 'clock_repeat=3' for the example above too, or any other multiple
swings but divide up the clock accordingly.  That should be about it.  As far
as cycling with just some equation, there might be a way but I couldn't say
right now whether there is or not.

Bob

Post a reply to this message