Hi,

How can I add 'true-indexed' RGB color to each point along a "sphere_sweep"
object? In other words, if this "sphere_sweep" object is defined by N points, I
would like to be able to specify N RGB colors.

Many thanks in advance for helping me out!

Cheers,
Alex

Post a reply to this message

"Alex" <ale### [at] hotmailcom> wrote in message 
news:web.4a82745d1c23c4f8db8ca50@news.povray.org...
> Hi,
>
> How can I add 'true-indexed' RGB color to each point along a 
> "sphere_sweep"
> object? In other words, if this "sphere_sweep" object is defined by N 
> points, I
> would like to be able to specify N RGB colors.
>
> Many thanks in advance for helping me out!
>
> Cheers,
> Alex
>

I don't think there's an easy way of doing exactly that. OTOH you can do 
something equivalent using splines and a #while loop quite easily. The 
spline example below is taken straight from the spline section in the help 
and illustrates using different colors along the length of an object created 
using lots of spheres (in this case about 100). It shouldn't be too 
difficult to adapt that to do something equivalent to what you ask.

camera {location <-1, 1,-1> look_at <0,0,0>}
light_source {<1,10,-1> color rgb 1}

#declare MySpline = spline {
  cubic_spline
  -.25, <0,0,-1>
  0.00, <1,0,0>
  0.25, <0,0,1>
  0.50, <-1,0,0>
  0.75, <0,0,-1>
  1.00, <1,0,0>
  1.25, <0,0,1>
}

#declare ctr = 0;
#while (ctr < 1)
  sphere {
    MySpline(ctr),.25
    pigment { rgb <1-ctr,ctr,0> }
  }
  #declare ctr = ctr + 0.01;
#end


Regards,
Chris B.

Post a reply to this message

"Chris B" <nom### [at] nomailcom> wrote:
> "Alex" <ale### [at] hotmailcom> wrote in message
> news:web.4a82745d1c23c4f8db8ca50@news.povray.org...
> > Hi,
> >
> > How can I add 'true-indexed' RGB color to each point along a
> > "sphere_sweep"
> > object? In other words, if this "sphere_sweep" object is defined by N
> > points, I
> > would like to be able to specify N RGB colors.
> >
> > Many thanks in advance for helping me out!
> >
> > Cheers,
> > Alex
> >
>
> I don't think there's an easy way of doing exactly that. OTOH you can do
> something equivalent using splines and a #while loop quite easily. The
> spline example below is taken straight from the spline section in the help
> and illustrates using different colors along the length of an object created
> using lots of spheres (in this case about 100). It shouldn't be too
> difficult to adapt that to do something equivalent to what you ask.
>
> camera {location <-1, 1,-1> look_at <0,0,0>}
> light_source {<1,10,-1> color rgb 1}
>
> #declare MySpline = spline {
>   cubic_spline
>   -.25, <0,0,-1>
>   0.00, <1,0,0>
>   0.25, <0,0,1>
>   0.50, <-1,0,0>
>   0.75, <0,0,-1>
>   1.00, <1,0,0>
>   1.25, <0,0,1>
> }
>
> #declare ctr = 0;
> #while (ctr < 1)
>   sphere {
>     MySpline(ctr),.25
>     pigment { rgb <1-ctr,ctr,0> }
>   }
>   #declare ctr = ctr + 0.01;
> #end
>
>
> Regards,
> Chris B.

Thanks Chris,

Some follow up questions:

* In the documentation, I cannot really find any info on the first parameter of
the spline function (-.25, 0.00, etc.). What does is do? With sphere_sweep I
don't need to define these values...

* I already have predefined matrices (N x 3) of colors and of "sphere widths".
How do I add them to the scene (instead of calculating them on the fly)?

* I am also worried about efficiency, as I am modelling many objects of this
kind: let's say 10000 "hyperstreamtubes" (a sphere_sweep object with variable
width), with each these consisting of 100 points. Here you can see an example:
http://www.exploredti.com/gallery/gof_2.htm

