Devlog 4: Changing to Quarks and adding 3D

So I looked into it a bit, and now I know that the Cornell Potential didn’t work correctly for the nuclei, because well, the Cornell potential is meant for quarks, which is also why I have no decided to already switch over to working with quarks, because I get more enoyment out of that now, and it is something I planned on doing anyway.
I have also added 3D simulation, so I can see how stuff acts there.
And also, I’ve added a minimal distance, because stuff always got too close, and the force got close to infinity because of 1/x, so now everything that is too close, just doesn’t interact.

Devlog 3: Strong force

I have now implemented a strong force, I did that by using the Cornell potential and it’s derivative:

V(r) = -(a/r) + ro
F(r) = -(a/r^2) - o        (Derivative!)

It took me a bit to both find that formula, and to try understand it, but now I think I understand it good enough.
But I do think I have to change some stuff, because the neutrons and protons like do not stop at all, and I think the electrons shouldn’t be affected the way they are, but I think the reason for both might be that the derivative is bad? I don’t really know, I don’t know how derivatives work.

Devlog 2: Adding Physics

It took me a little, but now I’ve added interaction between the different particles, to reflect their charges, based on Coulomb’s Law:
F = k * q_1 * q_2 / d^2
Where k is the coulomb constant, q the charges of the particles in coulombs (a unit) and d the distance between the particles.

Whether a particle is a proton, neutron or electron, is based on their index in the positions array, modulo 3:

colors[index % 3];
charge[index % 3];

But the reason it took me a bit is, because I tried to change the coulomb constant in a way so that when q is of the unit e (elemental charge) instead of in coulombs and the distance d in fm instead of in m (1fm = 10^-15), it still is correct. But I struggled a bit, until eventually I found the problem, I forgot to account for the fact that d is squared, meaning the 10^15 I was working with, where supposed to be 10^30, so as soon as I fixed that, it finally worked like it should.

Next thing to do, is to imitate the strong force, so the protons can stay together.

Devlog 1: Starting the project

So in this project I’m going to simulate atoms, while probably trying to stay somewhat physically accurate.
I’m going to start of by simply simulating particles that are either Protons, Neutrons or Electrons, that have a certain charge. Later I’m planning on making it so each of them is made out of three quarks, with their corresponding charges, which hopefully adds more realism.
Right now, I already have made it so I can see the different particles, and only have to add the logic behind it.

Devlog 4: The Parser works!! (Somewhat)

SO now i’ve managed to get the parser working, in fact the thing wrong was that for my main function I called it “Main” instead of “main”, so it couldn’t find it.
I also had the problem that after running it, it returns a pointer to a that isn’t the one it should be, which I think I fixed now?
So now I have the problem that the values aren’t correctly passed through the objects, meaning the logic doesn’t work the way it should.

Devlog 3: First Parser attempt

So I tried making a parser, but it hasn’t worked yet, but I think that’s probably because I kind of confused myself again and again with my own decisions.
So now, I’ll try to improve my parser to a working state, and in the worst case, change my approach.

Devlog 2: Having made the classes.

I have now create two classes that my parser will be able to use to turn the written code into something that can be executed.
For my parser I’m going to have it build a tree out of NAND objects, so that when the root is called, the entire tree gets executed recursively. The kind of parser I wanna use is called a recursive descent parser, which starts at the first symbol of the text and moves through it left to right, and ends at the last symbol.

So now I’m going to start working on the exact grammatical rules of NANDSpeak, so I can then start working on the parser and tokenizer.

Devlog 1: Starting a new project

So I decided to make a programming language, where instead of writing code, you write hardware, in the sense that you can only connect NAND gates with each other and a few Input and outputs, and that would be the entire language.
I will probably also make something that allows you to input stuff into your creation and get the output, maybe even let your write code to run on what you created?
We’ll see, I have just begun after all.

Devlog 11: Fixed a Bug & Finished README

The bug I mentioned in my last devlog, the one where I couldn’t understand why it only happens when a number is odd, I still don’t understand it, but I managed to fix it.
In the shader I use for rendering, I used fmod(InstanceID, colorCount) for finding out what color a particle is, but in my compute shader i do it like this InstanceID % colorCount, and apparently those do something different with the same int input? I don’t know.

