Warp wrote:

> :>   Secondly: With progressive render you can't use antialiasing.
> : You're obviously more informed than I, but must this be true?
>   Ok, it's not true. You can use antialiasing, but only for every pixel.
> That is, your image will get (by default) 9 times slower to render. That is,
> if your scene renders in 1 hour without antialiasing, it will take
> approximately 9 hours with antialiasing.
> : AA happens by comparing pixel colors to those around it. If there is too much
> : difference, it sends out new pixels, right?
>   Yes, but if there are no nearby pixels, how can you know if the current
> pixel has to be antialiased or not?

Okay, this is probably like a caveman who's used a phaser a week arguing with the
Starfleet engineer who designed it, but here goes:

Bryce renders aren't  THAT slow, are they, and the image that evolves on the screen
suggests that the anti-aliasing that occurs only happens at the very end.  This
scenario of "no nearby pixels" would be a bigger problem if the AA occurred line by
line rather than at "the end".  I just cannot see how it takes more time, you've got
to do the comparison sometime, right?


>   Also continuing an interrupted render may cause problems with this kind
> of progressive rendering.

That's actually something I've never even considered doing.

Post a reply to this message

Warp wrote:
> 
> Greg M. Johnson <gre### [at] my-dejanewscom> wrote:
> 
> : >   Secondly: With progressive render you can't use antialiasing.
> 
> : You're obviously more informed than I, but must this be true?
> 
>   Ok, it's not true. You can use antialiasing, but only for every pixel.
> That is, your image will get (by default) 9 times slower to render. That is,
> if your scene renders in 1 hour without antialiasing, it will take
> approximately 9 hours with antialiasing.
> 
> : AA happens by comparing pixel colors to those around it. If there is too much
> : difference, it sends out new pixels, right?
> 
>   Yes, but if there are no nearby pixels, how can you know if the current
> pixel has to be antialiased or not?

From what I understand, POVRay does antialiasing by subsampling
individual pixels, not by interpolation.. so progressive rendering
shouldn't have any effect on it. Also, why on earth would you want to
antialias anything but the final pass anyway?

-Xplo

Post a reply to this message

On 7 Sep 2000 16:15:18 -0400, Ron Parker wrote:
>On Thu, 7 Sep 2000 22:17:53 +0200, Alessandro Coppo wrote:
>>
>>Well, with this kind of containers it would be possible to fake object
>>oriented programming. For example
>
>[...]
>
>>Having associative heterogeneous arrays + macros is all that is needed for
>>OOP in POVRay.
>
>Careful there, you'll get Warp all revved up again.  What you're talking
>about is structured programming, not OOP.

Nope. "Structured Programming" doesn't have anything to do with having a
"struct" or "record" data type (which is what Alessandro is simulating
with an associative array here). It is about having structure in the
flow of control: In structured programming each program consists of
nested blocks, each of which can only be entered at the top and left at
the bottom. Basically this forbids goto, return (except at the end of a
procedure) and alternative entry points. The habit of indenting inner
blocks is also heavily coupled with structured programming.

The opposite of structured programming is "spaghetti code".

	hp

-- 
   _  | Peter J. Holzer    | Nicht an Tueren mangelt es,
|_|_) | Sysadmin WSR       | sondern an der Einrichtung (aka Content).
| |   | hjp### [at] wsracat      |    -- Ale### [at] univieacat
__/   | http://www.hjp.at/ |       zum Thema Portale in at.linux

Post a reply to this message

On 9 Sep 2000 16:08:40 -0400, Warp wrote:
>Greg M. Johnson <gre### [at] my-dejanewscom> wrote:
>:> Secondly: With progressive render you can't use antialiasing.
>
>: You're obviously more informed than I, but must this be true?
>
>  Ok, it's not true. You can use antialiasing, but only for every
>  pixel.

This is also not true. After you have rendered the whole frame without
AA, you can "refine" only those pixels which differ more than some
threshold from their neighbours.

>: AA happens by comparing pixel colors to those around it. If there is
>: too much difference, it sends out new pixels, right?
>
>  Yes, but if there are no nearby pixels,

Every pixel has at least 3 nearby pixels.

>  Also continuing an interrupted render may cause problems with this
>kind of progressive rendering.

True. You would need a file format which lets you determine exactly
where you left off. For example, with PNG, you could use the alpha
channel to store info about whether the pixel has already been computed.

	hp

-- 
   _  | Peter J. Holzer    | Nicht an Tueren mangelt es,
