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

Daniel Nilsson wrote:
> 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.

This would require exactly the same amount of insideness tests as the 
suggestion by Tim Attwood; only they would be done during rendering instead 
of during parsing.

Rune
-- 
http://runevision.com

Post a reply to this message

Rune wrote:
> Daniel Nilsson wrote:
>> Tim Attwood 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. 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.
> 
> This would require exactly the same amount of insideness tests as the 
> suggestion by Tim Attwood; only they would be done during rendering instead 
> of during parsing.

Yes, that is true. But povray's built-in adaptive anti-aliasing will 
save some samples. Implementing adaptive sampling in SDL is probably not 
as fast.
Anyway, I don't think this is what the OP was looking for.

-- 
Daniel Nilsson
haven't really used povray for several years, still lurking here though

Post a reply to this message

Rune nous apporta ses lumieres en ce 10-01-2007 12:33:
> 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
What about a complex shape with another complex shape carved out of it, making a 
strange, one opening, hole?

-- 
Alain
-------------------------------------------------
Age is a very high price to pay for maturity.

Post a reply to this message

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

I ran a test on a half sphere that came out in 13 seconds
with an accuracy of about 0.3%
The half sphere should be 2/3 pi r cubed volume, 2.094
since I used a r of 1, and the estimate was 2.087

I ran a second test with the half sphere scaled up by 100
and got the same sort of result 13 seconds and 2087920,
so the adaptive loop in my volume estimate algorithm isn't
sensitive to object size.

I did a third test with a narrow cylinder (rotated so that the
bounding was larger), it was off by about 1.3% in 11 seconds.

If I remember my statistics right, it only takes a fixed number
of samples to accurately represent a larger population to
some confidence level, which is why you see the plus or minus
4% on a lot of news polls. So it should run about O(n) time, though
that time increases O(n^3) as you modify the algorithm to be more
accurate.

I could see that a narrow enough object might return
zero volume if the real volume is only a few percent of the
bounding box.

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?

Might be the same that Rune mentioned:
If you make the surface transparent and fill the interior with a uniformly
emitting medium, then the sum over the pixels of an orthographic rendering
should give you a reasonable approximation of the volume.

  Mark Weyer

Post a reply to this message

Mark Weyer <nomail@nomail> wrote:
> If you make the surface transparent and fill the interior with a uniformly
> emitting medium, then the sum over the pixels of an orthographic rendering
> should give you a reasonable approximation of the volume.

  How can a 2-dimensional projection of a 3-dimensional object give you
the volume of the object?

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Mark Weyer <nomail@nomail> wrote:
>> If you make the surface transparent and fill the interior with a
>> uniformly emitting medium, then the sum over the pixels of an
>> orthographic rendering should give you a reasonable approximation of
>> the volume.
>
>  How can a 2-dimensional projection of a 3-dimensional object give you
> the volume of the object?

Because each pixel's color represents the volume of the object contained 
within the confines of the area of the object that is behind that pixel? The 
volume-to-color mapping is non-linear though, so one would have to know or 
test the mapping used, but that should be quite simple.

Rune
-- 
http://runevision.com

Post a reply to this message

Rune schrieb:
> Warp wrote:
>> Mark Weyer <nomail@nomail> wrote:
>>> If you make the surface transparent and fill the interior with a
>>> uniformly emitting medium, then the sum over the pixels of an
>>> orthographic rendering should give you a reasonable approximation of
>>> the volume.
>>  How can a 2-dimensional projection of a 3-dimensional object give you
>> the volume of the object?
> 
> Because each pixel's color represents the volume of the object contained 
> within the confines of the area of the object that is behind that pixel? The 
> volume-to-color mapping is non-linear though, so one would have to know or 
> test the mapping used, but that should be quite simple.
> 
> Rune

I just had the same idea, ..., but the other way around.

white background, orthographic camera, cylindrical ligth, transparent
surface and a black color fade inside (light attenuation). I think this
would be even more accurate as the fade is calculated directly by the
length of the ray traveling inside the object, while with media you also
can influence the result by means of intervalls/samples parameter.

dave

Post a reply to this message

David El Tom wrote:
> I just had the same idea, ..., but the other way around.
>
> white background, orthographic camera, cylindrical ligth, transparent
> surface and a black color fade inside (light attenuation). I think
> this would be even more accurate as the fade is calculated directly
> by the length of the ray traveling inside the object, while with
> media you also can influence the result by means of
> intervalls/samples parameter.

Yes, I agree, except that I don't think you need any light source.

Rune
-- 
http://runevision.com

Post a reply to this message

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

It just occured to me that the object can be rotated and the bounding
box tested for minimum volume to reduce the bounding volume on long
narrow objects, it wouldn't do much for spikey things though.

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

