I'd say that a bicone is a poor representation of HSL anyways...
it doesn't have a 1:1 mapping of points, points in the bicone
can't be inverted to refer to a particular HSL vector. Though
for artistic reasons it makes some sense to leave out repeated
colors... who needs multiple white vectors?

Try this code, it uses vector macros instead of parametric
functions... (that should avoid the crashes too)

#include "colors.inc"

camera {
   location  <0.0, 1.0, -4.0>
   direction 1.5*z
   right     x*image_width/image_height
   look_at   <0.0, 0.0,  0.0>
}

background {Gray50}

#declare bicone_r = 1;
#declare bicone_h = 2;
#macro bicone(H,S,L)
   (vrotate(<S,0,0>,<0,H,0>)*(1-abs((L-0.5)*2))*bicone_r +L*y*bicone_h)
#end

union {
#declare Hue_Count = 0;
#while (Hue_Count < 360)
   #declare Sat_Count = 0;
   #while (Sat_Count <= 1)
      #declare Lum_Count = 0;
      #while (Lum_Count <= 1)

         #local HSLLOC = bicone(Hue_Count,Sat_Count,Lum_Count);
         #local C = CHSL2RGB(<Hue_Count,Sat_Count,Lum_Count>);

         difference {
         sphere {HSLLOC,0.05}
            box{<0,-2,-2>,<2,3,0>}
            pigment{color C}
            finish {ambient 1}
         }
         #declare Lum_Count=Lum_Count+1/20;
      #end
      #declare Sat_Count=Sat_Count+1/8;
   #end
   #declare Hue_Count=Hue_Count+12;
#end
  rotate <0,45,0>
  translate <0,-bicone_h/2,0>
}

Post a reply to this message

"Tim Attwood" <tim### [at] comcastnet> wrote:
> I'd say that a bicone is a poor representation of HSL anyways...
> it doesn't have a 1:1 mapping of points, points in the bicone
> can't be inverted to refer to a particular HSL vector. Though
> for artistic reasons it makes some sense to leave out repeated
> colors... who needs multiple white vectors?

The point of the debate is that they want to remove a spherical model (a simple
mapping of the HSL vectors to spherical coordinates) from the article. The
image was eventually removed for being "original research" (which it is), but
they're continuing to debate its merits as well as the merits of their own. The
debate is getting kind of tiresome, and I'm thinking of backing out and cutting
my losses.

> Try this code, it uses vector macros instead of parametric
> functions... (that should avoid the crashes too)

Thanks for the cone, but I'm trying to render the particular model (some weird
construction designed to meet the specifications of one of the references)
described in the image I linked to. Here's the fixed version of the code (there
was a problem with the loops):

#local cone_max_h = 12;
#local cone_max_s = 6;
#local cone_max_l = 6;
#local cone_interval_h = 360/cone_max_h;
#local cone_interval_s =   1/cone_max_s;
#local cone_interval_l =   1/cone_max_l;
#local cone_max_i = 1000;

#local cone_count_h = 0;
#while (cone_count_h < cone_max_h)
 #local cone_h = cone_count_h * cone_interval_h;
 #local cone_count_s = 0;
 #while (cone_count_s < cone_max_s)
  #local cone_s = cone_count_s * cone_interval_s;
  #local cone_count_l = 0;
  #while (cone_count_l < cone_max_l)
   #local cone_l = cone_count_l * cone_interval_l;
   #local new_var = 2 * cone_l - 1;
   #local f_of_new_var = sqrt(1 - pow(new_var, 2));
   #local x_coo = f_of_new_var * cone_s * cosd(cone_h);
   #local y_coo = f_of_new_var * cone_s * sind(cone_h);
   #local z_coo = new_var;
   sphere
   {
    < x_coo, z_coo, y_coo>, 0.05
    texture
    {
     pigment {rgb CHSL2RGB(<cone_h, cone_s, cone_l>)}
    }
   }
   #local cone_count_l = cone_count_l + 1;
  #end
  #local cone_count_s = cone_count_s + 1;
 #end
 #local cone_count_h = cone_count_h + 1;
#end

Post a reply to this message

> As for the crashes, I don't know what is causing them. Usually, if there's a
> typo or some error in copying and pasting text into the edit window, the
> program will simply quit parsing and give a minor error in the status bar or
> "Messages" tab.

Please post the *whole* .pov file you're using. I want to try 
reproducing it. What OS and what version of POV-Ray?

Post a reply to this message