MtI 0.9 (19 nov 2007 release)

[dougal2]

PS: XBMLANGPATH can be used to set icons path as well.

that is true, but the installation is simpler without

[dougal2]

posted it in the tutorials forum:
http://www.indigorenderer.com/joomla/fo ... highlight=

CTZn: if you create vids and post them there, try to keep a similar thread title so that they all look consistant

[bkircher]

REV 163
Fixed Shell-Script output (Someone please double-check!), added "\"" statements to cope with "program files" annoyance.
Fixed a global scaling bug.

I guess we all use "_filename_01" convention wherever we can, except MS with it's urgent need to name one main System Folder "Program Files".

Next thing for me will be to take a (casual) look into AE-Templates:
From what I've seen, this is confusing stuff, but could help greatly with our pretty complex mti_settings thing.

@ Dougal, we must seem all phlegmatic to you.
i think we are near to a sound release. How about everybody checking the code again, introducing last changes and making a feature freeze:
We than branch the code and use a development thread to work on new features, and a stable thread to erase all the bugs, clean up the code...

p.s.: Please check the repository if everything is still in place, couldn't find the icons, etc. stuff after I started with a fresh folder and choose one of the database things....

[dougal2]

the repo looks fine.
BTW there's a web interface to it here
https://svn.hamsterfight.co.uk/listing. ... h=%2F&sc=0
where you can check the files present, view the log, compare changes etc.

You did manage to commit some junk files... i've just removed these and an update at your end should sort you out

Thanks for doing the GSF thing, that did occur to me, but slipped my mind to fix it.

I've also just disabled the pause command in the .bat output. If I'm rendering an animation, I don't want to hit a key for every frame (rendering overnight etc) - it kinda defeats the point of automatically putting all the frames in the same .bat file.

I also think this is fairly close to release.

[dougal2]

I've updated the video tutorial, now using flash video on the same gallery as all my other indigo related stuff. (I also edited it and re-synced it)
http://ftlfm.com/gallery/v/MtI/vidtut/m ... t.flv.html

If you guys have any feedback regarding the vid - visual/sound quality, usefulness etc I'll take that on board before I do any more.

[dougal2]

We than branch the code and use a development thread to work on new features, and a stable thread to erase all the bugs, clean up the code...

I think it's already pretty clean. I don't see a reason to branch it, that's just making 2x the work for ourselves.

Bear in mind that there are probably less than 30 people (here) using this script, and not one of them has yet reported a bug (yourself, me and CTZn excluded). I find that slightly odd, but it shows we must be doing something right.. ??

Over the next week or so, we could probably look more at tidying and fixing than new features (unless a new amazing version of indigo comes out with a must-have feature). We probably need a plan for this though so that we work towards a common goal and not just our own needs.

I agree that mti_settings could work better - there's a lot of stuff in there now.
Perhaps we should split it out into multiple nodes: mti_paths/mti_renderSettings/mti_cameraSettings etc

I'm not too sure yet what AETempaltes are, but I'll have a look at that also.

[CTZn]

Your video is perfect Doug, sexy voice and all, nothing to add

Concerning video threads: let's stick with one single thread, with categories progressively added in first post, or at least let's have a wiki page wich link them all; we don't want users to miss an important video tut.

@ Dougal, we must seem all phlegmatic to you.

Who !? What !? Huh !? AETemplates for instance; I talked about that at least a week ago, am still missing that upgrade but didn't do anything to help; not to talk about ObjectEditor and even that nasty clamp in Reinhard values. I'm the one to blame, even makeInstances is crying for a revision but I just can't get serious. Always too high on ...
- - - -

Now to some requests

