MayaToIndigo_1.0.95_beta3

[CTZn]

This release should work with 1.1.13, hence I recommend this move. However features remain the same as in 1.0.9_3, current work resides in internal modifications to lay the ground for new shader definition down. In this regard, your feedback from now and during the coming dev process is vital.

Layer and Emission features were removed as well, since old and new shader definitions can not coexist.

MayaToIndigo_1.0.95_beta3

I don't like disclaimers because I believe we are responsible of our actions, but if you are using Indigo in a formal environment, ask everyone around you to go to the ground then hurl "grenade !!!" before clicking the "Export Scene" button. Word.

Ah... the python plugin may throw errors wich are no showstoppers, you can safely ignore them, unless they prevent the use of indigoShader's.

[CTZn]

I think the next big release will lose compatibility with 1.0.9, so if in the meanwhile you have some features/fixes you need now, just ask here I'll do these before the big thing.

For now I've just noted Hellstorm's request of changing how absorbtion is put in. Changing this will have as a consequence to change blinn color in viewport to the invert (absorbed) value, wich is indeed counter-intuitive, but actual implementation lacks the precision needed sometimes.

[Hellstorm]

Yeah, may be I'll have a better idea one day, but at the moment that's the only one

[Sinister]

Do this compatible with indigo 1.1.14?

[CTZn]

yes, but it still uses old syntax for xml*. That means that emission is not implemented, you must use meshlights instead. It is compatible because new indigo versions are compatible with older xml scenes.

But I can recommend you to wait for the next version of MtI wich should come this monday; with the ability to use spectrums even to define a diffuse parameter, as Indigo allows it. Actually you will be able to set spectrums (amongst blackbody, peak, uniform or rgb) for:

Diffuse (and transmitter):
<albedo_spectrum>

Phong:
<diffuse_albedo_spectrum>

Specular:
<absorption_coefficient_spectrum>
<scattering_coefficient_spectrum>
<phase_function> (hg or uniform)

while before (or still, for you) only 0 < rgb < x (eventually more than 1) was available. I'm looking into generalizing this as much as both Indigo and current MtI core allow it.

Also spectrums were streamlined to be exported from a single rgb attribute, with the following limitations and ehancements:

- If R = G = B !=0 -> uniform

- if 0 <R <= 255 -> RGB

- if 400 <= R < 800 (?) -> Peak, respectively start, width and peak value. Base value is then forced to zero (yes this is a limitation, saturation will be at max with peak spectrum)

- if 800 (?) <= R < (not limited, hum) blackbody, r = Temperature; g = gain, and for meshlights you can still specify both efficacy parameters. they are no more forced to the previous values.

- plus i may document a way of managing hand written shaders for export, with your help Sinister (remember that phongE I couldn't use ? Now I can and that's thanks to you).

All this for the upcoming release (and maybe more) !

*Of course not all features of Indigo 1.1.14 are implementd

[Kram1032]

hmm... what's about IoR? Can't that also be a spectrum? All those colour- or absorption spectrums are roughly like the "k" (or it's inverse) in nk-files... the "n" is the IoR....

[CTZn]

Well, definitly not spectrums but volumetric values, could be... IOR is a scalar, a ratio, not a compound value like colors. I guess that's about the best I can answer I'm afraid...

[Kram1032]

but IoR also is wavelenght dependend...
Making IoR spectrum-based might be the same as making Cauchy-B spectum based... Dispersion comes from different IoR for different wavelenghts...

[CTZn]

I understand your point better than physics, Kram (and that means it was very difficult for me to answer you), but I shall stick with the documentation, wich specifies IOR's type:

type: real scalar.

NK data type is supported by MtI, so are tabulated spectrums, now I'd like to try a fbm as IOR (for a medium) but am not at ISL now... This question you have may be logical but it is also a technical issue as far as I'm concerned, by the way too technical for me right now.

Making IoR spectrum-based might be the same as making Cauchy-B spectum based

I never heard about that one... Cauchy coeff is a scalar too Kram, I would not try to plug a spectrum in it. Could you ?

By the way, concerning <phase_function>, i'm not making a spectrum element out of it, it uses a dedicated function to switch between uniform/ and HG functions.

I'm going to improve that very function, and probably remove the uniform spectrum from the gen proc and use a separate slot for it, as I didn't grab the specificity of the uniform curve. PureSpider gave me a hint I'll try for that.