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 <bonnm...@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 <bonnm...@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 <richmondmathew...@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@lists.runrev.com >>> Please visit this url to subscribe, unsubscribe and manage your >>> subscription preferences: >>> http://lists.runrev.com/mailman/listinfo/use-livecode >>> >> >> _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
