If you mean to optimize for fastest code, I just did it and it does seem to be more fluid, it still slows down a tiny bit but not as noticeable, and it also seems faster when the saber is not ignited.
And lockups look very cool!
Here’s a link to a video:
I was not really able to reproduce the boot up problem. However, I have tweaked the command delays a bit, so maybe it works better now?
I also recommend trying the v4.1 arduino-proffieboard plugin from the beta stream, as that seems to fix some problems for me.
I also put the display on the HF (high frequency) loop which should make it run smoothly even with lots of neopixels. (Of course, that could mean that the neopixels gets slower, we’ll see…)
The boot up issue got resolved when I turned optimizations on.
I’ll try v4.1 when I get a chance.
I’m down to help make the file.
Cairon59 actually did help out and we have one animation based on his work. Having more would be great if you’re interested though.
Thanks Profezzeron, I see later in the discussion that this is underway. I’m afk now but will take a look at the specs in the discussion and start building a blender demo file next week. I only have a 2.2 board so can’t test the files.
found this tutorial and project file that will help
Crystal 1
I’ll remake the crystal tutorial and include it in the distributed Blender file with a more user friendly controls for people unfamiliar with blender.
Started working in the crystal generator. I have two gnereators. The one on the right is the new one and is much simpler. I still want to work on the shader for the crystal.
Very cool. 
Hello, sorry for the lack of response, I’m full time on the renovation of my new house (+ my job).
@ez-set , it’s good to see that, you can find some textures I’ve used for the shading here:
Looking forward to seeing the result
I have been doing some crystal studies that might interest you
They are fully procedural, done in Houdini, so the color, shape, and details can be generated based on a random seed or user input. It would be very easy to throw them in a crystal chamber and render out a bunch of different crystal variations thanks to the procedural aspect.
With this I would render out all possible combinations, and then host them online and let people pick through them with a nice gui, rather than them having to learn houdini. But of course that file can be made public too
Very nice!
It’s good to have the sources for future modifications, or rendering in different sizes. Ideally we’d use blender, or something else open-source so that anybody could do the rendering, but beggars can’t be choosers.
The way I did if for our existing crystals was to render the crystal in Red, Green and Blue (but everything else identical) and then just interpolate between the images to get other colors.
Although now that I think about it, I realize that interpolating might not be the best since it won’t generate colors like full-brightness yellow… I should probably do the interpolation in HSL instead.
Not sure if the colors for these crystals is that simple though, I mean, a red crystal could have different colors in it too.
If we render out full values for R G and B, we should be able to just add the values to get full values for the inbetween colors, as long as we work in linear colorspace. Same way the idea of 1 1 0 turns on the red and green in a pixel to make Yellow.
The way I would approach it is to use a hue shift tool however, sliding all the color values together towards the desired color. Then you just render once and edit afterwards. And no worries about flakes or detail colors not matching, as they are all adjusted at the same rate: orange with red details becomes blue with green details for example.
Houdini does have a free version, not open source, that anyone could use. The learning curve is slightly higher than blender though. If you want the renders or the files though, I’d be happy to move forward with this
I’ll make a quick edit for the Hue shift to demonstrate what I mean. Be right back
Don’t mind the compression from the GIF formatting, I’m surprised it even got the color range that it did…
Adjusting just the Hue allows to change the colors of the image, while remaining relatively photoreal. Hence only needing one render, and no funky math. At least for the crystal layer
If the crystal is on it’s own layer, then that should work well.
The final layering will need to use as few layers as possible, so the script may need to composite the crystal into the crystal chamber, but that’s standard alpha-blending stuff.
First foray into this.
Reading documentation, getting things together in prep.
Unfortunately, make is failing?
c++ -pthread -MD -ggdb -O2 -c -o cpqoi.o cpqoi.cc
In file included from cpqoi.cc:1:
./pqoi.h:312:18: warning: unknown attribute 'optimize' ignored [-Wunknown-attributes]
312 | __attribute__((optimize("Ofast"))) uint16_t* read(uint16_t* out, uint16_t* end) {
| ^~~~~~~~~~~~~~~~~
./pqoi.h:339:18: warning: unknown attribute 'optimize' ignored [-Wunknown-attributes]
339 | __attribute__((optimize("Ofast"))) uint16_t* read(uint16_t* out, uint16_t* end) {
| ^~~~~~~~~~~~~~~~~
./pqoi.h:362:16: warning: default member initializer for non-static data member is a C++11 extension [-Wc++11-extensions]
362 | State state_ = AT_START;;
| ^
./pqoi.h:363:25: warning: default member initializer for non-static data member is a C++11 extension [-Wc++11-extensions]
363 | uint8_t previous_byte = 0;
| ^
./pqoi.h:684:14: warning: default member initializer for non-static data member is a C++11 extension [-Wc++11-extensions]
684 | int state_ = 0;
| ^
./pqoi.h:964:12: error: unknown type name 'constexpr'
964 | static constexpr uint32_t onecc(char c, int shift) {
| ^
./pqoi.h:964:30: error: expected ';' at end of declaration list
964 | static constexpr uint32_t onecc(char c, int shift) {
| ^
| ;
./pqoi.h:1010:19: warning: default member initializer for non-static data member is a C++11 extension [-Wc++11-extensions]
1010 | int dithertmp = 0;
| ^
./pqoi.h:817:7: error: use of undeclared identifier 'mkditherMatrix'
817 | mkditherMatrix(0,0,1);
| ^
./pqoi.h:821:13: error: use of undeclared identifier 'ditherMatrix'
821 | V += (ditherMatrix[x & 3][y & 3] - 7.5)/ 16.0;
| ^
In file included from cpqoi.cc:8:
./pamstream.h:122:14: warning: default member initializer for non-static data member is a C++11 extension [-Wc++11-extensions]
122 | bool first = true;
| ^
./pamstream.h:123:13: warning: default member initializer for non-static data member is a C++11 extension [-Wc++11-extensions]
123 | int xsize = 0;
| ^
./pamstream.h:124:13: warning: default member initializer for non-static data member is a C++11 extension [-Wc++11-extensions]
124 | int ysize = 0;
| ^
./pamstream.h:125:13: warning: default member initializer for non-static data member is a C++11 extension [-Wc++11-extensions]
125 | int depth = 0;
| ^
./pamstream.h:126:14: warning: default member initializer for non-static data member is a C++11 extension [-Wc++11-extensions]
126 | int maxval = 0;
| ^
In file included from cpqoi.cc:9:
./pqoiml.h:82:16: warning: default member initializer for non-static data member is a C++11 extension [-Wc++11-extensions]
82 | bool has_fps = false;
| ^
./pqoiml.h:87:21: warning: default member initializer for non-static data member is a C++11 extension [-Wc++11-extensions]
87 | size_t total_size = 0;
| ^
./pqoiml.h:75:10: warning: 'auto' type specifier is a C++11 extension [-Wc++11-extensions]
75 | for (auto g : gotos) {
| ^
./pqoiml.h:75:17: warning: range-based for loop is a C++11 extension [-Wc++11-extensions]
75 | for (auto g : gotos) {
| ^
./pqoiml.h:78:35: warning: range-based for loop is a C++11 extension [-Wc++11-extensions]
78 | for (const std::string& chunk : chunks) {
| ^
./pqoiml.h:320:10: warning: 'auto' type specifier is a C++11 extension [-Wc++11-extensions]
320 | for (auto line : lines) {
| ^
./pqoiml.h:320:20: warning: range-based for loop is a C++11 extension [-Wc++11-extensions]
320 | for (auto line : lines) {
| ^
./pqoiml.h:325:10: warning: 'auto' type specifier is a C++11 extension [-Wc++11-extensions]
325 | for (auto line : lines) line.dump(f);
| ^
./pqoiml.h:325:20: warning: range-based for loop is a C++11 extension [-Wc++11-extensions]
325 | for (auto line : lines) line.dump(f);
| ^
./pqoiml.h:330:10: warning: 'auto' type specifier is a C++11 extension [-Wc++11-extensions]
330 | for (auto line : lines) {
| ^
./pqoiml.h:330:20: warning: range-based for loop is a C++11 extension [-Wc++11-extensions]
330 | for (auto line : lines) {
| ^
22 warnings and 4 errors generated.
make: *** [cpqoi.o] Error 1
Maybe I can’t just do this in MacOS Terminal.
I think you might need a newer compiler.
What is “c++” ?
I guess g++ is an older GNU compiler on my Mac. I changed the Makefile to use clang++ instead and it works now.
So I guess c++ is the system’s built-in compiler and works better with newer C++ code. Not totally sure why g++ was a problem, but swapping it out made everything compile fine.
CXXFLAGS= -std=c++11 -pthread -MD -ggdb -O2
LDFLAGS=-lm -lpthread
COMMON=pqoiml.h pamstream.h stb_image_write.h
HOST_COMMON=
BINARIES=cpqoi dpqoi
all: $(BINARIES)
clean:
rm $(BINARIES) *.o *.d
$(BINARIES) : % : %.o $(COMMON) $(HOST_COMMON)
clang++ $(CXXFLAGS) -o $@ $< $(LDFLAGS)
-include *.d
Without -std=c++11, the compiler defaults to an older version of C++ ?
Next, I thought I’d try to make a pqf. I only have an 8 pixel blade PCB at the moment.
Source input file is a 128x4.
Do I scale to 8x1 now? Or leave it and let the display controller handle that?
Like doing:
#ifdef CONFIG_PRESETS
InMemoryDisplay<1, 8, 3> test_display;
StandardColorDisplayController<1, 8> test_display_controller(&test_display);
NAME_INSTANCE(test_display, TEST);
Preset p1[] = {
{ "Font", "",
StylePtr<DisplayStyle<TEST>>(),
"imgtest"},
};
When trying to use cpqoi directly on the input.bmp — even with -x 1 -y 8 flags — the tool fails with this error:
./cpqoi -x 1 -y 8 input.bmp > output.pqf
Executing: ffprobe -i "$FILE" 2>&1 | sed -n 's@.*Video:.*, \([0-9.]*\) fps,.*@\1@gp'
Executing: ffprobe -i "$FILE" 2>&1 | sed -n 's@.*Video:.*, \([0-9.]*\) fps,.*@\1@gp'
FPS: 0:0
Executing: ffmpeg -i "$FILE" -an -pix_fmt yuv444p -f yuv4mpegpipe - | y4mtopnm -P | 1
Failed to read PAM header.
Sorry, I literally just jumped into this and should be in bed instead.
I’ll come back after reading up some more.
That’s true, I should fix that in the Makefile.
No scaling happens after it’s been made in a PQF.
The display code is able to use black bars around an image/animation, but it cannot scale it, and it cannot show anything that is bigger than the display, so scaling needs to happen before or while creating a PQF.
cpqoi has no such flags, in fact it has no flags at all.
It takes one or two arguments.
First is an input file (an image, a movie or pqoiml file)
Second is optional, but if present it should be a command (or pipeline of commands) to handle the scaling of the image(s) using netpbm commands.
The other failures might simply be because it will try to use -x as the filename.