When I permute the gaussians dimension, the rendered result will be noisy, why?

[dongzhuoyao]

"This novel rasterization algorithm brings multiple benefits. First, our accu-mulated blending process is insensitive to the order of Gaussian points. Thisproperty allows us to avoid the impact of the random order of Gaussian pointson rendering"

I mainly permute the _xyz, _cholesky, _features_dc in GaussianImage_Cholesky, this is roughly the function(I only use your overfitting technique(fittign 8 parameters), I didn't use any compression technique):

with permute:

without permute:

[djx99]

Yes, I've run into this problem as well.
At the end of training, when I shuffle the Gaussians (get_xyz, get_cholesky_elements, get_features) and render the image, the same problem occurs. Here is my code and results.

I have found that when the number of num_points is small, there is no problem even if it is disrupted; however, when the number of num_points is large (downsampling by a factor of 2, kodak dataset, 50,000 points), the problem occurs.

I suspect it's a problem with the rasterize_forward_sum() function, and I don't think it should have done=true inside the loop for(int b = 0; b < num_batches; ++b), which would cause it not to be able to get into the loop for(int t = 0; (t < batch_size) && ! done; ++t) when b > 0. So some Gaussians aren't being trained.
The only time done can be set to true is if next_T <= 1e-4 occurs in 3D.

Please correct me if I'm wrong.

[dongzhuoyao]

For me, even when #GS=1000 in CIFAR10, I still got quite noisy image after permutation.

looking forward to the authors' reply, I need this permutation invariance featrure for my own project

[Downchuck]

I'm not clear here but this is where I paused:

            if colors.shape[-1] == 3:
                rasterize_fn = _C.rasterize_sum_forward
            else:
                rasterize_fn = _C.nd_rasterize_sum_forward

I think that's where it toggles between the two render modes - with the permutations using the nd logic which does not hit that code block you're looking at.

The data structures aren't abstracted much for manipulation; I don't see anything wrong with your code off-hand, but I have had to manually update other variables to make things work. For example, actually just scaling up requires resetting the tile bounds per #8

[djx99]

The rendering process in the paper is not dependent on the ordering (aka the rasterize_sum_forward function), it's just the weighting of all covered ellipses. So when I upset the order of the ellipses, I should get the same rendering result. But when I use the above code to disrupt before executing the rendering program, the rendered image is changed