My V2+ has been acting up, so I purchased a V3. I’m copying over my favorite patterns, but I notice that the previews and running of some of the patterns are very different between the two, such as Block Reflections, Crossfading, and Edgeburst. Does the V3 process some of these patterns differently?
There’s a couple things that might be going on. I’ll discuss factors that might affect LEDs+Previews, vs ones that probably only affect previews.
LEDs + Previews
To compare a pattern on v2 vs v3 apples to apples, first check:
- You have the same number of LEDs connected and configured for both
- The LEDs are the same speed and type, like both are either Neopixel or APA102
- The global brightness slider and “Limit Brightness” in the Settings tab are set similarly
- You have the color order setting set the same (or otherwise matching your LEDs). Check that the live preview matches your LEDs.
After this, some patterns may be affected by how the v3 is much faster than the v2.
Most of the default included patterns render similarly (but smoother, at a higher framerate) on the faster v3, because they were built around references to time() or delta. In fact, a couple default v2 patterns were updated on v3 to make them render more consistent across the two.
Patterns that inherently depend on a random flickering without adjusting for framerate (for example, function render(i) { hsv(0, 0, random(1) < .1) }) will definitely appear differently between the two. This can be seen in the “firework” patterns.
Off the top of my head, the three you mention (unless you meant Shimmer Crossfade 2D instead of Crossfading) shouldn’t have been affected.
Shimmer Crossfade would have been affected: its method is to pick probabilistically for each pixel which of the two modes to use, so the shimmer will be faster.
Differences between Embedded and Generated Preview Images
The preview contained in the .epe file is the last one rendered on the board that exported it (or you can patch one in with a text editor - the .epe file is just JSON). These previews are what you see in the pattern library or when you first import a pattern, however, the preview will be regenerated when a pattern is first edited on a board. Here are some reasons you might see a different preview on the board vs what you saw in another place:- The total pixelCount from Settings tab might be different. Preview images contain the first 100 pixels worth of preview data. For something symmetric like Edgeburst, Wizard or I would be sure to set the number of pixels in Settings to 100 before generating the preview image and exporting the .epe file so that people get a good sense of the mirror symmetry. If you loaded Edgeburst on board that’s set up for 200 pixels or more, the preview image will only render the first 100, and you won’t see the mirror at all.
- The timing issues noted above: If the preview image was generated on a v2 and the pattern contained significant processor-speed dependent code, the preview may re-render differently on v3.
- Preview images are generated after applying the global brightness slider and “Limit Brightness” from Settings, so intensity differences may be due to that. I know that on many of my LEDs, I like to work on patterns with the brightness dialed way back. As a side effect, my previews are dim while working on patterns. I try to remember to turn everything back up before exporting so the preview looks good.
- On rare occassion, Wizard and I “cheat” by cherrypicking the best preview, or by generating a preview that uses special parameters to communicate the essence. For example, the code for Crossfading in the pattern library intentionally specifies 3 modes shown for 5 seconds per mode. This is nice in real life. However, preview images only loop through ~6 seconds of rendered pattern content, so to generate a preview image that faithfully shows crossfading 3 modes, I patched a special preview into the final .epe that was hand-tuned for about 2 seconds per mode so that it looped smoothly.
- If a preview depends on sensor input but you don’t have a sensor board connected, it will of course render differently. All the sound-dependent patterns shipped with v3 now include generators that will simulate sound if no sensor board is detected, so you still get something useful at a party when you just start the default set with a big “Shuffle All”.
Hope this helps! If you’d like, send me some code you’re pretty sure is rendering differently and I’ll take a look.
1 Like
No, that all sounds perfectly reasonable.
However, do you recall which default V2 patterns were rewritten first the V3? I may have overwritten some of them by copying over code from my V2 and the patterns website.
Pretty much all of them. If they have a lot of comments they are likely the v3 version. You could compare them to this repo which is very close to the final v3:
1 Like
I think I figured out the problem. I’ve been copy/pasting the code into Notepad++, and apparently that alters the formatting to some extent. I’m now using the Export/Open File commands instead.
And since my second V3 came in, I can replace the ones I corrupted on the first one.
1 Like
!
Found a weird difference. The same code for Cube Fire 3D between two V3s renders differently. Settings are the same, near as I can tell. Not a big deal, just thought I’d share.
1 Like
Hi - Thanks for looking. I just compared the code and it should execute identically, so I think what’s actually going on is that the two 1D previews were generated from fairly different points in the overall cycle of the animation. It’s built on several combinations of sine waves with different periods, so you can get very different previews generated at different times.
1 Like
I think I found a reason. Xorcery 2D/3D is rendering differently as well, but I noticed my first V3 (Left) shows the editor as 2D, and the second (Right) shows 1D. Is there a way to change the Dimension of the Editor, or is that baked into the chip?
1 Like
Do you have a 2D map (the same map) on both?
It’s the exact same code. It also happens on Cube Fire 3D and Spotlights / Rotation 3D. The first V3 switches to 2D, while the second V3 stays in 1D.
It would be nice to switch the Dimension of the preview, to see what it would look like on my strands.
@Mebejedi,
Check the “Mapper” tab, this is where pixels can be mapped to 2D or 3D coordinates. You probably have a 2D map installed on only one of your Pixelblazes. The mapper code/array is independent of the pattern code, and will apply/interact with whichever pattern is loaded.
A pattern can implement any combination of render, render2D, and render3D. You can see this in your screen shot of xorcery. It implements all 3 variants and will render with no pixel map, a 2D map, or a 3D map.
If a 2D map is installed, it will prefer render2D, likewise for 3D. If no map is installed with the same dimensionality, it will default to render if available.
The patterns you mention will work with or without a pixel map, but will render differently depending on if a map is installed, and of course the layout of the installed map.
Since a pixel map defines coordinates for each pixel index, the preview (which is a 1D representation based on pixel index) will depend very much on how those coordinates are arranged.
2 Likes
Yep, that was it. Thank you very much. 
2 Likes