Indigo Renderer Forum

Restored the right camera aperture exporting formula, and indeed now the feedback for camera and linear tonemapping is sweeter for MtI users in Indigo UI, I apology about that mistake.

Fixed meshlights:

Incandescence of Maya materials is still used to determine wether they are actual Indigo materials, or just meshlights definitions. Specifically incandescenceR is used for that. See meshlights in Maya (note that this very meshlight section is the only one updated in wiki for now).

Added more spectrum types for some material parameters, I will document that soon (like for meshlights try to define a spectrum for specular absorbtion (blinn color. By the way blinn export (to specular) has changed)).

Get the beast here:

MayaToIndigo_1.0.96_beta1.zip

Ah, finally Can you write for what vesion of indigo this suggested? Because there is already new indigo:)

This version should work with 1.0.9 up to 1.1.15, but as before most features since Indigo 1.0.9 weren't implemented in MtI...

I must document how specular (blinn) works now, here's a sneak doc:

refractionLimit -> precedence
refractiveIndex -> IOR
surfaceThickness -> cauchy_b_coeff
color -> absorption_coefficient_spectrum (spectrum)
ambientColor -> scattering_coefficient_spectrum (spectrum)
incandescence -> phase_function (grey = uniform, else takes value as H-G value - not sure about negative values for this one)
transparency -> switch for specular transparency (on-off)

CTZn
Will this work with the new Indigo 1.1.15? Anxious to use Indigo/MtI again (now that there is finally a new linux build - exciting stuff!).

Yes Phr0stByte, just keep in mind that not much has changed since the last stable build, ie you will not find the most recent features in MtI.

I presume that I will not be able to provide linux-specific support, but let me know whatever goes wrong (that code hasn't changed). Be aware also that the documentation (aka the wiki) is wip, I have posted nearby on blinn changes, amongst others.

wb.

CTZn
Cool. One question - is normal mapping/displacement possible? I know its been in Indigo for a while now - just not sure if it is in the script (been Vray-ing with Maya for a long while now).

Normal mapping is not supported by Indigo, MtI supports bump mapping but not displacement yet.

I think there will be another release soon, this one has too much junk output. Hopefully Maya procedural texures baking will be supported by then.

CTZn
Hrmmm... The file is not there? Can't download the zip:

"The requested URL /svn-mti/trunk/dist/MayaToIndigo_1.0.96_beta1.zip was not found on this server."

yes btw, sorry... I'm fixing it right now.

Fixed, thank you Phr0stByte !

CTZn
Awesome! Thanx!

We don't like NKs anymore?

"indigo_x64_linux_v1.1.15/nkdata/Alcu.nk'...
Error: IndigoDriverExcep: SceneLoaderExcep: MaterialExcep: ComplexIORExcep: ComplexIORDataSetExcep: Only spectral units of eV supported right now. (In element 'phong', around line 73, column 5)
Stopped."

Correction: we never liked some nk's

I have the same error as you with 1.1.15, but also with 1.0.9_3... we knowt that some nkData aren't read by Indigo in no ways, Alcu.nk is one of those. 1.1.15 can render (as in my test scene) Al.nk, so I assume its behaviour with nkData hasn't changed since earlier versions.

Now, if you ask me how Indigo can discriminate amongst the two nk types (or why it's finding Alcu wrong), I would not be able to answer that...

Short: no stress, nothing has changed

CTZn
I actualy changed it to good 'ol Cr.nk and that worked fine, but got this error instead:

"IndigoDriverExcep: SceneLoaderExcep: MaterialExcep: ComplexIORExcep: ComplexIORDataSetExcep: Failed to open file '/home/phr0stbyte/indigo_x64_linux_v1.1.15/nkdata\fesi2el2.nk' for reading. (In element 'phong', around line 5, column 9)"

What is that about? Cr.nk was the only nk I was trying to use...

[EDIT] Figured that one out - it was a case sensitive problem with an IGM I was using. I still ran into another problem - this time with an object and not a mat. Just don't have the patients to mess with it further.

Uncheck Append in the Write to file & render section of the main window.

Since it was checked, MtI assumed you did no changes to material assignements and didn't export the geometries again. The matter is, Indigo is looking for the material defined within the obj file. If you haven't re-exported the geometries (ie uncheck Append) Indigo will read the exact same material calls in the very same objects.

Once you exported the obj beholding the new material assignements, you can check Append back, exporting will be faster because only xml will be written, obj files will be reused

CTZn
See above...