I am using multiple views (each has its own viewer), and animating objects within those views in sync (motion in each view is the same). For each animation frame, I have to update each of the viewers with the same change (setting node transforms, replacing meshes etc). This means that as the number of views increases, the amount of time to push the changes to all the views also scales linearly. This slows down the simulation significantly. Anyway to share the model between the views and only make the changes to this shared model?
1 Like
Unfortunately, it is currently not possible to share a model between different HOOPS Communicator webviewer instances, though that is a feature that is currently under consideration as far as I know.
In the absence of this feature my suggestion would be to sample the animations and perform the update (e.g. setting the matrices) at a lower frequency when there are multiple windows and performance is an issue.
1 Like
Hey Guido … from a performance issue perspective … I think the solution for having multiple views would be to take the OffscreenCanvas + Web Worker route. This way, one can run each instance of the WebViewer in its own Web Worker thread.
Cranking Up Performance in Graphics Intensive Web Apps and Games (Google I/O '17) - YouTube - Useful presentation of OffscreenCanvas from Google IO
When running on its own exclusive worker thread, the performance is supposed to be closer to native.
Here is a three.js article on this
https://threejs.org/manual/?q=offscreencanvas#en/offscreencanvas
poking around in the hoos_web_viewer.js and engine-wasm.js files … it was pretty easy for me to get HC to work inside of a Web Worker. But I could only get to the point where the Axes and View Cube on an empty model were shown. I am encountering some errors related to master model key etc when I try to load a model. My changes are not yet sufficient to address all the issues.
I am positive that if I had access to the actual non-minified code, things could be much easier. DOM access is baked into HC all the way to engine-wasm.js … and these need to be rearrange to work with the OffscreenCanvas object.
This could be a great addition to the capabilities of HC. I am hoping I can get some help from TS3D experts on this.
I have HC rendering on a Web Worker thread using OffscreenCanvas successfully. To get the basic thing working … it took me 2 days of minified code. I sincerely wish TS3D would make it a legitimate feature that is supported out of the box.
Still some work to port mouse events to the worker thread etc.
Three.js has a very well explained article on how to make it work with OffscreenCanvas.
https://threejs.org/manual/#en/offscreencanvas
Lot of the steps hold for HC as well. But it is a bit unfortunate that Three.js is ahead on this compared to a paid/licensed tool like Hoops Communicator.
The off screen rendering feature demonstrated by Three. js is a fundamental capability. My guess is that because HC is based on the feature of streaming asynchronous loading, it brings ultra-high rendering performance to HC, but it also makes handling interactive operations in Web Worker particularly complex.
1 Like
It is indeed true, that we have a much more complex feature set than three.js, with our built-in support for streaming, incremental updates, server-side rendering but also more complex operators that are leveraging SVG and the DOM in general more heavily. Not to mention that the core of the engine is written in C++ and uses WebAssembly. It would certainly require quite a bit of work, to fully support offscreen rendering in HOOPS Communicator (and my understanding is that even in three.js, enabling this mode is just experimental).
Having said that, we are looking at offscreen rendering, in particular in the context of better supporting multiple views of the same model on a page (which is the primary use-case here) so keep an eye on our roadmap in this regard.
1 Like
