"Kenneth" <kdw### [at] gmailcom> wrote:
> "LanuHum" <Lan### [at] yandexru> wrote:
> > Hello! I created a picture with a gradient. I want to use it as a
> > height map for a sphere. However, only gray stripes are visible on the sphere.
> >
>
> The 'flat' look of those gray stripes seems odd to me; there *should* be some
> (fake) 'depth' to them due to your bump_map, based on the normal-pattern image
> that you posted:
>
> normal{ bump_map{"/home/lanuhum/src/Thread_90.jpg"
> gamma 1.1000 map_type 0
> interpolate 2 bump_size 5}
>
> I ran your code--using the same 'normal' image that I copied here-- and it seems
> that a gamma of 1.1 that you used is not a good value for a bump_map. I changed
> that value to 2.2 (and boosted the bump_size to 10) and it looks much better.
>
> If I leave out the gamma keyword altogether, the 'flat' result looks nearly
> identical to your 1.1 value. The POV-ray default is 1.0 (i.e., it treats the
> image as 'linear' data.)
>
> Since we are both using jpeg's for the bump_map, they have a standard 'embedded
> gamma' of around 2.2 (or maybe 'srgb'), which is not linear. So using a value of
> 1.1 (or 1.0) changes that; a somewhat simple explanation is that it reduces the
> contrast of the image-as-bump_map.
>
> From the documentation:
> "While POV-Ray will normally interpret the bump map input file as a container of
> linear data [gamma of 1.0] irregardless of file type, this can be overridden for
> any individual bump map input file by specifying gamma immediately after the
> file name."

My sincere apologies. I missed your message. Thank you so much for your help

Post a reply to this message

Attachments:
Download 'screenshot.jpg' (104 KB)

Preview of image 'screenshot.jpg'

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
> >
> > I ran your code--using the same 'normal' image that I copied here-- and it
> > seems that a gamma of 1.1 that you used is not a good value for a bump_map.
> > I changed that value to 2.2 (and boosted the bump_size to 10) and it
> > looks much better.
>
>
> If you share your thoughts about how the image gets converted to gamma 2.2 or
> srgb-modified rgb values...

[Sorry for the long delay in responding here; I had to deal with repairs on my
car, one after the other.]

I have been trying to reproduce Lanahum's flat-looking result with my *own*
image(s) for the bump_map, made in POV-ray at typical assumed_gamma 1.0-- and
see 'normals' results  that sometimes do not agree with my previous comments
about the  bump_map's gamma setting requiring a 2.2 value. (I'm running the
tests in v3.7, same as he did.) The surface normals in at least one of my tests
look OK even with the bump_map's gamma at 1.0 (or just leaving out 'gamma'
altogether). That seems strange, based on my earlier remarks. But I finally
'chased the rabbit down its hole' and discovered the reason for the disparity.

Simply put: The final appearance of the 'normal' effect is very sensitive to the
gamma used to encode its image_map (and sensitive to the chosen pattern itself,
apparently.)

NOTE: In the attached image, all of the bump_maps use bump_size 10 for the
normal.

[A] While the default 'gamma' setting in a bump_map does indeed seem to be 1.0,
my new tests indicate that POV-ray automatically compensates for an image having
an intrinsic or 'encoded' gamma of 2.2-- like typical  jpeg's or png's-- and
*without* having to specify a gamma-value change in the bump_map. (I used an
inverted sine_wave pattern for this one; I took the original sine_wave .jpeg
render into my paint.net app and inverted it there.) It's 'normals' look as
expected!

[B] This is just Lanahum's posted pattern again and his original bump_map
result, then with my gamma 2.2 'correction' as before. (To use his pattern, I
simply snipped it out of his .jpeg image post-- using paint.net--and re-saved it
as a .jpeg again.) The final 'normals' result looks like a 'scallop wave'-- but
that's misleading...

[C] To create a pattern that looks like his, I had to use a triangle_wave
pattern instead-- with the image_map **rendered  at assumed_gamma 2.2** in
POV-ray, rather than at my usual 1.0.  It looks nearly identical to Lanahum's
pattern. Using that image in the bump_map-- with a gamma 1.0 setting there--
produces the flat gray-stripes look again, same as Lanahum's.  A setting of 2.2
gives the surface normals some 'depth'...although the result looks like a
'scallop wave' instead of a triangle. That's to be expected: The gamma is
changing the 'slope' of the black-to-white gradations.

