Indigo Renderer Forum

There is a confusion going on I think, and I would like to do something about this.

MtI does not attempt to approximate Maya shaders, it uses what they have in common with Indigo materials and add to them what they need in this regard.

I want to keep shader interpretation as an option. Would you like it ?

What's the first thing that you would like to see coming about shaders ?

What do you mean by "shader interpretation" ?

Lemo wrote:What do you mean by "shader interpretation" ?

I mean approximating Maya shaders into Indigo blends, mostly. Eventually the mia shader.

It would come at a cost, less fuzz on the user side but "slower than you would expect" materials. That's not my preferred option, I would rather expand the plugin flavor.

I'm just trying to put the finger on what is puzzling users the most about MtI and materials. Is the missing indigoShader viewport feedback n°1 ?

Lemo wrote:"slower than you would expect" materials

You mean a maya shader is slower to render than an indigoShader?

The most puzzling thing is probably to have two possible options for one apparently same result ?
I would suggest one of those:
-give indigoShader viewport feedback and delete maya shader's Indigo options
or
-add maya shaders transparency support and remove the indigoShader

Anyway I have no idea how all of this is implemented so just do what you think is the best.
As far as I am concerned, I'm perfectly fine with the actual thing, now that I know a little more about it.

-give indigoShader viewport feedback and delete maya shader's Indigo options

Oh that would be quite neat :]

Check out how the other exporters do it.
I just had a look at Cindigo, to make a new material you create a new 'Indigo material' which contains all Indigo material options. It's generated icon reflects the material changes, and also in the viewport (Ie: specular makes it transparent etc).
So this would translate to a singular IndigoShaderMaterial as is currently implemented. I personally prefer this option, as I know where all the Indigo-related material options are - and can get expected results.
Whereas if mti were to translate all Maya materials (lambert, blinn, phong E etc) it would be far less accurate of what I want.

The confusion for me is I don't know when to use the Indigo palette, and the Attribute editor (as you know I prefer the attribute editor).

Interesting, in both cases knowledge of the current exporter is playing an important role with user's preference (yes I'm naïve lol). I'll fire the video tuts any soon, it's about time for an introduction

Soup wrote:

-give indigoShader viewport feedback and delete maya shader's Indigo options

Oh that would be quite neat :]

Okay. My ideal setup is nearly this, but with an indigoShader exploded into various nodes for clarity. Though, I may have figured a way to have a dynamic AE on custom nodes. I'm guessing that a better AE for the indigoShader could be a good alternative meanwhile.

an indigoShader exploded into various nodes

How do you mean? A different node for each material type? IndigoDiffuse; IndigoSpecular etc?

It's an interesting dilemma, as Hypershade users expect nodes to do all sorts of crazy things with channels and connections - a lot of which would be too difficult, or not possible with Indigo. Whatever the interface, it needs to be clear what can be done and what can't be done, in relation to Indigo-specific attributes

And here comes a filtering UI

Yeah, kind of a dilemna ! But nodes may have methods to check what gets connected I bet.

Soup wrote:

an indigoShader exploded into various nodes

How do you mean? A different node for each material type? IndigoDiffuse; IndigoSpecular etc?

yup

Soup wrote:It's an interesting dilemma, as Hypershade users expect nodes to do all sorts of crazy things with channels and connections - a lot of which would be too difficult, or not possible with Indigo. Whatever the interface, it needs to be clear what can be done and what can't be done, in relation to Indigo-specific attributes

The documentation and attributes types together should do. Textures would get evaluated the same, I don't see a problem. The stake would be: how far would the integration go.

Only split them up if there is a real benefit from doing so. Having a single IndigoShader seems fine enough to me :]

Okay. I'll give a shot to these dynamic AE thingies, haven't evaluated their extent still. I don't like the AEindigoShaderTemplate at all