Wolfgang Wieser wrote:
> [...]
> 
> But about things like my "radial slope pattern" (rather small and simple) 
> or the "progressive refinement patch" (which would require somebody else 
> write the windows/mac - related part). 

The PRT patch is on the 'considered' list of MegaPOV for some time now 
but without support on the other platforms it won't be included.  You 
say 'somebody else' should write that but that's not the way it is 
likely to work.

I only had a quick look at the implementation but the design is somewhat 
problematic - you implement a lot of stuff in a new C++ class but this 
no way forms a well defined unit inside POV.  Implementing a new render 
method in a C++ class does not make POV-Ray a C++ program and it will be 
quite painful to apply other changes to this part afterwards. Not to 
mention that text output via fprintf(stderr, ...) is not the right way.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 11 Jan. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

Patrick Elliott wrote:

> a height field, c) some other thing... You might have better luck
> convincing people 
>
I do NOT want to convince anybody. 
I just had that idea and implemented it (in a dirty way) for me 
because I need it. 
Just in the unlikely event that several people were saying 
"Ah, I've been looking for that already", I would have considered 
making a real patch from it and ask for inclusion. 

> that filling the image, instead of simply clipping is
> better, if we had an example of what you are doing with it. ;)
> 
http://www.cip.physik.uni-muenchen.de/~wwieser/render/img/mars/#landingspirit

BTW, I have to thank Christoph for the idea to make the angle of the 
light sooo flat. (And my atmosphere is basically the earth rendering 
atmosphere with red and blue components exchanged and absorption 
removed ;)

Wolfgang

Post a reply to this message

Christoph Hormann wrote:

> Wolfgang Wieser wrote:
>> [...]
>> 
>> But about things like my "radial slope pattern" (rather small and simple)
>> or the "progressive refinement patch" (which would require somebody else
>> write the windows/mac - related part).
> 
> The PRT patch is on the 'considered' list of MegaPOV for some time now
> but without support on the other platforms it won't be included.  You
> say 'somebody else' should write that but that's not the way it is
> likely to work.
> 
Well, I simply have no access to mac here - and no windows (compiler) 
around. So in case we really want to consider putting it into megapov, 
I/we need to ask for somebody willing to do that. 

> I only had a quick look at the implementation but the design is somewhat
> problematic - you implement a lot of stuff in a new C++ class but this
> no way forms a well defined unit inside POV.  Implementing a new render
> method in a C++ class does not make POV-Ray a C++ program and it will be
> quite painful to apply other changes to this part afterwards. 
>
Hmm... What would you suggest should be done differently? 
I put the code into the class in order to surely avoid naming collisions 
and to make it easy to see what belongs to the PRT patch. 

And about POV and C++, I'm a bit puzzled when reading the rest of the 
code, especially the image IO. It seemed to me that decision was taken 
to C++ify the C code for 3.5 and above ending up in a lot of C in cpp 
files with a little bit of C++. I'm not having a very good feeling when 
it comes to that. 

> Not to
> mention that text output via fprintf(stderr, ...) is not the right way.
> 
Yes, correct. There are some things which need to be cleaned up for 
actual inclusion. The fprintf's are basically debug messages which I 
found to be useful so I did not remove them. 

Wolfgang

Post a reply to this message

In article <4012cd76@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>  
wrote:

> The most basic idea against what I called "hindering" is to
> make available devel code (or at least beta versions) to those who
> want to "work".

And promtly distribute binary versions without a timeout in them. No!

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <4012cd76@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>  
wrote:

> It's just that I learned to never fix bugs in old versions. I tracked
> down other bugs for other projects and the correct behaviour always was
> use the current development code and not a one-year-old code base.

Well, let us worry about integrating bug fixes.  Really!

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Wolfgang Wieser wrote:
> [...]
> 
> Hmm... What would you suggest should be done differently? 

I'd suggest to implement it like the other render techniques are 
implemented (Start_Adaptive_Tracing() and Start_Non_Adaptive_Tracing()). 


And if you want to have a chance that someone else implements the 
frontend for the other platforms you seriously need a documentation of 
the interface between the core code and the platform specific part.  It 
might be a good idea to completely leave out the interactive part so you 
just need POV_DISPLAY_UPDATE_RECT and nothing more.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 11 Jan. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

In article <4012dca5@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>  
wrote:

> And about POV and C++, I'm a bit puzzled when reading the rest of the
> code, especially the image IO. It seemed to me that decision was taken
> to C++ify the C code for 3.5 and above ending up in a lot of C in cpp
> files with a little bit of C++. I'm not having a very good feeling when
> it comes to that.

Why?  C++ is just a superset of C (well, with a few very minor exceptions).
So features that are in a need for a rewrite get rewritten using some C++
features.  However, that does not imply there should be a wild mix of
designs.  If a particular section of code uses a C++ features (in particular
is put in a class), then every similar module should also do so.  So, just
don't create a mess.  Either go all the way or don't go it at all.  To only
do something because it seems convenient without any direct benefit isn't
the idea behind the code structure and allowing the use of C++ features.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich wrote:
> And promtly distribute binary versions without a timeout in them. No!
> 
??!

Wolfgang

Post a reply to this message

In article <4012cd76@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>  
wrote:

