Thorsten Froehlich <tho### [at] trfde> wrote:
> 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

Setting the threshold to 0 doesn't eliminate the problem.

Post a reply to this message

Nicolas Alvarez nous apporta ses lumieres en ce 2008/01/12 18:45:
> Trevor G Quayle escribió:
>> 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.
Anything that cause random graininess with aa will cause a large slowdown.

crand, sparse jittered area_light, coincident surfaces.

-- 
Alain
-------------------------------------------------
"The fact that windows is one of the most popular ways to operate a computer 
means that evolution has made a general fuckup and our race is doomed." 
            -- Anon.

Post a reply to this message

SharkD wrote:
> Setting the threshold to 0 doesn't eliminate the problem.

What AA method are you using?

	Thorsten

Post a reply to this message

Two things:

>  #local SphereGrid_bounds = sphere
>  {
>   0, SphereGrid_radius
>  }

This is causing a coincident surface problem.  Make the radius slightly larger
(eg: SphereGrid_radius*1.001)



>    #local SphereGrid_value = 360 * (SphereGrid_start + SphereGrid_i *
> SphereGrid_increment);
>    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

Another coincident surface problem.  Your radial gridlines go from one side to
the other, but you are also rotating a full 360 degrees.  This makes twice as
many as needed, but with the second set overlapping the first.  Either
a) make the box only from the center out
or
b) make half as many rotated through 180 degrees

-tgq

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> SharkD wrote:
> > Setting the threshold to 0 doesn't eliminate the problem.
>
> What AA method are you using?
>
>  Thorsten

It's not an anti-aliasing problem. It's a problem with the scene. If I replace
the sphere with something else and align things identically, the problem
disappears.

Post a reply to this message

"Trevor G Quayle" <Tin### [at] hotmailcom> wrote:
> Two things:
>
> >  #local SphereGrid_bounds = sphere
> >  {
> >   0, SphereGrid_radius
> >  }
>
> This is causing a coincident surface problem.  Make the radius slightly larger
> (eg: SphereGrid_radius*1.001)

I changed this but didn't notice a difference. Where does this have an effect?

> >    #local SphereGrid_value = 360 * (SphereGrid_start + SphereGrid_i *
> > SphereGrid_increment);
> >    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
>
> Another coincident surface problem.  Your radial gridlines go from one side to
> the other, but you are also rotating a full 360 degrees.  This makes twice as
> many as needed, but with the second set overlapping the first.  Either
> a) make the box only from the center out
> or
> b) make half as many rotated through 180 degrees

Doh! That resolves one of the issues. However, the problem with the area under
the grid and above the cut-away portion of the sphere still remains. I'm at a
complete loss.

Post a reply to this message

"SharkD" <nomail@nomail> wrote:
> "Trevor G Quayle" <Tin### [at] hotmailcom> wrote:
> > Two things:
> >
> > >  #local SphereGrid_bounds = sphere
> > >  {
> > >   0, SphereGrid_radius
> > >  }
> >
> > This is causing a coincident surface problem.  Make the radius slightly larger
> > (eg: SphereGrid_radius*1.001)
>
> I changed this but didn't notice a difference. Where does this have an effect?


At the surface of the sphere.  If you make the grid thickness large enough, you
should see the difference.  You are bounding the difference object to a sphere
of 1 unit radius, then differencing that from a sphere of 1 unit radius.


> Doh! That resolves one of the issues. However, the problem with the area under
> the grid and above the cut-away portion of the sphere still remains. I'm at a
> complete loss.


You are still having the same problem with your cones, or rather similar.  You
are now working from 0 to 180 degrees, with the angle being the angle from the
north pole.  The cone has a defined height of 2*SphereGrid_radius*y, but the
radius of the cone is 2*SphereGrid_radius*abs(tand(SphereGrid_value)).  When
angle=90, tan(90)=undefined, giving you a problematic cone, which happens to be
the equator gridline.  If you want to continue the way you have it, have an
additional #if statement for SphereGrid_value=90 which differences a box
instead.

-tgq

Post a reply to this message

"Trevor G Quayle" <Tin### [at] hotmailcom> wrote:
> You are still having the same problem with your cones, or rather similar.  You
> are now working from 0 to 180 degrees, with the angle being the angle from the
> north pole.  The cone has a defined height of 2*SphereGrid_radius*y, but the
> radius of the cone is 2*SphereGrid_radius*abs(tand(SphereGrid_value)).  When
> angle=90, tan(90)=undefined, giving you a problematic cone, which happens to be
> the equator gridline.  If you want to continue the way you have it, have an
> additional #if statement for SphereGrid_value=90 which differences a box
> instead.
>
> -tgq

OK, that fixed it. Thank you! Also, is there a way I can use the #switch
statement instead of branching #if and #else statements? I don't mind using
#ifelse statements (which POV-Ray doesn't have), but I hate using branching
where it's not necessary.

Post a reply to this message

"SharkD" <nomail@nomail> wrote:
> "Trevor G Quayle" <Tin### [at] hotmailcom> wrote:
> > You are still having the same problem with your cones, or rather similar.  You
> > are now working from 0 to 180 degrees, with the angle being the angle from the
> > north pole.  The cone has a defined height of 2*SphereGrid_radius*y, but the
> > radius of the cone is 2*SphereGrid_radius*abs(tand(SphereGrid_value)).  When
> > angle=90, tan(90)=undefined, giving you a problematic cone, which happens to be
> > the equator gridline.  If you want to continue the way you have it, have an
> > additional #if statement for SphereGrid_value=90 which differences a box
> > instead.
> >
> > -tgq
>
> OK, that fixed it. Thank you! Also, is there a way I can use the #switch
> statement instead of branching #if and #else statements? I don't mind using
> #ifelse statements (which POV-Ray doesn't have), but I hate using branching
> where it's not necessary.

You could try:

#declare LATRANGE=select(90-SphereGrid_value,1,2,3);

#switch (LATRANGE)
  #case(1) //Do this for angle < 90
  #break
  #case(2) //Do this for angle = 90
  #break
  #case(3)  /Do this for angle > 90
  #break
#end


There may be other more elegant ways...
-tgq

Post a reply to this message

"Trevor G Quayle" <Tin### [at] hotmailcom> wrote:
> You could try:
>
> #declare LATRANGE=select(90-SphereGrid_value,1,2,3);
>
> #switch (LATRANGE)
>   #case(1) //Do this for angle < 90
>   #break
>   #case(2) //Do this for angle = 90
>   #break
>   #case(3)  /Do this for angle > 90
>   #break
> #end
>
>
> There may be other more elegant ways...
> -tgq

No, I was wondering if it would be possible to pass conditional statements to
the #case calls. This is not the case, so I'll just stick with what I've got.

Post a reply to this message