 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi,
Although a long-term user of POV-ray, I am new to community activity here, so
please forgive me if this has been discussed before.
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, ...).
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.
I assume this is due to the C language heritage handed down from the olden DKB
Trace days.
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.
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.
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.
I am ready to volunteer time for this but would like to draw on your opinions
first. Tell me, why my plan is a bad idea or where I can contribute to already
ongoing activity I just failed to see.
best,
MiB
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 02/01/2012 15:12, MiB a écrit :
> Hi,
Hi, Just some personal opinions & hints.
> 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.
>
> I assume this is due to the C language heritage handed down from the olden DKB
> Trace days.
>
> Are there any plans or maybe even actual activity to redesign/refactor POV-Ray
> into a class based design?
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.
> 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.
>
>
> 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 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
Fig 1.1 was for povray, and removing some containers (like texture; at
least at the storage level for the scene, if not from the SDL), you
could end up with something along Fig 1.4 on page 21.
Classes are described in Fig 4.1 on page 38. Even deeper model in 4.2 &
4.3 are currently missing some solution for pattern which need access to
the object they might be applied to.
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)
> 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.
>
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)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le_Forgeron <jgr### [at] free fr> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
