"Trevor G Quayle" <Tin### [at] hotmailcom> wrote:
> One more little thing:
> When you are making the cones for the lat lines, your are making them 1 unit
> (the sphere radius) high and then offsetting up and down.  If it happens that
> the bottom cone is offset enough that it no longer intersects the sphere
> surface, the grid lines won't extend all the way out as you want them to.  This
> is especially possible near the poles.  I suggest making the cones twice as big
> (just multiply the height and radius by 2) to guarantee that they intersect the
> surface.
>
> -tgq

Thanks for the tip!

Post a reply to this message

"SharkD" <nomail@nomail> wrote:

> > The error is in your SphereGrid macro when you are making the cones for the
> > latitude grids.  You set the radius of the cone to be 1/tan(value), which is
> > fine, except when you have one that is completely flat (i.e. the equator).
> > Here, value=0, therefore tan(0)=0 which leaves a division by 0 error.  I don't
> > know exactly how POV is handling this, but it is creating something similar to
> > a coincident surface problem.
>
> This is incorrect. A cone with a width of zero at its base results in a vertical
> line segment, not a disc. The width would have to be infinitely great in order
> to create a disc.
>
>
> > Two other problems that I noticed as well:
> > You are cycling from 0deg up to 180deg, with the angle being the angle from the
> > equator.
> > 1) This means that you are going through angle=90, which is a vertical cone of 0
> > thickness, that is, unnecessary.
> > 2)  above 90, you are creating the cones using angles greater than 90deg.
> > 1/cos(value) for these angles is <0, therefore you are using a negative radius
> > which can cause problems.
>
> No. Angle 90 results in a flat cone, e.g. the equator.
>


Relook at your trig.  You've got it backwards. You are using diameter =
1/tan(angle).  You are also explicitly setting the height to y=1 so the cone
will always have a height of 1, not be flat.
For angle=0, tan(0)=0, 1/tan(0)=undefined.
For angle=90, tan(90)=inf., 1/tan(90)=0.  This does create a line segment, but
is unnecessary as I stated.



> > You would be better to iterate from the top down to the equator, with the angle
> > being the angle from the pole instead.  That gives you a few advantages:
> > a) you can create 2 identical cones at once and just -y mirror one for the grids
> > below the equator (this will avoid problem 2) above.
> > b) You can skip angle=0, the vertical one from item 1) above
> > c) Then you just make sure you have a special case for angle=90.  I would
> > suggest using a cylinder.
>

> I have had no problems using a cylinder. However POV-Ray handles cases where the
> width of a cone's base is zero or infinite, the objects are rendered properly.

You are right, I assume that gridline thickness would never be 0, but a box
works just as well.

>
> > Speaking of item c).  For the Longitudinal lines, you are using the intersection
> > of 2 planes, which work fine, but you would be better to use a cylinder or box
> > instead.  It is best to avoid differences and intersections as much as possible
> > if you can, as they can creat bounding_box difficulties which con slow down
> > rendering quite a bit.
>
> Thanks for the tip. I changed my code to use a box instead. I noticed that the
> image renders in about half the time. Unfortunately, it has resulted in
> clipping errors that I'm unable to resolve. Maybe you can take a look.

This is because of bounding.  When you difference or intersect, the one object
is turned inside-out, and has unlimited size, therefore POV is always looking
for it, even where it is not needed.  As a rule, if possible, avoid
difference/intersection if it can be done another way (like here), or try
manually bounding (effect of this can vary).  Speaking of this, since you are
subtracting it from a sphere, try manually bound the differencing object.  If
the object fills the screen (as your camera setup is doing) you won't notice a
huge speedup, but if you zoom out, the speedup can be great.

>
> I changed this:
>
>    intersection
>    {
>     plane
>     {
>      z, SphereGrid_thickness/2
>     }
>     plane
>     {
>      -z, SphereGrid_thickness/2
>     }
>     rotate y * SphereGrid_value
>    }
>
> To this:
>
>    box
>    {
>     <1, 1, SphereGrid_thickness/2,>, <-1, -1, -SphereGrid_thickness/2,>
>     rotate y * SphereGrid_value
>    }
>
I'd make them just slightly larger (1.001).


> You'll notice in the example scene I provided that you can now see inside the
> sphere in certain places, as if I'd used the clipped_by statement instead of
> difference.


Not sure what you mean here.


