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