MayatoIndigo Developement
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.
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.
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![Confused :?](./images/smilies/icon_confused.gif)
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
![Confused :?](./images/smilies/icon_confused.gif)
obsolete asset
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 :/
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 :/
obsolete asset
My prefered solution as I said would be to use scientific notation, aka straight physical values. Mind this:
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:
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 ![Laughing :lol:](./images/smilies/icon_lol.gif)
Still, that's only my opinion; best thing could be a switch between artistic/physical values, a boolean btw. I mean including both methods.
Code: Select all
setAttr "nurbsSphere1.translateX" 11.35e-006;
getAttr "nurbsSphere1.translateX";
// Result: 1.135e-005 //
input:
Code: Select all
<exponent>270305564e-5</exponent>
Code: Select all
Calculating energy loss compensation curve for exponent 2703.055664
![Laughing :lol:](./images/smilies/icon_lol.gif)
Still, that's only my opinion; best thing could be a switch between artistic/physical values, a boolean btw. I mean including both methods.
obsolete asset
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![Very Happy :D](./images/smilies/icon_biggrin.gif)
Edit: merging my changes isn't a problem. I don't have to change too many lines
![Very Happy :D](./images/smilies/icon_biggrin.gif)
Physical values are given from defined (web) sources, it's not messing with them but replicating them plain ![Smile :)](./images/smilies/icon_smile.gif)
Ok. What about:
That's for a beginning, all physical values will have to be input with scientific notations (XX[+/-]eYY).
![Smile :)](./images/smilies/icon_smile.gif)
Ok. What about:
Code: Select all
if the value contains "e", paste it plain in xml
else do the other way.
obsolete asset
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:
My change:
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![Very Happy :D](./images/smilies/icon_biggrin.gif)
PS: thx for the svn Account, Dougal![Smile :)](./images/smilies/icon_smile.gif)
I also want to mention that I'll visit my parents this weekend, so I'll be not here![Very Happy :D](./images/smilies/icon_biggrin.gif)
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);
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
![Very Happy :D](./images/smilies/icon_biggrin.gif)
PS: thx for the svn Account, Dougal
![Smile :)](./images/smilies/icon_smile.gif)
I also want to mention that I'll visit my parents this weekend, so I'll be not here
![Very Happy :D](./images/smilies/icon_biggrin.gif)
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.
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.
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 ![Very Happy :D](./images/smilies/icon_biggrin.gif)
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![Smile :)](./images/smilies/icon_smile.gif)
Maybe the default focal lenght of 35cm is too wide for your needs ? Try 24 maybe ? Damn I must learn that stuff![Embarassed :oops:](./images/smilies/icon_redface.gif)
![Very Happy :D](./images/smilies/icon_biggrin.gif)
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
![Smile :)](./images/smilies/icon_smile.gif)
Maybe the default focal lenght of 35cm is too wide for your needs ? Try 24 maybe ? Damn I must learn that stuff
![Embarassed :oops:](./images/smilies/icon_redface.gif)
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.
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.
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.
Last week I couldn't commit, server was not accessible. I'll try that tomorow again, a new mti version should come then.
Who is online
Users browsing this forum: Bing [Bot] and 42 guests