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).

Unity Code Screen
BrightSign XT4

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

Privacy Preference Center