In article <pan### [at] maccom> , Christopher James
Huff <chr### [at] maccom>  wrote:

> The structure of functions calling other functions and passing the
> results to other functions could be the "state". But if that's not what
> you are talking about, I have no idea what you are thinking of.

I think I am very bad explaining it; it is a really unusual concept that
doesn't even make sense in programming languages.

Lets take a scene object like a sphere.  Its most primitive form is defined
as a vector and a scalar.  Now, these are both expressions.  As you know it
is easily possible to determine if an expression is constant or now.  Before
I continue, please ignore the existence of the preprocessing stage, that is
all directives as it only gets confusing when describing this, but
nevertheless will still work the same with them.

So, now you determine an expression is not constant.  In the scene
description language this would most likely be due to the use of "clock" in
the expression.  Instead of replacing the "clock" with a constant and having
to re-parse for every frame, you just store the expression as function.  The
important backward compatibility would still exist by re-parsing the scene
just as it happens now, but at the same time objects can now be modified in
one frame, which is for example very useful when doing motion blur.

However, this is only a simple case.  The same logic can be applied to
everything else.  If the parser can detect expressions, it can also be
implemented such that it can automatically determine if a block-level
statement contains a usual definition or a complex multi-line expression
(function).  A simple case to explain this with would be a texture.  For
simplicity, lets assume a texture is computed only based on the intersection
location and normal vector.  So if you open a texture block and find
anything else but a texture definition, assume it is a multi-line
expression.  (This is much easier as it may sound, really!)  So, now assume
there are two predefined names for these implicit parameters (just like
x,y,z,u,v are currently in function blocks).  Lets say they are
"intersection" and "normal" (what name they are is really irrelevant for
this example).  So, now you can have a function that uses these to
variables, both of which would be vectors.  All you now need is to return a
color vector from your functions and you have a custom texture!

This can be adapted to all other block level "objects".  They can either be
a predefined hardcoded type or any complicated expression you can imagine.
Essentially it would allow you to overload any default block level
functionality.  It would even be possible for objects by just adding an
"intersection-test" block, "inside" block, etc and use it in object blocks
to create completely user-defined objects.

What is very nice is that such an implementation would only extend the
current SDL and not require scene modifications, yet it would allow control
over absolutely everything.  Just imagine a custom camera block or
light_source block.  It would essentially make patching the source code
unnecessary when developing features.  Even better, by also writing a
utility to convert the internal language code to C/C++ code one could easily
add those features later and get native speed.

> You said everything would be a function...are you talking about an API
> where you use functions to create objects in the scene?

No!  I am not talking about destroying POV-Ray and turning it into a
unusable piece of waste! ;-)

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message