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

Post by dougal2 » Tue Nov 27, 2007 5:15 am

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.

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

Post by CTZn » Tue Nov 27, 2007 5:31 am

Ok I can have a look, just in case, where's that code chunk of yours ?
obsolete asset

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

Post by dougal2 » Tue Nov 27, 2007 5:34 am

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.

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

Post by CTZn » Tue Nov 27, 2007 5:41 am

Yeah long time no see, many new stuff in there :) I'll tell if I can get a clue (or not hehe).

bkircher I haven't tested that yet but I like the idea with icons, will discover more soon.

Cheers both
obsolete asset

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

Post by dougal2 » Tue Nov 27, 2007 5:54 am

yeah I like the icons too, one thing that always catches me out though is forgetting to set the environ type to sun after adding a sun... should we change it automatically if the user adds a sun? I think it's a fairly safe assumption that if you add a sun you are going to want to render with it ;)

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

Post by CTZn » Tue Nov 27, 2007 6:07 am

Yes at some point I tried to implement something similar, wich was working even while I thought I asked it not to, under certain circumstances at least ;)

Carefull coz one may want to have night/day setup in the same scene, thus having a Sun but not using physical sky.
obsolete asset

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

Post by CTZn » Tue Nov 27, 2007 6:31 am

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

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

Post by bkircher » Tue Nov 27, 2007 8:43 am

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?

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 + "\"";
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.

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

Post by dougal2 » Tue Nov 27, 2007 8:45 am

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

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

Post by dougal2 » Tue Nov 27, 2007 8:52 am

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 + "\"";
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?
no paths set here, it just works. what vesion of windows are you on?
b)
what's our policy with end-slashes - seems we shouldn't set them any more.
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.
c)
date-settings didn't work on a maya 7 I tested with. Do we have to check against maya-versions?
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.
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.
I prefer this approch, and works well apart from in 2 cases:
- 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.

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

Post by bkircher » Tue Nov 27, 2007 10:06 am

what vesion of windows are you on?
Win XP, English, SP2
Double-Clicking on the .cmd works, though.
No harm done if the user puts them on though.
let's take them out, then.
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.
let's take it out or somehow check against the maya-version:
I really like the robustness of mti, that it should work with every (Windows-) Maya-Version, and eventually all the others.
I prefer this approch, and works well [...]
Than that's the way forward. I was basically worried performance-wise.


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.

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

Post by CTZn » Tue Nov 27, 2007 10:25 am

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

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. // 
Using last rev.

- - - -

Exporting objs to separate dirs is a cool idea !
obsolete asset

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

Post by dougal2 » Wed Nov 28, 2007 2:00 am

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.
perhaps the showXMLOnRender mti_settings should be changed to an enum list containing: NONE:INTERNAL:EXTERNAL.
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.
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. // 
Using last rev.
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.

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

Post by dougal2 » Wed Nov 28, 2007 2:49 am

REV 156
changed showXMLOnRender to enum None:Internal:External.
Internal is currently broken though.

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

Post by dougal2 » Wed Nov 28, 2007 5:55 am

REV 157
implemented v1.0.4 camera aperture stuff.

Post Reply
88 posts

Who is online

Users browsing this forum: Semrush [Bot] and 1 guest