Is there a way to calculate and/or export the internal volumes of the finite
CSG objects in a POV-Ray scene?

If not, are there any CAD/CAM translators that can take a .pov file as
input?

I realize this isn't what the program was designed for, but figued it
couldn't hurt to ask.  It seems like the kind of thing somebody might have
thought of before me.

Thanks,

Jay

Post a reply to this message

OJCIT wrote:
> Is there a way to calculate and/or export the internal volumes of the finite
> CSG objects in a POV-Ray scene?

<http://tag.povray.org/povQandT/languageQandT.html#wireframes>

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> OJCIT wrote:
> > Is there a way to calculate and/or export the internal volumes of the finite
> > CSG objects in a POV-Ray scene?
>
> <http://tag.povray.org/povQandT/languageQandT.html#wireframes>

Thanks for the quick response, but that's not quite what I meant.  I don't
need to export the surfaces, but I was wondering if there were a way to get
the numerical volume of each solid entity in my scene (i.e., if I filled
them with water, how much would they hold?).  For this purpose I'm only
talking about discrete primitives and objects created by union and
difference operations among them.

For example, I might have a model with a cylinder with a box subtracted from
it, and want to know the resulting volume.  Since the SDL allows much more
complexity than what I use it for, and since there is seamless integration
of infinite primitives, I wouldn't think that's a number that gets computed
in the normal course of things.

My limited understanding seems to be that ray tracers are more interested in
surfaces than interior volumes, and that there's not a concept of internal
mass or material, except for the purposes of diffraction, translucence,
etc.  If photons don't need to know it, I'm guessing it doesn't get
computed.

Post a reply to this message

OJCIT nous apporta ses lumieres en ce 09-01-2007 16:40:
> Thorsten Froehlich <tho### [at] trfde> wrote:
>> OJCIT wrote:
>>> Is there a way to calculate and/or export the internal volumes of the finite
>>> CSG objects in a POV-Ray scene?
>> <http://tag.povray.org/povQandT/languageQandT.html#wireframes>

> Thanks for the quick response, but that's not quite what I meant.  I don't
> need to export the surfaces, but I was wondering if there were a way to get
> the numerical volume of each solid entity in my scene (i.e., if I filled
> them with water, how much would they hold?).  For this purpose I'm only
> talking about discrete primitives and objects created by union and
> difference operations among them.

> For example, I might have a model with a cylinder with a box subtracted from
> it, and want to know the resulting volume.  Since the SDL allows much more
> complexity than what I use it for, and since there is seamless integration
> of infinite primitives, I wouldn't think that's a number that gets computed
> in the normal course of things.

> My limited understanding seems to be that ray tracers are more interested in
> surfaces than interior volumes, and that there's not a concept of internal
> mass or material, except for the purposes of diffraction, translucence,
> etc.  If photons don't need to know it, I'm guessing it doesn't get
> computed.


You can't get the volume of an object directly. You can calculate it for a 
primitive, using the trigonometric formulaes.
Obvious for a box, a cylinder, a torus or a sphere, easy for most simple solids.
It would be a real headache for a blob with more than 1 components...
You can only gues it for SCG objects in non-trivial cases, you can hardly know 
what percentage of any object actualy add or substract from the total volume.

-- 
Alain
-------------------------------------------------
If you pick up a starving dog and make him prosperous, he will not bite you; 
that is the principal difference between a dog and a man.

Mark Twain

Post a reply to this message

> Is there a way to calculate and/or export the internal volumes of the 
> finite
> CSG objects in a POV-Ray scene?

Using extents of an object you can calculate the
volume of the bounding box, then use a large number of
random point samples within the bounding box to determine
the percent of samples that are inside the object, then
the volume can be estimated to be that percent of the
bounding volume. This is sort of like filling a real object
with water then measuring the water.

#include "rand.inc"
#macro volume(Obj)
   #local mn = min_extent(Obj);
   #local mx = max_extent(Obj);
   #local rs = seed(1);
   #local in = 0;
   #local lp = -1;
   #local p = -2;
   #local n = 0;
   #while ( abs(p-lp) > 0.0001)
      #local lp = p;
      #local c = 0;
      #while (c < 5000)
         #local r = VRand_In_Box(mn, mx, rs);
         #local in = in + inside(Obj,r);
         #local c=c+1;
         #local n=n+1;
      #end
      #local p = in/n;
   #end
   #local result = p*(mx.x-mn.x)*(mx.y-mn.y)*(mx.z-mn.z);
   (result)