But now it’s fixed, and I added a Demo video to my README.
So now I can finally ship this.

Devlog 10: Writing a README & finding bugs

So, I now pretty much have finished writing my README, only thing missing is a demo video, but before I can add that, I’ll have to fix a bug.
Because apparently when you input a odd number as the amount of colors, the values in the matrixes are not the one of the color shown, but of the color 1 to the left/up? But only for odd numbers, even numbers work fine?

But anyway, I also added a FPS counter to the simulation.
So now I’ll go to either try find out why that bug happens, or just add something that makes the bug invisible.

Devlog 9: Input Validation & Bug Fixing

Knowing that I know my code to well, I gave a working version of it to my sister, to watch her try it, and see if there’s anything somebody could do, that isn’t really intended.
And it turns out there is!
It seems quite obvious now, but one thing you could do, but weren’t supposed to, was inputting any values you want, which is fine if you know what you’re doing, but most probably you won’t, so I had to add Input validation.
In some places it was more important than in others, because your GPU really doesn’t like it if you define a buffer with a negative size, which happend if you inputted a negative amount of particles.
I also cleaned up the files a bit, by taking all unused files, and putting them in a folder called… “Unused”, really clever name choice, isn’t it?

So now, I get to prepare for Shipping my project, although I’m not really looking forward to writing the README yet.

Devlog 8: Matrix editing & Camera Movement

So I know I said in Devlog 7, I would only polish some stuff and get ready to ship, but I just couldn’t not add the ability to edit the Matrixes and move the Camera, the first of the two, I was able to do with the help the GridLayout Component, which automatically arranges all it’s children in a grid. I did that by dynamically adding an UI input Element for each Value in the Matrix, and putting in the corresponding Value. And now, you can change the values of each Cell, and when you’re finished, you can hit apply, and now you’ve changed the behaviour of the particles, yay!

Getting the Camera to zoom and move in a way I like, was really hard, probably because I was kind of tired, or maybe because I’m just stupid, who knows. But anyway, I’m using Unitys Input System to geth mouse movements and scrolling, so that I can then read out the value of those in my Script.
The zooming is works like this:

Zoom += Zoom * (ScrollValue/10);
CameraSize = OriginalCameraSize * Zoom

And the camera movement works by turning the mouse position an the screen into a position in the World Space, and multiplying it wiht the suqre of zoom, so that the movement gets slower and slower when you zoom in.

