On Tue, 25 Jun 2002 10:51:25 -0500, Rafal 'Raf256' Maj wrote:

> I think that I can write a little preprocesor that will impliment this
> function, and I would only take about 0.01-0.05 sec every 1000 lines of
> .pov source on 1GHz.

Writing that preprocessor would be very difficult, and a preprocessor
would not be sufficient for all cases. Here is one simple one that is
unsolveable with a preprocessor:

#macro Position()
    translate -min_extent(this)
#end

sphere {... Position()}

And what about something like:
sphere {min_extent(self), 1}
Your preprocessor would need to define default values for everything.

Plus, just recognizing all the different kinds of objects and figuring
out how to split them up properly could be impossible. For example:

#macro Ball(Center, Size)
    sphere {Center, Size
#end

Ball(< 0, 0, 0>, 1)
    pigment {proximity {self ...}}
}


> I can write it - because I want to do something for best free 3d
> renderer ever :) I hope that this will be usefull... If I would write
> [1] some preprocesor that will add useful functions to POV, will someone
> just add my ANSI C code to pov souces (or do You have too many volunteer
> coders already ;) ?

Hacking in a preprocessor stage does not sound like a good idea, and
almost certainly would not get into any official version. The idea sounds
useful, but the method you propose is a "dirty hack" that wouldn't work
perfectly and could cause some very difficult to diagnose problems when
it goes wrong. Something like this should be carefully added into the
existing structure, not bolted onto it to trick the existing code into
doing what you want.


-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: <chr### [at] tagpovrayorg>
WWW: http://homepage.mac.com/chrishuff/

Post a reply to this message