While working on a partial image reading patch, I came accross the 
following bug in POVRay: 

In jpeg_pov.cpp, around line 405, the code reads: 

-------------------<jpeg_pov.cpp:405>---------------------------------
        bufptr->row_stride = w * 3;

        bufptr->row_pointer[0] = (JSAMPROW)POV_MALLOC(
                bufptr->row_stride * w, "JPEG line buffer");
----------------------------------------------------------------------

And some lines below: 

-------------------<jpeg_pov.cpp:636>---------------------------------
        /* JSAMPLEs per row in output buffer */
        bufptr.row_stride = 
                bufptr.cinfo.output_width * bufptr.cinfo.output_components;
        /* Make a one-row-high sample array */
        bufptr.row_pointer[0] = (JSAMPROW)POV_MALLOC(
                bufptr.row_stride * width, "JPEG line buffer");
----------------------------------------------------------------------

Both chunks of code contain the same stupid bug which causes excessive 
memory consumption: 

row_stride is the amount of memory in bytes needed for one ROW in the 
image. What is being done here is allocating this amount of memory for 
EVERY ROW in the image. 

This means that for bpp bytes per pixel, we end up allocating 
   width*width*bpp bytes 
where only 
   width*bpp bytes
are needed! [In my case that meant 768Mb instead of 50kb.]

Please apply the following patch: 

-------------------<jpeg_pov.cpp:405>---------------------------------
        bufptr->row_stride = w * 3;

        bufptr->row_pointer[0] = (JSAMPROW)POV_MALLOC(
                bufptr->row_stride, "JPEG line buffer");
----------------------------------------------------------------------

-------------------<jpeg_pov.cpp:636>---------------------------------
        /* JSAMPLEs per row in output buffer */
        bufptr.row_stride = 
                bufptr.cinfo.output_width * bufptr.cinfo.output_components;
        /* Make a one-row-high sample array */
        bufptr.row_pointer[0] = (JSAMPROW)POV_MALLOC(
                bufptr.row_stride, "JPEG line buffer");
----------------------------------------------------------------------

This modification (effectively removing the with multiplication in the 
memory allocation size calculation) has been verified to work correctly 
by me. Note that row_pointer[0] is always only meant to contain one 
single image row, never more. 

Regards,
Wolfgang

I hope I can have a look at POVRay's next beta version (linux source 
code) real soon.

Post a reply to this message

Wolfgang Wieser wrote:
> While working on a partial image reading patch, I came accross the 
> following bug in POVRay: 

You'd probably save some time if you wait until 3.6 is out because 
otherwise you would need to rewrite the code (image reading/writing has 
not changed much but some changes require modifications at a lot of 
places in the code).

> In jpeg_pov.cpp, around line 405, the code reads: 
> 
> [...]

Sounds logical to me although i have no experience with libjpeg.

Just in case this is not clear to everyone - this is not a memory leak, 
it is just POV-Ray temporarily allocates more memory than it needs.

> 
> I hope I can have a look at POVRay's next beta version (linux source 
> code) real soon. 

As usual source will not be available during beta.

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

Christoph Hormann wrote:

> Wolfgang Wieser wrote:
>> While working on a partial image reading patch, I came accross the
>> following bug in POVRay:
> 
> You'd probably save some time if you wait until 3.6 is out because
> otherwise you would need to rewrite the code (image reading/writing has
> not changed much but some changes require modifications at a lot of
> places in the code).
> 
Well, I really see your point but I am actually very tired of _waiting_. 
If anybody out there is waiting for the POVRay team to do just the smallest 
thing, he'd better invest in finding the fountain of youth ;)

BTW, what about including this patch into POVRay-3.6? 
Basically, the patch allows you to select a rectangular region of 
an image_map so that only this part is read in and stored in RAM. 
Pixels outside this region are all considered 50% gray (some other 
solution like quick_color could also be thought of). 

Of course, inclusion only makes sense if there are more people 
interested in it. I am currently using it to render MARS images, 
because I cannot fit all the 2.4 Gb topo & color into RAM. 

> Just in case this is not clear to everyone - this is not a memory leak,
> it is just POV-Ray temporarily allocates more memory than it needs.
> 
Correct. 

>> I hope I can have a look at POVRay's next beta version (linux source
>> code) real soon.
> 
> As usual source will not be available during beta.
> 
It may or may not make sense to publish source code of beta versions. 
But as I am sombody who actually works with the code, has already found 
several bugs, suggested fixes for most of them and is actively writing 
patches for POVRay, it may make sense to let me join the group of people 
who may view the current development code. 

Regards,
Wolfgang

Post a reply to this message

Wolfgang Wieser wrote:
> 
> Well, I really see your point but I am actually very tired of _waiting_. 
> If anybody out there is waiting for the POVRay team to do just the smallest 
> thing, he'd better invest in finding the fountain of youth ;)

Well i only suggested you might *save* time by waiting.

> BTW, what about including this patch into POVRay-3.6? 

As Chris Cason has mentioned in the status report 3.6 does not introduce 
significant new features in the core functionality.

> Basically, the patch allows you to select a rectangular region of 
> an image_map so that only this part is read in and stored in RAM. 
> Pixels outside this region are all considered 50% gray (some other 
> solution like quick_color could also be thought of). 

I don't think this would be a very useful patch - selecting and copying 
a rectangle from a larger image is the task for an external program, 
what would be really useful would be a patch that adaptively loads those 
parts on an image into memory that are actually used - without the need 
to specify a rectangle and that also unloads those parts that are no 
more needed during render progress to free space for new parts.  Of 
course such a feature would not only be useful for images but also for 
meshes for example.  AFAIK some other raytracing programs also have such 
a feature.

> It may or may not make sense to publish source code of beta versions. 
> But as I am sombody who actually works with the code, has already found 
> several bugs, suggested fixes for most of them and is actively writing 
> patches for POVRay, it may make sense to let me join the group of people 
> who may view the current development code. 

This is of course no way my decision but to be frank - it does not seem 
to me that you propose to be allowed source access primarily to fix 
bugs, this is perfectly possible with the 3.5 code and some of your 
proposals have already been included in 3.6 (and the last two probably 
will be as well).

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 <401291b0@news.povray.org>, Wolfgang Wieser <wwi### [at] gmxde> 
wrote:

