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 () {

    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 () {

    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