In article <470d186a$1@news.povray.org>, zeg### [at] povplacecom 
says...
> "Darren New" <dne### [at] sanrrcom> wrote in message 
> news:470cf833$1@news.povray.org...
> > Alain wrote:
> >> You obviously miss a fundamental point: there is only ONE transform 
> >> matrix per object that contain the SUMATION of every single transforms
 
> >> applyed to that object. There is no transform array, there never was a
ny 
> >> such thing.
> >
> > I'm amazed at the number of people arguing
> > "This is how the next one should be."
> > "No, this is how the current one is."
> > "But this is how the *next* one should be."
> > "Don't you understand this is how the current one *is*?"
> 
> that's not how it is, it's more like this:
> 
> "This is how the next one should be."
> "No, this is how the current one is, and there's absolutely no reason why
 
> that particular part should change."
> "But this is how the *next* one should be."
> "You really don't understand why the current one is the way it is, do you
?"
> 
> If you ask me, keeping an array of transformations makes it all needlessl
y 
> complicated. If you want such an array, define it yourself in SDL, there'
s 
> absolutely no need for it in the POV-core.
> 
> In my opinion, the main idea of the new SDL should be to seperate the 
> core-functionality from the user-definable functionality.  At the very ba
se 
> of the rendering-process, having an array of transformations is simply 
> ridiculous.  If users want such an array, then I'm sure someone will writ
e 
> an inc-file (or whatever) that makes this possible and even easy to do.
> 
> cu!
> 
Your seriously missing the point. Sure, you could just create an array, 
but we are looking at how you A) maintain the syntax while B) also 
supporting **real** animation and flexibility in a new SDL. Lets put it 
simpler. Right now, if you used SDL like the following certain things 
will happen:

object {
  foot{some_transforms}
  low_leg{some_transforms}
  top_leg{some_transforms}
  some_transforms
}

The parser is going to "immediately" perform each transform 
"statically" to each sub object, then to the final one, parse the rest 
of the script, then render. You *can't* do it that way in a SDL/script 
that doesn't exit, it has to be able to handle the "final" creation 
"just before" the render, so you can make changes from frame to frame, 
without reparsing the entire file. What I would be proposing is:

object {
  foot{some_transforms} // Object created, transforms stored in 
foot.transforms.
  low_leg{some_transforms} // Object created, transforms stored in 
low_leg.transforms.
  top_leg{some_transforms} // Object created, transforms stored in 
top_leg.transforms.
  some_transforms //Final transforms still stored, since they may 
contain things "dependent" on function calls or variables, which may 
change.
}
 // Transform functions stepped through for every object, generating 
**this** frames transformation matrices, then the engine renders the 
result.
render
top_leg.transform(2)="rotate <5,0,0>" // Change position of the leg.
// Again, the matrices are created for "this" frame, then rendered.
render

Mind you, a good system will also flag object that do change between 
frames, so only those objects that "need" to have there matrix 
recalculated have it done. Noting too that those containing "variables" 
instead of specific locations must always be recalculated (since the 
variables could change). That won't slow things down, it will bloody 
speed them up, for all objects that don't have "calculated" rotations, 
translations, etc., since the last thing you want to do is recalculate 
the transform matrix for 500 static objects that "don't move" between 
one frame and the next, if all you want to do is make the robot take a 
step. The current SDL has to recalculate ***every*** matrix for 
***every*** frame. Memory be damned. Yes, it "might" take more, 
depending on if some shortcut does/doesn't exist to help avoid that 
issue, but you can't fix the limitation that exists in how the current 
SDL works by pretending it doesn't exist at all, or that you can fix it 
by without changing how the parser/engine works.

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