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

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

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

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

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