Direction, and color

[Mike Bonner]

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
>>>>
>>>
>>>