You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have played with saving widget states into Jupyter notebooks for this purpose, and it works! I think this would be awesome for sharing interactive examples with 3D data from HOOMD and freud.
However, the data used by plato's pythreejs backend may be much larger than necessary, resulting in enormous file sizes of the resulting notebooks and slower loading / rendering. I built a notebook that visualizes a couple scenes like the one shown below (significantly smaller than most simulations in our group) and it ballooned to hundreds of megabytes, which isn't conducive to web viewers or file sharing. In my understanding, a vastly smaller data format could be used for most scenes without any loss of quality.
For example, the current sphere geometry class builds a buffer geometry of vertices and per-vertex colors, storing (N * 64 * (3 + 4)) float values for the vertex positions and colors alone, not counting however many integer face indices are required to construct the convex hull. I think this could be replaced by a SphereBufferGeometry that stores only positions, radii, and per-shape colors, resulting in the storage of something more like (N * (3 + 1 + 4)) values. That's a savings of about 56x for spheres, not counting the unnecessary storage of face indices.
I am not completely certain if this will work, but I believe it's worth trying with the Sphere class to see how it performs.
The text was updated successfully, but these errors were encountered:
This seems like a good idea, but if we run into any limitations in three.js, it may be worth revisiting (once more) the idea of making our own plato.js library and ipywidgets-based adapter that is able to use the exact same schema as plato itself.
In case anyone ends up tackling this later, @bdice pointed to a page in the pythreejs documentation that may be helpful. Making a proper ipywidgets extension as the documentation seems to imply would be necessary involves a lot of work as far as I recall, but it may be worth it at some point.
It's possible to embed pythreejs 3D visualizations into documentation with Sphinx: https://pythreejs.readthedocs.io/en/stable/examples/Geometries.html
I have played with saving widget states into Jupyter notebooks for this purpose, and it works! I think this would be awesome for sharing interactive examples with 3D data from HOOMD and freud.
However, the data used by plato's pythreejs backend may be much larger than necessary, resulting in enormous file sizes of the resulting notebooks and slower loading / rendering. I built a notebook that visualizes a couple scenes like the one shown below (significantly smaller than most simulations in our group) and it ballooned to hundreds of megabytes, which isn't conducive to web viewers or file sharing. In my understanding, a vastly smaller data format could be used for most scenes without any loss of quality.
For example, the current sphere geometry class builds a buffer geometry of vertices and per-vertex colors, storing
(N * 64 * (3 + 4))
float values for the vertex positions and colors alone, not counting however many integer face indices are required to construct the convex hull. I think this could be replaced by a SphereBufferGeometry that stores only positions, radii, and per-shape colors, resulting in the storage of something more like(N * (3 + 1 + 4))
values. That's a savings of about 56x for spheres, not counting the unnecessary storage of face indices.I am not completely certain if this will work, but I believe it's worth trying with the Sphere class to see how it performs.
The text was updated successfully, but these errors were encountered: