An interesting thing happened when I tried Dasher 360 with the latest production version of the Forge viewer: no sensor dots appeared. As Dasher without sensors is a glorified 3D viewer, this was a bit of a problem.
Digging into things a little, I worked out that our custom WebGL shader wasn’t working properly in this latest version.
At this point I reached out to my friend Elias Cohenca in Tel Aviv for a quick sanity check: he confirmed that this latest version of the Forge viewer is now defaulting to WebGL 2.0. This was confirmed in the Forge viewer change-log, where there was this innocent-looking line-item:
This version will attempt to initialize using a WebGL2 and will fallback into WebGL1.
As far as I can tell this means that WebGL 2 will be used if your device supports it, not based on whether your application has been migrated to support WebGL 2 (although for all I know there may also be a setting somewhere to force the use of WebGL 1).
Anyway, after realising this was at the root of my problem, Elias pointed out a way to understand what was wrong with this shader. If you declare a DEBUG_SHADERS a DEBUG_SHADERS variable in your host application, setting it to true – I did in mine by simply having var DEBUG_SHADERS = true; inside a <script> element on the main page – then the Forge viewer will dump some extra output to the developer console when it fails to compile your shader. Happy days!
Debugging shaders can be tricky at the best of times: the errors being given by any compilation process can be obscure, but GLSL seems to take this to a whole new level. During various points of the debugging process we went from being told there was an assignment issue to a type mismatch, until I eventually twigged that we had a variable called ‘texture’, which is a reserved word in GLSL 3.0. Aha!
Fixing this meant that the shader now displays sensor dots inside v7.10 of the Forge viewer, but unfortunately there are still some quirks around the access and use of display attributes for each item in our point cloud (which is what we use to display our sensor locations). This means that a) they’re not all in quite the right place and b) they don’t have the right behaviour when you hover over them.
For instance, the inner colour never changes on hover…
… unless you hit the sensor or equipment dot that is first in their respective lists – with index of 0 – which causes the whole of the list to have their inner colour change.
Reading between the lines on this behaviour, it’s probably because I need to migrate the vertex attributes to use Vertex Array Objects. We’ll see.
All of this will take some more digging into, and no doubt a call or two with Elias, who I’m going to have to fill with beer the next time I see him. On a closing note, Elias’s 3D printer project has been featured on Hackaday, so I may have to pick his brain quickly before he retires as a Maker celebrity creating 3D printed music full-time.
Assuming we manage to make some progress, in the coming days I should be able to share some more specifics about what else you might need to change to have your own custom shaders work properly in the Forge viewer v7.10 and above. (Oh, and if you’re asking yourself “do I have custom shaders?” then you almost certainly don’t. You’d remember.)