> BTW, what about including this patch into POVRay-3.6? 

It's too late for that. Public betas are already starting, the only 
things that will go into POV from now until the 3.6 final release are 
bug fixes. The over-allocation fix might get in, but no new features or 
major changes.


> Basically, the patch allows you to select a rectangular region of 
> an image_map so that only this part is read in and stored in RAM. 
> Pixels outside this region are all considered 50% gray (some other 
> solution like quick_color could also be thought of). 

Pixels outside that region should probably be fully transparent, to be 
consistent with the "once" option. And why not read in the region as the 
entire image, filling the entire area of the image_map? Simpler, and 
avoids the above problem completely.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

Christoph Hormann wrote:

> As Chris Cason has mentioned in the status report 3.6 does not introduce
> significant new features in the core functionality.
> 
...which is perfectly acceptable (to me). 

> I don't think this would be a very useful patch - selecting and copying
> a rectangle from a larger image is the task for an external program,
>
Yes, but there are two reasons for my approach: 
(1) Opening a 1Gb file in an external program, selecting some part, 
    saving it... all that for every view port is too much work for me. 
(2) The cut-down chunk needs extra calculations to make sure the 
    image map projection is exactly correct. 
My patch saves me from both these. 

Still it is probably a very special thingy and of little use for 
most people. 

> what would be really useful would be a patch that adaptively loads those
> parts on an image into memory that are actually used - without the need
> to specify a rectangle and that also unloads those parts that are no
> more needed during render progress to free space for new parts.  Of
> course such a feature would not only be useful for images but also for
> meshes for example.  AFAIK some other raytracing programs also have such
> a feature.
> 
I actually had the plan to implement something like that for meshes 
before I came accross the possibility using the isosurface for the topo. 

In-memory (de)compression of the data was another approach I thought of. 

> This is of course no way my decision but to be frank - it does not seem
> to me that you propose to be allowed source access primarily to fix
> bugs, this is perfectly possible with the 3.5 code and some of your
> proposals have already been included in 3.6 (and the last two probably
> will be as well).
> 
But...
> Well i only suggested you might *save* time by waiting.

I was told the same argument some time ago. It read like "we did a 
complete rewrite of unix.cpp but you can do everything with the old 
version so feel free to send us patches for the old code". 

I could consider that as an expression of no interest in what other 
people are doing. It's a bit like preaching water and drinking wine. 

Don't you think that this effectively hinders futher development?
It makes me waste time writing patches for old code which have to 
be converted to the new code. It makes the POVRay team waste time 
getting patches based on one-year old code base. And finally, most 
of the bugs I see come from looking at the source, not from using 
a binary. 

Don't understand me wrong: I respect any decision the POVRay team 
makes. 

But I see a further possibility using the following roadmap:
(1) get povray 3.6 out
(2) bring out long awaited new megapov based on 3.6
(3) more frequent megapov updates

In this case I'd be more happy to see current megapov development 
and to be able to write patches for (or even contribute to) megapov 
[than to mainline povray] anyways. 

To me (as looking at it from outside) it seems like there would be 
enough ideas, code and manpower around here for quite some innovation 
but there is somebody somewhere out there actively pulling the break. 

I learned that in most cases it turns out negatively to hinder those 
people who want to work (and have the ability to do it well) from 
doing their work. 

Wolfgang

Post a reply to this message

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

> Well, I really see your point but I am actually very tired of _waiting_.

Well, then  start your own ray-tracer project.  Oh, well, wait, every single
one ever started has died about as quickly.  Quality software development
takes time, otherwise you would end up with bloated junk and broken 1.0
designs!  For example Mozilla is a great example for a design broken from
the beginning...

    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 <401291b0@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>  
wrote:

> BTW, what about including this patch into POVRay-3.6?

This ain't a patch, this is a trivial bug fix!

    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

Christopher James Huff wrote:

>> Basically, the patch allows you to select a rectangular region of
>> an image_map so that only this part is read in and stored in RAM.
>> Pixels outside this region are all considered 50% gray (some other
>> solution like quick_color could also be thought of).
> 
> Pixels outside that region should probably be fully transparent, to be
> consistent with the "once" option. 
>
I would prefer the pixels to be of configurable color...

> And why not read in the region as the
> entire image, filling the entire area of the image_map? Simpler, and
> avoids the above problem completely.
> 
I do not completely understand what you plan there but it seems to me 
that this requires the used to do additional scaling and 
rotation/translation of the texture (which may not be trivial for 
some projections). 
Furthermore, for my current personal use, the 50% gray is a "feature" 
(sea level on Mars). 

Wolfgang

Post a reply to this message

Thorsten Froehlich wrote:
>> BTW, what about including this patch into POVRay-3.6?
> 
> This ain't a patch, this is a trivial bug fix!
> 
I was talking about the partial image reading. 

Wolfgang

Post a reply to this message

Wolfgang Wieser wrote:
> 
> Yes, but there are two reasons for my approach: 
> (1) Opening a 1Gb file in an external program, selecting some part, 
>     saving it... all that for every view port is too much work for me. 
> (2) The cut-down chunk needs extra calculations to make sure the 
>     image map projection is exactly correct. 
> My patch saves me from both these. 
> [...]

I don't understand (2) and (1) of course is no more an issue with an 
external program than it is with a POV-Ray patch.

> I was told the same argument some time ago. It read like "we did a 
> complete rewrite of unix.cpp but you can do everything with the old 
> version so feel free to send us patches for the old code". 

No, please reread the past postings in this concern.  The proposal to 
work on the unix specific part of the 3.5 code did only involve the X11 
display code.  This is exactly as it is in 3.5 and the changes you made 
there could be merged with the 3.6 code without any trouble.

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

Thorsten Froehlich wrote:
> Well, then  start your own ray-tracer project.  Oh, well, wait, every
> single
> one ever started has died about as quickly.  Quality software development
> takes time, otherwise you would end up with bloated junk and broken 1.0
> designs!  For example Mozilla is a great example for a design broken from
> the beginning...
> 
Thorsten, PLEASE!

I actually bet my evening dinner on you writing just that. 

Please reduce a tiny bit your expression of the "POV-code-is-the-best-
code-in-the-world-and-all-other-programs-are-full-of-bugs-or-trivial"
theoreme. 