#end

Post a reply to this message

Tim Attwood <tim### [at] comcastnet> wrote:
> Using extents of an object you can calculate the
> volume of the bounding box, then use a large number of
> random point samples within the bounding box to determine
> the percent of samples that are inside the object, then
> the volume can be estimated to be that percent of the
> bounding volume.

  If you want any accuracy at all, it would take a very LONG time.

  I would estimate that getting one additional decimal of accuracy
(or whichever base is used) requires O(n^3) more points to be sampled.
You can figure out that that number grows quite fast.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Tim Attwood <tim### [at] comcastnet> wrote:
> > Using extents of an object you can calculate the
> > volume of the bounding box, then use a large number of
> > random point samples within the bounding box to determine
> > the percent of samples that are inside the object, then
> > the volume can be estimated to be that percent of the
> > bounding volume.
>
>   If you want any accuracy at all, it would take a very LONG time.
>
>   I would estimate that getting one additional decimal of accuracy
> (or whichever base is used) requires O(n^3) more points to be sampled.
> You can figure out that that number grows quite fast.
>
> --
>                                                           - Warp
If you take an average of m such tests, the standard deviation of errors
will be multiplied by 1/m^2, so that overall accuracy will rise rather
quickly. ;-)

Post a reply to this message

Warp wrote:
> Tim Attwood <tim### [at] comcastnet> wrote:
>> Using extents of an object you can calculate the
>> volume of the bounding box, then use a large number of
>> random point samples within the bounding box to determine
>> the percent of samples that are inside the object, then
>> the volume can be estimated to be that percent of the
>> bounding volume.
>
>  If you want any accuracy at all, it would take a very LONG time.
>
>  I would estimate that getting one additional decimal of accuracy
> (or whichever base is used) requires O(n^3) more points to be sampled.
> You can figure out that that number grows quite fast.

For objects that fill a reasonably high percentage of the bounding box (such 
as a sphere) it wouldn't be a big problem unless you really care about high 
accuracy. For other objects though, such as, say, a cylinder from <-1,-1,-1> 
to <1,1,1> with radius 0.01, testing all points (with some proximity) within 
the bounding box is extremely inefficient. However, pre-testing with trace 
lines within the bounding box parallel with one or more axes could be used 
to weed out by far the most points beforehand, and this would only be 
O(n^2).

Rune
-- 
http://runevision.com

Post a reply to this message

Rune wrote:
> For objects that fill a reasonably high percentage of the bounding
> box (such as a sphere) it wouldn't be a big problem unless you really
> care about high accuracy. For other objects though, such as, say, a
> cylinder from <-1,-1,-1> to <1,1,1> with radius 0.01, testing all
> points (with some proximity) within the bounding box is extremely
> inefficient. However, pre-testing with trace lines within the
> bounding box parallel with one or more axes could be used to weed out
> by far the most points beforehand, and this would only be O(n^2).

...in most common cases that is. It won't work for, say, a sphere with a 
slightly smaller sphere carved out of it.

Come to think of it, the tracing could be used iteratively to do the volume 
calculation in the first place. This would work in all cases and would only 
be O(n^2*m) where m represents the complexity of the object.

Rune
-- 
http://runevision.com

Post a reply to this message

Tim Attwood wrote:
>> Is there a way to calculate and/or export the internal volumes of the 
>> finite
>> CSG objects in a POV-Ray scene?
> 
> Using extents of an object you can calculate the
> volume of the bounding box, then use a large number of
> random point samples within the bounding box to determine
> the percent of samples that are inside the object, then
> the volume can be estimated to be that percent of the
> bounding volume. This is sort of like filling a real object
> with water then measuring the water.


A better way to sample the volume (although requiring external 
processing) may be to render a series of slices of the object and then 
sum the number of covered pixels in those images. This can be done using 
an object pattern mapped to a plane and animating the translation of the 
pattern along the axis perpendicular to the plane, much like a CAT-scan 
really.

-- 
Daniel Nilsson
going back to lurking mode...

Post a reply to this message