Spring RTS Engine

I am pretty sure it's three things:

1. The tiles should be a lot larger, and not bother trying to be optimized in terms of fetch and sort (other than culling outside the frustrum), because it eats more CPU than it's worth, for typical use cases (i.e., practically nobody is building maps that use a lot of tiling, other than a few butt-ugly metal maps and a few of Forb's designs). I hardly even bother with compression, because it doesn't work well and the performance impact just isn't worth seeing a nice map turned into a mess.

IOW... instead of fetching hundreds of sectors and having to do all the calculations for figuring out what texture coordinates to use, etc., it should fetch big chunks, with big textures (1024s for 128 sectors, test to find sectors in frustum by doing ray collisions with cubes).

I can't prove that this will work better yet, and I expect to be told it won't, again. But what this little experiment seems to indicate, at least to me, is that geometry and texture throughput is not the problem. It's CPU getting wasted left and right on attempts at optimizing things that aren't actually getting used by the vast majority of maps.

I think that when JC wrote SMF, he was thinking we'd be happy with tileset textures, basically, and it just never worked out in terms of tradeoffs- the kinds of maps we want to build, vs. what the engine is designed to do, are in conflict.

2. The ROAM algorithm needs to get finished. I was rather disappointed how small of an impact it made on total performance, but it's an optimization, and hopefully along the way somebody will write a callin for Lua so that people like me who want to play around with alternative rendering schemas can fetch the ROAM'd heightmap.

3. The size of the heightmap resolution is an issue in terms of cost of the pathfinder (and a billion other things in this engine) vs. beauty. A properly implemented SMF, imo, would use a half-resolution heightmap, vs. current spec, and a normalmap / depthmap texture pass. It would look twice as good, and run faster as well.

I've said most of that several times though, and gotten nowhere. It's just Not Fun re-writing the map / pathfinder to be able to do stuff outside it's current specifications, and I can't blame people for not getting all that excited about it, without stronger arguments in favor of change.

Doesn't it use 1024 tiles?...

He imo meant using big tiles - e.g. a map consisting of 128 big "tiles" having a 1024x1024 texture each...

As far as I know when the map is loaded is loaded it stitches the texture together into 1024x1024 tiles, so that CPU waste isn't happening. Is this incorrect?

Argh wrote:I posted my first practical shot of this practical application in the Lua sub-forum, because I need some help with a non-trivial algorithm.

Haven't even messed with forced drawing / optimization yet, but it looks like my prediction that prebuilt geometry would be a lot faster than the SMF renderer is pretty much right on the money. I am starting to suspect that the only real performance limit is the geometry limit of the card, since it's barely using CPU at all.

Remember you're losing all the layered effects on the landscape too - groundscars et al. I'll bet that supporting the layers for those features probably isn't free, even when there are no groundscars or shadows or whatnot on the map.

As far as I know when the map is loaded is loaded it stitches the texture together into 1024x1024 tiles, so that CPU waste isn't happening. Is this incorrect?

Essentially, yes, unless it works completely differently than how it's been described in the past.

Basically, when the map is built, the texture gets cut up into thousands of swatches. The compression algorithm searches for matches, and if it finds any it tags each swatch, and assigns each swatch to a heightmap fragment.

These heightmap fragments are very small- 32X32 heightmap squares, maybe even 16X16, I forget.

So, each render pass, the heightmap fragments have to be combined with the texture swatches before they can be passed to the ARB shader.

That is how I think it works.

What I'm saying, though, is that I don't think that that is a good strategy, given the maps that we actually want to make. Amongst other problems, it means that pre-fetch is hard- hence jK writing the PBO to store the map texture chunks.