>> Why?  The policy to not make development source code accessible has a good
>> reason, because it simply did not work in the past.  Considering that back
>> in that "past" far fewer users with a lot more technical clue has access
>> to online resources, the internet of today does only make matters worse.
>>
> The proper reaction IMO is to find those people which do have a clue.

You really think we have the time to manage read access rights for many
developers?  It is really hard to tell somebody who just wants to lurk at
the code to someone who is going to contribute something.  So the
alternative would be to make the source code readable for everybody, which
in turn would result in people make distributions based on that code, which
is something they absolutely should not make.

>> And periodically looking at various "open source" development projects
<snip>
> [I am skipping this paragraph in an attempt to not feed the trolls.]

Take a look at the Debian povray package.  How they fixed the code to
compile on 64 bit platforms says a whole lot about the quality of their
"fix".  Especially as a correct solution had been available on this server
for a very long time before they "fixed" it.

>> My personal opinion is that no future patches' source code from MegaPOV
>> should be added to an official POV-Ray at all.  This is from the very bad
>> experience with patch quality that caused massive problems getting a
>> timely release of POV-Ray 3.5, and even in 3.6 not all of the flaws in
>> some patches have been corrected.
>>
> I do not completely understand that. In order to advanve/innovate one
> needs to add code to existing code, hence "patch" it. If you do not
> patch code, you stop development.

If the next release, which will be 4.0 and is a rewrite, what point would
there be in adding new minor patches to the official 3.x code base?

> So what is the alternative?
> Direct implementation by a POV team member (with inspiration from
> the patch code)?
>
> In this case we definitely need megapov as a patch playground because
> the above tends to take quite long...

Indeed, it takes so long because quality software development takes long.
That way we don't need to release hot fixes every other day like many other
companies and projects do.  And users don't have to hunt down the latest and
greatest version every other day either.

> Maybe we are using slightly differrent meanings for "patch".

Nope.

> This is clear (although I think that "just converting" the parametric
> object will not be that easy...)

As I said, "most" objects.  And the parametric object is one with the most
bugs still in it.

> As you are talking about version 4.0, I think it should not only be
> a re-write but a re-design

That is obvious!

>> And you can be sure the community as well as the POV-Team will
>> greatly appreciate bug fix contributions.
>>
> (And any bug fix writer will appeciate access to up-to-date source code...)

Why?  It is much easier to track down a bug if the source code does not
change while you are tracking it down, so it is irrelevant if you have the
most recent source code and can't update it or you have the release source
code of the last official version and can't update it until you have found
the bug.

>> I strongly disagree.  All "those people who want to work" usually do only
>> want to add features.  They have no desire to go through the very time
>> consuming, boring and frequently frustrating process of fixing bugs.  So,
>> when pushing for a quick including of a patch into the official POV-Ray,
>> these people also want to leave at least some of the work of fixing the
>> bugs to the POV-Team.
>>
> (1) One does not need to integrate patches quickly into povray.
>     But one could at least make it easier for people to write their
>     patches.

It is very easy to write patches that add new objects and patterns.  You
don't need any non-final source code to do that.  As far as other features
are concerned, those should really not be added unless they add something
truly useful to most users, the code outside objects and textures has enough
problems already.

> If one threatens to de-integrate the patch, there will probably be
> somebody who finds it useful and takes over the responsivbility.
> If tere is not, there seems to be no interest at all and one can live
> without that functionality.
> I don't think this is the best solution but a fallback...

You miss an important point: Also no developer is interested in a particular
patch does not say anything about no user being interested in a patch.  You
make the typical mistake all these "open source" proponents do, in assuming
that everybody who uses a program is also able to fix it.  That is of course
nonsense.  Even the average advanced user of POV-Ray does not know
programming...

> It's just that I learned to never fix bugs in old versions. I tracked
> down other bugs for other projects and the correct behaviour always was
> use the current development code and not a one-year-old code base.

I think you are mistaken.  The correct behavior always is to use the version
they make available.  In many of those projects individual developers in
turn keep large changes private and only contribute them when they are
"ready".  Thus, it just moves the problem around, but does not help to solve
it.


    Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Christoph Hormann wrote:

> Wolfgang Wieser wrote:
>> [...]
>> 
>> Hmm... What would you suggest should be done differently?
> 
> I'd suggest to implement it like the other render techniques are
> implemented (Start_Adaptive_Tracing() and Start_Non_Adaptive_Tracing()).
> 
I wrote a class PRTImageData holding the image for PRT. 

Then there is PRTTileHeap which implements a heap of rectangular 
tiles to be rendered. 

I consider the introduction of these two classes as good design. 

And then there is PRTRenderer. It may be better design to get rid 
of this class especially because I am unhappy with the static 
self-reference to the one existing instance. This would, most likely 
require a further global variable (pointer). 

If you think that I should re-implement PRTRenderer's functionality 
using plain C and use PRTImageData and PRTTileHeap for their 
purposes, I will very likely consider doing that. 

> And if you want to have a chance that someone else implements the
> frontend for the other platforms you seriously need a documentation of
> the interface between the core code and the platform specific part.  It
> might be a good idea to completely leave out the interactive part so you
> just need POV_DISPLAY_UPDATE_RECT and nothing more.
> 
I will not get rid of the interactive part because that is the more 
useful part for me. If you think that non-interactive PRT should be 
included into megapov, removing that functionality for doing so would 
be easy. 

Wolfgang

Post a reply to this message