Page 4 of 5
Posted: Tue Nov 25, 2008 11:16 pm
by Hellstorm
well... since everything fades somewhere to black when I use values greater than zero, I need a maximum multiplier. I hadn't time by now, but I'll search for that multiplier with a medium color of <0.999 0.999 0.999> (near perfect transparent). I'll get something like a multiplier of 100000 I guess.
Now I just need to compute (100000 - distance) and everything should work. That's the theoretical part. However, I don't want <distance> to be the value where everything is black. <Distance> should be the multiplier where I would see the medium color (for instance in front of a white wall) as I see it in the viewport. I guess this would be something like ((100000/2) - distance).
However, I have to do some test renderings when I've got some time.
For your textfieldnode:
I'm also not very familar with python, but I'll see what I can do.
Posted: Wed Nov 26, 2008 5:47 am
by dougal2
Hellstorm, PM me if you want an account to perform MtI SVN commits.
Posted: Wed Nov 26, 2008 12:08 pm
by CTZn
Hello Dougal, glad to see you pop here !
Hellstorm, I guess I'll let you do that part on transparency, I always prefered plain numbers to anything tricky, or limiting. But until I see it I will not have a precise idea on the result, so fire it up mate.
I'll be back soon, but still when I think "coding" I have XML's Parsing Hell yelling in my head, I need a longer break
Posted: Wed Nov 26, 2008 12:27 pm
by CTZn
I'm asking Ono to move this thread to the developement forum... I don't think you can move it out here, Dougal...
On the textFieldNode: It will be lot easier with it both for us to parse the content for a single attribute, and clearer for the user to have one single text field by attribute too. Also we could save presets for isl bits, plus tabulated data and much more, I believe it's worth fixing. When it's here I will finish the parsing headache from hell crap (I shud up the files if you get write access).
It seems I just wasn't able to declare the right kind of attribute type for the text field (by text field I mean in fact a block, like notes every node has, accessible down the AE), I tried kStringData and couldn't go much further. I have the bitmap and vector icons for it already, really it should have only this attribute, there's not much left to bridge the gap, I guess.
edit: renamed thread in anticipation of it's upcoming migration.
edit 2: Completed: At revision: 277
Hellstorm, sorry, you will have to merge your bits manually :/
Posted: Wed Nov 26, 2008 1:40 pm
by CTZn
My prefered solution as I said would be to use scientific notation, aka straight physical values. Mind this:
Code: Select all
setAttr "nurbsSphere1.translateX" 11.35e-006;
getAttr "nurbsSphere1.translateX";
// Result: 1.135e-005 //
You can use this notation straight in any numeric attribute, that would be my best choice because physical values exist and are known. And after a short test it seems that Indigo can read it the same way:
input:
ouput:
Code: Select all
Calculating energy loss compensation curve for exponent 2703.055664
What you think ? I forgot about that possibility, but now I want it ! Note that it needs no further modifications then, it's up to the user to learn writing values this way... we could make a guide for that... at least I am going to need one
Still, that's only my opinion; best thing could be a switch between artistic/physical values, a boolean btw. I mean including both methods.
Posted: Thu Nov 27, 2008 12:22 am
by Hellstorm
As switch would be nice. As an artist I dont want to mess around with scientifiy values. My mind is full of values regarding lighting, texturing. Ideas of how I model things. and also: common values are comparable by just looking less than a second onto them.
Edit: merging my changes isn't a problem. I don't have to change too many lines
Posted: Thu Nov 27, 2008 2:05 am
by CTZn
Physical values are given from defined (web) sources, it's not messing with them but replicating them plain
Ok. What about:
Code: Select all
if the value contains "e", paste it plain in xml
else do the other way.
That's for a beginning, all physical values will have to be input with scientific notations (
XX[+/-]eYY).
Posted: Thu Nov 27, 2008 10:19 am
by Hellstorm
Would be the best way I guess. Nobody has to mess around with additional settings.
Posted: Fri Nov 28, 2008 1:09 am
by Hellstorm
Heya. Found something interesting:
When I use the default Global Scale Factor of 0.01 (100 Maya centimeter = 1 Indigo Meter) I noted the following:
The Depth Of Field was ways too strong. Even with an F-Stop of 250 which should remove almost any DoF.
I had a look into the mti_ExportModuleCamera.mel
And changed a thing on (or around) line 86:
Original:
Code: Select all
float $mApertureRadius = ($mFocalLength / ($FStop * 2.0)) * (1/$mtiGSF_Cam);
My change:
Code: Select all
float $mApertureRadius = ($mFocalLength / ($FStop * 2.0));
I'm not sure if this is correct, but I get reasonable results at GSF 1, as well as GSF 0.01.
I'll also won't commit the change at this time, because I'm not sure if my change is correct (I have to read the Indigo Docs), but maybe someone here can help me
PS: thx for the svn Account, Dougal
I also want to mention that I'll visit my parents this weekend, so I'll be not here
Posted: Fri Nov 28, 2008 3:36 am
by dougal2
The DOF/GSF thing has been changed several times back and forth iirc.
You need to carefully look at the value of $mFocalLength and find out what units it's using, and if those units change with the Maya dimension units setting.
I have performed tests with this and blendigo as reference, but that was a while ago and I forget if the matter was ever fully resolved.
Posted: Fri Nov 28, 2008 5:41 am
by CTZn
Well, I think I added what you removed, but indeed I have not acquired the knowledge to answer this definitly. I remember i choosed to modify this formula after empirical attempts, just like you
As Dougal, I would recommend prudency with the camera, since it was often broken in the past.
Most of the time Maya is used with centimeters (and if not, specially camera are going nuts). There has to be a conversion, right ?
The behaviour I observed with the actual setting was coherent:
Framing a 1cm tall cube (default cube + GSF 0.01) just gives a blurry image with 3 sharp point where the focal plane cut the cube. Framing a 10 cm cube gives a strong blur but the shape of the object is now identifiable. If the cube is 1m tall well I feel things are ok like for the other units
Maybe the default focal lenght of 35cm is too wide for your needs ? Try 24 maybe ? Damn I must learn that stuff
Posted: Fri Nov 28, 2008 10:07 am
by Hellstorm
I don't like a focal length of 35mm. I rather use 20-25 mm for most purposes
However, I'll also have a closer look on the formula. I'll have some ideas, but I have to check the maya/mel reference manual.
So far I'll stick with the changed line for my personal sake as far as I find a good solution.
Posted: Fri Dec 05, 2008 10:26 am
by CTZn
How goes that camera thing
Hellstorm ?
Regarding the indigoShader, you added that extra attribute didn't you ?
And forget about the textFieldNode, it was removed from the script. I can't remember I did that.
Posted: Mon Dec 08, 2008 8:16 pm
by Hellstorm
Yah. It's located in the Extra Attributes tab. I didn't edit the template MEL yet. I'm not sure wether I should put it directly into the Medium Tab or create a new MtI-specific tab.
Cuz I was away longer than planned I hadn't enough time to get everything managed to work as expected. One of my customers is also sitting in my neck, so don't expect an update today.
Posted: Mon Dec 08, 2008 8:32 pm
by CTZn
Ok, take care of your customer first. Not sure what you are meaning about extra attributes and tabs or mediums. The script creates a custom, standalone node wich holds text and can be plugged into materials attributes to replace them individualy, much like textures. Maybe I'll give it a try soon again...
Last week I couldn't commit, server was not accessible. I'll try that tomorow again, a new mti version should come then.