MtI 0.9 (19 nov 2007 release)
MtI 0.9 (19 nov 2007 release)
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.
- 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 296 times
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....
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....
Oh that is possible ? Nice one then !also added in renderSavDir so that renders are output in a subfolder of where the scene file is
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
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):
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.
Code: Select all
<!--model>
blah blah
</model-->
That's a limitation I forget to document, thanks Doug.
obsolete asset
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
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
That's right, I didn't mention that because that was too complicated I thought, nice one.
Returns a list, item [0] should be the transform. Is that what you meant ? Also I discovered pickwalk command recently.
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
yup that's exactly itCTZn wrote:Code: Select all
listRelatives -parent $shape
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.
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.
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.
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, 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>
?
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>
?
Who is online
Users browsing this forum: No registered users and 67 guests