MtI 0.9 (29 nov 2007 release)
REV 173
added deg_to_rad convertion in mti_ExportModuleCamera.mel - apertureshape::generated::start_angle
fixed nk_data XML formatting
added switch..case in mti_Gen.mel for detecting windows/linux so that we can write the correct commands.
I think we should give a copy of this revision to phr0stbyte to test.
edit: If there's anyone here on linux or mac, can you test the attached version and report back with what happens when you try to use renderDirect. We need your input to get this right (as I for one only have Maya on windows).
added deg_to_rad convertion in mti_ExportModuleCamera.mel - apertureshape::generated::start_angle
fixed nk_data XML formatting
added switch..case in mti_Gen.mel for detecting windows/linux so that we can write the correct commands.
I think we should give a copy of this revision to phr0stbyte to test.
edit: If there's anyone here on linux or mac, can you test the attached version and report back with what happens when you try to use renderDirect. We need your input to get this right (as I for one only have Maya on windows).
- Attachments
-
- MtI-svn-rev173.zip
- SVN revision 173
- (44.25 KiB) Downloaded 189 times
Actually, I've found that the new Export Visible code doesn't work correctly... parented objects don't work.
What we actually need is a full scene-traversal proc that starts with displayLayers (also had some problems where defaultLayer wasn't being recognised), and starts to pick off visible children and store meshes, transforms, and shaders into different arrays that we then use in other Export modules.
I also notice that some parts of mti_Gen are using their own `ls ...` commands, where really we should traverse the scene just once at the start of the script, picking off the nodes that we are interested in and then make the rest of the exporter refer back to these master lists.
One big problem with doing all this is.... it's hideously complicated (i mean, from a coding point of view - it'll be wonderful to actually use when it works )
[side note, actually the beauty of using `ls -s` is that all nodes are returned, regardless of parenting. In fact if we can find out what displayLayer an object is on from it's name, rather than the other way around, this might be a better way of doing it]
What we actually need is a full scene-traversal proc that starts with displayLayers (also had some problems where defaultLayer wasn't being recognised), and starts to pick off visible children and store meshes, transforms, and shaders into different arrays that we then use in other Export modules.
I also notice that some parts of mti_Gen are using their own `ls ...` commands, where really we should traverse the scene just once at the start of the script, picking off the nodes that we are interested in and then make the rest of the exporter refer back to these master lists.
One big problem with doing all this is.... it's hideously complicated (i mean, from a coding point of view - it'll be wonderful to actually use when it works )
[side note, actually the beauty of using `ls -s` is that all nodes are returned, regardless of parenting. In fact if we can find out what displayLayer an object is on from it's name, rather than the other way around, this might be a better way of doing it]
REV 176
Fixed saveVisibleOnly with display Layer and parented object support
It actually wasn't that complicated when starting from `ls -s`.
I think we should now look at other parts of the script, and make sure they are all using the proper $shapes, $meshes and $transform lists, rather than regenerating them all the time.
Then, tests like
in modules (eg, ExportModuleObjects) should be redundant and can be removed.
Fixed saveVisibleOnly with display Layer and parented object support
It actually wasn't that complicated when starting from `ls -s`.
I think we should now look at other parts of the script, and make sure they are all using the proper $shapes, $meshes and $transform lists, rather than regenerating them all the time.
Then, tests like
Code: Select all
if(`objectType $one`=="mesh")
haha, my avatar is one of the very first things I rendered with indigo - my first fibre optic experiment. It was modelled in blender though.
as for the script, it's fairly easy to follow..
we start with a few variations of `ls -s` and then if savVisible is true, that selection is filtered according to a couple of helper functions' outputs. (ie, if the object itself is visible, and if it's display layer is visible).
as for the script, it's fairly easy to follow..
we start with a few variations of `ls -s` and then if savVisible is true, that selection is filtered according to a couple of helper functions' outputs. (ie, if the object itself is visible, and if it's display layer is visible).
So far, I could export an heavy scene (2171 simple true objs, no instances) with all the objects grouped and such, really that's mind-blowing how versatile turned MtI these last times ! That said it took 10mn to export, writing all these objects to disk took 7mn+ ...
bkircher was the little brise reviving the Maya forum and MtI, then Doug, you've been a meccano storm upon it.
Thanks all !
Me doing some modest corners rounding, at the periphery Seems that <aperture_diffraction> should not be set in <render_settings>, added date stamp at the end of export, commented feedback line for skipped objs (2000+ then) etc but not submitted yet. In fact I'm not fancy submitting, I feel I don't have enough control/understanding on the scripts suite for that. That may take some time.
Cheers !
bkircher was the little brise reviving the Maya forum and MtI, then Doug, you've been a meccano storm upon it.
Thanks all !
Me doing some modest corners rounding, at the periphery Seems that <aperture_diffraction> should not be set in <render_settings>, added date stamp at the end of export, commented feedback line for skipped objs (2000+ then) etc but not submitted yet. In fact I'm not fancy submitting, I feel I don't have enough control/understanding on the scripts suite for that. That may take some time.
Cheers !
obsolete asset
CTZn:
you should commit the datestamp and removed feedback line, I've no problem with that.
As for <aperture_diffraction> in <render_settings>, well it's the only way we can reliably control it. I for one don't ever edit my inifile, but others might and leaving the setting out might have unpredictable results for some people.
I think it should stay in render_settings.
I've been a bit absent the last couple of days, and will likely remain so - there's a few important web projects happening at work which is taking all my time. I will probably head back this way towards the end of next week.
you should commit the datestamp and removed feedback line, I've no problem with that.
As for <aperture_diffraction> in <render_settings>, well it's the only way we can reliably control it. I for one don't ever edit my inifile, but others might and leaving the setting out might have unpredictable results for some people.
I think it should stay in render_settings.
I've been a bit absent the last couple of days, and will likely remain so - there's a few important web projects happening at work which is taking all my time. I will probably head back this way towards the end of next week.
okay, I may commit within 48h then, I will see what addition could be worse it meanwhile.
Okay as well for aperture diffraction, specifically if that works that way. My point was that I had issues yesterday (Indigo 1.0.4 running in 1.0.2 folder, throwing an error because "'aperture_diffraction' isn't in the map" ie not in 1.0.2 inifile), and while helping me to debug psor insited on that I had to remove that line from render_settings, that was not it's place to be. But if that works it will stay here
Good luck for your job !
Okay as well for aperture diffraction, specifically if that works that way. My point was that I had issues yesterday (Indigo 1.0.4 running in 1.0.2 folder, throwing an error because "'aperture_diffraction' isn't in the map" ie not in 1.0.2 inifile), and while helping me to debug psor insited on that I had to remove that line from render_settings, that was not it's place to be. But if that works it will stay here
Good luck for your job !
obsolete asset
- Phr0stByte
- Posts: 395
- Joined: Wed Nov 22, 2006 5:07 am
- Location: Centreville, VA
- Contact:
OK... I have encountered a little strangeness here..... (got UV-Mapping figured out, by the way. Thanx, guys).
Check out the iPod screenshot from within Maya and then look what Indigo produced. I am refering to the iPod screen here - in the Indigo render, it is way off center. Whats up with that?
Using the latest MtI 0.9 with the SVN update. I can provide the Maya scene and/or Indigo XML if needed.
Check out the iPod screenshot from within Maya and then look what Indigo produced. I am refering to the iPod screen here - in the Indigo render, it is way off center. Whats up with that?
Using the latest MtI 0.9 with the SVN update. I can provide the Maya scene and/or Indigo XML if needed.
- Attachments
-
- Screenshot.png (65.27 KiB) Viewed 4097 times
-
- im1197067113.png (381.87 KiB) Viewed 4097 times
ok.. finally a bug report !!
I have a few questions, if I may.
1. Which exact revision of MtI were you using?
2. Was the export process aborted at any time?
- The newest code uses a new method for exporting objects whereby they each get temporarily moved to the origin (and then back to their original locations). If the process is interrupted, objects can be left there.
[As an aside, I would like to hear suggestions as to how we might be able to avoid this problem - this occurs particularly if you choose "cancel" to the "File exists, Overwrite?" prompt.]
3. Are any of the ojbects parented/grouped/constrained to any other?
4. Are any of the translate attributes locked on any object?
(the code mentioned in Q#2 above won't be able to move the objects about if translate is locked, the exported object will then render with an offset in the opposite direction to it's translation)
I have a few questions, if I may.
1. Which exact revision of MtI were you using?
2. Was the export process aborted at any time?
- The newest code uses a new method for exporting objects whereby they each get temporarily moved to the origin (and then back to their original locations). If the process is interrupted, objects can be left there.
[As an aside, I would like to hear suggestions as to how we might be able to avoid this problem - this occurs particularly if you choose "cancel" to the "File exists, Overwrite?" prompt.]
3. Are any of the ojbects parented/grouped/constrained to any other?
4. Are any of the translate attributes locked on any object?
(the code mentioned in Q#2 above won't be able to move the objects about if translate is locked, the exported object will then render with an offset in the opposite direction to it's translation)
- Phr0stByte
- Posts: 395
- Joined: Wed Nov 22, 2006 5:07 am
- Location: Centreville, VA
- Contact:
As I really have no idea what you are saying (too technical - I just like to model stuff and make pretty pictures...), I am including the maya scene and xml output.
Using Maya 8.5 (linux x64)
Indigo 1.0.4 (via wine 0.9.47)
MayaToIndigo09_20071129
MtI-svn-rev173
As a side note, I seem to have heard issues with other Indigo scripts exporting scenes with no mats - maybe this is why? I will add mats later to check it out. I dont think the script was interupted, as I got a finish status in the status area at the bottom of Maya. Also no objects are tied or grouped together.
Using Maya 8.5 (linux x64)
Indigo 1.0.4 (via wine 0.9.47)
MayaToIndigo09_20071129
MtI-svn-rev173
As a side note, I seem to have heard issues with other Indigo scripts exporting scenes with no mats - maybe this is why? I will add mats later to check it out. I dont think the script was interupted, as I got a finish status in the status area at the bottom of Maya. Also no objects are tied or grouped together.
- Attachments
-
- Maya_Scene_n_XML.zip
- (344.82 KiB) Downloaded 215 times
Last edited by Phr0stByte on Sat Dec 08, 2007 11:29 am, edited 1 time in total.
ok, the scene file is useful. having a look now.
edit: yeah it renders the same here. very strange. i can't explain it yet.
edit edit:
Freezing xforms has no effect (they are frozen already)
Deleting all history has no effect (there is no history)
There's nothing wrong with the exported .obj files either - if you re-import them 1 by 1, they come back in exactly the right place.
Also, grabbing the parts from the scene you provided, and translating and rotating them has no effect.
I think we could file a bug report against this one
edit: yeah it renders the same here. very strange. i can't explain it yet.
edit edit:
Freezing xforms has no effect (they are frozen already)
Deleting all history has no effect (there is no history)
There's nothing wrong with the exported .obj files either - if you re-import them 1 by 1, they come back in exactly the right place.
Also, grabbing the parts from the scene you provided, and translating and rotating them has no effect.
I think we could file a bug report against this one
- Attachments
-
- ipod2.zip
- Complete re-exported scene with .obj files
- (251.03 KiB) Downloaded 215 times
Who is online
Users browsing this forum: No registered users and 68 guests