MtI rev 32 29 oct 2007

[CTZn]

No need for a GUI, burn it when the user call mtiGen ! Hey dougal, you let a funny header to the scriptNode wich generated a bunch of errors, I commented a few lines out

Now I have a question on SVN:

Developer 1 and Developer 2 get the same revision at the same time. Dev1 works on code chunk A and commit. Dev2 works on code chunk B and commit. What happened to new code chunk A ? What will Dev 1 find when he updates ?

Thx if you can answer this one coz it's a bit stressfull. I think you already told that there was no merging feature in Tortoise ?

Rotation matrices partially working, at least for trees with Zup. Having a break !

[dougal2]

Now I have a question on SVN:

Developer 1 and Developer 2 get the same revision at the same time. Dev1 works on code chunk A and commit. Dev2 works on code chunk B and commit. What happened to new code chunk A ? What will Dev 1 find when he updates ?

I don't think SVN handles this at all. it's up to the dev's i think.
i'm going to have a google in a minute to see if there's any further info about this scenario.

HOWEVER, SVN will keep the revision that dev 1 committed, and it's possible to do a compare between that revision and the next one that dev 2 committed.
for example

I think a third commit is then necessary to manually merge the two changes.
of course, there's then further issues if the changes conflict....
ok; *goes off to do some research*

[dougal2]

ps..
mti_ScriptNode.mel line 90

Code: Select all

mti_SavePathsToFile();

is in the wrong place. this is probably the cause of the errors. you can safely remove it.

[dougal2]

ok testing over.
read the end of this chapter, about committing:
http://svnbook.red-bean.com/en/1.4/svn. ... le.resolve

if 2 devs check out the SAME revision, and work on it simultaneously. That's OK.
The first dev to commit will be allowed to do so.
If the second dev has changed any of the same files as the first dev and tried to commit - THE COMMIT WILL FAIL.

Dev 2 will have to do an update, at which point your SVN client will merge the changes that dev 1 made. dev 2 can now commit OK, and the changes that both devs made are kept.

(important note that made this make sense to me: it's your svn CLIENT that does the merging, not the SERVER).

If both devs changed the same code, and SVN cannot work out a merge, dev 2's files will be put into CONFLICT status, and he will have to manually do some merging. then he sends a RESOLVED command before committing further changes on that file are allowed.

It seems fairly safe to me. I've tested this scenario with MtI just now and it works. we're now at revision 42.

[CTZn]

ps..
mti_ScriptNode.mel line 90

Code: Select all

mti_SavePathsToFile();

is in the wrong place. this is probably the cause of the errors. you can safely remove it.

Nope, there was precisely a conflict with a version of the scriptNode I modified and the conflict markers screwed the script. I thought you writted that and let junk scripts beside, but that was conflict management only (plus temp files)... thanks for the lecture

[CTZn]

Hi Dougal,

Rev 43 is not doing well: mti_settings is showing 8 entries only instead of the bunch we are used with... mti_objsSaveDir is the last one, we can't activate sun etc.

On first call, mti_Main gives an error:

mti_Main;
// Error: //
// Error: Line 0.66: Unterminated string. //

On second call it launches ok but mti_settings is as described.

PS direct render has never worked for me, still get that bitchy inifile error.

[dougal2]

yeah i know. rev 44 should fix that.

also rev 45 fixes a linear tonemapping bug.

did you manage to resolve differences in ScriptNode?

I'm having a look at better SSS support right now.

[CTZn]

did you manage to resolve differences in ScriptNode?

Nope I just tried to run mti... I'd prefer to focus on rot mats for now, waiting for r44. Take it easy

[dougal2]

ok, probably my last changes for today will be in mti_ExportModuleShaders.mel

i'll commit later when I can be sure it's working.

(btw, r45 is already in the SVN)

[dougal2]

I'm changing the way that SSS materials are exported via blinn shaders:

absorption_coefficient_spectrum is now controlled by Color (RGB)

if ambient R+G+B == 0, then use uniform scattering controlled by lightAbsorbance.

otherwise use ambientColor RGB as scattering_coefficient_spectrum

specular transparent flag is controlled by Transparency R+G+B == 0 or not.

I think this'll give a better preview in Maya as to the colours of the final material (before, some SSS objects were mostly transparent and REALLY hard to see).

I realise that existing scenes will need to be updated to use this in the new exporter, which is why i'm asking here first

any objections, or better ideas?

[CTZn]

Better idea: fix that scriptNode bug I want a running exporter for my tests, and don't expect from me to correct your errors. Bugfixing should come before changes/upgrading.

Well IMO it would be best to link maya's shaders attribute to extra attributes with proper Indigo names: when you change scattering_coefficient_spectrum in blinn's extra attributes then ambient color is updated. See what I mean ? Then maya attr will only be place holders, but if the feedback is better then fine

fix fix fix

[dougal2]

Better idea: fix that scriptNode bug I want a running exporter for my tests, and don't expect from me to correct your errors. Bugfixing should come before changes/upgrading.

it is fixed! I fixed it in r44!

Well IMO it would be best to link maya's shaders attribute to extra attributes with proper Indigo names: when you change scattering_coefficient_spectrum in blinn's extra attributes then ambient color is updated. See what I mean ? Then maya attr will only be place holders, but if the feedback is better then fine

Yeah, that's a good idea, but still we need to work which Maya attributes/colours we're going to update. Also, getting it working in one direction first is a start and at least makes the feature usable. We can always go back and add in our custom attributes at a later date.

[CTZn]

Not quite, still got that error with r45... check it out ? I've deleted all files and folders from MayaToIndigoSimple but the svn folder, updated and get same error...

Yeah, that's a good idea, but still we need to work which Maya attributes/colours we're going to update. Also, getting it working in one direction first is a start and at least makes the feature usable. We can always go back and add in our custom attributes at a later date.

I agree, that's fine !

[dougal2]

OK, I eventually experienced the bug. not sure what happened there, seems like there was an extra return; amongst other things in there.

REV 46

Fixed ScriptNode bug... i think. please test!
be sure to remove your old mtiSettings.txt before launching - there's code to test which creates this file for the first time.

edit: Please note that the indigoDir should use forward slashes, and also have one on the end, eg:
R:/indigo/indigo_v1.0.1/
otherwise obj export fails.

CHANGED BLINN SHADER.
absorption_spectrum is now controlled by COLOR
if ambient RGB == 0, then use uniform scattering controlled by lightAbsorbance,
else use ambientColor RGB as scattering_spectrum.

[dougal2]

oh, hold on. it's not fixed yet

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