MtI rev 14 20 oct 2007

[dougal2]

Rev:
14
Author:
doug
Last modification:
Rev 14 - 2007-10-19 14:24:59 +0100 (Fri, 19 Oct 2007)
Log message:
Changed Documentation.txt to include info about meshlight power.
Changed mtiMain.mel to reflect same default advanced render settings as blendigo (improves SSS performance).
Added sss_1.ma test scene (Saved from Maya v8.5).

[CTZn]

I'll check your settings; I always tweak that to my taste, in fact I burn them into mtiMain. Likely, every person able to edit a bit of mel will do so.

Have you thought about restarting a new structure for MtI ?

[dougal2]

restarting a new structure?
why? how?

i think i'm going to work a little on bringing it up to date first, then think about possibly changing a few things just a little (I'm looking at all the custom attribute stuff, and perhaps a more logical mapping of attributes to indigo material properties).

any ideas or help you (or anyone else) can provide would be appreciated.

[bkircher]

Dougal2, I like the approach very much. Documentation is great and legible.

I didn't check in detail, but it is this based on the simplified scripts?
http://www.indigorenderer.com/joomla/fo ... php?t=2610
To my mind, they where way simpler and used less mel-procedures.

cheers
b

[dougal2]

Dougal2, I like the approach very much. Documentation is great and legible.

thanks.

I didn't check in detail, but it is this based on the simplified scripts?
http://www.indigorenderer.com/joomla/fo ... php?t=2610
To my mind, they where way simpler and used less mel-procedures.

cheers
b

no, actually it's not. it was based on the other one.
in terms of actual changes, I've made the system() call to start indigo work, changed the default advanced render settings, and written some documentation.
complete changelog

so... before it's too late - where do we go? should we swap over to the simpler version? are there any major differences?

[dougal2]

ok, having tried the simpler version I have both a few ideas and questions.

The "Full" version
--------------------
Pro:
I think it's easier to use.
More of the features seem to work (specifically, lights).
Direct render works.
I like the directional light for sunlight, and the mesh widget for meshlights.
Con:
There seems to be a fair amount of redundant code in it.


The "Simple" version
------------------------
Pro:
I really like the script node for the settings.
I like the slightly more compact layout.
Con:
The icons don't work.
I couldn't work out how to export any kind of light.
The menus aren't being used very effectively (ie. at all).


Now this is the big question -- actually there is an assumption first:
Do I assume correctly that it would be best to combine the best of each of these exports into a single exporter, and maintain just one exporter?

If yes, then the question is: How do we achieve this?
If no, then I'm going to concentrate on bringing the Full version up to date, and would like some help with regards to integrating the script node for render settings into it.

Your thoughts please.

[CTZn]

Thoughts... or questions !?

- can we create specific nodes and AE window for each of the following:

• materials <material>
  lights <meshlight>
  instances <model>
  etc...

so we don't mess at all with maya software's parameters (suggestion n°1)

- or we create extra attributes in maya's nodes, but only to allow the material/object editor to read/write them, ie the user will use mostly, if not only, the editor to set lights, instances, etc... properties. Suggestion n°2 is: Revive the editor windows.

Also why not create a monolithic shader node, wich will update content according to material set (as when you change the type of a shader in the AE). Not sure if what I say makes sens...

Finally I agree first priority is to integrate Indigo's features as fast as possible, we're too late for a rebuild now (if you rely on my skillz).

[bkircher]

1.
Concerning the more simple version:

There may be some bugs in the code, and I'll post one final update soon.
IMHO, we should stick use the "simple" version as a baseline and then add
one feature at a time, make it nicer, ... .

Using a Maya Node to store the MTI-Values is easy to access, is saved with the file, and can be easily adopted by simply changing
"mti_ScriptNode.mel".

2.
I agree that it is still a crude version - but it simplifies the code and eliminates the use of internal mesh-exporters, plug-ins, etc.

I also agree that a working Material Editor would be very nice:
It should parse all Phong, Lambert, Blinn and incandescent materials, create a list of them, and present the Attributes in Indigo-Terminology.

3.
Excellent if starting Indigo from Maya works finally ...

4.
Dougal, I think maybe the Meshlight works fine, but you might have to set the Emitter Colour to be incandescent RGB,
with
R being the Colour Temperature (set to ~6500),
G being the Power Drawn in Watts (~28W for a bright fluorescent tube),
B being the Efficacy, (~60 (%) for a fluorescent tube),
so a typical 1,1,1 efficacy will be both invisible from the spectrum, underpowered with 1 Watt at 1 Percent efficacy.

5.
Maybe the Icon path is not found and you have to copy the Icons to your standard user Icon directory?

Regards,
b

[CTZn]

Why not stick with the simplified one, thought I haven't tested it, yet... then put a svn on it beside the "old" MtI, Dougal, coz I'll have to integrate code again

Maybe, when one plan to work on some code chunk, would it be cool if he announces that here so there will be no conflict. Maybe I'll be able to integrate something concerning rotation matrices tomorrow, in order to have some control on instances rotation... fingers crossed.

[CTZn]

Oh and about renderer settings: IMO the distro should have the factory ones, as set in the inifile by Ono.

