POV-Ray : Newsgroups : povray.general : Graininess : Re: Graininess Server Time
31 Jul 2024 08:20:29 EDT (-0400)
  Re: Graininess  
From: SharkD
Date: 12 Jan 2008 02:05:01
Message: <web.478864ed22fbe8cfd410b38f0@news.povray.org>
"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

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.