From those bugs I have found myself in POV code, the code is not as 
high-quality as you consider it to be. I am really sorry to say that 
but sometimes it is healthy to face truth. 

[BTW, I do not remember my mozilla ever crashing. But I remember 
POVRay 3.5c (official) crashing. But I am using mozilla only when 
konqi does not get along with a page...]

But stop. I do NOT want to start a discussion here about mozilla, the 
linux kernel, XFree86, the different development models around etc. 

Especially, I would ask you not to answer here, that if we would put 
POVRay code in a public CVS and let all the world contribute, then the 
code will be fubar within very short time. 

This is correct. 

And this has already been discussed long enough. 

Regards,
Wolfgang

Post a reply to this message

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

> I was told the same argument some time ago. It read like "we did a
> complete rewrite of unix.cpp but you can do everything with the old
> version so feel free to send us patches for the old code".
>
> I could consider that as an expression of no interest in what other
> people are doing. It's a bit like preaching water and drinking wine.

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.

> Don't you think that this effectively hinders futher development?
> It makes me waste time writing patches for old code which have to
> be converted to the new code. It makes the POVRay team waste time
> getting patches based on one-year old code base. And finally, most
> of the bugs I see come from looking at the source, not from using
> a binary.

But you have access to the source code.  Use it.  Honestly I have to say
several of the contributed bug fixes we so far got for 3.5 cannot (well,
should not) be used as is in the source code.  While many bug fixes
correctly identify the problem, they frequently tend to be more of a "hack"
than a solution.

And periodically looking at various "open source" development projects makes
me worry a lot about even considering using that software.  Despite its age,
the POV-Ray source code is in a very good shape compared to many much
younger "open source" projects whose individual modules are rewritten every
three or four years...

> But I see a further possibility using the following roadmap:
> (1) get povray 3.6 out
> (2) bring out long awaited new megapov based on 3.6
> (3) more frequent megapov updates

The reason for there being no MegaPOV updates is that early on in the 3.5.1
development the MegaPOV sources were tried to that version and its release.
Due to purely administrative (and not going to be discussed in public), not
developmental reasons, the release of 3.5.1 had to be delayed far beyond our
expectations.  That is why there is POV-Ray 3.6 now, because we did not
simply stop development while having to deal with administrative issues.

> In this case I'd be more happy to see current megapov development
> and to be able to write patches for (or even contribute to) megapov
> [than to mainline povray] anyways.

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.

Apart from that, with 4.0 being a rewrite, producing patches, especially
some that just add minor individual tweaks (usually by parser or
preprocessing data later rendered) rather than new objects, are of very
little use because those parts of POV-Ray are in a major need for a rewrite
while most of the objects can just be converted.

> To me (as looking at it from outside) it seems like there would be
> enough ideas, code and manpower around here for quite some innovation
> but there is somebody somewhere out there actively pulling the break.

Well, POV-Ray is a program for users, not for developers.  Just adding
features is the absolute wrong way of doing development.  If you want to
contribute, there is a long list of outstanding bugs on www.povray.org and
p.bugreports that definitely have a higher priority than adding new
features.  And you can be sure the community as well as the POV-Team will
greatly appreciate bug fix contributions.

Still, also said list has been available since the release of POV-Ray 3.5, I
am only aware of two people only ever to look into any of them.

> I learned that in most cases it turns out negatively to hinder those
> people who want to work (and have the ability to do it well) from
> doing their work.

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.

Honestly, I find such behavior very disrespectful towards both the community
as well as the POV-Team members.  On the one hand the community is shown
some great new feature, but when there are bugs, frequently in the past more
than one original developer did not have any time to finish their work.  I
have no problem with someone turning to other interests, but I have a
problem if they do so only after they made the community curious about their
work.

In the end, the POV-Team frequently did add such features, and by doing that
had to go through all the source code they didn't write, fix the bugs, fix
the design flaws, and in many cases even write the documentation.

THIS IS NO FUN At ALL!  It takes a real lot of time and patience!!!  Time
and patience the original developer could not be bothered to find in several
cases.  So, if you consider the POV-Team being careful about adding new
features "to hinder those people who want to work", fine, I call it
prevention of wasting even more of our free time on something simply nobody
else wanted to waste their free time doing.

In conclusion, contribute fixes for the real bugs that concern users, or
quit complaining.

Of, course, this is only my personal opinion, nothing else.

    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:
>> 
>> Yes, but there are two reasons for my approach:
>> (1) Opening a 1Gb file in an external program, selecting some part,
>>     saving it... all that for every view port is too much work for me.
>> (2) The cut-down chunk needs extra calculations to make sure the
>>     image map projection is exactly correct.
>> My patch saves me from both these.
>> [...]
> 
> I don't understand (2) and (1) of course is no more an issue with an
> external program than it is with a POV-Ray patch.
> 
(1) is easier with POVRay than with an external program and much faster 
    because POVRay simply reads part of the info while the external proggy 
    requires reading the complete info, processing it, write a part and 
    then make POVRay read that part. 
(2) the cut-down image will be projected around the complete e.g. sphere. 
    To make use of it, I need to scale and rotate the texture in a way 
    that the original size is restored. The patch does not require that. 

I just write that because you asked. 

I am NOT actively demanding inclusion of that patch. All I wanted to 
express by my first posting was that in case there are several people 
who find it useful, one could consider doing it. That was unlikely 
from the beginning...

> No, please reread the past postings in this concern.  The proposal to
> work on the unix specific part of the 3.5 code did only involve the X11
> display code.  This is exactly as it is in 3.5 and the changes you made
> there could be merged with the 3.6 code without any trouble.
> 
IMO, it was pure luck that the code parts did not interfere. 
And it effectively hinders me to think of any more useful things 
in that concern. 

I may describe my situation as follows. 

(A)
For the partial image reading patch, watiting is no solution. 
I need it now, so I implement it now. I asked if there is interest 
but that fact that there is none does not pose any trouble because 
I am writing it for _my_ purpose in the first place. It currently is 
a not very clean hack anyways (but I would have considered writing 
it cleanly in case real interest exists). 

(B)
For unix.cpp the situation is differently. I think one can live with 
it but there are some things to be improved. So, due to the fact that 
I am using a great tool written by some clever people who share it with 
me (I mean POVRay), there are some days where I simply think that it 
would be the apropriate action to give something back by sitting down 
and writing some improvements. (I do not talk about simple bug fixes.) 

But these people effectively tell me that they don't care. 
So, I say "Well... I can spend my time more usefully."
It simply does not make sense to re-write old code. Or to quote you 
again: 
> You'd probably save some time [...]

The sad thing is that this does not help either party. 

BTW, you did not comment on megapov. 

Wolfgang

Post a reply to this message

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

> Please reduce a tiny bit your expression of the "POV-code-is-the-best-
> code-in-the-world-and-all-other-programs-are-full-of-bugs-or-trivial"
> theoreme.

I didn't say that at all.  And I definitely never said such a thing to the
contrary.

On the other hand, how old is the Mozilla code base, or the Linux kernel?
The POV-Ray code dates back to the mid 1980s.  And it has not required a
rewrite since.  Yet, the two projects mentioned have had their whole design
turned over how many times in just the last five years?

> From those bugs I have found myself in POV code, the code is not as
> high-quality as you consider it to be. I am really sorry to say that
> but sometimes it is healthy to face truth.

Read my other post.  It is very easy to complain about bugs and then to do
nothing about them.  Of course, you just want to do the fun part, but hey,
guess what, everybody want to do just that.  The difference between a
POV-Team member (or everybody with source code access) and the average patch
writer is that a POV-Team member takes the responsibility of a feature's
bugs getting fixed and to make it bug free eventually.

> [BTW, I do not remember my mozilla ever crashing. But I remember
> POVRay 3.5c (official) crashing. But I am using mozilla only when
> konqi does not get along with a page...]

Sure, Mozilla never crashing, not consuming a gigabyte of memory and taking
an hour to start up the first time.  Even Konqueror crashes if fed with the
"right" page.  At least my "version" of it does.  And I tend to use IE 5.2
to view pages in such cases.  Yet, compare Konqueror to Mozilla.  The first
one is well structured with a simple yet powerful and considerate design,
the later is a huge waste of compilation time with *much* more code to do
the same thing.  Code quality is more than just not crashing.  In fact,
crashing bugs are the easiest to find and solve.  The design on the other
hand...

> But stop. I do NOT want to start a discussion here about mozilla, the
> linux kernel, XFree86, the different development models around etc.

Ah, yes, the other two high-profile projects showing clear signs of forking
and serious code quality problems.  Of course, monolithic kernels are such a
great idea, so they flaw must be elsewhere than in the fool who conceived
it.

> Especially, I would ask you not to answer here, that if we would put
> POVRay code in a public CVS and let all the world contribute, then the
> code will be fubar within very short time.

CVS, sure.  Ever looked into the CVS source code?  I had the stupid idea to
do so just three weeks ago.  Two hours later, I rushed to delete it from my
harddisk again.  There are things I don't even want to know, and I really
don't want to know what holds CVS together.  But this shouldn't be the point
here:

Even if the code would not be "fubar within very short time", the ability of
every user to use any new feature would be very quickly.  Of course, I don't
want to point at the contribution of anybody (after all the POV-Team did
pick them up and was and still is committed to the original work and it was
all very useful), but if you look at how some patches had to be used (even
putting their flaws with fixed buffers and such aside) prior to being
included in 3.5, it should not be too hard to get an idea why I am
concerned.  Of course, you cannot know this because you probably never tried
to fix any of the old patches before they were added to 3.5...

    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 <4012b47d@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>  
wrote:

>  (I do not talk about simple bug fixes.)

But that is what is needed.  Don't you think POV-Team members cannot think
of more than "simple bug fixes"?  Yet, if all we get is *more* than "simple
bug fixes", which is what takes the real time of any serious software
development project, how are we supposed to actually do more?  By not doing
the "simple bug fixes"?

Anyway, let me rewrite this in my favorite and brutally honest style; but
please don't it personal, I am just saying exactly what I am thinking:

I don't want to get personal, and I don't know your background, but if you
think about bug fixes as "simple", you either never had to fix bugs, or you
don't know anything about software development.  I know absolutely no
professional (who I know isn't a fool, and even they usually have realised
fixing bugs is hard) that considers fixing bugs something that is simple.
So, given I know very little about you, using only what you say to judge the
validity of your arguments, your statement about "simple bug fixes" does not
give those arguments much credibility...

    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:
> 
> (1) is easier with POVRay than with an external program and much faster 
>     because POVRay simply reads part of the info while the external proggy 
>     requires reading the complete info, processing it, write a part and 
>     then make POVRay read that part. 
> (2) the cut-down image will be projected around the complete e.g. sphere. 
>     To make use of it, I need to scale and rotate the texture in a way 
>     that the original size is restored. The patch does not require that. 

Surely it is a matter of opinion if this is a useful patch - i can only 
say that i personally never felt nor now feel the necessity for such a 
feature and it offers nothing that would be impossible with external tools.

If you like this feature and therefore implement it that is of course 
all right, i just have the impression that you interpret the lack of 
interest in this patch as a lack of interest in people working on 
improving POV-Ray in general.

> 
> BTW, you did not comment on megapov. 

There is nothing to comment on i think.  Thorsten pretty much summarized 
the current situation of MegaPOV.  If you wanted to ask about inclusion 
of your patch, this is mainly a matter of:

- quality of the patch and its documentation
- if it is regarded as useful and well usable by the MegaPOV Team
- if there is interest in the patch among users

And in any case not for MegaPOV 1.1 which already contains more than 
enough new features.

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

Thorsten Froehlich wrote:

>> Please reduce a tiny bit your expression of the "POV-code-is-the-best-
>> code-in-the-world-and-all-other-programs-are-full-of-bugs-or-trivial"
>> theoreme.
> 
> I didn't say that at all.  And I definitely never said such a thing to the
> contrary.
> 
You did it and are doing it right here again. 
I just made an exaggeration to make the point obvious. 

