I know the standard answer to this sort of thing is "code it yourself", 
but since I can't do that, I might as well get the idea out...

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? Granted, this wouldn't 
work with antialiasing, but I would think that for un-AA'd test renders 
(which should ideally be as fast as possible, right?) this would be a 
huge improvement; every rendering pass after the first one would be 
twice as fast!

While I'm at it.. does POV-Ray really compare rendered pixels to 
determine if AA needs to be performed? If so, how does it compare a 
given pixel to an unrendered one that's on its right or bottom? And if 
you're comparing rendered pixels, would it be any slower to render an 
un-AA'd image first, then perform a separate AA pass with that data? If 
not, why not rework the AA code, essentially extending the "mosaic 
rendering" concept to the subpixel level? Would this be a bitch to 
implement?

-Xplo

Post a reply to this message

> huge improvement; every rendering pass after the first one would be
> twice as fast!

I think this should only be 33% as fast if I understand it.  For each new
pass you would calculate 3 new pixels + reuse one old one for every square
of 4 pixels.   4/3=1.33

-tgq

Post a reply to this message

TinCanMan wrote:
>>huge improvement; every rendering pass after the first one would be
>>twice as fast!
> 
> I think this should only be 33% as fast if I understand it.  For each new
> pass you would calculate 3 new pixels + reuse one old one for every square
> of 4 pixels.   4/3=1.33

Oh, you're right. Bad math on my part. D'oh.

Still, 33% is a pretty significant boost.

-Xplo

Post a reply to this message

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...

-- 
#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

Wasn't it Warp who 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...
>

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.

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 also suspect that the half-pixel fix (change 1340) might possibly be
related to the way that antialiassing works, and might need to be
addressed again.

None of these would be showstoppers, but would require careful
consideration and extra programming effort.

I also suspect that an antialliassing algorithm that really did look in
all four directions would take longer to render, and produce a result
that looks worse (or at least no better) than the existing algorithm.

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. The suggested algorithm would
also supersample the pixel that has the colour transition on its bottom
or right. 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.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

Xplo Eristotle wrote:

> TinCanMan wrote:
> 
>>> huge improvement; every rendering pass after the first one would be
>>> twice as fast!
>>
>>
>> I think this should only be 33% as fast if I understand it.  For each new
>> pass you would calculate 3 new pixels + reuse one old one for every 
>> square
>> of 4 pixels.   4/3=1.33
> 
> 
> Oh, you're right. Bad math on my part. D'oh.
> 
> Still, 33% is a pretty significant boost.


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

Post a reply to this message

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