MtI 0.9 (19 nov 2007 release)
to be honest, I don't know much about particles in Maya, but I have had an experiement with the different instancing modes, and managed to get the rotations I want with Maya - but the translation to Indigo's rotation matrices is going quite wrong. That said, I've got the positions correct, and I think that we have all the necessary proc's available to convert the rotations, I just don't think I'm using the right values. I don't really know exactly where the problem is.
it's a new module mti_ExportModuleParticleInstances.mel, which I adapted from a script bkircher found on highend3d.
There are several different modes of instancing available, I've added code to two of them, and neither work. If you try to export using the other methods, a load of debug info will be printed to the console.
some helper procs, like vector2rot are in there, other helper procs like mti_rotationTiplet2Matrix are in mti_ExportModuleInstances.mel - this is your code that I put into procs so that I could use it elsewhere.
There are several different modes of instancing available, I've added code to two of them, and neither work. If you try to export using the other methods, a load of debug info will be printed to the console.
some helper procs, like vector2rot are in there, other helper procs like mti_rotationTiplet2Matrix are in mti_ExportModuleInstances.mel - this is your code that I put into procs so that I could use it elsewhere.
First reaction on particules: ouch I remember myself struggling with that already. I'm not sure yet but I don't think we can retrive rotation data if the attribute was not defined by the user, or by the exporter.
You make it or you lack it !
That said, I'm gonna update n check the script (gaming first oc)
'soon
You make it or you lack it !
That said, I'm gonna update n check the script (gaming first oc)
'soon
obsolete asset
REV 153
Environment Sun is now set when sun is created
preferences are only set if no mti_settings-node exists
Great changes so far.
Some issues I've found so far:
a)
I still find that indigo does not render automatically via the cmd-file for me.
Even if I comment out the output path indigo is not starting via maya. With the -o path set as mti_Gen defines, the cmd is not working for me.
Maybe wrong slashes?
Does anybody of you work with the path-variable set to indigo-dir or something, as you don't seem to run into the same problems I do?
b)
what's our policy with end-slashes - seems we shouldn't set them any more.
c)
date-settings didn't work on a maya 7 I tested with. Do we have to check against maya-versions?
d)
Do you really prefer to scale every object back to it's origin (seems to work very well - looks nice) - or should we just do this in indigo by using the same values as with model * (-1)? If you have not experienced any issues thus far, I do like the clean look.
Environment Sun is now set when sun is created
preferences are only set if no mti_settings-node exists
Great changes so far.
Some issues I've found so far:
a)
I still find that indigo does not render automatically via the cmd-file for me.
Even if I comment out the output path indigo is not starting via maya. With the -o path set as mti_Gen defines, the cmd is not working for me.
Maybe wrong slashes?
Code: Select all
// $theCMD += "start " + $mWait + " /" + $mRenderPriority + " indigo" + $mConsole + ".exe"+ $threads + $mNetworking + " -o " + $mRenderFile + " \"" + $xmlFile + "\"";
$theCMD += "start " + $mWait + " /" + $mRenderPriority + " indigo" + $mConsole + ".exe"+ $threads + $mNetworking + " \"" + $xmlFile + "\"";
b)
what's our policy with end-slashes - seems we shouldn't set them any more.
c)
date-settings didn't work on a maya 7 I tested with. Do we have to check against maya-versions?
d)
Do you really prefer to scale every object back to it's origin (seems to work very well - looks nice) - or should we just do this in indigo by using the same values as with model * (-1)? If you have not experienced any issues thus far, I do like the clean look.
after some manual testing:
In the aimDirDup proc, the objAimDir is the correct velocity vector.
However, vector2rot is not correctly turning this into rotation values in degrees.
Further to this, we are then converting the rotation degrees back into a matrix.
Do either of you know what each of the rotation matrix values actually represents? Can we not drop the velocity vector straight in there somewhere?
it seems absurd to convert a vector value into degrees, and then back into a vector (matrix).
In the aimDirDup proc, the objAimDir is the correct velocity vector.
However, vector2rot is not correctly turning this into rotation values in degrees.
Further to this, we are then converting the rotation degrees back into a matrix.
Do either of you know what each of the rotation matrix values actually represents? Can we not drop the velocity vector straight in there somewhere?
it seems absurd to convert a vector value into degrees, and then back into a vector (matrix).
no paths set here, it just works. what vesion of windows are you on?a)
I still find that indigo does not render automatically via the cmd-file for me.
Even if I comment out the output path indigo is not starting via maya. With the -o path set as mti_Gen defines, the cmd is not working for me.
Maybe wrong slashes?
Does anybody of you work with the path-variable set to indigo-dir or something, as you don't seem to run into the same problems I do?Code: Select all
// $theCMD += "start " + $mWait + " /" + $mRenderPriority + " indigo" + $mConsole + ".exe"+ $threads + $mNetworking + " -o " + $mRenderFile + " \"" + $xmlFile + "\""; $theCMD += "start " + $mWait + " /" + $mRenderPriority + " indigo" + $mConsole + ".exe"+ $threads + $mNetworking + " \"" + $xmlFile + "\"";
I've noticed this, I think we are doubling up in the script, so it's safe to leave them off in mti_settings. No harm done if the user puts them on though.b)
what's our policy with end-slashes - seems we shouldn't set them any more.
is this the date command I put on the console output? we can drop it if it's not compaitble. it's only a minor aesthetic point.c)
date-settings didn't work on a maya 7 I tested with. Do we have to check against maya-versions?
I prefer this approch, and works well apart from in 2 cases:d)
Do you really prefer to scale every object back to it's origin (seems to work very well - looks nice) - or should we just do this in indigo by using the same values as with model * (-1)? If you have not experienced any issues thus far, I do like the clean look.
- if the script crashes, but i've only had this when tinkering with code. this hopefully won't be an issue in any releases we make
- if the user clicks "cancel" to overwrite .obj file. the script then stops.
In these cases the object that the script was working on is left at the origin.
I think we can work around this by putting part of the ExportModuleObjects into a proc, and calling it with catch(), so that if it fails (or the user cancels a file overwrite confirmation), we can reset the current object's location.
Win XP, English, SP2what vesion of windows are you on?
Double-Clicking on the .cmd works, though.
let's take them out, then.No harm done if the user puts them on though.
let's take it out or somehow check against the maya-version:is this the date command I put on the console output? we can drop it if it's not compaitble. it's only a minor aesthetic point.
I really like the robustness of mti, that it should work with every (Windows-) Maya-Version, and eventually all the others.
Than that's the way forward. I was basically worried performance-wise.I prefer this approch, and works well [...]
p.s.:
- Let's check all the presets if they are still meaningfull and comment every one of them- That will help new users a lot, I'd guess.
- I've thought about your idea to implement an mti-converter:
Still like the Idea for Meshlight Emitters and multi-UV-surfaces, especially since all the code is there in the early versions of mti, but this would make everything much more complex -> the shader names might have to be determined differently, etc.
I do, direct render will launch the version of Indigo I set in system variable (path). Same applies to MAYA_SCRIPT_PATH and XBMLANGPATH, working good here.Does anybody of you work with the path-variable set to indigo-dir or something, as you don't seem to run into the same problems I do?
I couldn't break through the particle code at the first try, looks quite complicated. The result shows that you are almost done Doug, just need a lil correction I'd say Upon observation they seem to be oriented toward the wrong axis, nicely.
- - - -
How do I restore old Output Window ? I prefer that since it does not create a new process, even if in some cases the actual behaviour would be usefull.
- - - -
When I recall mti_Main because it was closed (scriptNode preserved in scene), an error is thrown:
Code: Select all
Adding mti v0.97 features to mti_settings
// Warning: file: C:/work/dev/svn_MtI/trunk/MayaToIndigo/mti_ScriptNode.mel line 108: Name 'mti_saveAnimation' of new attribute clashes with an existing attribute of node 'mti_settings'. //
// Error: file: C:/work/dev/svn_MtI/trunk/MayaToIndigo/mti_ScriptNode.mel line 108: Found no valid items to add the attribute to. //
- - - -
Exporting objs to separate dirs is a cool idea !
obsolete asset
perhaps the showXMLOnRender mti_settings should be changed to an enum list containing: NONE:INTERNAL:EXTERNAL.CTZn wrote:
How do I restore old Output Window ? I prefer that since it does not create a new process, even if in some cases the actual behaviour would be usefull.
Then we can please everyone by turning display off, using the old window or using notepad.
I personally prefer the XML code in a separate process, because if the scene file is large it helps Maya's memory usage (which is already massive). Also, notepad is resizeable and the internal window isn't.
erm... no idea. I think deleting your mti_settings will cure it. To preserve your settings, save your existing settings to a preset before deleting it, re-run mti_Main and restore your preset.When I recall mti_Main because it was closed (scriptNode preserved in scene), an error is thrown:
Using last rev.Code: Select all
Adding mti v0.97 features to mti_settings // Warning: file: C:/work/dev/svn_MtI/trunk/MayaToIndigo/mti_ScriptNode.mel line 108: Name 'mti_saveAnimation' of new attribute clashes with an existing attribute of node 'mti_settings'. // // Error: file: C:/work/dev/svn_MtI/trunk/MayaToIndigo/mti_ScriptNode.mel line 108: Found no valid items to add the attribute to. //
Who is online
Users browsing this forum: No registered users and 19 guests