I think that this should get used.
This is how all of the current-gen RTS games have been kicking our ass, visually, in terms of map formats. Just needs to be ported to GLSL from HLSL.
For the very short version... so far as I can determine, this is SMF-style rendering, performed almost entirely on the GPU. I'll let jK/JC comment if they wanna, but it appears that SMF just uses Losasso / Hoppe, which is highly CPU-dependent, see their notes about performance, etc.
This would probably not even require a new map format (i.e., it could just be an optional thing in SpringSettings, and voila, huge drop in CPU usage for all video hardware from 6800 up, iow... anything even vaguely modern), although inclusion of normalmaps in a SMF-like format would mean that our map renderer finally reached the level of quality seen in modern games.
Long version:
Basically, the problem is in where tessellation's occurring and very inefficient use of the GPU-->CPU. That article discusses one way around this issue, and I thought it was useful- decompress the data, just like SMF is doing... but never do any vertex generation on the CPU. Seems like a winner to me, less pain.
Other approaches I've been looking at / thinking about...
Meh, I read way too many articles about this, trying to figure out what, if anything, could be done. These seem to be the best choices available:
1. Tesselate manually (i.e., fixed mesh, designed / optimized by artists). Pros: potentially great performance- low-detail areas can be optimized far better than Lossaso-Hoppe, high-detail areas can have a vertex shader applied to tesselate the meshes at render time, so it will be pretty as hell. Cons: too many to mention, starting with the need for a tool to "slice and dice" meshes so that culling is practical. We'd need a brand-new toolset, or a radical use of existing tools (i.e., I haven't yet found any research or evidence to support the idea that low-poly mesh slices could be easily made without having serious issues with water-tightness at render time). Long story short: while I could see myself wasting a week on a tech demo that would look awesome, I think it's an utterly dead end.
2. Use a lower heightmap resolution, use splatting. This has been the trend up to the most modern engines I've seen, other than WiC. Pros: better performance than SMF, because that power-of-two difference in resolution really matters quite a bit. Cons: inflexible levels of detail, probably wouldn't be welcomed by artists used to SMF's theoretical (although practically never seen IRL) levels of beauty... and nobody around here has proposed anything like a working splat model that would run really efficiently in realtime.
I came up with a partial solution to that, just doing back-of-envelope bullshit- instead of JC's approach, where multiple large alpha maps are interpolating between steps (which is bad, because it requires at least two steps of vertex re-creation) I was thinking that splats could be stored as point data, for better culling performance, and you'd have a very small resulting texture atlas where points corresponded to splats, with a base layer and only one level of interpolation, and you'd just average each level for each splat, so multiple overlapping splats would get expensive, but it would be a local optimization problem, not a global problem like it was in SM3.
I think that this is workable, personally, and I'm probably going to try and implement a model of this next week, using a SMF map as the base, with a simple tile for maximum non-suck, and then use a bunch of "splats" done with Spring's existing support of same, i.e., the ground-textures we currently have. That won't work well in the SMF framework, however, because before the efficient pixel / vertex programs can do their thing... the CPU has to do a bunch of tessellation, and provide them with vertexes to work with. Therein lieth the suck. This is why ground-textures of all kinds run so damn slowly, not because those shaders are terrible.
Whatever I am able to do will, because of that limitation, not be a workable alternative pipeline, I expect.
3. Explore entirely volumetric approaches using voxelmaps. Pros: the examples I've seen are very impressive- people have finally figured out how to do really amazing mip-mapped voxel stuff on fixed-function GPUs now, with huge triangle rates on the flip side and amazing levels of fidelity. Cons: I have yet to read any public source for this stuff, let alone gimme code, and I have no fucking clue how it works, nor do I think I could ever understand the math involved. So I'm entirely at a loss as to how to present any evidence as to whether or not it's a place worth visiting, or where we could practically go with this, let alone in a timeframe that mattered.
4. Using an entirely volumetric approach using a normalmap and a distortion map that also doubled as our effective heightmap, perhaps at a lower mip level for pathfinding / LOS. I think that this is practical, but in practice, where does it really differ from what I've proposed? Well, it would involve a fundamental rewrite of the pathfinder, is what. Our pathfinder isn't going to handle that sort of situation very well, I don't think, at least if it allowed for the kind of flexibility that it should (i.e., if a mapper wanted to use a lower real heightmap rez, because the map has mainly gross features... and just makes it look incredibly detailed with parallax stuff or volumes, they could, which could be radically awesome, in terms of presentation imo). And we'd face a lot of resistance from people, because it would be a modern-GPU standard, older crappier hardware would be in the cold. I'd rather maintain a legacy mode that is available side-by-side, and I cannot see how this approach could be reconciled with it.
At any rate... meh, these are my current thoughts. I think SMF needs to get replaced with something decent soon. I don't think it'll matter for my project, and I'm not even worrying about it, beyond little experimental things on my way to release.
I'll just do baked-on micro-details in my final MP maps for RC4, like the other mappers are starting to do, and that's still going to look like ass, compared to a modern game. So... meh, if nobody wants to bother, fine, it won't matter to me anyhow, I'm just saying that that's a major feature that we're missing, that it appears that solutions do exist, it's not like these things haven't been done outside this place, and I find it a bit mystifying why everybody's just settling for sullen frustration about it since SM3 failed, instead of proposing something, anything else.
My little experiment will get done this week, just to see what can be done with the icky limitations of SMF, but it'll be quick and rough... and meh... now that I've done my homework, I have a pretty good idea of where the suck is... and the good news is, it should be something we can work around, and in a way that doesn't leave old-hardware folks in the cold. The bad news is... I think jK's work pretty much pushed the CPU-side optimizations to the absolute wall, there isn't anywhere further to go.
Everything past here, no matter what I read, involves using the GPU. The question is methods and means, it's not a question of whether there is some magical way out. Spring's mainly CPU-bound, and a fairly large chunk it is in the Unit rendering pipeline (which should be changing very soon) and the map format.
But the bigger issue is that, in terms of quality, we simply cannot expect this engine to compete with modern engines until we get serious about using the GPU as the primary tool for anything touching OpenGL. When GLSL shading of Units is routine, and normalmaps are working, etc., etc., which should be any day now, we're going to have a really sudden visual discontinuity between our maps, that previously looked all right, and our Units, Features, and other 3D objects. We need to get serious about this topic, moving forward, or we're going to plateau and the project's effectively reached an end-point, in terms of practical appeal to a wider audience, imo. I mean... no offense, but when I show anything that ain't my game to gamers who aren't excited about OTA... they basically declare that it looks like crap, and they'd never play it. Since I don't have Gundam or IW or S'44 to show them, my somewhat-feeble, "I swear, there are more decent-looking games for this engine" falls on deaf ears. It's really interesting, tbh- as the engine gets further behind graphically, about the only real appeal is to major OTA fans at this point. Kinda explains a lot about the Lobby population.
Oh, and this is pretty fascinating reading, hearing Carmack's (slightly dated) discussion of all of this. Seems the fancy voxel stuff really is what he thinks might be the killer tech, and I really liked his discussions about auto-decimation / procedural content, mainly because I'm entirely in agreement with his analysis, as most of you know
http://www.pcper.com/article.php?aid=532