So, if you start with a grid and trace across, measuring the surface 
locations
with the trace to determine the distance of the line that is inside the 
object
at each grid point and then average all the distances, then the average
divided by the depth of the bounding box should be the percentage of the
bounding volume that represents the object volume? Sort of like sticking
a bunch of long pins into it and measuring how much is inside? Wouldn't
some objects still squeeze thru the grid?

Post a reply to this message

Reducing the bound volume seems to keep the
errors smaller when estimating the object volume.

#macro reduce_bounding(Obj)
   #local num = 360;

   #local mn = min_extent(Obj);
   #local mx = max_extent(Obj);
   #local O = object{ Obj // center
      translate <-1*(mx.x-mn.x),-1*(mx.y-mn.y),-1*(mx.z-mn.z)>};
   #local BVol = (mx.x-mn.x)*(mx.y-mn.y)*(mx.z-mn.z);
   #local RotY = 0;
   #local c = 1;
   #while (c<num)
      #local OY = object{O rotate <0,(360/num)*c,0>};
      #local mn = min_extent(OY);
      #local mx = max_extent(OY);
      #local TV = (mx.x-mn.x)*(mx.y-mn.y)*(mx.z-mn.z);
      #if (BVol > TV )
         #local BVol = TV;
         #local RotY = (360/num)*c;
      #end
      #local c = c + 1;
   #end
   #local O = object{O rotate <0,(360/num)*RotY,0>};

   #local mn = min_extent(O);
   #local mx = max_extent(O);
   #local RotX = 0;
   #local c = 1;
   #while (c<num)
      #local OX = object{O rotate <(360/num)*c,0,0>};
      #local mn = min_extent(OX);
      #local mx = max_extent(OX);
      #local TV = (mx.x-mn.x)*(mx.y-mn.y)*(mx.z-mn.z);
      #if (BVol > TV )
         #local BVol = TV;
         #local RotX = (360/num)*c;
      #end
      #local c = c + 1;
   #end
   #local O = object{O rotate <(360/num)*RotX,0,0>};

   #local mn = min_extent(O);
   #local mx = max_extent(O);
   #local RotZ = 0;
   #local c = 1;
   #while (c<num)
      #local OZ = object{O rotate <0,0,(360/num)*c>};
      #local mn = min_extent(OZ);
      #local mx = max_extent(OZ);
      #local TV = (mx.x-mn.x)*(mx.y-mn.y)*(mx.z-mn.z);
      #if (BVol > TV )
         #local BVol = TV;
         #local RotZ = (360/num)*c;
      #end
      #local c = c + 1;
   #end
   #local O = object{O rotate <0,0,(360/num)*RotZ>};

   object{O}
#end

Post a reply to this message

"Tim Attwood" <tim### [at] comcastnet> 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).
>
> It just occured to me that the object can be rotated and the bounding
> box tested for minimum volume to reduce the bounding volume on long
> narrow objects, it wouldn't do much for spikey things though.
>
The shape of the object is irrelevant, for the algorithm you suggested, as
long as the pseudo-random number generator has "good properties". Likewise,
rotating the object to minimise the bounding box doesn't have any effect, on
average.[subliminal message] Of course, averaging the result over m tests
would increase the accuracy [/subliminal message]. Seriously, you don't
really need 5000 points in one go, you can cut that down up to a mere 30
points per sample, and select a number of m tests = 5000/n. n=100 seems
reasonale. Then average the result of the m tests.
> >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.
>
> So, if you start with a grid and trace across, measuring the surface
> locations
> with the trace to determine the distance of the line that is inside the
> object
> at each grid point and then average all the distances, then the average
> divided by the depth of the bounding box should be the percentage of the
> bounding volume that represents the object volume? Sort of like sticking
> a bunch of long pins into it and measuring how much is inside? Wouldn't
> some objects still squeeze thru the grid?
The trace will depend on the rounding POV-ray uses. If it doesn't use
banker's rounding, it will be over-(or under-)estimating systematically
each trace, resulting in an over(or under) estimate of the volume.
If the grid is too loose, and the object is complex, you might indeed loose
some volume.

Regarding media, suggested by others, I don't know much, but it seems to me
that the boundary of emitting media is brighter than the inside (is that
correct?), so that the method would be unsuitable for non-convex items.
Absorbing media, on the other hand, would suffer from the rounding method
mentioned above, and from the limited number of grays available. Not only
that, but for maximum accuracy (minimum inaccuracy, actually) you would
have to fine-tune the absorbtion value such that the furthest value is
exactly black.

Post a reply to this message

Rune nous apporta ses lumieres en ce 12-01-2007 20:24:
> David El Tom wrote:
>> I just had the same idea, ..., but the other way around.

