Your browser (Internet Explorer 6) is out of date. It has known security flaws and may not display all features of this and other websites. Learn how to update your browser.

[Final] Now it’s finished!

It’s been a good few weeks, and time has passed with a flash. The project has had a lot of ups and downs, but it has finally arrived at a conclusion, to my delight. It was a fun process and I believe I’ve learned a lot, and have got good grounds to learn even more. I don’t intend on stopping my work on this project as it is, not now. There are just a lot of more things I can do to it.. but anyway, here’s my wrap-up. My report. In short.


The positives:

  • A lot of tasks were simpler than I had estimated, so I ended up winning a lot of time.
  • OpenCL was easier to get into than imagined.
  • I was more capable than I first imagined, too. It helps to get confident. =D
  • Managed work so quickly, even with timelosses..

The negatives:

  • Timeloss on sickness: 2 weeks approx.
  • Timeloss on driver issues: 1 week approx.
  • Could have had better initial planning!
  • There’s a lot of place for more sophisticated solutions, like maybe using a heightmap for particle collision. Or something else.

Overall I’m happy with my results, and I feel there is a lot of room for improvement. Improvements that I am going to try out from home and at my own leisure.


The final delivery ended up being not quite a .lib. I wasn’t happy enough with the result, so instead I send out my entire source, which is full of test-code and unoptimized parts; but it’s something for anyone to improve upon.

This is Klas, over and out.

[Week 6] Just a few example videos

Now, I know the system behaves mostly the same. But the purpose of these tests were just to try out functionality.

[Week 6]Simple local forces somewhat finished, trying plane/triangle collision

I didn’t think trying local forces would go as fast as it did, after settling the sorting and putting extra time in some overdue courses I did it in less than a day. The local forces are not complex by any means.. I had hoped to put in some sort of field texture, but with my time I think I’d rather focus on a simple spherical ’emitter’. That can either drag in or push away particles. I may, when I create the kernel for this functionality also add functionality for bounding boxes with a “wind” vector..

I am currently looking into plane/triangle collision with my particles.. if I could get it done swiftly, I could get to cleaning up my code and actually make a demo of sorts. I’ve already planned what the demo should contain by itself. I may also, since it’s an extremely logical thing to do, add support for several particle systems in one particle manager. However, focus lies on making the particles behave pleasantly first! It doesn’t matter if I can demonstrate several systems at once if they don’t behave as I want. I’d rather have a demo with a single particle emitter, than several that don’t work.

[Week 4] A note on not-progress, and some handy links!

So, this week I haven’t got a lot done past reworking my schedule. mostly because my time has been spent reading papers and pre-existing code in SDKs. I may end up using pre-existing code for sorting, with slight modifications. However, if I do, I’ll make sure it’s within my right, leave a nudge towards the original authors/owners.

As said, I’ve had no VISUAL, nor any CODE advancements this week apart from the particle rendering. Instead I’ve read up on sorting on the GPU. I want to sort on the GPU because transferring all of the data back and forth from the GPU-CPU would be out of the question. It would be a bottleneck. However, I thought I’d make a few shout outs. NVIDIA and AMD both have nice SDK examples (however I haven’t found the sorting samples of NVIDIA). And Intel has got great OpenCL samples too, one of which are a bitonic sort, which is what I’m looking for!


The idea for the particles are that I’m gonna sort them. But I will not sort the particles once every frame. I’ll look into depth-sorting the particles maybe every fifth frame, or tenth. This is an arbitrary number and shouldn’t be tough to fiddle with.

[Week 4] Colored Billboards done

So, after finishing the billboards I figured I wanted transparency, and thus I read through that a little bit. What was seemingly simple bounded into me realizing just how much I have to learn. Even if I did bind VBOs, I rewrote the system a little bit so that I could send the buffers to my shaders, something I wasn’t quite sure about, but it worked well. However, I had many issues compiling a geometry shader, and first after fixing a bug with my debug logging could I see that it was because Geometry Shaders don’t take parametres that aren’t arrays. A facepalm later, I fixed it in a swiffy!

Also: I got some help with blending from someone.. and I feel I don’t quite grip it quite yet; I’ll have to take a more proper look later. As I will have to use different blending schemes later. I will also have to look into rendering particles to the depth buffer, but not against themselves.

This little adventure in itself worked fairly nice, I did learn a few things. Now I feel I can start with my research on particle sorting! This is gonna be interesting! The coming week I may also work on cleaning up my code a little bit and having more examples than just an all-emitting, fill-rate consuming ball of chaos. Even if it looks kind of neat!

[Week 4] Here, have a video!

[Milestone 2] Where I am now

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.

[Week 1] Getting started with OpenCL

The week has been a slow start, but it’s mostly been because I’ve been distracted and/or busy for the most part. These last two days I’ve been doing progress however, I’ve been able to create and compile a simple openCL program of my own after trying a few applications. The biggest ‘issue’ I’ve ran into yet was a problem with linking, that was all my doing. After getting started though, I came to a surprising discovery:

OpenCL is surprisingly simple to set up. I hope to get a head start on next week by implementing a simple particle system ahead of time. Of course, this is just me being positive.

After playing a little with OpenCL, I felt like it was in my place to create a little OpenCL handler of my own, just to ensure code stays tidy and separated. It will not be anything fancy, just a few functions that return integer handles to std::vectors kept inside the handler. I’m considering making it a singleton, but it won’t really need such a treatment.

[MS1 Concluded] Crisis Averted

After about a week of insecurities and having no idea of what to do with my particle system, I managed to have a miracle presentation using incorrect slides and an unfinished research document. I’ve been trying hard, but been thinking too much.

The first week has, as this implies, been tough on my nerves. However, it is back on track.


Further note for anyone making later projects: The MS1 presentation is about your research, it can be ground down into:

  • What you have decided to do and why.
  • How you are going to do it (research should have got some information on this)
  • A risk assessment (research should also have got information on this)

I had trouble understanding what to present, but this is something I feel properly describes the process.