Hello,

I'm developing a set of macros to load and manipulate 16-bit height 
field data. With them, you can import red/green 16-bit grayscale images 
and manipulate them as you would any other pigment. There are functions 
for finding edges (via a proximity pattern), finding angles for special 
effects, and even one for exporting red/green images to a few 24-bit 
image formats (to compensate for 3.7's rudimentary 16-bit support). They 
can be used to add features to existing height field data or to create 
new data. The pigments can be used in isosurfaces. I'm keeping my macros 
easy-to-use this time :)

Unfortunately, there are limitations. For one, POV-Ray's handling of 
image_maps produces strange edge artifacts, so I'm having to bring the 
edges of the images down to zero. This creates a sharp drop-off at the 
perimeter of the height field. It's not a feature I wanted.

Another problem is speed. A person would have to develop their height 
maps in a 2D fashion to avoid high parse times, but the macros *can* be 
used directly in a scene.

Considering these limitations, does anyone think they might find such an 
include file useful? I'm pretty much done with most of the functions, so 
all I need is one response so I can begin making example files!

~Sam

Post a reply to this message

stbenge wrote:
> Hello,
> 
  > Considering these limitations, does anyone think they might find 
such an
> include file useful? I'm pretty much done with most of the functions, so 
> all I need is one response so I can begin making example files!
> 
> ~Sam

That’s very kind of you Sam. Consider it requested :-)

-- 

Best Regards,
	Stephen

Post a reply to this message

stbenge wrote:

> I'm developing a set of macros to load and manipulate 16-bit height 
> field data. With them, you can import red/green 16-bit grayscale
> images and manipulate them as you would any other pigment.

I'm not sure I understand what these do. As far as I know,
Povray 3.6 already supports 16 bit png as input format both
for height fields and image_map pigments. Wouldn't that be
simpler to use than red/green tga?

> There are functions for finding edges (via a proximity pattern),
> finding angles for special effects

I can see these would be useful. Do they work on pigments which
encapsulate height information both in red and green channel or
do you linearize the data into a gray pigment? The latter case
would be more flexible as your processing functions will then
be independed of the height field image format.

> POV-Ray's handling of image_maps produces strange edge artifacts

What kind of edge artifacts do you mean?

Post a reply to this message

Christian Froeschlin wrote:
> stbenge wrote:
> 
>> I'm developing a set of macros to load and manipulate 16-bit height 
>> field data. With them, you can import red/green 16-bit grayscale
>> images and manipulate them as you would any other pigment.
> 
> I'm not sure I understand what these do. As far as I know,
> Povray 3.6 already supports 16 bit png as input format both
> for height fields and image_map pigments. Wouldn't that be
> simpler to use than red/green tga?

World Machine and TerraBrush use 16-bit tgas. In the version of WM I 
have, the option for png output is not supported yet. My attempts to 
convert a 16-bit tga to a png have not been successful; the data is 
still encoded with red and green colors, thus resulting in a high 
frequency mess. This probably wouldn't be true if I converted it using 
POV, but it's faster to use IrfanView :)

Regarding pngs, if a person were to supply a well-supported 16-bit png 
to some versions of my functions, then it should work out all right.

>> There are functions for finding edges (via a proximity pattern),
>> finding angles for special effects
> 
> I can see these would be useful. Do they work on pigments which
> encapsulate height information both in red and green channel or
> do you linearize the data into a gray pigment?

The macros will return straight grayscale data, be it 8 or 16-bit data. 
Some will load images (converting them to a grayscale pigment), and some 
will work directly with whatever pigment you provide for it, including 
pre-declared, processed images. All will return grayscale information 
which can then be encoded into a red/green height map if one wishes to 
do so.

>The latter case would be more flexible as your processing functions will then
>be independed of the height field image format.

My goal is to make the edge and angle functions work with any pigment, 
exporting to a few 16-bit pigments.

>> POV-Ray's handling of image_maps produces strange edge artifacts
> 
> What kind of edge artifacts do you mean?

It only appears at certain times, under certain conditions, when I 
convert images to functions. It's a single line of incorrect image info 
residing between units. I can try to reproduce the artifact. It happens 
with my luminous bloom code if I comment out the fixes I made.

Post a reply to this message