> On the other hand, how old is the Mozilla code base, or the Linux kernel?
> The POV-Ray code dates back to the mid 1980s.  And it has not required a
> rewrite since.  Yet, the two projects mentioned have had their whole
> design turned over how many times in just the last five years?
> 
[I won't feed the trolls.]

>> From those bugs I have found myself in POV code, the code is not as
>> high-quality as you consider it to be. I am really sorry to say that
>> but sometimes it is healthy to face truth.
> 
> Read my other post.  It is very easy to complain about bugs and then to do
> nothing about them.  Of course, you just want to do the fun part, but hey,
> guess what, everybody want to do just that.  The difference between a
> POV-Team member (or everybody with source code access) and the average
> patch writer is that a POV-Team member takes the responsibility of a
> feature's bugs getting fixed and to make it bug free eventually.
>
(1) I did something against all bugs I found in POVRay where I could. 
    I remember only the parametric object bug and I looked into it a 
    month ago and sill do not know what to do about it. 
(2) You should read it like that: all the closed source & design 
    effords did not prevent the code from being as good as you would 
    like to have it. So...
 
> Sure, Mozilla never crashing, not consuming a gigabyte of memory and
> taking
> an hour to start up the first time.  Even Konqueror crashes if fed with
> the
> "right" page.  At least my "version" of it does.  And I tend to use IE 5.2
> to view pages in such cases.  Yet, compare Konqueror to Mozilla.  The
> first one is well structured with a simple yet powerful and considerate
> design, the later is a huge waste of compilation time with *much* more
> code to do
> the same thing.  Code quality is more than just not crashing.  In fact,
> crashing bugs are the easiest to find and solve.  The design on the other
> hand...
> 
[I won't feed the trolls here. Just a statement: I had more konqui 
crashes than mozilla crashes. Maybe because I am using beta versions 
from time to time.]

> Ah, yes, the other two high-profile projects showing clear signs of
> forking
> and serious code quality problems.  Of course, monolithic kernels are such
> a great idea, so they flaw must be elsewhere than in the fool who
> conceived it.
> 
[I don't feed the trolls here. And I would have liked you for not 
doing so as well.]

> CVS, sure.  Ever looked into the CVS source code?  
>
Yes, because it had some trouble with symlinks. 
And after doing so I thought one should make a complete re-write 
because the design is flawed. 
Then I wondered why so many people are using it. 

Wolfgang

Post a reply to this message

Christoph Hormann wrote:
> If you like this feature and therefore implement it that is of course
> all right, i just have the impression that you interpret the lack of
> interest in this patch as a lack of interest in people working on
> improving POV-Ray in general.
> 
No, stay assured that I do not. My impression is older. 

> - quality of the patch and its documentation
> - if it is regarded as useful and well usable by the MegaPOV Team
> - if there is interest in the patch among users
> 
> And in any case not for MegaPOV 1.1 which already contains more than
> enough new features.
> 
I was not thinking about partial image reading. 

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

Especially, the latter may be considered useful by other people; there 
even once was a posting about someone demanding something similar being 
implemented. 

Wolfgang

Post a reply to this message

Thorsten Froehlich wrote:

> Anyway, let me rewrite this in my favorite and brutally honest style; but
> please don't it personal, I am just saying exactly what I am thinking:
> 
No problem. 

> I don't want to get personal, and I don't know your background, but if you
> think about bug fixes as "simple", you either never had to fix bugs, or
> you don't know anything about software development. 
>
Well, neither is true. I've been writing code during a decade now, 
currently O(1Mb) per year and I know that fixing the bugs in the code 
can take you 5 hours for something as stupid as a missing semicolon. 

What I was referring to with "simple bug fix" was a patch which 
does changes to O(1) lines to fix some bug and which is pretty trivial 
to understand. We had several such bugs in POVRay. 

It was to say that the patches are "simple" to understand and "simple" to 
integrate into the code. 

I did not say that they were "simple" to find. But for some of them 
even that is true because I accidentally found them because I read the 
code and not because I saw the bug appearing in program behaviour. 

> I know absolutely no
> professional (who I know isn't a fool, and even they usually have realised
> fixing bugs is hard) that considers fixing bugs something that is simple.
>
Fixing a bug which is only known by misbehaviour can be extremely hard. 
Fixing a bug which you see in the source code _can_ be extremely easy. 
Or it can open your eyes for a huge design flaw which demands a large-scale 
rewrite. I already had both cases myself...

> So, given I know very little about you, using only what you say to judge
> the validity of your arguments, your statement about "simple bug fixes"
> does not give those arguments much credibility...
> 
Then re-read them with my actual intend (as explained above) in mind :)

Wolfgang

Post a reply to this message

