POV-Ray : Newsgroups : povray.general : Status of Moray? : Re: New SDL for POVRay Server Time
5 Jul 2025 04:08:40 EDT (-0400)
  Re: New SDL for POVRay  
From: Patrick Elliott
Date: 13 Oct 2007 00:11:10
Message: <MPG.2179f3215e243b3a98a046@news.povray.org>
In article <470dbc43$1@news.povray.org>, dne### [at] sanrrcom says...
> Patrick Elliott wrote:
> > Umm. Because it doesn't make much sense? Seriously, any such transforms
 
> > are going to be "very" specific to the IK chain of the particular objec
t 
> > you are working with. There is no point in making an array called 
> > "walk", which contains the needed transforms, instead of making it part
 
> > of the object, because logically it can't be applied to any "other" 
> > objects.
> 
> Errr, well, have you used Hash Animation Master? As long as you name the
 
> bones the same there, you can apply the "walk" to anything you want.
> 
> However, you missed my point, which was that if the array is separate 
> from the object, you can have multiple arrays and hence multiple sets of
 
> transformations that apply to the object at different times in the 
> animation.  If the character walks a while, then runs a while, do you 
> put the walk transformations or the run transformations in the object?
> If the array can be indexed by the object itself, then there's no 
> question in the code of the transformation being "off separate" 
> somewhere that's hard to find.
> 
But, nothing is stopping you from trading out the arrays, like you would 
with any other similar case. And yeah, I covered the issue with applying 
the "same" walk to anything you want. 1) it wouldn't really work, unless 
it had identical parts, and 2) for realistic animation of anything other 
than marching robots, its not applicable, since you never want two 
objects behaving 100% identically to each other.

Ok, lets get at a practical example. Lets say all you have is a sphere 
and torus. The torus is rotated a bit out of the plane of rotation. The 
initial design would look like (not checking the code, so I hope it 
comes out close. lol):

#define wobble = union{
  sphere {<0,0,0>, 1}
  torus {<0,0,0>, .5, 2> rotate <.1,0,0>
  texture{blah}
  rotate <0,clock,0>
  translate <56,43,12>
}
                    
This makes an object that, from the code perspective, looks like:

wobble
  \-sphere
    \-location
    \-size
  \-torus
    \-location
    \-size
    \-transforms
      \-[0] rotate <.1,0,0>
  \-texture
    \-...
  \-transforms
    [0] rotate <0, clock, 0>
    [1] translate <56,43,12>

This "continues" to be the way it works for 10 frames. Then you "keep" 
the rotation, but also change the angle of the torus (over 10 more 
frames).

toruschange[0] = "rotate <.1 * (20-10/10),0,0>"
toruschange[0] = "rotate <0,0,0>"
wobble.torus.transforms[0] = toruschange[0]

Then at frame 21 you "stop" both the rotation and the change to the 
torus, but send the object zipping down some 3D path:

z = clock //Lets say its now also 21.
main_trans[0] = "rotate <0,z,0>"
main_trans[1] = "translate GetLocation()"
wobble.torus.transforms[0] = toruschange[1]
wobble.transforms = main_trans

In this case z, unless you change it, will "remain" 21, so from then on 
you don't need to update anything in the object, and "GetLocation" 
returns a "path" that the object is going to follow, so that is 
automatically recalculated each frame, before the render happens.

You saving memory this way, because you **don't** have to change any 
transforms that you don't have to, while your way requires they all be 
stored, even the ones that don't change. Further, the "initial" state is 
"stored" in the object, so if instead you wanted wobble to do nothing 
but sit in one place through the entire animation, without ever changing 
its behavior, you don't ever have to do anything more than set use the 
SDL to tell it to use the clock value the determining how much to rotate 
it each frame.

Note, it might be useful to allow the "clock" to return both an integer 
of all "seconds" that have passed, as well as things like clock.seconds, 
clock.minutes, etc. Just for the sake of only having to do, "rotate <0, 
clock.seconds * 6, 0>", instead of something like "rotate <0, mod(clock 
/ 60) * 60, 0>". Mind, that isn't that bad, but a more direct way to get 
the number might be nice anyway, especially if you are incrementing the 
time by a large factor, like for time lapse or something.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
 
3D Content, and 3D Software at DAZ3D!</A>


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.