Stephen wrote:
> stbenge wrote:
>> Hello,
>>
>  > Considering these limitations, does anyone think they might find such an
>> include file useful? I'm pretty much done with most of the functions, 
>> so all I need is one response so I can begin making example files!
>>
>> ~Sam
> 
> That’s very kind of you Sam. Consider it requested :-)

:)

Post a reply to this message

"stbenge" <UN### [at] hotmailcom> schreef in bericht 
news:4b240aaf@news.povray.org...
>
> World Machine and TerraBrush use 16-bit tgas. In the version of WM I have, 
> the option for png output is not supported yet. My attempts to convert a 
> 16-bit tga to a png have not been successful; the data is still encoded 
> with red and green colors, thus resulting in a high frequency mess. This 
> probably wouldn't be true if I converted it using POV, but it's faster to 
> use IrfanView :)

WM2, which is also free (with the usual limitations) exports 16bit png 
heightfields. My latest landcape here is precisely that.

I am certainly very much interested in your functions, Sam  :-)

Thomas

Post a reply to this message

Thomas de Groot wrote:
> "stbenge" <UN### [at] hotmailcom> schreef in bericht 
> news:4b240aaf@news.povray.org...
>> World Machine and TerraBrush use 16-bit tgas. In the version of WM I have, 
>> the option for png output is not supported yet. My attempts to convert a 
>> 16-bit tga to a png have not been successful; the data is still encoded 
>> with red and green colors, thus resulting in a high frequency mess. This 
>> probably wouldn't be true if I converted it using POV, but it's faster to 
>> use IrfanView :)
> 
> WM2, which is also free (with the usual limitations) exports 16bit png 
> heightfields. My latest landcape here is precisely that.

I'll have to download that. When trying to stitch pieces of 512x512 
height fields together, are there still visible seams when using erosion?

> I am certainly very much interested in your functions, Sam  :-)

Really, I've got only two functions so far: the angle map and the edge 
map. The edge map is just a hack from a previous proximity pattern.

The red/green importing functions are just useless novelties. I was 
learning how to decode/encode 16-bit data for another project, which, in 
the end, won't need that kind of functionality anyway.

Hopefully the angle map can be used to displace pigments from from an 
isosurfaces according to angles. This should overcome problems arising 
when displacing isosurfaces based on height field data. There might be 
another way to do this. It wouldn't be the first time I've tried to 
solve a problem the hard way ;)

I was beginning to regret having mentioned this set of macros, but maybe 
  you guys will find a good use for them.

Sam

Post a reply to this message

On 12/12/2009 12:58 PM, stbenge wrote:
> Hello,
>
> I'm developing a set of macros to load and manipulate 16-bit height
> field data. With them, you can import red/green 16-bit grayscale images
> and manipulate them as you would any other pigment. There are functions
> for finding edges (via a proximity pattern), finding angles for special
> effects, and even one for exporting red/green images to a few 24-bit
> image formats (to compensate for 3.7's rudimentary 16-bit support). They
> can be used to add features to existing height field data or to create
> new data. The pigments can be used in isosurfaces. I'm keeping my macros
> easy-to-use this time :)
>
> Unfortunately, there are limitations. For one, POV-Ray's handling of
> image_maps produces strange edge artifacts, so I'm having to bring the
> edges of the images down to zero. This creates a sharp drop-off at the
> perimeter of the height field. It's not a feature I wanted.
>
> Another problem is speed. A person would have to develop their height
> maps in a 2D fashion to avoid high parse times, but the macros *can* be
> used directly in a scene.
>
> Considering these limitations, does anyone think they might find such an
> include file useful? I'm pretty much done with most of the functions, so
> all I need is one response so I can begin making example files!
>
> ~Sam

See here:

http://wiki.povray.org/content/Knowledgebase:High_precision_heightfields


--
Michael Horvath
mik### [at] gmailcom
http://isometricland.com

Post a reply to this message

SharkD wrote:
> See here:
> 
> http://wiki.povray.org/content/Knowledgebase:High_precision_heightfields

That looks really cool, but really slow :( In my include file, I rewrote 
some of my comments and code to redirect a user towards using pngs 
instead of other formats.

I was unaware that the png format could be used with such flexibility...

Post a reply to this message

Stephen wrote:
> stbenge wrote:
>> Hello,
>>
>  > Considering these limitations, does anyone think they might find such an
>> include file useful? I'm pretty much done with most of the functions, 
>> so all I need is one response so I can begin making example files!
>>
>> ~Sam
> 
> That’s very kind of you Sam. Consider it requested :-)

