|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I'm in the process of creating an infinitely tall car garage and came across two
problems. Here's what I want it to look like, as well as an implicit description
of how I've made it:
http://gfycat.com/ScholarlyMeekAtlanticridleyturtle
So, I take a cylinder, cut out four slices as prisms by doing so at the origin
and translating along an axis. I then proceed to take an infinite number (i.e.
eleven) of these, stack them vertically, and I want to connect them by smooth
ramps.
Now, I found that the nicest results for the ramps I would get by using the
parametric objects, since I could then describe everything in polar coordinates
and describe the height of the ramp by a nice differentiable trigonometric
function (code below).
So, problem #1: as you can see from final structure, even though the entire
thing consists of a bunch of vertical translates, the "middle" set of ramps has
some issues with lighting (the checker pigment is all smeared). I found that I
could limit this effect by giving lower values of accuracy, but if I go below
0.000007, I'll get a segmentation fault when rendering. Here's a still showing
the problem:
https://i.imgur.com/p7ZkDTZ.png
Is there any way around this issue?
My second problem is probably related. If I try to double the angle of the
slices (i.e. change Angle to 8/360*2*pi in the code below), some translates
behave weirdly. Again, here's a still:
https://i.imgur.com/cDYNLHD.png
As you can see, the topmost ramps have some strange cuts that the bottommost do
not, even though they're all just translates of the same thing. Is there any way
to fix that?
Here's the full code. The relevant part is in #declare Stairs.
-------------------------------------
#declare Radius = 2.5;
#declare Height = 1;
#declare Angle = 4/360*2*pi;
#declare CameraDistance = 10;
#declare CameraAngle = 5*pi/8+2*pi*1;
camera {
location <CameraDistance*cos(CameraAngle), CameraDistance*sin(CameraAngle),
-Height/3>
sky <0,0,1>
look_at 0
}
// We first create the disks as very thin cylinders, so as to be able to use CSG
// later on.
#declare Disk = cylinder {
<0, 0, -0.001>, <0, 0, 0>, Radius
pigment { checker pigment { color rgb <0.9,0.3,0.3> filter 0.3 }, pigment{
color rgb <0.8,0.1,0.1> filter 0.3 } }
finish { phong 0.7 specular 0.6 }
}
// From the disks, we will cut out four slices (with angle 2*Angle, given
below).
// These will be given as if they had a vertex at the origin, then translated to
// each of the punctures.
//
// The punctures have <x,y>-coordinates <-1.5,0>, <-0.5,0>, <0.5,0> and <1.5,0>.
#declare CutOut = prism {
linear_sweep
linear_spline
-0.5,
0.5,
4,
<0,0>, <-2*Radius*sin(Angle),-2*Radius>, <2*Radius*sin(Angle),-2*Radius>,
<0,0>
rotate x*90
}
#declare CutDisk = difference {
object { Disk }
union {
object { CutOut translate -0.5*x }
object { CutOut translate 0.5*x }
object { CutOut translate -1.5*x }
object { CutOut translate 1.5*x }
}
}
// Now to the ramps between each floor. We take these to go upwards from our
reference
// disk. Once again, we construct a ramp at the origin where we can use polar
coordinates,
// and we translate it afterwards.
#declare Stairs = parametric {
function { v*cos(u) },
function { v*sin(u) },
// Differentiable stairs:
function { Height*(cos(pi*(u-(-3*pi/2-Angle))/(2*Angle))+1)/2 }
<-3*pi/2-Angle,0>, <-3*pi/2+Angle,Radius+1>
// For whatever reason, the numerics tend to die on one ramp layer without a
fairly low value of 'accuracy' (i.e. high accuracy).
// Unfortunately, with values lower than the one given below, the rotation
animations die with a segmentation fault.
accuracy 0.000007
precompute 10 x,y,z
contained_by{box{<-Radius,-Radius,-0.1>,<Radius,Radius,1.1>}}
// It would be neat to let the ramps have filter values but this causes
graining.
pigment { checker pigment { color rgb <0.9,0.3,0.3> }, pigment{ color rgb
<0.8,0.1,0.1> } }
finish { phong 0.7 specular 0.6 }
}
// We now translate all the ramps into the slices we cut out of the disks.
// When translating however, the ramps end up sticking out of the cylinder, but
this we can fix
// with a simple simple difference.
#declare DiskWithStairs = union{
object { CutDisk }
difference {
object { Stairs translate -1.5*x }
object { cylinder { <0,0,-0.1>, <0,0,Height+1.1>, Radius inverse } }
}
difference {
object { Stairs translate -0.5*x }
object { cylinder { <0,0,-0.1>, <0,0,Height+1.1>, Radius inverse } }
}
difference {
object { Stairs translate 0.5*x }
object { cylinder { <0,0,-0.1>, <0,0,Height+1.1>, Radius inverse } }
}
difference {
object { Stairs translate 1.5*x }
object { cylinder { <0,0,-0.1>, <0,0,Height+1.1>, Radius inverse } }
}
}
union {
object { DiskWithStairs translate -5*Height*z }
object { DiskWithStairs translate -4*Height*z }
object { DiskWithStairs translate -3*Height*z }
object { DiskWithStairs translate -2*Height*z }
object { DiskWithStairs translate -1*Height*z }
object { DiskWithStairs translate 0*z }
object { DiskWithStairs translate 1*Height*z }
object { DiskWithStairs translate 2*Height*z }
object { DiskWithStairs translate 3*Height*z }
object { DiskWithStairs translate 4*Height*z }
object { DiskWithStairs translate 5*Height*z }
}
Post a reply to this message
|
|
| |
| |
|
|
From: William F Pokorny
Subject: Re: Accuracy with parametric: An infinite car garage
Date: 22 Oct 2014 18:25:44
Message: <54482ee8$1@news.povray.org>
|
|
|
| |
| |
|
|
On 10/22/2014 04:10 AM, fuglede wrote:
> So, problem #1: as you can see from final structure, even though the entire
> thing consists of a bunch of vertical translates, the "middle" set of ramps has
> some issues with lighting (the checker pigment is all smeared). I found that I
> could limit this effect by giving lower values of accuracy, but if I go below
> 0.000007, I'll get a segmentation fault when rendering. Here's a still showing
> the problem:
> https://i.imgur.com/p7ZkDTZ.png
>
> Is there any way around this issue?
>
> My second problem is probably related. If I try to double the angle of the
> slices (i.e. change Angle to 8/360*2*pi in the code below), some translates
> behave weirdly. Again, here's a still:
> https://i.imgur.com/cDYNLHD.png
> As you can see, the topmost ramps have some strange cuts that the bottommost do
> not, even though they're all just translates of the same thing. Is there any way
> to fix that?
>
I don't have a lot of experience with parametric surfaces, but I've
found with them and some other of Pov-Ray's mathematical surfaces that
there can be issues when the rays from the camera more or less line up
on the axis of the mathematical axis there can be noise. I've seen this
in more complex prisms too for example.
Looks like your camera is offset some so a quick test as to whether you
are hitting calculation noise is to try an orthographic camera by adding
the word orhographic as the first line of your camera definition. You
probably won't want this camera type for your final render, but if it
cleans things up, it gives the strong hint cleaner results are possible
by positioning your camera more off axis relative to the problem parts
of the object. If orthographic works, with the default camera maybe go
to a height of 1.5*height in z. Or a change to the parametric object
itself might help if it makes the problem camera ray to object
relationship less orthogonal.
Other things I see. You've got a couple pigment+finish definitions on
sub objects of the whole. This can be done if one is careful not to
create competition between them. It would be more normal to have one
texture in the final union/object.
Parametric objects are defined by their surface so where doing
differences or intersections on the edge you may well have black or
white spots which are difficult or impossible to eliminate.
With all numerical noise issues, anti-aliasing, +A, +jitter etc, can
help quite a bit, but the noise too can make the anti-aliasing more
expensive.
I couldn't really see the issue with the smaller angle - the differences
looked to me to mostly due looking at aspects of the surface. Maybe
there were some of the 0-thickness edge effects opening things up a
little - I was not sure. Also possible I am not seeing that issue.
Hope something in my rambling a help.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Now, I found that the nicest results for the ramps I would get by using the
> parametric objects, since I could then describe everything in polar coordinates
> and describe the height of the ramp by a nice differentiable trigonometric
> function (code below).
>
> So, problem #1: as you can see from final structure, even though the entire
> thing consists of a bunch of vertical translates, the "middle" set of ramps has
> some issues with lighting (the checker pigment is all smeared). I found that I
> could limit this effect by giving lower values of accuracy, but if I go below
> 0.000007, I'll get a segmentation fault when rendering. Here's a still showing
> the problem:
> https://i.imgur.com/p7ZkDTZ.png
>
> Is there any way around this issue?
If you can't find an easy solution then I would be tempted to write a
macro to create a mesh2 object on-the-fly from the parametric equations.
It should render faster too.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
William F Pokorny <ano### [at] anonymousorg> wrote:
Thanks for the reply.
> I don't have a lot of experience with parametric surfaces, but I've
> found with them and some other of Pov-Ray's mathematical surfaces that
> there can be issues when the rays from the camera more or less line up
> on the axis of the mathematical axis there can be noise. I've seen this
> in more complex prisms too for example.
>
> Looks like your camera is offset some so a quick test as to whether you
> are hitting calculation noise is to try an orthographic camera by adding
> the word orhographic as the first line of your camera definition. You
> probably won't want this camera type for your final render, but if it
> cleans things up, it gives the strong hint cleaner results are possible
> by positioning your camera more off axis relative to the problem parts
> of the object. If orthographic works, with the default camera maybe go
> to a height of 1.5*height in z. Or a change to the parametric object
> itself might help if it makes the problem camera ray to object
> relationship less orthogonal.
With the orthographic camera, there is still visible noise. However, what bugged
me the most was the "slice" through the middle floor of
https://i.imgur.com/p7ZkDTZ.png
and that could be mitigated with the orthographic camera and, indeed, by
changing the z-axis offset of the camera. So yeah, of course it's not completely
optimal but for my purposes, this should be fine; thanks.
> Other things I see. You've got a couple pigment+finish definitions on
> sub objects of the whole. This can be done if one is careful not to
> create competition between them. It would be more normal to have one
> texture in the final union/object.
Makes sense. For the pigment ones, I need to apply different ones to the ramps
and the disks; if I put the "filter" from the disks on the ramps, they turn
grainy -- is there a way to fix that?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott <sco### [at] scottcom> wrote:
> If you can't find an easy solution then I would be tempted to write a
> macro to create a mesh2 object on-the-fly from the parametric equations.
> It should render faster too.
Yeah, I can see how that can be useful, and it looks like Parametric() of
http://wiki.povray.org/content/Reference:Meshmaker.inc
would do that for me. The other reply more or less solved my problem though, so
I will probably not play around with it too much. I'll keep it in mind for the
future though.
Post a reply to this message
|
|
| |
| |
|
|
From: William F Pokorny
Subject: Re: Accuracy with parametric: An infinite car garage
Date: 23 Oct 2014 17:36:20
Message: <544974d4@news.povray.org>
|
|
|
| |
| |
|
|
On 10/23/2014 10:30 AM, fuglede wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
...
> Makes sense. For the pigment ones, I need to apply different ones to the ramps
> and the disks; if I put the "filter" from the disks on the ramps, they turn
> grainy -- is there a way to fix that?
>
>
Perhaps we should back up and be sure it is understood what you are
doing in using infinitely thin surfaces in intersections and differences
to define the whole of your object is pushing past what POV-Ray - let us
say - robustly supports. It used to be scenes like yours would generate
warnings along the lines that CSG operations with surface or 2D objects
was not supported.
That said, doing what you are doing often works out OK. If the rays
bouncing around cross the surface in a mathematically favorable way,
things can work fine.
What I suspect in allowing some light to filter through the surface is
we are further exposing ourselves to mathematical noise - there are now
more rays bouncing around adding those passing through surfaces. The
determination of inside vs outside becomes important and that is iffy /
undefined for surfaces hanging in space.
If when you turn on the filtering of light for the ramps, are parts of
the ramp with direct lines to the camera and light source clean, without
graininess? I suspect yes. I doubt there is any easy fix for the
filtering and graininess. Another test would be to set the filtering to
50% say - the graininess would get worse if coming from noise of rays
through the surfaces.
That said. There is too a max_gradient option for parametric surfaces. I
>think< the default is 1.0. Your accuracy is already set really high,
but you can crank up the max_gradient to 5.0 say and see what happens.
Calculation of the surface should be more accurate. Unfortunately, the
render will get much slower.
Hope something said a help.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
William F Pokorny <ano### [at] anonymousorg> wrote:
> Perhaps we should back up and be sure it is understood what you are
> doing in using infinitely thin surfaces in intersections and differences
> to define the whole of your object is pushing past what POV-Ray - let us
> say - robustly supports.
Wouldn't a more robust fix focus on adding some thickness to the surfaces?
Use cylinders and boxes and CSG for one level, and then just stack the resulting
optimized unit with a loop...
Post a reply to this message
|
|
| |
| |
|
|
From: Thomas de Groot
Subject: Re: Accuracy with parametric: An infinite car garage
Date: 24 Oct 2014 10:38:28
Message: <544a6464$1@news.povray.org>
|
|
|
| |
| |
|
|
On 24-10-2014 2:19, Bald Eagle wrote:
> Wouldn't a more robust fix focus on adding some thickness to the surfaces?
> Use cylinders and boxes and CSG for one level, and then just stack the resulting
> optimized unit with a loop...
>
That's what I thought too. I have been playing a little bit with the
concept and came up with something like this:
//---------------------------------------------------------------------------
#include "functions.inc"
union {
difference {
cylinder {
<0,0,0>,<0,0.10,0>, 1.00
scale <1,1,1> rotate<0,0,0> translate<0,0,0>
}
difference {
prism {
-0.01, 0.11, 4
<-0.50, 0.00>, // first point
< 0.50, 0.00>,
< 0.00,-1.00>,
<-0.50, 0.00> // last point = first point !!!
scale <1.00, 1.00, 1.00>
rotate <0,0,0>
translate <0.00, 0.00, 1.00>
}
cylinder {
<0,-0.2,0>,<0,0.12,0>, 0.50
scale <1,1,1> rotate<0,0,0> translate<0,0,0>
}
} //end of difference
rotate 180*y
} //end of difference
intersection {
difference {
isosurface {
function {
f_helix1(
x,y,z,
1, // number of helixes, (1 = single helix, 2 = double
helix etc.)
2, // period, turns on the length of 2*pi
0.5, // minor radius,
0.90, // major radius,
0.15, // shape parameter,
0, // cross section type, (0.0 to 1.0 = square ...
rounded to circle
// over 2.0 to 3.0 = rounded to
diamond and concave diamond
0 // cross section rotation angle
)
}
contained_by {box {<-1,0,-1>,<1,2,1>}}
max_gradient 10
scale 1.0
rotate <0, -120, 0>
translate <0,0,0>
}
cylinder {<0,-0.01,0>,<0,10,0>,0.5}
} //end of difference
cylinder {<0.0,0>,<0,10,0>,1}
} //end of intersection
texture {
pigment {color rgb <1,1,0.8> }
normal {bumps 0.1 scale <0.005,0.005,0.005>}
finish { phong 0.5 reflection{ 0.00 metallic 0.00} }
}
rotate 25*y
} //end of union
//---------------------------------------------------------------------------
The most difficult to control imo is the isosurface. Some more
documentation in addition to the POV-Ray docs and Mike Williams'
explanation (http://www.econym.demon.co.uk/isotut/builtin1.htm) would be
welcome in fact.
Thomas
Post a reply to this message
|
|
| |
| |
|
|
From: Thomas de Groot
Subject: Re: Accuracy with parametric: An infinite car garage
Date: 25 Oct 2014 07:23:30
Message: <544b8832$1@news.povray.org>
|
|
|
| |
| |
|
|
On 24-10-2014 16:38, Thomas de Groot wrote:
> The most difficult to control imo is the isosurface. Some more
> documentation in addition to the POV-Ray docs and Mike Williams'
> explanation (http://www.econym.demon.co.uk/isotut/builtin1.htm) would be
> welcome in fact.
Much easier is using Tim Attwood's spring.inc macro, to be found in the
Object Collection.
//---------------------------------------------------------------------------
#include "functions.inc"
union {
difference {
cylinder {
<0,0,0>,<0,0.10,0>, 1.00
scale <1,1,1> rotate<0,0,0> translate<0,0,0>
}
difference {
prism {
-0.01, 0.11, 4
<-0.50, 0.00>, // first point
< 0.50, 0.00>,
< 0.00,-1.00>,
<-0.50, 0.00> // last point = first point !!!
scale <1.00, 1.00, 1.00>
rotate <0,0,0>
translate <0.00, 0.00, 1.00>
}
cylinder {
<0,-0.2,0>,<0,0.12,0>, 0.50
scale <1,1,1> rotate<0,0,0> translate<0,0,0>
}
} //end of difference
rotate 27*y
} //end of difference
#include "spring.inc"
// The spring is created with it's base on the origin, oriented on
the +X axis
// U and V are the rectangular width and height of the spring wire
// X_Length is the overall length of the spring
// Radius is the radius of the spring
// Coils is the number of turns the spring makes (fractional numbers
are OK)
// Rez is the approximate number of desired triangles in the mesh.
object {
// U, V, length, radius, coils, rez
Spring (0.1, 0.5, 1, 1.0, 0.5, 5000)
/*texture {
pigment {color rgb <1,1,0.2> }
normal {bumps 0.1 scale <0.005,0.005,0.005>}
finish { phong 0.5 reflection{ 0.00 metallic 0.00} }
}*/
rotate 90*z
rotate 90*y
translate <0,0,0>
}
texture {
pigment {color rgb <1,1,0.8> }
normal {bumps 0.1 scale <0.005,0.005,0.005>}
finish { phong 0.5 reflection{ 0.00 metallic 0.00} }
}
rotate 160*y
} //end of union
//---------------------------------------------------------------------------
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|