Hi

I was wondering if there is a simple way
to draw a helix on a sinus. Instead of having a straigh helix
we should have a helix that would follow a sine function. It seems
hard but may be I am not optimising the code. so far it is not working

regards

Post a reply to this message

sahraoui nous apporta ses lumieres en ce 29-03-2007 08:25:
> Hi

> I was wondering if there is a simple way
> to draw a helix on a sinus. Instead of having a straigh helix
> we should have a helix that would follow a sine function. It seems
> hard but may be I am not optimising the code. so far it is not working

> regards

Using an iso_surface with the helix function, you just need to add the sin wave 
with the correct amplitude and wave length. Using a sin and a cosin, you can 


-- 
Alain
-------------------------------------------------
WARNING: The consumption of alcohol is a major factor in dancing like a retard.

Post a reply to this message

Wasn't it Alain who wrote:
>sahraoui nous apporta ses lumieres en ce 29-03-2007 08:25:
>> Hi
>
>> I was wondering if there is a simple way
>> to draw a helix on a sinus. Instead of having a straigh helix
>> we should have a helix that would follow a sine function. It seems
>> hard but may be I am not optimising the code. so far it is not working
>
>> regards
>
>Using an iso_surface with the helix function, you just need to add the sin wave 
>with the correct amplitude and wave length. Using a sin and a cosin, you can 


The problem is that if you just replace x with (x+A*sin(B*y)) in the
parameters of f_helix1, it also distorts the cross section and looks
rather ugly.

You can get away with it if the minor radius is very small, like this:

#include "functions.inc"
camera { location  <0, 4, -10> look_at <0, 0, 0> angle 35}
light_source {<-100,200,-100> colour rgb 1}
isosurface {
  function { f_helix1((x+sin(y*2)*0.4),y,z,1,50,0.02,0.6,1,1,0) }
  max_gradient 1.5
  contained_by{sphere {0,2}}
  pigment {rgb 1}
}

but it just looks wrong if the minor radius is larger

#include "functions.inc"
camera { location  <0, 1, -10> look_at <0, 0, 0> angle 35}
light_source {<-100,200,-100> colour rgb 1}
isosurface {
  function { f_helix1((x+sin(y*2)*0.4),y,z,1,15,0.1,0.6,1,1,0) }
  max_gradient 1.5
  contained_by{sphere {0,2}}
  pigment {rgb 1}
}

What you'd have to do to make it look right is to obtain the actual
equation of the helix and apply the variable substitution to the x
factors that affect the path of the helix but not to those that affect
the cross section.

I couldn't find the equation for a helix surface anywhere. Searches just
get bogged down with huge numbers of sites that have the equations for a
helicoid surface or a helical curve. I suppose one could read the POV
source code of f_helix1, but I suspect it might be rather messy because
of all the extra parameter options that you're probably not interested
in.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

Mike Williams <nos### [at] econymdemoncouk> wrote:
> I couldn't find the equation for a helix surface anywhere. Searches just
> get bogged down with huge numbers of sites that have the equations for a
> helicoid surface or a helical curve.
>
> --
> Mike Williams
> Gentleman of Leisure
Or one could look in one's own site! ;-) I googled for an hour or so but if
there are any good hits they are hidden very well indeed. Then I stumbled
on one of your zips that sure enough contained the following:

//Helix

camera { location  <0, 0, -30> look_at <0, 0, 0> angle 10}

sky_sphere { pigment {
    function{abs(y)}
    color_map { [0.0 color blue 0.6] [1.0 color rgb 1] }
  }
}

light_source {<100,200,-100> colour rgb 1}
light_source {<-100,-200,-100> colour rgb 0.5}


#declare H=0.3;
#declare R=0.2;

#declare Fx = function(u,v){(1-R*cos(v))*cos(u) }
#declare Fy = function(u,v){(1-R*cos(v))*sin(u) }
#declare Fz = function(u,v){ R*(sin(v)) + u*H }

#include "param.inc"


object {Parametric(Fx,Fy,Fz,<-10,0>,<10,2*pi>,100,20,"")
  pigment {uv_mapping checker rgb 0.95 rgb 0.85 scale 0.25}
  finish {phong 0.5 phong_size 10}
  rotate y*60
  no_shadow
}

Post a reply to this message

With this algorithm you cannot fix the origin
of the helix.
You cannot put them on a lattice for example.