All right, it's in p.b.scene-files.

Post a reply to this message

"stbenge" <UN### [at] hotmailcom> schreef in bericht 
news:4b269825@news.povray.org...
> Thomas de Groot wrote:
>> WM2, which is also free (with the usual limitations) exports 16bit png 
>> heightfields. My latest landcape here is precisely that.
>
> I'll have to download that. When trying to stitch pieces of 512x512 height 
> fields together, are there still visible seams when using erosion?
>

I am not sure about that as I have not investigated that properly.


> I was beginning to regret having mentioned this set of macros, but maybe 
> you guys will find a good use for them.
>

Oh yes, you bet!

Thank you very much indeed, Sam.

Thomas

Post a reply to this message

stbenge <UN### [at] hotmailcom> wrote:
> Hello,
>
> I'm developing a set of macros to load and manipulate 16-bit height
> field data. With them, you can import red/green 16-bit grayscale images
> and manipulate them as you would any other pigment. There are functions
> for finding edges (via a proximity pattern), finding angles for special
> effects, and even one for exporting red/green images to a few 24-bit
> image formats (to compensate for 3.7's rudimentary 16-bit support). They
> can be used to add features to existing height field data or to create
> new data. The pigments can be used in isosurfaces. I'm keeping my macros
> easy-to-use this time :)
>
> Unfortunately, there are limitations. For one, POV-Ray's handling of
> image_maps produces strange edge artifacts, so I'm having to bring the
> edges of the images down to zero. This creates a sharp drop-off at the
> perimeter of the height field. It's not a feature I wanted.
>
> Another problem is speed. A person would have to develop their height
> maps in a 2D fashion to avoid high parse times, but the macros *can* be
> used directly in a scene.
>
> Considering these limitations, does anyone think they might find such an
> include file useful? I'm pretty much done with most of the functions, so
> all I need is one response so I can begin making example files!
>
> ~Sam


Hi Sam,

I'm trying for a couple of days now to generate a 6000x4000 pixel image of a
hexagon pattern and am at the brink of getting a little desperate. First I tried
it with a smooth-edged hi-res heightfield texture, than with the same texture as
16bit grayscale tga but I still got little jagged edges. Then I tried the Wilbur
software to generate that special red-green tga for POV, which worked nicely,
except that the Wilbur software always crashed, when I wanted to generate a
really big texture (more than 4000x4000 pixels or so). So that didn't work
either for a hi-res rendered image.

Then I came across your .inc files. Do you think they are suitable for making
such a heightfield with a hexagon pattern? Something like this (I used the
tga-texture generated from the wilbur software for the heightfield in this
image):
http://alien23.de/misc/forum_up1.jpg

I tried a little to make a hexagon heightfield with your .inc files (first with
the pov-ray hexagon pattern and than with a hexagon texture map) but I didn't
got very far:
http://alien23.de/misc/forum_up2.jpg

Possibly I'm just too stupid, though.

Best wishes,
Simone

Post a reply to this message

mone wrote:
> Hi Sam,

Hello mone.

> Then I came across your .inc files. Do you think they are suitable for making
> such a heightfield with a hexagon pattern? Something like this (I used the
> tga-texture generated from the wilbur software for the heightfield in this
> image):http://alien23.de/misc/forum_up1.jpg

Actually, you don't need my include file to accomplish that. POV-Ray has 
some special functions in functions.inc. One of them can produce 
honeycomb-like patterns. Check this out:

// begin code

// If using 3.7, put +fng at the command line for 16-bit gray scale.
// If using 3.6, uncomment this line:
//global_settings{hf_gray_16 on}

#default{finish{ambient 1}}

camera{
  orthographic
  right x*2 up y*2
  location -z*100
  look_at 0
}

#include"functions.inc"

plane{z,0
  pigment{
   function{
    f_hex_x(x,y,z, 0)
   }
   color_map{[.7 rgb 0][.9 rgb 1]}
   scale .25
  }
}

// end code

> Possibly I'm just too stupid, though.

Not at all! Sometimes we tend to over-think our problems, and we don't 
know all our options.

I encourage you to continue reading as much of the documentation as you 
can. This way, when a problem arises, solutions will start popping up. 
POV-Ray is one of those programs that lets you accomplish many tasks in 
several different ways.