Cheers,
-A

Post a reply to this message

Wasn't it Alex who wrote:
>* In the documentation, I cannot really find any info on the first
>parameter of the spline function (-.25, 0.00, etc.). What does is do?
>With sphere_sweep I don't need to define these values...

You do if you're using cubic_spline mode of sphere_sweep.

A cubic spline can only be calculated between the second and
next-to-last of the control points, so a phantom point needs to be added
at each end.

If you really don't have such extra points in your sphere_sweep, then I
guess that means that you're using linear_spline mode. In that case
using cones and cylinders, with spheres at the nodes for neat joins, is
more efficient than hundreds of spheres.

>* I am also worried about efficiency, as I am modelling many objects of
>this kind: let's say 10000 "hyperstreamtubes" (a sphere_sweep object
>with variable width), with each these consisting of 100 points. Here
>you can see an example: http://www.exploredti.com/gallery/gof_2.htm

Sphere_sweeps are inherently not very efficient, because the algorithm
is quite complicated. You may well find that lots of simpler objects
render faster. Lots of simpler objects will bound better when you have
long strings like in that example.

However, lots of simple objects will always give you rounded edges. If
you want spiky edges like in that example, you might consider something
like the SweepSpline macro

See the bottom section of http://www.econym.demon.co.uk/isotut/more.htm

SweepSpline produces a mesh2 object which renders very quickly, but if
you've got lots of detail it may take a while to parse. You can save the
parsed mesh2 object to a file (see comments at the top of
sweepspline.inc) and skip the parse phase next time.

To colour a sweepspline along its length, use uv_mapping, like this:

object {
  SweepSpline(USpline, VSpline, WSpline, Upoints, Vpoints, Filename)
  texture {
    pigment { uv_mapping
      function{u}
      colour_map {...}
    }
  }
}

where the colour_map specifies the colours to be used along the length.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

"Mike Williams" <nos### [at] econymdemoncouk> wrote in message 
news:IDs### [at] econymdemoncouk...
> Wasn't it Alex who wrote:
>>* In the documentation, I cannot really find any info on the first
>>parameter of the spline function (-.25, 0.00, etc.). What does is do?
>>With sphere_sweep I don't need to define these values...
>
> You do if you're using cubic_spline mode of sphere_sweep.
>

I think Alex was referring to the 'val_1', 'val_2' parameters on the spline 
function. As Mike says, you will still need all of the same coordinates for 
points on the curve and for the control points for 'curved' curves, but the 
'val_n' settings are a feature specific to the spline function.

The best way I can explain it is that this value represents how far through 
the spline the point is and is usually defined so that the visible points 
lie from 0 to 1. Any additional control points that aren't on the curve 
(used at the start or end of a curve) can be defined using values less than 
0 or greater than 1, so the initial control point for the cubic spline was 
defined with a 'val_n' value of -0.25. You can more or less define whatever 
spacing you want with these values, but the example #while loop that I 
posted before assumed that the points were more or less evenly spaced 
distance-wise, so it simply incremented it's way along the spline using this 
value (The example below removes this assumption).

When you come to use a spline function you specify a number from 0 to 1 as a 
parameter and it returns the coordinate on the curve based on how the number 
you specify relates to the 'val_n' settings that the spline was defined 
with.

>
>>* I am also worried about efficiency, as I am modelling many objects of
>>this kind: let's say 10000 "hyperstreamtubes"
> Sphere_sweeps are inherently not very efficient, because the algorithm
> is quite complicated. You may well find that lots of simpler objects
> render faster. Lots of simpler objects will bound better when you have
> long strings like in that example.
>
> However, lots of simple objects will always give you rounded edges. If
> you want spiky edges like in that example, you might consider something
> like the SweepSpline macro
>
> See the bottom section of http://www.econym.demon.co.uk/isotut/more.htm
>

