Game programmer and his thoughts

Not dead yet, new project announced

2011-10-11T15:57:00.000-07:00

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

2011-06-13T18:47:00.000-07:00

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

2011-06-13T18:06:00.000-07:00

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

2011-05-23T09:46:00.000-07:00

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

2011-05-16T14:42:00.000-07:00

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

2011-03-30T09:20:00.000-07:00

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

2011-03-14T16:55:00.000-07:00

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?

LibOcean alpha here - a demo for you

2011-02-17T15:24:00.000-08:00

Hello fellow programmers,
this time especially for programmers, as no one will appreciate this thing more, here it is - my almighty LibOcean! Okay, before we get too excited, there are several things right now - this is a demo (limited use, no control over wind or tessellation of grid to simulate, no multithreading, etc.), even though you still can build pretty nice ocean simulation on it. Here are few screenshots of it in action:

As you can see, LibOcean generates just and only water surface, everything else (including rendering that surface) is up to you.
I also supply sample application (source + win32 binaries) with libraries (win32 binaries), that shows how to implement simple ocean cell surface, animated with LibOcean. Also I promise that there are going to be future releases (and updates) with much more funcionality, this one is just a demo library + application.
LibOcean uses inverse FFT of some spectrum to animate ocean surface, it also is using own FFT function - that is highly optimised for this purposes, currently single thread on Core i3 can compute 512x512 grid in realtime.

For future releases, these are planned features:
- Multithreading support (up to 8 cores)
- Choppy waves
- Pre-computing height fields (and offset fields for choppy waves), and saving them
- Setting wind and wave direction (you're not allowed to do this in demo)
- Setting tessellation and other parameters (you're also not allowed to do this in demo)
- Full scale LibOcean site (right now in progress)

So, what do you think? Will you give it a try? Here is sample video:

Also note, that same system was used on Game Access conference in our tech demo, sample screenshot and video:

Okay, you also want a sample application archive and library demonstration, here they are:
LibOcean library win32 binaries
LibOcean win32 sample source binaries

Linux libraries + source will be here soon.

2011-02-01T19:26:00.000-08:00

Another update, this time quite different, because this is the first post I'm writing from linux operating system (I've had been using it for quite a long time, although I've never used it for writing here ... huh strange).
Apart from another (path tracing positive) news, that I'll post tomorrow or the day after it, I've got some recent news now, this is image:

Yes, this is a little bit more complicated model of horse (2k triangles), rendered with current version of my software ray tracer (and still single core, no packets and such...).
The first official specification of my interactive raytracer is being more and more complete (before release to public!), and here goes some specs stuff for version 0.1:
- Support for triangle primitives (more primitives like Spheres, and such next time; I need to test hit on performance for different kinds of prims)
- Support for KD trees (right now no BVHs, or BIHs; I gotta start small, so KD trees are only option, although KD compiler is O(N log N) one ... so maybe less complex dynamic scenes are also possible)
- Support for textures (no texture filtering right now, in next specification and next release)
- Support for point lights
- Support for fixed-shading rendering path (possiblity for reflection and/or refraction)
- Support for single core rendering (Ah... this one hurts!)
Don't be scared that this spec can seem a bit too fixed, as for next version I plan adding a lot (of finished stuff, that hasn't been debugged). I hope for releasing spec in due time, but...
Also there will be no packet tracing right now, I still have to decide if to use it, or not (some 2.5 speed gain would be cool, but...), also no gpu support for now (although I have thought of OpenCL, and even more insane GLSL, support), changelog for version 0.2 is going to be:
- Adding magnification texture filtering (bilinear and bicubic filters)- Adding multi-core processing (hee yeah, n-threads means n-times faster ... well ... almost)- Speeding up (better memory alignment, I think I can dig out some percents outta this)- Extending fixed shading rendering path to be a bit programmable (e.g. start to extending it)
- Start working on GPU support
As you can see, it is gonna grow, with little steps, but... it will grow. I hope I'll manage to keep this project on a line.

Now it is alot better

2011-01-23T14:14:00.000-08:00

Yeah, SAH splitting did good job and I made some pointer magic ... so now performance runs from 1.2 MRays/s to 4.6 MRays/s (Hee yeah!).

Converged image from path tracing :P ... okay, next time I'll probably use another scene, this one is pretty boring and evil for KD-trees (made out of triangle fans). I'll probably compose mine, and compare results to offline renderers and my own OpenGL 4.1 engine.

Optimizing

2011-01-19T15:28:00.000-08:00

Raising performance with KD-trees is really important part of code, one has to write fast and cache-wise traversal, along with being careful at construction phase - Surface Area Heuristics is really important part, it can make ray tracer run like hell, or die (very, and I mean really very) slowly in pain.

I prefer first way, to make it run like hell - 1.54 MRays/s showed on screenshot is definitely not good! Still it uses single core, but I can do better - I mostly finished some traversal optimisations, tripled triangle count in scene (performance stood the same - so I'm definitely not triangle bound right now) ... so right now I'll focus on implementing median and surface area heuristics - instead of naive.

So next things are:

Median, SAH splitting in KD Building process
Optimizing KD-tree cache-wise
Optimizing traversal further
Doing some black magic?

KD-trees

2011-01-16T17:50:00.000-08:00

Ok, so I've said myself to try some KD-trees and write a new code to them ... (I haven't touched them for a while and I wanna rewrite my old code, so...) to see how they outperform todays BVHs! Of course right now I tested just primary rays with some simple single texture unit on BSP level, see some very boring screenshot.

The important thing is, I can get between 0.67 and 3.92 MRays/s on single core with median splitting KD-tree (with really unoptimised structure and pretty ugly and slow traversal) - I presume that implementing SAH could definitely double the speed at least, and more important thing, optimising speed could double or triple it again! That would be really good gain (I just need to perform some black magic on it :P).
And I'll give it at least 4 cores - that should ideally quadruple the speed. So in recent time I'll probably want to implement SAH KD tree and optimise code a bit (with lots and lots of magic).

As this is weekend project I don't know when I'll get my hands on it again. I just have too much of standard work through the week, but I might find some hours to work on it :).

Blog reset + changes to come

2011-01-09T13:07:00.000-08:00

Hello,

I've decided to reset whole blog and make it a bit more attractive (e.g. write here more professional stuff). And also to attract more people here.

I've also decided to write weekly reports here (they might be written often, and also they might not as well - but I'll try to write at least one a week) on what am I working, how my projects progressed, etc.

So I hope it will get more cool in few moments!