Direction, and color

Mike Bonner bonnmike at gmail.com
Sat Dec 13 22:45:23 EST 2014


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