I released some hexagonal patterns a while back, you might want to check 
them out: 
http://news.povray.org/povray.binaries.scene-files/message/%3C482478cb%40news.povray.org%3E/#%3C482478cb%40news.povray.org%3E

Happy Raytracing,

Sam

Post a reply to this message

I think these macros won't help you as they are designed to
facilitate importing red-green tga data which you didn't yet
manage to create at the desired resolution.

You didn't mention what the actual source of your height_field
data is. The supported formats for 16-bit height_fields in Povray
are either 16-bit PNG grayscale or red-green TGA.

As red green TGA is a POV-specific hack software which uses it is
sparse. You should however manage to find a way to get 16 bit PNG.
You may find the excellent ImageMagick suite helpful:

   http://www.imagemagick.org/script/index.php

Post a reply to this message

Le 2010-01-09 02:37, mone a écrit :

>
> Hi Sam,
>
> I'm trying for a couple of days now to generate a 6000x4000 pixel image of a
> hexagon pattern and am at the brink of getting a little desperate. First I tried
> it with a smooth-edged hi-res heightfield texture, than with the same texture as
> 16bit grayscale tga but I still got little jagged edges. Then I tried the Wilbur
> software to generate that special red-green tga for POV, which worked nicely,
> except that the Wilbur software always crashed, when I wanted to generate a
> really big texture (more than 4000x4000 pixels or so). So that didn't work
> either for a hi-res rendered image.
>
> Then I came across your .inc files. Do you think they are suitable for making
> such a heightfield with a hexagon pattern? Something like this (I used the
> tga-texture generated from the wilbur software for the heightfield in this
> image):
> http://alien23.de/misc/forum_up1.jpg
>
> I tried a little to make a hexagon heightfield with your .inc files (first with
> the pov-ray hexagon pattern and than with a hexagon texture map) but I didn't
> got very far:
> http://alien23.de/misc/forum_up2.jpg
In this image, you should NOT have those dark parts along the edges. The 
tint should go from dark or black in the center of every hex, and 
sharply climb to 1 on BOTH sides of every edges.
>
> Possibly I'm just too stupid, though.
>
> Best wishes,
> Simone
>
>
>

Maybe you can try shearing the pattern to have some vertical as well as 
horizontal edges. You then apply an inverse shear to the resulting hight 
field.
You still will have one direction with jaggies, but you can use some 
juditious rotation, lighting, texturing and camera placement to mostly 
hide those.

You can use a small tile that you use many times. That tile only covers 
one complete hex and just enough of 4 adjacent ones to create a 
continous pattern when tilled. That smaller tile can have much finner 
grain than a single one covering the whole thing.

Another solution would be to NOT use an hight field but a mesh that you 
replicate as needed. That mesh alone just create a single hex and one 
single edge on one side.



Alain

Post a reply to this message

Thanks to all of you for the useful advice!


stbenge <UN### [at] hotmailcom> wrote:

> #default{finish{ambient 1}}
>
> camera{
>   orthographic
>   right x*2 up y*2
>   location -z*100
>   look_at 0
> }
>
> #include"functions.inc"
>
> plane{z,0
>   pigment{
>    function{
>     f_hex_x(x,y,z, 0)
>    }
>    color_map{[.7 rgb 0][.9 rgb 1]}
>    scale .25
>   }
> }
>
> // end code
>

I tried this function and it can generate textures suitable for the heightfield
very quickly, thanks for the code! I tried some changes with the color map in
the code, and wonder if it's possible to change it in a way, that you don't get
a gradient, but only a white on black pattern?
Because all kinds of gradients, which at first I hoped would maybe result in a
rounded or bevelled looking edge in the heightfield instead made it looking
either jagged or make some strange sort of tiny stripes on the heightfield
walls.
So I removed the gradients in Photoshop (which can handle 16bit grayscale png)
and put a gray border around the white edge without antialiasing.
It still looked a little jagged but a lot better than with the gradients.

Another possibility was to cut a little of the top of the heightfield off with
csg. Now all edges looked perfectly smooth, but they also looked a bit boring,
because the top of the edges reflect the radiosity all in the same way and have
the same color. I'm still experimenting with that, though.

>
> I encourage you to continue reading as much of the documentation as you
> can. This way, when a problem arises, solutions will start popping up.
> POV-Ray is one of those programs that lets you accomplish many tasks in
> several different ways.

