"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