Photon color for custom gui

[jan-ace]

Hello all,

I'm creating a gui to manage my lights in a scene.
currently I am trying to create a color slider for the photon color.

But for some reason I can not access this attribute correctly.
I have tried to use the .energy attribute but this also modifies the photon intensity and it does not update correctly.

if i change the photoncolor on the light itself then the gui updates but if i change the photoncolor via the gui then the photoncolor on the light is not updated.

also it looks as though the photon intensity is defined by the v value of the HSV color channels.
Because if i change this value and then select the light the intensity slider is modified.

Any help would be apriciated.
thanks,
Jan

Added a little script for clarification

string $window = `window`;
    columnLayout;
        $lightOBJ =`spotLight`;
            $phColorSlider = `attrColorSliderGrp -at ($lightOBJ+".energy")`;
showWindow $window;

[joojaa]

But for some reason I can not access this attribute correctly.

I took a second look at this: That would be because no such attribute exists, the slider in attribute editor is pure and simple mel code to do something that to user doesent get exposed to inetrnals. a bit akin to the angle of view of a camera which also does not exist. All attributes present in the AE dont need to exist, after all thats what the AE templates are all about: Ability to separate implementation internals from the gui.

 The energy attribute is not actually the color attribute, in fact theres no such thing as photon color, theres just energy which is allways computed on fly. So if you want the same thing than in attribute editro then you must also do the same conversions as in attribute editor.

Please look at:

miLightUpdatePhotonEnergy function found in AEmentalrayLightCommon.mel for details on how its IS implemented

Looking here you see that

color=energy/intensity

Actually intensity also dont exist as far as mentlaray is concerned so soley setting it without updating energy does you no good. Its there just so that the data can be set presitent

if i change the photoncolor on the light itself then the gui updates
but if i change the photoncolor via the gui then the >> photoncolor on the
light is not updated.

And it will not be updated becayuse theres no link to any attribute for that value in AE because the AE assumes its the only setter. Either you need to manually update that value if ae is present or forget about it.

PS: you would probably be better off getting one of the ready made light management scripts a go first rether then trying to reinvent the wheel.

[jan-ace]

Hey Joojaa,

Thank you very much for your reply.

I did notice that it was something internally in maya but I never realised i could check the "core" mel scripts of maya.
So thank you for showing that to me :D.

So I will see if i can do something with the
miLightUpdatePhotonEnergy function.
Hopefully I can implement it just like maya has done in the AE.

Part of creating this script is for me to learn more about maya MEL even if the scripts already exists.

I have checked a few scripts but none had the photon color attribute in their scripts that is why I am trying to get it to work
As soon as I get the entire script to work I will post it in the mel section.

As for the photon intensity. The attribute  ".photonIntensity" does seem to work correctly so that is no problem... i hope.

Thank you again for your time and help.
If I find the solution I will also post it here.

Jan

[joojaa]

I did notice that it was something internally in maya but I never
realised i could check the "core" mel scripts of maya.

Yes the, trick is to sometimes strategically turn echo all on. Then whatIs the function names to track where they are defined to have a look see.

After all they are meant for you to re purpose

had the photon color attribute in their scripts

Well obviously what does not exist can not be used.

[jan-ace]

Well obviously what does not exist can not be used.
"
hahaha yeah definitly true. But what I've learned is that there is always a "work around".
So I'm going to try to find one

To quote Thomas Edison:
I have not failed. I've just found 10,000 ways that won't work.

[joojaa]

In this case its a miplementation not a workaround.

[jan-ace]

Well that was easier than I thought. (cough)

I started off with copying the original code and started to create a custom function for my slider...
But after an hour or so something in my mind kept saying: THIS CAN BE DONE A WHOLE LOT EASYER !!!

Wel so far i have 2 options, the most elaborate option is to copy the
miLightPhotonColorReplace
and
miLightUpdatePhotonEnergy
procs and modify it to my slider.
But this gave me some update problems which are easily fixable. However I think this is way too much code for this simple operation.

So the easiest solution I have found so far is by directly modifying the colorSliderGrp in the AE editor and then force the update of the photon color. However there are two problems

1) the light has to be selected.

The problem is that if I force the selection the color is not updating as it should. I'm puzzled by how this goes wrong. Maybe maya does not update quickly enough for the procedure to work correctly.
A solution would be if i would be able to select the controller name based on the object but I am afraid that that is not possible. Something like this for example "spotLightShape2.lightPhotonColorCtrl".

2) problem two is somewhat trivial; the control only works one way.

