Pixel simulation order shows in certain situations

[JonasBergholz]

Hey all,

Suspected Problem:
I have found an oddity which is that in certain situations you can really see that the pixels are simulated from the top left row by row to the bottom right.

Suggested Solution:
I suggest adding a mode in which the calculation of each pixel is done in a random order per frame.

What I did:
I have found this by building a kind of a star in circular gravity mode. I build a sphere of uranium (20 pixels in diameter) in the center, put a ton of sand around it and melted all.

What went right:
Due to the molten glass it now acts pressure on the uranium which further heats it up. Pressure rises until a certain point depending on mass, which in tern limits the heat. Because its cooler and lower pressure on the outside, convection start kicking in and it now builds out a corona around the sphere with moving convection columns and all, which is amazing.

What went wrong:
The Problem though is, that it doesnt happen equally around the whole sphere, but in the bottom right corner it only rises and travels around the sphere to the top left, where you have convection collums pointing to the top left corner of the screen.

What I expected that would happen:
Basically that the convention columns in the top left would form all the way around and grow radially out or that the particles rise and fall all the way around equally.

[jacob1]

This is an interesting phenomenon that I've seen before, and it would be nice to fix it. It's actually not related to particle order though, but rather a quirk of the air sim. The air sim is always calculated top to bottom, left to right, and sometimes shows some biases like this.
Particles are not simulated based on screen position, but rather by particle ID. You can go into debug mode (press 'd') and see the particle IDs. If you were to totally mix this up via MIX tool, you would see it has the same behavior.

Related issue, which includes some code that probably fixes it: #668

[tugrul512bit]

Randomly computing particles would add more latency not just because of random number generation but the non-cached access to particles. Cache line is wasted and the CPU has to do more branch failure due to randomness.

Perhaps one day someone adds an optional "parallelized" computation mode that takes input particles and writes result to a different output array without messing with other particles' computation order. This way whole screen would be computed with equal importance and the performance would be a lot higher like you could even go 3D with the simulation. Maybe some new particle type called PAR_WTR could be a water that is computed in parallel and things like that and if it catches attention maybe other developers do same for their own particles too. But it looks so hard that a complete-rewrite of program is easier?

At the cost of performance, a simulation error can be decreased by going forward in simulation, then reversing back to starting frame, all particles should be same place. By subtracting the difference between forward+backward and the original coordinates, you get the simulation error (i.e. the bias of serial computation). Then you can simply add -1/2 of the error amount for the step and go forward again in time-step to fix particles' positions. But this is like 1/3 or 1/2 performance. Too bad for a non-scientific simulation.