We have a feature in Dasher called "kiosk mode". It basically takes control of the browser to run a sequence of operations that show people how Dasher works. I published a series of posts a couple of years ago that explain a bit about how we implemented it.
One of the issues in kiosk mode is knowing when Forge viewer operations – such as view transitions or state restorations – are complete. Until recently the code just checked the viewer's progressbar property, to see whether its value was close to 100 or not. This wasn't ever a very good approach, because the progress bar is used multiple times when re-rendering a view of a model, especially when applying ground shadows or reflections. But it worked well enough because we could start the next operation in our sequence of features to show off even if the rendering was underway. Lately, though, I've found it isn't working well, probably because the relative time it takes to perform certain operations has changed. So anyway, I started looking for another way of waiting for the viewer to be in "idle" state (a term we use a lot in desktop tools such as AutoCAD and Revit).
I came across two pointers to Autodesk.Viewing.FINAL_FRAME_RENDERED_CHANGED_EVENT, an event that's fired by the Forge viewer when the very last frame of an animated sequence (such as a view transition) has been rendered. The first was by Jan Liska on an internal Slack discussion; on Googling it I found that Adam Nagy had mentioned it in a blog post on the Forge blog with respect to viewer state restoration. Anyway, it turned out to be exactly what we needed (thanks, Jan and Adam!). Kiosk mode now waits a little longer between operations, but it does now show features off more effectively. Definitely a positive change. If you need to find out when things have completed inside the Forge viewer, be sure to check out this event and the code in Adam's post.
On a largely unrelated note, I've been using the downtime imposed by Covid-19 event cancellation to work on getting our new timeline component integrated into Dasher. For a while I found that it was behaving poorly inside kiosk mode – which had me looking into how I can control target framerates in Pixi.js-based components – but I then realised it was my own fault: when integrating the new timeline I'd mistakenly wired it up to our old "playback manager" code that tries to control the timeline's playback, inadvertently competing with the timeline's own built-in playback management.
Once I'd disabled the old playback manager things started working super-smoothly. Here's an animation of various time-series graphs – and some surface-shading – being animated at 16x via the new timeline:
The timeline still has a few kinks we need to iron out before we can push it live, but it's looking really promising. I'll for sure post again once we have something people can take for a spin and give us feedback on.
Leave a Reply