MtI rev 32 29 oct 2007

[CTZn]

Well still no luck... where should the mti_settings file be created ? it's not in mtisimple folder after a second click on mti_Main icon, when Main window runs...

I'll have a look later, will be out right now. Cheers mate !

oh, hold on. it's not fixed yet

tbh, I really gotta do some work.... I'll look later.

Ah, ok. I feel better now you admit it

To bkircher: it appears that you put your scenes in the Indigo app folder, wich is not my workflow as I let Indigo app dir untouched. That explains also the paths you set in your release. So from my point of view the folder CopyTo_Indigo_Dir makes no sense. I suggest that the mandatory folders get created at export time at the specified path (eg only objs dir if no textures are used). And I only got a local copy af Indigo, I work in no office Thoughts ?

[dougal2]

REV 47
another attempt to fix the ScriptNode.

I've added lots of print() output, if the script fails, please report back the script output

I've tried:
1. launch mti_Main; on a new blank scene.
2. launch mti_Main; a second time on the same scene, after mti_settings has been created
3. launch mti_Main; on a saved scene that already had mti_settings
4. calling mti_LoadPathsFromFile; manually
5. calling mti_SavePathsToFile; manually

and I've got no errors so far with this revision. please test.
If it fails, please also report what you were doing

BTW, I'm using Maya 8.5 here and the mtiSettings.txt is saved in
C:\Documents and Settings\doug\My Documents\maya\8.5\scripts\

[CTZn]

print outputs are fine to me, actually I like that.

On a blank scene:

Code: Select all

mti_Main;
Opened file.
Got savStr: C:\work\3d\Indigo\dev\|C:/Progs/3d/indigo/indigo_09_test8/|||
Found 2 parts.
mti_settings exists
Iterating paths:
// Error:  // 
// Error: Line 0.66: Unterminated string. // 
mti_Main; //second call
node exists
0.11

Main opens at second click, mti_Settings shows 8 text captions only. Same error.

Now that I'm looking closer, the error could be because ||| cant be tokenized, check that Edit: no that was stupid.

I'm off a bit, won't work on mti tonight I think, cya ltr.

*missing the end of the sentence l33 in Documentation.txt

[dougal2]

i think you may need to cenvert your path backslashes \ into forward slashes /

give that a go and let me know what happens please.

[bkircher]

Hey guys, fabulous work so far and everything:
But I am getting frustrated with the whole settings thing.
Suddenly, we have a prefs file (.mel) and a prefs file (.txt).
And that's only where the confusion starts.
I like the idea of moving the whole elements out of the standard indigo-installation dir, but this is getting to complicated for my taste.

And pls, I tried to put an example file as comment into the mtiSettings.mel,
though that didn't work out. Maybe someone can fix this, so we all know the correct form.

If someone has made specific tools, let's put them into the mti-toolbar that's currently empty anyhow. (I'll put in a tool to make simple cubic uv mappings and to select the camera soon).

Finally, I think for rotation matrix, for this to work we will have to get the absolute translation of each object, move it in the opposite direction while exporting to have it in the real origin, and put the real values into the indigo instance of the object. Than, rotation should happen correctly. Ctzn, is the rotation in the actual mti_Gen?

Something else: Lets move the geometry generating part out of the main script into a similar module as the camera/shaders.

[dougal2]

i don't follow you bkircher, there's no mtiSettings.mel on my machine

The problem as I saw it was that fair enough you want to keep a scene's settings in the mti_settings script node once you've set it up, but to keep having to input your defaults, like the indigo path, on every new scene using values that are hard coded into the mti_ScriptNode.mel file is not my idea of a good system.

If you've got something else in development that you've not shown us yet then do please revela your plans.
As it stands, my code to save the paths to a .txt file is only 2 simple drop-in procs that could be substituted easily for a different mechanism.

edit: i see you updated mti_ScriptNode.mel - so you agree with this approach? i find your post confusing.
Also, on the subject of toolbar - can you add a call to mti_SavePathsToFile(); please?

[bkircher]

Hi Dougal, I've added a call to mti_SavePathToFile() in the mti_Main.mel in the menu "tools".

Upon first call of mti, I get following answer:
// Error: line 0: No object matches name: mti_settings.mti_ // guess that's not a problem, second time seems to work though.

Your correct, it's called "mti_ScriptNode.mel", and I didn't check.
Anyway, for me, if I want to edit the prefs, I edit the mti_ScriptNode.mel.

And obviously, I appreciate your effort to simplify the whole process and give something of an install-mechanism, but the file naming convention has to be visible at a glance in my opinion:

Let's just add a system call to open the renamed mti_ScriptNode.mel file (let's call it "mti_preferencesNode.mel"), and comment the relevant lines.

