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.
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.
I actually thought off a solution some time back (I even used it on CPU to still achieve 2-bytes per KDTree node on 64-bits machines), I wonder whether this one is actually the only solution right now... :
So, I actually pass array of CPrimitiveContainer and array of unsigned integers (where the mPrimitivesPtr is index where the primitive IDs begin in mPrimitiveIDs array.
This works and seems (to me) to be only way to transfer arrays of arrays (of arrays of ....) to OpenCL (which is quite logical - as I can't just pass pointer and hope that it will work, as all data transfered to VRAM has different address than in RAM).
You can actually do nyanit.com with anything (even with nyan.cat, not just gamedev.net) and you can catch them (and kill them) if you won't, they grow bigger. Though it has pretty poor performance (they're lagging a bit)