Generally speaking the three of us use different settings, and as developers we tend to export them with our code; I think it would be a nice effort to let our ego apart and deliver an exporter neutral to what Ono's settings are. That could be generalized to the whole piece. Amen

[dougal2]

Why not stick with the simplified one, thought I haven't tested it, yet... then put a svn on it beside the "old" MtI, Dougal, coz I'll have to integrate code again

Maybe, when one plan to work on some code chunk, would it be cool if he announces that here so there will be no conflict. Maybe I'll be able to integrate something concerning rotation matrices tomorrow, in order to have some control on instances rotation... fingers crossed.

i think either which way round, there's going to be some replication of work already done.

I'm happy to start the process again from the simple version. There's only 2 major changes that I made, and now that I've figured out the correct system() command, that is fairly easy to implement back in.
(the other change I made was formatting all the source nicely, not hard but a little tedious.)

I'm not sure how your last updates compare CTZn - can you give us an idea of what you did?

I don't think it's a good idea to maintain 2 versions of the exporter.
For now, I'll make no more amends on the SVN (currently rev 15), and I'll swap the code over at some point.

I agree about default settings being same as the shipped version. That's not so hard to implement.
On the subject of settings - I was trying to work out earlier why the -t parameter for number of threads wasn't working.
apparently we'll have to include an "auto|1|2|3|...etc" option somewhere, and if it's not on auto then override the auto_choose_num_threads setting before settings the -t command line.
Ono could possibly be persuaded to make the command line override the inifile/XML I think if it's too much of a PITA.

b:
I think the only real issues I had were regarding your points #4 & #5 - but that could be easily solved with a little documentation i think... more user error than bugs
Also, PM me if you want SVN access. Even if you don't know what SVN is, PM me and I can guide you through - I think it'll make the development process a bit easier (and disaster-proof).

Apologies for length etc, but I think there's a fair bit of work to do and I think it's never a bad idea to do a little planning

[CTZn]

Length is ok as long as we keep focusing on the topic

Changes I made AFAIR (gotta be more serious on todo and done txt files):

- The sun creation (was a simple nurbs sphere b4)
- removed mtiGen.mel line 5: Object's name is not unique: progWin when user had'nt closed progress window b4 exporting again.
- makeMtiInstances procedure
- added hspp and hybrid locally but I found b. had integrated hybrid already, so I left it as is
- fixed error when initialShadingGroup wasn't declared in xml/igs, and initialParticleSE was declared instead but not used at all
- added gamma beside rgb in absorbtion spectrum but not in other tags where it is required now (mtiGen l282)
- messed up (ie untested) with reading of incadescence array, second value was declared as index [2] wich is the third term (arrays first index is always 0), that is B or V, while the doc was stating that the second term (G or S) should be used.

That's all I can remember of, and since everyone is coming with it's updates the code has to be arranged again. I suggest someone courageous does that (a girl ? ), I am supposed to implement rotation matrices for instances within 7 days and that's a big topic for me, but a friend of mine did that fingers in the nose (cheers guillaume !), indigo approved I still have to translate his TI basic language code into mel, shouldn't be too hard; if multiplying arrays (or matrices) is not to much of a PITA in Maya

edit: so at least I will implement the makeMtiInstances code myself to add random rotations, say around the up axis for a beginning (trees and common objects relying on a surface floor), that in the "newminindigofromaya" box.

[bkircher]

Sorry, but I'm getting confused.
So I'll add to this a final version of the reduced approach.

Dougal, I'll look into SVN for the next steps, and again, great work.

- - - - - - -
What I added/changed:
Added some quick-access Icons of tools I found I was using a lot.
Fixed some things that were broken.
Pieced together a crude version of the system command that works with the simple version, for me...

- - - - - - -
What needs fixing:
Background Colours
The Camera can become distorted, maybe we should roll back the camera
FoV-Settings... Anyone knows the formula for translating Maya-Camera statements into Indigo-Equivalents?
We should add IES-Support asap, and for this it is pretty cool if Ctzn is looking into rotation matrixes. Incidentially, I'd like the idea of randomizing locators in Maya and Exporting them with the correct angles.

[dougal2]

ok, i commited that to SVN alongside the "Full" version.
I've also added loads of stuff to the TODO.txt.
This brings us to revision 21.

I suggest that for any further development, you:
1. check out a revision from SVN (or get an update)
2. acquire a lock on the file(s) you want to work on
3. do whatever hacking
(3a. update TODO/readMe/Documentation)
4. commit your changes
(4a. WITH a log comment please )
5. release your locks.

[CTZn]

How does the locking mechanism works ? Can 2 devs work on the same file in parallel ? I was hoping SVN would compare two versions of a file and merge them nicely are the todo/readme/docs SVNized ? Is there a specific way to announce what you are currently working on (I'd like to know about that) ?

yep I'll first test, finally, the "mini" one today and start messing with it later, I'm really glad to see we are focusing our efforts !

edit: bkircher: have a look at the previous thread, dougal gives a quick how to wich helped me a great deal on SVN.

edit2: if all the coming versions are to be under SVN, let's create a new SVN thread and update the top post, instead of creating a new topic on every mod Does SVN keep older versions up ?