POV-Ray : Newsgroups : povray.programming : POV-Ray C++? Server Time
28 Mar 2024 12:36:45 EDT (-0400)
  POV-Ray C++? (Message 4 to 13 of 13)  
<<< Previous 3 Messages Goto Initial 10 Messages
From: Le Forgeron
Subject: Re: POV-Ray C++?
Date: 2 Jan 2012 12:39:35
Message: <4f01ebd7$1@news.povray.org>
Le 02/01/2012 15:48, Warp nous fit lire :
> 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?
> 
>   (This is not an objection to your claim. I'm just being lazy and don't want
> to wade through the code to see examples, so I'm hoping you could provide
> some.)
> 

I would suggest the pattern structure (so far a fat struct+union):
Pattern_Struct in frame.h (source/backend)

In fact, the evaluation of each pattern goes through  a switch statement
(for each ray, i.e. pixels and sub...), which might be faster (well,
it's only a kind of jump, so maybe not) with a virtual member from an
abstract pattern class, whose actual instance could provides directly.

On the opposite direction, making pattern an abstract class would means
the basic footprint of each instance might be a bit larger (due to the
storage of virtual members in situ).


Post a reply to this message

From: Thorsten Froehlich
Subject: Re: POV-Ray C++?
Date: 2 Jan 2012 12:55:32
Message: <4f01ef94@news.povray.org>
On 02.01.12 15:12, MiB wrote:
> Looking at the POV-Ray 3.7 sources I noticed that it extensively uses the
> object-oriented C++ standard library (e.g. std::string, std::vector, ...).

Yes, all new code uses it. And I have some work done to at least get rid of 
C memory management that isn't in 3.7.0 RC.

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

It isn't object-oriented in the C++ way, that is true. It is contemporary C 
though.

> I assume this is due to the C language heritage handed down from the olden DKB
> Trace days.

Yes.

> Are there any plans or maybe even actual activity to redesign/refactor POV-Ray
> into a class based design? I am aware, this is no trivial work, and there may be
> reasons why a class redesign my be shunned here (worries about compatibility,
> performance, to mention a few). I am asking to reconsider these worries, if any.

No, the reason is simple: To get 3.7 started required a lot of work - about 
10 person-month full time over about 4 month, plus some additional work. 
This was kindly supported by AMD, and made possible because Chris Cason had 
no other major contract work at the time, and I as the other developer had a 
whole semester worth of spare time before starting my actual PhD work. When 
Christoph Lipka did the radiosity rework, he also had the time to do it.

Without this block of time and at least two people full-time (to pick up the 
slack its essential!), development doesn't go that fast. Add to that the 
years of time Chris and I had to spend on a legal battle for POV-Ray (which 
has the nice side effect that we have all the author rights sorted now), 
development suffered.

And last but not least, Chris is busy with contracts, and I have a full-time 
job, too. As do all the other POV developers.

> There is a very noticeable tendency of C++ compilers converging to a common
> standard, especially in regard to the new C++11 standard. Before, even popular
> compilers (say, VC++6) felt like implementing different languages. Now its
> different.

That is no concern.

> I am convinced, the POV-Ray development would profit a lot by introducing a
> class based design, maybe it would also be a good idea to start with an UML
> architectural model before attempting any code changes in this direction. A
> fresh wind in POV-Ray development may result. Correct me if I am wrong, but
> POV-Ray seems to be stagnant for years already.

Quite a bit goes on beyond 3.7, and it isn't so much a problem do come up 
with a proper design. But a design is worthless if it cannot be implemented 
straight out. To do this part-time is next to not feasible. If there was 
some funding for two or three of the current core developers for just tree 
to four months, we would be up and running within that time. Plus a 
lead-time of half a year to have the time on hand, of course.

	Thorsten


Post a reply to this message

From: Warp
Subject: Re: POV-Ray C++?
Date: 2 Jan 2012 14:26:35
Message: <4f0204eb@news.povray.org>
Le_Forgeron <jgr### [at] freefr> wrote:
> On the opposite direction, making pattern an abstract class would means
> the basic footprint of each instance might be a bit larger (due to the
> storage of virtual members in situ).

  A class having virtual functions only increases by one pointer
(overall, not per function).

-- 
                                                          - Warp


Post a reply to this message

From: Christian Froeschlin
Subject: Re: POV-Ray C++?
Date: 3 Jan 2012 15:13:40
Message: <4f036174$1@news.povray.org>
Thorsten Froehlich wrote:

> If there was some funding for two or three of the current core 
> developers for just tree to four months, we would be up and running 
> within that time.

I remember Chris Cason posting once about a policy of not
accepting cash donations (and checking now I couldn't find
any obvious way to donate). I think a lot of people here would
contribute if possible. Probably not enough to finance an entire
man year but if you are actually interested in funding the
policy seems counter-productive.


Post a reply to this message

From: Thorsten Froehlich
Subject: Re: POV-Ray C++?
Date: 3 Jan 2012 15:20:09
Message: <4f0362f9@news.povray.org>
On 03.01.12 21:13, Christian Froeschlin wrote:
> Thorsten Froehlich wrote:
>
>> If there was some funding for two or three of the current core developers
>> for just tree to four months, we would be up and running within that time.
>
> I remember Chris Cason posting once about a policy of not
> accepting cash donations (and checking now I couldn't find
> any obvious way to donate). I think a lot of people here would
> contribute if possible. Probably not enough to finance an entire
> man year but if you are actually interested in funding the
> policy seems counter-productive.

There is a difference with small donations compared to some organization 
funding a specific goal. The former requires management of money and the 
leftovers, the later is simply a contract of that organization (usually with 
an interest in POV-Ray, i.e. for marketing) with specific developers for a 
specific result. That is for example how POV-Ray got into SPEC, and how the 
SMP branch came about.

     Thorsten


Post a reply to this message

From: MiB
Subject: Re: POV-Ray C++?
Date: 4 Jan 2012 18:40:01
Message: <web.4f04e2bcc9ae25fcb154c30@news.povray.org>
Le_Forgeron <lef### [at] freefr> wrote:
[..]
> IMHO, main issue for 3.7 was licensing and parallel rendering on SMP. I
> heard there is plan for a rewrite as 4.0, once 3.7 is out.

Then maybe volunteering work for 4.0 is the wiser course of action rather than
spawn a separate project.

[..]
> A long time ago, I tried to push the SDL into a more conformant UML
> approach. If you like fancy uml diagrams in French, have a look at
> http://jgrimbert.free.fr/crayon.pdf

My French language abilities are close to non-existent, but I had a look at your
document anyway. To my surprise, reading French is so much easier than follow
spoken text that I can actually comprehend your writings. You give some English
translations in selected places, that also helps, plus UML is a language I can
"read". The pointers you added in you posting will also contribute to guiding
me.
Its still a slow process, I have to look up vocabulary in a dictionary but this
seems effort well spent - your text makes a good read, thank you for sharing.

[..]
> I'm a bit radical on that: no backward compatibility.
> (which is bad, as I enjoyed too being able to run old scene in modern
> process)

I tend to think of software design in layers, where a model in one layer is
rather loosely coupled to its neighbors. I understand, the CSG language used for
describing a scene in POV-Ray pretty directly maps to data structures and
functions in the render engine.
It should be possible though, to decouple the two layers language and renderer,
just like in the Model-View-Controller design pattern, where presentation of
data in a GUI, in the corresponding business logic and in backing storage is
expected to be independent and different.
Maybe its a good idea to give this some thought - backward compatibility is a
valuable asset (consider the huge library of existing scenery code!), I am
hesitant to sacrifice it on the altar of a new design.

[..]
> If you can fix the issue #217 (using +C to continue an animation-render
> with some existing frames already done), I would be delighted. I have no
> clue why it fails. (seems like a cache of something... I just get lost)