"Grassblade" <nomail@nomail> wrote:
> Mike Williams <nos### [at] econymdemoncouk> wrote:
> > I couldn't find the equation for a helix surface anywhere. Searches just
> > get bogged down with huge numbers of sites that have the equations for a
> > helicoid surface or a helical curve.
> >
> > --
> > Mike Williams
> > Gentleman of Leisure
> Or one could look in one's own site! ;-) I googled for an hour or so but if
> there are any good hits they are hidden very well indeed. Then I stumbled
> on one of your zips that sure enough contained the following:
>
> //Helix
>
> camera { location  <0, 0, -30> look_at <0, 0, 0> angle 10}
>
> sky_sphere { pigment {
>     function{abs(y)}
>     color_map { [0.0 color blue 0.6] [1.0 color rgb 1] }
>   }
> }
>
> light_source {<100,200,-100> colour rgb 1}
> light_source {<-100,-200,-100> colour rgb 0.5}
>
>
> #declare H=0.3;
> #declare R=0.2;
>
> #declare Fx = function(u,v){(1-R*cos(v))*cos(u) }
> #declare Fy = function(u,v){(1-R*cos(v))*sin(u) }
> #declare Fz = function(u,v){ R*(sin(v)) + u*H }
>
> #include "param.inc"
>
>
> object {Parametric(Fx,Fy,Fz,<-10,0>,<10,2*pi>,100,20,"")
>   pigment {uv_mapping checker rgb 0.95 rgb 0.85 scale 0.25}
>   finish {phong 0.5 phong_size 10}
>   rotate y*60
>   no_shadow
> }

Post a reply to this message

sahraoui nous apporta ses lumieres en ce 02-04-2007 14:44:
> With this algorithm you cannot fix the origin
> of the helix.
> You cannot put them on a lattice for example.


You can rotate and translate any parametric. But stay warned that parametric is 
about the slowest primitive available. Using the precompute keyworld can 
significatively accelerate the rendering.
The maximum value you can use is: precompute 20 x,y,z
It does use a good amount of memory, but that memory is shared by all instances 
of that particular parametric object.


-- 
Alain
-------------------------------------------------
Educate and inform the whole mass of the people... They are the only sure
reliance for the preservation of our liberty.
Thomas Jefferson

Post a reply to this message

I agree that you can rorate them and move them
but I don;t see where is the orrigin
of the object in the parametric form.
In the case of sphere for instance you
say sphere {<0,0,0>..bla bla}
and you know that you start from there your
lattice
I also noticed that parametric is very very slow

thanks

Alain <ele### [at] netscapenet> wrote:
> sahraoui nous apporta ses lumieres en ce 02-04-2007 14:44:
> > With this algorithm you cannot fix the origin
> > of the helix.
> > You cannot put them on a lattice for example.
>
>
> You can rotate and translate any parametric. But stay warned that parametric is
> about the slowest primitive available. Using the precompute keyworld can
> significatively accelerate the rendering.
> The maximum value you can use is: precompute 20 x,y,z
> It does use a good amount of memory, but that memory is shared by all instances
> of that particular parametric object.
>
>
> --
> Alain
> -------------------------------------------------
> Educate and inform the whole mass of the people... They are the only sure
> reliance for the preservation of our liberty.
> Thomas Jefferson

Post a reply to this message

In the code listed above, the centre of the helix is at <0,0,0>. 

Without the "rotate y*60" z would go from -10*H-R to +10*H+R.
x and y would go from -(1+R) to 1+R.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

What about this code


#declare ObjectSpline = create_spline (
   array[4] {<-2, 0, 0>, <0, 15, 5>, <2, 1, 0>, <0, 15,5>},
   create_hermite_spline)


//create_spline_object (ObjectSpline, default_options)

union {coil_spline (ObjectSpline, spline_steps (60)
   + spline_radius (1.2)
   + coil_radius (0.05))
   pigment {rgb <1, 0, 0>}
   finish {phong 0.6}
   }

I am still not at ease with splines. Your code also creat a spline right?
where you used sphere_sweep and b_spline
Where can i find a literature about these two commands.

thanks

Mike Williams <nos### [at] econymdemoncouk> wrote:
> In the code listed above, the centre of the helix is at <0,0,0>.
>
> Without the "rotate y*60" z would go from -10*H-R to +10*H+R.
> x and y would go from -(1+R) to 1+R.
>
> --
> Mike Williams
> Gentleman of Leisure

Post a reply to this message

Forget about the question on b_spline

I am reading the documentation



Mike Williams <nos### [at] econymdemoncouk> wrote:
> In the code listed above, the centre of the helix is at <0,0,0>.
>
> Without the "rotate y*60" z would go from -10*H-R to +10*H+R.
> x and y would go from -(1+R) to 1+R.
>
> --
> Mike Williams
> Gentleman of Leisure

Post a reply to this message