johnatm / itween

Automatically exported from code.google.com/p/itween
1 stars 2 forks source link

Can't animate arbitrary color values (e.g. "_TintColor") #43

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
In the iTween documentation 
<http://itween.pixelplacement.com/documentation.php>, the "namedcolorvalue" 
argument to methods like ColorFrom and ColorTo is documented to take a value of 
type "NamedColorValue or string". However, it turns out that only strings that 
name a value from the NamedValueColor enumeration are accepted. If you pass 
another color name, for example "_TintColor", then you get the warning, 
"iTween: Unsupported namedcolorvalue supplied! Default will be used."

If this restriction on the possible values for "namedcolorvalue" is to be kept, 
then it should be documented. However, it would be better if the restriction 
were removed.

"_TintColor" is the name of the main color value for a number of built-in 
shaders, for example Particles/Alpha Blended, so it would be useful if this 
value were supported.

But more generally, it would be nice to be able to use iTween to animate an 
arbitrary color value, because a user-defined shader may contain color 
parameters with arbitrary names. Since iTween does nothing with the 
NamedValueColor enumeration other than to call its "ToString" method, there 
should be no difficulty in supporting an arbitrary string for the 
"namedcolorvalue" argument.

Original issue reported on code.google.com by g...@garethrees.org on 3 Nov 2010 at 12:03

GoogleCodeExporter commented 8 years ago
[deleted comment]
GoogleCodeExporter commented 8 years ago
I see that the code contains the comment:

            //allows namedcolorvalue to be set as either an enum(C# friendly) or a string(JS friendly), string case usage doesn't matter to further increase usability:

In order to support arbitrary strings for the "namedcolorvalue" argument, 
you'll probably want to drop this case insensitivity feature (because it is in 
theory possible to write a shader with two color parameters that differ only in 
case). Luckily, the feature was never documented, so you can expect the 
breakage to be fairly small.

Original comment by g...@garethrees.org on 3 Nov 2010 at 1:17

GoogleCodeExporter commented 8 years ago
Thanks for the catch I'll address this.

Original comment by pixelplacement on 6 Jan 2011 at 5:23

GoogleCodeExporter commented 8 years ago
I have a solution for this, but it's not yet complete.  As I'm working on Unity 
5 and, well, nearly no material.color works anymore, I made those changes:

- "namedcolorvalue" hash item may be of type "string" or "Int32"
- the old code for this was replaced - no more enum NamedColorValue, it simply 
keeps an Int32
- upon ParseArgs any color-name will be converted to an ID via 
Shader.PropertyToID
- we now use [...].material.GetColor(ID) and [...].material.SetColor(ID, 
newColorValue) for reading/writing colors
- ValueTo was replaced by "DoValue", this NEEDS an ID or colorname to work 
without a callback for manipulating material properties other than a color
- DoValue may have a "to" entry or a "from", or both.  If it has only one 
value, the other one will be grabbed from the material on start.  This is by 
far incomplete, but it works for my needs.

Original comment by st0ff....@gmail.com on 20 Apr 2015 at 8:10

Attachments: