 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] trf de> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"SharkD" <nomail@nomail> wrote:
> "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.
Unfortuneately the #range keyword is inclusive at both ends ( a<= value <= b).
You could place a #case(90) statement first in the #switch block, and it should
capture the '90' value, then follw with the two #range (or one #range and one
#else), but this seem progamatically a bit sloppy.
-tgq
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Trevor G Quayle" <Tin### [at] hotmailcom> wrote:
> You could place a #case(90) statement first in the #switch block, and it should
> capture the '90' value, then follw with the two #range (or one #range and one
> #else), but this seem progamatically a bit sloppy.
>
> -tgq
I agree. Thanks again for your help! I will upload the fixed version to the
Object Collection sometime soon.
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
Just out of curiosity, do you think the problem is related specifically to the
cone, or is it a more general case that is applicable to other types of
objects?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
