Warp wrote:

>   I think it would be possible to render first a non-antialiased image
> and then make a second pass shooting more rays where necessary in order to
> antialias the image.
> 
>   POV-Ray still works as it worked 10 years ago, when computers had just a
> few megabytes of memory (and thus loading a big image to memory was just
> out of question). Nowadays keeping the entire image in memory (as an option)
> would not be such a burden as it was 10 years ago and thus all kind of
> extra passes would be possible.
>   Perhaps POV-Ray 4 will change to this ideology...
> 


Some people have been rendering image (for poster printing) at big 
resolution (10000 x 10000).
That's only a need of 400 Meg of memory, just for the image (RGBA),
at only 8 bits per components.
What if they want it with 16 bits per components or even a bigger size ?

Because you have a lot of memory available is no reason to waste it
with an algorithm which scales badly.

Handling two lines of 10000 pixels is reasonnable, keeping a whole
picture in memory is not. Doing a two pass rendering (no AA, then AA) 
might be reasonnable, if you use an intermediate picture file.

Post a reply to this message

Le Forgeron <jgr### [at] freefr> wrote:
> Because you have a lot of memory available is no reason to waste it
> with an algorithm which scales badly.

  Did you notice that I said "as an option"?

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

"Le Forgeron" <jgr### [at] freefr> wrote in message
news:3D6### [at] freefr...
> Warp wrote:
> > Nowadays keeping the entire image in memory (as an option)
> > would not be such a burden as it was 10 years ago and thus all kind of
> > extra passes would be possible.
> >
> Handling two lines of 10000 pixels is reasonnable, keeping a whole
> picture in memory is not. Doing a two pass rendering (no AA, then AA)
> might be reasonnable, if you use an intermediate picture file.
>


    Why the need to keep it memory - are their really any modern computer
systems that don't allow complete random read-write access to files ?
    Think about Windows virtual memory files and you'll see there's no need
to actually keep the whole image in physical memory...

--
Pandora/Scott Hill/[::O:M:C::]Scorpion
Software Engineer.
http://www.pandora-software.com

Post a reply to this message

Mike Williams <mik### [at] econymdemoncouk> wrote:
> Permitting the continuation of a render that was stopped part way
> through would need extra attention. If the render was stopped during the
> AA pass, then the continuation would need to find files containing both
> the result of the first pass and the partial render of the AA pass.

  Not really. It just needs to save the image rendered so far and put some
extra information in the image file (most image formats support this) about
what it was doing before it was interrupted. Basically it just would have
to write the information "I was at the antialiasing pass and was interrupted
at this pixel".

> I guess that there might also be some subtle problems with things like
> isosurface cacheing, particularly if the image has large areas where the
> values don't change enough to cause many extra rays to be cast on the
> second pass.

  I don't see any difference between the current antialiasing scheme and
the second-pass-antialiasing in this respect. They both do the same thing,
but at different times.

> I also suspect that an antialliassing algorithm that really did look in
> all four directions would take longer to render

  I don't see why.

> and produce a result that looks worse (or at least no better)

  I definitely don't see why. If anything, it will look better because it
has more existing information to perform the antialiasing, which may help
it doing a better job.

> With the present algorithm, a vertical or horizontal black/white
> transition results in one pixel being supersampled - the one that has
> the colour transition on its top or left.

  Are you completely sure of this? If you look carefully at what antialiasing
does, it does modify the existing pixels at the left and up of the current
pixel.

> So I would expect this to result in twice the number of
> supersample calculations being performed, and double the width of the
> grey zone, which may well be enough to make the image look out of focus.

  I don't want to sound rude, but that is plain nonsense.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Xplo Eristotle wrote:
> A post on p.b.i reminded me of something that's been bugging me for a 
> while: when using mosaic rendering, each successive pass recalculates 
> every pixel. Wouldn't it be a great deal faster to save the data and 
> only calculate color information for new pixels?

