|
|
Vadim Sytnikov wrote:
>
> [...]
>
> I'm sure that one day we will see functions as complex as shaders in
> RenderMan. By the way, I do not think that there exist any fundamental
> difficulty for that -- I know that many have branded that not feasible on
> portability grounds. But -- that only applies to the solution that was
> implemented in POVMan (based on POV-Ray 2.2, IIRC), which employed bytecode
> compiler built with Flex/Bison. If you look at how it was done in BMRT, you
> will find quite different solution, less powerful, but more portable (SL
> files are not even compiled, they are, err... preprocessed :-)
One major concern about functions is speed. Although PovMan can be very
useful, the performance of shaders compared to Povray 3.5 functions is
rather bad i think. I have not worked with BMRT, but i doubt it is
faster.
> So my point is -- we should not have, say, two different if's, for parse and
> rendering time, but rather a single statement. If its control expression
> does evaluate to a constant -- OK, it works like present #if. If it does
> not -- well, it depends. If context does allow the use of functions (say, in
> a height_field or an image_map), then, if we are not inside a function body
> already, then that 'if' should be implicitly wrapped by the automatically
> generated function (and should thus work as 'if' in Algol -- that is, return
> a value). If the context does not allow that -- signal an error.
From how i understand this you want to mix up the parse time and render
time level. Note this is quite different from the previosly discussed
directives and scene description layers during parsing. I don't know how
much you have worked with Povray 3.5 functions, but to distinguish between
those two levels is quite essential for scene design.
For example have a look at:
http://www-public.tu-bs.de:8080/~y0013390/pov/water/water_inc.html
for a scene efficiently using directives in functions.
Christoph
--
POV-Ray tutorials, IsoWood include,
TransSkin and more: http://www.tu-bs.de/~y0013390/
Last updated 13 Mar. 2002 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|