|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ran into this before, long time ago, still confused.
'd like to write 16 bit greyscale files from an array[][] to use them in
a hight-field (in the same scene).
Tried different packages to generate .pgm's, many won't work. Some do
and it seems POV-Ray can use 16 bit greyscale pgm's for HF's despite
what the docs say.
What would be the exact form of 16 bit pgm's that POV-Ray supports?
Ingo (...and if somebody has a macro ...)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 07.10.2016 um 22:40 schrieb ingo:
> Ran into this before, long time ago, still confused.
> 'd like to write 16 bit greyscale files from an array[][] to use them in
> a hight-field (in the same scene).
> Tried different packages to generate .pgm's, many won't work. Some do
> and it seems POV-Ray can use 16 bit greyscale pgm's for HF's despite
> what the docs say.
>
> What would be the exact form of 16 bit pgm's that POV-Ray supports?
http://netpbm.sourceforge.net/doc/pgm.html, with the following limitations:
- Where the specification allows arbitrary whitespace between width and
height, POV-Ray requires this to contain neither CR nor LF.
- Where the specification allows an arbitrary single whitespace
character between the height and the maxval, POV-Ray requires this
whitespace character to contain at least one line break.
- Where the specification allows an arbitrary single whitespace
character between the maxval and the raster, POV-Ray requires this
whitespace character to be a line break.
- Where the specification allows comments ("#" followed by arbitrary
characters followed by a newline; see
http://netpbm.sourceforge.net/doc/pbm.html) anywhere in the header (the
portion before the single whitespace right before the raster), POV-Ray
requires any comments to reside in otherwise blank lines.
- I'm not sure right off the top of my head whether POV-Ray allows VT or
FF whitespace charaters in the file.
Also, current versions of POV-Ray do not gamma-correct PGM input files
unless you explicitly specify the gamma (using the `gamma` keyword).
Other than that, I'm not aware of any limitations.
POV-Ray supports both binary (P5) and ASCII (P2) PGM files.
POV-Ray 3.7 can write binary data; see the `ARRAYS_WriteDF3()` macro in
`arrays.inc` for sample code. As a matter of fact, that macro happens to
also export a multi-dimensional array as a binary file, albeit as DF3
rather than PGM, but it should be easy enough to adapt for binary PGM
export.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Op 2016-10-08 om 07:26 schreef clipka:
> http://netpbm.sourceforge.net/doc/pgm.html, with the following limitations:
> [...]
Danke, I'll fiddle with it a bit more,
Ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
First shot at it
Ingo
---8<---8<---
#version 3.7;
#macro Arraytopgm16(Array, Filename)
/*
Marcro to write 16 bit (greyscale) .pgm files from a 2d array.
Array: 2 dimensional array
Filename: Name of file the data are written to
Uninitialised elements of the array are written as 0. Content of
arrays are
not scaled to fit max range nor any gamma-correction is done.
Maxvalue in
header is always set to 65535. It is to the user to provid a
fitting array.
.pgm file header:
magic number in ASCII( 'P5' = fixed)
width height in ASCII (dimension_sizes from Array)
maxvalue in ASCII (65535 = fixed)
values 16 bit unsigned, big endian
*/
#if (dimensions(Array)!=2)
#error "Arraytopgm16: not the right array dimension, needs 2\n"
#end
#local SizeX = dimension_size(Array,1); //test for zero?
#local SizeY = dimension_size(Array,2);
#fopen Fpgm Filename write
#write (Fpgm, "P5\n", SizeX," ", SizeY,"\n65535\n")//.pgm header
#for (IndY, 0, SizeY-1)
#for(IndX, 0, SizeX-1)
#ifdef(Array[IndX][IndY])
#local Value = Array[IndX][IndY]; //test for value
#else
#local Value = 0;
#end
#write (Fpgm, uint16be Value)
#end
#end
#fclose Fpgm
#end
global_settings{ assumed_gamma 1.0 }
#default{ finish{ ambient 0.1 diffuse 0.9 }}
#declare MyGrid = array[50][50]
#declare MyGrid[25][25]=65535;
Arraytopgm16(MyGrid,"test.pgm")
height_field {
pgm "test.pgm"
smooth
double_illuminate
translate<-0.5,-0.0,-0.5>
texture{pigment{rgb 1}}
scale<10,10,10>
}
light_source{< 3000,3000,-3000> rgb 1}
camera {
perspective angle 55
location <0 , 15 ,-15>
right x*image_width/image_height
look_at <0,0,0>
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Interesting approach to write image files directly from SDL :)
Note since you already have the array inside POV-Ray an alternative
way might be to create one box for each "pixel" and let povray do the
image creation by rendering to 16-bit PNG or PPM (+FN16 or +FP16).
It probably requires ortographic camera and some fiddling with
screen.inc for exact positioning. However it won't work if you want
to render a scene in one pass where first the image is created and then
immediately used in a height_field (that would require something like
the camera pigment in MegaPOV, not sure if that already exists in
some of the current POV derivates).
BTW I think the main usefulness of a heightfield image is ease of
use and import of data from external sources, but in your case you
might also consider building a mesh from the array data and render
that directly.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
in news:5802a0e5$1@news.povray.org Christian Froeschlin wrote:
> Interesting approach to write image files directly from SDL :)
The idea is to do some generative image creation (think Processing but 16
bit depth) and turn that in an HF.
Have random spline "crawl" along the array and paint the surrounding
pixels using a pattern as a paintbrush. The same would indeed work with a
mesh and uv manipulation.
So far only a few rough sketches of an idea.
Ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|