I’ve got an example in the earlier blog post, and a less compressed version available in my MS2 folder. I’ll be brief on the rest.
I have a very simple particle application capable of updating the VBO directly on the graphics card. This is along (even ahead of) my initial planning, it turned out relatively simple. The only thing I think I’ve got left to actually do is to give the particles the ability to “spawn” after a delay.
No time will be wasted on complex if-cases, and for every sort of particle system I intend to do, I’ll make separate sub-classes for each that load the related programs and openCL kernels. As some openCL kernels can have specific behaviour that I might want for a certain particle system. This will also allow me to draw different sorts of particles in different drawing functions, so that systems that are meant to be drawn additive can be drawn additive, while particles that are not, will be drawn their own way, etcetera. This is not implemented, and not thought of, and it is something that will be added in next week’s planning! I will also add cleaning up my code to the planning, as it could easily get out of hand at this rate!
Otherwise everything will be going as planned, I’ll be looking into replacing the points in the VBO point cloud with textures or meshes through shaders, and/or start researching sorting on the GPU. I found a neat example where this “bitonic mergesort” was used, and I’ll see if I cannot get any inspiration, or a clue of what I’m doing from there. It is also mentioned in GPU Gems 3 and in a few papers and assorted websites, I’ll see to it.
I will have to consider doing a n-body simulation of sorts, but I would rather not get into it at this time. I will have to discuss the merits of this with my teacher as I am still not sure how much time my sorting and rendering will take.