Requests with ISL!

[galinette]

Dear Indigo team,

I make intensive use of the ISL, as you can see here http://www.indigorenderer.com/materials ... iew_source and I am often annoyed of the parser and compiler bugs. Even if there is always a solution to avoid the bugs, it's quite annoying when shaders become complex...

I'm not fully sure of the exact bugs, but I am often annoyed with the prefix "-" operator which is not working well, as long as the integer not implicitely converted to float. It should have a math grammar behavior as close as possible to C.

Also, making complex shaders is a pain in the a##, because there is no possibility to declare/set temporary variables/registers. They would make code much more readable and they would also improve performance (to avoid computing some values twice, for instance). If variables are to difficult to implement, maybe some hardcoded registers (a few of real, vec2, vec3 types) would be enough.

The doti, dotj, dotk are quite unreadable, too. Some C style .x, .y, .z would be more easy.

The most complicated request : I often do the same expensive computation in the different shaders of the same material (for instance, in bump and blend). I'm pretty sure that Indigo computes them several times and this ends in a slow shader. It would be nice to define "global shaders" that pre-compute some stuff in "global variables" and are called just before the material shaders.

And, last, for the material editor : parenthesis coloring or highlighting would make complex shaders more easy, too. With the lack of variables, I sometimes have 12 nested parenthesis, in a tiny text editor window : you can imagine the headache. Also, it is not possible to tab them correctly for readability, due to the auto line wrap & non fixed width font. Every coder wants fixed size fonts & no line wrap!

Then I would be able to make more complex & efficient shaders...

Thanks for listening!

Etienne

[PureSpider]

Every coder wants fixed size fonts & no line wrap!

HELL yes!

[galinette]

Every coder wants fixed size fonts & no line wrap!

HELL yes!

At least, this one should be a very quick fix!

Etienne

[OnoSendai]

Dear Indigo team,

I make intensive use of the ISL, as you can see here http://www.indigorenderer.com/materials ... iew_source and I am often annoyed of the parser and compiler bugs. Even if there is always a solution to avoid the bugs, it's quite annoying when shaders become complex...

I'm not fully sure of the exact bugs, but I am often annoyed with the prefix "-" operator which is not working well, as long as the integer not implicitely converted to float. It should have a math grammar behavior as close as possible to C.

I agree, the expression syntax should be as similar as possible to C.

Also, making complex shaders is a pain in the a##, because there is no possibility to declare/set temporary variables/registers. They would make code much more readable and they would also improve performance (to avoid computing some values twice, for instance). If variables are to difficult to implement, maybe some hardcoded registers (a few of real, vec2, vec3 types) would be enough.

I'm doing some work on what will replace/upgrade ISL, (all going well) currently. There will be let clauses, which are a bit like 'constant variables'. This should help ISL readability quite a lot.

The doti, dotj, dotk are quite unreadable, too. Some C style .x, .y, .z would be more easy.

Sure. Until I support .x syntax, you could define x: def x(vec3 v) float : doti(v)

The most complicated request : I often do the same expensive computation in the different shaders of the same material (for instance, in bump and blend). I'm pretty sure that Indigo computes them several times and this ends in a slow shader. It would be nice to define "global shaders" that pre-compute some stuff in "global variables" and are called just before the material shaders.

This may be possible, but one must be pretty careful, due to thread safety issues etc.. Can you give me an example of an expression that you with to factor out in this way?

And, last, for the material editor : parenthesis coloring or highlighting would make complex shaders more easy, too. With the lack of variables, I sometimes have 12 nested parenthesis, in a tiny text editor window : you can imagine the headache. Also, it is not possible to tab them correctly for readability, due to the auto line wrap & non fixed width font. Every coder wants fixed size fonts & no line wrap!

Indeed, that does sound quite nasty. I would recommend coding in a programmer's editor and pasting the results into the material editor

Then I would be able to make more complex & efficient shaders...

Thanks for listening!

Etienne

np

[OnoSendai]

Hi there Galinette, all,
A bit of an update on ISL:

unary minus now works a bit better, you can do stuff like

Code: Select all

def main() int : -(1 + 2)

There is now a '.' syntactic sugar for vector / structure field access:
v.x is equivalent to x(v)

I'm currently working on type coercion (implicit type conversion) from integer -> float, which will be applied in some circumstances.

[galinette]

Do I need to define x(vec3) before using v.x, or is it built-in?

[OnoSendai]

Do I need to define x(vec3) before using v.x, or is it built-in?

It will be built in.

[OnoSendai]

