/* Hi, friends and creators of POV-Ray


as "t" alone, and the letter following the "u" looks like a
greek beta, spoken as a sharp "s". If your computer doesn't know
it, use "ss" instead [ or "$" ;-) ].
Usually I'm called "Sputnik".

Please look at this and check it:

To create a drop, I used a quartic as described in the scene
below, and to see the effect of varying the threshold constant
T, I "differenced" this with a drop having T=0, which should
give an hollow object similar to a drop-shaped soap bubble.
But I saw strange effects I couldn't understand.

To show these effects, I prepared an environment with light,
a camera (one of 3), the coordinate axes (x/y/z, colored R/G/B),
a shadow-casting grey box, a flat box, and two scenes: the first
contains a difference of a drop and two planes, below it a full
drop for comparison. The second scene contains a difference of
two drops. A third (empty) scene is provided for your own
explorations.

Perhaps you gurus can render these scenes (simply copy this
*whole* text to POV-Ray - all non-SDL is a comment;
"320x240, No AA" is sufficient; 16 sec. at 533 MHz) and tell me
if you see what I see (WISIWYG: what I see is what you get?!):
_the_planes_use_a_larger_drop_to_cut_from_! (It seems to be a
drop with T increased by 0.0001: compare with the lower drop
Drop(T+0.0001).) T=-0.00003 even gives a visible cutting surface
*completely outside* the drop; the drop itself is invisible,
because the true intersection with the planes is empty.
The second scene (use #switch(2)) shows an coincident-surface-
effect on the surface of the outer drop.

Is this an error in my visual perception, a misunderstanding
of quartics/difference, a bug in all three computers mentioned
below, a problen of numerical accuracy or an error in POV-Ray
3.1g? Does this also happen with POV-Ray 3.5 (I haven't
installed it yet)?

Awaiting your comments

   Sputnik

fr### [at] computermuseumfh-kielde

P.S. Change the color of the yellow box to "rgbt<1,1,0,.7>",
use a "camera { location <0.002, 0.004, 0> look_at 0.002*y }",
select the empty scene by "#switch(3)" and look at the shadows
of the green cylinder: in my pictures they don't start at the
cylinder, but look as if the cylinder ends above the box. What
is going on there?
*/


/* ========================
=========================
===========

POV-Ray scene showing a bug (?) in a difference
with a drop-shaped quartic
using POV-Ray 3.1g.watcom.win32 on
- a Pentium-Pro-PC, 233 MHz, 32 MB, with Windows 95
- a Pentium-Laptop, 133 MHz, 40 MB, with Windows 95
- a Pentium-PC, 533 MHz, 1 GB, with Windows 2000 Professional



quartic for a lying drop along the x-axis ---------------------
(use a non-proportional font to see this ASCII-picture)

R^2 ^
    !  __                  ___
    ! /  \                /   \
  --+=---+---> x   =>   -=     )
  / 0    1\               \___/

-x^3*(x-1)+T = x^3-x^4+T = R^2 = (Radius at x)^2 >= y^2+z^2
x^4-x^3+y^2+z^2-T <= 0
T=0 => tip at <0, 0, 0>, bottom at <1, 0, 0>
T>0 => larger drop, T<0 => smaller drop
*/
#macro Drop ( T )
  quartic {
    <1, 0,0, -1, // x^4, x^3
    0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
    1, 0,0,0,0,0,0, 1, 0, -T > // y^2, z^2, 1
    sturm
    }
  #end//macro Drop


// transparent texture for drops ------------------------------

#declare Tex = 

  texture  { 

    pigment { color rgbt <.6, .7, 1, .5 > }
    finish { ambient .3 specular .2 }
    }


// lights and camera ------------------------------------------

light_source { <1, 1.5, -2>, rgb 1.5 }
light_source { <-1, 1, 1>, rgb 1.5 }

// look at the whole scene
//camera { location <1.2, 0.5, -0.5> look_at 0.7*x }

// closely look at the tip
camera { location <0.04, 0.05, -0.04> look_at 0.01*y }

// closely look at the tip from the other side
//camera { location <-0.065, 0.055, 0.055> look_at -0.01*x }


// auxiliary objects ------------------------------------------

box { -0.002, 0.002 texture { pigment { color rgbt <1,1,0,0> } } } 

cylinder { 0, 1.1*x, 0.0004 texture { pigment { color red 1 } } } 

cylinder { -y, y, 0.0004 texture { pigment { color green 1 } } } 

cylinder { 0, z, 0.0004 texture { pigment { color blue 1 } } }

box { <-0.049, -0.025, -0.005>, <-0.0491, 0.025, 0.005>
  texture { Tex }
  } 

box { <0.01, 0.034, 0>, <0.011, 0.035, 0.033>
  texture { pigment { color rgb .7 } }
  }