In article <lnm### [at] tritonimagicode>, chr### [at] gmxde 
says...
> Wolfgang Wieser wrote:
> > 
> > Yes, but there are two reasons for my approach: 
> > (1) Opening a 1Gb file in an external program, selecting some part, 
> >     saving it... all that for every view port is too much work for me. 
> > (2) The cut-down chunk needs extra calculations to make sure the 
> >     image map projection is exactly correct. 
> > My patch saves me from both these. 
> > [...]
> 
> I don't understand (2) and (1) of course is no more an issue with an 
> external program than it is with a POV-Ray patch.
> 
Actually it is more of an issue with an external program. It is called 
wasted time. It may only be 4-5 minutes, but it is still time you spend 
screwing with an external program (that may even crash in some cases with 
an image 1G in size), instead of doing a relatively trivial clipping of 
the image in the program you need to actually use the result in. I think 
it is a good option, but then I also can't afford on my system to 
generate x number of 100-200MB, or whatever, files containing all the 
images I clipped out, on top of the original 1G file. And if you are 
doing a panorama, where you may want/need those things to overlap, you 
may end up using 2G of extra space, tripling how much room the images 
take up, instead of merely doubling it. God forbid you don't have a DVD 
burner (such images won't fit on a CD-R) and you decide to make 30-40 of 
these images, each using a 1G file. Even the 80G hard drives most people 
can now get cheap won't last long in such a situation. lol Imho, this is 
actually a good idea.

-- 
void main () {
  If Schrödingers_cat is alive  
    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

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

> But you have access to the source code.  Use it.  Honestly I have to say
> several of the contributed bug fixes we so far got for 3.5 cannot (well,
> should not) be used as is in the source code.  While many bug fixes
> correctly identify the problem, they frequently tend to be more of a
> "hack" than a solution.
> 
I cannot comment on that beause I did not see them. 
(And as other peple out here do not see them, they can hardly come up 
with something better.)

> And periodically looking at various "open source" development projects
> makes
> me worry a lot about even considering using that software.  Despite its
> age, the POV-Ray source code is in a very good shape compared to many much
> younger "open source" projects whose individual modules are rewritten
> every three or four years...
>
[I am skipping this paragraph in an attempt to not feed the trolls.]
 
> 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. 

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

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

> Apart from that, with 4.0 being a rewrite, producing patches, especially
> some that just add minor individual tweaks (usually by parser or
> preprocessing data later rendered) rather than new objects, are of very
> little use because those parts of POV-Ray are in a major need for a
> rewrite while most of the objects can just be converted.
> 
This is clear (although I think that "just converting" the parametric 
object will not be that easy...)

As you are talking about version 4.0, I think it should not only be 
a re-write but a re-design in that it allows several things being 
done which one would like to do with the current version but cannot 
due to design resaons. 
But probably design is already being discussed in the group?

>> To me (as looking at it from outside) it seems like there would be
>> enough ideas, code and manpower around here for quite some innovation
>> but there is somebody somewhere out there actively pulling the break.
> 
> Well, POV-Ray is a program for users, not for developers.  
>
Correct. And my terms of "use" of software imply that I change that 
software in case it does not fit my use. 

> Just adding
> features is the absolute wrong way of doing development.  If you want to
> contribute, there is a long list of outstanding bugs on www.povray.org and
> p.bugreports that definitely have a higher priority than adding new
> features.  
>
These lists do by no means contain all issues which should be improved. 

My mode of contribution is to write something which is immediately 
useful for _me_and_ the other users. 

It is unlikely that I start writing a fix for the "fog+media" problem 
because I do not use fog. So this problem is simply irrelevant for me 
(at least currently). 

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

> Still, also said list has been available since the release of POV-Ray 3.5,
> I am only aware of two people only ever to look into any of them.
> 
Then I am probably the third one :)

I did not look at the 
"Known bugs in POV-Ray version 3.5 that will be fixed in soon"
because it already says that obviously the solution already exists. 

The "Known bugs in POV-Ray version 3.5" either seem unimportant to 
me (superflouos warnings) or I have no clue about them (radiosity). 

About the "Bugs inherited from POV-Ray 3.1 and older versions", 
I read them, then thought that some more clever people failed to correct 
them and that I would try to fix and of them in case I actually 
hit one myself. As for the bugs in the parser, I'd suggest a complete 
rewrite anyways. 

>> I learned that in most cases it turns out negatively to hinder those
>> people who want to work (and have the ability to do it well) from
>> doing their work.
> 
> 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. 
(2) If some people do not want to take responsibility for their code 
    once it is included in povray, than that is sad. A solution has 
    to be found which does not hurt those people who behave "correctly". 

> I have no problem with someone turning to other interests, but I have a
> problem if they do so only after they made the community curious about
> their work.
> 
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...

> cases.  So, if you consider the POV-Team being careful about adding new
> features "to hinder those people who want to work", fine, I call it
> prevention of wasting even more of our free time on something simply
> nobody else wanted to waste their free time doing.
> 
I was aware of these arguments before. 
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". 

> In conclusion, contribute fixes for the real bugs that concern users, or
> quit complaining.
> 
Why not give people who want to do that the current code?

(I am not saying here that you send me the code and then I fix all the 
bugs -- just to be sure.) 

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. 

If I am the only non-team member thinking so, them this can be 
considered irrelevant by the team. But most people doing code review 
or open source development will probably consent. 

But probably nobody will read these lines because the posting is too long.

Wolfgang

Post a reply to this message

In article <4012a910@news.povray.org>, wwi### [at] gmxde says...
> Christopher James Huff wrote:
> 
> >> Basically, the patch allows you to select a rectangular region of
> >> an image_map so that only this part is read in and stored in RAM.
> >> Pixels outside this region are all considered 50% gray (some other
> >> solution like quick_color could also be thought of).
> > 
> > Pixels outside that region should probably be fully transparent, to be
> > consistent with the "once" option. 
> >
> I would prefer the pixels to be of configurable color...
Considering that 'color' can be rgbf <1,1,1,1>, I would have to agree 
there. You want transparent, make it transparent. lol

> 
> > And why not read in the region as the
> > entire image, filling the entire area of the image_map? Simpler, and
> > avoids the above problem completely.
> > 
> I do not completely understand what you plan there but it seems to me 
> that this requires the used to do additional scaling and 
> rotation/translation of the texture (which may not be trivial for 
> some projections). 
> Furthermore, for my current personal use, the 50% gray is a "feature" 
> (sea level on Mars). 
However, I agree with Christopher's view that actually clipping the image 
completely, instead of filling the rest of a color, could be better for 
some uses. Like an actually image map, instead of the what you are doing 
with it. It wouldn't necessarily require extra scaling and the like, 
since in this case you would be using the clipped region as though it was 
the complete image, so in some situation like an animation you just move 
the clipping you plan to do in the direction you want and that becomes 
the new image. POV-Ray would save memory a lot by only loading the region 
piece of the image it actually needs, instead of the whole thing.

I am still not 100% sure what you are actually doing in the case of your 
patch, the only explanation you give is a vague reference to "(sea level 
on Mars)", which doesn't say if you are using it as a) and image map, b) 
a height field, c) some other thing... You might have better luck 
convincing people that filling the image, instead of simply clipping is 
better, if we had an example of what you are doing with it. ;)