If you're doing it for preview renders, it might be nice as well have an 
option to use "solid guessing" like fractint did.  I suppose this would 
be like making the decision to render pixels on later passes or not the 
same as for AA, only render if the next one over is "sufficiently" 
different.

-josh

Post a reply to this message

Le Forgeron wrote:
> 
> You do not have to use mosaic preview, at least not until 1x1 pixels.
> That's a better boost.

Congratulations. You've just missed the ENTIRE point of the feature.

-Xplo

Post a reply to this message

Pandora wrote:
 >     Why the need to keep it memory - are their really any modern computer
 > systems that don't allow complete random read-write access to files ?
 >     Think about Windows virtual memory files and you'll see there's 
no need
 > to actually keep the whole image in physical memory...

True, but then wouldn't you take a performance hit all over again?
Consider the classic question "Should I invest in a better CPU or
more memory to improve my raytracing speed?" (to which the
classic answer, of course is simply "Yes")

On large data sets, of course you get more bang for your buck
from memory because of the performance hit that falling back on
virtual memory gives you. Similarly, if you had to read the old
data from file might it simply cause enough performance loss to
render the new feature's efficiency moot?


-- 
@C[$F];
The Silver Tome ::  http://www.silvertome.com
"You may sing to my cat if you like..."

Post a reply to this message

"Charles Fusner" <cfu### [at] enternet> wrote in message
news:3D7### [at] enternet...
> Pandora wrote:
>  >     Why the need to keep it memory - are their really any modern
computer
>  > systems that don't allow complete random read-write access to files ?
>  >     Think about Windows virtual memory files and you'll see there's
> no need
>  > to actually keep the whole image in physical memory...
>
> True, but then wouldn't you take a performance hit all over again?


    Yes, you're going to take a slight performance hit, but on a modern
machine, with a decent harddisk and some intelligently written buffering
code (i.e. you keep the areas of the image that are most likely to be
accessed in memory, rather than accessing a file on disk for each and every
pixel) that hit will be negligible.

--
Pandora/Scott Hill/[::O:M:C::]Scorpion
Software Engineer.
http://www.pandora-software.com

Post a reply to this message

Pandora <pan### [at] pandora-softwarecom> wrote:
> that hit will be negligible.

  Nope. Accessing the disk, even when cached by the OS, is always very very
much slower than accessing a memory location (given that it's not swapped to
disk, of course). Of course the disk cache makes the operations a lot faster
in the average (compared to the case where each disk read really reads data
physically from the disk), but they are still very much slower than a direct
memory access.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message
news:3d7341da@news.povray.org...
> Pandora <pan### [at] pandora-softwarecom> wrote:
> > that hit will be negligible.
>
>   Nope. Accessing the disk, even when cached by the OS, is always very
very
> much slower than accessing a memory location (given that it's not swapped
to
> disk, of course). Of course the disk cache makes the operations a lot
faster
> in the average (compared to the case where each disk read really reads
data
> physically from the disk), but they are still very much slower than a
direct
> memory access.
>


    I know. But if the buffering is written intelligently you can minimise
the hit - a bit like the buffering currently used in POV, but with the added
ability to be able to read & write to any part of the image at any time -
sucking a whole 1Mb off disk in one go, adjusting (i.e. reading the data
that's there an updating it or writing new data based on what's there) half
of it and then writing the whole 1Mb back in one go is far faster than
reading/writing 1/2Mb in single byte steps...
    Of course, direct memory access is quicker, but if you're trying to
anti-alias an image with a width of say 400,000,000 pixels (that's over 1GB
per line!) when you've only got 1/2GB of physical memory is going to fail
each and every time, unless you have read-write buffering... (yes, this is
an _extreme_ example, but it illustrates my point quite nicely - the same
applies to much smaller images once you take into account the memory used
for the scene description, program & O/S)

--
Pandora/Scott Hill/[::O:M:C::]Scorpion
Software Engineer.
http://www.pandora-software.com

Post a reply to this message