Mike, I'm wondering how this works for anything other than a sphere of 0,1 ,
and I'm trying to figure out how the trace function doesn't flake out when
you "miss" the object completely.

Consider:
http://news.povray.org/povray.text.scene-files/thread/%3C39bc2947%40news.povray.org%3E/?ttop=203039&toff=300



--
Greg M. Johnson

Post a reply to this message

Just a suggestion: adaptive integration. Recursively subdivide the object
into octants, comparing the volume calculated from each subdivision with
the previous stage, and stopping subdivision when the difference in
calculated volumes drops below a certain level.

I've used this technique succesfully in 2D, I don't see any reason for it
not to work in 3D. Adaptive integration is most efficient when each stage
can reuse the results from the previous stage.

Post a reply to this message

Wasn't it gregjohn who wrote:
>Mike, I'm wondering how this works for anything other than a sphere of 0,1 ,

It works for any convex object that fits inside the unit sphere.
For objects that don't fit into the unit sphere you could use min_extent
and max_extent of the object.

>and I'm trying to figure out how the trace function doesn't flake out when
>you "miss" the object completely.

When it misses, trace() returns P1 = <0,0,0>and P2 = <0,0,0>, so 
(P1.z - P2.z)*Area is zero, and that line adds nothing to the volume.

I could have got trace() to return a normal and checked that in the
documented manner to determine if trace() had missed, but it's probably
more efficient to just add the zero.

(It might possibly be more efficient to check to see if the trace() in
one direction hits, and only perform the second trace() if the first one
succeeds, but I was writing it in the middle of the night and couldn't
be bothered with such fine points.)

>Consider:
>http://news.povray.org/povray.text.scene-files/thread/%3C39bc2947%40news.povray.
>org%3E/?ttop=203039&toff=300

I guess that approach might work for concave objects too.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

Will scanning the object (in X, Y and Z) with the inside() function do what
you want? I've used that approach to compute the centre of mass for things,
I don't think it's much different. You can easily modify it to do the
adaptive subdivision thing as well.

Post a reply to this message

> What is the best method in POV-Ray for finding the
> volume of a simple convex (that is, no hollows or cavities)
> object that is the intersection of two other objects?


Out of curiosity, why?

People ask this question a lot, but I've never found it necessary myself.

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

I've been interested in using a method like this for collision detection of
oddly-shaped objects...you know, find the volume of the intersection of the
two objects...if it's not zero, then they've collided.  There's probably a
more mathematically correct way of doing it, but often it turns out I can't
be bothered to figure out the necessary maths for doing it "right" when an
approximation will work almost as well...

Cheers,
Joe

Post a reply to this message

"Slime" wrote
> Out of curiosity, why?

In this specific instance, my sailboat was destroyed a couple
of months ago, and I've salvaged its lead-filled keel. Getting
it weighed (~1500lbs) has proved problematic, but I've taken
measurements, can model its shape, and wanted to estimate
its weight using the density of lead.

A longer-term "why" is that I'm interested in modeling objects
and then create them physically. Rather than develop mathematical
models independently of POV-Ray (say in Excel), wanted a
general approach for estimating volume of complex shapes.

For example, I want to design a series of cascading bowl-shapes
for a water feature in a garden, define shapes, sizes, thicknesses,
etc., and then cast them in concrete. It would be cool to get
a readout of volume of concrete needed and the resulting cast
weight.

--Chris

Post a reply to this message

Among other things, Tom York saw fit to write:

> Will scanning the object (in X, Y and Z) with the inside() function do
> what you want? I've used that approach to compute the centre of mass for
> things, I don't think it's much different. You can easily modify it to do
> the adaptive subdivision thing as well.

Sometimes, some kind of "Monte Carlo integration" could work better. It's
basically the same, but you scan the volume randomly. In the limit, if the
bounding shape is scanned homegeneously:

Ni/Nt = Vo/Vs

Nt -> Number of points tested
Ni -> Number of points inside the object
Vo -> Volume of the object
Vs -> Volume of the bounding shape

The good thing is you can stop testing points when you want (based on time,
precision, number of points), instead of being "constrained" to sweeping
the whole grid you set up at the beginning.

-- 
light_source{9+9*x,1}camera{orthographic look_at(1-y)/4angle 30location
9/4-z*4}light_source{-9*z,1}union{box{.9-z.1+x clipped_by{plane{2+y-4*x
0}}}box{z-y-.1.1+z}box{-.1.1+x}box{.1z-.1}pigment{rgb<.8.2,1>}}//Jellby

Post a reply to this message

Hi all,

I experimented with finding the area of a circle, based on a suggestion
in response to my original post, mistakenly placed in povray.programming.

I did 1000 samples, calculated Ni/Nt (see below), and then averaged 100 runs.
After 100K iterations, the error was ~1%, which didn't seem accurate enough.
I dimly recall that there's a statistical method for developing a weighted
average based on the mean of the samples. After searching for about
an hour, moved on to Mike Williams method (the first response to my
original post in povray.general), which pretty much nailed it for my purposes.
Working on coding a generalized macro that sets the initial bounding box to
the extents of the object, and can (hopefully) handle simple concavities,
internal voids, and rejects internal surfaces.

>>>Concerning this last issue, I had a question: when you do a union of
two objects that results in an internal surface, would trace() stop at the
internal surface? Using a 2D example, if you do a union of two overlapping circles,
you get two arcs that are inside the combined object. Probably should just
do the test rather than asking a general question...but would it be necessary
to use merge rather than union?

--Chris

||||| www.kinata.net web design and hosting

"Jellby" <me### [at] privacynet> wrote in message news:4vq### [at] badulaqueunexes...
> Among other things, Tom York saw fit to write:
>
>> Will scanning the object (in X, Y and Z) with the inside() function do
>> what you want? I've used that approach to compute the centre of mass for
>> things, I don't think it's much different. You can easily modify it to do
>> the adaptive subdivision thing as well.
>
> Sometimes, some kind of "Monte Carlo integration" could work better. It's
> basically the same, but you scan the volume randomly. In the limit, if the
> bounding shape is scanned homegeneously:
>
> Ni/Nt = Vo/Vs
>
> Nt -> Number of points tested
> Ni -> Number of points inside the object
> Vo -> Volume of the object
> Vs -> Volume of the bounding shape
>
> The good thing is you can stop testing points when you want (based on time,
> precision, number of points), instead of being "constrained" to sweeping
> the whole grid you set up at the beginning.
>
> -- 
> light_source{9+9*x,1}camera{orthographic look_at(1-y)/4angle 30location
> 9/4-z*4}light_source{-9*z,1}union{box{.9-z.1+x clipped_by{plane{2+y-4*x
> 0}}}box{z-y-.1.1+z}box{-.1.1+x}box{.1z-.1}pigment{rgb<.8.2,1>}}//Jellby

Post a reply to this message

Chris Kinata nous apporta ses lumieres en ce 2005-09-28 14:26:
> Hi all,
> 
>
> two objects that results in an internal surface, would trace() stop at the
> internal surface? Using a 2D example, if you do a union of two overlapping circles,
> you get two arcs that are inside the combined object. Probably should just
> do the test rather than asking a general question...but would it be necessary
> to use merge rather than union?
> 
> --Chris
> 
> 
A merge only remove unneeded internal surfaces, and generaly increase the render time.
It's used to 
remove unwanted internal surfaces inside complex transparent objects. It's a variation
of an union, 
and is unsuited in the case of an intersection or difference. The trace function will
stop at the 
first surface it encounter, just like when you render an opaque object.

-- 
Alain
-------------------------------------------------
Beware of low-flying butterflies.

Post a reply to this message