Hadmut Danisch <had### [at] danischde> wrote:
> Mike Williams wrote:
>
> >  texture {
> >   pigment {radial frequency 30
> >     colour_map{[0.1 rgb 1][0.1 rgbt <0,0,0,1>]}
> >   }
>
>
> Just a little detail problem:
>
> while this does what I am looking for in principle, there's one
> problem: The line is not of constant width. The closer it gets to the
> poles, the smaller it gets, like a slice of cake. Becomes highly visible
> when the frequence gets lower, e.g. frequency 4
>
> regards
> Hadmut


Try this code, it combines a gradient with a spherical warp for the lat lines
with cylinder-based object pattern for the long lines.  The lat and long grid
line widths are constant and definable in width (along the arclength even).

Feel free to pick it apart and modify it as needed.

-tgq

//START
#declare LatDiv=8;    //Number of Latitude divisions, used for long too (degrees
= 90/LatDiv)
#declare GRDTHK=0.01;  //Line thickness for 1 unit radius sphere

#declare AA=GRDTHK*LatDiv/2/(pi*2/4);

#declare PLat=
pigment{
  gradient
  y
  colour_map{
    [AA rgb 0]
    [AA rgb 1]
    [1-AA rgb 1]
    [1-AA rgb 0]
  }
  frequency LatDiv*2

  warp {
    spherical
  }
}

#declare LONG=
union{
  #local i=0;#while(i<180)
    cylinder{-z*sin(GRDTHK/2),z*sin(GRDTHK/2),1.1 rotate y*i}
  #local i=i+90/LatDiv;#end
}

#declare PGrid=
pigment{
  object{
    LONG
    pigment{PLat}
    pigment{rgb 0}
  }
}

sphere{0,1
  pigment{PGrid}
  scale 340
}
//END

Post a reply to this message

Wasn't it Hadmut Danisch who wrote:
>Mike Williams wrote:
>
>>  texture {
>>   pigment {radial frequency 30
>>     colour_map{[0.1 rgb 1][0.1 rgbt <0,0,0,1>]}
>>   }
>
>
>Just a little detail problem:
>
>while this does what I am looking for in principle, there's one
>problem: The line is not of constant width. The closer it gets to the
>poles, the smaller it gets, like a slice of cake. Becomes highly visible
>when the frequence gets lower, e.g. frequency 4

Here's one where the lines are constant width. It's significantly
slower.


#declare Longs =10;     // number of longitude lines : should be > 3
#declare Lats = 10;     // number of latitude lines  : must be even
 
#declare LongW = Longs/200;                    

#include "functions.inc"

sphere {0,1
  texture{
    pigment {function {f_ph(x,y,z)*(Longs-1)/2}
      colour_map{[LongW rgb 1][LongW rgb 0]}
    }      
  }
  #declare th=0;
  #while (th<180)
    texture {
      pigment {function {abs(x)}
        colour_map{[0.01 rgb 1][0.01 rgbt 1]}
        scale 1.02
        rotate y*th
      }
    }      
    #declare th = th+(360/Lats);
  #end 
}



Watch out for that  "scale 1.02"  If you don't have it, you sometimes
get some white circles at the edges.

The "function {abs(x)}" looks slightly better than "gradient x". If you
use "gradient x" then the gap next to the line at 180 degrees looks
slightly different from all the others. I'm not sure why.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

47377c4d@news.povray.org...
>
> Why not build your lines with some tori and make an object_pattern with 
> them?
> You could keep constant width lines that way.
>
> Marc

#include "colors.inc"
#include"math.inc"

global_settings {
  assumed_gamma 1.0
}

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

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



light_source {
  <0, 0, 0>            // light's position (translated below)
  color rgb <1, 1, 1>  // light's color
  translate <-30, 30, -30>
}

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

#declare Sphere_rad=1;
#declare Line_width=0.0025;
#declare Long_number=24;
#declare Lat_number=12;

//construction of the longitude lines
#declare Line_long=torus{Sphere_rad,Line_width rotate x*90}
#declare Cnt_long=0;
#declare Long=union{
#while(Cnt_long<Long_number)
object{Line_long rotate y*360*Cnt_long/Long_number}
#declare Cnt_long=Cnt_long+1;
#end
}

//construction of the latitude lines
#declare Cnt_lat=0;
#declare Lat=union{
#while (Cnt_lat< Lat_number)
torus{Sphere_rad*cosd(90*Cnt_lat/Lat_number),Line_width translate 
y*Sphere_rad*sind(90*Cnt_lat/Lat_number)}
#declare Cnt_lat=Cnt_lat+2;
#end
}

#declare Lines=union{
object{Long}
object{Lat}  //North hemisphere
object{Lat scale<1,-1,1>} //South hemisphere
}

