Patrick Elliott nous apporta ses lumieres en ce 2007/10/10 01:42:

> 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, 
That's not a valid syntax and generate an error at the next object encountered.
You can transform any individual element.
You can transform the whole CSG object, but ONLY after every last one of it's 
elements have been included.
> 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.
> 
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 any such thing.
Using an array of transforms would be wastefull. It would uselessly use extra 
memory. It would make rendering slow as the whole array will need to be computed 
for every ray that encounter the object, as well as any CSG operation that use 
that object. That array will need to be dynamic as you can never tell beforehand 
how many transforms will be applyed to any particular object, adding some 
useless overhead, and requiring still more memory.

-- 
Alain
-------------------------------------------------
Don't waste your time on a man/woman, who isn't willing to waste their time on you.

Post a reply to this message