In article <470b5016@news.povray.org>, war### [at] tagpovrayorg says...
> Bruno Cabasson <bru### [at] alcatelaleniaspacefr> wrote:
> > I think that leaving the responsability to handle these stacks of
> > transformations to the programmer is dangerous and requires too much
> > programming skills wrt the goal we intend to reach in terms of programm
ing
> > ease and accessibility.
> 
>   There's no more skill involved than in the current POV-Ray when you app
ly
> a series of transformations to an object.
>   There's no need for a stack. There's no need to revert transformations.
> You simply apply a series of transformations to the object at each frame
> (basically what you do with the current SDL, but without having to repars
e
> the object).
> 
>   I really can't understand what is the problem people are seeing here.
> Could someone please explain to me this?
> 
>   Is it that some people seem to think that once you have applied a
> texture to the object you can't transform the object without transforming
> the texture too? Says who? Just because you can't do it in the current SD
L
> that doesn't mean it wouldn't be possible in the new one. Even in the
> current SDL it's just a *syntactical* limitation. There's absolutely no
> technical reason why there couldn't be a command like "apply this
> transformation to the object but not its texture". It would simply be
> a question of adding the proper syntax for it.
> 
>   Seemingly some people also think that if a transformation has been
> applied, it's engraved in stone and cannot be removed anymore. Removing
> all the transformations is just a question of resetting the transformatio
n
> matrix. Then you can re-apply all the transformations you want to the
> object, making the modifications you want.
> 
>   (Granted, in the current POV-Ray implementation this would require a
> bit more of work because certain transformations to certain objects are
> "optimized away", for example by applying the transformation to some
> object coordinate instead of applying it to the transformation matrix.
> Thus such a transformation would indeed by "engraved in stone" and not
> possible to revert.
>   However, it's perfectly possible to change this system without removing
> these optimizations. It's possible to apply all the transformations to
> the transformation matrix of the object and then, after all the
> transformations have been applied, just before starting the rendering,
> it's possible to examine the transformation matrix for certain properties
> and if these properties exist, they can be "optimized away" in the same
> way as currently. For example, if the object is a sphere there exists a
> translation component, the translation can be applied to the center
> coordinate of the sphere and removed from the transformation matrix.)
> 
> > My point of view is that within a single frame, all transforms should b
e
> > defined at creation time, and post creation transforms should be forbid
den
> 
>   Why impose such an artificial limitation? It doesn't make any sense.
> 
I think we are talking past each other here in some respects. Yeah, I 
agree, if they work in the sense that they should, i.e., scaling 
"before" defining the last object in a union also scales "that" object, 
not just the prior ones, then applying all transforms "after" is 
perfectly valid. It doesn't fundamentally change my argument, which is 
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 apply 
10 transforms to object Z, then *make that array* part of the Z object, 
*at least* from the perspective of the coder. That way you can tell 
"what" they belong to by simply referencing the object they belong to, 
not some arbitrary array that has no association, save that you just 
happen to use it for that.

Or is there some huge objection to making it even than simplified?

Oh, and the idea of placing each "type" of transform into a separate 
array is more like a filter. I.e., you want to change the 3rd "scale", 
just reference the 3rd scale in the array, even if it is "actually" the 
7th transform. This doesn't even need to be a separate array, just a 
function call that counts the transforms in the main array, until it 
gets the "nth" transform of the type requested. In other words, 
something like:

function translate(n)
  c = -1
  for each temp in self.transforms
    if type(temp) = "translate" then
      c = c + 1
    end if
  next
  if c > -1 then
    return c
  else
    return -1
  end if
end function

"transforms" being the "array" that is used to track "all" transforms 
applied to that object in the original SDL step that created it, which 
would be identical to the existing SDL. This doesn't prevent you adding 
new transforms, either via the existing SDL method, or via the object 
reference, or even *deleting* one that was previously applied (which 
isn't currently possible).

Hope that is clearer.

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