Yes. I had searched "hexagon" in the documentation, but I hadn't found the code
in the functions.inc, because it's abbreviated to "hex" there and it didn't show
up in the search result. I should definitely read more in the doc, but the
problem is, before I'm even partly through I've already forgotten completely
about what I had read in the beginning. I'm not good at memorizing things. I
remember I had read  through the functions.inc half a year or so ago, but I
didn't even remember there was this hex-function in there.
>
> I released some hexagonal patterns a while back, you might want to check
> them out:
>
http://news.povray.org/povray.binaries.scene-files/message/%3C482478cb%40news.povray.org%3E/#%3C482478cb%40news.povra
y.org%3E

Yes they look groovy :)
The little yellow star thing inspired me to try to make a whole field of sphere
sweep hexagons in a row with a while loop. But I still haven't figured out the
correct distance between them.




Alain <aze### [at] qwertyorg> wrote:
> Le 2010-01-09 02:37, mone a écrit :
>
> You can use a small tile that you use many times. That tile only covers
> one complete hex and just enough of 4 adjacent ones to create a
> continous pattern when tilled. That smaller tile can have much finner
> grain than a single one covering the whole thing.

I thought I could use tiles only with textures/pigments and so on. I don't know
how to put them on heightfields? Because in the documentation I didn't found any
"repeat" statement in the description for heightfields, so I thought tiles are
not possible. But maybe I missed some essential point, it wouldn't be the first
time :).

Best wishes

Simone

Post a reply to this message

mone wrote:
> I tried this function and it can generate textures suitable for the heightfield
> very quickly, thanks for the code! I tried some changes with the color map in
> the code, and wonder if it's possible to change it in a way, that you don't get
> a gradient, but only a white on black pattern?

Sure, you can squeeze the color_map values together, but the jaggies 
will look much worse.

> Because all kinds of gradients, which at first I hoped would maybe result in a
> rounded or bevelled looking edge in the heightfield instead made it looking
> either jagged or make some strange sort of tiny stripes on the heightfield
> walls.
> So I removed the gradients in Photoshop (which can handle 16bit grayscale png)
> and put a gray border around the white edge without antialiasing.
> It still looked a little jagged but a lot better than with the gradients.

Whatever works :)

Do you know about sin/cos functions? With them, you can make polygonal 
shapes with any number of sides. For instance, to make a 6-sided prism 
you can use sin/cos like so:

prism{
  -1,1,7,
  <sin(pi*2/6*0),cos(pi*2/6*0)>,
  <sin(pi*2/6*1),cos(pi*2/6*1)>,
  <sin(pi*2/6*2),cos(pi*2/6*2)>,
  <sin(pi*2/6*3),cos(pi*2/6*3)>,
  <sin(pi*2/6*4),cos(pi*2/6*4)>,
  <sin(pi*2/6*5),cos(pi*2/6*5)>,
  <sin(pi*2/6*0),cos(pi*2/6*0)> // closing the hexagon
  pigment{rgb 1}
}

Essentially, sin/cos functions map a circle. By studying this code, you 
can figure out how to make polygons with any number of sides. You can 
apply it towards other objects, like cylinders and spheres to make 
skeletal frameworks.

> Yes. I had searched "hexagon" in the documentation, but I hadn't found the code
> in the functions.inc, because it's abbreviated to "hex" there and it didn't show
> up in the search result. I should definitely read more in the doc, but the
> problem is, before I'm even partly through I've already forgotten completely
> about what I had read in the beginning. I'm not good at memorizing things. I
> remember I had read  through the functions.inc half a year or so ago, but I
> didn't even remember there was this hex-function in there.

Learning POV-Ray is daunting, to be sure. It is helpful to create mini 
projects for yourself, to learn how different features work. Also, it 
might be helpful to have a testing scene file with camera, lights, 
background, etc. to test things out in. I always keep such a file 
around, as well as a texture-making scene for trying out new 
pattern-related things.

>> I released some hexagonal patterns a while back, you might want to check
>> them out:
>>
http://news.povray.org/povray.binaries.scene-files/message/%3C482478cb%40news.povray.org%3E/#%3C482478cb%40news.povra
> y.org%3E
> 
> Yes they look groovy :)
> The little yellow star thing inspired me to try to make a whole field of sphere
> sweep hexagons in a row with a while loop. But I still haven't figured out the
> correct distance between them.

