MtI 0.9 (19 nov 2007 release)

Announcements, requests and support regarding the MAYA exporter
User avatar
dougal2
Developer
Posts: 2532
Joined: Wed Nov 15, 2006 8:17 am
Location: South London

MtI 0.9 (19 nov 2007 release)

Post by dougal2 » Tue Nov 20, 2007 7:39 am

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.
Attachments
MayaToIndigo09_20071119.zip
(194.88 KiB) Downloaded 214 times

User avatar
dougal2
Developer
Posts: 2532
Joined: Wed Nov 15, 2006 8:17 am
Location: South London

Post by dougal2 » Wed Nov 21, 2007 12:11 pm

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....

User avatar
CTZn
Posts: 7240
Joined: Thu Nov 16, 2006 4:34 pm
Location: Paris, France

Post by CTZn » Wed Nov 21, 2007 12:25 pm

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) ;)
obsolete asset

User avatar
dougal2
Developer
Posts: 2532
Joined: Wed Nov 15, 2006 8:17 am
Location: South London

Post by dougal2 » Wed Nov 21, 2007 9:44 pm

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.

User avatar
dougal2
Developer
Posts: 2532
Joined: Wed Nov 15, 2006 8:17 am
Location: South London

Post by dougal2 » Thu Nov 22, 2007 3:15 am

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?

User avatar
CTZn
Posts: 7240
Joined: Thu Nov 16, 2006 4:34 pm
Location: Paris, France

Post by CTZn » Thu Nov 22, 2007 3:42 am

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

<!--model>
    blah blah
</model-->
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.
obsolete asset

User avatar
dougal2
Developer
Posts: 2532
Joined: Wed Nov 15, 2006 8:17 am
Location: South London

Post by dougal2 » Thu Nov 22, 2007 4:28 am

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 :?

User avatar
CTZn
Posts: 7240
Joined: Thu Nov 16, 2006 4:34 pm
Location: Paris, France

Post by CTZn » Thu Nov 22, 2007 5:34 am

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.
obsolete asset

User avatar
dougal2
Developer
Posts: 2532
Joined: Wed Nov 15, 2006 8:17 am
Location: South London

Post by dougal2 » Thu Nov 22, 2007 5:34 am

@bkircher:
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?

User avatar
dougal2
Developer
Posts: 2532
Joined: Wed Nov 15, 2006 8:17 am
Location: South London

Post by dougal2 » Thu Nov 22, 2007 5:36 am

CTZn wrote:

Code: Select all

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

bkircher
Posts: 115
Joined: Thu Nov 23, 2006 6:24 am

Post by bkircher » Thu Nov 22, 2007 6:16 am

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.

User avatar
dougal2
Developer
Posts: 2532
Joined: Wed Nov 15, 2006 8:17 am
Location: South London

Post by dougal2 » Thu Nov 22, 2007 10:34 am

latest changes:


131 / doug 0 minutes
mti_ModuleTools.mel:
updated indigoCamera to produce correct camera matching

mtiConvertAllProc.mel:
no longer required.

130 / doug 18 minutes
mti_add_customAttributes_proc.mel:
comments only

mti_ExportModuleCamera.mel:
progressBar

mti_ExportModuleInstances.mel:
correct command for getting instanced object's parent transform
tidied XML output

mti_ExportModuleObjects.mel:
progressBar

mti_Gen.mel:
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)

mti_ModuleTools.mel:
moved convertAllProc here

mti_ScriptNode.mel:
new settings for render priority and view XML

rudimentaryHelp_mti.mel:
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.

bkircher
Posts: 115
Joined: Thu Nov 23, 2006 6:24 am

Post by bkircher » Thu Nov 22, 2007 11:29 am

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.
-

User avatar
dougal2
Developer
Posts: 2532
Joined: Wed Nov 15, 2006 8:17 am
Location: South London

Post by dougal2 » Thu Nov 22, 2007 11:37 am

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>
?

User avatar
dougal2
Developer
Posts: 2532
Joined: Wed Nov 15, 2006 8:17 am
Location: South London

Post by dougal2 » Thu Nov 22, 2007 11:39 am

bkircher you forgot to commit mti_ModuleGUITools.mel

Post Reply
88 posts

Who is online

Users browsing this forum: No registered users and 6 guests