1) PROGRESSIVE RENDER.
The one thing I like about Bryce is that it does a progressive render:
first shows you a 40 x 30 render of your scene, then a 160 x 120, and so
on up to the resolution you're asking for. When positioning my camera, I
often want to do something like this. If I have a really complex object
or special effect, I have to wait a long time to see the "feet" of my
image just to see if it's positioned right.   I suppose I could change
my quickres.ini file to include these scenes and do the extra dozen
mouseclicks each time to see a progressively greater resolution, but
isn't that what we have computers for?

2) VOLUME
I'd like to be able to know the volume of an object.

Post a reply to this message

"Greg M. Johnson" wrote:
> 
> 1) PROGRESSIVE RENDER.

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

> 2) VOLUME

For simple primitives, knowing the volume is easy.  For more
complex stuff, you could write a #macro that samples the volume
of an object, using the "object" pattern (in MegaPOV).

Fabien.

Post a reply to this message

Fabien Mosen wrote:

> "Greg M. Johnson" wrote:
> > 1) PROGRESSIVE RENDER.
>
> You will be happy : it's already there !! Command-line options
> +SP +EP ..

Could you please tell me the menu for the Windows version and the phrase
I could add to POVRAY.INI?

>
> > 2) VOLUME
>
> For simple primitives, knowing the volume is easy.  For more
> complex stuff, you could write a #macro that samples the volume
> of an object, using the "object" pattern (in MegaPOV).
>
> Fabien.

I can imagine how to do this with a few zillion trace calls and counting
cubes, but not immediately how to do with object pattern.

Post a reply to this message

--

Ian

Inkwell: Ian's Homepage
http://www.topcities.com/cartoon/inkwell/index.htm
"Greg M. Johnson" <gre### [at] my-dejanewscom> wrote in message
news:39B79C30.E480F2D9@my-dejanews.com...
> 1) PROGRESSIVE RENDER.

What's wrong with mosaic preview?? from memory its +sp in the .ini file
followed by a multiple of 4.  +sp 32 for example.


--

Ian

Inkwell: Ian's Homepage
http://www.topcities.com/cartoon/inkwell/index.htm

Post a reply to this message

Ian Witham wrote:

> What's wrong with mosaic preview?? from memory its +sp in the .ini file
> followed by a multiple of 4.  +sp 32 for example.

Wow! This is neat!

For us non-switch-typing mortals, we would add

Preview_Start_Size=4

to POVRAY.INI,

Post a reply to this message

that's why it's a good idea to have a printed version of the docs and to
read them once a month.  there's always something new to learn.

"Greg M. Johnson" wrote:
> 
> Ian Witham wrote:
> 
> > What's wrong with mosaic preview?? from memory its +sp in the .ini file
> > followed by a multiple of 4.  +sp 32 for example.
> 
> Wow! This is neat!
> 
> For us non-switch-typing mortals, we would add
> 
> Preview_Start_Size=4
> 
> to POVRAY.INI,

Post a reply to this message

"Greg M. Johnson" <gre### [at] my-dejanewscom> wrote in message
news:39B7AFF0.B38E4942@my-dejanews.com...

> Wow! This is neat!
>
> For us non-switch-typing mortals, we would add
>
> Preview_Start_Size=4
>
> to POVRAY.INI,
>

In megaPov, Mosaic preview doesn't work with radiosity enabled.... and even
if you turn radiosity off, the preview won't work until you restart MegaPov.
I'd call that a bug ;-)

sorry just a random rant.....

--

Ian

Inkwell: Ian's Homepage
http://www.topcities.com/cartoon/inkwell/index.htm

Post a reply to this message

I would really like that POV-4 had associative arrays of heterogeneous
elements. For example:

arr["location"] = <1,1,1>;
arr["texture"] = texture { ... }
arr["show"] = true;

etc.

Why?

Well, with this kind of containers it would be possible to fake object
oriented programming. For example

#macro MySmartBox_Create(this)
    this = assoc_array();
    this["location"] = 0;
    this["side"] = 1;
#end

#macro MySmartBox_Display(this)
    object {
        this["location"] - <Side/2, Side/2, Side2>,
        this["location"] + <Side/2, Side/2, Side2>
        texture {
            this["texture"]
        }
    }
#end

etc.

Having associative heterogeneous arrays + macros is all that is needed for
OOP in POVRay.

Post a reply to this message

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.

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

Post a reply to this message

In article <39B79FDF.16E6555D@my-dejanews.com>, 
gre### [at] my-dejanewscom wrote:

> I can imagine how to do this with a few zillion trace calls and counting
> cubes, but not immediately how to do with object pattern.

Use eval_pattern() with the object pattern, using the object you are 
calculating the volume of as the control object for the pattern. Check 
eval_pattern() multiple times in a 3D grid and use the results to 
calculate the volume.

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

Ron Parker <ron### [at] povrayorg> wrote in message
news:slr### [at] fwicom...
> Careful there, you'll get Warp all revved up again.  What you're talking
> about is structured programming, not OOP.

