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



-- 

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
> 


:)

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
> 


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

Post a reply to this message