 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"SharkD" <nomail@nomail> 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....
Here's the scene. It uses two include files available from the Object
Collection.
#include "SphereGrid_macro.inc"
#include "Axes_macro.inc"
#include "functions.inc"
#include "math.inc"
global_settings
{
assumed_gamma 1.0
ambient_light 0.3
}
light_source
{
<0, 0, 0> // light's position (translated below)
color rgb <1, 1, 1> // light's color
translate <-30, 30, -30>
shadowless
}
light_source
{
<0, 0, 0> // light's position (translated below)
color rgb <1, 1, 1> // light's color
translate <-30, 30, -30>
rotate y * 90
shadowless
}
camera
{
#local CameraDistance = 10;
#local ScreenArea = 2;
#local AspectRatio = image_width/image_height;
// orthographic
location -z*CameraDistance
direction z*CameraDistance
right x*ScreenArea*AspectRatio
up y*ScreenArea
rotate x*asind(tand(30))
rotate y*45
}
// the coordinate grid and axes
Axes_Macro
(
10, // Axes_axesSize, The distance from the origin to one of the grid's edges.
(float)
1, // Axes_majUnit, The size of each large-unit square. (float)
10, // Axes_minUnit, The number of small-unit squares that make up a large-unit
square. (integer)
0.0005, // Axes_thickRatio, The thickness of the grid lines (as a factor of
axesSize). (float)
off, // Axes_aBool, Turns the axes on/off. (boolian)
on, // Axes_mBool, Turns the minor units on/off. (boolian)
off, // Axes_xBool, Turns the plane perpendicular to the x-axis on/off.
(boolian)
on, // Axes_yBool, Turns the plane perpendicular to the y-axis on/off.
(boolian)
off // Axes_zBool, Turns the plane perpendicular to the z-axis on/off.
(boolian)
)
object
{
Axes_Object
translate -0.000001
no_shadow
no_reflection
// no_image
finish
{
ambient 0
}
}
SphereGrid_Macro
(
6, // SphereGrid_radii, The number of radial divisions. (integer)
//radii, The number of radial divisions. (integer)
12, // SphereGrid_longt, The number of longitudinal divisions. (integer)
//longt, The number of longitudinal divisions.
(integer)
6, // SphereGrid_lattt, The number of lattitudinal divisions. (integer)
//lattt, The number of lattitudinal divisions.
(integer)
1, // SphereGrid_radius, The radius of the sphere. (float)
//ObjectRadius, The radius of the sphere. (float)
0, // SphereGrid_center, The center coordinates of the sphere. (vector)
//ObjectCenter, The center coordinates of the
sphere. (vector)
0.01, // SphereGrid_thickness, The thickness of the grid lines. (float)
//LineThickness, The thickness of the
grid lines. (float)
0, // SphereGrid_offset, Determines whether the divisions are offset by half
the amount (sometimes necessary when doing cut-aways at intervals matching the
grid's divisions). (boolian)//OffsetBool Determines whether the divisions are
offset by half the amount (sometimes necessary when doing cut-aways at
intervals matching the grid's divisions). (boolian)
)
#declare sRadius = 1 ;
#declare sCenter = 0 ;
difference
{
sphere
{
sCenter, sRadius
}
box
{
sCenter, <-sRadius,sRadius,-sRadius,> * 2
}
object
{
SphereGrid_Object
}
texture
{
pigment
{
color rgb 1
}
finish
{
ambient 1
}
}
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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.
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.
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.
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.
Hope this helps. Keep up the good work though.
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.
-tgq
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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.
I thought that resulted in a "degenerate cone" warning and the object
completely removed from the scene.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez <nic### [at] gmail isthebestcom> 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.
>
> I thought that resulted in a "degenerate cone" warning and the object
> completely removed from the scene.
I don't know, I guess not. Fixing this fixes the problem though.
-tgq
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
One more little thing:
When you are making the cones for the lat lines, your are making them 1 unit
(the sphere radius) high and then offsetting up and down. If it happens that
the bottom cone is offset enough that it no longer intersects the sphere
surface, the grid lines won't extend all the way out as you want them to. This
is especially possible near the poles. I suggest making the cones twice as big
(just multiply the height and radius by 2) to guarantee that they intersect the
surface.
-tgq
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Trevor G Quayle" <Tin### [at] hotmailcom> wrote:
> One more little thing:
> When you are making the cones for the lat lines, your are making them 1 unit
> (the sphere radius) high and then offsetting up and down. If it happens that
> the bottom cone is offset enough that it no longer intersects the sphere
> surface, the grid lines won't extend all the way out as you want them to. This
> is especially possible near the poles. I suggest making the cones twice as big
> (just multiply the height and radius by 2) to guarantee that they intersect the
> surface.
>
> -tgq
Thanks for the tip!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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.
Just to illustrate how effective this often overlooked technique can be, I ran a
few tests using your basic scene.
I first ran the scene as is at 4 camera settings, 1) the original where the
sphere fills the image, 2)zoom out 2X, 3)zoom out 4X, 4)zoom out 10X.
I then reran the scene with the same camera settings, but manually bounding the
difference object (bounded_by{sphere{0,SphereGrid_radius*1.01}})
Unbounded:
1) 49s
2) 26s
3) 19s
4) 8s
Bounded:
1) 40s (82%, not much improvement because the object fills the entire image
almost, only the corners are skipped in the bounding check
2) 13s (50%)
3) 6s (32%)
4) 2s (25%)
As you can see, the payback gets greater as you zoom out. This is because nore
of the scene is outside the bounding box now, so POV doesn't need to check for
intersections, whereas before, the bounding box was infinite, filled the entire
scene, so intersections had to be checked at every pixel.
-tgq
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
