WebAssembly (WASM) Version

[philworthy]

Hi. Love your work on this Vasco! I'm curious if you have considered/tried to implement a WebAssembly version of this and whether that is likely to have significant speed gains when working with very large graphs (many thousands of nodes).

I saw some others have tried similar things for the classic d3-force library Eg. d3-wasm-force

[vasturiano]

Hi @philworthy thanks for reaching out!

I haven't tried to do a WebAssembly version, I think it would be a nice idea to experiment with. I think it probably be more applicable to the d3-force-3d lower level pure JS module, that takes care of the force simulation engine.

I'm thinking that would mostly only help in cases where the bottleneck is in the forces simulation, for scenarios with complex computationally expensive forces. If the bulk of the load is in the rendering section (due to high volume of objects in the scene), that would possibly not make a large difference.

[philworthy]

Thanks @vasturiano yep that makes sense (sorry I should have posted this over in the d3-force-3d repo). We'll definitely have a lot of nodes (many 1000's) in our sim, all with radial and manybody forces... so sounds like this might be something worth us investigating. Hey while I have you on the subject, when you render many nodes using Three.js, are you using instanced meshes? (or are we sending thousands of draw calls to the GPU?)

[vasturiano]

@philworthy you bring up a good question concerning instanced meshes. The lib is not currently using it because:

• Links generally constitute the bulk of the number objects in graphs, so that's where the rendering bottlenecks tend to be. The links are rendered as Line objects, and I don't think there is an equivalent InstancedLine class that could be used for it. Furthermore, the lines tend to have mostly different inner geometries (different lengths, curvature, etc), which makes the grouping by equivalent geometry something with very low aggregation ratio typically.

• As for the default nodes (spheres), we also tend to have different sizes, but what's more is that they share materials for performance optimization (for example two spheres with the same color will be applied the same material object). And the instanced mesh docs mention that materials should not be shared. So possibly grouping by node wouldn't work either.

What you could possibly do is use InstancedMesh in the custom nodeThreeObject method. That would theoretically give you the optimization you're looking for, but I haven't actually tried.

[philworthy]

Thanks @vasturiano Hey would you be interested in consulting with us to create a react component based on this library, but with a few specific additional needs?

[vasturiano]

@philworthy appreciate you reaching out. I would like to help, but not sure I have enough bandwidth at the moment to focus on a specific project. In any case, have you seen react-force-graph?

[philworthy]

Ok, that's a shame :( but I totally understand. Yep, we're using react-force-graph. Just the developer is new to d3-force, and to three.js (and 3D in general in fact) so there's a big learning curve. Thanks anyway. Appreciate you taking to time to respond so quickly.

[jesus4497]

What you could possibly do is use InstancedMesh in the custom nodeThreeObject method. That would theoretically give you the optimization you're looking for, but I haven't actually tried.

Hi @vasturiano ! Quick question, could you provide an example on how to implement the mentioned above? 🙏 I have been trying to do it but no luck