1 - Cameras: Provided that the single difference between a Maya Camera and an Indigo camera is a single line of code (can't find the exact command again about setting node count to 3 ?), why can't I have a list of cameras and select the renderable one as in Render Globals ? Optionally the others cameras in scene could be exported as comments in xml so I can test them all in a row.

2 - Export visible only is not working. I would like to keep reference/history objects in scene without exporting them. Exporting to Indigo is a quite destructive process isn't it ?

Then finally MtI is ready to go, but the Maya audience is pretty much obnubilated by mental ray and many of them moke progressive renderers. We must sensibilize them to Indigo prior to presenting MtI, therefore we need an extensive list of Indigo's features and compare it with MtI ones. Thoughts.

[dougal2]

Concerning video threads: let's stick with one single thread, with categories progressively added in first post, or at least let's have a wiki page wich link them all; we don't want users to miss an important video tut.

yeah good idea. I can also convert to flash and put in my gallery for easy linking and viewing.

re: AETemplates
I think this is for compiled (binary) plugins from what I've read. Not a route I particularly want to go down; I can foresee huge version compatibility problems - even if we could create perfect custom Indigo nodes (ie, for shaders also).

re: ObjectEditor
Sketch a plan of what you want, even a non-functional GUI and we can start to fill in the missing functions.

re: that nasty clamp in Reinhard values.
Must have missed that one. Should be a matter of removing -min and -max from the attr in scriptNode ??

makeInstances is crying for a revision but I just can't get serious.

Well, every little that you can do will help.
I know that I can blaze through revisions with ease, but that's because I'm a professional programmer I've had a lot of practice.
If there's stuff you need to learn, I can help; just ask.

Now to some requests

1 - Cameras:
...
why can't I have a list of cameras and select the renderable one as in Render Globals ? Optionally the others cameras in scene could be exported as comments in xml so I can test them all in a row.

Nice idea. I'll have a look. I think we'd need a bit of dynamic GUI here... *starts thinking*.

2 - Export visible only is not working.

I can verify this. We could make much better use of the render/display layer system.

Exporting to Indigo is a quite destructive process isn't it ?

Not always. I very rarely actually delete any history. But there are some problems with hiding unwanted objects, I agree.
It depends also on what's present in the scene and how much history there is. Truth is, I don't have very many complex scenes, and pretty much all my modelling is in polys to start with.

Therefore we need an extensive list of Indigo's features.

Why should we do that ? I've already pestered Ono for an up-to-date manual and he said that he's on the case.
Perhaps if you ask as well, he might do it quicker

[CTZn]

re: that nasty clamp in Reinhard values.
Must have missed that one. Should be a matter of removing -min and -max from the attr in scriptNode ??

Yes please do ! In my magnaminity I agree to save -min's life.

We could make much better use of the render/display layer system.

Oh yes, definitly.

I've already pestered Ono for an up-to-date manual and he said that he's on the case.
Perhaps if you ask as well, he might do it quicker

Well maybe not, then. Dunno, the promotional aspect is somehow important...

[bkircher]

. I think we'd need a bit of dynamic GUI here... *starts thinking*.

2 - Export visible only is not working.

I can verify this. We could make much better use of the render/display layer system.

As always, do what helps you most, though personally I thouroughly dislike the render-layer system in Maya.

As to prefs-node, we could do something similar to MR - Use two seperate nodes (I think MR-Does this to seperate adv. from mainstream settings).
Also, we should connect the mti_settings.message attribute with the locators, so they are not "empty" to Maya and are not discarded with default clean-ups.

AETemplates are some evil magic that arranges the values accessible via the attribute editor in better readable way, it can hide elements and would eliminate the need to go under additional attributes: Apart from that, I have the vague feeling that it helps to define UI-Elements as string variables.

Apart from that, a direct access to the main-maya rendering attributes is a nice thing, otherwise we would have to go through all those disparate Maya-Nodes where the info is stored (obviously, fstop can be set at the camera attributes, but then we would have to open the Render Settings, the Camera Attributes, ... for a simple renderer - An alternative is to link the parameters...)

Puh, much text for little coding.

[dougal2]

Also, we should connect the mti_settings.message attribute with the locators, so they are not "empty" to Maya and are not discarded with default clean-ups.

which locators? Not all scenes contain locators

AETemplates are some evil magic that arranges the values accessible via the attribute editor in better readable way, it can hide elements and would eliminate the need to go under additional attributes: Apart from that, I have the vague feeling that it helps to define UI-Elements as string variables.

Do you know if this is for mel created scriptnode attributes, or for compiled .mll binary plugins? i get the impression it's for the latter, and not compatible with what we're doing with the scriptnode. I can't find much in the way of tutorials on this stuff.

Apart from that, a direct access to the main-maya rendering attributes is a nice thing, otherwise we would have to go through all those disparate Maya-Nodes where the info is stored (obviously, fstop can be set at the camera attributes, but then we would have to open the Render Settings, the Camera Attributes, ... for a simple renderer - An alternative is to link the parameters...)

linking sounds like a good idea.
If we can get the indigoCamera function to be able to create multiple indigoCameras (easy), and create a GUI control to select which one to render from (fairly easy, I think) [and keep it updated when the number of indigoCameras changes (ermm.. possible, dunno about easy)], then we can link the mti_Settings camera settings to the currently active camera. i think. Should be straightforward to implement, but I don't know if it gets a little contrived for the user.

[CTZn]

By chance I was trolling recently in a french thread where they set up a script to detect camera deletion, that may help:

http://www.mayalounge.com/viewtopic.php?t=571&start=8

I can translate comments if needed.

[dougal2]

cool, good find! I think that will help.