KTH Project DH2323

There are a few things in particular that I could improve with my solution, but as I see as out of scope for this project. I don't like that some parameters in the code is hard-coded. Far from everything is hard-coded and I think I have managed to use design-patterns to separate classes rather well in general. However, since I wrote the code somewhat hastily, there are a bit too many parameters hard-coded to make it "work". Something that could have been fixed early on is to not have tiny coordinates, such that there is a huge gap between the x-values x == 1 and x == 2. This caused me to multiply certain values in other parts of the code by a constant in order for them to scale. Also, the OBJ-file which is used for rendering a fox was downloaded for free legally on the internet, but it seems to be made by a hobbyist that made the local vertex coordinates sloppily. Usually OBJ vertex coordinates are between -1 and 1. But these vertices can go to about from 20 to -20. A tip

I consider this project to be more or less done now. The last thing I implemented was a way to reduce the amount of collision checks. If one does a naive solution, then all particles gets checked against all particles resulting in a O(n^2) solution. This quickly escalates already for only 3 objects in my expiremts such that it becomes infeasible. So what I did was to read online and most recommended using a 3D uniform grid for the particles. Such that each particle inside a grid voxel was checked only against particles within the voxel itself and adjacent voxels. One powerpoint I found online suggested using a hashmap and only store voxel IDs that are used, otherwise one would have to allocate a huge chunk of memory of a finite amount of space. I could not find that powerpoint again but I'm glad that I remembered this idea. In my solution I ended up using std::map instead which internally has a red-black tree. I used this as it is more reliable, a hash solution can in worst case

I have now implemented the physics part of GPU Gems. So far I just have 1 object of particles, resembling a fox that collide with the floor. The floor is not made of particles and is just a special case that enables me to visualize things and make it easier to show the simulation later. I did run into a lot of problems implementing this but I think that I have solved all the important bits. So what is left is adding more objects with initial forces and aim these to hit one another. This is more or less required if I want to demonstrate my project, which obviously is pretty important. One big issue that I encountered was that the "actual" world position of particles that I calculated in a function differed from how the visual particles were drawn on the screen. So either the drawing process was wrong or some other calculation. In the end I managed to see that the non-visual particle positions rotated twice as much as the drawn particles which used a rotation-matrix (given by

I wanted to optimize the way I render particles for an object and also make it have the right dimensions. This was very important to achieve since I will have to do a lot of collision detection later on. I used a VBO to associate one particle-object with a set of particles so that they can be drawn quickly. I spent 24 hours locating a bug that was because I had some deletions in a destructor, which got called automatically in C++ when I copied over an object into an array. One reason for this taking a long time to discover was that there are so many other possible things that can go wrong in OpenGL. I checked the shader code, the initialization for the VBOs and if how I rendered particles on to the screen was wrong. In the end it was neither of these but just a simple destructor error. Here are some cool videos of how the particles looks like for a fox object:

I've spent quite a lot of time perfecting how to draw particles in OpenGL. This is pretty easy, but if you want particles to correspond to world space then things get more difficult. I have found on GitHub other students doing a project with very similar goals to my own project, altough they have executed their project using mainly GPU and Cuda technology. I am doing my code so far a lot on the CPU side so our code will be very different. I did check their shader code for particles, and copied their way of diffusing a particle to get a 3D effect. The clipping needed to make particles appear round did I already discover on other parts of the internet. If interested, this project can be found here . The main issue is that you have to use the shader code "gl_PointSize". This parameter only specifies how many pixels to draw, and don't care about where the pixel is in world space. Luckily someone already asked a question on how to solve this on StackOverflow here . If I

I know there has been a long time since I did any updates, and I am behind my made up schedule for this project. The good news is though that I have managed to create C++ code for generating particles. Given a mesh, which I read from an OBJ-file, I take all the vertices making up the triangles and use these to generate particles on the CPU. I found inspiration for my own solution by the short amount of text described on GPU-Gems 3 chapter 29. GPU-Gems mainly focused on a solution that generated particles with the GPU and Cuda (which only NVIDIA graphics cards can use). Since I am not used to graphics programming, don't have a NVIDIA graphics card on my laptop, and want the code to work on any computer, I decided to generate the particles using normal C++ code. I sort of got stuck on how to generate particles, since I had some bugs in my code. But after discovering and fixing these bugs I got much better result. I know that I haven't explained HOW yet, but here is a short expl