>
> > Hope this helps.  Keep up the good work though.
>
> Thanks.
>
> > PS, When writing macros like these, I like to create a spreadsheet that mimics
> > my loops so I can see the trig in action and catch the errors, especially
> > division by zero errors.
>
> I use GeoGebra to plan all my scenes.
>
> To return back to my original problem, I noticed when changing the
> SphereGrid_thickness parameter of the macro to something greater that other
> areas of the sphere are "pixely". I tried messing with the pigments (giving
> each object its own pigment instead of only giving the final object one), but
> was unable to rid it of them.

Pixely usually means a coincident surface problem.  This can come from a
combination of 2 or more objects, or from a pigment pattern and 1 or more
objects.  I'd need to know more or see your exact scene file to figure this out
exactly.

-tgq

Post a reply to this message

> This is because of bounding.  When you difference or intersect, the one object
> is turned inside-out, and has unlimited size, therefore POV is always looking
> for it, even where it is not needed.  As a rule, if possible, avoid
> difference/intersection if it can be done another way (like here), or try
> manually bounding (effect of this can vary).  Speaking of this, since you are
> subtracting it from a sphere, try manually bound the differencing object.  If
> the object fills the screen (as your camera setup is doing) you won't notice a
> huge speedup, but if you zoom out, the speedup can be great.

Just to illustrate how effective this often overlooked technique can be, I ran a
few tests using your basic scene.

I first ran the scene as is at 4 camera settings, 1) the original where the
sphere fills the image, 2)zoom out 2X, 3)zoom out 4X, 4)zoom out 10X.
I then reran the scene with the same camera settings, but manually bounding the
difference object (bounded_by{sphere{0,SphereGrid_radius*1.01}})

Unbounded:
1) 49s
2) 26s
3) 19s
4) 8s

Bounded:
1) 40s (82%, not much improvement because the object fills the entire image
almost, only the corners are skipped in the bounding check
2) 13s (50%)
3) 6s (32%)
4) 2s (25%)

As you can see, the payback gets greater as you zoom out.  This is because nore
of the scene is outside the bounding box now, so POV doesn't need to check for
intersections, whereas before, the bounding box was infinite, filled the entire
scene, so intersections had to be checked at every pixel.

-tgq

Post a reply to this message

"Trevor G Quayle" <Tin### [at] hotmailcom> wrote:
> Relook at your trig.  You've got it backwards. You are using diameter =
> 1/tan(angle).  You are also explicitly setting the height to y=1 so the cone
> will always have a height of 1, not be flat.
> For angle=0, tan(0)=0, 1/tan(0)=undefined.
> For angle=90, tan(90)=inf., 1/tan(90)=0.  This does create a line segment, but
> is unnecessary as I stated.

Woops! You're right. The way you describe it is the way I /intended/ it.
Somewhere, I must have got the angles mixed up. BTW, I noticed some other
problems while reviewing this section of the code. For angles greater than 90
degrees, the /absolute value/ must be used for the cone radius. Otherwise, it
results in a degenerate cone (all lattitude lines below the equator were being
omitted).

> This is because of bounding.  When you difference or intersect, the one object
> is turned inside-out, and has unlimited size, therefore POV is always looking
> for it, even where it is not needed.  As a rule, if possible, avoid
> difference/intersection if it can be done another way (like here), or try
> manually bounding (effect of this can vary).  Speaking of this, since you are
> subtracting it from a sphere, try manually bound the differencing object.  If
> the object fills the screen (as your camera setup is doing) you won't notice a
> huge speedup, but if you zoom out, the speedup can be great.

OK, I'll try this.

> > You'll notice in the example scene I provided that you can now see inside the
> > sphere in certain places, as if I'd used the clipped_by statement instead of
> > difference.
>
>
> Not sure what you mean here.

You'll have to render the scene to see it (after applying the changed code). The
very last difference statement (the corner cut-away) now cuts into the sphere so
that you can see the insides of the (solid!) objects, as if a clipped_by
statement were being used instead.

> Pixely usually means a coincident surface problem.  This can come from a
> combination of 2 or more objects, or from a pigment pattern and 1 or more
> objects.  I'd need to know more or see your exact scene file to figure this out
> exactly.

I posted the exact scene file a few messages ago. The only thing that needs to
be changed is the "SphereGrid_thickness" parameter of the macro call. Increase
it to something larger (but not too large!), like 0.05. This will widen the
gaps between the segments large enough to see some noisy surfaces adjacent to
the gaps.

