SOGS compression keeps coming up here as a go-to method for reducing Gaussian Splatting model sizes. I put together a deep dive into how SOGS actually works under the hood, with some practical insights on how it can be used in production.
The article stays fairly high-level, but I'm happy to dive into specifics in the comments. I learned quite a bit from implementing my own version of SOGS compression.
For some time I have a feeling that Apple actually IS playing the hardware game in the age of AI. Even though they are not actively innovating on the AI software or shipping products with AI, their hardware (especially the unified memory) is great for running large models locally.
You can't get a consumer-grade GPU with enough VRAM to run a large model, but you can do so with macbooks.
I wonder if doubling down on that and shipping devices that let you run third party AI models locally and privately will be their path.
If only they made their unified memory faster as that seems to be the biggest bottleneck regarding LLMs and their tk/s performance.
It's weird to see only one word at the time. I don't think this reflects my true typing speed as I have a tiny pause to read the word once it shows on the screen. On the other hand, I'm able to read multiple words ahead as long as I can see them and naturally remove the pause.
Working on a platform to host and share 3D Gaussian Splatting models.
The key goal is that the creators of 3DGS models can use Blurry as a powerful tool to build the 3D experience that is performant, simple, and aesthetically pleasant for end users (viewers).
3DGS models can be shared via a link or embedded on a website, notion, etc..
I'm not convinced that there is one generalised solution to sync engines. To make them truly performant at large scale, engineers need to have deep understanding of the underlying technology, their query performance, database, networking, and build a custom sync engine around their product and their data.
Abstracting all of this complexity away in one general tool/library and pretending that it will always work is snake oil. There are no shortcuts to building truly high quality product at a large scale.
> think of your queries as super human friendly SQL
> The database? Massive amounts of data boiled down to unique entries with probabilities. This is a simplistic, but accurate way to think of LLMs.
I disagree that this is the accurate way to think about LLMs. LLMs still use a finite number of parameters to encode the training data. The amount of training data is massive in comparison to the number of parameters LLMs use, so they need to be somewhat capable of distilling that information into small pieces of knowledge they can then reuse to piece together the full answer.
But this being said, they are not capable of producing an answer outside of the training set distribution, and inherit all the biases of the training data as that's what they are trying to replicate.
> I guess my point is, when you use LLMs for tasks, you're getting whatever other humans have said. And I've seen some pretty poor code examples out there.
Yup, exactly this.
More formats are definitely on the roadmap. At first I'd like to add full support for higher order of spherical harmonics and then I wanted to take a look at other methods, too. Maybe 2DGS and/or SMERF would make sense for comparison purposes.
Explanation of controls makes sense, too. I'll add that.
Regarding WebXR, that's currently not on my roadmap. However, if the demand is there I'd consider adding it
- Adding better controls (and an explanation) makes sense!
- Good job discovering the L control. That's actually something that's not supposed to be public. I use that tool to find the correct orientation of splats before publishing them. But once I find those values saved in the DB, there's no use for that tool anymore. When I make it available to the users I'll defo make the UX clearer.
Thanks!
At the moment the intent is to showcase what the method is capable (and what isn't).
One of my future plans is to extend it to other methods than just gaussian splatting so that we can compare methods across a wide range of captures with varying light conditions, different materials, etc..
100%. I really think Gaussian Splatting as a method can offer a lot, but it's also not powerful enough (yet) to be useful. Specifically editing and relighting GS models is rather clunky.
I think SplatGallery is an exploration of how people use the technology and what can it be useful for today and what is the next step.
I'm currently working on splatgallery.com. It's supposed to be a curated community driven gallery of the best 3D models reconstructed from photos or videos. It's currently in a very early stage and I am still adding more models to it hoping it'll gain traction from the community :)
Thanks! I was initially pondering calculating the moves on the server and storing the state regularly in the DB, so the animation can run forever. But in the end simplicity won and I just reset the animation every 24h. The cube is usually "as scrambled as it gets" after 20-30 moves anyway.
I'll defo take a look at playing the next song after the first one ends. I had this functionality at some point, so if it is not working it's defo a regression. Will fix it.
Btw, I am happy you love the music! It's royalty free music I added there, but I should add some credits as it seems many people listen to it. Since I published this last week it used up all my 100GB Vercel allowance and I had to move it to Google Storage.
Thanks for checking it out! Do you have some suggestions for a more interesting background? I was thinking about adding some planets/galaxies to keep it in the sci-fi and space theme.
And thanks for the bug report. I'll take a look at it this weekend!