// the drops --------------------------------------------------

#switch ( 1 ) // 1: difference of drop and planes;
              // 2: difference of drops
              // 3: empty (for your experiments)


// SCENE 1: difference of drop and planes -----------
#case ( 1 )
  #declare T = 0.00003; // try  0.00003, -0.00003, 0.0001, -0.0001
  intersection {
    Drop ( T )
    plane { x, 0.03 }
    plane { -z, 0 }
    texture { Tex }
    translate 0.015*y
    }
  // drop with T+0.0001 for comparison
  object {
    Drop ( T+0.0001 )
    texture { Tex }
    translate -0.015*y
    }
  #break


// SCENE 2: difference of drops ---------------------
#case ( 2 )
  difference {
    Drop ( 0.0001 )
    Drop ( 0 )
    //plane { z, 0 } // that's what I wanted to do
    texture { Tex }
    }
  #break


// scene 3: this is the place for your experiments --
#case ( 3 )
  // ...
  #end//switch


// E N D ======================
=========================
=======

Post a reply to this message

> 
> Please look at this and check it:
> 
> To create a drop, I used a quartic as described in the scene
> below, and to see the effect of varying the threshold constant
> T, I "differenced" this with a drop having T=0, which should
> give an hollow object similar to a drop-shaped soap bubble.
> But I saw strange effects I couldn't understand.
> 
> [...]

In POV-Ray 3.5 try using:

#macro Drop ( T )   
  isosurface {
    function { pow(x, 4)-pow(x, 3)+y*y+z*z-T }    
    max_gradient 0.5 
    accuracy 0.0001
    contained_by { box { -0.06, 0.06 } }
  }     
#end//macro Drop

You might have to vary the container object and the max_gradient and
accuracy parameters to your specific configuration.

Concerning your observation: You should not expect the root solver to work
perfectly under all conditions.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 13 Aug. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

/* Hi, Christoph

I don't think the root solver is the problem, because it
works perfectly with, for example, standard spheres, but not
with the *same* spheres modeled by a poly.
I have continued to experiment with polys and I'm irritated
even more -- just look at my intersection of three orthogonal
semitransparent poly-planes. Even these _most_simple_ polys
create cutting-faces that are too large (by _exactly_ 0.0001 --
compare with the white sphere: the same value as with my drop).
Replace the polys by the equivalent planes and everything will
be perfect. Do you understand the shadows? Especially: where do
the small triangular "shark shadow" on the white sphere and the
big one at the bottom left corner of the picture come from? Not
to mention the bizarre patterns on the white box!

    Sputnik

P.S. The 'origin' of the checker pattern isn't <0, 0, 0>, it
is -- you guess it -- <0.0001, 0.0001, 0.0001>! Why? Also a
root solver accuracy? Where does this magic number come from?


fr### [at] computermuseumfh-kielde


*/
// VERY simple example of poly error
intersection {
  poly { 2, < 0,0,0, 1, 0,0,0,0,0,0 > sturm } // plane { x, 0 }
  poly { 2, < 0,0,0,0,0,0, 1, 0,0,0 > sturm } // plane { y, 0 }
  poly { 2, < 0,0,0,0,0,0,0,0, 1, 0 > sturm } // plane { z, 0 }
  texture  { 

    pigment { color rgbt < .6, .7, 1, .5 > }
    finish { ambient .3 specular .2 }
    }
  }

// white sphere, just as landmark and size-comparator
sphere { 0, 0.0001 texture { pigment { color rgb 1 } } }
//white box, to catch bizarre shadows
box { <0, 0, 0.0002>, <0.00045, -0.0008, 0.00021>
  texture { pigment { color rgb 1 } }
  }

light_source { <-1, 1, -1> color rgb 2 }
camera {
  location <1, 1, -1>/2000 // also use "/200": _seems_ to be OK
  look_at -0.0002*y
  }

// E N D ======================
=========================
=======

Post a reply to this message

In article <3D77E242.8F775B59@computermuseum.fh-kiel.de>,


> I don't think the root solver is the problem, because it
> works perfectly with, for example, standard spheres, but not
> with the *same* spheres modeled by a poly.

The sphere primitive doesn't use the poly root solver, it is completely 
unrelated.


> I have continued to experiment with polys and I'm irritated
> even more -- just look at my intersection of three orthogonal
> semitransparent poly-planes. Even these  most simple  polys
> create cutting-faces that are too large (by  exactly  0.0001 --
> compare with the white sphere: the same value as with my drop).

You are depending on an object that is already prone to precision 
problems to be accurate at scales that would stress many primitives. It 
happens that 10e-4 is a tolerance value used for several things in the 
poly code, including the root tolerance. Just use larger values or 
different shapes.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message