POV-Ray : Newsgroups : povray.general : Should POV-Ray be split up and redone? : Re: Should POV-Ray be split up and redone? Server Time
13 Aug 2024 17:21:59 EDT (-0400)
  Re: Should POV-Ray be split up and redone?  
From: Ron Parker
Date: 29 Jul 1998 10:39:35
Message: <35bf2617.0@news.povray.org>
On Wed, 29 Jul 1998 11:25:00 +0900, Rainer Mager <rvm### [at] cyberadjp> wrote:
>Hi all,

>1.    Pre-parsing / POV Binary format: I think it would be very, very useful
>if POV-Ray supported some sort of compiled binary format for scene files and
>that this format was well defined and documented. There are a number of
>benefits this could give which will be discussed below.

This does sound like a good idea, so long as the format is extensible and
flexible.

>
>2.    Object orientedness: I've often felt that POV-Ray is screaming to make
>its scene language more object oriented. I think something like the
>following would be very useful (this is not 100% thoughtout yet):
>
>        mySphere = new sphere( <0,0,0>, 1.5 );
>        mySphere.Texture = myTexture;
>        myNewSphere = mySphere;
>        mySphere.Scale = x*2;
>        myNewSphere.Scale = y*2;
>        while( intersects( mySphere, myNewSphere ) ) {
>            mySphere.x += 0.01;
>        }

Surely you didn't mean to scale your spheres by zero in two dimensions.
There is a big difference between saying "scale the object by 2" and "set the
scale of the object to 2," and that difference isn't apparent in this syntax.

Also, you're slipping in a new function (intersects) that would be a 
tremendous chore to write, object oriented or not.  Collision detection with
the kind of primitives POV-Ray provides is not easy at all.  

By the way, you can approximate this now, except for the dubious intersects 
function with:

        #declare mySphere = sphere{ <0,0,0>, 1.5 }
        #declare mySphere = object {mySphere texture myTexture}
        #declare myNewSphere = object {mySphere}
        #declare mySphere = object {mySphere scale x*2} // gives a warning
        #declare myNewSphere = object {myNewSphere scale y*2} // this too

>    Although, in theory, someone could write a new scene language parser now
>that generates normal POV scene language I think this idea would be a lot
>cleaner and easier in the long term.

Actually, as you see, it's not hard to translate what you wrote into POV code,
but the result probably takes a lot longer to parse.

>    I think that one of the real short comings of POV-Ray right now is how
>difficult it is to "know" about an object created in a scene, especially for
>object interactions. At the same time I don't think the ability to do this
>should be forced into the render engine. Given a clean, well defined render
>engine then any outside idea could be implemented.

When you put the ability to know about an object into POV-Ray, you're not
putting it into the render engine.  You're putting it into the parser.  For
example, my object bounds patch at http://www2.fwi.com/~parkerr/traces.html
is mostly a patch to express.c, the part of the parser that deals with 
expressions.  The only difference between the way it is now and the way it
would be if the parser were split off is one of compile time and (I hate to
say it) run time.  Yes, splitting off the parser would actually SLOW POV 
DOWN as it writes the sometimes-massive binary representation to disk and 
then reads it back.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.