Maya File handling makes myself slightly nervous (which is why I avoid other Dirs and why I wrote this post the way I did), so I'll rely on you to set mti up in such a way that it works with arbitrary directory locations.

cheers

[dougal2]

i understand where you're coming from, but I'm trying to look from a user's point of view.
A user might (would) expect to be able to edit the renderer's location etc from the attributes we've provided in Maya, not to go and start editing our carefully crafted .mel files.
Also the user may expect to only have to input his indigo location once. It's fine if you set up custom paths for a particular scene - that gets remembered in the script node, but for new scenes the user would probably expect it to work without further modification.

I know that editing the .mel is an option, but also for us, sharing revisions frequently, it's a big pain in the arse.

I'm thinking about why that error occurs. perhaps because your mtiSettings.txt is empty? not sure why that happens yet.

[CTZn]

i think you may need to cenvert your path backslashes \ into forward slashes /

I'm not sure because before that bug mti was doing well with a path using both / AND \.

I like the idea of moving the whole elements out of the standard indigo-installation dir, but this is getting to complicated for my taste.
...
Maya File handling makes myself slightly nervous [...], so I'll rely on you to set mti up in such a way that it works with arbitrary directory locations.

I trust you on how Maya handles files creation. My own experience is to have a project directory in a separate place than the executable, xml beside ma, and manually added "objs" folder there. If I have to export textures, it's ok to create an "mti_textures" folder as well ! The scriptE should output an explicit error saying that $saveTexturePath folder doesn't exist. Creation of the folder by the user would fix the issue.

About rotation matrices I implemented a version wich was at least working in zup world around z axis (fine for trees), others axes where kinda inverted (again), couldnt test further (was supposedly designed to work automatically the same for Yup), because I updated the folder and that jettisonned it all I shouldnt edit in ths svn folder directly, that's bad

I'll have a look into scriptWhateverNode.mel to understand what it does, but it sounds logical to have in one hand an AETemplate file, and in the other hand a file storing values as an array. That's how I can understand it at least. Then no need to edit whatever file: Settings are loaded with mti_Main and saved at export time. Loaded and saved

So far I've been reluctant to coding, I'll push myself a bit...

[CTZn]

That's what I came with:

- World up axis should be detected automagically. Maybe I forget to update certain code chunks accordingly. Removed from GUI.

- Added redundancy in scriptNode, but at least read/write from file works in all case here.

Definitely I find the "local" feature too specific, redundant and confusing. And undocumented I use no help line no more...

Why on earth is everything declared as global when it works better as local ? That said, according to the doc your implementation of global variables in scriptNode.mel was correct, but for some reason it didn't work as expected. For me at least, or did it ? So $savePathOrder[] is declared twice but that works.

Thoughts plz, have a good day !

[dougal2]

variables declared outside of procs need to be global if you want to use them inside procs.

and then again inside the proc you need to declare the variable as global in order to have access to the value.

[CTZn]

I know that, but again the behaviour is different when I set $savePathOrder[] as local variable: the scriptNode finally works right in all respects. I have no explanation why the global value was returning an empty array but it did. My question is: was it working ok for you before that modification; is it working now ? Again it is for me but it wasn't at REV50.

[dougal2]

well, it was working for me that way I wrote it, here at work using v8.5.
it didn't really work properly at home with v2008.

If it works with your modification, fair enough - I can live with that. I haven't got the time to test right now. maybe later this evening or sometime tomorrow I can.

btw, which version do you have?

[CTZn]

I released REV51, that was hidden in the title of my post. I'm on Maya 8.5 as well, and still I have no explanation for the phenomenon...

BTW loading and writing to txt file are working in all respects, got something broken at export time tho. Sorry for that *fixing now*.

Thanks for answering Doug,

'later !

Edit: Arf no it's not broken, I forget to add the final slash to my path ! This MUST be documented, or fixed. Everything fine here so far

Compare:

Code: Select all

Creating c:/work/3d/indigo/dev/export_test.xml
// Error: file: C:/work/dev/svn_MtI/trunk/MayaToIndigoSimple/mti_Gen.mel line 200: Could not save file. // 

and

Code: Select all

Creating c:/work/3d/indigo/dev//export_test.xml
Adding to c:/work/3d/indigo/dev//export_test.xml
OBACHT:initialShadingGroup.surfaceShader
Shader: lambert1
The File has been saved to c:/work/3d/indigo/dev//export_test.xml
Done... See Script Editor for more Info

Isn't that funny ?

[CTZn]

Repository server seems to be down...

Anyway I try to upgrade REV51 with rotations.