OOP requires encapsulation (only XXX_ macros work with a particular setup of
the associative array), inheritance (if the generic object has "location"
and "texture" attributes, macros working only with them with work with any
associative array) and polymophism, which in our context looks to me almost
useless. OO languages make things automatic but, given that thing called
SELF-DISCIPLINE, you can  develop OO code even with assembler... it is
"just" the way you look at it.

Obviously, if POVTeam throws in a GNU/Panorama-like OO scene description
language, I am not going to cry!!!!

Bye!!!!

P.S.: I proposed the associative array escamotage because it: 1) does not
require much code , 2) has the least impact upon POV description language
(if you don't like it, you just don't use it).

Post a reply to this message

"Greg M. Johnson" wrote:

> Fabien Mosen wrote:
>
> > "Greg M. Johnson" wrote:
> > > 1) PROGRESSIVE RENDER.
> >
> > You will be happy : it's already there !! Command-line options
> > +SP +EP ..
>
> Could you please tell me the menu for the Windows version and the phrase
> I could add to POVRAY.INI?

Sure, +SP +EP
INIs can take command-line options

--
David Fontaine   <dav### [at] faricynet>   ICQ 55354965
Please visit my website:  http://davidf.faricy.net/

Post a reply to this message

David Fontaine wrote:

> Sure, +SP +EP
> INIs can take command-line options

BTW, u can go to Render->Edit settings/render and specify cmnd-line ops if u
don't wanna mess with INIs.

--
David Fontaine   <dav### [at] faricynet>   ICQ 55354965
Please visit my website:  http://davidf.faricy.net/

Post a reply to this message

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.

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

Ian Witham <ian### [at] hotmailcom> wrote:
: What's wrong with mosaic preview?? from memory its +sp in the .ini file
: followed by a multiple of 4.  +sp 32 for example.

  Although the answer is perfectly correct, it should be said that this is
not the only way of doing it.

  For example I don't want the mosaic preview every time, but only when
doing test renders. I don't want mosaic preview in the final render because
it will increase considerably the rendering time.
  If the +sp option is in the .ini file, you'll get mosaic preview in each
render, thus increasing the total rendering time.

  I always use +sp in the command line field. It's easy to add and remove
and povray remembers it from session to session.
  The command line field is also handy to quickly add other options, such
as antialiasing (other than +a0.3), radiosity and so on.

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

Warp wrote:

>   For example I don't want the mosaic preview every time, but only when
> doing test renders. I don't want mosaic preview in the final render because
> it will increase considerably the rendering time.

How much does it increase it?
If it's just a little bit more bookkeeping for the software, no problem.

If it actually throws away the first few scans, then it's much less useful**1
and not like Bryce's progressive render as I understand it.

**1 If you're doing command line rendering, yeah, it's no biggie either type
+SP or not type it.  If you have to edit your INI each time, it's more of a
biggie.

Post a reply to this message

"Greg M. Johnson" <gre### [at] my-dejanewscom> wrote in message
news:39B8DAE9.B3A8B5D2@my-dejanews.com...
>
> How much does it increase it?
> If it's just a little bit more bookkeeping for the software, no problem.
>
> If it actually throws away the first few scans, then it's much less
useful**1
> and not like Bryce's progressive render as I understand it.
>

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)

Post a reply to this message

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

I would have assumed that the intelligent way to do it would be like below. I
assume it's how Bryce does it.

Say you're doing a 400 x 300. That's 1200 pixels.
First you shoot pixels AS IF it were a 40 x 30, where you choose by some
algorithm 1 pixel out of every block of 100.
Report the color of these pixels to the viewer as if it were ONLY a 40 x 30.
Now assume it's a 160  x 120,  shoot 3 pixels out of every block of ....... and
so on......

Post a reply to this message

> In megaPov, Mosaic preview doesn't work with radiosity enabled.... and even
> if you turn radiosity off, the preview won't work until you restart MegaPov.
> I'd call that a bug ;-)

eh? For me in MPov it's always there with radiosity enabled, in fact, I'd like
it *not* to be there; the best I can do is +SP2

Post a reply to this message

"Greg M. Johnson" <gre### [at] my-dejanewscom> wrote in message
news:39B8E565.987346EF@my-dejanews.com...
>
> Say you're doing a 400 x 300. That's 1200 pixels.
> First you shoot pixels AS IF it were a 40 x 30, where you choose by some
> algorithm 1 pixel out of every block of 100.
> Report the color of these pixels to the viewer as if it were ONLY a 40 x
30.
> Now assume it's a 160  x 120,  shoot 3 pixels out of every block of
....... and
> so on......

Doh! Of course. That makes sense. My notion wasn't even sensible - it would
take just as long (longer actually) to work out the average for a mosaic as
it would for a full render (since you have to calc. the rgb for each pixel
before you can average them).

Post a reply to this message

Greg M. Johnson <gre### [at] my-dejanewscom> wrote:
: How much does it increase it?

  Too much.

  It's probably a quite small percent of the rendering time in the final pass,
but even small slowdown is too much.

: If it actually throws away the first few scans, then it's much less useful**1
: and not like Bryce's progressive render as I understand it.

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

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