I included two functions and two variables in the include file for 
working in trigonal space, you might want to check them out. With them, 
you can find the correct distances :) They are called: h1, h2, ht(x,y), 
ht2(x,y).

> Alain <aze### [at] qwertyorg> wrote:
>> Le 2010-01-09 02:37, mone a écrit :
>>
>> You can use a small tile that you use many times. That tile only covers
>> one complete hex and just enough of 4 adjacent ones to create a
>> continous pattern when tilled. That smaller tile can have much finner
>> grain than a single one covering the whole thing.
> 
> I thought I could use tiles only with textures/pigments and so on. I don't know
> how to put them on heightfields? Because in the documentation I didn't found any
> "repeat" statement in the description for heightfields, so I thought tiles are
> not possible. But maybe I missed some essential point, it wouldn't be the first
> time :).

I think he might have been talking about making a basic height_field 
tile, like this (Thunderbird might put a line directly through the hexagon):
     ____
    /    \
__/      \__
   \      /
    \____/


It's a height_field with only one hexagon, an object you can place in a 
nested #while loop to make a larger honeycomb. You can use the 
previously mentioned variables and functions from my hex patterns 
include file to scale the hexagon correctly.

Sam

Post a reply to this message

Le 2010-01-10 16:38, stbenge a écrit :
> mone wrote:
>> I tried this function and it can generate textures suitable for the
>> heightfield
>> very quickly, thanks for the code! I tried some changes with the color
>> map in
>> the code, and wonder if it's possible to change it in a way, that you
>> don't get
>> a gradient, but only a white on black pattern?
>
> Sure, you can squeeze the color_map values together, but the jaggies
> will look much worse.
>
>> Because all kinds of gradients, which at first I hoped would maybe
>> result in a
>> rounded or bevelled looking edge in the heightfield instead made it
>> looking
>> either jagged or make some strange sort of tiny stripes on the
>> heightfield
>> walls.
>> So I removed the gradients in Photoshop (which can handle 16bit
>> grayscale png)
>> and put a gray border around the white edge without antialiasing.
>> It still looked a little jagged but a lot better than with the gradients.
>
> Whatever works :)
>
> Do you know about sin/cos functions? With them, you can make polygonal
> shapes with any number of sides. For instance, to make a 6-sided prism
> you can use sin/cos like so:
>
> prism{
> -1,1,7,
> <sin(pi*2/6*0),cos(pi*2/6*0)>,
> <sin(pi*2/6*1),cos(pi*2/6*1)>,
> <sin(pi*2/6*2),cos(pi*2/6*2)>,
> <sin(pi*2/6*3),cos(pi*2/6*3)>,
> <sin(pi*2/6*4),cos(pi*2/6*4)>,
> <sin(pi*2/6*5),cos(pi*2/6*5)>,
> <sin(pi*2/6*0),cos(pi*2/6*0)> // closing the hexagon
> pigment{rgb 1}
> }
>
> Essentially, sin/cos functions map a circle. By studying this code, you
> can figure out how to make polygons with any number of sides. You can
> apply it towards other objects, like cylinders and spheres to make
> skeletal frameworks.
>
>> Yes. I had searched "hexagon" in the documentation, but I hadn't found
>> the code
>> in the functions.inc, because it's abbreviated to "hex" there and it
>> didn't show
>> up in the search result. I should definitely read more in the doc, but
>> the
>> problem is, before I'm even partly through I've already forgotten
>> completely
>> about what I had read in the beginning. I'm not good at memorizing
>> things. I
>> remember I had read through the functions.inc half a year or so ago,
>> but I
>> didn't even remember there was this hex-function in there.
>
> Learning POV-Ray is daunting, to be sure. It is helpful to create mini
> projects for yourself, to learn how different features work. Also, it
> might be helpful to have a testing scene file with camera, lights,
> background, etc. to test things out in. I always keep such a file
> around, as well as a texture-making scene for trying out new
> pattern-related things.
>
>>> I released some hexagonal patterns a while back, you might want to check
>>> them out:
>>>
http://news.povray.org/povray.binaries.scene-files/message/%3C482478cb%40news.povray.org%3E/#%3C482478cb%40news.povra
>>>
>> y.org%3E
>>
>> Yes they look groovy :)
>> The little yellow star thing inspired me to try to make a whole field
>> of sphere
>> sweep hexagons in a row with a while loop. But I still haven't figured
>> out the
>> correct distance between them.
>
> I included two functions and two variables in the include file for
> working in trigonal space, you might want to check them out. With them,
> you can find the correct distances :) They are called: h1, h2, ht(x,y),
> ht2(x,y).
>
>> Alain <aze### [at] qwertyorg> wrote:
>>> Le 2010-01-09 02:37, mone a écrit :
>>>
>>> You can use a small tile that you use many times. That tile only covers
>>> one complete hex and just enough of 4 adjacent ones to create a
>>> continous pattern when tilled. That smaller tile can have much finner
>>> grain than a single one covering the whole thing.
>>
>> I thought I could use tiles only with textures/pigments and so on. I
>> don't know
>> how to put them on heightfields? Because in the documentation I didn't
>> found any
>> "repeat" statement in the description for heightfields, so I thought
>> tiles are
>> not possible. But maybe I missed some essential point, it wouldn't be
>> the first
>> time :).
>
> I think he might have been talking about making a basic height_field
> tile, like this (Thunderbird might put a line directly through the
> hexagon):
> ____
> / \
> __/ \__
> \ /
> \____/
>
>
> It's a height_field with only one hexagon, an object you can place in a
> nested #while loop to make a larger honeycomb. You can use the
> previously mentioned variables and functions from my hex patterns
> include file to scale the hexagon correctly.
>
> Sam