[There is another way to produce the same effect, which I didn't post here:
making a triangle-wave image_map *as* a gamma 1.0 image. I made one in POV-ray
using assumed_gamma 1.0 and changing both Display_Gamma and File_Gamma to 1.0,
rather than their usual 2.2 (or 'srgb'). Then it likewise required a gamma 2.2
value in the bump_map. BTW, this image_map had to be in the .png format--
apparently a .jpeg cannot(?) be rendered at gamma 1.]

I think that Lanahum's original image_map was made using one those two schemes--
which is why it required a 2.2 gamma change.

[D] I used POV-ray's triangle_wave pattern again for the image_map, but rendered
at typical assumed_gamma 1.0. With the bump_map's gamma set to 1.0, there
appears to be *some* 'depth' to the normal-- but changing the gamma to 2.2 makes
flat stripes instead(!), which is a mystery. To get any further depth from it
requires a bump_map gamma of between 4 and 5 (4.4??)-- but then it looks like a
'scallop wave' again.

--------------------
[off topic]
Lanahum's code uses a 'brilliance' setting in his finish{...}. That seems to
work (or look) better in v3.7 than in v3.8 beta 1, to my eyes. There must have
been a 'change' of some kind for the current betas.

Post a reply to this message

Attachments:
Download 'bump_map_tests_3_23_2026_kw.jpg' (561 KB)

Preview of image 'bump_map_tests_3_23_2026_kw.jpg'

Nice work producing all those variants.

I'm curious:

In some of your renders you get a mis-match / seam in your normal/texture.
Also, there is that small half-black/half-white circular "blemish" at the
forefront of some of the spheres.

- BE

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> In some of your renders you get a mis-match / seam in your normal/texture.
> Also, there is that small half-black/half-white circular "blemish" at the
> forefront of some of the spheres.
>

The mis-match seam comes from my attempt to give my own image_map the same
'tilt' of the pattern as Lanahum's...although I didn't get it quite right. Then
the pattern repeats on the sphere, causing the visible 'seam'.

That small circle on my sphere renders is also visible in Lanahum's original
post, although not as pronounced. I don't quite know what the cause is, as I
have not really examined his code in detail, and just used it as-is. (Although,
I did comment-out his various matrices to simplify the code, since they were
having no effect as far as I could tell.) The circle might be because the
bump_map's image_map does not exactly fit the sphere(?) or is not exactly
aligned to it. (We are both using map_type 0 for applying the bump_map, which is
just planar mapping, not 'spherical')

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> >
> > In some of your renders you get a mis-match / seam in your normal/texture.
> > Also, there is that small half-black/half-white circular "blemish" at the
> > forefront of some of the spheres.
> >
>
> The mis-match seam comes from my attempt to give my own image_map the same
> 'tilt' of the pattern as Lanahum's...although I didn't get it quite right. Then
> the pattern repeats on the sphere, causing the visible 'seam'.

Ok, well - it doesn't seem to be there in column B,
and
looking back at the OP, he's got another weird seam that's perpendicular to that
and seems to line up with where the black/white circle divides.

I would not ignore either of these things, as this is usually where we
discover/learn something important.

Just curious if you can use spherical bump-mapping or spherical warp

> That small circle on my sphere renders is also visible in Lanahum's original
> post, although not as pronounced. I don't quite know what the cause is, as I
> have not really examined his code in detail, and just used it as-is. (Although,
> I did comment-out his various matrices to simplify the code, since they were
> having no effect as far as I could tell.) The circle might be because the
> bump_map's image_map does not exactly fit the sphere(?) or is not exactly
> aligned to it. (We are both using map_type 0 for applying the bump_map, which is
> just planar mapping, not 'spherical')

That doesn't really make any sense to me.
I'd experiment with other bump maps - maybe a grid, and see what happens, and
where on the bump map that artefact appears.

- BE

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:

> >
> > The mis-match seam comes from my attempt to give my own image_map the same
> > 'tilt' of the pattern as Lanahum's...although I didn't get it quite right.
> > Then the pattern repeats on the sphere, causing the visible 'seam'.
>
> Ok, well - it doesn't seem to be there in column B.