sphere {
  0.0, Sphere_rad
  texture {
    pigment{
  object {
    Lines
    color rgb <0,0,0.5>,      // outside object
    color rgb <0,1,0>       // inside object
  }

}
    finish{
      specular 0.6
    }
  }
}

Post a reply to this message

47380442$1@news.povray.org...
>
> //construction of the longitude lines
> #declare Line_long=torus{Sphere_rad,Line_width rotate x*90}
> #declare Cnt_long=0;
> #declare Long=union{
> #while(Cnt_long<Long_number)
> object{Line_long rotate y*360*Cnt_long/Long_number}
> #declare Cnt_long=Cnt_long+1;
> #end
> }
ooops should be :
object{Line_long rotate y*180*Cnt_long/Long_number}


Marc

Post a reply to this message

"Chris B" <nom### [at] nomailcom> wrote:
> That's the problem that the one on
> http://lib.povray.org/searchcollection/index.php is designed to avoid
> (search for 'GridLines').
>
> Regards,
> Chris B.

Here's a challenge: someone adapt the above code to create gridlines such as the
ones found in this imag (http://en.wikipedia.org/wiki/Image:HSLSphere.svg).

Post a reply to this message

"SharkD" <nomail@nomail> wrote in message 
news:web.4783e426a8d0eaae458a4ca0@news.povray.org...
> "Chris B" <nom### [at] nomailcom> wrote:
>> That's the problem that the one on
>> http://lib.povray.org/searchcollection/index.php is designed to avoid
>> (search for 'GridLines').
>>
>> Regards,
>> Chris B.
>
> Here's a challenge: someone adapt the above code to create gridlines such 
> as the
> ones found in this imag 
> (http://en.wikipedia.org/wiki/Image:HSLSphere.svg).
>

I'm not really sure what you're requesting.

The SDL above already generates grid lines similar to the grid lines in the 
image you've linked to.

Do you just want the colour or spacing to be different or is it that you 
want a colour chart rather than the grid lines themselves, or is it the 
inset quadrant in each of the two spheres that you're trying to achieve?

Also, is this just a challenge as some sort of exercise that you're setting, 
or do you have some practical use for whatever it is you're asking for?

Regards,
Chris B.

Post a reply to this message

"Chris B" <nom### [at] nomailcom> wrote:
> "SharkD" <nomail@nomail> wrote in message
> news:web.4783e426a8d0eaae458a4ca0@news.povray.org...
> >
> > Here's a challenge: someone adapt the above code to create gridlines such
> > as the
> > ones found in this imag
> > (http://en.wikipedia.org/wiki/Image:HSLSphere.svg).
> >
>
> I'm not really sure what you're requesting.
>
> The SDL above already generates grid lines similar to the grid lines in the
> image you've linked to.
>
> Do you just want the colour or spacing to be different or is it that you
> want a colour chart rather than the grid lines themselves, or is it the
> inset quadrant in each of the two spheres that you're trying to achieve?
>
> Also, is this just a challenge as some sort of exercise that you're setting,
> or do you have some practical use for whatever it is you're asking for?
>
> Regards,
> Chris B.

I'd like the grid lines to exist /within/ the sphere, as well as on the surface.
Currently, if I cut a corner away from the sphere, the cut-away portion is
completely opaque (dark green in this case, black if I use Trevor G Quayle's
code).

It's a personal request. I'd like to replace the SVG image with a nicely
rendered one, as the SVG image was removed from an article for being "too ugly"
(kind of a stupid reason to remove a diagram from an encyclopedia, but
anyway...).

Post a reply to this message

> It's a personal request. I'd like to replace the SVG image with a nicely
> rendered one, as the SVG image was removed from an article for being "too ugly"
> (kind of a stupid reason to remove a diagram from an encyclopedia, but
> anyway...).

And a "nicely rendered one" wouldn't be scalable. The only way to keep 
both advantages would be rendering it in POV-Ray, then manually 
"vectorizing" it.

Post a reply to this message

"SharkD" <nomail@nomail> wrote in message
> ... snip ...
> I'd like the grid lines to exist /within/ the sphere, as well as on the 
> surface.
> Currently, if I cut a corner away from the sphere, the cut-away portion is
> completely opaque (dark green in this case, black if I use Trevor G 
> Quayle's
> code).
>

Actually I think the grid lines do exist within the sphere and I suspect 
that this is why you get a green or black surface in your cut-away. If the 
cut surfaces align with a horizontal line (eg. latitude 0 degrees) and two 
of the longitudinal lines (e.g. 0 and 90 degrees) then you'll get the colour 
of the grid lines (assuming you apply the one texture to the whole object).

One way of resolving that would be to shift the horizontal lines up by half 
the current separation and rotate the sphere around the vertical axis by 
half a segment. Another would be to specify an appropriate texture of your 
choice to the object doing the cutting. e.g. a displaced and rotated 
gridline texture combined with an onion texture to give you the concentric 
spheres.

> It's a personal request. I'd like to replace the SVG image with a nicely
> rendered one, as the SVG image was removed from an article for being "too 
> ugly"
> (kind of a stupid reason to remove a diagram from an encyclopedia, but
> anyway...).
>

If it's an ugliness problem then presumably you don't want to just reproduce 
something that's very similar to what you've got. Also, I agree with Nicolas 
that a rendered image with grid-lines wouldn't scale as well as a vector 
graphics image will, resulting in less clarity and potentially some of the 
lines disappearing as it gets scaled down or uneven thickening as it gets 
scaled up. You may want to consider keeping the lines from the existing SVG 
file overlayed on top of prettier bitmapped spheres.

You could probably do smoothly graded spheres in POV-Ray using orthographic 
projection and only ambient lighting, but I thought it was also possible to 
do such colour grading in an SVG editor.

Hope there's something in all that that's helpful.

Regards,
Chris B.

Post a reply to this message

"Chris B" <nom### [at] nomailcom> wrote:
> "SharkD" <nomail@nomail> wrote in message
> > ... snip ...
> > I'd like the grid lines to exist /within/ the sphere, as well as on the
> > surface.
> > Currently, if I cut a corner away from the sphere, the cut-away portion is
> > completely opaque (dark green in this case, black if I use Trevor G
> > Quayle's
> > code).
> >
>
> Actually I think the grid lines do exist within the sphere and I suspect
> that this is why you get a green or black surface in your cut-away. If the
> cut surfaces align with a horizontal line (eg. latitude 0 degrees) and two
> of the longitudinal lines (e.g. 0 and 90 degrees) then you'll get the colour
> of the grid lines (assuming you apply the one texture to the whole object).
>
> One way of resolving that would be to shift the horizontal lines up by half
> the current separation and rotate the sphere around the vertical axis by
> half a segment. Another would be to specify an appropriate texture of your
> choice to the object doing the cutting. e.g. a displaced and rotated
> gridline texture combined with an onion texture to give you the concentric
> spheres.
>
> > It's a personal request. I'd like to replace the SVG image with a nicely
> > rendered one, as the SVG image was removed from an article for being "too
> > ugly"
> > (kind of a stupid reason to remove a diagram from an encyclopedia, but
> > anyway...).
> >
>
> If it's an ugliness problem then presumably you don't want to just reproduce
> something that's very similar to what you've got. Also, I agree with Nicolas
> that a rendered image with grid-lines wouldn't scale as well as a vector
> graphics image will, resulting in less clarity and potentially some of the
> lines disappearing as it gets scaled down or uneven thickening as it gets
> scaled up. You may want to consider keeping the lines from the existing SVG
> file overlayed on top of prettier bitmapped spheres.
>
> You could probably do smoothly graded spheres in POV-Ray using orthographic
> projection and only ambient lighting, but I thought it was also possible to
> do such colour grading in an SVG editor.
>
> Hope there's something in all that that's helpful.
>
> Regards,
> Chris B.

The grid lines do go all the way through.  What he is referring to is the
concentric layer lines.

This should be fairly easy to do.  A few notes:

1) The Longitudinal lines are fine, they are already a constant thickness
through.

2) The latitude lines are from a spherical map, so they will radiate to the
center as needed, but they aren't constant thickness.  better to replace them
with another object pattern made from appropriately sized and offset cones.

3) For the concentric layer lines, a simple onion pattern should suffice.

4) A note on offsetting though. In the image, the lines aren't at the quadrants,
but rather the colour grids are centered on them, all grid lines should be
shifted accordingly. (This is why you get solid black when cutting though the
quadrant)

5) Unfortunately you will get thicker lines at the the center axis from the skew
of the longitudinal lines.  This really can't be avoided if you want to maintain
a constant thickness in the planes.  Perhaps they could be stopped short of the
center axis to prevent this.

6) Regarding 5), perhaps you don't need the separating grid lines for the
graphic, just the colour stepping alone (or even a constant gradient)would work
best.  You could still highlight the cutout edges with black lines though (again
using an object pattern)

7) For the colour gradient, you could use a simple macro for the cells, however
you could also use the HSL->RGB functions I posted in a different thread (look
for the thread regarding colour spaces and colour interpolation).  These
functions can be used to create a continous gradient function or modified to
give a stepped gradient.

I already started throwing some of the stuff together and may be able to post
something tomorrow.

-tgq

Post a reply to this message