Open comments for this post
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
Open comments for this post
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
Open comments for this post
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.
Open comments for this post
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.
Open comments for this post
Devlog 4: Making the case for my Hackpad
So today I have finally begun the case for my CelePad, but I kind of made it more difficult for myself than I had to, because I just had to measure everything before I could be happy with it, and even then I still doubted whether everything was right or not.
But no I’ve done it, and the only thing left is the firmware and decorative stuff.
Open comments for this post
Devlog 3: Fixing the wrong key matrix to be right.
Having to go back to your schematic and change stuff and the also needing to update the PCB to fit it, is certainly annoying, but I hope it is right this time, because I do not wanna have to do that again.
Because as someone kindly pointed out in the comments of my first Devlog, the diodes in my matrix wiring were wrong, so I fixed that, but then having to reroute my PCB to be correct too, as mentioned already, was annoying.
I also encountered the problem of having closed the website that directs you to the Lookout app, so at first i had no idea why my time wasn’t syncing, luckily I managed to find the right Site in my browser history.
Open comments for this post
Devlog 2: Designing the PCB layout, and learning about LED’s
Designing a PCB for the first time is interesting to say the least, especially when you don’t yet know what excactly it is going to look like.
I experienced some difficulty getting everything into a position I liked and then routing the traces in a way I liked and that I thougt made sense.
I decided to do the LEDs last as I had no idea where to put them exactly, but by doing so I then had the problem that when I finally did do it, it messed up the already existing traces, so I had to redo some of them.
But before I finally put the LEDs where they are now, I first had to find out where exactly to put them, cause how are you supposed to know they are supposed to be put directly underneath the key switches?
Open comments for this post
I’ve created the Schematic for my macropad, and began making the PCB.
At first I had difficulties understanding KiCad and Lapse, but it ended up working out.
At first I also had no Idea what exactly i wanted to create with my macropad, but I found that one out quickly enough.