"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

Margus Ramst wrote:

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

I finally wrote my own macro with help from Chris H.  It is in p.t.s.-f.  I've had
fun trying measuring the volume of isosurfaces.  My POV-Ray-modelled blob man has a
volume of 342.69 units. This information could be helpful if I ever want to make him
float. The volume of intersection between my flocking spaceships and an obstacle
course they are negotiating will be the quickest, most precise feedback for
improving it.

> Anyway - strictly speaking, such tasks are
> usually expected of a modeller, not a renderer like POV.

Dogbert wags his tail at the slogan "POV-Ray is a renderer, not a modeller."

So which "modellers" will allow me to compute the volume of the noise3d isosurface
I'm working on? Enable me to use scripting to make my blob man walk across that
isosurface?  Which ones enable me to set up a camera path across an
isosurface-landscape based on the trace function to avoid trees and rolling hills?
Make a pushbot game?  Make marbles roll all over an isosurface? Do a missile defense
simulation using the trace function and hand-written flocking algorithms?
Which of the modellers that do all this are free, and functional (vs. povlab),  mind
you?

Yes, there are folks out there only interested in rendering store-bought DXF's,  but
pov is  _so much more_  to many people.  I don't mean to be insulting, but it's just
that I think some people have a wooden view of all the cool things this software can
do!

Push the envelope. Expand your horizon. Povray is the coolest toy there is.

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Fabien Mosen <fab### [at] skynetbe> wrote:
> :> 1) PROGRESSIVE RENDER.

> : You will be happy : it's already there !! Command-line options
> : +SP +EP ..

>   I think this is the main problem in WinPov. People don't care about command
> line options because they have everything (that is, they think they have
> everything) in menus and buttons. So they don't even read the documentation
> about command line options and thus miss this kind of basic options (which
> most command line users, like me, have used from the very beginning).
>   As we can see, they usually don't even know _where_ the command line
> options field is in WinPov.

To be fair, finding the command line option that does what you want in the
docs is a bloody pain sometimes.  I *knew* that there was a option for this
and it took me over an hour to find it.  Similarly, I knew you could
continue a previous render, but it took posting to the group to find out
what the option was.

That is one of the areas of the docs that I'd like to see cleaned up.  I'm
sure there are other command line options that I don't know about and have
no clue to look for that could be really useful.

Geoff

Post a reply to this message

Tom Melly <tom### [at] tomandlucouk> wrote:

> Hmm, I've always assumed that POV throws away any mosaic info without using
> it for any subsequent action (except for radiosity), and that any other
> renderer must do the same.

> After all, calculating that an area x pixels by x pixels is dark green on
> average does nothing helpful when it comes to calculating the colour of an
> individual pixel. The only exception I can think of is if the average is rgb
> 0 or rgb 1 (or whatever the appropriate equivalent is).

> If this isn't the case with either POV or Bryce, can someone give me an
> idiot's explanation of how the info is used?

> (and BTW that's an explanation FOR and idiot, not BY one)

I always assumed that it didn't antialias during previews.  So the color of
the pixel is the color of the upper left corner.  Each progression only does
the three other corners of the pixel.  The last render does all the pixels,
but with anti aliasing and the like.

I could easily be wrong on this, though.

Geoff

Post a reply to this message

On Mon, 11 Sep 2000 10:58:47 -0400, Greg M. Johnson wrote:
>Other question:
>What DOES pov do currently with Mosaic preview: are early traces thrown away?

Except for radiosity samples, yes.  If your Mosaic preview is taking long 
enough for this to matter, you're not using it in the manner in which it 
was intended.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message