Loss not going down and renders look bad about gaussian-splatting

[dllu]

OK, after 50k iterations with the above settings, it is looking pretty reasonable.

[Snosixtyboo]

That makes it hard... I would suggest reducing the scaling, initial, and final position learning rate, e.g., divide them all by a factor 3 for starters.

[Snosixtyboo]

Hi, would it be possible to get access to the dataset (your colmap input) so we can get an idea what's going on?

[dllu]

Unfortunately the input dataset contains confidential proprietary data.

[Snosixtyboo]

40

We'd be happy to hear how it goes! There's a few things that could happen at this scale we did not observe, our evaluation was mainly room-sized or smaller outdoor areas. The fact your first run ended in 6 minutes on what seems like an urban data set seems curious.

[dllu]

reducing learning rate

Thanks for the pro tip!

Indeed, with the following parameters

--iterations 50000 --scaling_lr 0.0002 --rotation_lr 0.0002 --position_lr_init 0.00003 --opacity_lr 0.01 --feature_lr 0.001

it seems the loss is decreasing healthily. Let's see what it ends up at after 50k iterations!

[grgkopanas]

How is it number-wise compared to the taichi implementation? Do you think there is room for improvement considering the hyper-params?

[Snosixtyboo]

OK, after 50k iterations with the above settings, it is looking pretty reasonable.

Great, thanks for letting us know!

A short word on urban data sets (there is also a section on it in the FAQ): The approach considers the distribution of the cameras and scales the learning rate accordingly (spatial_lr_scale). I.e., Gaussians will move faster if the cameras are 1,000 units apart than if it's only 1, since by default we have no absolute scaling information for how much one unit is. If cameras are distributed over kilometers or on a long straight path, you can therefore mess it up quite a bit, since Gaussians will zip off quickly. If you know the extent of your dataset, then extending the approach such that it sets learning rates from this information should be trivial (constant * spatial_lr_scale / real_extent). Or, if the coordinates of the point data sets are always at a known size (1unit = 1m), then replacing spatial_lr_scale by a constant should also do it.