Not dead yet, new project announced

I'm still not dead, though I got a bit busy. There are quite a lot of updates, but the most important is announcement of new project.

The site for new project is in-development and it will be available till end of October (hopefully), along with wiki there, and hopefully first demos.

Whats new project about? Realtime ray tracing (and hopefully even some path tracing will get introduced). Whole system is based on OpenCL + C/C++ (w pthreads of course) - hopefully I'll be able to achieve realtime performances in game-like scenes.

Except some fancy screenshots and demo time soon.

Particle systems optimizations

Particle systems optimizations

I've recently met with few problems while integrating particle systems to more kinds of renderers, so here are few notes and tricky solutions on things I've met. (Consider this article as some uncontrolled brain dump for particles, this thing got up based upon some discussions with other developers and it is more less just a bit of text about our thoughts on particle systems, by the way all these optimisations are running in praxis and they actually work - although it depends...).

Particle systems integration is same for rasterizers and same for ray tracers. Although we won't see that much impact on performance in rasterizers as we see in raytracers, it is due they're better fit for particle systems.

As I said problems are similar and I'll try to show few of them and explain how to solve or at least reduce them.

Fillrate problem

The biggest problem of particles is their rendering, whole particle system can gain a lot or lose a lot in this phase. The most important is only thing - how many times will every pixel be redrawn, until we get resulting color of this pixel.

The worst particles are additive ones (alpha blended can be quite easily optimised with early out - when we reach accumulated alpha of 1.0), lets look at simple fire like this:

Fire computed using ray tracing algorithm and additive "blending" of particles

If we would just render these particles right in additive blending mode (of cours back-to-front so everything will be correct, actually we can also use front-to-back ... but lets leave it, as we don't think just about rasterizers), or if we used additive ray tracing (after hitting the particle, we spawn a new ray at this position in same direction that we trace again, adding its result to the value), it'd result in very high fillrate (lots and lots of overdraw, and thats not good - the result can be very slow), lets see how much fillrate is used on different regions of viewport:

Fillrate - The brighter is higher

We can define maximum value of particles that can be added together (F.e. 16 additive operations), it can lower fillrate a bit. It can be applied on rasterizers with texkill or alpha test), it gives some speedup, but this technique can't be used with additive blending, only with alpha blending. With raytracers there seems to be higher gain (one can terminate tracing rays on pixel even with additive blending, and we gain more).

Fillrate - defining max value of possible additions (to 16) 

What helps us most with fillrate is so called Particle trimming. Instead of quad we choose much more suitable shape for particle. We can even stay with four vertices shapes, although it is much better to use F.e. 7-vertices shape. Vertex processing is less hit for performance, than huge overdraw of single pixel.

Particle trimming - green represents shape of particle 

We will gain most fps with particle trimming, also we can gain even more with compositing more particles into single (LODing for particles).

Bandwidth problems

The second problem, can even overgrow over fillrate problem. Huge CPU generated particle system with 1M particles and 64-byte per particle can have 64MiB stream for every frame, that's 1.92GiB to go every second to card!

If we generate geometry on geometry shader during the run, we ca achieve 2/3 speedup in bandwidth problems. We can also compute whole particle system on GPU (gives us even better performance, although one must not have too busy GPU).

For ray tracing real-time geometry generation (like in geometry shader) has its sense, although we won't save that much as in case of rasterizers and GPUs. We have to rebuild whole scene hierarchy and that takes time. If we don't generate particle geometry during rendering we can die on CPU<->RAM latency, otherwise we will die on the same thing, but we will probably use cache more.

Although we can accelerate the computation by parallelization on mutliple cores, or using SIMD extensions, be it AVX or SSE.

State changes problem