|_|_) | Sysadmin WSR       | sondern an der Einrichtung (aka Content).
| |   | hjp### [at] wsracat      |    -- Ale### [at] univieacat
__/   | http://www.hjp.at/ |       zum Thema Portale in at.linux

Post a reply to this message

"Chris Huff" <chr### [at] maccom> wrote in message
news:chrishuff-064EC3.15262009092000@news.povray.org...
> In article <39ba98c8@news.povray.org>, Warp <war### [at] tagpovrayorg>
> wrote:
>
> >   You sound like using the command line field would be harder than
> > editing an ini file.
>
> I personally prefer the POV-Ray Mac way: go to Render Settings, either
> by going to the edit menu or by using the Cmnd-Y shortcut. Choose the
> "Preview" pane, if it isn't already up. If you want a mosaiac preview,
> check the box for it and adjust the sliders to the start and end sizes.
> Save preferences and render.

Stop it, you're making me miss my Mac, which I no longer have :-( Pov-Ray
for Mac-OS is just so much cooler than windows POV-Ray....  I especially
miss the output straight to QuickTime.

Post a reply to this message

"Modules" could be better.

  As I have already said elsewhere, programming languages using modules but
which are not OO languages (such as Modula2) support structures that look
a lot like object-oriented ones, however without being an OO language.

  To be a truely OO language, the language has to support inheritance and
dynamic binding (besides all the stuff that modules support of course).

  It's kind of silly to talk about OO features when there are no mention
about those two things.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Greg M. Johnson <"gregj;-)56590\""@aol.c;-)om> wrote:
: Bryce renders aren't  THAT slow, are they, and the image that evolves on the screen
: suggests that the anti-aliasing that occurs only happens at the very end.

  Well, that's a possible solution. First the image is calculated as without
antialiasing and then the extra calculations are made for the pixels that
need it.
  Not a bad solution although you'll need to keep all the information about
the image in memory. The color components of the final image (before writing
to the final image format) are handled with floats. If a float is 4 bytes
long in most systems and there are 3 color components (4 if we are using
alpha channel) and our image is 1024x768, that would take 9 Megs (12 if using
alpha) of memory.
  Well, we have plenty of memory.

:>   Also continuing an interrupted render may cause problems with this kind
:> of progressive rendering.

: That's actually something I've never even considered doing.

  You are not the only povray user in the world :)

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Xplo Eristotle <inq### [at] unforgettablecom> wrote:
: From what I understand, POVRay does antialiasing by subsampling
: individual pixels, not by interpolation..

  Yes, but povray doesn't antialias every pixel. Povray decides whether
a certain pixel needs antialiasing or not by looking at the nearby pixels:
If the current pixel differs too much from the nearby pixels, the current
is antialiased.
  This is why your render is not 9 times longer when using antialiasing
(which it will be by default if there's no aa threshold used).

: so progressive rendering
: shouldn't have any effect on it.

  When you calculate one pixel in an early step of the progressive rendering,
it will not have nearby pixels and thus you will not know if it needs to
be antialiased or not.

: Also, why on earth would you want to
: antialias anything but the final pass anyway?

  If you calculate antialiasing in the final step you'll have to recalculate
the pixels that need antialiasing and which weren't antialiased in the
previous passes (for the reason I described above).

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Peter J. Holzer <hjp### [at] sikituwsracat> wrote:
: This is also not true. After you have rendered the whole frame without
: AA, you can "refine" only those pixels which differ more than some
: threshold from their neighbours.

  You are right. This, however, needs that the info of the whole image is
kept in memory for the final antialiasing pass.
  Not an impossible solution, though.

:>  Yes, but if there are no nearby pixels,

: Every pixel has at least 3 nearby pixels.

... which are yet to be calculated when we are in an earlier step of a
progressive render.

: True. You would need a file format which lets you determine exactly
: where you left off. For example, with PNG, you could use the alpha
: channel to store info about whether the pixel has already been computed.

  Not a good solution if you want to use the alpha channel of the final
image for transparency information (possible in povray with option +ua).

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Again, I ask with respectful ignorance.

Pov can render all pixels once with no AA  and then store to HDD or to memory.
Then it goes through the collection, if it finds too much difference, it resamples
some
pixels along the way.

Is the objection that:
1) loading in and out of HDD is too slow, or
2) storing an entire big image takes up too much memory.

Other question:
What DOES pov do currently with Mosaic preview: are early traces thrown away?

Post a reply to this message