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

Altough this is not needed for the project, I decided to implement a skybox for the background. In the end, it wasn't that complicated. However, many tutorials online don't tell you all the details needed for implementing it. So I took out pieces of information from different tutorials and used a bit of trial and error. One thing that was confusing is that some sites refer to the model matrix as the "world matrix", but once I learned that these are the same it became much simpler. I also found some good free cubemaps online, but these are in the form of tga-files, and my texture loader only acceps png-files. I suppose that is something to consider for potential future work. Fox object with a cloudy skybox

Today I have been working on re-structuring the code by adding more classes. This will help later on in the project. I also made a "Shape class" which I plan to use to instantiate many rigid bodies for the simulation. Each rigidbody has it's own shader reference and model matrix. I have been researching online about how to best handle 3D rotation along any axis. I am not 100% clear on how this will work out when I will want to have sudden rotations to the objects in any direction. I believe that by following tutorials and reading papers about rigid body simulations, this will eventually solve itself. I noted that I will need to save the orientation of each individual rigid body, and for this I will use a quaternion that represents that. Supposedly this will affect how some physics calculations are done in the code. I found an interesting powerpoint online which at least mentions this briefly which can be found here . Something I plan to fix next is the "game loop&q

I have currently managed to setup the code to load OBJ-files by which I use to render shapes. This will be necessary later on for colliding different objects. Technically one of the labs contained code for loading these files, however that code seems outdated. Also, I want to be able to load any type of OBJ-files, not just old ones. I took another course in computer graphics 1-2 years ago, there we were provided with code to load OBJ-files as well. This loader was good, but it seems to not be completely generic or contain bugs. It might be the case that I fixed a certain bug in that code, but I believe I saved that code on an external HDD which is far away from where I am at the moment. In any event, this code can be found here . So I continued my search online for finished C++ OBJ-file loading code, and found this header . I have right now a mix of the first and secondly mentioned codes. The first one provides a better quality but crashes if it doesn't load very specific OBJ-fil

I have setup a camera system by looking for guides online. By using W,A,S,D it's possible to move the camera forward, backward, left and right. E and Q rotates the camera. The look-at direction is determined by the mouse position on the screen. This is not strictly necessary for the project, but it's always useful to have a camera. Also, something that is different from the labs is that in modern OpenGL you create a model-view-projection matrix or a model matrix, view matrix and a projection matrix. The MVP matrix is then sent to the shader code and used there to multiply vertex positions with. In the animation lab track the matrices are stack-based and probably calculated on the CPU which is deprecated. The camera code was taken from "LearnOpengl" here . Next I am planning to do something that isn't needed for the project either, namely implementing a skybox, or a cubemap. I don't think it will be too difficult and wont take that long either. When that is

So I have a plan for how I want to do this project. The goal is to be at least 90% done by the 1st of august 2019. The first thing to do is to setup a scene by which I can demonstrate my solution. None of the scene setup is that relevant to the project per se, but having good visuals are impressive for both graders and potential employers in the future. So what needs to be done is to setup my work environent using Visual Studio and GLFW. I have done this earlier so there may already be such a work environment readily available on my PC somewhere. I think that I also have Lua setup on that environment, which may be useful for making real-time changes to the code, instead of having to recompile a lot of times. I believe it was a good thing to try to create a rigid body simulation first. I will also do the course "Advanced Graphics and Interaction" as well as a master thesis later on related to graphics and interaction. To me this topic seems like it can provide a solid founda

I read about topics on GPU gems and found something similar to what I had planned in regards to collision. What I found is called "rigid body simulation". It seems like there are a lot of recourses about this topic online and it includes simulating physics which I find interesting. If this turns out to be too easy however, I may extend this project into a fluid simulation instead. According to GPU gems, the techniques used for rigid body simulation can also be used in fluid simulation. So by playing the safe cards first I can decide later if I want to put in more work.

This is going to be my blog for the project part in the course DH2323. I will probably make a project involving collision detection between a shape and an uneven surface, perhaps best described as a set of connected triangles. I have not figured out the details of what I plan to do exactly, but besides solving a general problem statement, I also want to create a program that enables me to demonstrate it properly. I will probably use C++ and GLFW as well as GLM.