If i change the photoncolor in the custom gui the photon color in the AE updates accordingly.
But if i do it the other way around the custom gui is not updated. I am afraid that I will not be able to work around this without adding a line of code in the original mel scripts. Which I absolutely do not want to do.

This is what I have at the moment which works if the correct light is selected.

 
if (`window -ex photonColorTest`){
    deleteUI -window photonColorTest;
}
string $window = `window photonColorTest`;
    columnLayout;
        $lightObj = `spotLight`;
        select -r $lightObj;
        float $rgbValue[] = `colorSliderGrp -q -rgbValue lightPhotonColorCtrl`;
        $phColorSlider = `colorSliderGrp -rgbValue $rgbValue[0] $rgbValue[1] $rgbValue[2] -cc "photonColUpdate($lightObj,$phColorSlider)" photonColorTest`;
showWindow $window;
global proc photonColUpdate(string $lightObj,string $controlName){
    // get current color value
    float $rgbColors[] = `colorSliderGrp -q -rgbValue $controlName`;
    // change the color attributes of the selected light.
    colorSliderGrp
        -edit
        -rgbValue $rgbColors[0] $rgbColors[1] $rgbColors[2]
        lightPhotonColorCtrl;
    miLightUpdatePhotonEnergy ($lightObj);
}

If i would add this piece of script to force the selection of the light when a change in the color slider occurs,
The update of the photon color does not seem to work anymore.

    // at the start of the "photonColUpdate" procedure. 
    // get the current selection so we can restore it afterwards
    $curSelObj = `ls -sl`; does not work
    // select the light
    select -r $lightObj;
    // at the end of the procedure
    // give user back original selection
    select -r $curSelObj;

Do you have any idea how either
a) I would make sure that the light is correctly loaded
or
b) i can access the lightPhotonColorCtrl // nevermind this is definitly not possible without having the AE open
or any other solution you can come up with.

Thanks again for your time.
Jan

[jan-ace]

ARGGGGG CLASSIC CASE OF REBOOT MAYA AND IT WORKS !!!

Now i still have the problem that the gui does not update when i change the photonColor in the AE.

Any idea's on that.

[joojaa]

This si as advaced concept in mel as it gets, not easy to solve.

Thing is theres really no way of doing this elegantly, whet has been done is a layer on top of something that you have. That layer has been decoupled with whats underneath and can not be solved without fixing both your code as well as their code. Unfortunately mel has no vocabulary to fix this issue very well. (mel can only connect attributesto each other not controlls, so there will be a time lag between changes for sure)

So whatever you do its going to be a lot more involved than you think.

See you have

• attributes separated by mel to give gui.
• gui assumes one way operation AE operates, this means theres no hook back.
• Now you can not rely on the AE to do the job for you because it wont report back and it wont react to you.

Like i said its not esy since you dont have the hooks needed to do this. You can create them but thats not very nice and ultimately youll be doing very much code for something remotely cosmetic and it will work out badly.

Now problem number one is that the AE is transient, you can not rely on it to be there, you just can not. Further theres no single thing you can hook to since mel is not hookable.

THIS CAN BE DONE A WHOLE LOT EASYER !!!

Well tat may be, however there's code and then there's code. See you write code, that code is on top of something else. Now you can not measure your codes elegance  by lines of code, because your 10 line code may actually be a 1000 line code whereas somebody else writes 50 lines of code may be just that. So elegance also depends on whats underneath your system

Ok how to approach this then? Well thing is i would personally just steer clear if i were you. Some things are inheritnly to be left alone this one costs you more tan t will under any sane circumstances. Say it takes of each users life by 1 minute each day, and this small minor update detail takes you 3 days to code, now surely that detail isnt the entire minute say its 0.1 minutes worth, thet means a single user would need to use 14400 days to return your investment. Is it worth it?

The computer dont care if its a exercise or not

[jan-ace]

Hey Joojaa.

Thank you very much for your elaborate explanation.

I understand that I have reached one of the limits of mel.I totally agree on the fact that I can not trust nor expect the AE to be there. Not even if I force the AE in the screen. Usually I'm fond of using hacky techniques to get my result but from a users point of view I think that forcing the AE each time you make a change is maybe overkill and unreliable.

So I guess either the photon color will not be accesable or my gui will only work one way :).

The computer dont care if its a exercise or not

That is definitly true, but for some reason I keep wanting to optimize the script. I hope that this will keep me sharp and improves my scripting skill and the knowledge of the underlying system. Even though it does not really matter much for mel in some situations.

Thank you for all your time and help.