I'll try to set up a working development environment for POV-Ray and have a look
at it this weekend.

kind regards,

   MiB.


Post a reply to this message

From: MiB
Subject: Re: POV-Ray C++?
Date: 4 Jan 2012 19:40:01
Message: <web.4f04f005c9ae25fcb154c30@news.povray.org>
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.

To focus on a single example, the function
void Translate_Object( ObjectPtr Object, const VECTOR Vector, const TRANSFORM
*Trans )
looks like a good candidate for a member function of Object - it is already set
up like one, the first parameter "Object" would become implicit as "this".
I'd prefer to set up a base class Object like this

class Object {
/* ... */
public:
   virtual void Translate( const VECTOR& Vector, const TRANSFORM* Trans );
}

Derived classes of Object may override the method to take care of their
specifics.

The flag system could be completely replaced by a class hierarchy, where each
type of object implements its own version of functionality that now needs to be
singled out by "if" or "switch" constructs.

I wrote programs in this style, too, until around 1992 :-) ... in a funny kind
of revelation I "invented" object orientation for C (using function pointers as
struct members). When I proudly presented this "novel" approach to a friend, I
was devastated to learn that this idea was a normal feature of OO languages for
years already. C++ became a friend after that.

>   (This is not an objection to your claim. I'm just being lazy and don't want
> to wade through the code to see examples, so I'm hoping you could provide
> some.)

Actually, I need to relativise my statement somewhat. A lot of POV-Ray code
already is organized in classes, I just happened to stumble upon older code
parts first.

 kind regards,

   MiB.


Post a reply to this message

From: MiB
Subject: Re: POV-Ray C++?
Date: 4 Jan 2012 19:45:01
Message: <web.4f04f1d8c9ae25fcb154c30@news.povray.org>
Thank you a lot for the clarification.

kind regards,

   MiB.


Post a reply to this message

From: clipka
Subject: Re: POV-Ray C++?
Date: 13 Jan 2012 19:11:31
Message: <4f10c833@news.povray.org>
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

From: David Buck
Subject: Re: POV-Ray C++?
Date: 12 Feb 2012 11:50:47
Message: <4f37ede7$1@news.povray.org>
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

<<< Previous 3 Messages Goto Initial 10 Messages

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