Post a reply to this message

"SharkD" <nomail@nomail> wrote:
> You'll have to render the scene to see it (after applying the changed code). The
> very last difference statement (the corner cut-away) now cuts into the sphere so
> that you can see the insides of the (solid!) objects, as if a clipped_by
> statement were being used instead.

I forgot to mention: do this before changing "SphereGrid_thickness" to 0.05.
Only change "SphereGrid_thickness" in order to see the noise, not the clipping.

Post a reply to this message

"SharkD" <nomail@nomail> wrote:
> "Trevor G Quayle" <Tin### [at] hotmailcom> wrote:
> > Relook at your trig.  You've got it backwards. You are using diameter =
> > 1/tan(angle).  You are also explicitly setting the height to y=1 so the cone
> > will always have a height of 1, not be flat.
> > For angle=0, tan(0)=0, 1/tan(0)=undefined.
> > For angle=90, tan(90)=inf., 1/tan(90)=0.  This does create a line segment, but
> > is unnecessary as I stated.
>
> Woops! You're right. The way you describe it is the way I /intended/ it.
> Somewhere, I must have got the angles mixed up. BTW, I noticed some other
> problems while reviewing this section of the code. For angles greater than 90
> degrees, the /absolute value/ must be used for the cone radius. Otherwise, it
> results in a degenerate cone (all lattitude lines below the equator were being
> omitted).

Yes I noticed this and mentioned it.  I'm not sure how POV is handling them, but
it was causing massive slowdowns for me.

>
> > > You'll notice in the example scene I provided that you can now see inside the
> > > sphere in certain places, as if I'd used the clipped_by statement instead of
> > > difference.
> >
> >
> > Not sure what you mean here.
>
> You'll have to render the scene to see it (after applying the changed code). The
> very last difference statement (the corner cut-away) now cuts into the sphere so
> that you can see the insides of the (solid!) objects, as if a clipped_by
> statement were being used instead.
>
> I posted the exact scene file a few messages ago. The only thing that needs to
> be changed is the "SphereGrid_thickness" parameter of the macro call. Increase
> it to something larger (but not too large!), like 0.05. This will widen the
> gaps between the segments large enough to see some noisy surfaces adjacent to
> the gaps.

Hmm, I can't see either of these.  Maybe repost your scene and macro.  Perhaps
something is different (My changes or yours).  Is it still there after you fix
the negative cone issue above?

BTW, this is how I fixed the latitude grids:
(You can ignore the formatting changes, I just made them the way I like to see
them)

//START
  #local SphereGrid_increment = 1/SphereGrid_lattt*2;
  #local SphereGrid_i = 0;
  #local SphereGrid_start =
SphereGrid_increment-SphereGrid_offset*SphereGrid_increment/2;
  #while(SphereGrid_i < SphereGrid_lattt/2)
   #local
SphereGrid_value=90*(SphereGrid_start+SphereGrid_i*SphereGrid_increment);
   #if (SphereGrid_value=90)
     cylinder{-SphereGrid_thickness/2*y,SphereGrid_thickness/2*y,1.1}
   #else
    #declare j=-1;#while (j<=1)
      difference{
       cone{
        0, 0,
        y*2, tand(SphereGrid_value)*2
        translate -y/sind(SphereGrid_value)*SphereGrid_thickness/2
       }
       cone{
        0, 0,
        y*2, tand(SphereGrid_value)*2
        translate y/sind(SphereGrid_value)*SphereGrid_thickness/2
       }
        scale <1,j,1>
      }
        #declare j=j+2;#end
   #end
//END

-tgq

Post a reply to this message

SharkD wrote:
> http://img213.imageshack.us/my.php?image=hslsphereshowgw2.jpg
> 
> If you look at the above image you can see graininess where the square grid
> overlaps the cut portion of the sphere? What causes this? Ususally stuff like
> this only happens when there are coincident surfaces. I checked and there are
> none. Moving the grid away from the sphere surface causes the problem to
> lessen. Turning the light sources off causes it to go away. I've experimented
> with changing to a parallel camera, parallel lights, turning off shadows and
> reflection for objects, turning off ambient in global settings and in the
> finish, turning off radiosity, etc....

This looks simply like aliasing ... what happens if you use anti-aliasing
with relatively high settings?

	Thorsten

Post a reply to this message

