 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez <nic### [at] gmail com> wrote:
> http://imagebin.ca/view/5lUU-ge.html
>
> Source attached.
>
> "interpolate 2" in the image_map is absolutely necessary. Without
> interpolation, it like a bunch of square blocks, one for each pixel; the
> function gradient and the render times go through the roof, and it looks
> ugly. With it, the isosurface looks like a non-smoothed heightfield.
I tried a higher interpolation value, and the result is pretty cool looking, but
not useful. :)
-Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez <nic### [at] gmailcom> wrote:
> SharkD wrote:
> > As an experiment, I created a copy of "Untitled1_hf.png", except with the
> > blue channel set to zero. The resulting heightfield looks subtly but
> > noticibly different.
> Oh really...
YRLY.
-Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"SharkD" <nomail@nomail> wrote:
> > height = red + (green/256.0) + (blue/65536.0)
> >
> > with red, green, blue and height all ranging from 0.0 to 1.0.
>
> I don't quite understand your math. If red, green and blue all range from 0 to
> 1, then the maximum possible height is 3. The maximum height of heightfields is
> 1.
Red, green and blue are "misused" to encode one single higher-precision value.
The range of 0.0 to 1.0 which I presumed is just for convenience, because that's
PoV-ray's "native" range for colors, and is a very convenient range for heights
because it can easily be scaled to any other range you may need.
In the image, the red, green & blue channels each have a precision of 8 bit, so
the smallest step a single channel can encode is 1/256 of its total range.
Now if we used only a single channel (say red) to encode the height, we could
map it like this (note that this is just a convention, not a law):
height = red
This would give us the same precision for the height as the red channel can
provide, i.e. smallest steps being 1/256 of the total range.
If we want to increase this, we can use the other channels to help us, e.g.:
height = red + green + blue
In this way, our smallest step is 1/256 of a *single* channel's range, but as
the height will now - as you correctly observed - be in range 0.0 to 3.0, this
is actually 1/768 of the *height's* total range. So we have tripled the
height's precision.
This is, however, not the highest precision one can get out of 3*8 = 24 bits. In
fact, it should be possible to encode steps as small as 1/(2^24) of the total
range.
In fact, we can achieve that by using the green and blue component to encode
*smaller* steps than the red component (a kind of high-precision correction
terms), e.g.:
height = red + 0.1 * green + 0.01 * blue
So although red, green and blue have a range of 0.0 to 1.0 each, the terms now
have a range of 0.0 to 1.0, 0.0 to 0.1 and 0.00 to 0.01 respectively, with
their smallest steps being 1/256 of the *term's* range, i.e. 1/256 for the "red
term", 0.1/256 for the "green term" and 0.01/256 for the "blue term".
So the height's range would now be in the range of 0.0 to 1.11 (quite similar to
the original range), but the smallest step would be 0.01/256, i.e. we have
hundredfold the precision of a single channel.
It turns out that the ideal factors for the single terms are powers of 1/256
(the smallest step representable by a single component), giving the term I
mentioned:
height = red + green/256 + blue/65536
Well, actually I must confess that this is not *really* the ideal formula,
unless the range for red, green and blue isn't precisely 0.0 to 1.0, but 0/256
to 255/256 and the resulting range of the height would not be 0.0 to 1.0
either, but 0/(2^24) to (2^24-1)/(2^24); for the range 0.0 to 1.0 as actually
used by PoV-ray (if I'm not mistaken), the formula should be:
height = ( (red*255) + (green*255)/256 + (blue*255)/65536 )/255
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"clipka" <nomail@nomail> wrote:
> Red, green and blue are "misused" to encode one single higher-precision value.
> ...
> Well, actually I must confess that this is not *really* the ideal formula,
> unless the range for red, green and blue isn't precisely 0.0 to 1.0, but 0/256
> to 255/256 and the resulting range of the height would not be 0.0 to 1.0
> either, but 0/(2^24) to (2^24-1)/(2^24); for the range 0.0 to 1.0 as actually
> used by PoV-ray (if I'm not mistaken), the formula should be:
Hehe. I already finished creating the pigment. Check one of my earlier posts.
-Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez <nic### [at] gmailcom> wrote:
> I don't think it would be easy at all. You definitely can't use
> antialiasing :) (try slightly blurring the image you have and loading it
> into your app, see what you get!)
Antialiasing doesn't seem to have harmed it in any way. See:
http://i421.photobucket.com/albums/pp292/SharkD2161/Support/hf_24_bit_pigment_overhead_hf_24.png
http://i421.photobucket.com/albums/pp292/SharkD2161/Support/hf_24_bit_pigment_overhead_hf_24_no.png
-Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
SharkD wrote:
> Nicolas Alvarez <nic### [at] gmailcom> wrote:
>> I don't think it would be easy at all. You definitely can't use
>> antialiasing :) (try slightly blurring the image you have and loading it
>> into your app, see what you get!)
>
> Antialiasing doesn't seem to have harmed it in any way.
That's because at first I thought you wanted to do the opposite: generate
such a 24-bit image from POV-Ray, for another program to use. *That* would
be harmed by AA.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"SharkD" <nomail@nomail> wrote:
> I generated the following heightfield in some program or other. It uses all 24
> bits for elevation information. My question is, how are the colors/height data
> organized? I would like to create a pigment that produces similar maps.
>
> http://i421.photobucket.com/albums/pp292/SharkD2161/Support/Untitled1_hf.png
>
> -Mike
I just rediscovered that I originally created the heightfield using Daylon
Leveller.
-Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
SharkD wrote:
> I just rediscovered that I originally created the heightfield using Daylon
> Leveller.
Daylon provides a patch for POV-Ray that can load .ter files (directly from
Leveller) as heightfield images.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez <nic### [at] gmailcom> wrote:
> Daylon provides a patch for POV-Ray that can load .ter files (directly from
> Leveller) as heightfield images.
Does this result in superior heightfields, or is it just for the convenience of
not having to convert between various formats?
-Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"SharkD" <nomail@nomail> wrote:
> I tested the pigment on a cone, and then used the output in a heightfield. It
> seems to work OK if the output is rendered in as a 24 bit image, but produced
> weird results when using a 48 bit image.
>
> -Mike
It seems the 48 bit image is being converted to grayscale first, which results
in a wildly different heightfield.
-Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
