I'm writing some code in C++ (on windows) to generate some 16-bit height
field data.  What is going to be the easiest way for me to export the
numbers to use in POV?  The PNG file format looks pretty complex (compared
to BMP which is what I'm used to).

Is there any way to make POV use red+256*green or something like that from a
BMP file?  Or some software that will make red+256*green into 16-bit grey
PNG?

Thanks

Scott

Post a reply to this message

scott wrote:
> I'm writing some code in C++ (on windows) to generate some 16-bit height
> field data.  What is going to be the easiest way for me to export the
> numbers to use in POV?  The PNG file format looks pretty complex (compared
> to BMP which is what I'm used to).
> 
> Is there any way to make POV use red+256*green or something like that from a
> BMP file?  Or some software that will make red+256*green into 16-bit grey
> PNG?
> 
> Thanks
> 
> Scott
> 
> 
Hi Scott

You could use TARGA to export your data. There is an introduction to 
this format here :
http://astronomy.swin.edu.au/~pbourke/dataformats/tga/

I did write a piece of C++ some years ago that handled the 
reading/writing of TGA images, but I fear it's not terribly well 
coded... And it is badly commented, and in french... I could give a try 
at cleaning it up if you wish, but I think you'd be better off writing 
it yourself ;-) Anyway the format is rather easy to understand.

Hope this helps

-- 
Vincent

Post a reply to this message

scott <sco### [at] spamcom> wrote:
> I'm writing some code in C++ (on windows) to generate some 16-bit height
> field data.  What is going to be the easiest way for me to export the
> numbers to use in POV?  The PNG file format looks pretty complex (compared
> to BMP which is what I'm used to).

  The png format is not intended to be read/written directly (unless you
are a really hardcore programmer... :P ) but there are libraries for
that purpose. Of course at least the most common png library is pretty
hard to use all on itself, but that's another issue... ;)

> Is there any way to make POV use red+256*green or something like that from a
> BMP file?  Or some software that will make red+256*green into 16-bit grey
> PNG?

  From http://povray.org/documentation/view/3.6.1/279/

"The TGA and PPM file formats may be used as a storage device for 16
bit numbers rather than an image file. These formats use the red and
green bytes of each pixel to store the high and low bytes of a height
value."

  The raw TGA file format is extremely simple. It has a 18-byte header
(which format is fixed) and then the raw image data.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

>   From http://povray.org/documentation/view/3.6.1/279/
>
> "The TGA and PPM file formats may be used as a storage device for 16
> bit numbers rather than an image file. These formats use the red and
> green bytes of each pixel to store the high and low bytes of a height
> value."
>
>   The raw TGA file format is extremely simple. It has a 18-byte header
> (which format is fixed) and then the raw image data.

Thanks, raw TGA is exactly what I need.  Cheers.

Post a reply to this message

In article <4219be88$1@news.povray.org>, "scott" <sco### [at] spamcom> 
wrote:

> I'm writing some code in C++ (on windows) to generate some 16-bit height
> field data.  What is going to be the easiest way for me to export the
> numbers to use in POV?  The PNG file format looks pretty complex (compared
> to BMP which is what I'm used to).

PNG would be the best option. libpng is really not that hard to use, 
just follow the examples in the documentation. You get lossless 
compression and files that are widely supported.

Alternatively, you could encode the data as 16 or 24 bit fixed point 
float values split into 8 bit chunks among the RGB channels, and either 
use POV-Ray's built in red-green "16 bit grayscale TGA" feature or 
combine the channels manually using a function to generate the height 
field. I would suggest the latter...it seems most flexible.

-- 
Christopher James Huff <cja### [at] gmailcom>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

Have you considered writing the data out as a mesh2?  Since you're 
writing a C++ program anyway, it's probably a lot easier to write a few 
floating point numbers out in text format than to write out a specific 
image file format.  Plus you get to have a greater degree of precision 
than with a 16 bit image file.  Also you can control the mesh smoothing 
if you calculate a few normal vectors.

I wrote a C++ program (win32 command line) that takes a raw 32bit 
floating point output file from World Machine, calculates the mesh, does 
a non linear transform (cylindrical wrapping), calculates the normal 
vectors, then spits out a mesh.  Email me if you'd like the source and 
you can feel free to use it however you like.

Peter D.

scott wrote:
> I'm writing some code in C++ (on windows) to generate some 16-bit height
> field data.  What is going to be the easiest way for me to export the
> numbers to use in POV?  The PNG file format looks pretty complex (compared
> to BMP which is what I'm used to).
> 
> Is there any way to make POV use red+256*green or something like that from a
> BMP file?  Or some software that will make red+256*green into 16-bit grey
> PNG?
> 
> Thanks
> 
> Scott
> 
>

Post a reply to this message

Peter Duthie <pd_### [at] warlordsofbeercom> wrote:
> does a non linear transform (cylindrical wrapping)

... to the vertex points, you mean?

  (Technically a mesh is more than just its vertex points, and performing
a transformation on the vertex points is not the same thing as performing
a transfromation on the mesh.)

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

Christopher James Huff schrieb:
> In article <4219be88$1@news.povray.org>, "scott" <sco### [at] spamcom> 
> wrote:
> 
> 
>>I'm writing some code in C++ (on windows) to generate some 16-bit height
>>field data.  What is going to be the easiest way for me to export the
>>numbers to use in POV?  The PNG file format looks pretty complex (compared
>>to BMP which is what I'm used to).

Aha, me too, but linux is my choice.
As Christopher mentioned libpng is not that hard to use.
Just yesterday I took a look at the manpage (man libpng) and there are
several examples on how to write the image data.
I didn't try it yet, but it didn't look too complicated.
Maybe within the next week I'll have some C++ code.

> 
> PNG would be the best option. libpng is really not that hard to use, 
> just follow the examples in the documentation. You get lossless 
> compression and files that are widely supported.

Regards,
Sebastian H.

Post a reply to this message

> Have you considered writing the data out as a mesh2?

I believe height fields trace considerably faster than their equivalent
meshes.

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

In article <421cc4e9$1@news.povray.org>, "Slime" <fak### [at] emailaddress> 
wrote:

> > Have you considered writing the data out as a mesh2?
> 
> I believe height fields trace considerably faster than their equivalent
> meshes.

Have you tried it? (I haven't...I'm really wondering if there's much of 
a difference.)
A mesh has other advantages as well. You could create overhangs and 
other structures, make it higher resolution tessellation in areas that 
are more important, use a tessellation that doesn't produce artifacts 
that are as obvious, etc. You can also compute the normals more 
precisely while you're generating the mesh, rather than estimating them 
from the triangle data. Look at the height field macros to see the 
difference this can make...they compute the normal by looking at the 
slope of the height function.

On the other hand, an image-based height field is easier to 
edit...though you really need something that can handle 16 bit images.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message