"Trevor G Quayle" <Tin### [at] hotmailcom> wrote:
> Hmm, I can't see either of these.  Maybe repost your scene and macro.  Perhaps
> something is different (My changes or yours).  Is it still there after you fix
> the negative cone issue above?

Here's the current scene:

// BEGIN
#include "SphereGrid_macro.inc"
#include "Axes_macro.inc"
#include "functions.inc"
#include "math.inc"

global_settings
{
 assumed_gamma 1.0
 ambient_light 0.3
}

light_source
{
 <0, 0, 0>            // light's position (translated below)
 color rgb <1, 1, 1>  // light's color
 translate <-30, 30, -30>
 shadowless
}

light_source
{
 <0, 0, 0>            // light's position (translated below)
 color rgb <1, 1, 1>  // light's color
 translate <-30, 30, -30>
 rotate y * 90
 shadowless
}

camera
{
 #local CameraDistance = 10;
 #local ScreenArea = 2;
 #local AspectRatio = image_width/image_height;
// orthographic
 location -z*CameraDistance
 direction z*CameraDistance
 right     x*ScreenArea*AspectRatio
 up        y*ScreenArea
 rotate x*asind(tand(30))
 rotate y*45
}

// the coordinate grid and axes
Axes_Macro
(
 10, // Axes_axesSize, The distance from the origin to one of the grid's edges.
(float)
 1, // Axes_majUnit, The size of each large-unit square. (float)
 10, // Axes_minUnit, The number of small-unit squares that make up a large-unit
square. (integer)
 0.0005, // Axes_thickRatio, The thickness of the grid lines (as a factor of
axesSize). (float)
 off, // Axes_aBool,  Turns the axes on/off. (boolian)
 on, // Axes_mBool,  Turns the minor units on/off. (boolian)
 off, // Axes_xBool,  Turns the plane perpendicular to the x-axis on/off.
(boolian)
 on, // Axes_yBool,  Turns the plane perpendicular to the y-axis on/off.
(boolian)
 off // Axes_zBool,  Turns the plane perpendicular to the z-axis on/off.
(boolian)
)

object
{
 Axes_Object
 translate -0.000001
 finish
 {
  ambient 0
 }
}

//------------------------------------------------------------------------------CSG
objects

