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

On Tue, 25 Jun 2002 15:34:48 -0500, Thorsten Froehlich wrote:

> Yu still inherit a bunch of problems from pointers/references which are
> not necessary.  After all, there is still no real need.  A function
> simply operates on whatever object it was called by.  It couldn't access
> any other object anyway...

Nobody said anything about pointers or references. I don't see how they
apply.


>> That sounds like my understanding of a functional language
> No, it would not because POV-Ray SDL itself describes a state and still
> would after such an extension.  The function would be nothing else but a
> user-defined type of texture, pattern, media, vector, float, matrix etc.

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.

You said everything would be a function...are you talking about an API
where you use functions to create objects in the scene? Like
create_sphere(), add_object(), translate(), etc? That is the only other
way I can think of to interpret what you are saying, but it doesn't sound
like a very fun way to code a scene...


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

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

On Sun, 30 Jun 2002 16:12:38 -0500, Thorsten Froehlich wrote:

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

Ok, I think I'm understanding what you meant now...kind of a markup
language describing a scene with dynamic parts (expressions) that would
respond to the clock variable. The scene would be set up at parse time and
the non-constant portions would be re-evaluated for every frame or every
time they are accessed. You could have optimization detect three types of
expressions:

constant-for-scene, like "1" or "< 1, 3, 5>"

constant-for-frame, like "clock*3"

always-evaluate, such as a texture expression that uses ray or
intersection information.


>> 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! ;-)

Good, I didn't like that idea either.


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