Mike's macro looks like it will give you by far the best performance, 
especially with the option to store the generated mesh to disk to cut down 
on parse times. The mesh2 object is very efficient and a uv_mapped color_map 
is likely to be the easiest way of using the N*3 color matrices that you 
mentioned. Using 1000 spheres for each of 10,000 "hyperstreamtubes" would 
probably be slow, particularly if your machine starts paging. Nevertheless 
I've pasted a short example using the "lots of spheres" approach below my 
signature in case this is of any interest.


Regards,
Chris B.



camera {location <-1, 1,-2> look_at <1,0.3,0>}
light_source {<1,10,-1> color rgb 1}

#declare PointCount = 6;
#declare SeparationRatio = 0.01;
#declare Segments = PointCount-1;

#declare Spline = spline {
  cubic_spline
  -0.25, <0   ,-1  ,0>
   0.0 , <0   , 0  ,0>
   0.18, <1.4 , 0.6,0>
   0.2 , <1.45, 0.6,0>
   0.4 , <1.5 , 0.6,0>
   0.6 , <1.55, 0.6,0>
   0.62, <1.6 , 0.6,0>
   0.8 , <2.5 , 0.5,0>
   1.0 , <3.5 , 0.5,0>
   1.25, <5   , 1  ,0>
}


#declare Colors = array [PointCount] {
  <1,0,0>, <1,1,0>,
  <0,1,0>, <0,1,1>,
  <0,0,1>, <1,0,1>
}


#declare Widths = array [PointCount] {
  0.02,0.01,0.08,0.02,0.005,0.02
}


// Loop through the spline
#declare Ctr = 0;
#declare Last_Point = Spline(-0.2);
#declare TargetSeparation = 0;
#while (Ctr < 1)
  // Work out distance from the previous point.
  #declare This_Point = Spline(Ctr);
  #declare Separation = vlength(This_Point-Last_Point);
  #if (Separation > TargetSeparation)
    // Work out relative distance between control point.
    #declare Proportions    = mod(Ctr*Segments,1);
    // Work out the color at this point
    #declare Previous_Color = Colors[floor(Ctr*Segments)];
    #declare Next_Color     = Colors[floor(Ctr*Segments)+1];
    #declare This_Color     = Previous_Color*(1-Proportions) + 
Next_Color*Proportions;
    // Work out the radius at this point
    #declare Previous_Size = Widths[floor(Ctr*Segments)];
    #declare Next_Size     = Widths[floor(Ctr*Segments)+1];
    #declare This_Size     = Previous_Size*(1-Proportions) + 
Next_Size*Proportions;
    // Add a sphere the right color and size
    sphere {
      This_Point,This_Size
      pigment { rgb This_Color}
    }
    #declare TargetSeparation = SeparationRatio*This_Size;
    #declare Last_Point = This_Point;
  #end
  #declare Ctr = Ctr + 0.0001;
#end


// Axes
cylinder {-10*x,10*x,0.01 pigment {rgb <1,0,1>}}
cylinder {-10*y,10*y,0.01 pigment {rgb <1,1,0>}}
cylinder {-10*z,10*z,0.01 pigment {rgb <0,1,1>}}

Post a reply to this message

Dear Mike and Chris,

Chris, I tried your script, but the transition between points with different
widths seems too abrupt (but thanks anyway!).

So I think I will use Mike's tool. However, I found a few things that 'bothered'
me here:

1) The spline that handles the width does not seem to correspond with the real
width (as obtained, for instance, with the 'sphere' object). Some spline issue?

2) The end point seems to be off (not at the right position) and varies, for
instance, according to the 'number-of-Upoints' parameter. Again, spline
related?

3) How do I close the tubes, i.e., put end-caps on it? I guess a sphere or
cylinder does the job, but it is not trivial, given point 1).


I added a toy example below - any suggestions on how to fine-tune the result
that tackles the issues above?

Again - much appreciated!

Alex

//--------------------

camera {orthographic  location  <3, 4, 10> look_at <3, 4, 0> angle 50}
light_source {<3,4,1000> colour rgb <1,1,1>}