Greets Jan

[joojaa]

Well you can sortof do this with a very longwinded path usinga scriptjob. But etheres a lot of caveats such as initialisation. You see Intensity doesnt necceserly exist untill it gets created just for this gui widget. So not only do you nee dto update things but you must also ensure that they jhave been initialized. Ill post some cludge once i get it working.

wanting to optimize

Dont optimize make a different approach.

[joojaa]

/* jooDemoPhotonSettingsGUI.mel  0.11a
   THIS VERSION IS A PROTOTYPE FOR TESTING ONLY!
 
  Authors:     Janne 'Joojaa' Ojala
  Testing:     Brief, report any bugs or ugliness
  Nade for:    jan ace
  Licence:     Public Domain
  About:
  
 
  Known Limitations: Terrible amount of events flying around.
                     Should be made into a panel.
                     Does not react to light creation or elimination
  
  Install Instructions:
  
  place jooDemoPhotonSettingsGUI.mel to your maya script directory*
  
  Usage:
  run jooDemoPhotonSettingsGUI() to load the demo window up.
 
*****************************************************************/
 
 
 
/*******************    Support Functions   *********************/
 
// lightPhotonIntensityInit
//
// default intensity is 1 but either it hasnt been 
// computed yet, or it really is one in wich case 
// the function yelds a successfull answer anyway.
//
proc lightPhotonIntensityInit(string $node){
  float $intensity = `getAttr ($node + ".photonIntensity")`;
  if ($intensity==1){
    float $energy[] = `getAttr ($node + ".energy")`;
    float $maxColor = max($energy[0], max($energy[1], $energy[2]));
    if ($maxColor>1){
      $intensity = $maxColor;
      setAttr ($node + ".photonIntensity") $intensity;
    }
  }
}
 
proc createPhotonSettingsGRP(string $node, string $window){
  frameLayout -label  $node -collapsable 1;
    columnLayout;
      $chk=`checkBox -label "Emit Photons" emitPhotons`;
 
      $ctrl=`colorSliderGrp -label "Photon Color"  photonColor`;
      colorSliderGrp -e -cc ("photonSettingsGRPChanging "+
                              $node+" "+$ctrl+"") $ctrl;
 
      $int=`floatSliderGrp -label "Photon Intensity" -field true 
                           -cc ("photonSettingsGRPChanging "+
                                 $node+" "+$ctrl+"") 
                           -max 10000.0 photonIntensity`;
 
      connectControl $int ($node+".photonIntensity");
      connectControl $chk ($node+".emitPhotons");
 
      // Create script jobs, this is usually acceptable for 
      // GUI building but for other functionality try to avoid
      // using script jobs. Also make sure the initial values 
      // are correect.
      // IMPORTANT: remeber to make the script jobs attached to
      //            the gui so they die gracefully
 
      scriptJob -ac ($node+".emitPhotons") 
                    ("photonSettingsGRPChek "+
                      $node+" "+$int+" "+$ctrl)
               -p $window; 
      scriptJob -ac ($node+".energy")
                    ("photonSettingsGRPChanged "+$node+" "+$ctrl)
                -p $window;
 
      lightPhotonIntensityInit($node);
      photonSettingsGRPChek $node $int $ctrl; 
      photonSettingsGRPChanged $node $ctrl;
    setParent ..;
  setParent ..;
}
 
 
/*******************    Event Functions   ***********************/
 
// photonSettingsGRPChek
//
// global because its registered as a temporary node 
// change event.
//
global proc photonSettingsGRPChek
             (string $node,string $ctrl,string $ctrl2){
  $state=getAttr($node+".emitPhotons");
  colorSliderGrp -e -enable $state $ctrl2;
  floatSliderGrp -e -enable $state $ctrl;
}
 
// photonSettingsGRPChanging
//
// global because ist a gui callback
//
global proc photonSettingsGRPChanging(string $node,string $ctrl){
       global string $gAECurrentTab;
	float $val[] = `colorSliderGrp -query -rgbValue $ctrl`;
       float $intensity = `getAttr ($node + ".photonIntensity")`;
	$energy[0] = $val[0]*$intensity;
	$energy[1] = $val[1]*$intensity;
	$energy[2] = $val[2]*$intensity;
       setAttr ($node + ".energy") 
               ($energy[0]) ($energy[1]) ($energy[2]);
	if(!`colorSliderGrp -query -exists lightPhotonColorCtrl` ||
           `colorSliderGrp -query -isObscured lightPhotonColorCtrl`||
           !gmatch($gAECurrentTab, $node)){
		return;
       }
       float $val[] = `colorSliderGrp -query -rgbValue $ctrl`;
       colorSliderGrp -e  -rgb ($val[0]) ($val[1]) ($val[2]) 
                      lightPhotonColorCtrl;
}
 
