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