Shader tests

[cpfresh]

basically, floor rounds down to nearest int, and ceil rounds up to nearest int...? i'll give it a go. thanks!

[Kram1032]

I think so, yes
"floor" and "ceiling" Very intuitive names, actually...
I'm not sure, is there actually a "round"- function implemented in Indigo?
with floor and ceiling, there are problems with rounding negative values. They become wrong. To solve that, you'd need to use the absolute value and multiply the "direction" to them, afterwards (sign) - though, that makes troubles with zero, which needs an extra definition sign(0):=0 or you need to deal with NANs...

[OnoSendai]

Actually there is currently no function for converting a real to an integer and vice versa.

Perhaps I'll add

floorToInt(real x) : int,

ceilToInt(real x) : int, and

real(int x) : real

[OnoSendai]

Messing around trying to create marble, using some some of the new shader funcs which will be in next build - clamp, lerp.

Not entirely successful, but I think it's promising at least

The code:

Code: Select all

<material>
		<name>previewmaterial</name>

		<phong>
			<diffuse_albedo>
				<shader>
					<shader>
						<![CDATA[
							def col(real x) vec3 :
								if(
									lt(x, -0.4),
									vec3(0.8, 0.8, 0.8), # highlight white
									lerp(
										vec3(0.2, 0.1, 0.1), # Dark red
										vec3(0.4, 0.15, 0.15), # red
										clamp(x, 0.0, 1.0)
									)
								)
									
							def eval(vec3 pos) vec3 : 
								col(
									fbm(
										mul(mat3x3(10.0, 0.0, 0.0, 0.0, 200.0, 0.0, 0.0, 0.0, 200.0), pos),
										10
									)
								)
						]]>
					</shader>
				</shader>
			</diffuse_albedo>

			<ior>1.4</ior>

			<exponent>
				<constant>1000.0</constant>
			</exponent>
		</phong>
	</material>

[OnoSendai]

btw, stuff for next release:

1.1.12
* added min, max, lerp, floorToInt, ceilToInt, real(), clamp to shader lang

[CTZn]

Sure it looks promising Ono, I think people used like me with procedural textures (sadly through an ui) can't wait to play with the shader language...

I would use it to make a low res bitmap look higher, or make it less repetitive (both by blending it with a proc one), things like that...

can't wait, too bad I'm not saavy and patient enough to go with formulas !!!

For marble... you are closing, but in maya video link the lerp is not coloring fbm, but fbm pertubs lerp projection onto the surface



fractal is offsetting U&V



If the exercise was to use latest commands, then nevermind btw it would be cool to be able to specify lerp entries number and position (0;1) along with the color value.

[Kram1032]

as long as the floorToInt function isn't called floorToInt, it would be nice
real(int) - does it floor, ceil or round?
And what's about that:

round(real,int)
real is the number to round, int is the number of decimals...
(has to be an it, obviously) + hidden check "if int = 0 -> real -> int"
In my opinion, real and int should be pretty much dynamic, so that you can add a real and an int, resulting in a real or you could substract two reals so that the result is an integer... And Indigo should recognize it as integer.
Or differently said: If there's a function, requiring integers, where you put in a real, check if that real also is an integer or if you need to put out a warning...
And you can also give a warning without stopping the progress and internally automatically use round(real,0)

[cpfresh]

Onosendai, that marble is looking cool. And CTZn how does that setup in Maya work, can you explain what is happening in each step of your diagram, ... maybe someone could translate that into Indigo Shader Language? It looks like the texture is sampled and fbm in a linear fashion (lerped?) and then there is one more step ...?

The new functions will be very useful it seems. More info on the real->int conversion would be cool too. It sounds like it's meant to be a typical rounding: x >= 0.5 up; x <= 0.4999999 down. I like that.

toReal(int x) real :
toInt(real x) int :

[cpfresh]

here is an image of my cmu block shader. im having scaling issues right now and cant get it to show on the matdb preview scene. but in any case, it is working. once the new shader functions are implemented the code can be optimized slightly.

[CTZn]

cpfresh: the place2dTexture nodes are linking the texture with the UVs of the surface to wich the shader is applied.

The fbm is not used as a coloring element, but it's values sampled at x,y will shift (be added to) the one in x,y of the stripes texture. The result are perturbed stripes (refer to the video link above)

So it's a two step process: apply stripes as color, then shift their UVs values, as read by Indigo, with fbm.

[cpfresh]

it looks as though it is fbm'ed twice as there is a 'moderately' scrambled first image followed by a kind of smudged over second image. pretty cool and should be doable with the ISL

[CTZn]

No no it happens once only, the node called marble1 in the picture is maya built-in, it's here as a reference only fractal1 smudges stripes UVs, that's it.

I think it's readily doable with ISL and has many applications.

Hey, you already did a great blend texture for bricks !

edit Actually grimm achieved the exact same effect I'm describing, aparently at least (I don't get isl yet).

[cpfresh]

bricks FTW!!!

[OnoSendai]

Erm, I am already using the FBM to perturb the position that is sampled from the 1-D 'colour function'

[OnoSendai]

as long as the floorToInt function isn't called floorToInt, it would be nice
real(int) - does it floor, ceil or round?
And what's about that:

round(real,int)
real is the number to round, int is the number of decimals...
(has to be an it, obviously) + hidden check "if int = 0 -> real -> int"
In my opinion, real and int should be pretty much dynamic, so that you can add a real and an int, resulting in a real or you could substract two reals so that the result is an integer... And Indigo should recognize it as integer.
Or differently said: If there's a function, requiring integers, where you put in a real, check if that real also is an integer or if you need to put out a warning...
And you can also give a warning without stopping the progress and internally automatically use round(real,0)

It's called floorToInt() because it floors the real, then converts it to an int.

real(int) doesn't need to round, as any integer can be represented exactly by a real (64 bit floating point number)

I prefer strong typing with no implicit type conversions, thanks. So no automatic real -> int conversion of vice versa.