Jump to content

  • Log In with Google      Sign In   
  • Create Account

Vilem Otte

Member Since 11 May 2006
Offline Last Active Feb 05 2016 06:46 AM

Topics I've Started

Compute Shader vs Transform Feedback

09 September 2015 - 03:58 AM

Recently I've stumbled across few things inside particle systems in my own engine. Previously a lot of my particle simulation was done on the CPU (not that it would be too slow, but hey, I need by CPU more free for other computations), therefore I re-written them to work on the GPU. There are actually 2 ways I've implemented particles - the transform feedback (where geometry shader takes care of particle system) and compute shader. As for performance, I haven't seen any major difference in between these two techniques (assuming they are doing the same calculations).


Now, both implementations are just a basic particle system (a lot more simple than what I have on CPU currently), now - if I'd like to add things like collision detection and response for particles (I have collision geometry stored as shapes inside BVHs), applying 'wind' on them (velocity voxel-grid, precomputed), and also forming animations where particles form some sort of geometry surface -> which is a better way to go?


From my point of view compute shader based simulation might be better, but I guess that you can do all this stuff using both solutions. If you tried both, please also share some experience.


02 July 2015 - 08:30 PM

I know this one is not strictly game dev and so it belongs to lounge. I hope there are also other game developers who do the cooking!


Actually, for anyone who also tries to cook from time to time, I wanted to ask (especially few of you who live or lived in Japan) - I tried several different recipes on ramen, plus in restaurants, but that thing tastes different each time (note that it tastes good each single time). Do you have some custom recipe for your own? I'm very curious about that!

Do you extend GLSL?

18 July 2013 - 06:17 PM

I would like to know if anyone else out there extends GLSL by some pre-processing by C++ code? If you do, how much preprocessing do you use?

Do you implement includes? Do you implement "target" specification in shader (e.g. which code path to use with "shader model 3.0", with "shader model 4.0", etc.) ... e.g. somewhat extending GLSL to allow as much stuff as HLSL allows us to do.

Managing large worlds

02 July 2013 - 05:31 PM


I'd like to discuss question and possibly get confirmation of what I've got so far on "the management" of large scale worlds.

First of all - let's further assume that my world consists of section (square tiles), for simplicity 100x100 meters. As player moves, the tiles load/unload from memory (for simplicity, the config file describes how many tiles is loaded, whether 3x3 or 5x5 or generally NxN).

Graphics - each tile contains the list of resources (meshes, textures, shaders, materials), upon crossing the tile border, some stuff might be load/unload. First of all I do load phase (items in resource list, not already in memory gets loaded (streamed from hard drive)), then I do unload phase (items that are not anymore needed - e.g. they were needed in tile that just "popped out" - are removed from memory).
Now, as the world grows, the imprecision problems might appear. There are two possible ways to fix this (and I'd like to know which one is more practical). First is very simple, use fixed-point. Although I'd still rather stick with floats (all libraries I use work primarily with them), so the second one: Each tile contains its absolute position in the world, and each object on tile contains relative position on tile. The tile where player currently stands always originates at 0, and as he crossed the border, he is moved along with world (of course the "move" is invisible).
This works flawlessly for static objects (they're all time on the same place, so they're all time in the exactly same tile. This leads to first problem, dynamic objects and physics.

Physics - static objects (including terrain) are simple, I can add new ones and pop out old ones, and translate them as player moves. Dynamic objects are worse - they can fall over static tile edge (as the world after last loaded static tile is non-existent), this can be solved by modificaton - let's say I load 5x5 tiles with statics only and 3x3 with dynamics. The true problem though is, that they can also cross tile boundary (and they're not anymore on tile that holds them) ... storing the owner of the dynamic object (e.g. tile)? Although storing this would need to store current world data (just changes to base world), but savegames (*insert desparate scream here*) would take hell lot of data as game would progress?! ... From what I know, the games with large scale worlds ignore this and dynamic objects cease to exist when player just moves away, and are reset when he comes back to location.

Actors - and generally AI. Simulating every actor in the world is possible, but only for worlds with small count of people. Or better, simulating only actors in active cells, and estimating whether travelling actors can cross current cell at given game time (and possibly spawning them and simulating them). As they should be mostly script driven, it is simple to estimate this.
"Local AI" like simulation of animals and their possible attacking/following player is done only in active cells, so it is actually the same as in standard game (where whole level/scene/... is in memory).

Any hints on my thinking is welcome. Or if there are some really, really wrong ideas in this one, please let me know.

TexSubImage2D weirdness

17 September 2012 - 11:36 AM


I'd like to ask - I'm updating half of the texture with OpenCL program and another half on CPU. But calling:

glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, width, (height - delta_height), GL_RGBA, GL_FLOAT, data_v);

Updates half of the texture (done by CPU) and ignores texture updated by OpenCL. Note that I make sure that OpenCL finishes before I do the TexSubImage call.

Any idea/hint (e.g. what I missed)?