 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Trevor G Quayle" <Tin### [at] hotmail com> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"SharkD" <nomail@nomail> wrote:
> 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.
I forgot to mention: do this before changing "SphereGrid_thickness" to 0.05.
Only change "SphereGrid_thickness" in order to see the noise, not the clipping.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"SharkD" <nomail@nomail> wrote:
> "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).
Yes I noticed this and mentioned it. I'm not sure how POV is handling them, but
it was causing massive slowdowns for me.
>
> > > 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.
>
> 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.
Hmm, I can't see either of these. Maybe repost your scene and macro. Perhaps
something is different (My changes or yours). Is it still there after you fix
the negative cone issue above?
BTW, this is how I fixed the latitude grids:
(You can ignore the formatting changes, I just made them the way I like to see
them)
//START
#local SphereGrid_increment = 1/SphereGrid_lattt*2;
#local SphereGrid_i = 0;
#local SphereGrid_start =
SphereGrid_increment-SphereGrid_offset*SphereGrid_increment/2;
#while(SphereGrid_i < SphereGrid_lattt/2)
#local
SphereGrid_value=90*(SphereGrid_start+SphereGrid_i*SphereGrid_increment);
#if (SphereGrid_value=90)
cylinder{-SphereGrid_thickness/2*y,SphereGrid_thickness/2*y,1.1}
#else
#declare j=-1;#while (j<=1)
difference{
cone{
0, 0,
y*2, tand(SphereGrid_value)*2
translate -y/sind(SphereGrid_value)*SphereGrid_thickness/2
}
cone{
0, 0,
y*2, tand(SphereGrid_value)*2
translate y/sind(SphereGrid_value)*SphereGrid_thickness/2
}
scale <1,j,1>
}
#declare j=j+2;#end
#end
//END
-tgq
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Trevor G Quayle" <Tin### [at] hotmailcom> wrote:
> Hmm, I can't see either of these. Maybe repost your scene and macro. Perhaps
> something is different (My changes or yours). Is it still there after you fix
> the negative cone issue above?
Here's the current scene:
// BEGIN
#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
finish
{
ambient 0
}
}
//------------------------------------------------------------------------------CSG
objects
SphereGrid_Macro
(
6, // SphereGrid_radii, The number of radial divisions. (integer)
12, // SphereGrid_longt, The number of longitudinal divisions. (integer)
6, // SphereGrid_lattt, The number of lattitudinal divisions. (integer)
1, // SphereGrid_radius, The radius of the sphere. (float)
0, // SphereGrid_center, The center coordinates of the sphere. (vector)
0.01, // SphereGrid_thickness, 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)
)
#declare sRadius = 1 ;
#declare sCenter = 0 ;
difference
{
sphere
{
sCenter, sRadius
}
object
{
SphereGrid_Object
}
box
{
sCenter, <-sRadius,sRadius,-sRadius,>
}
pigment
{
color rgb 1
}
finish
{
ambient 1
}
}
//END
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Trevor G Quayle" <Tin### [at] hotmailcom> wrote:
> Hmm, I can't see either of these. Maybe repost your scene and macro. Perhaps
> something is different (My changes or yours). Is it still there after you fix
> the negative cone issue above?
Here's the current macro:
//BEGIN
#include "math.inc"
#macro SphereGrid_Macro
(
SphereGrid_radii, // The number of radial divisions. (integer)
SphereGrid_longt, // The number of longitudinal divisions. (integer)
SphereGrid_lattt, // The number of lattitudinal divisions. (integer)
SphereGrid_radius, // The radius of the sphere. (float)
SphereGrid_center, // The center coordinates of the sphere. (vector)
SphereGrid_thickness, // The thickness of the grid lines. (float)
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)
)
#local SphereGrid_thickness = SphereGrid_thickness/SphereGrid_radius;
#local SphereGrid_bounds = sphere
{
0, SphereGrid_radius
}
#declare SphereGrid_Object = union
{
#local SphereGrid_increment = 1/SphereGrid_radii;
#local SphereGrid_i = 0;
#local SphereGrid_start = 0;
#if (SphereGrid_offset = on)
#local SphereGrid_start = SphereGrid_increment/2;
#end
#while(SphereGrid_i < SphereGrid_radii)
#local SphereGrid_value = SphereGrid_radius * (SphereGrid_start +
SphereGrid_i * SphereGrid_increment);
difference
{
sphere
{
0, SphereGrid_value + SphereGrid_thickness/2
}
sphere
{
0, SphereGrid_value - SphereGrid_thickness/2
}
bounded_by
{
SphereGrid_bounds
}
}
// #debug concat("radii_value = ", str(SphereGrid_value, 0, -1),"\n")
#local SphereGrid_i = SphereGrid_i + 1;
#end
#local SphereGrid_increment = 1/SphereGrid_longt;
#local SphereGrid_i = 0;
#local SphereGrid_start = 0;
#if (SphereGrid_offset = on)
#local SphereGrid_start = SphereGrid_increment/2;
#end
#while(SphereGrid_i < SphereGrid_longt)
#local SphereGrid_value = 360 * (SphereGrid_start + SphereGrid_i *
SphereGrid_increment);
/*
intersection
{
plane
{
z, SphereGrid_thickness/2
}
plane
{
-z, SphereGrid_thickness/2
}
rotate y * SphereGrid_value
}
*/
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
#local SphereGrid_increment = 1/SphereGrid_lattt;
#local SphereGrid_i = 0;
#local SphereGrid_start = 0;
#if (SphereGrid_offset = on)
#local SphereGrid_start = SphereGrid_increment/2;
#end
#while(SphereGrid_i < SphereGrid_lattt)
#local SphereGrid_value = 180 * (SphereGrid_start + SphereGrid_i *
SphereGrid_increment);
#if (SphereGrid_i <= SphereGrid_lattt/2)
difference
{
cone
{
0, 0,
2*SphereGrid_radius*y, 2*SphereGrid_radius*abs(tand(SphereGrid_value))
translate SphereGrid_radius*-y * 1/abs(sind(SphereGrid_value)) *
SphereGrid_thickness/2
}
cone
{
0, 0,
2*SphereGrid_radius*y, 2*SphereGrid_radius*abs(tand(SphereGrid_value))
translate SphereGrid_radius*y * 1/abs(sind(SphereGrid_value)) *
SphereGrid_thickness/2
}
bounded_by
{
SphereGrid_bounds
}
}
#else
difference
{
cone
{
0, 0,
2*SphereGrid_radius*-y, 2*SphereGrid_radius*abs(tand(SphereGrid_value))
translate SphereGrid_radius*y * 1/abs(sind(SphereGrid_value)) *
SphereGrid_thickness/2
}
cone
{
0, 0,
2*SphereGrid_radius*-y, 2*SphereGrid_radius*abs(tand(SphereGrid_value))
translate SphereGrid_radius*-y * 1/abs(sind(SphereGrid_value)) *
SphereGrid_thickness/2
}
bounded_by
{
SphereGrid_bounds
}
}
#end
// #debug concat("lattt_value = ", str(SphereGrid_value, 0, -1),"\n")
#local SphereGrid_i = SphereGrid_i + 1;
#end
translate SphereGrid_center
}
#end
//END
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
