A few posts ago I mentioned some work was needed to migrate our Dasher 360 shaders to the latest version of the Forge viewer (or the one after it). This work is now complete, so I can share a few thoughts and comments on what was needed to make this happen.
Before doing that, though, I need to thank Elias Cohenca for his invaluable help during this process: I can honestly say that without his help the migration would either not have happened or would remain a work in progress. Thanks, Elias!
Firstly, it’s important to note that even if you have custom shaders, there’s a reasonable chance that they will just work when moving from WebGL 1 to 2 (or from v7.9 or below of the Forge viewer to v7.10 or above). There are syntactical changes between WebGL 1 and 2, but in the Forge viewer these are handled by some pre-processor directives that auto-translate GLSL 1.00 to GLSL ES 3.00 (i.e. WebGL 1 to 2). So it’s very possible to write shaders that work with both WebGL 1 or 2 (in fact this is now the case with Dasher 360).
The big stumbling block we hit – other than using a reserved word (“texture”) to name a variable in our point cloud shader, which we talked about last time – was the need to use BufferGeometry for our shaders: the WebGL2Renderer requires that you use BufferGeometry rather than the older, slower Geometry implementation. Frankly this was really just “the right thing to do”, and something we’d been meaning to make happen for some time. The move to WebGL 2 just forced our hand somewhat.
Some miscellaneous points that came up during the migration:
- You will need to set the isPoints property on your BufferGeometry object to true.
- You will also need to set attributes on the material, even if this may now seem redundant (this was fixed in three.js r72, and the Forge viewer is still on r71).
- We’ve tried to reduce the amount the geometry gets recreated, so we now allocate a dedicated “hover node” that is used to highlight sensors that are hovered over.
- We copy the sensor’s properties across to the hover node – which is at the end of the array, and so gets drawn last, i.e. on top – when the originating sensor is hovered over.
- We also hide the originating sensor, although this isn’t strictly needed (as the sensor dots are slightly transparent, there is a minor visual difference if we don’t do this).
- All of this has greatly reduced our need to move data around inside our buffers, which certainly feels like the right thing to do.
We’re still testing the updated shader implementation in our staging environment: so far it appears to work well in v7.10 and v7.11. It also works in older versions only supporting WebGL 1 such as v7.6, which is helpful because we’re seeing some strange visual artefacts when we isolate objects per-level in versions from v7.7 onwards: we need to understand what’s happening there and fix the core issue before we’re able to move off that version and pick up the latest & greatest.
Some breaking news: I had such a good time in the UK, this week, that I’ve decided to head back across for the upcoming Forge Accelerator that’s being held in our Soho office on February 17-21. I don’t think I’ll manage to spend the whole week, but it will I’m sure be another fun (and productive) event.