Page 1 of 1

Still using MtI 3.2.5.2

Posted: Mon Jun 03, 2013 11:35 am
by ior
The problem with the world pivot is still on the versions prior than 3.2.5.2.

Recalling what does the problem do at render time:

Code: Select all

 XYZ of world scale pivot become the XYZ values of the rotate pivot (translate), multiplied to the values XYZ of scale, plus the XYZ values of the previous world scale pivot.
Anyone with the knowledge to spot what is wrong?

It would be good to use the new things added after that version.

My endless animation works good with 3.2.5.2 thought.

Re: Still using MtI 3.2.5.2

Posted: Wed Jul 03, 2013 8:46 am
by ior
ior wrote:

Code: Select all

 XYZ of world scale pivot become the XYZ values of the rotate pivot (translate), multiplied to the values XYZ of scale, plus the XYZ values of the previous world scale pivot.
Can anyone confirm this behavior? World scale pivot changing after render.

If so, CTZn, can you please write a script that runs, after clicking render, to make the world scale pivot equal to world rotate pivot of every scene object?

This would not really fix the thing but it would make later versions usable.

I simply do not have the knowledge to do that.

Re: Still using MtI 3.2.5.2

Posted: Wed Jul 03, 2013 9:36 am
by CTZn
fyi the procedure wich does the transform thing is mti_EM_processObj in the file mti_EM.mel (Export Modules).

You can replace it with the one of the version you want after you made a back-up.

The whole topic of catching actual objects transforms, specially constrained-locked-animated objects is also slightly above my hairs. They are not always where xform tells, I feel rather helpless.

Probably are there many more tests to do than MtI does or even did.

Re: Still using MtI 3.2.5.2

Posted: Wed Jul 03, 2013 10:04 am
by ior
Thanks, Ill try that, and post the result.

Re: Still using MtI 3.2.5.2

Posted: Wed Jul 03, 2013 11:07 am
by CTZn
This procedure does not exist in earlier versions of MtI. In wich case, the procedure to replace is mti_EM_objects; it's a longer one.
I feel rather helpless
You can tell because that's where you'll find the worst piece of MEL code from MtI probably: undo; undo; undo; !

Re: Still using MtI 3.2.5.2

Posted: Wed Jul 03, 2013 11:14 am
by ior
in the line 386 if I replace:

Code: Select all

	float $sclPiv[] = `xform -q -ws -sp $obj`;
with:

Code: Select all

	float $sclPiv[] = `xform -q -os -sp $obj`;
the problem disappears! :) [EDIT]and everything seems fine

I do not know what is -os or -ws. Maybe this change makes something not to work?

Re: Still using MtI 3.2.5.2

Posted: Wed Jul 03, 2013 12:00 pm
by ior
Tested in the a more complex scene and everything is fine.

Still thinking in what might be missing.

Re: Still using MtI 3.2.5.2

Posted: Wed Jul 03, 2013 12:14 pm
by CTZn
Great you fixed MtI.

I did that merging a couple days ago myself but was bothered with different things to test. Do you confirm that it is better to revert from the 3.2.5.2 obj proc ?

I may update MtI this quarter since I've been tinkering with the ISL framework a bit.

Re: Still using MtI 3.2.5.2

Posted: Wed Jul 03, 2013 12:45 pm
by ior
CTZn wrote:Do you confirm that it is better to revert from the 3.2.5.2 obj proc ?
I did not do anything other than changing a letter from MtI 3.6 in mti_EM.mel file accordingly to "float $rotPiv". I do not know what -ws was doing there nor what is -os, I only know that -ws appears several times and might be doing something there, but it seems it is ok tho change the letter.

I do not know how to program I only know some basics.

Tel me what is -ws and -os.

I do not know anything about object procedure.

[EDIT]I think that if -ws or -os is not doing something specific in that line of code and if there are no new things in the new obj procedure then reverting to the old procedure might be better, but if this fix the problem with no downsides then I do not see problem in maintaining this proc.

Re: Still using MtI 3.2.5.2

Posted: Wed Jul 03, 2013 10:02 pm
by CTZn
Ah I missed your correction on the line 386.

Well the scale pivot was queried (stored) in world space and you changed the query to object space.

That was one bug indeed because the ws data was restored later as object space data, wich it is not.

My mind got totally obfuscated over the years on this topic of transforms.