>> white background, orthographic camera, cylindrical ligth, transparent
>> surface and a black color fade inside (light attenuation). I think
>> this would be even more accurate as the fade is calculated directly
>> by the length of the ray traveling inside the object, while with
>> media you also can influence the result by means of
>> intervalls/samples parameter.

> Yes, I agree, except that I don't think you need any light source.

> Rune
No. All you need is a ambient 1 white plane, or set background rgb 1

-- 
Alain
-------------------------------------------------
An organizer for the "Million Agoraphobics March" expressed disappointment in 
the turnout for last weekend's event.

Post a reply to this message

> The shape of the object is irrelevant, for the algorithm you suggested, as
> long as the pseudo-random number generator has "good properties". 
> Likewise,
> rotating the object to minimize the bounding box doesn't have any effect, 
> on
> average.

Objects that are a small percent of their bounding box volume
encounter a rounding error from the implementation of floating
point numbers. Minimizing the bounding volume for these objects
shifts the numbers to be larger and results in more accuracy.
A test I ran on a long narrow cylinder went from being off by
1.3% to 0.18% after rotating. It had no effect on objects that
fit well into their bounding box in the first place (0.3% off).

>...[subliminal message] Of course, averaging the result over m tests
> would increase the accuracy [/subliminal message]. Seriously, you don't
> really need 5000 points in one go, you can cut that down up to a mere 30
> points per sample, and select a number of m tests = 5000/n. n=100 seems
> reasonale. Then average the result of the m tests.

The average already uses all the samples.  The code just
checks the average every 5000 samples to decide if the
average is still changing. When the average stops changing
the sampling stops.  I tried smaller blocks but there can be
false stops and big errors. 5000 forces at least 10000
samples.  A fixed number of samples might be better.

> The trace will depend on the rounding POV-ray uses. If it doesn't use
> banker's rounding, it will be over-(or under-)estimating systematically
> each trace, resulting in an over(or under) estimate of the volume.

It isn't so much that the coordinates of the point that trace returns
is accurate, as that you know that all the points on the line from
the trace origin to the trace hit are either inside or outside the
object with only one test. So it might be possible that a few traces
can result in many fold the number of samples during the same
parsing time.

Post a reply to this message

These are some great ideas.  Thanks for all the responses.

-ojc

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>


The answer is yes!


