Problem with bump mapping

[solarray]

Hey all,

I wanted to create a good clay/plasticine material and found a nice page where a guy provides a fingerprint texture for a bump channel to get a realistic material. But somehow I get problems with this bump channel in indigo. If you have a look at the border of the material sphere you can notice some darker areas, which looks like when using a too high bump value. But the bump on all other parts looks perfect. What Im doing wrong, or is it a bug ?

Clay, plasticine

I modified the original fingerprint texture by lowering the contrast a bit. Here is my version:

Modified fingerprint bump texture

The original fingerprint image can be found here:

http://www.3dallusions.com/forums/mrmat ... stuff.html

Here are my material settings:

Code: Select all

<?xml version="1.0" encoding="utf-8"?>
<scenedata>
	<material>
		<name>BClay_phong</name>
		<phong>
			<diffuse_albedo>
				<constant>
					<rgb>
						<rgb>0.58400 0.31800 0.26300</rgb>
						<gamma>2.2000000000000002</gamma>
					</rgb>
				</constant>
			</diffuse_albedo>
			<exponent>
					<constant>80.0000000000000000</constant>
			</exponent>
			<layer>0</layer>
			<fresnel_scale>1.0000000000000000</fresnel_scale>
			<ior>1.8000000000000003</ior>
			<nk_data></nk_data>
		</phong>
	</material>
	<material>
		<name>clay</name>
		<oren_nayar>
			<texture>
				<path>C:/Users/31/sub/Entwicklung/cg/materials/indigo/clay/Fingerprints_bump_output.jpg</path>
				<a>0.0100000000000000</a>
				<b>0.0015000000000000</b>
				<c>0.0000000000000000</c>
				<uv_set_index>0</uv_set_index>
				<exponent>0.0400000000000000</exponent>
				<tex_coord_generation>
					<uv>
						<matrix>1.00000 0.00000 0.00000 1.00000</matrix>
						<translation>0.00000 0.00000</translation>
					</uv>
				</tex_coord_generation>
				<smooth>false</smooth>
			</texture>
			<albedo>
				<constant>
					<rgb>
						<rgb>0.69800 0.58800 0.49000</rgb>
						<gamma>2.2000000000000002</gamma>
					</rgb>
				</constant>
			</albedo>
			<sigma>
					<constant>0.3000000000000000</constant>
			</sigma>
			<bump>
				<texture>
					<texture_index>0</texture_index>
				</texture>
			</bump>
			<layer>0</layer>
		</oren_nayar>
	</material>
	<material>
		<name>BClay</name>
		<blend>
			<a_name>BClay_phong</a_name>
			<b_name>clay</b_name>
			<blend>
				<constant>
					0.75000
				</constant>
			</blend>
			<step_blend>false</step_blend>
		</blend>
	</material>
</scenedata>

[Zom-B]

I have trouble finding the bump value (a,b and c) of the texture you have here, but can give a general tip here.
Your texture is grey based centered, so RGB 128 shouldn't bump anything in any direction... its neutral!

To let that work in Indigo you need to set your c value at (0.5*b)* -1.
So a b value of 0.005 needs a c value of -0.0025...
Regarding the gamma value (or Texture Exponent) atm Indigo behaves quite strange, but a RGB texture for the bump channel needs a gamma of 1 (not 2.2!) to work probably!

if that doesn't help, try out dismissing the blend... I have more of a feeling that the issue is rooted there...

[solarray]

Ok thanks for the hint, maybe I have to think about the a/b/c behaviour again.
My current values for the bump texture are
a=0,01
b=0,001
c=0
exp=0,04

I get the same error when using only the oren nayar model with bump.

[CTZn]

It would be best to stick with the original version, solarray. Basically, setting a B value below 1.0 is a contrast reduction action so let's not crunch data down with your image editor.

You can try to smoothen the details slope by using an exponent value well below 1.0 but this effect, wich has been explained recenly by galinette, is inherent to bump mapping. Wether some core rendering trick could be used by Indigo in order to reduce it I can't tell.

Basically these dark regions are caused by a shading normal pointing away from the camera direction, wich is to say that this point should be simply hidden to the camera. But since bump mapping is just a shading trick these regions can not be hidden at all, so they appear black. Darker, say.

I don't know how normal mapping would behave in this situation, better possibly.

[Polinalkrimizei]

This a/b/c behaviour in bump mapping is really the most awkward thing within Indigo, giving head ache even to experienced users... and for newbies this must look quite experimental and unfinished!

[Zom-B]

its a mathematical approach that doesn't explain itself by naming A, B and C ^^

regarding Bump/Displacement I setup a simple scene that uses a small example texture with pure white, 50%black and pure black (see attachment)

displacement is a great debugger to see that your 50% black texture area is not moved:

RGB Texture with Gamma 2.2:

GRAYSCALE Texture with Gamma 2.2:

That was my actual settings for Gamma I used a loooong time... as you see its crap!
Here more examples of possible settings users may come up with:


GRAYSCALE Texture with Gamma 1.0 (VERY BAD!):

RGB Texture with Gamma 1.0 (Correct result, but why???):

GRAYSCALE Texture with Gamma 0.65656565 (Correct for Greyscale... but why???):