That's exactly what I had in mind.


Alain

Post a reply to this message

stbenge <UN### [at] hotmailcom> wrote:

>
> Do you know about sin/cos functions?

I recall dimly there was sth. like that at school that I never quite understood.

With them, you can make polygonal
> shapes with any number of sides. For instance, to make a 6-sided prism
> you can use sin/cos like so:
>
> prism{
>   -1,1,7,
>   <sin(pi*2/6*0),cos(pi*2/6*0)>,
>   <sin(pi*2/6*1),cos(pi*2/6*1)>,
>   <sin(pi*2/6*2),cos(pi*2/6*2)>,
>   <sin(pi*2/6*3),cos(pi*2/6*3)>,
>   <sin(pi*2/6*4),cos(pi*2/6*4)>,
>   <sin(pi*2/6*5),cos(pi*2/6*5)>,
>   <sin(pi*2/6*0),cos(pi*2/6*0)> // closing the hexagon
>   pigment{rgb 1}
> }
>
> Essentially, sin/cos functions map a circle. By studying this code, you
> can figure out how to make polygons with any number of sides. You can
> apply it towards other objects, like cylinders and spheres to make
> skeletal frameworks.
>

I see. I just checked that with cylinders, it becomes a hexagon when one puts
the sin/cos lines in the end and start points coordinates. There are some ugly
gaps in between but basically it works. Might be useful for some other things
I'll put it in my "tipps & tricks" folder :).



> > The little yellow star thing inspired me to try to make a whole field of sphere
> > sweep hexagons in a row with a while loop. But I still haven't figured out the
> > correct distance between them.
>
> I included two functions and two variables in the include file for
> working in trigonal space, you might want to check them out. With them,
> you can find the correct distances :) They are called: h1, h2, ht(x,y),
> ht2(x,y).

I had a look at them but I don't understand them.
The distances between points I tried to find out yesterday with graph paper,
which didn't work, then I looked them up at wikipedia which did work.

But what I meant with distances in the rows and columns of the hexagonal
sphere_sweeps was not the distances between the points of one hexagon but
between the single hexagons. Though I could calculate the distance, I wanted
them to overlap, so two of them always share one border because that looks
better. The width of the borders I could not calculate because it is determined
by the width of the gradient in the heightfield texture. Maybe some mastermind
can calculate them too, but it will be no problem to just trial&error a bit.



> I think he might have been talking about making a basic height_field
> tile, like this (Thunderbird might put a line directly through the hexagon):
>      ____
>     /    \
> __/      \__
>    \      /
>     \____/
>
>
> It's a height_field with only one hexagon, an object you can place in a
> nested #while loop to make a larger honeycomb. You can use the
> previously mentioned variables and functions from my hex patterns
> include file to scale the hexagon correctly.
>

Oh, I see. I have understood that now :)

I'll try to do my best and output some final images now, which should be no
problem with all the useful advice and before anybody will get hexagonized :))


Thanks & Best wishes

Simone

Post a reply to this message