// photonSettingsGRPChanged
//
// global because its registered as a temporary node 
// change event.
//
global proc photonSettingsGRPChanged(string $node,string $ctrl){
 
  float $energy[] = `getAttr ($node + ".energy")`;
  float $intensity = `getAttr ($node + ".photonIntensity")`;
	$energy[0] /= $intensity;
	$energy[1] /= $intensity;
	$energy[2] /= $intensity;
  colorSliderGrp -e -rgb ($energy[0]) ($energy[1]) ($energy[2])
                 $ctrl;
}
 
 
 
/*******************    In Point Function   *********************/
 
global proc jooDemoPhotonSettingsGUI(){
string $window = `window -title "photonTest"`;
  columnLayout -adjustableColumn true;
  string $lights[]=ls("-lights","-long");
  for ($light in $lights)
    createPhotonSettingsGRP($light,$window);
  showWindow $window;
}

[jan-ace]

Hey Joojaa,

Thank you very much for all your time you spend on researching this.

I have learned a tremendous ammount from this example, not only the photon update part but also the rest of the script.
For example the creation of the gui in the for loop in a sepperate proc. Currently I have most of the creation of the gui in one big proc.
Also the parenting of a script job to a gui great solution for keeping it clean !

I have a few questions though about some techniques you used.

in the following proc

photonSettingsGRPChanging

you get  the

global string $gAECurrentTab;

string. Why do you do this? does this get the current tab name that is open in the AE so you can make sure the correct AE is opened ?

in the proc

lightPhotonIntensityInit
you set the intensity to the $maxColor but you only do this if the intensity is set to 1 would you not want to do this always?
and why do you not connect the intensity slider with a 

attrFieldSliderGrp
control ?

when you call these 2 procs:

  lightPhotonIntensityInit($node);
  photonSettingsGRPChek $node $int $ctrl;

why do you use brackets in one scenario and no brackets the other?

In Limitations you mentioned
"Should be made into a panel."
What do you mean by that?

I have uploaded the script I have so far, if you are interested you can take a look at it.
Unfortunatly I did not find the time yet to implement your technique yet.

But as you can see, I will need to make a lot of "different approaches" in order for the script to be nice and tidy.

http://www.redace.nl/Scripting/red\_lightManager.mel

Again thank you for your time and help.
Jan

[joojaa]

Well i don't think this code is a good learning practice, it teaches bad habits that in this instance are ok but then when you get into it most users mostly use them wrong.

You have been warned.

global string $gAECurrentTab; Why do you do this
Because I want to access the global that AE uses to track the node that's being show in the AE. See you ONLY want to edit the control if it happens to be the same object you are changing, otherwise you'd accidental write to another objects color slot.

you set the intensity to the $maxColor but you only do this if the intensity is set to 1 would you not want to do this always?

because it would make it impossible to have color other than ones with full value as always when you'd change the color it would recompute intensity and push the color to full value. Not that i would mind this behavior but thing is the default doesn't so i don't either.

1 simply means nothing would change, and that's the initial non calculated state and then its wrong so that's why you check for it. Also saves time, but that's just because i don't need it to.

Main reason for this being that the light may have been used already, you launched second window or for second time etc.

and why do you not connect the intensity slider with a  attrFieldSliderGrp control ?

Well as a matter of fact i do the same thing but with connect control instead. There's really no difference the grp's are actually many elementary functions combined into one, you can explode them and build each one separately with same effort. See I'm actually reserving the right to expand.

just beinga  bit messy is also one other reason, wanted to get it out of my way ASAP.

  why do you use brackets in one scenario and no brackets the other?

Nothing really, wanted to follow same event conventions as AE and because O happened to have the second version that way, i just copy pasted it. Likewise there's no difference between saying

data=ls -sl;

data=ls("-sl");

except the other version has a handy feature when combined with other commands and lazy evaluations. SO prefer that but the shorthand is shorter to type (DUH!).

"Should be made into a panel."

Everybody does windows, however 90% of cases they wanted to make a scripted panel but didn't bother to read the docs. Read the mel reference for:

scriptedPanel

In any case a panel is dock-able, persistent, passes shortcuts and in all other ways more elegant than a window, basically behaves like true Maya internal editors. Just a few more lines of hassle.