That speeds up transfer from RAM to GPU via DMA, but it doesn't really help a lot with all the heavy lifting that's required on the CPU end (why it's advertised in SpringSettings as being good for people with low texture RAM is beyond me, btw- those are the very same people who are generally CPU-bound, not GPU-bound, on this engine, and what they need is the option to force textures to lose the top mip level to get texture RAM requirements under control, imo).

I thought they were 32x32 texture squares - is in, about the size of a windows desktop icon - not just heightmap squares.

Yeah, you're right. So... they'd be... eh... 4 pixels of heightmap (with some giant float).

That's even worse than I thought it was, considering that in the average POV, we're viewing somewhere between 128 and 256 heightmap squares.

So, for each pass... at 128... that's 32^2 match-up operations, texture coordinate assignments, etc.

Whereas what I'm proposing would be (typically) four. And it'd be four from a static grid, with no large search time, too. 1024 vs. 4. Think about it.

Wouldn't bridges and tunnels require Spring to support a collision mesh?

The game would have to get rid of the spherical hitboxes and switch to requiring map features and/or? units to use its own custom collision mesh for this to work, right?

That is how most modern games do it afaik.

The game would require its own new model format too right?

Good questions.

Wouldn't bridges and tunnels require Spring to support a collision mesh?

Bridges don't require a collision mesh. Tunnels do. The problem is that people think they're the same thing, since a bridge is also a tunnel, in the real world.

A "bridge" is just some geometry that looks like it crosses an uncrossable place.

A "tunnel", however, has to have a hole that can be entered, but a cap that can be driven over, as well.

I can do bridges with that demo in the Lua forum. I can even fake tunnels pretty well. True tunnels, though, no. That's going to require a whole 'nother approach.

The game would have to get rid of the spherical hitboxes and switch to requiring map features and/or? units to use its own custom collision mesh for this to work, right?

Not really. You can have collisions between mesh geometry and simple primitives, it's not either / or.

The main thing to keep in mind is that true 3D has major ramifications for pathfinding, which is why those of us thinking about these issues on this engine want to avoid anything that requires an entirely new pathfinder. Other than Kloot and maybe Hoijui, I don't think anybody here even has the skillsets required.

That is how most modern games do it afaik.

Yeah, kind of. Most FPS shooters are still using portal-based systems, and collisions are either with meshes, like you're describing, or with map brushes. Crysis was really slow, at least on every computer I saw it run on, when you were in scenes built mainly with props and collision meshes, instead of a lot of brushes, and combat started to require a lot of collision checks. Today's consumer-grade, multicore PCs can handle a lot more now, though.

But basically, I'd like to look at solutions that will still run on my hardware, if possible, so even if it's feasible, I'm not really excited about it.



Most RTS games are still using a heightmap, I suspect. They're just not necessarily drawing it.

The game would require its own new model format too right?

Yes and no, if it went full 3D. Maps would have to become geometry, with full collision meshes built in, so that we could cheat sensibly, and use a lower-resolution collision mesh on map geometry where it wouldn't be obvious (for example, a small tree just needs a cube, a giant column with 64 facets could have a collision mesh for that part that was merely 8, etc. This would mean building a map took an awfully long time, though, and be almost entirely out of the reach of newbies, though.

For that reason alone, I'm not really in favor of this concept of a true-3D solution. A tile system like my demo is actually a better idea, especially if the tiles can be arbitrary geometry (hence my request) and can be S3Os, which are already handled quite efficiently by the engine.

Moreover... meh... I'll probably never get to build it, since doing it by hand would be really, really painful... but in theory, we could use tile geometry, not just a 2D polygon intersection, but a 3D one... to set up heightmap geometry. IOW, we could model a hill, texture it, and make it a tile, and it would reshape the heightmap, so that what you see is pretty close to what you get.

This is how Freelancer handled collisions, as well as most FPS games. The problem there is very simply, it's very expensive to do that on the CPU, and RTS CPU requirements are already considerably worse than a really well-designed FPS should be. I just don't think it's practical, frankly. It would look great until we started scaling it up, then we'd hit a huge wall, performance-wise.

I've already hit several other walls, and I'm pretty sure I know where things are bound up, so I kinda want to take things in a different direction.

I know they're in 32 pixel tiles in the map format, but what I've been saying all along is that afaik they get combined into 1024 tiles of actual map texture ingame, exactly what you want.


It's not a real bridge if you go under it, but fake bridges are certainly valuable in some situations.

lurker wrote:I know they're in 32 pixel tiles in the map format, but what I've been saying all along is that afaik they get combined into 1024 tiles of actual map texture ingame, exactly what you want.


It's not a real bridge if you go under it, but fake bridges are certainly valuable in some situations.

A feature worth looking into would be a "fake landscape" that is offset from the true landscape. That is, for the purposes of all unit motion and lua, the landscape is at X when graphically, it's at Y. Of course, this would result in ugly behavior with projectile collisions. It would be a good way to do bridges.

You could have a voidmap, geometry in the X-colored area doesn't render. You're rendering a level with lua anyway, probably not a huge need to specify a full heightmap to change normal rendering.

Voidmap would be good for a tile-based map, but I was thinking more about bridges and other mesh-based constructs existing as small additions to a typical landscape-based map.