in news:3f6f5605@news.povray.org Tim Nikias v2.0 wrote:

>  E.g. macro's with same
> name, but if I leave out a texture, it
> will still work:
> #macro Tex_Translate(Position,Texture)
>  texture{Texture translate Position}
> #end
> #macro Tex_Translate(Texture)
> 

Something like this?:
http://www.python.org/doc/current/tut/node6.html#SECTION0067100000000000
00000   
4.7 More on Defining Functions and further
(there may be a few zeros broken off that link)


Regarding speed, when I made my param.inc file I also did it in python. 
The original param.inc only used macros and was quite a bit slower that 
its Python equivalent. After rewriting param.inc to using functions the 
parse time of both seemed the same at first sight, but SDL was actually 
faster. In the same time it took to run the python program, SDL did the 
same calculations and also parsed a million triangles. The resulting 
file generated by python still had to be read and parsed by POV-Ray 
then. So SDL isn't that bad in all cases. In one of the old MegaPOV 
versions is a patch for speeding up macros that also helped a lot. And 
when I see the speeds that can be reached with for example the 
'interpreted' version of ocaml, there must still be some room for 
improvement somewhere.


Regarding plugins, why do so many people want these and why do so few 
people suggest going in the "opposite way". Chop POV-Ray in two/three 
pieces, a raytracing libray (+parser) +API and have the SDL as its prime 
implementation. Then everybody could write their scenes in any language 
somebody generated a binding for. You could even plug POV-Ray into one 
of the big 3D apps, although you probably could do now too if somebody 
wrote the stuff that is needed inbetween.

All the above is offcoarse written without being hamperd by any 
knowledge of the matter.

Ingo

Post a reply to this message