Making a Better Particle Simulation in C++ (Part 2)

Finally this video is done. Still have more particle ideas planned for the future though! Fluid simulation is next.
I also should be getting a new microphone soon so video quality will improve

A helpful comment about my multithreaded code, by @thesquee1838 :
"One thing to clarify is that std::move just casts to an r-value, which allows for move semantics if they are implemented for a type. You mention perfect forwarding but for that you would use std::forward() with a templated function of that takes in the r-value type T&&. Perfect forwarding has more to do with how types are converted when passed to a function (look up reference collapsing), and allows for the type that is passed in to be conserved and not changed."

Music:

About this video/for the algorithm:
I improve my particle simulation, made in C++ and SFML, by optimizing collision and adding multithreading, and also implement obstacles and the ability to generate images.

Timestamps:
0:00 Intro
0:45 Recap of Part 1
1:27 Optimising Collisions
5:31 Making Images
8:00 Multithreading
12:20 Obstacles
17:28 Obstacle Issues
21:07 Improving Rendering
23:18 Final Result & Outro

[josealvim]

One thing I love about circular particle simulations like those is the topological defects that arise when they all settle down, you can clearly see them around 24:17 just before the transition; just like microcrystaline grains, you can see the domain walls separating the big cells where the spheres are tightly packed. Very cool.

[ratchetfreak]

instead of storing a list of particle indices for each grid you can sort the particles by grid index with counting sort. That way all particles in each gridcel are contiguous and you are not thrashing the cache looping over all particles in each cell.

[Tkk-im]

your ability to get so far into a project without quitting is insane

[thesquee]

Cool video!

One thing to clarify is that std::move just casts to an r-value, which allows for move semantics if they are implemented for a type. You mention perfect forwarding but for that you would use std::forward() with a templated function of that takes in the r-value type T&&. Perfect forwarding has more to do with how types are converted when passed to a function (look up reference collapsing), and allows for the type that is passed in to be conserved and not changed.

Also some additional things to think about for speedups is focusing on making the size of all structs/classes as small as possible; if you can compress the size of the particle for instance you will likely see even more speedups due to better cache coherence. For me this had one of the largest effects on my particle simulator.

[splits]

oh wow, wow this looks like great quality and very inspiring, im blessed to have found this!

[SobTim-euxu]

Damm, man, your vid is fire
Love that, I need to subscribe
Will love to watch more parts of it, and wish you good at your exams
You deserve more views and subs

[nuke_clear]

I was recommended your first video just now and I really enjoyed watching both the parts. I would love to finish my particle physics code some day but I always get too busy with my main projects. Looking forward to more such content.

PS : It's nice to find somebody who watches the exact same youtubers I do lol

[hmmmidkkk]

Danm man you're underrated af, I'd love to see more of your work ❤

[nezznh]

Awesome video, the algorithm has blessed me with a W. As for the multithreading performance issue, I may have a solution you can try when you're feeling up to it : Your problem right now is that you have a fixed thread assignment structure, which effectively means that in geometrically diverse simulations (that being the beginning simulation you showed), it's still effectively up to one thread to simulate MOST of the particles. Add that to the extra overhead required to assign, mutex and synchronize the threads themselves, a greater performance overhead is expected.

What I advice you try doing (im an amateur myself, so this may not work, but it sounds right) is looking over the cells in the grid themselves to determine how many particles are in them. Then, u can use define a constant that determines how many particles each thread can handle at a time (this constant will take some tweaking to figure out, dw if you dont get it right away), and then assigning as many cells as you can to each thread to fill up that count. This means that one thread will get a bunch of empty cells which will take him the same amount of time to calculate out as one thread that handles one cell that has TONS of particles. Essentially, you are making sure that a bunch of threads handle a bunch of particles, while the other threads handle the almost empty parts of the simulation. This means you are actually parallelizing things correctly, and it should mean that they will take roughly the same amount of time to finish all the calculations. Hopefully, this should work!

I'm really impressed with the project so far, it's motivated myself to code in C++ again. Keep it up man!

[EmergentLifeArchive]

Amazing work! Im absolutly implementing all your optimization techniques!! You should look into SOA (Structure of arrays) vs AOS (array of structures). Its a small optimization boost due to its cashe performance increase, which I found quite useful when making my particle systems!

[sohailu]

Great video man! Please dont make the music too loud.

[paulkanja]

you can probably save like a millisecond if you make the grid cells overlap by the diameter of the particles, , that way, you only need to check one cell

[RichardEricCollins]

Nice work. Would love Jason from c++ weakly to have a look at your threading code. He could well make it go a lot faster. He's like a c++ whisperer. Also watch out for thread::yeald. I've been stung by it in the past. Just sleeping the thread for 10ms can be a lot faster. 🤷‍♂️

[Adamplaysbadminton]

Great vid! You should make some tutorials for people optimistic about coding 😁

[DYELB]

12:07 “Calamitas even.” wait, say that again…

[wedding_photography]

Next: move the simulation to the GPU. For 1 million particles.

[hugocusson]

you should think about mixing your audio and compressing the music track so it doesnt distort as much and allows more room to your voice

[Flourish]

I wonder if a hexagonal (or, really, offset square) grid might be more efficient, since then each cell would only have 6 neighboring cells instead of 8.

[williamist]

i did not see your first video but particle simulations are pretty cool...

[tacolands]

Is that a picture of the hugs building by lumphini park in bangkok?