MtI rev 63 08 nov 2007

[bkircher]

Update: Rev. 102

- Fixed Toolbox resizing. I'd leave it at that, otherwise we could take it out
completely and I'm not willing to give CTZn that satisfaction
Honestly, as it's working, I think it's o.k. like this.

- Added $mti_useAdvOpt-access to mti_UserPrefs.mel.
This could be 0 or 1, depending how we see the function of the script.


The Idea of the userPrefs is that before installation, the user has a small file that he can edit, set the three or four most important values, and be done with. As a new user, I'd prefer this to editing the complete mti_settings file, and still have it startup nicely. We could call it in mti_settings, so that a user acquainted with the details could deactivate it there.

- Added check to IES-locator about the Z-Axis, it is rotated downwards
accordingly for Z-up also.

- Rearranged some code lines to look nicer.

- Added some script-presets modifying some elements of mti_settings:
- either sample directory locations,
- render settings like bidir and metropolis, or
- settings how long an image update will take.

Please have a look into them with a text-editor and modify them according to your experiences if you find the time, that could make some arcane details of indigo more transparent.

- - - - -
Is it possible that we make the IES-Locator work from scratch?
Some related commands:
connectAttr -f lambert.outColor lambertSG.surfaceShader;
addAttr -ln "mti_ies" -dt "string" $SG;
setAttr -type "string" lambert.mti_ies "1.ies";

[dougal2]

Is it possible that we make the IES-Locator work from scratch?
Some related commands:
connectAttr -f lambert.outColor lambertSG.surfaceShader;
addAttr -ln "mti_ies" -dt "string" $SG;
setAttr -type "string" lambert.mti_ies "1.ies";

yes, this makes sense, I wanted this to happen, but couldn't work out how.
however, will this create a new lambert for every IES light?

edit: I've implemented it so that each IESlight gets a new IESShader complete with custom attrs

[bkircher]

Shouldn't be a problem, as hopefully the user copies the IES-locator to create more of the same type.

Anyhow, I think the IES-Element is especially great to reach a fast success for new users.

( string $lambertX = `shadingNode -asShader lambert`; //works)

[bkircher]

Checked the sun, didn't work again:

Small white points on white appearing and getting sampled out with the next update.

No Clue as to why this happens, though.
Tried with three different angles of the sun, seems independend of that.

[dougal2]

Checked the sun, didn't work again:

Small white points on white appearing and getting sampled out with the next update.

No Clue as to why this happens, though.
Tried with three different angles of the sun, seems independend of that.

I'm not sure what you mean - must be something specific to your mti_settings or your scene.

A few tests here show sun rendering with no problems.

[dougal2]

REV 105
implemented camera exposure_duration. (ie. shutter speed)
the corresponding ScriptNode setting is inverted because of typically small values. ie. enter 1000 for 1/1000 sec.
allowed values are 0.1 to 10000
(10 sec to 1/10000 sec)

updated changelog


we must be damn close to something that is pretty full featured... apart from lack of glossy_transparent, blend material, the epidermis stuff and regular_tabulated spectrum I can't think of much else.

[dougal2]

actually, there are other things.. like RGB and peak meshlights.

[CTZn]

Sun is fine here. The two of you have achieved a great work. Actually I'm kinda out...

[dougal2]

here's an idea... quite a crazy idea for meshlights:

if (R <= 1.0)
use RGB spectrum as is.

if (300 <= R <= 800)
use peak spectrum

if (2000 <= R <= 9500)
use blackbody spectrum

these are quite clearly defined ranges, it could work

[CTZn]

yes but would be frustrating for the user... well actually you don't have to document that. In the other hand it's just about adding an attribute to the shader...

I'm not much on taking initiatives, because that evoluated lightning fast and well I'm on a lazy stance these last days. If you see something that I could try to hack tonight just tell me, or I see myself spending my time stupidly at home

[dougal2]

I'm not going to ask you to do anything.. totally your own decision.

I'm not going to change meshlights yet... there are more parameters than Maya attributes

sketched out rethink:

Code: Select all

Attribute	->	spectrum setting

?		->	power drawn
?		->	efficacy



blackbody	2500 < r < 9500
---------

r		->	temp
g		->	gain
b		->	


peak		300 < r < 800
----

r		->	peak min
g		->	peak width
b		->	base value

(peak value always 1.0)


RGB		0 < r < 1
---

r		->	r
g		->	g
b		->	b

mtiGlobalGamma 	->	gamma	


uniform ?
--------

In fact, I might just take a step back for a day or two and have a general slow-think about the whole shader->material translation and whether there's a better solution.
Possibly heaps of custom attributes, but that might get cumbersome and confusing.

[CTZn]

Look, I'm myself quite out of order but just observing the color picker: we have a switch3:

RGB:0 to 1 -> blackbody
RGB:0 to 255 -> RGB
HSV -> Peak

Then as you know input values are unclamped, so can be either kind of data incoming. Temp, frequency, whatever. Plain values.

Edit: peak needs 4 values, that's no perfect idea.

[dougal2]

one last thing for today.

edit: if both of you could at least try using rev105 tomorrow, that would be good. lets release tomorrow evening if you're both happy with it.
I for one think it's ready - we've added pretty much all current features,
and it's pretty good looking.

next thing I want to look at is improving intuitivity - particularly in the shaders. I don't want to give too many new ideas just yet or we'll get tied up implementing them and not actually releasing anything. I'll clarify my thoughts after the next release.

However, if anyone can get this kind of attribute to work I would like to know how

Code: Select all

addAttr -longName IndigoDiffuse -numberOfChildren 2 -attributeType compound myShader;

    addAttr -longName albedo_texture  -numberOfChildren 6 -attributeType compound -parent IndigoDiffuse;
	addAttr -longName albedo_texture_path		-dt "string" -parent albedo_texture;
	addAttr -longName albedo_texture_uv_set		-dt "string" -parent albedo_texture;
	addAttr -longName albedo_texture_exponent	-attributeType "float"  -parent albedo_texture;
	addAttr -longName albedo_texture_a_coeff	-attributeType "float"  -parent albedo_texture;
	addAttr -longName albedo_texture_b_coeff	-attributeType "float"  -parent albedo_texture;
	addAttr -longName albedo_texture_c_coeff	-attributeType "float"  -parent albedo_texture;




    addAttr -longName bump_map  -numberOfChildren 6 -attributeType compound -parent IndigoDiffuse;
	addAttr -longName bump_map_path		-dt "string" -parent bump_map;
	addAttr -longName bump_map_uv_set	-dt "string" -parent bump_map;
	addAttr -longName bump_map_exponent	-attributeType "float"  -parent bump_map;
	addAttr -longName bump_map_a_coeff	-attributeType "float"  -parent bump_map;
	addAttr -longName bump_map_b_coeff	-attributeType "float"  -parent bump_map;
	addAttr -longName bump_map_c_coeff	-attributeType "float"  -parent bump_map;

[bkircher]

I'll check the sun-issue I had...

As to the materials:
I think we should work in parallel on mechanism to derive the attached texture of the bumps / colours and implement that in the future.

The material attrib editor make the translation transparent...

more later

[CTZn]

when I was having black renders or a few fireflies on a black background, that was because of scale issues; the camera was within an overscaled object or 100x further from the scene than initially set in Maya, I hope that can help...