Spring RTS Engine

I have figured out what I think is a good idea for allowing bridges and other fancy stuff.

I think this might even be reasonably simple.

Allow for heightmap changes that came with a certain tag that prevented them from being translated into geometry changes. Or, alternatively, just give us a callout for masking an area, and then any changes to this area would be ignored by the SMF interpreter.

This would achieve all of the goals for bridges and other things where we want heightmap changes but don't want visual changes in the rendered geometry (we could use Lua to raise the heightmap, but apply that mask value, voila), but:

1. We'd need to be able to see the true heightmap to debug, I guess wireframe could do that.

2. The map interpreter would have to accept a mask value for those squares, and act like they were at the original height when drawing the geometry. It would ignore all heightmap changes in the masked zone, basically.

3. Ideally... Units could have a state, set via Lua, that allowed them to also ignore the heightmap's true state, and use the original state. This probably can't be done for mobile Units, but it's not what I had in mind. This would allow for some very interesting stuff to happen all of a sudden.

Hey, if we had this, and GLSL shader support for SMF, we could pretty much do what we've seen in SupCom 2's map rendering, and doing really fancy mixed-media maps with "blocked off" areas that also affected aircraft flight would be entirely possible. Want your map to have impassible, indestructible zones? This would allow you to do that, and if the Unit tag in #3 were allowed, then you could put forests or rocks or rubble or whatever you wanted in those zones, providing a visual reason why players were blocked.

Hell, we could even use this and some typemap stuff (if Kloot ever responds to my PM about certain testing problems that still need to be addressed) to put invisible, aircraft-friendly slopes around cliff zones that ground Units couldn't use, and other things, etc. All we need is a mask-state and the change to ROAM, basically, to treat the areas as if no damage had occurred. I suppose that in some circumstances, this could lead to odd behavior (aircraft slamming into "air", etc.), but that's something that could be managed with experimentation.

Oh, and we could also use this to have factories whose floors weren't on the ground level.

Basically, this isn't a panacea and doesn't give us 3D maps, but it would be awfully close.

Is this already possible with transparent bits in the texture?

Well, this is my initial thought:

A. No, because making it transparent means we have to paper it over with OpenGL, which won't look as good.

B. The last bit I saw about that was jK's comments to Behirith about how he ran into this obscure feature of SMF without knowing it was there... and I dunno whether any of the current systems for compiling can properly set it up, and I don't see a Lua callout for doing it arbitrarily, which makes me think it's a static SMF thing- which is really, really, really *not* what we want.

I misread your post at 4am, doesn't the forum tell you when the topic changes before you reply

Yeah, but it's 4AM here too, and I wrote that bit about Units (no. 3, which is kinda vital) after you posted, so you probably didn't misread so much as try to correct my faulty logic. It's all good.

Seems like a mess, honestly. To maintain two different heightmaps, having some functions apply to both, some apply to one, some apply to the other.

(if Kloot ever responds to my PM about certain testing problems that still need to be addressed)

It's called "being busy". I'm also not convinced these PF attraction problems even exist, based on my own tests (with a modified copy of your gadget). AFAICS, the code works.

I don't see the real gain in your suggestion. It'd be easier to just take your bridge model, do a top-down height scan, save that into a bitmap and paste it on the heightmap the pathfinder uses before the pathfinding gets done. That should lead to pretty much the exact same kind of limited bridges (as you still wont have anything going under it)...

Real bridges imo need several pathfinding layers - e.g. for a bridge over a river where ships just use a heightmap without the bridges included while ground units get a pathfinding based on the copypasted bridge heightmap. You'd be able to have units going over your bridge just as under it - all you'd need from that point on is a clever algorithm for amphibic units which just change the pathfinding layer once they enter the water (the algorithm would need to give clever places for the switching points which shouldn't be that hard to guess (as the water is just a plain area) but as nobody wants to touch the pathfinding I guess this won't ever happen)...

Ive learned alot of the terrain rendering engine for smf in spring, and having a separate heightmap just used for rendering is very simple IF mapdamage=false. I can look into implementing it once I get spring running again.

@Kloot: I understand the "busy" part. I know that I've observed Units obeying the higher speeds, but the PF result doesn't seem to be all that different, even at 2X the speed or greater. Perhaps the issues's being caused by the steering code (which is still avoiding Units even if they are no-block)? Maybe I need to use zones that are twice the current width (aiiieee).

@Master-Athmos: Prolly the easiest single way to implement true multi-height is the one that sounds the hardest- write a new pathfinder from scratch, write a new map format fundamentally change Spring. If I had anything like the knowledge required to begin tackling that, I'd write a proposal. I haven't made that a priority.

@Behirith: you're stopping because an ARB shader won't compile on your awful Intel chipset, yes? It seems that more and more hardware is falling into this category. The only way out is GLSL to replace the ARB stuff and some safe fixed-function stuff if that fails to compile. If you'd like, maybe we can all talk seriously about this issue, I would probably be willing to contribute time to porting the shaders if somebody else was willing to tinker with the engine-side stuff.

Argh dont worry about it, things should be back to normal for me in 2 weeks.