These thoughts are provided merely as a point
of discussion.

Here are a few ideas about a C++ povray.
Basically, I think the biggest assets
in POV are the existing mathematics and
the scene description language.  While
I feel that general compatibility with
the scene description language should
be maintained, I think the parsing
should be re-designed.  Essentially,
I think that objects should know how
to parse themselves.  This could be
implemented by designing a "parsable"
interface for each derived object,
and adding a new plug-in is simply a
matter of compiling in the new class.
This drags in a few more ideas, like
giving each object in the system a
name, so that when the parser encounters
the string "sphere" it knows to 
construct a PovSphere object.  If the
parser encounters a "FunkyNewSphere"
string, but the class is not compiled
into the binary, it can simply ignore it.
(Perhaps issuing a warning)

Would anyone like to expand the design?

Summary
-------

Base Classes:

PovObject
PovParsable
PovPrimitive 
PovCamera
PovCanvas

Derived Classes:

PovSphere
PovBox
PovPlane
PovCsgUnion
PovCsgIntersection
PovCsgDifference

Detailed Information
--------------------

PovObject

  Generic base class for all POV objects.
  
  Methods:

    char *getObjectName()   "sphere" for example

    protected constructor: setObjectName(char *)

PovParsable (is a PovObject) 

  Abstract interface for Input/Output

  Methods:

    bool  supportsTextInput();
    bool  supportsTextOutput();
    bool  supportsBinaryInput();
    bool  supportsBinaryOutput();

    constructor from istream

    void  writeText(ostream &os);
    void  writeBinary(ostream &os);

    void  readText(istream &is);
    void  readBinary(istream &is);

PovPrimitive (is a PovParsable)

  Abstract interface for ray-tracable geometric object.

    bool intersectRay (double &t,        PovRay &ray);
    int  intersectsRay(vector<double> &t,PovRay &r);

    PovBoundingBox boundingBox();

PovCamera (is a PovParsable)

  Abstract interface for camera.  All cameras
  do is emit ray's.

    int  rays();
    Ray  ray(int x);

PovCanvas (is a PovParsable)

  Images are formed by painting the result of
  emitted camera rays onto a bitmap image.

    setCamera(PovCamera &camera)
    setFilename(char *filename)

    render();


