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 <bonnm...@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 <bonnm...@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 <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