There is even more to it than this, but it would be a pretty long Devlog if I explained everything, so I guess next time I shouldn’t wait 8h to write a Devlog. (:

Devlog 7: Adding a UI

I finally did it, I added an UI to it, it doesn’t include everything I wanted, but it doesn’t have to be perfect, especially seeing as Unity thought it had to nuke half my work an the UI, just as I wanted to save it, that was quite annoying.
But now you can control pretty much everything except the stuff that you can’t through the UI, like the amount of particles to simulate, some range values, physics variables, and of course the color of the particles.
So now I probably just need to polish some stuff and get everything ready to be shipped, and then I’ll probably ship it, we’ll see.

Devlog 6: Compute Shaders!

So I know the next thing, and only thing left, on my To-Do list, as seen in my last Devlog, was to add an GUI/interface, but I wanted to improve on how many particles you can simulate at once, so I researched how shaders and compute shader work, and made one that could do everything my C# script could do too, but faster, as compute shaders run on the GPU, which is really good at doing things in parallel.
But it wasn’t easy, as I had no idea how both shaders and compute shaders work, and I still don’t really know how shaders work, but atleast I know how compute shaders work now.
But getting to this point, where it finally works, took me the entire day, with having to do research and having to keep trying new stuff to find something that works, but I think it was worth it.
But I was kind of too lazzy to implement a BitonicMergeSort to sort using the GPU, so I took that code from https://github.com/SebLague/Fluid-Sim, and slightly altered it, so it would work for me.

So now, I’ll just have to add an GUI or something like that, adjust some stuff, (like changing it so the particles don’t spawn in a symmetric grid, or particles don’t spawning inside other particles anymore), and clean everything up, and then I’d probably be ready ship it for the first time, depending on whether I wanna add more stuff first or not.

Devlog 5: Speed up thanks to Spatial Partitioning

So now I’ve done it, the next thing on my To-Do list is completed, as seen in my last Devlog, it was to Optimize and Improve calculations, and I did that, mostly by implementing Spatial Partitioning.
How it works is that, if there is only a certain range around an particle, in this case the MaxRange, you can pretty much ignore everything outside of this range when calculating attraction, instead of having to check the distance to each particle, and getting the same result. To do that you split the area where the particles can be into squares(Cells) with length of MaxRange, and then assinging each particle a key, which you get like this:
key = someHashFunction(CellPos.x, CellPos.y) % ParticleAmount
And then with some sorting and such, you can calculate the attractions, only the Cell the particles in, and the 8 cells around it.

This was somewhat simplified, but I hope one could understand it.

And in the video below, you can see me simulating 4000 particles, at roughly 10 fps, which might not sound like a lot, but compared to before, where simulating 2000 particles resulted in about 5 fps, it certainly is.

To-Do:

• Add interaction based on color and distance.
• Optimize and Improve calculations.
• Add an GUI / Interface

Devlog 4: Getting to a working version

Like mentioned in my last Devlog, one thing I had to do was adding interaction based on color and distance, and hurray! I did both!
So I did it by having an array of floats, which contains the attraction matrix, but flattend, and did the same for the distance values, basically like this:
array[i + j * width] = matrix[i][j]
I also made a function that based on a minRange and maxRange around a particle calculates it’s attraction to other particles, if it’s closer than minRange, it gets pushed away, otherwise if it’s closer than maxRange, it gets attracted or repelled based on the attraction matrix.
I made it so instead of using Time.deltaTime it now uses a fixed value that you can change, and added friction, so the particles, making the particles alot more stable than they’d be otherwise.

So now, I’d have a usable version of Particle Life, but as you can see my To-Do list isn’t quite finished yet.
To-Do:

• Add interaction based on color and distance.
• Optimize and Improve calculations.
• Add an GUI / Interface

Devlog 3: Implemented some stuff

In Devlog 2 I wrote down what I planned to do next, and now I’ve done it.
I added an adjustable border that when crossed moves the particles back inside, and makes them bounce of by inverting their velocity, but dampening it a bit.
Then I made it so whenever you start, it arranges the amount of particles you choose in a grid, in the middle of the border, with adjustable spacing between the particles.
Then I made it so you can chose however many colors you want, and the colors will be equaly distributed to all the particles. I did this by basically doing this:
particleColor[i] = colorList[i % colorList.length]
Where the colorList[] is made up from the colors you input in the inspector.

To-Do:

• Add interaction based on color and distance.
• Optimize and Improve calculations.
• Add an GUI / Interface

Devlog 2: Changing my approach

I have now decided to not have each particle be a GameObject, but instead handle all of them from 1 Script that stores each particles position and velocity, to then calculate interactions and draw them. Right now I’m doing the drawing using Graphics.RenderMesh() for each individual particle, and I can already have them be attracted or repelled by each other.

What I plan on doing next:

• Add a border, so the particles don’t escape.
• Make it so the particles starting positions are spread out.
• Add the possibility for particles to have different colors.

Devlog 1: Starting my Project

So first I had to set up my Unity project, link it to a GitHub repo, and then installed HackaTime to track the time I work in Unity.
So I wanna create something based on Particle Life, but with a few changes and twists.
So up until now, I have already made a Script that gets all colliders in a certain range around the GameObject it’s attached to, by using Physics2D.OverlapCircleAll(), and then calculates and applies a certain force into the direction of that other Collider, by using RigidBody2D.AddForce().
But right now, they still act the same towards all other particles, not just those of the same color.
And now, I have also come to the conclusion that I will have to think about whether I wanna do this Project using the GPU for the calculations, or not, because I’ve realized that only using the CPU might not have the greatest performance, but the way I’m currently doing stuff, probably won’t work for a compute shader.