State changes are problem for both rasterizers and ray tracers. I strongly recommend using texture atlases as one can gain a lot of speed with them (and you won't need to bind texture for every particle system. On the other hand, there are situations where texture atlases are impossible to do or absolutely useless.

Matter of time...

The last problem is when to render particles? It is simple with ray tracers ... insert them before updating of hierarchy, be it KD-tree or BVH (or any other favourite of yours). And renderer takes care of them. Although it is not that simple with rasterizers.

For forward rendering it is best to render front-to-back (with other models), but thats not possible, it is needed to render them after all models and mostly back to front. And that rewrites Z-buffer ... slow, slow ... :( There is probably no way with additive particles, for alpha blended there is.

For deferred rendering it is best to use separated pass for particles after generation of G-Buffer, and after light computation (lighting phase) mix them into the buffer. And thus we discard all deferred advantages for particles, but we get them. Second possibility is MSAA G-Buffer and stippling. Another solution is depth-peeling, but well we're getting too far from realtime performance now.

The most common is to use separated pass, even half sized, we can use this mainly for consoles, as the fillrate is bigger problem there than on PCs.

So thats all?

Not at all! But this is just short article on few of the problems. If you wish you can implement some of the things, here are summed tips:
- use particle trimming, it is simple and you will gain a lot
- use geometry shaders on newer cards, R2VB on older if possible
- use texture atlases if possible and if suitable for renderer
- use less larger particles rather than more smaller (if you're limited when computing particles) otherwise NOT and NEVER (if you're limited on fillrate)
- don't compute with particle systems that you can't see (some variation of frustum or occlusion culling is good), keep just time variable for them so they won't "jump"

Well that were few points for particles. If you wish them to implement feel free and do it. You'll probably gain one or two fps on most GPUs and that counts!

Note: I hope you liked the article, feel free to comment. It was lying here on my disk for a while so I released it to public (also there is czech version on www.ceske-hry.cz ).

A little of this and a little of that

Well, it's been a while I've written on this blog and it had mainly two reasons.

First one was that I actually decided to play through Risen, and it inspired me a lot into my one personal project (that is long time work-in-progress).

Second one was and is more important, as I'm actually gonna showcase some real stuff soon that was in development. It is about libOcean, libRNR and nice technology demo with them (combined with my updated engine). And I hope also first step for doing preview of the first reason (e.g. the game in progress)

Some facts:
- it will behave as small game (e.g. you'll have main menu, maybe a console)
- it will be multi-platform (e.g. you'll be able to try it on Windows, but mainly on Linux and other nix systems - as Linux is our main development platform)
- it will be situated on island
- it will use newest features from the engine

Rendering engine had some major update recently and whole pipeline is more and more based upon physics (For example physically based shading model).

So await some news during this and next week. I'll definitely try to get images on some servers (like devmaster.net) and probably also give demo available to public through my website (hopefully it will be reconstructed during this week).

Audio library implementation

Hello again,

I'm back to work and I was given a task to work on audio part of game engine recently. As I found, most articles about OpenAL implementation, are outdated, so I had to implement it on my own (with help of reference manual).

In fact I've got basic sound system finished and right now I'm about to work on OGG standard. After it I'll have audio part of game engine complete and you can wait some sort of article about designing audio part of game engine and how to work with it.

I've recently found out, that I'm really busy finishing lots of different parts of game engine and that I'm finally seeing the light in the end of tunnel.

I hope that I'll be able to deliver more info about engine soon, and possibly info about a game.

Appologize for absence

I appologize for my absence here, I'm having time full of stress. I'm graduating in ~37 hours and well, that's not too much time to learn (my consciousness to me - why are you posting here!!! Prepare yourself!!!).
I hope I'll pass the exam. I'll let you know here, and as soon as I'll pass it - I'll bring new news here, along with some cool stuff.

For your information, I'm gonna graduate from math, czech language and literature, physics and english.

Okay, I'm going to learn a bit more, god knows I need it.

RNR system

Still no luck with moving blog to my site (I didnt have time to actually finish the site). Although here are some news:

• LibOcean site is in development (it will probably actually be finished sooner than my own site, as it is quite huge)
• LibOcean v0.2 (planned) will have a demo, and a smaller application showing how to implement it (demo won't be with source, smaller application will)
• RNR system - for creating and rendering vegetation - is being work-in-progress for some time and today itactually has first tree type implemented

RNR system is system for generating and rendering vegetation, right now it is rather small (first tree-type implemented today) and there are still not any GLSL shaders for rendering implemented. Anyway here is a shot with tree render:

Spruce, the first one implemented.

So as you can see, it doesn't look that bad. And whole rnr is taking care of LOD, so in the end you'll just render it whenever you will need (with lod activate for current render or not - because sometimes, f.e. when generating shadow maps, it can be very disturbing).

Okay, I hope I'll have anything new to bring here soon.

Blog moving

This blog is gonna move, I will probably include it as part of my new websites (still not opened). Design of my new website can be seen here:

http://www.otte.cz/Otte/

Pretty, dont you think?