-- 
Nigel Stewart (nig### [at] eisanetau)  http://www.eisa.net.au/~nigels/
Postgrad Research Student, RMIT University, Melbourne, Australia
All extremists should be taken out and shot.

Post a reply to this message

Nigel Stewart wrote in message <371438B4.3D35341D@eisa.net.au>...
>
>Here are a few ideas about a C++ povray.
>
>Would anyone like to expand the design?



How about a PovWorld or a PovScene object?
This is the object that contains all the
other scene objects, and is therefore
the root node in the scene graph.
Stuff like PovWorld.scale(x,y,z) would
scale the geometry of the entire world,
whereas object-level calls like Sphere.scale()
and Sphere.Translate() would do the
intuitive transform, making the sphere
bigger but translating it using the
world's coord system.

Of course, a PovGroup object or
a POVCSGUnion object might be the same thing,
except PovWorld has no parent object
and may have methods specific to it.

Hmm... would camera objects be part
of the PovScene scenegraph? If I scale
the world, do I want the cameras to
scale with it?

We could also use subclasses of PovCanvas
like PovZbuffer, PovAlphaChannel...

Ray

Post a reply to this message

I've had an interesting thought about what
should be the "top level" object in an OO
scene for raytracing.  In one sense it is
the camera, since all the rays originate
from it.  Otherwise, you can have a glorified
Union container, perhaps with global 
parameters tacked on.  One interesting 
alternative is treating the top level
object as a 2D texture.  A camera naturally
maps 3D rays to the 2D texture, but allows
procedural textures, blending, even camera-
motion blur, for each pixel. 

To implement camera-motion blur, you put
maybe 20 cameras and average the result for
each pixel, perhaps multiplied by a brightness
channel for fade in.out, etc.

Simply:  PovCamera is a PovProceduralTexture

> How about a PovWorld or a PovScene object?

PovScene  (is a PovParsable)

  Container class for a world or scene.  Global
  parameters, cameras, fog, clock, etc live here.
  A PovScene may contain any number of camera's
  that are selectable without editing the scene
  file, perhaps from the command line.  
  
  Methods:

    void   setTime(double time);
    double getTime();

    bool   selectCamera(int cameraIndex);
    bool   selectCamera(char *label);
   
    vector<PovCamera> &cameras();

  Notes:

  Associate the whole scene with a transform?
  Allow encapsulation of scenes within scenes?
  -  If a ray enters a room, model the room as
     a seperate scene?
  -  If we're watching TV, allow TV to be an
     independent scene?

> We could also use subclasses of PovCanvas
> like PovZbuffer, PovAlphaChannel...

PovZbuffer (is a PovCanvas)

  Can be used as an alternative to an RGB
  canvas, stores the distance for each ray,
  rather than performing shading, lighting,
  etc.

PovAlphaChannel (is a ????)

  Notes:

  Where does alpha channel fit?  Is it simply
  the degree of "background" that shows for
  each pixel, or is it something more?  Perhaps
  alpha channel should be an optional extention
  of PovCanvas.

Post a reply to this message

Nigel Stewart wrote in message <3714BFE3.BF82787E@eisa.net.au>...

>
>PovAlphaChannel (is a ????)
>
>  Notes:
>
>  Where does alpha channel fit?  Is it simply
>  the degree of "background" that shows for
>  each pixel, or is it something more?  Perhaps
>  alpha channel should be an optional extention
>  of PovCanvas.

Background visibility is a good definition.
Having it as a member of PovCanvas seems right.
During the raytracing process, rays that
partially hit objects or never hit them
set a transparency value into the alpha channel.

Having other compositing channels/canvasses
would be good too, like one for shadows only.

Ray

Post a reply to this message

Here's some things on my POV wish-list...

*  Programmable procedural texturing,
   using macros.  (Perhaps slow, but
   certainly fun and flexible)

*  Perhaps programmable cameras.
   (Write your own motion blur and
   stuff into it)  All you need to
   to is define the interface, and
   let any POV file supply the
   macro.

Post a reply to this message

Some plug-in architecture like GIMP has.
Its simple and portable.

Disnel

Post a reply to this message

I think a sanctioned, Leveller-like plug-in architecture would be great.
Instead of having to mix and much unofficial patches, you would just have to
register a plug-in and call it in a standardized way from POv-Ray scripts.
By the way, I have started playing with Linux (besides Win32) and I saw that
also in Linux you have DLLs (even if they are called differently). So,
Windows has DLLs, Linux has DLLs, I presume that other UNIX flavours have
something like DLLs, Macs have the equivalent, VMS has shared libraries....
I think every target of POV-Ray has the system support for DLLs, so PLEASE:
dynamically loaded plug-ins!!!!

Alessandro Coppo
a.c### [at] iolit
www.geocieties.com/SiliconValley/Way/8111

Disnel wrote in message <371C9AE6.D6AF1D34@linux.itam.cas.cz>...
>Some plug-in architecture like GIMP has.
>Its simple and portable.
>
>Disnel

Post a reply to this message

Do it in dos and amiga, and make a plugin cross compilant. (no or little source
changes.)
Then it's worth thinking of. And, you'd have to be able to implement it at a
decent speed level(where/how would the changes be applied?) 
No, that's why the source and patch version is here, to avoid that sort of
struggle, and to KEEP it cross compilant.


-- 
//Spider
        [ spi### [at] bahnhofse ]-[ http://www.bahnhof.se/~spider/ ]
What I can do and what I could do, I just don't know anymore
                "Marian"
        By: "Sisters Of Mercy"

Post a reply to this message

On Wed, 21 Apr 1999 01:05:07 +0200, Spider <spi### [at] bahnhofse> wrote:
>Do it in dos and amiga, and make a plugin cross compilant. (no or little source
>changes.)

Amiga has shared libraries, too.  They've had 'em since the beginning, or 
at least since OS 1.2.

Post a reply to this message

Alessandro Coppo wrote:

> I think a sanctioned, Leveller-like plug-in architecture would be great.
> Instead of having to mix and much unofficial patches, you would just have to
> register a plug-in and call it in a standardized way from POv-Ray scripts.
> By the way, I have started playing with Linux (besides Win32) and I saw that
> also in Linux you have DLLs (even if they are called differently). So,
> Windows has DLLs, Linux has DLLs, I presume that other UNIX flavours have
> something like DLLs, Macs have the equivalent, VMS has shared libraries....
> I think every target of POV-Ray has the system support for DLLs, so PLEASE:
> dynamically loaded plug-ins!!!!
>
>

You know that a shared lib is slower than statically linked code. well now you
do :)
Also it can be quite hard to support this in a generic way.  But I could be
done I think if the build system is converted to gnu autoconf/libtool. Libtool
take care of all the hairy things involving dll's

Post a reply to this message