ArthurBrussee
Joined 8 years ago
Karma
43
Submissions
25
Member since
Nov 22
Recent submissions
Comment · 2 years ago
Comment · 2 years ago
That was in some way the original motivation for the project!
I think if you are reconstructing your own data the algorithm better just work, without input, ideally.
But, imagine you could add in generated videos. Lay down a camera path, tell it what to generate, and add it to the reconstruciton. A brush stroke one might say ;)
Comment · 2 years ago
Yes :) But it will take a while!
Comment · 2 years ago
The input to this are two things - images, and camare poses. The camera poses tell you where each camera was in 3D space (and some of its properties).
The training takes this information, to make a 3D model out it, visually matching all your photos.
COLMAP can still be quite expensive & a hassle sadly, order half hour, as opposed to seconds. There are modern alternatives like https://lpanaf.github.io/eccv24_glomap/, or even deep learning based systems like https://github.com/naver/dust3r
This is definitely still a big blocker to adoption. The goal is to get to a more all-in-one system. The splatting optimization can also help align cameras, if they don't start out entirely random, so any system to quickly provide a good "initial guess" will help here. At least for mobile devices, initialization from ARCore / ARKit poses should be enough.
Keep an eye out :)
Comment · 2 years ago
Not a dumb question! This first version is still mainly targetted at people who are in this area and generate some excitement, I do hope to make this more accesible though!
The inputs are 1. images 2. with a pose. The usual way to get poses for your images is https://github.com/colmap/colmap.
The output is a 3D model. Specifically a "Gaussian Splat", which is a sort of fuzzy point cloud. There are some tools out there to view & edit these (besides Brush), eg. https://playcanvas.com/supersplat/editor.
Comment · 2 years ago
Yeah this is the next big challenge. There's some ideas what to do, but one step at a time!
Comment · 2 years ago
Devices & operating systems! Windows/Mac/Linux, AMD / nvidia / built-in GPUs, Android/iOs, or running in a browser context.
My bad, I really bungled the original tweet the title is from :)
Comment · 2 years ago
I'm a bit out of the loop on async runtimes. I know Tokio is of course the big on, but, that seemed much to heavy to just run some tasks, and isn't very WASM compatbile afaik.
Otherwise there's smol, and maybe others? Would love to hear what a good web WASM compatible async framework is nowadays!
Comment · 2 years ago
Love to hear it!! Most viewers take some shortcuts, like only sorting every so often, it's good to hear the difference is noticable :)
Training a splat requires a lot less setup with this, but does still require running COLMAP(https://github.com/colmap/colmap) first, which is still a big barrier... one thing at a time!
Comment · 2 years ago
Its really the latest incarnation in the field of Photogrammetry https://en.wikipedia.org/wiki/Photogrammetry - aka, converting 2D images / video to 3D data.
Imagine one of those house tours on Zoopla on steroids, or street view but smoother.
Comment · 2 years ago
I think the title is taken from my original tweet which I really bungled, my bad :) Hopefully the readme does a better job!
Comment · 5 years ago
Wonder if Rust should pursue this as a feature as well - might be hard to promise this as a fully fledged feature when Cranelift comes into the picture though. Still it could be possible to ship a linker that can handle cross-compiling like Zig and compile C code with LLVM irregardless of the Rust backend.
Either way, hope Zig and Rust continue to inspire each other a bit!
Comment · 7 years ago
Is it me or are those results somewhat underwhelming if anything? Dedicated hardware for a 2x speedup at best, tossup for most results, and only competes in some categories. Not to be just a NVIDIA fan here, surely there is value in dedicated training hardware, but just surprising that benefit isn't bigger!
Comment · 7 years ago
If every single transaction in the world was Bitcoin it would still be a _ridicilous_ amount of energy by several orders of magnitude. It is totally, fundamentally, broken
Hard at work to make performance better - the "main" kernels are at least as fast as gSplat, so now need to remove other overheads.
That, and make splatting train more efficiently in general, lots of compute is wasted on small steps.
Ps: the web version takes a minute to warm up and is generally slower, do try a native version if you haven't yet!