Brushed Aluminum

[ozzie]

Thx I'll check it in Monday.

where are you using it? in a <blend>, <bump>, <exponent>, <albedo>, or whatever?

basically blend, bump and exponent expect real as a return value, displacement, too, but without the "vec3 pos" as a parameter. albedo expects a vec3 as the return value. if youre using it in an albedo try this:

Code: Select all

def eval(vec3 pos) vec3 :
                  vec3(fbm(dot(getTexCoords(0)*1000.0, vec2(0.0, clamp(noise(getTexCoords(0)), 1.0, 5.0))), 4)*0.0003)

[CTZn]

uhm... it already uses infix operators?

Ah yes, I see what you mean, a pointless request from me... I was hoping for an even easier notation I think

(only sum, mult and such are concerned by the infix notation) isn't it ?

[ozzie]

It's working great :] !!!! :******* THX

[ieatfish]

I'm going to revive this thread. Schosch, your brushed aluminum is amazing but I have an issue with your material. I made a thread a while back here: http://www.indigorenderer.com/forum/vie ... php?t=8191

I recently got enough motivation to try and figure out how to fix it. Well, I failed. Can other people duplicate my results with that material? It happens any time I have a flat surface with curves.

[Meelis]

Hi

Plz help me out with how to move this shader from A's bump to B's albedo.
I want to see what the random stripes look like.

I read ISL Tutorial by Yves Colle from http://www.indigorenderer.com/book/export/html/1151
But so far material editor keeps crashing on my tests (i just don't know what i'm doing).

I do def eval(vec3 pos) vec3:.........from there i don't know how to edit
fbm(dot(getTexCoords(0)*1000.0, vec2(0.0, clamp(noise(getTexCoords(0)), 1.0, 5.0))), 4)*0.0003

I think i need to remove bump but what fully specifies it other than value 0.0003

A

Code: Select all

<?xml version="1.0" encoding="utf-8"?>

<scenedata>
	<material>
		<name>aluminium_brushed</name>
		<phong>
			<exponent>
				<constant>25000</constant>
			</exponent>
			<ior>1.60838</ior>
			<nk_data>nkdata\al.nk</nk_data>
			<diffuse_albedo>
				<constant><rgb>
					<rgb>0.8 0.8 0.8</rgb>
					<gamma>2.2</gamma>
				</rgb></constant>
			</diffuse_albedo>
			<bump>
				<shader>
					<shader>
						<![CDATA[
					def eval() real :
						fbm(dot(getTexCoords(0)*1000.0, vec2(0.0, clamp(noise(getTexCoords(0)), 1.0, 5.0))), 4)*0.0003
						]]>
					</shader>
				</shader>
			</bump>
		</phong>
	</material>

</scenedata>

B

Code: Select all

<?xml version="1.0" encoding="utf-8"?>
<scenedata>
	<material>
		<name>Unnamed</name>
		<diffuse>
			<albedo>
				<shader>
					<shader><![CDATA[def eval(vec3 pos) vec3 :
	vec3(0.4, 0.4, 0.4) # Return a grey colour]]></shader>
				</shader>
			</albedo>
			<random_triangle_colours>false</random_triangle_colours>
			<layer>0</layer>
		</diffuse>
	</material>

</scenedata>

[CTZn]

Hi meelis, I'm glad I can answer you. ISL is an exciting field with vast applications. I am going to give more details than you may need but that may serve others as well.

- - - -

Bump (as does displacement, phong exponent and several other material parameters) takes a real for value, aka float.

Converting a real to a color (vec3 => triplet of reals just like RGB) is as simple as:

Code: Select all

vec3(real)

wich will result in a "gray" shaded triplet, because the same value is then attributed to each of the three components. I'll explain the quotes around the gray word later.

Let's start with a practical example you can play with:

Code: Select all

# this declares a definition called 'someReal()' wich should return a real value
# we set the value to be returned to 0.5

def someReal() real :
	0.5

# making a vec3 from there
# this whole shader code will return a vec3 of value:
# vec3(0.5, 0.5, 0.5)

def eval(vec3 pos) vec3 :
	vec3(someReal())

Here you go with your 50% grey color !

Now, since the bump code does in effect return a real, you can make it a vec3 as exposed above:

Code: Select all

def eval(vec3 pos) vec3 :
	vec3(fbm(dot(getTexCoords(0)*1000.0, vec2(0.0, clamp(noise(getTexCoords(0)), 1.0, 5.0))), 4)*0.0003)

However, because initially thought as meters, the bump value was here multiplied by 0.0003 wich results in a height of less than the third of a millimeter. Take a pure white, multiply it by 0.0003 and you will find yourself with a nearly black color !

So you want to remove that 0.0003 real wich serves as a scaling for the bump mapping. You'll now have a full strength vec3, suitable for a color:

Code: Select all

def eval(vec3 pos) vec3 :
	vec3(fbm(dot(getTexCoords(0)*1000.0, vec2(0.0, clamp(noise(getTexCoords(0)), 1.0, 5.0))), 4))

Note that the bit below is indeed a scaler, but instead of scaling the output value it is acting on the UV coordinates alone, you want to preserve that one in order to keep the features very small. In other words, this chunk scales the shader horizontally, not vertically:

Code: Select all

getTexCoords(0)*1000.0

Now why did I put the gray word between quotes ? Because a vec3() triplet can hold negative values, and such values within an albedo will always be clipped to 0.0, resulting in pure black. Because noises in Indigo are returning values between -1.0 and 1.0 (afaik, but those max are never really attained out of the box, they are strong limits), you want to divide the output by two so it fits within [-0.5;0.5], and finally add 0.5 in order to push this range within the [0;1] range:

Code: Select all

def eval(vec3 pos) vec3 :
	vec3(fbm(dot(getTexCoords(0)*1000.0, vec2(0.0, clamp(noise(getTexCoords(0)), 1.0, 5.0))), 4) / 2.0 + 0.5)

Here you go ! Well, hopefully that's valid code, I kept it in a text editor it's untested

[Meelis]

Thank you CTZn

It works

[Meelis]

Hey

What are this weird looking areas and why they happen?
It was in 2.4.13, gonna update real soon

Looks like scale bug. Happens in bump and albedo with fbm noise shader.

~ 0.36 - 1.00 in video
http://youtu.be/Da8Uz5CFQag?hd=1&t=35s

[CTZn]

They have the shape and size of the noise function declared, effected by a clamping effect. It's a programmed thing, the values you are inputing are unbalancing the shader. Not a renderer bug

I do not have a good enough understanding of the dot() function yet to explain you, but basically the V parameter of one of the terms is clamped into a very low amplitude (hence the balance loss I suppose). That must defeat the hardcoded (shader) /2.0 + 0.5 correction.

[Meelis]

Okay i see.