I put some objects through my volume macro
( http://www.irtc.org/pipermail/irtc-l/2001-August/010802.html )

CASE ONE
First a sphere of radius 20!  I took the liberty of pasting the total debug
stream (slightly modified SDL from above).  The debug stream was outputting
time into the parse.

# of sects  VOLUME CALC

   3       45037.0370
   4       32000.0000
   5       41472.0000
   6       40296.2963
   7       33399.4169
   8       35000.0000
   9       34150.8916
  10       35328.0000
  11       35534.1848
  12       33777.7778
  13       34636.3223
 0:00:01 Parsing 1405K tokens
  14       34332.3615
  15       33962.6667
  16       34000.0000
 0:00:02 Parsing 2896K tokens
  17       33257.0731
  18       34150.8916
 0:00:03 Parsing 4381K tokens
  19       34477.3291
 0:00:04 Parsing 5872K tokens
  20       33792.0000
  21       34173.4154
 0:00:05 Parsing 7355K tokens
  22       33755.0714
 0:00:06 Parsing 8768K tokens
  23       33680.6115
 0:00:08 Parsing 11672K tokens
  24       33370.3704
 0:00:09 Parsing 13152K tokens
  25       33656.8320
 0:00:10 Parsing 14643K tokens
  26       33966.3177
 0:00:12 Parsing 17614K tokens
  27       33799.7257
 0:00:14 Parsing 20575K tokens
  28       33632.6531
 0:00:16 Parsing 23524K tokens
  29       33832.9575
 0:00:18 Parsing 26478K tokens
  30       33962.6667
 0:00:20 Parsing 29411K tokens
  31       33330.8717
 0:00:23 Parsing 33863K tokens
  32       33703.1250
 0:00:26 Parsing 38317K tokens
  33       33575.2010
 0:00:29 Parsing 42629K tokens
  34       33660.8997
 0:00:32 Parsing 46963K tokens
  35       33697.9592
 0:00:36 Parsing 52721K tokens
  36       33558.2990
 0:00:40 Parsing 58510K tokens
  37       33792.2729
 0:00:44 Parsing 64278K tokens
  38       33553.5792
 0:00:49 Parsing 71598K tokens
  39       33557.4099
 0:00:54 Parsing 78956K tokens
  40       33552.0000
 0:00:59 Parsing 86364K tokens
  41       33556.7969
 0:01:05 Parsing 95205K tokens
  42       33710.3984
 0:01:11 Parsing 103976K tokens
  43       33688.4048
 0:01:18 Parsing 114265K tokens
  44       33598.7979
 0:01:25 Parsing 124562K tokens
  45       33594.6447
 0:01:33 Parsing 136299K tokens
  46       33601.7095
 0:01:41 Parsing 148106K tokens
  47       33555.5705
 0:01:49 Parsing 159903K tokens
  48       33481.4815
 0:01:58 Parsing 173054K tokens
  49       33490.8074
 0:02:08 Parsing 187765K tokens
  50       33665.0240
 0:02:18 Parsing 202533K tokens
  51       33579.3624
 0:02:29 Parsing 218729K tokens
  52       33602.1848
 0:02:40 Parsing 234686K tokens
  53       33619.1621
 0:02:52 Parsing 252150K tokens
  54       33617.6396
 0:03:05 Parsing 270935K tokens
  55       33570.8129
 0:03:19 Parsing 291231K tokens
  56       33562.6822
 0:03:33 Parsing 311744K tokens
  57       33602.3068
 0:03:48 Parsing 333600K tokens
  58       33525.9338
 0:04:04 Parsing 357075K tokens
  59       33587.2314


CASE TWO
Now, M.I.M.E. Man, a complex blob with hundreds of components in the shape
of a person.


# sects       volume
   3           0.0000
   4           0.0000
   5           0.0000
   6           0.0000
   7           0.0000
   8           0.0000
 0:00:01 Parsing 347K tokens
   9           0.0000
  10           0.0000
  11           0.0000
 0:00:02 Parsing 862K tokens
  12           0.0000
  13        5634.5571
 0:00:03 Parsing 1370K tokens
  14       11278.3546
 0:00:04 Parsing 1878K tokens
  15       11003.6640
 0:00:05 Parsing 2380K tokens
  16        4533.3699
 0:00:06 Parsing 2883K tokens
  17        7558.9998
 0:00:08 Parsing 3884K tokens
  18        7429.1713
 0:00:10 Parsing 4881K tokens
  19        9023.9992
 0:00:12 Parsing 5879K tokens
  20       10831.7318
 0:00:14 Parsing 6872K tokens
  21       12030.2450
 0:00:17 Parsing 8360K tokens
  22       13369.6378
 0:00:20 Parsing 9848K tokens
  23       13226.6448
 0:00:23 Parsing 11332K tokens
  24       12536.7266
 0:00:27 Parsing 13307K tokens
  25       11883.9572
 0:00:32 Parsing 15781K tokens
  26       11973.4339
 0:00:36 Parsing 17757K tokens
  27       12264.0289
 0:00:42 Parsing 20720K tokens
  28       11278.3546
 0:00:48 Parsing 23684K tokens
  29       12943.0322
 0:00:54 Parsing 26640K tokens
  30       11691.3931
 0:01:01 Parsing 30082K tokens
  31       12465.9683
 0:01:09 Parsing 34018K tokens
  32       12088.9864
 0:01:20 Parsing 38515K tokens
  33       11539.6552
 0:01:31 Parsing 42857K tokens
  34       11653.4581
 0:01:42 Parsing 47839K tokens
  35       13714.4792
 0:01:55 Parsing 53366K tokens
  36       14593.0151
 0:02:09 Parsing 59566K tokens
  37       17718.3256
 0:02:23 Parsing 65886K tokens
  38       20078.3981
 0:02:41 Parsing 72856K tokens
  39       20660.0429
 0:02:57 Parsing 80019K tokens
  40       20116.0733
 0:03:09 Parsing 85049K tokens

The system choked here because I'd used up all the memory on the machine.

Post a reply to this message

> First a sphere of radius 20!  I took the liberty of pasting the total 
> debug
> stream (slightly modified SDL from above).  The debug stream was 
> outputting
> time into the parse.

The actual Volume of a sphere with a 20 unit
radius is 33510.3216

According to your test data the accuracy of
your estimations are similar to those from
the algorithm I used.

That is an interesting use of eval_pigment...
but aren't you just using it to test if a
point is inside the object?

seg  %Error
3    34.40
4     4.51
5    23.76
6    20.25
7     0.33
8     4.45
9     1.91
10    5.42
11    6.04
12    0.80
13    3.36
14    2.45
15    1.35
16    1.46
17    0.76
18    1.91
19    2.89
20    0.84
21    1.98
22    0.73
23    0.51
24    0.42
25    0.44
26    1.36
27    0.86
28    0.37
29    0.96
30    1.35
31    0.54
32    0.58
33    0.19
34    0.45
35    0.56
36    0.14
37    0.84
38    0.13
39    0.14
40    0.12
41    0.14
42    0.60
43    0.53
44    0.26
45    0.25
46    0.27
47    0.14
48    0.09
49    0.06
50    0.46
51    0.21
52    0.27
53    0.32
54    0.32
55    0.18
56    0.16
57    0.27
58    0.05
59    0.23

Post a reply to this message