SphereGrid_Macro
(
 6,   // SphereGrid_radii,  The number of radial divisions. (integer)
 12,   // SphereGrid_longt,  The number of longitudinal divisions. (integer)
 6,   // SphereGrid_lattt,  The number of lattitudinal divisions. (integer)
 1,   // SphereGrid_radius,  The radius of the sphere. (float)
 0,   // SphereGrid_center,  The center coordinates of the sphere. (vector)
 0.01,   // SphereGrid_thickness,  The thickness of the grid lines. (float)
 0,   // SphereGrid_offset,  Determines whether the divisions are offset by half
the amount (sometimes necessary when doing cut-aways at intervals matching the
grid's divisions). (boolian)
)


#declare sRadius = 1 ;
#declare sCenter = 0 ;

difference
{
 sphere
 {
  sCenter, sRadius
 }
 object
 {
  SphereGrid_Object
 }
 box
 {
  sCenter, <-sRadius,sRadius,-sRadius,>
 }
 pigment
 {
  color rgb 1
 }
 finish
 {
  ambient 1
 }
}

//END

Post a reply to this message

"Trevor G Quayle" <Tin### [at] hotmailcom> wrote:
> Hmm, I can't see either of these.  Maybe repost your scene and macro.  Perhaps
> something is different (My changes or yours).  Is it still there after you fix
> the negative cone issue above?

Here's the current macro:

//BEGIN
#include "math.inc"

#macro SphereGrid_Macro
 (
  SphereGrid_radii,  // The number of radial divisions. (integer)
  SphereGrid_longt,  // The number of longitudinal divisions. (integer)
  SphereGrid_lattt,  // The number of lattitudinal divisions. (integer)
  SphereGrid_radius,  // The radius of the sphere. (float)
  SphereGrid_center,  // The center coordinates of the sphere. (vector)
  SphereGrid_thickness,  // The thickness of the grid lines. (float)
  SphereGrid_offset,  // Determines whether the divisions are offset by half the
amount (sometimes necessary when doing cut-aways at intervals matching the
grid's divisions). (boolian)
 )

 #local SphereGrid_thickness = SphereGrid_thickness/SphereGrid_radius;
 #local SphereGrid_bounds = sphere
 {
  0, SphereGrid_radius
 }

 #declare SphereGrid_Object = union
 {

  #local SphereGrid_increment = 1/SphereGrid_radii;
  #local SphereGrid_i = 0;
  #local SphereGrid_start = 0;
  #if (SphereGrid_offset = on)
   #local SphereGrid_start = SphereGrid_increment/2;
  #end
  #while(SphereGrid_i < SphereGrid_radii)
   #local SphereGrid_value = SphereGrid_radius * (SphereGrid_start +
SphereGrid_i * SphereGrid_increment);
   difference
   {
    sphere
    {
     0, SphereGrid_value + SphereGrid_thickness/2
    }
    sphere
    {
     0, SphereGrid_value - SphereGrid_thickness/2
    }
    bounded_by
    {
     SphereGrid_bounds
    }
   }
//   #debug concat("radii_value = ", str(SphereGrid_value, 0, -1),"\n")
   #local SphereGrid_i = SphereGrid_i + 1;
  #end

  #local SphereGrid_increment = 1/SphereGrid_longt;
  #local SphereGrid_i = 0;
  #local SphereGrid_start = 0;
  #if (SphereGrid_offset = on)
   #local SphereGrid_start = SphereGrid_increment/2;
  #end
  #while(SphereGrid_i < SphereGrid_longt)
   #local SphereGrid_value = 360 * (SphereGrid_start + SphereGrid_i *
SphereGrid_increment);
/*
   intersection
   {
    plane
    {
     z, SphereGrid_thickness/2
    }
    plane
    {
     -z, SphereGrid_thickness/2
    }
    rotate y * SphereGrid_value
   }
*/
   box
   {
    <2*SphereGrid_radius, 2*SphereGrid_radius, SphereGrid_thickness/2,>,
<-2*SphereGrid_radius, -2*SphereGrid_radius, -SphereGrid_thickness/2,>
    rotate y * SphereGrid_value
   }

//   #debug concat("longt_value = ", str(SphereGrid_value, 0, -1),"\n")
   #local SphereGrid_i = SphereGrid_i + 1;
  #end

  #local SphereGrid_increment = 1/SphereGrid_lattt;
  #local SphereGrid_i = 0;
  #local SphereGrid_start = 0;
  #if (SphereGrid_offset = on)
   #local SphereGrid_start = SphereGrid_increment/2;
  #end
  #while(SphereGrid_i < SphereGrid_lattt)
   #local SphereGrid_value = 180 * (SphereGrid_start + SphereGrid_i *
SphereGrid_increment);
   #if (SphereGrid_i <= SphereGrid_lattt/2)
    difference
    {
     cone
     {
      0, 0,
      2*SphereGrid_radius*y, 2*SphereGrid_radius*abs(tand(SphereGrid_value))
      translate SphereGrid_radius*-y * 1/abs(sind(SphereGrid_value)) *
SphereGrid_thickness/2
     }
     cone
     {
      0, 0,
      2*SphereGrid_radius*y, 2*SphereGrid_radius*abs(tand(SphereGrid_value))
      translate SphereGrid_radius*y * 1/abs(sind(SphereGrid_value)) *
SphereGrid_thickness/2
     }
     bounded_by
     {
      SphereGrid_bounds
     }
    }
   #else
    difference
    {
     cone
     {
      0, 0,
      2*SphereGrid_radius*-y, 2*SphereGrid_radius*abs(tand(SphereGrid_value))
      translate SphereGrid_radius*y * 1/abs(sind(SphereGrid_value)) *
SphereGrid_thickness/2
     }
     cone
     {
      0, 0,
      2*SphereGrid_radius*-y, 2*SphereGrid_radius*abs(tand(SphereGrid_value))
      translate SphereGrid_radius*-y * 1/abs(sind(SphereGrid_value)) *
SphereGrid_thickness/2
     }
     bounded_by
     {
      SphereGrid_bounds
     }
    }
   #end
//   #debug concat("lattt_value = ", str(SphereGrid_value, 0, -1),"\n")
   #local SphereGrid_i = SphereGrid_i + 1;
  #end
  translate SphereGrid_center
 }
#end
//END

Post a reply to this message

> Yes I noticed this and mentioned it.  I'm not sure how POV is handling them, but
> it was causing massive slowdowns for me.

I think graininess (caused by coincident surfaces) makes POV attempt a 
*lot* of antialiasing.

Post a reply to this message