|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Wolfgang Wieser
Subject: Re: [BUG] POVRay excessive memory consumption
Date: 24 Jan 2004 14:54:32
Message: <4012cd76@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Wolfgang Wieser
Subject: Re: [BUG] POVRay excessive memory consumption
Date: 24 Jan 2004 15:46:23
Message: <4012d99e@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Wolfgang Wieser
Subject: Re: [BUG] POVRay excessive memory consumption
Date: 24 Jan 2004 15:59:18
Message: <4012dca5@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Thorsten Froehlich
Subject: Re: [BUG] POVRay excessive memory consumption
Date: 24 Jan 2004 16:30:31
Message: <4012e3f7@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Thorsten Froehlich
Subject: Re: [BUG] POVRay excessive memory consumption
Date: 24 Jan 2004 16:31:38
Message: <4012e43a$1@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|