#declare tube_width=0.3;

#declare USpline =
   spline {
     natural_spline  // using 'cubic_spline' gives an error?!
    0,    < 5, 6, 0>,
    0.25, < 4, 5, 0>,
    0.5,  < 3, 4, 0>,
    0.75, < 2, 3, 0>,
    1,    < 1, 2, 0>,
   }

// I added a few extra points to make it look more 'circular'...
#declare VSpline =
  spline {
    cubic_spline
   -0.125,  <0.7071,-0.7071,0>,
    0,     < 1, 0,0>,
    0.125,       <0.7071,0.7071,0>,
    0.25,  < 0, 1,0>,
    0.375,       <-0.7071,0.7071,0>,
    0.5,   <-1, 0,0>,
    0.625,       <-0.7071,-0.7071,0>,
    0.75,  < 0,-1,0>,
    0.875,       <0.7071,-0.7071,0>,
    1,     < 1, 0,0>,
    1.125,  <0.7071,0.7071,0>,
  }

#declare WSpline = spline {
  cubic_spline
    0,  tube_width,
    0.25,  tube_width,
    0.5,   5*tube_width,
    0.75,  tube_width,
    1,    tube_width,
 }

#declare Upoints = 50;  // change this to 10 and something strange happens (why
does it get shorter?)
#declare Vpoints = 50;  // Number of points around
#declare Filename = ""

#include "SweepSpline.inc"
object {
  SweepSpline(USpline, VSpline, WSpline, Upoints, Vpoints, Filename)
           pigment { uv_mapping
           function{u}
           colour_map {[0   rgb<1,0,0>]
                       [0.25 rgb<0,1,0>]
                       [0.5   rgb<1,0,1>]
                       [0.75   rgb<0,1,1>]
                       [1   rgb<1,1,0>]}}
           finish {phong 0.5 phong_size 10}
}

sphere {<5,6,0> ,tube_width  pigment { rgb <1,1,1> }}
sphere {<1, 2, 0> ,tube_width  pigment { rgb <1,1,1> }}

//--------------------

Post a reply to this message

"Alex" <ale### [at] hotmailcom> wrote in message 
news:web.4a82d669ff67402be81b49cc0@news.povray.org...
> Dear Mike and Chris,
>
> Chris, I tried your script, but the transition between points with 
> different
> widths seems too abrupt (but thanks anyway!).

Actually only the one change is abrupt and that's because I put 3 points 
close together and added a very large width change to demonstrate that it 
was possible to do abrupt changes. This was because the image you linked to 
contained some quite abrupt changes and I didn't want you to think it 
couldn't do 'abrupt'. Looks like I overemphasized this capability  :-).

Anyhow I think Mike's is the better way to go for what you want to do.

Regards,
Chris B.

Post a reply to this message

"Chris B" <nom### [at] nomailcom> wrote:
> "Alex" <ale### [at] hotmailcom> wrote in message
> news:web.4a82d669ff67402be81b49cc0@news.povray.org...
> > Dear Mike and Chris,
> >
> > Chris, I tried your script, but the transition between points with
> > different
> > widths seems too abrupt (but thanks anyway!).
>
> Actually only the one change is abrupt and that's because I put 3 points
> close together and added a very large width change to demonstrate that it
> was possible to do abrupt changes. This was because the image you linked to
> contained some quite abrupt changes and I didn't want you to think it
> couldn't do 'abrupt'. Looks like I overemphasized this capability  :-).
>
> Anyhow I think Mike's is the better way to go for what you want to do.
>
> Regards,
> Chris B.

Hi Chris,

You are right - sorry! And you do not seem to have these strange things
happening as mentioned earlier. So I might end up using your way. But how would
I adjust your tool for multiple "hyperstreamtubes"?

Cheers,
-A

Post a reply to this message

I figured it out - *macro's* !
Thanks again for the support!
Cheers,
-A

Post a reply to this message