Column B is just a copy of Lanahum's initial post, along with my gamma 2.2
'correction' for the bump_map. His own posted pattern is 'tilted' just enough to
show no seam when it repeats.
>
> Just curious if you can use spherical bump-mapping or spherical warp

I never got around to that. "So little time, so much other neat stuff to work
on." ;-)
>
> > That small circle on [the] sphere renders...
>
> That doesn't really make any sense to me.
> I'd experiment with other bump maps - maybe a grid, and see what happens, and
> where on the bump map that artefact appears.
>

You're right, it *is* kind of odd. I took a look at Lanahum's code again, and
there is nothing there to cause that little circle.

Herewith, a grid example. Same Lanahum code, but I substituted an image_map
PIGMENT using the same map_type 0; no bump_map. My grid image_map has a
2-pixel-wide vertical purple stripe on the right edge from top to bottom, as a
tester. A purple circle shows up on the sphere where the bump_map's 'circle'
was-- along with a white dot in the center, which is probably a 1-pixel 'repeat'
from the left side of the image_map(?). So the anomaly does not seem to be
bump_map specific.

Perhaps it's a result (or a glitch?) of using map_type 0 when applying an
image_map of any kind to a *sphere*.

Post a reply to this message

Attachments:
Download 'grid_test_kw.jpg' (491 KB)

Preview of image 'grid_test_kw.jpg'

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> I did comment-out his various matrices to simplify the code, since they were
> having no effect as far as I could tell.

My mistake: His sphere does use a matrix-- but is has no effect on that small
'circle' except to move it (and the pattern itself) around the sphere. I tested
it. (His code had another matrix that I did comment out, which was just a
default one producing no change.)

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:

> You're right, it *is* kind of odd. I took a look at Lanahum's code again, and
> there is nothing there to cause that little circle.

I think I see why - the image_map is getting wrapped around that point as a
pole.
That's why you get that purple/white circle - it's the right edge of your image
map.

> A purple circle shows up on the sphere where the bump_map's 'circle'
> was-- along with a white dot in the center, which is probably a 1-pixel 'repeat'
> from the left side of the image_map(?). So the anomaly does not seem to be
> bump_map specific.
>
> Perhaps it's a result (or a glitch?) of using map_type 0 when applying an
> image_map of any kind to a *sphere*.

Could be.
No way to know without comparing it to spherical map_type.
In the meantime, put a (different) colored stripe along the left side of that
image_map and see if the color of the central dot changes.

If it's a persistent "repeat", then that's a problem.
I should already have a fix for that, if such is the case, but that will require
another dive into the depths of the source code.

y'all know how I love that.

- BE

Post a reply to this message

This also reminded me that hand-rolled a uv_mapping mechanism in SDL.

https://news.povray.org/povray.binaries.images/thread/%3Cweb.5d5757a84c72a7284eec112d0%40news.povray.org%3E/

So you could try that and see what happens.

- BE

Post a reply to this message

I found the cause(s) of that small circle in the bump_map appearance. It is  a
combination of two different things:

1) a gray value *difference* between the left and right edges of the applied
image (see column E). The circle seems to be a natural consequence of this
difference. My guess is that the 'normals' mechanism under-the-hood needs(?) to
use the gray values from BOTH left and right to figure out what the normal
should be at that circle 'point'. Or possibly it's a precision issue.

2) using 'interpolate 2' in the bump_map, which makes the circle even worse. In
this case, the resulting normal  definitely appears to be using the
left-and-right edges of the image for the interpolation.

Column F shows the normals result when the applied image has the SAME gray
values on the left and right-- NO circle is produced, whether or not interpolate
2 is also used. But such an applied image is not a realistic test; it will
usually have natural grayscale differences on the left and right, like LanuHum's
original pattern of a tilted wave.

Column G shows that NO 'circle' is produced when a typical pigment{image_map...}
is applied instead of a  bump_map-- unless 'interpolate 2' is used, which then
'blends' the left and right edge colors of the image_map.

Post a reply to this message

Attachments:
Download 'bump_map_circle_vs_pigment_image_map_kw_3_28_26.jpg' (510 KB)

Preview of image 'bump_map_circle_vs_pigment_image_map_kw_3_28_26.jpg'