In article <4723f102@news.povray.org>, war### [at] tagpovrayorg says...
> Patrick Elliott <sel### [at] rraznet> wrote:
> > Yes, we are talking about percentages here, but those can matter, 
> 
>   What's so hard to understand in the concept that applying transformatio
ns
> to objects is in no way the slowest step in the parsing process? Using yo
ur
> transformation tables will *not* speed up parsing, not in any relevant wa
y.
> Using speed as an argument to support your idea is simply flawed.
> 
And what part of, "Its not the applying of them that is the issue, its 
how you get the data read/parsed to do it.", are you missing?

And I am not using speed as support for my idea. I think the idea is 
still good on its own merits, since otherwise you have to write your own 
way to do it, and most of the people trying to do stuff in POVRay are 
***not*** going to be interested in reinventing this same wheel over and 
over again. Putting it in a plugin is possible, yes, but **only** if the 
framework is available to allow for it in the first place. A framework 
that only allows you to add new tokens, as it where, for new functions, 
but which can't handle something like this **won't** do it. I thought 
about it, and it just won't work, not without having to add a command 
word to every level of a compound object you want to use it on, which is 
imho damn stupid, if there is a better way.

I covered the point of if the idea was useful already, and whether you 
fracking agree or not, I instead opted to talk about the logistics of 
implementation and the likely issues that could pop up as a result of 
it. Your idea, that you explicitly tell it to apply a transform (or even 
a table of them) every damn time is programically complex, unnecessary 
if the framework exists to do it my way, and divorces the data from the 
object in a way I personally don't like much. Its not functionally 
equivalent, since yours is explicit, mine is implicit, even if on the 
deeper level some of the code is necessarily similar.

And again, the point is, how would you implement it. Which method 
**would** be faster, when you want to use predefined transforms, where 
you have no plans to change the number, type or any major features of 
those things. Whether or not you think its a good idea has jack to do 
with how you would implement it, if it was used, which is what nearly 
the entire prior post was about.

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