Direction, and color

Mike Bonner bonnmike at gmail.com
Mon Dec 15 10:47:26 EST 2014


ok, so I lied. I keep making adjustments to how the color generation works,
but to get the results I want.. i'm lost again.

Currently, if I want to find "red", I can get a factor for red where
abs(sin((tCurAngle - tColorAngle) * pi / 180))  (cur angle is 0, color
angle is also 0, factor returned is 0)  Then do 255 - (255 * factor) so the
value for red is 255.

But for the other 2 colors, I need to return a factor of 1 so that they are
completely removed so that the primary color is the only one left.   To do
this requires a current angle offset from the designated color angle to be
90 degrees.  So for example, green is 60, to get a factor of 1, the current
angle would have to be 150, and for blue it would have to be 30 on my
imaginary, impossible number circle.

I can fix this by setting my colors to 0, 90, 180. (again, only using half
the circle)  But doing it this way, I end up with grey between cycles, so
there is a nice solid sequence of reds, then grey,then green, then grey,
then blue, repeat.

So, what I need to figure out, is a way to weight things, so that the
closer 1 color gets to 255, then more reduction affect there is on the
other 2 colors.

Any suggestions?



On Sun, Dec 14, 2014 at 2:47 PM, Mike Bonner <bonnmike at gmail.com> wrote:
>
> Last post on this, things are working well enough that I'm happy.  In case
> anyone is interested, here is a link to a stack with 3 sliders, r, g, b
> sliders so that the weight of each color can be adjusted during cycling.
> All it does is change the background color of the card based on the sliders
> and cycling through (figmentary)  angles.
>  https://dl.dropboxusercontent.com/u/11957935/colorphase.livecode
>
> On Sat, Dec 13, 2014 at 8:45 PM, Mike Bonner <bonnmike at gmail.com> wrote:
>>
>> Oh, just realized, due to the normalization, I only needed to cycle 1 to
>> 180 to get the full color chart. DOH.  360 repeats. (since its basically,
>> seeing "how far" from a point on the circumference, based on degrees, 180
>> is the cap, and the abs() stuff makes dealing with negatives moot. )
>>
>>
>> On Sat, Dec 13, 2014 at 8:24 PM, Mike Bonner <bonnmike at gmail.com> wrote:
>>>
>>> Thanks for the ideas and hints, some ideas finally triggered in my
>>> noggin and I have a pretty good solution now.  Craig, yeah I love the idea.
>>> A simple lookup table would work, especially since the motion of the
>>> objects is a simple x,y thing, so a keyed array would make it simple.
>>>
>>> I'm stubborn though, and want to generate a nice smooth transition (like
>>> my own home built color wheel algorithm.)
>>>
>>> The code (plus extra code that cycles the background color of a field
>>> just to see the visual) follows.
>>> -- constants for these.  Mainly so that if I want skewed colors like
>>> heavy blue, I can tweak these.
>>> constant kRed=255,kGreen=255,kBlue=255
>>> on mouseUp
>>>
>>>    repeat with i = 1 to 360 -- morph the color based on degrees
>>>       put i mod 360 into tCurAngle
>>>       put  round((colorshift(tCurAngle,0))* kRed) into tRed --
>>> colorshift function does all the work.
>>>
>>> -- multiply the base color value by the factor returned from the
>>> colorshift function
>>>       put  round(( (colorshift(tCurAngle,240))) * kBlue ) into tBlue
>>>       put round((colorshift(tCurAngle,120)) * kGreen) into tGreen
>>>       set the backgroundcolor of field 3 to tRed,tGreen,tBlue
>>>       wait 10 millisec with messages -- so you can more easily see the
>>> changes
>>>
>>>    end repeat
>>> end mouseUp
>>>
>>> -- this is the heavy lifting.  tcolorAngle is the angle that designates
>>> the stronges
>>> -- point of color intensity for that color. I've assigned, 0, 120, 240
>>> function colorshift tCurAngle, tColorAngle
>>> -- subtract tColorangle to "normalize"
>>> -- then convert that angle to radians, which gives a factor between 0
>>> and 1
>>> -- which will then be used to adjust the color value itself
>>>    put abs(sin((tCurAngle - tColorAngle) * pi / 180)) into tAdjustedAngle
>>>    return tAdjustedAngle
>>> end colorshift
>>>
>>> From there, it should be easy to adjust by velocity.  If initial values
>>> are maxed at 200, that gives a 55 point per color scale that can be used
>>> for intensity adjustments, which could be another factor multiplied
>>> uniformly across all 3 rgb values.
>>>
>>> I'm sure it can be simplified and cleaned up, but is working pretty well.
>>>
>>> Thanks all for helping me get my head wrapped around this.
>>>
>>> On Sat, Dec 13, 2014 at 12:32 AM, Mike Bonner <bonnmike at gmail.com>
>>> wrote:
>>>>
>>>> Hey!  Simple and easy, Thanks much, will try and get it working
>>>> tomorrow.
>>>>
>>>> On Fri, Dec 12, 2014 at 11:27 AM, Richmond <richmondmathewson at gmail.com
>>>> > wrote:
>>>>
>>>>> On 12/12/14 19:19, Mike Bonner wrote:
>>>>>
>>>>>> I have a quick question, its one of those that should be obvious, but
>>>>>> i'm
>>>>>> just not seeing it.
>>>>>>
>>>>>> What i'm playing with right now, is just a bunch of round grc moving
>>>>>> on
>>>>>> screen. (an adaption of the "swarm" sample stack created by scott
>>>>>> rossi)
>>>>>>   What I'd like to do, is modify the colors of of each ball based on
>>>>>> direction and speed.  Sort of like a color wheel, zero speed or
>>>>>> direction
>>>>>> being the center of the wheel.  So, direction would affect color, and
>>>>>> speed
>>>>>> would affect the end color based on a gradient dark to light.
>>>>>>
>>>>>> I hope the explanation is clearer than mud.
>>>>>>
>>>>>> Any suggestions, or reading material that might help get me
>>>>>> kickstarted?
>>>>>>
>>>>>> TIA
>>>>>>
>>>>>> Mike
>>>>>> _______________________________________________
>>>>>>
>>>>>>
>>>>> I don't think that should be unduly difficult . . .
>>>>>
>>>>> For instance, one could leverage RGB codes so that, let us say, the
>>>>> direction in degrees
>>>>> could be signalled something like this:
>>>>>
>>>>> RRR= round (255/(360-DIR)
>>>>> set the backgroundColor of grc "myFatBlob" to RRR,GGG,BBB
>>>>>
>>>>> where DIR is the direction in degrees, GGG is some number 0<GGG<256,
>>>>> and so is BBB.
>>>>>
>>>>> Darkness could be worked out by having one's "Blobs" consist of a pair
>>>>> of graphics (one on top of the other)
>>>>> where the lower one is black. Speed could then be signalled by setting
>>>>> the BLEND level of the top one.
>>>>>
>>>>> Richmond.
>>>>>
>>>>> _______________________________________________
>>>>> use-livecode mailing list
>>>>> use-livecode at lists.runrev.com
>>>>> Please visit this url to subscribe, unsubscribe and manage your
>>>>> subscription preferences:
>>>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>>>>
>>>>
>>>>



More information about the use-livecode mailing list