Warp wrote:
> 
>   I don't think you'll want a mosaic preview of a really large image
> anyways?-)

I was not referring to the mosaic preview but to your statement:

> >   With current computers there's no problem in keeping the whole image
> > in memory, so there's no such problem anymore. However, no-one has touched
> > that code since then, I suppose. :)

I just want to make sure no one assumes this is correct per se.

BTW a reusable mosaic preview does not require the whole image in memory
but only up to 1/4 of it.

Christoph

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

Post a reply to this message

On Sun, 02 Feb 2003 12:56:04 +0100, Wolfgang Wieser <wwi### [at] gmxde> wrote:
> I always read something about "well documented" and "cleanly coded" 
> patches to POVRay, so please look at povray.cpp (!)

Core code is not a patch. In principals it works as all raytracers. Raytracing
code and environment things are in core usually well isolated and do not
interfere. They exist for years and are well tested so you can be nearly sure
they are (perhaps not perfect but) well coded. The function/variable name
usually gives an answer what it does and quick search for this name gives an
answer when and why it is used.

Patches works otherwise. They are fresh, usually buggy in initial version and
developed by one person. They are developed for one state of core code and
therefore can be hard to port to other customized sources. All those
interested with your patch but working with own customized povray sources have
to solve set of conflicts between their patches and your. And that's why
"'well documented' and 'cleanly coded' patches" issue is so much important.
Look here http://megapov.inetart.net/manual/internals.html#markup

And all above does not mean I do not like comments. I also like well commented
sources to use for patching :-)

ABX

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message
news:3e3d383c@news.povray.org...
> Thorsten Froehlich <tho### [at] trfde> wrote:
> >> The current mosaic preview adds rendering time because the pixels
> >> rendered in the preview are not used in the final rendering.
>
> > Yes.  I know it is intentional, but I do not know why.
>

If youre talking about the Radiosity Pretrace, this is done to "seed" the
rendering with some prestored ambient values. It is essential to getting a
good-quality radiosity rendering.

George Pantazopoulos

Post a reply to this message

ABX wrote:
> On Sat, 01 Feb 2003 23:52:11 +0100, Wolfgang Wieser <wwi### [at] gmxde>
> wrote:
>> The principle is to only render some pixels and calculate the color of
>> other pixels using interpolation.
> 
> Sorry, that's not clear for me, is your addition supposed to be an final
> output or just preview ?
> 
Sorry if I was a bit confusing when using the word "preview". 

I intend that the rendered/partly interpolated image is the final 
image produced by POVRay. BUT you will most likely only use it as 
feedback during design, most notably for animations (-> "animation 
preview")
Because test-rendering animations always takes too long for me, 
I want to try and implement something to achieve slightly less quality 
in considerably less time. 

Don't know how well it will work or how much savings that will 
achieve. But do NOT use the patch I mentioned, it implements just 
the first step and produces bad results. 

BTW, I'll be VERY busy during the next 4 weeks, but come back 
to that issue once I play around with POVRay again (i.e. some time 
next month). 

Wolfgang

Post a reply to this message

ABX <abx### [at] abxartpl> wrote in
news:clfs3vsmh2h0tr5g3qbq27lafk836kkjjc@4ax.com: 

> On 2 Feb 2003 20:39:12 -0500, Tom Galvin <tom### [at] imporg> wrote:
>> 8192x8192*24bit color is only 200 MB.
> 
> ... when POST_PROCESS_PATCH is not applied yet ;-)
> 

True.

>> A 256MB simm is less than $100 US.  
> 
> I use 3 computers for developing POV patches and one is portable 486
> with 48 MB, just to be sure that neither memory or speed is wasted ;-)
> 
> ABX

My point was that times have changed.  I started using POV on a brand new 
IBM 486 DX-2 66Mhz machine with 4MB of RAM.  Rendering anything at 
8192x8192 would have been a feat.

I don't currently use mosaic since it does take longer.  If there was an 
"option" to sacrifice memory for speed when using Mosaic then I would use 
it all the time.  Leave the default setting to favor memory.  If it is 
really a simple matter to provide Mosaic without a speed penalty then it is 
at least worth considering as an option.

Post a reply to this message

Wolfgang Wieser wrote:
> ABX wrote:
>> On Sat, 01 Feb 2003 23:52:11 +0100, Wolfgang Wieser <wwi### [at] gmxde>
>> wrote:
>>> The principle is to only render some pixels and calculate the color of
>>> other pixels using interpolation.
>> 
>> Sorry, that's not clear for me, is your addition supposed to be an final
>> output or just preview ?
>> 
> BTW, I'll be VERY busy during the next 4 weeks, but come back
> to that issue once I play around with POVRay again (i.e. some time
> next month).
> 
And...

If somebody has a great idea for such an algorithm (deciding what to 
render and what to interpolate in which way so that it saves a lot 
of rendering time and does degrade quality only just a little) but 
does not want to code it (or has no time), feel free to share your 
ideas. If it sounds promising it's likely that I'll give it a try. 
(Any working patch will be made public by me, of course.)

Wolfgang

Post a reply to this message

Florian Pesth wrote:
> Thorsten Froehlich schrieb:
>> <offtopic>
>> In fact it will never be released under the GPL.  The GPL comes with a
>> political message that is not acceptable to all team members.  It 
>> certainly
>> isn't acceptable to me.
> 
> Which political message? Did I miss something?

The GPL as a set of rules and requirements is certainly a product or an 
expression of a particular political belief, but by that alone you could 
not claim that it has any more political message than a license that is 
the product of a different political belief. However, the GPL goes 
further than simply stating rules and requirements, from the preamble:

"The licenses for most software are designed to take away your freedom 
to share and change it."
and also:
"Finally, any free program is threatened constantly by software patents."
are indicative of the general tone of that section. I do not have any 
problems with the GPL as a license, but I can see that some people 
would. I do have problems with some of the things that Richard Stallman 
says, but these sentiments are not explicitly embodied within the GPL.

I don't see anything particularly political about the content of the 
section "TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND 
MODIFICATION". Certainly the particular rules may be unpalatable to some 
people, but they are nothing more than rules.

I would be curious to know what it is in particular that team members 
object to in the GPL, and wheather they may at some stage consider some 
other OSI approved license.

Post a reply to this message

In article <3E4### [at] alphalinkcomau> , Edward Coffey 
<eco### [at] alphalinkcomau>  wrote:

> I don't see anything particularly political about the content of the
> section "TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND
> MODIFICATION". Certainly the particular rules may be unpalatable to some
> people, but they are nothing more than rules.

The whole idea of the FSF and thus the GPL is to turn software development
and ownership of software into some kind of communism.  It seeks to strip an
elite group (programmers) from the right to make money from their creative
work and sole right to their work.  Instead the masses of uneducated wannabe
programmers are allowed to screw up the programs.

If that isn't political...

    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:
> The whole idea of the FSF and thus the GPL is to turn software development
> and ownership of software into some kind of communism.

This is where my view differs from yours. Remove the phrase "and thus 
the GPL" and I completely agree with that statement. The GPL is just 
saying "I'll let you have the source code for this, but only if you do 
likewise for anything you use the source in, if you don't like that, 
feel free not to use the source in your program". It never claims to be 
the one true license, the FSF does that. Certainly, the GPL does embody 
some aspects of a certain political belief, but I don't think that means 
that it is a political document in and of itself.

> It seeks to strip an
> elite group (programmers) from the right to make money from their creative
> work and sole right to their work.

Again, I think this can be attributed to the FSF, but not specifically 
the GPL, unless you are tarring all open-source licenses with the one 
brush here. Any license which allows the users to redistribute the 
software is obviously going to cut down on the authors revenue, but it 
in no way strips the author of the right to choose different licenses 
for different pieces of software (of course, the FSF does).

> Instead the masses of uneducated wannabe
> programmers are allowed to screw up the programs.

So the "bazaar" can't work, only the "cathedral" is acceptable? What 
particular GPL licensed programs are you referring to, and in what way 
are they screwed up? I don't see the Linux kernel as being particularly 
screwed up. Sure, there are many patched versions vying for distributor 
attention, indeed there are 11 different kernels on offer at the 
www.kernel.org frontpage alone. But everyone knows that the canonical 
stable release at the moment is 2.4.20, maintained by Marcelo, directly 
appointed by Linus.

Post a reply to this message

Tom Galvin <tom### [at] imporg> wrote:

> Christoph Hormann <chr### [at] gmxde> wrote in
>> Warp wrote:
>>>   With current computers there's no problem in keeping the whole
>>>   image in memory, so there's no such problem anymore.
>> 
>> You have obviously never rendered a really large image...
>> 
> 8192x8192*24bit color is only 200 MB. A 256MB simm is less than $100 US.
>
Sorry, but your calculation seems to be correct. 

POVRay internally stores the image (pixels, scan lines) as COLOUR and 
converts them to RGB only for writing them to disk (or displaying). 
All the code uses COLOUR. And that would require 1280MB of RAM for 
a 8192x8192 image. The 200Mb are needed additionally for the pixmap 
buffer...   [sizeof(COLOUR)=4*5=20]

So, how much is a 2Gb simm :p

Wolfgang

Post a reply to this message