add Rainbow Shimmer effect. Just like Rainbow Cycle but with a white … #4905
Conversation
…flash that runs across the segment
WalkthroughAdds a new FX mode "Shimmer": implements Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Suggested reviewers
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro 💡 Knowledge Base configuration:
You can enable these sources in your CodeRabbit configuration. 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
✨ Finishing Touches
🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
wled00/FX.cpp (1)
585-585: Metadata: consider reduced-resolution for Length and set sensible defaultsTo avoid huge shimmer lengths with small segments, either:
- mark “Shimmer Length” as reduced-resolution (0–31) in the metadata, or
- clamp in code (as suggested). If you keep it reduced, add r-flags and/or set a tighter default via cX/ix.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (2)
wled00/FX.cpp(2 hunks)wled00/FX.h(1 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
wled00/{*.cpp,!(html_*)*.h}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Use spaces (2 per level) for C++ source and header files
Files:
wled00/FX.hwled00/FX.cpp
🧠 Learnings (4)
📓 Common learnings
Learnt from: netmindz
PR: wled/WLED#4728
File: wled00/FX.h:378-378
Timestamp: 2025-06-15T09:59:52.720Z
Learning: In WLED's FX.h, MODE_COUNT represents the highest FX_MODE_ ID + 1, not the total count of FX_MODE_ definitions. This is because some effects may have been removed but their IDs are not reused, creating gaps in the numbering sequence. MODE_COUNT is used for array bounds and range checking.
Learnt from: netmindz
PR: wled/WLED#4728
File: wled00/FX.h:378-378
Timestamp: 2025-06-15T09:59:52.720Z
Learning: In WLED's FX.h, MODE_COUNT represents the highest FX_MODE_ ID + 1, not the total count of FX_MODE_ definitions. This is because some effects may have been removed but their IDs are not reused, creating gaps in the numbering sequence. MODE_COUNT is used for array bounds and range checking.
📚 Learning: 2025-06-15T09:59:52.720Z
Learnt from: netmindz
PR: wled/WLED#4728
File: wled00/FX.h:378-378
Timestamp: 2025-06-15T09:59:52.720Z
Learning: In WLED's FX.h, MODE_COUNT represents the highest FX_MODE_ ID + 1, not the total count of FX_MODE_ definitions. This is because some effects may have been removed but their IDs are not reused, creating gaps in the numbering sequence. MODE_COUNT is used for array bounds and range checking.
Applied to files:
wled00/FX.hwled00/FX.cpp
📚 Learning: 2025-08-26T11:51:21.817Z
Learnt from: DedeHai
PR: wled/WLED#4798
File: wled00/FX.cpp:7531-7533
Timestamp: 2025-08-26T11:51:21.817Z
Learning: In WLED PR #4798, DedeHai confirmed that certain gamma-related calls in FX.cpp/FX_fcn.cpp/particle systems are intentional for effect-level shaping (e.g., brightness curves, TV sim, Pride 2015 pre-mix), distinct from final output gamma. Do not flag or remove these in future reviews; add comments when feasible to clarify intent.
Applied to files:
wled00/FX.hwled00/FX.cpp
📚 Learning: 2025-09-02T19:42:57.457Z
Learnt from: freakintoddles2
PR: wled/WLED#4904
File: wled00/FX.cpp:3915-3930
Timestamp: 2025-09-02T19:42:57.457Z
Learning: WLED wled00/FX.cpp::mode_percent — For time-based options (% of Minute/Hour/Day), behavior is clock-like: at rollover (elapsed==0) intentionally show SEGLEN lit for one tick to represent completion, then move to 1 LED at the next second. This is by design (not a progress bar) and should not be “fixed”.
Applied to files:
wled00/FX.cpp
🧬 Code graph analysis (1)
wled00/FX.cpp (1)
wled00/colors.cpp (2)
color_blend(11-21)color_blend(11-11)
🔇 Additional comments (2)
wled00/FX.h (1)
377-378: Approve MODE_COUNT bump and effect registration
Manual check confirms highest FX_MODE_ ID (218) + 1 == MODE_COUNT (219), and addEffect(FX_MODE_RAINBOW_SHIMMER), its mode_rainbow_shimmer() implementation, and _data_FX_MODE_RAINBOW_SHIMMER are all present.wled00/FX.cpp (1)
10707-10708: No changes needed: FX_MODE_RAINBOW_SHIMMER and MODE_COUNT are correct
FX_MODE_RAINBOW_SHIMMER is defined as 218 and MODE_COUNT is 219 (highest ID + 1), matching WLED conventions.
wled00/FX.cpp
Outdated
| uint16_t mode_rainbow_shimmer() { | ||
|
|
||
| unsigned counter = (strip.now * ((SEGMENT.speed >> 2) + 2)) & 0xFFFF; | ||
| counter = counter >> 8; | ||
|
|
||
| uint32_t shimmerSpeed = 100 + (255 - SEGMENT.custom2) * 40; //ranges from 100-10260ms | ||
| uint32_t shimmerSize = (SEGMENT.custom3 * SEGLEN / 2 >> 5) + 1; | ||
| uint32_t cycleTime = (255 - SEGMENT.custom1) * 150 + shimmerSpeed; | ||
|
|
||
| uint32_t percCycle = strip.now % cycleTime; | ||
| float shimmerIndex = (float)percCycle / (float)shimmerSpeed * (SEGLEN + 2*shimmerSize); | ||
|
|
||
| shimmerIndex -= shimmerSize; | ||
|
|
||
| // reverse direction of shimmer | ||
| if(!SEGMENT.check1) { | ||
| shimmerIndex = (float)SEGLEN - shimmerIndex; | ||
| } | ||
|
|
||
|
|
||
| for (unsigned i = 0; i < SEGLEN; i++) { | ||
| // Standard rainbow effect. | ||
| uint8_t index = (i * (16 << (SEGMENT.intensity / 29)) / SEGLEN) + counter; | ||
| SEGMENT.setPixelColor(i, SEGMENT.color_wheel(index)); | ||
|
|
||
| //shimmer logic | ||
| float distFromShimmerCenter = fabsf(shimmerIndex - i); | ||
| // Only process pixels that are within the shimmer's range. | ||
| if (distFromShimmerCenter < shimmerSize) { | ||
| SEGMENT.setPixelColor(i, color_blend(SEGMENT.getPixelColor(i), 0xFFFFFF, (uint8_t)(255 * (1.0f - (distFromShimmerCenter / shimmerSize))))); | ||
| } | ||
| } | ||
|
|
||
| return FRAMETIME; | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Fix shimmer length scaling, avoid floats in hot loop, and make Reverse semantics intuitive
- shimmerSize scales up to ~4× SEGLEN (at custom3=255), often turning the whole segment white. Clamp to [1..SEGLEN] (or a saner fraction) and compute with integer math.
- The per‑pixel float math (fabsf, division, mul) inside the loop is costly on ESP8266/ESP32. Use integer math.
- Reverse currently uses “if (!check1) reverse”, which is counter‑intuitive for a checkbox labeled “Reverse”.
Apply:
- uint32_t shimmerSpeed = 100 + (255 - SEGMENT.custom2) * 40; //ranges from 100-10260ms
- uint32_t shimmerSize = (SEGMENT.custom3 * SEGLEN / 2 >> 5) + 1;
- uint32_t cycleTime = (255 - SEGMENT.custom1) * 150 + shimmerSpeed;
-
- uint32_t percCycle = strip.now % cycleTime;
- float shimmerIndex = (float)percCycle / (float)shimmerSpeed * (SEGLEN + 2*shimmerSize);
-
- shimmerIndex -= shimmerSize;
- // reverse direction of shimmer
- if(!SEGMENT.check1) {
- shimmerIndex = (float)SEGLEN - shimmerIndex;
- }
+ // speed: higher custom2 -> faster
+ uint32_t shimmerSpeed = 100u + (255u - SEGMENT.custom2) * 40u; // 100..10260 ms
+ // length: map to [1..SEGLEN] (or change divisor to limit max size, e.g. SEGLEN/3)
+ uint16_t shimmerSize = 1u + ((uint32_t)SEGMENT.custom3 * SEGLEN >> 8);
+ if (shimmerSize > SEGLEN) shimmerSize = SEGLEN;
+
+ // frequency: gap between flashes
+ uint32_t cycleTime = (255u - SEGMENT.custom1) * 150u + shimmerSpeed;
+ uint32_t percCycle = strip.now % cycleTime;
+
+ // progress within the active flash window [0..shimmerSpeed)
+ uint32_t tInWindow = percCycle % shimmerSpeed;
+ uint32_t travel = SEGLEN + shimmerSize * 2u; // allow off-edge fade-in/out
+ uint32_t shimmerIndex = (uint64_t)tInWindow * travel / shimmerSpeed;
+ int32_t center = (int32_t)shimmerIndex - shimmerSize; // center of the flash
+ // Reverse = checked -> flip direction
+ if (SEGMENT.check1) center = (int32_t)SEGLEN - center;
@@
- for (unsigned i = 0; i < SEGLEN; i++) {
+ for (unsigned i = 0; i < SEGLEN; i++) {
// Standard rainbow effect.
uint8_t index = (i * (16 << (SEGMENT.intensity / 29)) / SEGLEN) + counter;
SEGMENT.setPixelColor(i, SEGMENT.color_wheel(index));
//shimmer logic
- float distFromShimmerCenter = fabsf(shimmerIndex - i);
- // Only process pixels that are within the shimmer's range.
- if (distFromShimmerCenter < shimmerSize) {
- SEGMENT.setPixelColor(i, color_blend(SEGMENT.getPixelColor(i), 0xFFFFFF, (uint8_t)(255 * (1.0f - (distFromShimmerCenter / shimmerSize)))));
- }
+ int32_t d = abs(center - (int32_t)i);
+ if (d < (int32_t)shimmerSize) {
+ uint8_t w = (uint8_t)(((uint32_t)(shimmerSize - d) * 255u) / shimmerSize);
+ SEGMENT.setPixelColor(i, color_blend(SEGMENT.getPixelColor(i), ULTRAWHITE, w));
+ }
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| uint16_t mode_rainbow_shimmer() { | |
| unsigned counter = (strip.now * ((SEGMENT.speed >> 2) + 2)) & 0xFFFF; | |
| counter = counter >> 8; | |
| uint32_t shimmerSpeed = 100 + (255 - SEGMENT.custom2) * 40; //ranges from 100-10260ms | |
| uint32_t shimmerSize = (SEGMENT.custom3 * SEGLEN / 2 >> 5) + 1; | |
| uint32_t cycleTime = (255 - SEGMENT.custom1) * 150 + shimmerSpeed; | |
| uint32_t percCycle = strip.now % cycleTime; | |
| float shimmerIndex = (float)percCycle / (float)shimmerSpeed * (SEGLEN + 2*shimmerSize); | |
| shimmerIndex -= shimmerSize; | |
| // reverse direction of shimmer | |
| if(!SEGMENT.check1) { | |
| shimmerIndex = (float)SEGLEN - shimmerIndex; | |
| } | |
| for (unsigned i = 0; i < SEGLEN; i++) { | |
| // Standard rainbow effect. | |
| uint8_t index = (i * (16 << (SEGMENT.intensity / 29)) / SEGLEN) + counter; | |
| SEGMENT.setPixelColor(i, SEGMENT.color_wheel(index)); | |
| //shimmer logic | |
| float distFromShimmerCenter = fabsf(shimmerIndex - i); | |
| // Only process pixels that are within the shimmer's range. | |
| if (distFromShimmerCenter < shimmerSize) { | |
| SEGMENT.setPixelColor(i, color_blend(SEGMENT.getPixelColor(i), 0xFFFFFF, (uint8_t)(255 * (1.0f - (distFromShimmerCenter / shimmerSize))))); | |
| } | |
| } | |
| return FRAMETIME; | |
| } | |
| uint16_t mode_rainbow_shimmer() { | |
| unsigned counter = (strip.now * ((SEGMENT.speed >> 2) + 2)) & 0xFFFF; | |
| counter = counter >> 8; | |
| // speed: higher custom2 -> faster | |
| uint32_t shimmerSpeed = 100u + (255u - SEGMENT.custom2) * 40u; // 100..10260 ms | |
| // length: map to [1..SEGLEN] | |
| uint16_t shimmerSize = 1u + ((uint32_t)SEGMENT.custom3 * SEGLEN >> 8); | |
| if (shimmerSize > SEGLEN) shimmerSize = SEGLEN; | |
| // frequency: gap between flashes | |
| uint32_t cycleTime = (255u - SEGMENT.custom1) * 150u + shimmerSpeed; | |
| uint32_t percCycle = strip.now % cycleTime; | |
| // progress within the active flash window [0..shimmerSpeed) | |
| uint32_t tInWindow = percCycle % shimmerSpeed; | |
| uint32_t travel = SEGLEN + shimmerSize * 2u; // allow off-edge fade-in/out | |
| uint32_t shimmerIndex = (uint64_t)tInWindow * travel / shimmerSpeed; | |
| int32_t center = (int32_t)shimmerIndex - shimmerSize; // center of the flash | |
| // Reverse = checked -> flip direction | |
| if (SEGMENT.check1) center = (int32_t)SEGLEN - center; | |
| for (unsigned i = 0; i < SEGLEN; i++) { | |
| // Standard rainbow effect. | |
| uint8_t index = (i * (16 << (SEGMENT.intensity / 29)) / SEGLEN) + counter; | |
| SEGMENT.setPixelColor(i, SEGMENT.color_wheel(index)); | |
| // shimmer logic | |
| int32_t d = abs(center - (int32_t)i); | |
| if (d < (int32_t)shimmerSize) { | |
| uint8_t w = (uint8_t)(((uint32_t)(shimmerSize - d) * 255u) / shimmerSize); | |
| SEGMENT.setPixelColor(i, color_blend(SEGMENT.getPixelColor(i), ULTRAWHITE, w)); | |
| } | |
| } | |
| return FRAMETIME; | |
| } |
|
Thanks for contributing. |
|
I understand the concern about floats; it was a deliberate decision to balance the desire for a smooth transition of the "shimmer" without obfuscating the code with a pseudo implementation of float using bit shifts into an arbitrary index that would be remapped to physical indices. In my testing the performance limitation was vastly dominated by the strip bus speed rather than limits on computational power, a 1000 pixel strip was still achieving 40 FPS, which was the same as the unmodified rainbow cycle. If you would prefer the latter implementation I will refactor. I originally looked at implementing as an overlay, or how effects could be combined to achieve the same result, but I could not find documentation or effects designed for use that way. Considering 0.16 isn't released yet and there is no documentation outside of the comments on the PR, this would appear to be the first effect dependent on the new layer implementation; I admit I am playing catchup here. If the effect is intended to be secondary to a primary effect, adding color palette support is the natural extension of that line of thought. On the topic of non-standalone effects, from a user perspective there should be a way in the UI to mark an effect as secondary or describe how effects should be combined with other. Maybe a way to default a primary and secondary overlapping effect? Otherwise, the user might be left wondering the purpose or how to use a secondary effect. |
|
floats are only available on ESP32 and S3, not on S2, C3 or ESP8266. So no floats unless absolutely necessary or for things that run only once in a while, it also increases code size. |
|
As requested, removed float, added Fx and Bg colors. Removed the rainbow section for use as overlay. |
There was a problem hiding this comment.
Actionable comments posted: 2
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (2)
wled00/FX.cpp(2 hunks)wled00/FX.h(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- wled00/FX.h
🧰 Additional context used
📓 Path-based instructions (1)
wled00/{*.cpp,!(html_*)*.h}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Use spaces (2 per level) for C++ source and header files
Files:
wled00/FX.cpp
🧠 Learnings (5)
📓 Common learnings
Learnt from: DedeHai
PR: wled/WLED#4798
File: wled00/FX.cpp:7531-7533
Timestamp: 2025-08-26T11:51:21.817Z
Learning: In WLED PR #4798, DedeHai confirmed that certain gamma-related calls in FX.cpp/FX_fcn.cpp/particle systems are intentional for effect-level shaping (e.g., brightness curves, TV sim, Pride 2015 pre-mix), distinct from final output gamma. Do not flag or remove these in future reviews; add comments when feasible to clarify intent.
Learnt from: netmindz
PR: wled/WLED#4728
File: wled00/FX.h:378-378
Timestamp: 2025-06-15T09:59:52.720Z
Learning: In WLED's FX.h, MODE_COUNT represents the highest FX_MODE_ ID + 1, not the total count of FX_MODE_ definitions. This is because some effects may have been removed but their IDs are not reused, creating gaps in the numbering sequence. MODE_COUNT is used for array bounds and range checking.
Learnt from: netmindz
PR: wled/WLED#4728
File: wled00/FX.h:378-378
Timestamp: 2025-06-15T09:59:52.720Z
Learning: In WLED's FX.h, MODE_COUNT represents the highest FX_MODE_ ID + 1, not the total count of FX_MODE_ definitions. This is because some effects may have been removed but their IDs are not reused, creating gaps in the numbering sequence. MODE_COUNT is used for array bounds and range checking.
📚 Learning: 2025-06-15T09:59:52.720Z
Learnt from: netmindz
PR: wled/WLED#4728
File: wled00/FX.h:378-378
Timestamp: 2025-06-15T09:59:52.720Z
Learning: In WLED's FX.h, MODE_COUNT represents the highest FX_MODE_ ID + 1, not the total count of FX_MODE_ definitions. This is because some effects may have been removed but their IDs are not reused, creating gaps in the numbering sequence. MODE_COUNT is used for array bounds and range checking.
Applied to files:
wled00/FX.cpp
📚 Learning: 2025-08-26T11:51:21.817Z
Learnt from: DedeHai
PR: wled/WLED#4798
File: wled00/FX.cpp:7531-7533
Timestamp: 2025-08-26T11:51:21.817Z
Learning: In WLED PR #4798, DedeHai confirmed that certain gamma-related calls in FX.cpp/FX_fcn.cpp/particle systems are intentional for effect-level shaping (e.g., brightness curves, TV sim, Pride 2015 pre-mix), distinct from final output gamma. Do not flag or remove these in future reviews; add comments when feasible to clarify intent.
Applied to files:
wled00/FX.cpp
📚 Learning: 2025-08-28T08:09:20.630Z
Learnt from: mval-sg
PR: wled/WLED#4876
File: wled00/xml.cpp:0-0
Timestamp: 2025-08-28T08:09:20.630Z
Learning: The WLED codebase has opportunities for refactoring hardcoded array bounds (like the "15" used for DMX channels) to use sizeof(array)/sizeof(array[0]) for more maintainable code, but such changes should be done consistently across the entire codebase in a dedicated refactoring effort.
Applied to files:
wled00/FX.cpp
📚 Learning: 2025-09-02T19:42:57.475Z
Learnt from: freakintoddles2
PR: wled/WLED#4904
File: wled00/FX.cpp:3915-3930
Timestamp: 2025-09-02T19:42:57.475Z
Learning: WLED wled00/FX.cpp::mode_percent — For time-based options (% of Minute/Hour/Day), behavior is clock-like: at rollover (elapsed==0) intentionally show SEGLEN lit for one tick to represent completion, then move to 1 LED at the next second. This is by design (not a progress bar) and should not be “fixed”.
Applied to files:
wled00/FX.cpp
🧬 Code graph analysis (1)
wled00/FX.cpp (1)
wled00/colors.cpp (2)
color_blend(11-21)color_blend(11-11)
🔇 Additional comments (1)
wled00/FX.cpp (1)
10703-10703: Verify FX id alignment and default placementRegistration looks good next to Rainbow Cycle. Please double-check that:
FX_MODE_SHIMMERis defined in FX.h at the intended id andMODE_COUNTcovers it (remember MODE_COUNT is highest id + 1).- No gap overlaps another effect’s id.
If you want, I can scan FX.h to confirm.
wled00/FX.cpp
Outdated
| static const char _data_FX_MODE_SHIMMER[] PROGMEM = "Shimmer@Speed,Frequancy,Size,,,Reverse;!!;sx=231,ix=221"; | ||
|
|
There was a problem hiding this comment.
Typo in user-facing metadata and unclear parameter mapping
- “Frequancy” should be “Frequency”.
- Labels imply: Speed = speed slider, Frequency = intensity slider, Size = custom1, Reverse = check1. That matches the code. Fix the typo to avoid UI polish regressions.
Apply:
-static const char _data_FX_MODE_SHIMMER[] PROGMEM = "Shimmer@Speed,Frequancy,Size,,,Reverse;!!;sx=231,ix=221";
+static const char _data_FX_MODE_SHIMMER[] PROGMEM = "Shimmer@Speed,Frequency,Size,,,Reverse;!!;sx=231,ix=221";📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| static const char _data_FX_MODE_SHIMMER[] PROGMEM = "Shimmer@Speed,Frequancy,Size,,,Reverse;!!;sx=231,ix=221"; | |
| static const char _data_FX_MODE_SHIMMER[] PROGMEM = "Shimmer@Speed,Frequency,Size,,,Reverse;!!;sx=231,ix=221"; |
🤖 Prompt for AI Agents
In wled00/FX.cpp around lines 581-582, the user-facing metadata string contains
a typo: "Frequancy" should be "Frequency"; update the PROGMEM string to correct
the spelling while keeping the existing parameter order and mapping
(Speed,Frequancy,Size,,,Reverse) unchanged so Speed maps to speed slider,
Frequency to intensity slider, Size to custom1 and Reverse to check1.
|
thanks for the update, good progress.
also you did not add palettes as requested, please do so and we have the basic structure for this effect. What I would later also like to add is:
with palettes added, a user can create a custom palette to only partially apply the shimmer and with modulators it may look a lot better when not using it as an overlay. Please let me know if (and at what point) this gets beyond the time you are willing to invest. |
| segmentSize=SEGLEN; | ||
| } | ||
|
|
||
| uint32_t shimmerSpeed = 100 + (255 - SEGMENT.speed) * 40; // [100,10300] |
There was a problem hiding this comment.
if you change 100 to 200 in this line, no overflow and you do not have to limit the length.
| // slightly dangerous, but shimmer index is bounded to be safe | ||
| uint32_t distFromShimmerCenter = abs((int32_t)shimmerIndex - ((int32_t)i << 8)); | ||
| if (distFromShimmerCenter < (shimmerSize<<8)) { | ||
| SEGMENT.setPixelColor(i, SEGMENT.color_from_palette(255-(distFromShimmerCenter / shimmerSize),false,PALETTE_SOLID_WRAP,0)); |
There was a problem hiding this comment.
No, I didn't. It is up to the user to select a color palette that blends (or contrasts if desired) with the selected background color. Any additional blending between layers will happen using #4658 Enhanced Layering facilities. Adding additional blending into the loop could limit the number of ways the effect could be used.
There was a problem hiding this comment.
without the gradient, there are other effects that do almost the same.
There was a problem hiding this comment.
Then what exactly should the gradient be with?
There was a problem hiding this comment.
as it was, plus the suggestions: cosine, sub-gradiens, perlin
There was a problem hiding this comment.
I wrote this effect to be a simple, lite occasional flair to a relatively plain and simple back round, as every other effect had too much noise, randomness, and was always visible. Adding all of those gradients are well outside the scope of what I want my effect to be. I think we have very different ideas of what this effect should be so I am going to close this and just maintain my own fork. I'm happy to adapt to make my effect more versatile and flexible, but I am not going to make something I don't want.
2 participants
Adds a new effect called Rainbow Shimmer effect. It takes the Rainbow Cycle effect but adds a white flash that runs across the segment. Adjustable frequency of flash, direction, speed of flash, and size.
Summary by CodeRabbit