In article <471### [at] hotmailcom>, a_l### [at] hotmailcom 
says...
> Patrick Elliott wrote:
> > In article <47109fba@news.povray.org>, war### [at] tagpovrayorg says...
> >> Patrick Elliott <sel### [at] rraznet> wrote:
> >>> You keep claiming that you can just somehow "untransform" 
> >>> the matrix
> >>   Do you understand the concept of resetting a transformation matrix?
> >> Or is that concept way too difficult for you to comprehend?
> >>
> > Think I have already addressed most of this in the other post I made 
> [snip]
> > 
> > Or do you want to beat the straw man some more?
> > 
> I am not familiar with that expression, but anyway here are my 2 cents.
> 
> What you deem necessary for animation is in my (and Warp's if I may 
> speak for him) overkill. It may be handy for some situations but I think
 
> in the majority of cases I wouldn't use it. POV4, however, should make 
> it possible and easy to use. So what this discussion should have been 
> about is to what extend it has to be hardcoded in either the internal 
> datastructures or in the syntax of the language. My (and presumably 
> Warp's) opinion on this is that what you propose will be extremely easy
 
> to implement yourself within the new language for those cases where you
 
> need it. So it has no implication for the current POV4 discussion 
> whatsoever. You are free to continue this discussion with warp of 
> course, but it will be like talking to a wall, without being able to 
> study the delicate texture of the stones.
> The opinion that it is not needed is based on knowledge on how the 
> current implementation works and some safe assumptions on what POV4 will
 
> allow at the minimum. However, you should watch the development closely
 
> that indeed these minimum requirements will be met. Or even better: 
> create a list with those minimum requirements on the new wiki.
> 
Well, I have, in another post today, reversed my position somewhat. I 
still think an associative connection is useful, but that the method I 
suggested "is" a bit overkill and probably not strictly necessary. The 
modified concept allows for:

1. Associative connections between an array with the transforms needed, 
(which may include for multiple frames.), when needed.

2. Auto-magical application of those, instead of having the explicitly 
apply them.

3. No storage of anything "on" the object itself.

This loses the ability to track the "initial" state though.

But, one thing I do still think needs to remain is the idea that if you 
don't "explicitly" change a matrix, either via the automatic system or 
the manual code based one, it doesn't make sense to "reset" everything 
to the base state, then reapply things. Not sure how you work that 
though, since a change to a foot might have "its" matrix effected by 
transforms on the lower leg, upper leg, and even the full object. Do you 
just "save" the matrix for each object/union level, then reapply those 
transforms that effect them? If you reset them completely, then you are 
re-applying possibly hundreds of transforms, which you *must* store some 
how, when you might only be changing "one" in the entire chain. Its 
probably more cost effective to store all matrices at each level (i.e. 
the "default" state for that object/union), then only recalc those 
"specifically" effected by any change you later make. Hmm..

Oh, and "straw man" refers to side tracking an issue into something 
either not directly related to, or completely unrelated to, the main 
issue being discussed, usually, though not always, to avoid talking 
about the original subject. Its similar to "tilting at windmills".

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