Direction of the project

[MarcusAndreasSvensson]

Hey,

I'm currently playing around with this implementation and one of the things I really enjoy is the API, how familiar it is when you have previously worked with Three.js.

I'm curious about the general goal and direction of this project. Seeing as this is built similarly to Three.js it would make sense (and pretty low friction) to provide an interface between meshes and splats, but I see no dependency to three in the project.

Is the goal to keep this as its own separate thing or do you have thoughts of integration into other libs?

[dylanebert]

Hello! My original goal with this library is a very lightweight gaussian viewer wrapper so that I can plug it into gradio and enable a gaussian splatting viewing on machine learning demos. It has a grown from there, but I think focusing on solely gaussian splatting makes sense for this library.

An advantage of having no three.js dependency is that this library is very lightweight, only 213Kb unpacked, where three.js is 31.3Mb unpacked.

I think the mkkellogg library will suit your needs better if you want to mix splatting with traditional rendering in a larger project.

[MarcusAndreasSvensson]

Thanks for taking the time! I see, makes sense and yes, three.js certainly adds quite some heft!

I suspected this might be the case, so I was thinking about how one could add this as a lightweight dependency to any render pipeline.

If you could access the rendered pixels and a depth map frambuffers/textures it should (in my mind) be fairly straight forward to blend the resulting images after the render passes, albeit not the most efficient solution. Maybe this has a use in machine learning applications as well?

Not sure if this idea is holds up in practice though.

[dylanebert]

It sounds like a good idea to me! If someone figures out how to keep this library fast and lightweight, with plugging it into other libraries, I definitely wouldn't be opposed.