MtI rev 32 29 oct 2007

[CTZn]

could you please add you changes to the log message when you commit though? cheers.

Will do for sure, missed it !

As for limits: kick them off !!! We don't want to prevent users to test Indigo. How would you make *very hot* metal ? I'ts a light emitter already at 1200°K I bet.

[dougal2]

supposedly about 700K
http://en.wikipedia.org/wiki/Black_body

[CTZn]

fine then. Put it a 500

[bkircher]

500 is fine with me!
We should probably also add a statement that hints at low values of power drawn / efficacy if the values are within the range of 0..1. (Do we need a feedback line?)

Concerning the Rotation Matrix:
I've made a small proof of concept, even though the result has a different orientation than I wanted it to be...

Code: Select all

$x = `getAttr locator1.rx`;
$y = `getAttr locator1.ry`;
$z = `getAttr locator1.rz`;

float $xCos = cos (deg_to_rad($x));
float $xCo_ = -1 * `cos (deg_to_rad($x))`;
float $xSin = `sin (deg_to_rad($x))`;
float $xSi_ = -1 * `sin (deg_to_rad($x))`;

float $yCos = `cos (deg_to_rad($y))`;
float $yCo_ = -1 * `cos (deg_to_rad($y))`;
float $ySin = `sin (deg_to_rad($y))`;
float $ySi_ = -1 * `sin (deg_to_rad($y))`;

float $zCos = `cos (deg_to_rad($y))`;
float $zCo_ = -1 * `cos (deg_to_rad($y))`;
float $zSin = `sin (deg_to_rad($y))`;
float $zSi_ = -1 * `sin (deg_to_rad($y))`;


matrix $mx[3][3] = << 1 , 0 , 0 ;
		      0 , $xCos, $xSi_;
		      0 , $xSin, $xCos>>;
		      
matrix $my[3][3] = << $yCos , 0 , $ySin ;
		      0 , 1, 0 ;
		      $yCo_ , 0, $yCos>>;

matrix $mz[3][3] = << $zCos , $zSi_ , 0 ;
		      $zSin , $zCos, 0;
		      0 , 0, 1>>;

matrix $mAll[3][3] = $mx * $my * $mz;

print "\nrotation Matrix:";
print $mAll;
print "\n";

+
http://en.wikipedia.org/wiki/Rotation_r ... ematics%29

That is still a first shot, and I think the conventions may differ, but the syntax works.

cheers,
b

[CTZn]

According to my reference $mx, $mz look correct, for $my try:

Code: Select all

matrix $my[3][3] = << $yCos , $ySi_ , 0 ; 
            $ySin  , $yCos , 0 ; 
            0 , 0, 1>>;

Should work for z up. Also I'm told that the final result has to be multiplied by

Code: Select all

       <<1 0 0 
         0 0 -1
         0 1 0>>

to work for Y up if I understand correctly.

[CTZn]

REV 36

- fixed initialShadingGroup bug

Ooops just realised instances are wrong with Y up

I'll do the rotation matrices after, or will you bkircher ? What is your status on that ?

[CTZn]

REV 37

- Fixed instances with Y up
- Added scale for instances
- updated documentation

Ready to have an insight of rotatrice mations right now ! bkircher I'm using your code as a basis, thx for the writing !

[dougal2]

can we put in the mtiSettings.txt back in for saving the indigo path?

I don't mind having to set up all the render settings for each new scene, but to keep inputting the path, which is always the same is a little tedious and boring. Also, changing the path in the file will then update every scene when the user installs a new indigo version

(another thought - I presume mti_settings.mti_version exists so that if major changes are made to the ScriptNode, we can detect this and update the scene with new ScriptNode attributes??)


edit: REV 38 - added, but left commented out, the code to read indigo path from file in mti_ScriptNode.mel

[dougal2]

ok, so what's happening here?

[Kram1032]

I tried it out, yesterday: lowest blackbody value that still gave emission was at 227.9 K - 227.8 rendered black I didn't try more accurate decimals, though...

[CTZn]

Thanks for the test, Kram.

There is a bug I think where instances are flipped in the Z (depth) axis. I think I know where it is but for the following hours I'll be on an urgent work.

$upAxis = `eval "getAttr mti_settings.mti_cameraUpAxis"`;

now returns 0 or 1 and not "Y" or "Z"

Gotta check that tonight. I've just fixed sun but won't commit before I fix that all.

Yep many scriptNode attr should be written on a file read when calling mti IMO, more explicit names for paths (eg Indigo(Install||App||Bin)Dir & Indigo(Proj||Work||whatever explicit)Dir) and initialize them with independent values.

What are you up to my friends ?

[bkircher]

just briefly:
Let's stick with one file containing all the prefs:
We could clear the script up by something like

global proc Bla ()
{

// edit these settings to your liking
$mti_InstallDir = "bla"; // path indigo is installed in
$mti_AlternativeInstallDir = "blaBla"; // alternative path indigo is installed in, e.g. local)

...

}

All settings should be contained in the mti_settings, so they can be editied/accessed within maya.

This is making very good progress!

p.s.:
Let's discuss about the best preferences, we do can deviate from the indigo defaults if that leads to a less noisy image, what do you think?

[CTZn]

I agree for the settings to be written to a file.

As for "improved" settings, well I'm not sure but I'll let you do for now bkircher if I may. That's a subjective/context-dependent topic and that's why my opinion is reserved.

On clamped values again: I suggest we clamp the slider but not the value itself as long as Indigo can take it, would like to have your opinion on that but really that's bugging me

Urgent work finished (waiting for feedback), will commit fixes within 6 hours !

[CTZn]

REV 39

Fixed: instances z flip when y is up.

now on rot matrices ! Did you get them working bkircher ?

[dougal2]

REV 40

implemented saving indigo paths to file.
upon first load the defaults are saved, but for now
mti_SavePathsToFile; needs to be called to update the file. changes are not automatically saved. we need a GUI button.