Thank you a lot for the clarification.

kind regards,

   MiB.

Post a reply to this message

Am 05.01.2012 01:34, schrieb MiB:

> Pretty much the first file I touched was
> povwin-src-3.7-RC3\source\backend\scene\objects.h
>
> Here, object types and properties are defined by flag values, operations on
> flags are preprocessor macros, operations on objects (including
> copy-construction and destructors!) are global functions instead of members of
> the Object class.

Yup. The core code to handle geometric primitives, patterns, textures 
and such didn't need any significant changes to run on multiprocessor 
systems (with the crackle pattern being the only notable exception I'm 
currently aware of), so it just hasn't been "objectified" - yet.

I'm pretty itchy to work on those parts, too, but of course it won't 
happen in 3.7.

Post a reply to this message

MiB wrote:
> Warp <war### [at] tagpovrayorg> wrote:
>> MiB <nomail@nomail> wrote:
>>> However, a quick survey reveals POV-Ray itself is not written in a contemporary
>>> object-oriented style; a lot of pointers to structs are handed around, functions
>>> manipulating data structures are on a global level and not members of classes.
>>   Could you give some clarifying examples of this, as well as a suggestion
>> of how it should be done better?
> 
> Pretty much the first file I touched was
> povwin-src-3.7-RC3\source\backend\scene\objects.h
> 
> Here, object types and properties are defined by flag values, operations on
> flags are preprocessor macros, operations on objects (including
> copy-construction and destructors!) are global functions instead of members of
> the Object class.

When I wrote DKBTrace originally, I had already been doing Smalltalk 
programming for a few years and was quite familiar with object oriented 
concepts.  Smalltalk obviously wasn't a good candidate language for 
implementing DKBTrace (sadly) and C was the only real alternative.

As such, you'll find that parts of the code do have an object oriented 
spin to them.  Take cones, for example.  In cones.cpp you'll find:

METHODS Cone_Methods =
{
   All_Cone_Intersections,
   Inside_Cone, Cone_Normal, Default_UVCoord,
   (COPY_METHOD)Copy_Cone, Translate_Cone, Rotate_Cone, Scale_Cone, 
Transform_Cone,
   Invert_Cone, Destroy_Cone
};

This is a virtual table of functions that allows call points to 
polymorphically call methods on objects without knowing the types of the 
objects.

This approach is difficult to maintain and wasn't used for other parts 
of the rendering system like vectors and textures.

Re-writing POVRay in C++ would probably be a good idea but obviously a 
lot of work. I would suggest staying away from some of the more 
difficult C++ concepts like multiple inheritance and operator 
overloading if you can.  I would agree to operator overloading for 
vectors and matrices since they make the syntax much nicer.  I'm not a 
fan of templates, but that's just my opinion.

David Buck

Post a reply to this message