It was a perfect match. I get to use one of my primary tools, the awesome Unity engine, to develop a handful of projects for a permanent installation at a Long Island state park. Some projects were slated for either a rack mount Windows machine or a BrightSign.
I love the idea of a BrightSign, a small device without the overhead of Windows to drive some interactive content. I did some simple tests and gave the OK to use these as playback devices for a number of projects for this installation. In Unity, the ease was to switch platforms from Standalone to WebGL simply by clicking a button (sort of).
Of course there would be some tinkering of settings and some content adjustments to get it to work just like a native standalone application. But if I could build it and run it from the Chrome browser on my machine, then what would be this issue of running it on a BrightSign which uses a modified, older version of Chromium. Let’s do this.
The first issue that was solved by the standard web (Stackoverflow) search was to change the publish setting -> Gzip to fix the BrightSign from loading the Unity WebGL instance.
Wait. There’s another issue. Why aren’t the external PNGs or MP4s loading up? I like to load graphics, videos, and text externally. I’ve been doing it for decades; starting withXML and now of course, it’s all about a good ‘ole JSON file. BrightSign was thrilled to load the external JSON file, but not so much the external media files.
Hours (maybe days) were spent on debugging with the thought that it must be a file system thing but when you have a deadline, you get to a point where you have to change course. I tried to embed the media files, but Unity WebGL ain’t having that.
Here’s a solution that failed -> export the media as image sequences, then bring the sequences into Unity as an animation. Nice! After pushing the WebGL files to the BrightSign, the animation sequences did some world class flickering. Not so nice! I debugged and the BrightSign engine did not like the RGB Compression on the image sequence. This was starting to make me unhappy. I tried to adjust it to a compression scheme to make the BrightSign happy, but Unity took forever during the bundling and compression process and that caused Unity to “not respond”.
One of the many things I’ve learned over the years is that there are many paths to get to a destination. When it became obvious, it was revealed that the Unity -> WebGL -> BrightSign work path was not going to work. What could work? In BrightAuthor, the tool used to develop and push ‘apps’ to BrightSign players, there is an option to build an HTML presentation. So here I am doing the ‘pivot’ from a Unity WebGL app to a Hypertext Markup Language, (HTML) + Cascading Style Sheets (CSS) + Javascript (how did this get built in 10 days?) project.
Related Posts
June 26, 2023
Controlling the Light, part 2
My introduction to DMX and controlling light really started back in the late…
April 11, 2023
Back to One
During the heart of winter, I finally made the switch to using Next.js coupled…
March 23, 2023
Controlling the Light, part 1
At the start of any project, I review the requirements and ask questions. What…
Nice Ron! I love the Brightsign units. They are very versatile units that can do a lot with just a little love. I have not gone down the HTML road yet with them, but have done many touch and button activated presentations and video walls with them for several years now.