QA. A Rant.
Moderator: Moderators
Re: QA. A Rant.
+1 split into dedicated thread in arghs subforum
Re: QA. A Rant.
Still working on the ground FX issue. It's a puzzler, largely because I'm trying to avoid reinventing the current wheel, which, after reading, is not a very good design at all.
The current Spring code is really un-optimal; it's not even bothering with a frustrum or nearness check for whether to create things or create display lists (with the exception of tracks), which is pretty needless for short duration events (a groundflash with < 30 frames of lifetime on the other side of the map and not in POV should just get discarded, amongst other obvious things), and the shader needs to be GLSL'd so that it can use the Fog of War map to determine whether to bother with a given vertex, to save a lot of GPU, instead of brute-forcing (which would also get rid of being able to see certain things we should not see, also). This stuff is all fixable, and would save a very considerable amount of CPU per rendering pass.
Came up with a strategy that I want to pursue, after much reflection about the problem; a light and darkness map for realtime "lighting" and ground scars, basically a pair of detail maps.
This should be a fast way to do lighting of the ground surfaces without resorting to expensive display lists all the time.
Anyhow, what I'm going to try to get done would use FBO'd large textures that would get drawn to by a simple quad shader, then interpolated into the final results. So we could have lights and groundscars for a low cost, because it'd just be part of the map's rendering pass.
There are various issues, starting with the fact that it'll cost two textures if I implement it directly into the current shader, and a fairly non-trivial cost per quad, but I think that the final results, speed-wise, are probably going to be compelling, and it means that these events can happen in true realtime, for unsynced glows the follow projectiles, better handling of lighting around characters, things like fast blob shadows that follow terrain, etc.
Perhaps I can get around the loss of the sixth splat texture by simply shifting some RGB values (I think I have enough spare channels atm), although that will make building sixth splats a lot less trivial. Dunno yet, still puzzling out how to write the FBO logic.
The current Spring code is really un-optimal; it's not even bothering with a frustrum or nearness check for whether to create things or create display lists (with the exception of tracks), which is pretty needless for short duration events (a groundflash with < 30 frames of lifetime on the other side of the map and not in POV should just get discarded, amongst other obvious things), and the shader needs to be GLSL'd so that it can use the Fog of War map to determine whether to bother with a given vertex, to save a lot of GPU, instead of brute-forcing (which would also get rid of being able to see certain things we should not see, also). This stuff is all fixable, and would save a very considerable amount of CPU per rendering pass.
Came up with a strategy that I want to pursue, after much reflection about the problem; a light and darkness map for realtime "lighting" and ground scars, basically a pair of detail maps.
This should be a fast way to do lighting of the ground surfaces without resorting to expensive display lists all the time.
Anyhow, what I'm going to try to get done would use FBO'd large textures that would get drawn to by a simple quad shader, then interpolated into the final results. So we could have lights and groundscars for a low cost, because it'd just be part of the map's rendering pass.
There are various issues, starting with the fact that it'll cost two textures if I implement it directly into the current shader, and a fairly non-trivial cost per quad, but I think that the final results, speed-wise, are probably going to be compelling, and it means that these events can happen in true realtime, for unsynced glows the follow projectiles, better handling of lighting around characters, things like fast blob shadows that follow terrain, etc.
Perhaps I can get around the loss of the sixth splat texture by simply shifting some RGB values (I think I have enough spare channels atm), although that will make building sixth splats a lot less trivial. Dunno yet, still puzzling out how to write the FBO logic.