Page 1 of 6

MtI 0.9 (19 nov 2007 release)

Posted: Tue Nov 20, 2007 7:39 am
by dougal2
I want to get this release out for two reasons:

- MtI now makes proper use of Hypershade for your texturing.
Your scene textures/ and objs/ folders are now auto-created, and all your textures are automatically copied over from your Maya project folder.
This also applies for bump and exponent maps.
(Exponent map = file texture on Cosine Power of phong shader)

- the Wiki has been kept thoroughly up to date and documents this version, which is quite different from the previous release.

Please read the included text files for more information.

Posted: Wed Nov 21, 2007 12:11 pm
by dougal2
REV 126
implemented halt spp as command line option for RenderDirect, as it seems to be commented out of renderer_settings ?? :?
also did the same for halt time while i was at it.

also added in renderSavDir so that renders are output in a subfolder of where the scene file is. (useful for local render).
*spots another inconsistancy* I've posted in Bugs/Requests forum as to why IGI and EXR aren't saved here also....

Posted: Wed Nov 21, 2007 12:25 pm
by CTZn
also added in renderSavDir so that renders are output in a subfolder of where the scene file is
Oh that is possible ? Nice one then !

I got to admit that I'm not helping much... I'm currently translating the wiki into french, by the way I am develloping some points further and I will later integrate them back in english page. Specially about sun, Dougal :) Unless you have changed it's behaviour only the position of the Sun relative to the origin of the scene does matter, not the angle. (c’est un vecteur) ;)

Posted: Wed Nov 21, 2007 9:44 pm
by dougal2
the renderSavDir applies only to PNGs though at the minute.

it's actually the sun angle that matters, but that's essentially the same thing as it's position relative to it's locator because of the constraint.

Posted: Thu Nov 22, 2007 3:15 am
by dougal2
there's a bug with instancing....

the instances seem to be output relative to the position of the original, rather than the absolute position of the instance locator.

can we sort this?

Posted: Thu Nov 22, 2007 3:42 am
by CTZn
All obj objects have their center of origin reset to the center of the scene when exported, they will be transformed from that point. You can verify that easily: all models have <pos> at 0 0 0. For that reason originals have to be in the center of the scene. What should be sorted out is not to show the original if you don't want it to appear in the center of the scene (ie comment model out):

Code: Select all

    blah blah
Another way to demonstrate this is to create any primitive, transform it (move + rotation) export with MtI, then reimport obj back into Maya. It's position will be 0 0 0 again but it will rely where you leaved it, transformed. At the end original obj transformations are added to instances transformations.

That's a limitation I forget to document, thanks Doug.

Posted: Thu Nov 22, 2007 4:28 am
by dougal2
no.. there's another way, which I've just tested.

Simply subtract the position of the original from the position of each instance.

Then, each instance renders at it's location on screen, and the original can be somewhere off-camera.

I've also done some updates to the progressBar to make it work better. I'll commit this, you test it and tell me what you think ;)

REV 127
- Instances export at their location on screen, not relative to the original
- better use of progressBar

LIMITATION: the instanced object and it's transform should be called xObjectN and xObjectShapeN - need to find a better way of getting a mesh's transform position than simply removing the word "Shape" from it's name :?

Posted: Thu Nov 22, 2007 5:34 am
by CTZn
That's right, I didn't mention that because that was too complicated I thought, nice one.
need to find a better way of getting a mesh's transform position than simply removing the word "Shape" from it's name

Code: Select all

listRelatives -parent $shape

Returns a list, item [0] should be the transform. Is that what you meant ? Also I discovered pickwalk command recently.

Posted: Thu Nov 22, 2007 5:34 am
by dougal2
where are you? i see you've done some updates recently, but there's no word here or in the docs as to what you've done.

Also, I'm finding that since you removed the 35mm button, the camera isn't lining up quite so well any more. any ideas?

Posted: Thu Nov 22, 2007 5:36 am
by dougal2
CTZn wrote:

Code: Select all

listRelatives -parent $shape
yup that's exactly it :)

Posted: Thu Nov 22, 2007 6:16 am
by bkircher
still there...

havn't had the time to do much actively...

I do agree, the camera is aligning somewhat strangely (there has been a correction factor in the "old" way indigo exported the settings).
Maybe Maya has a different understanding of film back?

I like the direction this whole project is taking a lot (textures, fixing the instances...), btw.

With this instancing trick, I think scaling may behave strange as the pivot is still off mark.

Posted: Thu Nov 22, 2007 10:34 am
by dougal2
latest changes:

131 / doug 0 minutes
updated indigoCamera to produce correct camera matching

no longer required.

130 / doug 18 minutes
comments only


correct command for getting instanced object's parent transform
tidied XML output


changed routine to open and close the file fewer times. was aiming for once only, but it makes sense to let Instances write separately.
Also the writeBuffer is cleared from time to time which should help memory usage on large scenes.
XML output is now shown using notepad, if the user requests (new mti_setting)

moved convertAllProc here

new settings for render priority and view XML

left align text

129 / doug 3 hours
updated README.txt for UserPrefs change

128 / doug 3 hours
corrected error in mti_UserPrefs.mel


going to test instancing now.

Posted: Thu Nov 22, 2007 11:29 am
by bkircher
REV 132:
Icon indicated presence of SUN/indigoCamera, changes to pick status for both if they exist.

Introduced mti_ModuleGUITools.mel, since it's not really related to writing data.

Put 35mm back in for test reasons.

Posted: Thu Nov 22, 2007 11:37 am
by dougal2
bkircher, must have read my mind about the camera check.. was about to commit that too

REV 133:
removed my instance translation substraction - you were right, it messes up the rotations.

is there a way we can get object locations into the <model> tag and out of the obj data?
would it be too wrong/slow/tedious to
-get every objects location,
-move it to the origin,
-export it,
-move it back,
-use the location in <model>

Posted: Thu Nov 22, 2007 11:39 am
by dougal2
bkircher you forgot to commit mti_ModuleGUITools.mel