Just added implicit type conversion, which applies in some cases:

Integer to float promotion in arithmetical expressions:

1 + 2.0 => 1.0 + 2.0

Promotion to match function return type:

def f() float : 1

Promotion to match required arguments for function expression:

def f(float a, float b)

f(1, 2) => f(1.0, 2.0)

Was actually surprisingly involved to get this to work in a reasonably general way, e.g. to allow stuff like this:

Code: Select all

def f(float x) float : x*x
def main() float : 14 / (f(2) + 3)

and this

Code: Select all

def main() float : (1.0 + 2) + (3 + 4)

[galinette]

All this looks promising!

Etienne

[CTZn]

A small one: fbm octaves as float.

eg: 9.2 would result in nine full octaves and the tenth dimmed down to 20% of its strength.

I'm guessing that current shaders would be compatible with this new declaration due to the integer promotion.

[CTZn]

I'm doing some work on what will replace/upgrade ISL, (all going well) currently.

Any more insights you may share, Ono ?

Now, about:

The most complicated request : I often do the same expensive computation in the different shaders of the same material (for instance, in bump and blend). I'm pretty sure that Indigo computes them several times and this ends in a slow shader. It would be nice to define "global shaders" that pre-compute some stuff in "global variables" and are called just before the material shaders.

This may be possible, but one must be pretty careful, due to thread safety issues etc.. Can you give me an example of an expression that you with to factor out in this way?

Abstract: by declaring a custom library with a fixed name, Indigo could embed custom definitions within into portable IGM's. As an incidence, the scope of ISL definitions would be less localized.

I'm also interested in this, perhaps you guys had a private discussion about it ? For instance in the stained glass material, the "voronoi" definition is present 3 times: in absorption_layer_transmittance, bump and blend, within two materials in total. I'm not sure concerning the computing footprint but in terms of readability and editing this is obstructing. If you want to modify the function then you must do it three times for that material.

I think that what Etienne wants is to place the ISL definition's scope at the scene level, possibly, so it can be shared amongst various materials and parameters without being rewritten for each.

Alternatively there could be a custom ISL library file with a fixed name for Indigo to seek, holding local definitions. If a material definition is using a def that is not hard-coded into Indigo nor into the standard library nor into the scenedata but into this custom lib, Indigo would embed that definition within the IGM. Or even better, into a third, portable library that the user could merge with its own local library if Indigo doesn't automatically.

Standard library: protected
Cusom library: expandable, manually or based on portable libraries found in IGM's

This could also be a nice way to share ISL snippets and increase ISL functionalities to the public. For instance, those below are trivial but may be of common use:

Code: Select all

#	abs: generalisation to vec3
	def abs(vec3 x) vec3 :
		vec3(abs(e0(x)), abs(e1(x)), abs(e2(x)))

#	mul: generalisation to vec3
	def mul(vec3 x, vec3 y) vec3 :
		vec3(
			mul(e0(x), e0(y)),
			mul(e1(x), e1(y)),
			mul(e2(x), e2(y))
		)

Well, something around those lines; not sure how clear I made myself

[OnoSendai]

Hi Guys, just a quick note to say that the new backend for ISL, codenamed 'Winter', should be getting merged into trunk very soon, hopefully this week. This will allow all the new stuff I have mentioned above.

Here's an example of some ISL code using the new let clause:

Code: Select all

def grid(vec2 uv) real :
  let 
    u = x(uv)
    v = y(uv)
  in
    if((fract(u) < 0.1) || (fract(v) < 0.1), 1.0, 0.0)
    				   
def eval(vec3 pos) vec3 :
  let 
    uv = getTexCoords(0)
  in
    vec3(grid(uv * 10))

[CTZn]

I'd use that clause already

It would be nice to allow <param> at the material level and have them taking precedence over those declared at the shader level.

In most materials cases there is a total correlation required between parameters.

Currently it is cumbersome to conform a dozen UI controls per parameter while most are supposed to be common to them.

edit: in my opinion one should find these UI controls above the parameters selection boxes, because they may affect many parameters at once.

edit 2: Etienne, I'm using your thread for a generic purpose, I hope that you don't mind !

[OnoSendai]

CTZn: We will add some kind of shared parameters, that will be per-material.

On another note, the Winter backend has now been merged in.
I've also added a new built-in function called gridNoise(), for efficiently getting random float values on the integer lattice (grid), when you don't need the full smooth Perlin noise.

Also built-in Voronoi is now much faster.

[CTZn]

Per material shared params is what I need, and thanks for the new functions !