: **1 If you're doing command line rendering, yeah, it's no biggie either type
: +SP or not type it.  If you have to edit your INI each time, it's more of a
: biggie.

  When I use winpov I use the command line field. You can get it with ALT-C
if I remember correctly.

-- 
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:
: Say you're doing a 400 x 300. That's 1200 pixels.
: First you shoot pixels AS IF it were a 40 x 30, where you choose by some
: algorithm 1 pixel out of every block of 100.
: Report the color of these pixels to the viewer as if it were ONLY a 40 x 30.
: Now assume it's a 160  x 120,  shoot 3 pixels out of every block of ....... and
: so on......

  How do you calculate antialiasing here?

-- 
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 <39b903fb@news.povray.org> , Warp <war### [at] tagpovrayorg>  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 ;-)


     Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message
news:39b8bd2c@news.povray.org...
| 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).

Well, not so for us long time POV-Ray users.  Since there wasn't a Windows
version in the beginning I never actually left the command line behind and
still use it every day.  It's about the quickest way to make a custom change
in the rendered output I know of.

Bob

Post a reply to this message

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

"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

"Greg M. Johnson" wrote:
> So which "modellers" will allow me to compute the volume of the
> noise3d isosurface I'm working on?

> Yes, there are folks out there only interested in rendering
> store-bought DXF's,  but pov is  _so much more_  to many people.

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

Hear hear!

POV-Ray, when used together with a simple text-editor, is indeed a
modeller - just not with a graphical interface!

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated July 23)
/ Also visit http://www.povrayusers.org

Post a reply to this message

"Greg M. Johnson" wrote:
> 
> 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?

You've answered your own question. If POV script is your modeller, do it there
with a macro. POV already contains many features usually associated with
modellers, but implementing renderer-specific features should always have higher
priority.

-- 
Margus Ramst

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

Post a reply to this message

Geoff Wedig <wed### [at] darwinepbicwruedu> wrote:
: 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.

  I don't understand why it should be so difficult to find it in the docs.

  First you look at the section named "POV-Ray options". That looks like
a promising name.
  Under that there's a subsection names "Options reference". Well, it may
not be the first place for a newbie to look, but there's no any better
subsection than that.
  Under that a subsection named "Output options" should be the most obvious.
  Again another subsection named "Display output options" and there is
the "Mosaic preview" section.

  A quite long set of suboptions, but it took about 10 seconds for me to
find the correct one.

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

The measurement of volume depends on your definition of volume.

  Is volume the space enclosed by the surface?
  If so, the volume of a sphere should be larger than the volume of a
difference of a sphere and a smaller sphere.

  Is it the space enclosed by the outer contiguous surface?
  If so, how do you calculate the volume of this kind of object:

difference
{ box { -1,1 }
  sphere { 0, 1.1 }
}

(and suppose the same situation with more complex objects than a box and a
sphere, eg. a lathe and an isosurface.)

  Is it the space enclosed by the visible part of the outer surface?
  Something else?

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

it's even easier if you have a printed copy because your eyes and
fingers can scan faster than you can click through the help file.

Warp wrote:
> 
> Geoff Wedig <wed### [at] darwinepbicwruedu> wrote:
> : 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.
> 
>   I don't understand why it should be so difficult to find it in the docs.
> 
>   First you look at the section named "POV-Ray options". That looks like
> a promising name.
>   Under that there's a subsection names "Options reference". Well, it may
> not be the first place for a newbie to look, but there's no any better
> subsection than that.
>   Under that a subsection named "Output options" should be the most obvious.
>   Again another subsection named "Display output options" and there is
> the "Mosaic preview" section.
> 
>   A quite long set of suboptions, but it took about 10 seconds for me to
> find the correct one.
> 
> --
> 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

Warp wrote:

>   The measurement of volume depends on your definition of volume.

My measurement goes off of eval_pigment and the object pattern in MegaPov. I
leave the metaphysics up to those functions.

>   If so, how do you calculate the volume of this kind of object:
> difference { box { -1,1 }  sphere { 0, 1.1 }}

That's 2.609  cubic units, to a 0.25% precision.  See my macro.  I keep taking
smaller and smaller intervals until the difference between two sucessive
values for volume is less than a certain percentage.

> (and suppose the same situation with more complex objects than a box and a
> sphere, eg. a lathe and an isosurface.)

I tried this isosurface and got a volume of  288737 cubic units.

isosurface{
          function{y/290+noise3d(x*0.05,y**0.05,z**0.05)}
           accuracy 0.01
           threshold .21
           contained_by {sphere{0,100}}
        pigment{SeaGreen}
        finish{ambient 0.1}
        }


As I was tossing in my sleep last night, however, I realized that my macro can
easily handle any of the above discussed objects, but it's not very good for
its original purpose: determining *whether* the intersection between two
objects has zero volume. It's not that great if say I have one object with a
huge bounding box-- say a landscape-- and a bunch of tiny things.  But I guess
if one had enough patience or set a low bailout, it would work here OK too.

Post a reply to this message