[using v3.7.0 and v3.8 beta 1 in Windows 10]

The material_map feature is new to me; I don't think that I have ever used it in
a scene-- probably because I never use 'indexed' images. But your post spurred
me to take a look at the documentation, and to try it out.

Instead of using a true indexed image, I decided to make a typical .png 24-bit
image for use in the map, by following the docs' example code at  "2.3.5.11 When
All Else Fails: Material Maps". (The material_map pattern still makes use of
so-called 'indices' in the image, but they are the red-channel gradations of
0/255, 1/255, 2/255 etc, rather than 1,2,3 etc.) I rendered this initial image
with *no* antialiasing, which makes a big difference...and *no* interpolation
later, when I used it in the map.

So far, I have not been able to reproduce the 'noise' that you mentioned-- but I
discovered something else: Once I carefully made the preliminary image for the
material_map, and added the required number of textures to correspond to the
'indices' of its red-channel steps, the final rendered texture results did not
quite correspond correctly to the indices: A few textures were missing.

After a lot of double-checking of my code and some experimentation, I made a
'lucky informed guess' as to the cause: It turned out to be a gamma issue. To
make the initial image for use in the material_map, I had used assumed_gamma 1.0
as usual, and with my File_Gamma as 'srgb' (as usual). But this 'mis-match' of
gammas caused the problem! So I re-made the image, keeping assumed_gamma at 1.0
but *changing* the File_Gamma to 1.0 to match it-- and the missing textures
appeared correctly in the final material_map render. (Using assumed_gamma 2.2
and a matching 2.2 File_Gamma also solves it.) Apparently, those two gamma
values need to be the same for that initial render, so that the material_map
code will then work correctly with it under-the-hood.

I don't yet know if this problem affects true 'indexed' images.

This solution leads me to believe that, when the material_map code was first
implemented in POV-ray long ago, the various gammas of rendering might have been
different than they currently are... possibly with a gamma of 2.2 being used
across-the-board, or by default. That's my guess.

Post a reply to this message