should all of this be in one script ? i have big troubles understanding where the diffrent parts are supposed to be
@gcruzatto2Ай бұрын
This may be a dumb question, but have you thought about simulating it by generating a 2D map for the gravitational field of the entire space, then have each body ping that map instead of multiple bodies? This would reduce the amount of times a body has to ping its surroundings to one per frame. The body would need to extract the "incline" of that field (if it was a height map) at the body's location to figure out the direction. Generating the full field might be expensive though, so I'm not sure how this would compare
@DeadlockCodeАй бұрын
There are no stupid questions. You’re suggestion is great in some cases - mostly when the distribution of bodies is uniform or when you only want a crude approximation. The most severe problem is probably when the bodies are very non-uniform (imagine two galaxies far far away). Then if you were to represent this 2D map as a texture/grid, you would have to make it extremely high resolution to capture any near field interactions which would be bad for computation time and memory consumption. This is why it makes so much sense to use a quadtree/octree which can sparsely approximate the field, focusing on where it matters and ignoring where it doesn’t. Of course, Barnes-Hut is not the be-all and end-all of this sort of algorithm but it is a really strong starting point.
@uberscottАй бұрын
I'm really enjoying your content.
@mrpocockАй бұрын
Would it be possible for you to describe your improved algorithm? I had a quick look at the source, but it would be fab to hear you explain it and the motivation behind it.
@1e1001Ай бұрын
for anti-aliasing you could probably check how SDF rendering works, since your distance comparison is pretty much an SDF already
@kebmanАй бұрын
(x - x₀)² + (y - y₀)² + (z - z₀)² = r² --- Look ma, no polygons! :D
@kebmanАй бұрын
Take a look at POV-Ray spheres. I think they're the most awesome things in the whole of computer graphics. Bcos they're freaking ROUND! xD
@farkarfАй бұрын
So this is a 2D simulation. I'm not sure how it's done in 3D, but it must be considerably more challenging. The QuadTree, for one, does not efficiently upgrade to its 3D version, an OctTree. As you increase the no. of dimensions from 2 to 3, an even larger proportion of the volume of the unit cube lies outside the unit sphere (of diameter 1). That cruft on the corners of the voxels, if you will, makes nearest neighbor searches not so efficient. A better data structure might be a kd tree, but the disadvantage there is that its tricky or near impossible to update.
@farkarfАй бұрын
Nice repo, btw! In Rust to boot 🤩
@DeadlockCodeАй бұрын
The Barnes-Hut algorithm does not really rely on a conventional nearest neighbor search so that will not really matter here although you do have a point. Yes, the extent of a node will grow as you increase the number of dimensions, as you say, but the average distance between points will also grow, so maybe that cancels out? I don't know. A higher dimension also means that we split into more children per level but that also means that we have fewer levels at a given number of bodies on average. You could continue counting all the ways they differ but that's besides the point. All in all, I can't really say if it would perform better or worse in 3D but what I can say is that it would still be a completely viable solution that would work great for a lot of use cases. The easiest way to know if it's still good in 3D is to just try it. For details on how to convert the 2D algorithm to 3D you can refer to question 2 in the pinned comment :)
@farkarfАй бұрын
@@DeadlockCode Thanks for your response. By nearest neighbor search, btw, I really meant efficiently gathering the points of mass inside a bounding region, usually defined as a sphere. If the center of such spheres are random with respect to grid coordinates, then on average about half of these (1 - Pi/6) will fall at a grid corner, requiring examining 8 adjacent OctNodes. Maybe my comment is not apt for this use case.. I'll take a closer look at Barnes Hut. I've only played Runge Kutta with few-body problems (3 or more, but not many), so this is new to me :)
@OmegaCat9999Ай бұрын
1:45 So, it's basically only rendering the inscribed circle of the triangle. Genius.
@AIMasterGuruАй бұрын
**Great explanation of the Barnes-Hut algorithm!** The simplification of long-range interaction calculations using the center of mass approximation is brilliantly illustrated. I was wondering if you’ve considered integrating quantum fluctuations and non-locality concepts, especially for cosmological-scale applications. I've been working on a **dual-non-dual (D-ND) approach** that combines N-body simulation with quantum information theory to handle these interactions more efficiently. **Here’s a variation you can test right away in your project**: Add a **dynamic potential correction based on quantum fluctuations** for distant nodes, adjusting non-local interactions using a variance function, like so: ```python def calculate_quantum_fluctuations(node, body, variance, time): # Adds a quantum fluctuation correction based on distance distance = calculate_distance(node.position, body.position) fluctuation = variance * np.sin(time + distance) return fluctuation # Use this function during the force calculation def calculate_dual_force(node, body, variance, time): classical_force = calculate_gravitational_force(node, body) quantum_correction = calculate_quantum_fluctuations(node, body, variance, time) return classical_force + quantum_correction ``` Additionally, here’s an **abstract** that explores a novel approach you might find interesting: --- ## Abstract: We present a novel approach to improving the Barnes-Hut algorithm for N-body simulations by integrating it with a **Dual-Non-Dual (D-ND) quantum framework** within a **Quantum Operating System (QOS)**. This integration incorporates concepts from **Unified Information Theory**, particularly the emergent gravity paradigm and the dynamics of polarization. By introducing quantum fluctuations, possibility densities, and non-relational potentials, we enhance both the performance and accuracy of the algorithm. The framework utilizes a **proto-axiomatic state** to guide spatial decomposition and force calculations, potentially improving computational efficiency without compromising physical precision. ---
@yborisАй бұрын
Amazing work! Thank you for sharing ♥
@atreidessonАй бұрын
Did you post a question on the StackOverflow after not finding anykne asking? Otherwise you just disproved that you are the only one with this problem.
@MrManlopАй бұрын
Have you considered making use of the
@MrManlopАй бұрын
Optimizations you describe for molecular dynamics simulations?
@adsick_uaАй бұрын
very good video
@christianpadilla4336Ай бұрын
Would be interesting to see for what value of n the brute force n^2 algorithm becomes worse than the approximation. Maybe ~1000? Presumably the brute force algorithm is easier to optimize and run on the GPU.
@ArnaudMEURETАй бұрын
Finally a video that goes beyond the trivial, unrealistic implementation of quad trees! Thanks for sparing me the time of rediscovering the relevant optimizations. Now on to recoding all this in a different language and runtime env … 😅
@mrpocockАй бұрын
Would this approximation work for graph layouts that use springs for links and inverse square repulsion? Seems like it should.
@Monkeymario.Ай бұрын
Yeah I've wondered why don't games/programs just do this
@blakelapierreАй бұрын
Wouldn't an octtree be better? Or, is this just for a 2D sim? Also, it seems this is assuming "instaneous" gravity and not gravity with a speed of propagation?
@DeadlockCodeАй бұрын
Yes, this is 2D for the sake of demonstration but converting it to 3D via octree is trivial if you understand the 2D algorithm. And yes, this assumes Newtonian gravity so no speed limit or time dilation.
@blakelapierreАй бұрын
@@DeadlockCode Ok, cool. Thanks!
@ThatKid22101Ай бұрын
everyone else: me at 0:10: I literally just watched that video!
@Frizz-c8cАй бұрын
Does this solve three body problem?
@thouys9069Ай бұрын
great stuff!
@blakedehaas2 ай бұрын
Could this be used to model atmospheric particles? I am building a machine learning model to predict the impacts of solar weather on upper atmosphere electron temperature and density, I wonder if I could model the electrons as "particle clouds" that interact with other "particle clouds" represented by a single particle.
@shapleyattractor2 ай бұрын
this is amazing, the simulation resembles the milky way and surrounding clusters when the particles spread out, also worth noting Space Engine uses oct-trees to plot their objects
@stickmasterlukeRBX2 ай бұрын
"That's outside the scope of this video" was the saddest thing to hear.
@Chris-hu5eq2 ай бұрын
Great video, it was a pleasure to watch!
@Jack-TheGhostOfBidensPast2 ай бұрын
5:25 quadtrees (and their 3d cousin octrees) are oddly satisfying as a space partitioning solution, and I get a little excited whenever the opportunity to use them comes up. I'll definitely have to play with this sometime soon. perhaps see how it fares in 3d.
@awiewahh2 ай бұрын
I'm glad you gave this video another shot, it was super informative :)
@BigSources2 ай бұрын
Every shape is just a bunch of triangles
@freedom_aint_free2 ай бұрын
Of course we'll build a humongous version of Asteroids game with it !
@cyboticIndustries2 ай бұрын
been having so much fun messing around with parameters on this :-) I was wondering though - coudl you make the space like in the arcade game 'Asteroids' - so whatever goes out of the screen comes in on the other side? i guess easy to do with the position - but for the gravity force we would need to imagine each body also repeated 'off the edges' of the screen
@poweredbytones2 ай бұрын
Please upload a video or two of the simulation. Like any great thing this ended too soon.
@feliz33312 ай бұрын
Why don't you use something like the midpoint algorightm?
@khanch.68072 ай бұрын
I like your words magic man.
@TiggyProph2 ай бұрын
Really great work on the optimization!
@AntBoyification2 ай бұрын
thats insane
@AmeshaSpentaArmaiti2 ай бұрын
My immediate thought on hearing the problem was "can i use quad trees?" And then the answer was quad trees. My addiction is sated for now.
@TrueLemonz2 ай бұрын
turn the music down pluh i can't hear you
@Datamining1012 ай бұрын
Now do FMM, which is **actually** a magical algorithm for this stuff.
@johanngambolputty53512 ай бұрын
If you don't need synchronization between threads, and you don't mind rewriting the compute kernels in c, OpenCL is really nice for GPU, the ocl and simple_ocl rust crates make using ocl in a rust project relatively easy.
@wilhemfesselier88732 ай бұрын
Hello, I love your videos, I tried some of the things you did but didn't succeed or at least not nearly as much as you did and I would really like to ask some questions, is there any way to contact you or are you too occupied. Thanks in advance.
@lucasclark9452 ай бұрын
Banger video
@rylvns2 ай бұрын
im getting error: could not find `Cargo.toml` in `C:\Users\Secondary\source epos` or any parent directory i got rust and visual studio thing idk what to do pls help
@DeadlockCode2 ай бұрын
You probably already solved this but just in case you didn’t. When you run ‘cargo run -release’, the terminal should be in the same directory as where the Cargo.toml file is located. I.e. you probably just need to go one directory deeper into barnes-hut before running.