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