"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