Warp wrote:

>   Firstly: Why would you want a progressive render in the final image?

I can look at the first few seconds and then walk away.
Without a progressive render along the way, I would have to decide it's OK, then
change my POVRAY.INI (or --gasp-- use command line rendering)  and then render.


>   Secondly: With progressive render you can't use antialiasing.

You're obviously more informed than I, but must this be true?

AA happens by comparing pixel colors to those around it. If there is too much
difference, it sends out new pixels, right?  So this can be done anytime at all.
Bryce does (suggests to the user) this at the end after the whole image is done.

Post a reply to this message

"Greg M. Johnson" wrote:
> 
> 2) VOLUME
> I'd like to be able to know the volume of an object.

Finding the exact volume is relatively easy for (closed) triangle meshes and
some primitives, but in many other cases it is very difficult. IMO it would only
be feasible if tessellation were implemented (and the volume found for the
approximated mesh representation). Anyway - strictly speaking, such tasks are
usually expected of a modeller, not a renderer like POV.

-- 
Margus Ramst

Personal e-mail: mar### [at] peakeduee
TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
:>   How do you calculate antialiasing here?

: You just continue doing it for imaginary sub-pixels, and then average them.
: It is no great anti-aliasing, but it still works.  Of course there is some
: cost of memory attached to it, and other restrictions apply ;-)

  And it would be incredibly slow. Like using always +a0 (that is,
supersampling is calculated for every pixel).

  The idea behind a non-zero antialiasing threshold is that it usually speeds
up the rendering a lot. In most simple images only a small percent of the
image has to be supersampled. Even in complex images there usually is no
need to supersample all the pixels.
  Of course the threshold needs that contiguous pixels are calculated.

-- 
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 <gre### [at] my-dejanewscom> wrote:
: I can look at the first few seconds and then walk away.
: Without a progressive render along the way, I would have to decide it's OK, then
: change my POVRAY.INI (or --gasp-- use command line rendering)  and then render.

  You sound like using the command line field would be harder than editing
an ini file.

:>   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?

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

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

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.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Chris Huff wrote:
> 
> 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.

I for one would like to see (using the Win version, but the suggestion
is valid overall) a permanent command-line area, where I could type 
commands without popping a dialog box.  I also would like to be able
to have the "resolution list" permanently unrolled (in the form of a
floating element).

The Team said they were doing some GUI changes for 3.5, so wait and
see..

Fabien.

Post a reply to this message

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