In article <470cecd7@news.povray.org>, dne### [at] sanrrcom says...
> Patrick Elliott wrote:
> > that, "If you are going to store that stuff in an array, lets at least
 
> > assign the array to something that "looks" like its part of the object,
 
> > and not some separate entity." In other words, if you are going to appl
y 
> > 10 transforms to object Z, then *make that array* part of the Z object,
 
> > *at least* from the perspective of the coder.
> 
> Why not just allow arrays that can be indexed by objects? Then you can 
> have multiple arrays of transformations per object. You could have a 
> "walking" array, indexed by body part, where each element is an array of
 
> transforms to be applied at each step of the walk cycle, then a 
> "running" array indexed by body parts ....
> 
> Walking gets
> object arm = cylinder(....)
> object leg = blob(...)
> translate(arm, walk[arm].translates[frame % 6])
> rotate(arm, walk[arm].rotates[frame % 6])
> translate(leg, walk[leg].mytranslate[frame % 6])
> 
> Running gets
> object arm = cylinder(....)
> object leg = blob(...)
> translate(arm, run[arm].translates[frame % 6])
> rotate(arm, run[arm].rotates[frame % 6])
> translate(leg, run[leg].translates[frame % 6])
> 
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 object 
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. The only argument that could be made is that you might want 50 
marching robots, which all move the same way. If you plan to add any 
sort of variability in their motion though, you run into the same 
problem, no single set of transforms will be applicable to "every" IK 
chain in those 50, so trying to apply the same one to all of them won't 
work.

This does present an issue though. Its true that storing these "will" 
hog memory. The simplest solution is to store a master list, which 
includes calls to a function that can vary the motion, dependent on the 
objects ID, of some sort. In other words, instead of storing something 
like: arm.transform(6)="rotate <4,5,3>", you store arm.transform(6)
="rotate <calc_angle(self.ID),5,3>", where calc_angle would get the 
"frame" number from the animation object, check the ID, then figure out 
what its supposed to do from that.

In a sense, when rendering, no object ever "completes" its creation 
cycle until the final parse happens. All objects exist, with "blank" 
transform matrices, **until** you call "render" at which point the 
"script" inside the array is played out for each level, starting at the 
deepest, until a final matrix for each object is completed, *then* the 
render happens. I don't see how else you handle it and *still* preserve 
the current SDL model. You can't simply revert, without replaying the 
transforms anyway, nor can you just toss a new one in, and hope that 
somehow the engine will produce the result you wanted. You have to delay 
final creation "until" you inform the engine that you want it to render 
the result.

Again, as with my prior post on that, a scene marked to use the "old" 
behavior wouldn't do that, it would complete, then render. In a scripted 
animation though, "complete" when talking about the state of an object 
is either referring to one where the types and number of transforms are 
"intentionally" limited, or its a real fuzzy concept, at best. lol

-- 
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