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

Post a reply to this message

"SharkD" <nomail@nomail> 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....

Coincident surface, move the grid plane up slightly.

-tgq

Post a reply to this message

"Trevor G Quayle" <Tin### [at] hotmailcom> wrote:
> "SharkD" <nomail@nomail> 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....
>
> Coincident surface, move the grid plane up slightly.
>
> -tgq

It's not a coincident surface. As I said, I already tried moving the grid away.
The problem gets gradually better as I move it farther away. This is different
than a coincident surface problem; when coincident surfaces are the problem,
the issue is resolved immediately once one of the surfaces is moved slightly.

Post a reply to this message

"SharkD" <nomail@nomail> 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....

Here's the scene. It uses two include files available from the Object
Collection.

#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
 no_shadow
 no_reflection
// no_image
 finish
 {
  ambient 0
 }
}

SphereGrid_Macro
(
 6,   // SphereGrid_radii,  The number of radial divisions. (integer)

                           //radii,  The number of radial divisions. (integer)
 12,   // SphereGrid_longt,  The number of longitudinal divisions. (integer)

                          //longt,  The number of longitudinal divisions.
(integer)
 6,   // SphereGrid_lattt,  The number of lattitudinal divisions. (integer)

                         //lattt,  The number of lattitudinal divisions.
(integer)
 1,   // SphereGrid_radius,  The radius of the sphere. (float)

                              //ObjectRadius,  The radius of the sphere. (float)
 0,   // SphereGrid_center,  The center coordinates of the sphere. (vector)

                                 //ObjectCenter,  The center coordinates of the
sphere. (vector)
 0.01,   // SphereGrid_thickness,  The thickness of the grid lines. (float)

                                       //LineThickness, 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)//OffsetBool  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
 }
 box
 {
  sCenter, <-sRadius,sRadius,-sRadius,> * 2
 }
 object
 {
  SphereGrid_Object
 }

 texture
 {
  pigment
  {
   color rgb 1
  }
  finish
  {
   ambient 1
  }
 }
}

Post a reply to this message

"SharkD" <nomail@nomail> wrote:
> Here's the scene. It uses two include files available from the Object
> Collection.

Woops. Just noticed all the junk comments. Hopefully you can weed them out.

Post a reply to this message

"SharkD" <nomail@nomail> wrote:
> "SharkD" <nomail@nomail> wrote:
> > Here's the scene. It uses two include files available from the Object
> > Collection.
>
> Woops. Just noticed all the junk comments. Hopefully you can weed them out.

Yeah, I did.

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.

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.

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.

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.

Hope this helps.  Keep up the good work though.

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.

-tgq

Post a reply to this message

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

I thought that resulted in a "degenerate cone" warning and the object 
completely removed from the scene.

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailisthebestcom> 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.
>
> I thought that resulted in a "degenerate cone" warning and the object
> completely removed from the scene.

I don't know, I guess not.  Fixing this fixes the problem though.

-tgq

Post a reply to this message

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

Post a reply to this message

"Trevor G Quayle" <Tin### [at] hotmailcom> wrote:
> "SharkD" <nomail@nomail> wrote:
> > "SharkD" <nomail@nomail> wrote:
> > > Here's the scene. It uses two include files available from the Object
> > > Collection.
> >
> > Woops. Just noticed all the junk comments. Hopefully you can weed them out.
>
> Yeah, I did.
>
> 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.

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

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

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
   }

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.

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

Post a reply to this message