So am I just not understanding that whole topic (very likely) or is that some stuff going on in Indigo
(like double gamma correction ??!)
Is that also related to albedo textures where Gamma is set to 2.2 by default (Cindigo)???

P.S. I hope not to Hijack your thread here solarray, it seems quite related for me to bump that...


*** EDIT ***
I figured out that my PS colorsetting were messed up and my saved greyscale images were "shifted"

[solarray]

P.S. I hope not to Hijack your thread here solarray, it seems quite related for me to bump that...

No problem. Any discussion also about this a,b,c thing can be helpful to me.

[CTZn]

So am I just not understanding that whole topic (very likely) or is that some stuff going on in Indigo

I have always been using RGB textures for displacement so I never noticed that issue, but certainly the results are not user-friendly. Worth a report.

This graphical method is otherwise the best way to explain the texture parameters.

[Zom-B]

I have always been using RGB textures for displacement so I never noticed that issue

I switched to greyscale textures since the can save you a lot of RAM in texture heavy scenes!
Indigo loads each texture in RAW Format, so a 2048x2048 RGB Texture eats up 12MB of RAM (no mater if JPG or TIFF) and a Greyscale Texture of same size only 4MB.
Doesn't seem much, but a High rez Wood Material From Arroway I own, with 6kx8k Textures, using Bump + Exponent ends up with 411MB of RAM in RGB and "only" 233MB of RAM if I use greyscale for Exponent & Bump...
After discovering that I switched to greyscale but also found that "gamma issue"...

This graphical method is otherwise the best way to explain the texture parameters.

great for testing grey textures, but the color representation of albedo textures is harder to test... I'm not capable of that

[CTZn]

Well in my opinion the texture parameters are marginally usefull for spectrum textures (including albedo). But they are strictly necessary if one wants for instance to carve a displaced surface instead of adding volume to it (old example here with the pillars).

I'm not sure what the A parameter is for, I tend to prefer to use the texture exponent but that's mostly by ignorance from me; it's not implemented in the exporter for Maya, wich has otherwise native B and C implementations.

[solarray]

I don't know how normal mapping would behave in this situation, better possibly.

Is normal mapping implemented in indigo 3.4.0 ?

[galinette]

I have trouble finding the bump value (a,b and c) of the texture you have here, but can give a general tip here.
Your texture is grey based centered, so RGB 128 shouldn't bump anything in any direction... its neutral!

To let that work in Indigo you need to set your c value at (0.5*b)* -1.
So a b value of 0.005 needs a c value of -0.0025...
Regarding the gamma value (or Texture Exponent) atm Indigo behaves quite strange, but a RGB texture for the bump channel needs a gamma of 1 (not 2.2!) to work probably!

if that doesn't help, try out dismissing the blend... I have more of a feeling that the issue is rooted there...

The "c" value is the quadratic coefficient ( a + b*t + c*t²) and should not be used in normal cases I think. I suppose you want to say a and b, not b and c.

Also, the "center" or "constant" coefficient a has no effect on bump maps, as only difference between neighbor pixels are used. Adding a constant value to the whole bump map doesn't make any difference on the result

[galinette]

Well in my opinion the texture parameters are marginally usefull for spectrum textures (including albedo). But they are strictly necessary if one wants for instance to carve a displaced surface instead of adding volume to it (old example here with the pillars).

I'm not sure what the A parameter is for, I tend to prefer to use the texture exponent but that's mostly by ignorance from me; it's not implemented in the exporter for Maya, wich has otherwise native B and C implementations.

I'm quite sure the Indigo calculation is as follow. Let "x" be the read texture channel from the input file (scaled to 0..1 range), and y be the final value used by Indigo in the shading

t = x^exponent
y = a + b*x + c*x²

So : "exponent" is used to decode the gamma encoded value from the texture to linear scale. It can be also used to apply artificial strong nonlinear correction. -> Default is 2.2 for colors, 1.0 for bump
"a" adds a constant bias to the decoded value (such as "brightness" in photoshop) -> Default is 0
"b" multiplies the decoded value (scales, such as "contrast" in photoshop) -> Default is 1.0
"c" adds a square term if you want to somewhat non-linearly tweak the values -> Default is 0

Etienne

[Zom-B]

The "c" value is the quadratic coefficient ( a + b*t + c*t²) and should not be used in normal cases I think. I suppose you want to say a and b, not b and c.

No I really was refering to C.
To center the bump or displacement texture I use (0.5*b)* -1.
So a b value of 0.005 needs a c value of -0.0025...
The Displacement examples above are generated this way, and the visual feedback looks quite right (ignoring the Gamma "situation")

Also to flip a BW mask to WB for a blend map, I use: a=0, b=-1 & c=1

I have to admit that my math knowledge behind that a, b and c values are = 0...

Also, the "center" or "constant" coefficient a has no effect on bump maps, as only difference between neighbor pixels are used. Adding a constant value to the whole bump map doesn't make any difference on the result

But that would raise the overall value and the overall strength of the bump, for displacement you'll have some visual feedback for sure!

[lycium]

y = a + b*x + c*x²

We have it as y = ax² + bx + c