Devlog 8: Control your speed!

I noticed how it’s really annoying when you try to view the particles while they aren’t scaled up by getting closer to them, it is really easy to just overshot, making it really hard to get a close look at them because your steps are just way to big.
So I decided to allow you to control how fast the camera moves by scrolling with your mouse wheel, which changes the Movement scale, I even made it so that scale doesn’t change linearly, but (exponential?), like this:

if(decrease_movement_scale){
    movementScale /= 2;
} else if(increase_movement_scale){
    movementScale *= 2;
}

Additionally I wanted you to be able to see what the current scale is, so I added a new section to the UI, where you can see the current movement scale and also a little guide on what the controls are.

And one last thing I added, is that I made it so when your cursor is on the UI you can’t accidentaly change the movement scale or turn the camera.

Devlog 7: Adding UI and Camera Movement

It’s been a while since I last worked on this project, but now I’m aiming to complete it.
So today I made an UI where you can change most of the values the simulation uses, and then wrote a Script so those changes in the UI can be communicated to the simulation itself. And when you start the program, you even get to chose whether you want the 2D or 3D simulation.
After that, I added the ability to move the camera around using WASD and QE, and found out that instead of making a complicated code to zoom in in the 2D mode, I can just have the camera be in perspectiv instead of orthografic and then move the camera closer to the particles, and after that I finally added the ability to turn the camera in the 3D mode.

Devlog 6: Compute shaders

So now I’ve turned my c# scripts I used for computing the particles into an compute shaders, so that you can simulate way more particles now, for me personally with an integrated graphics card, I can manage about 16000 particles pretty well.
I made the compute shaders by pretty much just copying the c# script into an compute shader, where I only had to change a few things, like changing Vector3’s to float3’s, and then wrote a little handler that does the communication with said compute shaders.

Devlog 5: Adding ranges

So I decided to add both a minimum and maximum range, the minimum range is to prevent division by zero errors, because I’m dividing by the distance, and the maximum range is to prevent the particles from always collecting in the middle.

I’ve also realized how difficult it is to simulate quarks, so I’ll be making this project shorter than originally planned, because I just simply don’t enjoy researching the entire day and yet not finding anything new or useful.
I also can’t just improvise stuff I can’t recreate realistically, because I know I just won’t be satisfied with that. Because of that, I’ll cut this project short, and will start working on getting it into a state that can be shipped.

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