-- 
void main () {
  If Schrödingers_cat is alive  
    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

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

> > Pixels outside that region should probably be fully transparent, to be
> > consistent with the "once" option. 
> >
> I would prefer the pixels to be of configurable color...

This would be a good option. And ideally, one would be able to specify 
both the domain (the area of the input image used) and the range (the 
area it maps to). Another possible feature would be to allow specifying 
the resolution to store the image as...maybe you need a low res version 
for some uses. The ability to reference frames of an animation for image 
maps would be nice. So would the ability to refer to specific channels. 
But none of this is going to make it into 3.6, it's just too late.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

Patrick Elliott wrote:
> 
> Actually it is more of an issue with an external program. It is called 
> wasted time. It may only be 4-5 minutes, but it is still time you spend 
> screwing with an external program (that may even crash in some cases with 
> an image 1G in size)[...]

Sorry but this is complete nonsense, i have been cutting subsets from 
large images for a long time now and it does not take any longer than to 
parse such images in POV (why should it - it is essentially the same 
operation).  And the  memory use while doing that is minimal.

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

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

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

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

The consequence would be users coming years later and reporting bugs in
versions they think are current.  This is exactly what happened in the days
when source code was available.  And it was before the WWW was around...

    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:

> 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.
> 
Okay, the distribution problem is something I was not thinking about. 
OTOH, if one distributes binary betas, why not source betas?

> 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?
> 
If 4.0 is supposed to come in several years, then "time" could be a 
reason. 

And as 4.0 will probably use the same numeric maths, fixing that would 
IMO make sense even if minor. 

> 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.
> 
No non-trivial software is completely bug-free. 

So, if one waits with releases until there are really no bugs left, 
one will never release it. 
OTOH, if one includes patches and releases without testing, there will 
be tons of bugs. 

This is nothing new. 

But given that problem the solution is to find a way between the two 
extrema. Where the cut is to be placed depends on one's opinion. 

As for me personally and considering POVRay, I'd actually prefer some 
more features (now) even if they come with some more bugs. Because I 
belong to those people who (potentially) fix those bugs they find. 

So, I benifit from the features. And when I find a bug, oh well, then 
time needs to be spent on that but _somebody_ would have to do just that 
anyways sooner or later. 

> 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.
> 
...as long as I do not spend 10 hours tracking something down which 
has already be fixed by someone else!

> 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. 
>
Yes, but it is enough if _one_ such person exists. 
And what is the use of fubar code nobody wants to care about? 
It's like cancer...

Wolfgang

Post a reply to this message

Thorsten Froehlich wrote:
>>> And promtly distribute binary versions without a timeout in them. No!
>>
>> ??!
> 
> The consequence would be users coming years later and reporting bugs in
> versions they think are current.  This is exactly what happened in the
> days
> when source code was available.  And it was before the WWW was around...
> 
(1) That is why I always get the newest release before reporting a bug. 
(2) Every bug report needs to contain a version number. And if a user 
    reports stoneage bugs, automatic reply would be "update your system"
    There is nothing else one could do against that. I do not see any 
    difference, especially as under the current model, is is not only 
    the version "they think is the current" but it _IS_ the current, 
    or to express is easier: 
(3) So what? The current code is year(s) old -- what makes the difference ;)

Wolfgang

Post a reply to this message

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

>> The consequence would be users coming years later and reporting bugs in
>> versions they think are current.  This is exactly what happened in the
>> days
>> when source code was available.  And it was before the WWW was around...
>>
> (1) That is why I always get the newest release before reporting a bug.

If you do it doesn't mean everybody else will.  Just look at all those
Outlook Express exploiting "emails" around even after bugs had been fixed a
long time ago and there is a rather easy update feature...

> (2) Every bug report needs to contain a version number.

Tell that to users.  You would be surprised how many even manage to report
the *wrong* version number...

> (3) So what? The current code is year(s) old -- what makes the difference ;)

I explained that before.  That there was no 3.5.1 had no developmental
reasons.  Apart from that, inn general, there is a huge difference between a
current version that has been released a year ago and a outdated long
replaced version that has been released five years ago!

    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:
> [...]
> 
> 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. 

PRTImageData and PRTTileHeap are both completely undocumented and they 
do some really strange things - using 16 bit values for the image for 
example is understandable for memory size reasons but this makes it 
essentially incompatible to other patches (HDR output, post processing).

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

Christoph Hormann wrote:

> Wolfgang Wieser wrote:
>> [...]
>> 
>> 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.
> 
> PRTImageData and PRTTileHeap are both completely undocumented 
>
No, they are not. The header file contains a small comment on the 
functionality of the methods. I normally put my docu into the header 
and not into the .cpp files because when I want to use the code 
lateron, I using the headers is more convenient. 

But of course, more comments explaining some general ideas and 
workings should be added. 

> and they
> do some really strange things - using 16 bit values for the image for
> example is understandable for memory size reasons but this makes it
> essentially incompatible to other patches (HDR output, post processing).
> 
Ah, you are right. In case there are other patches or parts of the code 
which need the complete image in memory, one should design and implement 
exactly one class which can do so if needed and can be used by all other 
parts. This class should be able to handle 16 bit precision if required. 

It should, however, not be the default, because the row-by-row 
working of povray enables users to generate images of real large size 
(6000x6000 which would use 200Mb for the PRT image buffer alone). 

BTW, Since when did I have access to HDR output and post processing code?

Wolfgang

Post a reply to this message

Wolfgang Wieser wrote:
> [...]
> 
> I consider the introduction of these two classes as good design. 

Speaking of good design:

static inline void PRT_interpolate_linear(COLOUR *dest,
	COLOUR *l,COLOUR *r,float p)
{
	for(unsigned int ii=0; ii<sizeof(COLOUR)/sizeof(float); ii++)
	{  (*dest)[ii]=PRT_interpolate_linear((*l)[ii],(*r)[ii],p);  }
}

For constructions like this you deserve to get shot.

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

Wolfgang Wieser wrote:
>>and they
>>do some really strange things - using 16 bit values for the image for
>>example is understandable for memory size reasons but this makes it
>>essentially incompatible to other patches (HDR output, post processing).
>>
> 
> Ah, you are right. In case there are other patches or parts of the code 
> which need the complete image in memory, [...]

No, this is not about keeping the whole image, it is about keeping the 
unclipped full precision color values.

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 <ofa### [at] tritonimagicode> , Christoph Hormann 
<chr### [at] gmxde>  wrote:

> Speaking of good design:
>
> static inline void PRT_interpolate_linear(COLOUR *dest,
>  COLOUR *l,COLOUR *r,float p)
> {
>  for(unsigned int ii=0; ii<sizeof(COLOUR)/sizeof(float); ii++)
>  {  (*dest)[ii]=PRT_interpolate_linear((*l)[ii],(*r)[ii],p);  }
> }
>
> For constructions like this you deserve to get shot.

Hey, that is *my* line! ;-)

    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:
>>>and they
>>>do some really strange things - using 16 bit values for the image for
>>>example is understandable for memory size reasons but this makes it
>>>essentially incompatible to other patches (HDR output, post processing).
>>>
>> Ah, you are right. In case there are other patches or parts of the code
>> which need the complete image in memory, [...]
> 
> No, this is not about keeping the whole image, it is about keeping the
> unclipped full precision color values.
> 
...probably including transparency and filter which sums up to 20 bytes 
per pixel which may get a problem when storing the whole image. 

So, my idea would be a class which can save the complete image at 
different resolutions: 8bit, 16bit, full float. If there are several 
code parts in need of such a storage, the one with the highest resolution 
demand will set the internally used format. 
The interface would use COLOUR, but the internal data representation 
would allow different formats to save memory. 

(And I am not only talking about it, I would also consider writing 
such a class if it is needed.)

Wolfgang

Post a reply to this message

Christoph Hormann wrote:

> Wolfgang Wieser wrote:
>> [...]
>> 
>> I consider the introduction of these two classes as good design.
> 
> Speaking of good design:
> 
> static inline void PRT_interpolate_linear(COLOUR *dest,
> COLOUR *l,COLOUR *r,float p)
> {
>       for(unsigned int ii=0; ii<sizeof(COLOUR)/sizeof(float); ii++)
>       {  (*dest)[ii]=PRT_interpolate_linear((*l)[ii],(*r)[ii],p);  }
> }
> 
> For constructions like this you deserve to get shot.
> 
(1) This does not come from one of the two classes. 
    I explicitly put the functions doing the dirty things as 
    some inline functions at the beginning of the file. 
    (pure C guys would use macros here...)
(2) These functions are actually older than the PRT patch. 
    They go back to my IPT patch. 
(3) What would you suggest as the "best" solution? 
    I'll be happy to replace it. 

Wolfgang

BTW, I like these much much better:

#define Assign_Colour_Express(d,s)  {(d)[pRED] = (s)[pRED]; (d)[pGREEN] = \
        (s)[pGREEN]; (d)[pBLUE] = (s)[pBLUE]; (d)[pFILTER] = (s)[
#define Make_Colour(c,r,g,b) {(c)[pRED]=(r);(c)[pGREEN]=(g);\
        (c)[pBLUE]=(b);(c)[pFILTER]=0.0;(c)[pTRANSM]=0.0;}
#define Make_ColourA(c,r,g,b,a,t) {(c)[pRED]=(r);(c)[pGREEN]=(g); \
        (c)[pBLUE]=(b);(c)[pFILTER]=(a);(c)[pTRANSM]=t;}
#define Make_Vector(v,a,b,c) { (v)[X]=(a);(v)[Y]=(b);(v)[Z]=(c); }
#define Make_UV_Vector(v,a,b) { (v)[U]=(a);(v)[V]=(b); }
#define Destroy_Colour(x) if ((x)!=NULL) POV_FREE(x)
#define Make_RGB(c,r,g,b) {(c)[pRED]=(r);(c)[pGREEN]=(g);(c)[pBLUE]=(b);}

What about shooting the author(s) with a machine gun? :p

Post a reply to this message

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

> What about shooting the author(s) with a machine gun?

You will have a hard time doing this in 3.6...

    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 <221### [at] tritonimagicode>, chr### [at] gmxde 
says...
> Patrick Elliott wrote:
> > 
> > Actually it is more of an issue with an external program. It is called 
> > wasted time. It may only be 4-5 minutes, but it is still time you spend 
> > screwing with an external program (that may even crash in some cases with 
> > an image 1G in size)[...]
> 
> Sorry but this is complete nonsense, i have been cutting subsets from 
> large images for a long time now and it does not take any longer than to 
> parse such images in POV (why should it - it is essentially the same 
> operation).  And the  memory use while doing that is minimal.
> 
> Christoph
> 
> 

Umm. Then I am a tad confused... Do you mean executing that program from 
inside POV? Unless this is what you mean, then I haven't a clue what you 
are talking about here. I am talking about limited the total size of the 
file you load in POV-Ray by chopping up the original into smaller bits, 
so when you do use them, you are loading much smaller ones.

As for it being the same operation. Some programs are memory hogs, have 
glitches when dealing with truly hug files, etc. And not all of us can 
afford to buy one that doesn't to replace whatever we are already using. 
The fewer extra programs you have to fiddle with to get something done 
the better imo.

-- 
void main () {
  If Schrödingers_cat is alive  
    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

In article <4012d99e@news.povray.org>, wwi### [at] gmxde says...
> 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. 
> 
Missing the point. You stated that you made a change, gave the code, but 
never actually said how or why you are using it. This is sadly one of the 
reasons why some great ideas never see the light of day. It is not enough 
to toss code into people's laps and say, "Here is something I did. Maybe 
someone will find it useful." You also have to tell them what the heck 
you thought it was useful for. You didn't do that until someone a great 
deal brighter than me questioned 'how' you did it and suggested 
transparency.

> > 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 ;)
> 
Now, there is what I meant. A wonderful example. Now someone can look at 
it as say, "Heh, that's something I could really use. Where is the 
patch?" I may even use it myself some time. I have a program I designed a 
while back involving a GPS locations database, but always wanted to put a 
map in with it. The problem was a) I didn't want a 1G files, which I 
couldn't put on a CD anyway and b) I couldn't find any smaller version 
that where not pure junk. Being able to take a 1G file of the place I 
want and render a series of smaller images that are easier to load would 
be very helpful. Now I just need to find the damn map I need to do it 
with... lol

Of course I also don't have, want to, or plan to compile a patch myself, 
so unless this does find its way into MegaPOV or something, I probably 
still won't use it. My philosophy is that if you don't understand even 
10% of how a program works, don't screw with any of it yourself. ;) lol

-- 
void main () {
  If Schrödingers_cat is alive  
    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

On Sun, 25 Jan 2004 19:58:02 +0100, Wolfgang Wieser <wwi### [at] gmxde> wrote:
> #define Assign_Colour_Express(d,s)  {(d)[pRED] = (s)[pRED]; (d)[pGREEN] = \
>         (s)[pGREEN]; (d)[pBLUE] = (s)[pBLUE]; (d)[pFILTER] = (s)[
> What about shooting the author(s) with a machine gun? :p

Apart all others things mentioned in this thread I find:

  (d)[pRED] = (s)[pRED]

much better "designed" than

  sizeof(COLOUR)/sizeof(float)

ABX

Post a reply to this message