Spring RTS Engine

I'm adding a dynamic heightmap texture, and
making it available to lua. Here's an example of
a new rendering technique that this enables:


http://trepan.bzflag.bz/spring/video/volcano.theora.ogg
(20 MB video, poor framing)


A few heightmap notes:

1. The heightmap texture is automatically updated for
ground damage (that's actually the main reason for
having it).

2. You'll need a decent GPU to use it. It requires non-
power-of-two textures, and more importantly FLOAT32
textures.

3. The texture is setup for NEAREST filtering. Do your
own bilinear filtering if you really need it (which I did
for the volcano effect).

4. The heightmap can be used to draw ground decals
very quickly with lua (probably faster than the engine).
A covered a complete 16x16 map with a decal and got
around 30 fps.

5. The height map texture can be disabled by clients
by setting the "HeightMapTexture" config parameter
to 0.


A few volcano notes:

1. It looks a lot better on my screen than in this vid.

2. It's synced to the game frames (although I did
pause the game during the filming, you can barely
tell because of the skipped frames and camera motion).

3. It's completely unoptimized. I'm sure it could be made
to run faster.

4. Used two RGBA32F textures, pos(vec3) and vel(vec3).
The trailing floats contain the particle age and time since
the last bounce, but those values aren't being used.

5. It uses the MRT (multi render target) feature I added in
0.76b1 (along with ping-pong RTT for the RGBA32F textures)


Basic HeightMap example:


Color graded decal shader:

So we can generate decals with lua now?

You already could.
gl.DrawGroundQuad()

So what does it do? Why does a new dynamic heightmap texture allow particle effects.

What does it do? It gives you access to the current terrain
height in the GPU. Nothing more, nothing less. There are all
kinds of rendering and simulation algorithms that benefit from
having this information readily available.

The reason this is required for the volcano demo is that the
particles are processed entirely on the GPU. The ground
collisions, bounce normals, particle position, and particle
velocity are calculated in a fragment shader and stored into
2 textures (at the same time using MRT). Then the display
vertex shader use VTFs (vertex texture fetches), to get the
position and velocity for each particle.

I can have about 500,000 dynamic particles floating about
without having any load on the CPU (and still have a reasonable
frame rate). The same can not be said for raw engine particles
or jK's cool LUPS system. Also note that although this is all
setup with lua, all of the real grind is done on the GPU.

Ok, I can see the point of the particle via GPU stuff. Question being, then... why not rewrite Spring's C++ particle code, so that if shader support is present, it uses this much-faster method, if not, it uses the current, very CPU-heavy method? CEGs are a major performance drag- if this can be accelerated a great deal, that's wonderful news, frankly, because it'd free up CPU a lot, for all but the lowest-end systems.

Sure, let us know when you're done with the rewrite.

Wouldn't it require a simple if/then switch, based on whether the user's card passed the shader tests? I mean, shader support is shader support, OpenGL is OpenGL. And this is shader-language stuff, right?

And, at a practical production level, we need a practical way to pass parameters to it, why not use the parameters we already know and like, for CEGs?

Because all the CEG particles are custom things with custom methods and custom properties it will be near impossible to rewrite them to run on the GPU, while retaining compatibility.

It'd probably be more advantageous to:

• entirely redesign the system in a way that can be represented more easily on the GPU, not caring about compatibility at all,
• or to extent the current projectiles with hardware accelerated particle systems, with possibly less scriptability (though I can imagine the shader could be made mod defined too) but more efficiency.

The first thing has downside that it breaks compatibility and that probably no one will do it because of the non-locality, ie. lots of things to change througout the entire engine. The second should be very possible.

extent the current projectiles with hardware accelerated particle systems, with possibly less scriptability (though I can imagine the shader could be made mod defined too) but more efficiency.

Does that mean "new projectile types", as in "universal types" that can be passed some parameters and be used, maybe with custom shader language stuff if absolutely required, but broad enough in functionality that it can be used to duplicate, say, a CSimpleParticleSystem or Smoke? That'd be super-sweet...

I don't really want, or see a practical need, to rip out the CEG stuff. If it suddenly becomes a "backup", because there's something that performs better and is easy to use, great, I'd then be able to rip the CEGs in P.U.R.E. down to basics, then use this. But it really has to be easy to use, guys. I can't emphasize that enough. I am maintaining dozens of CEGs, many of which have a hundred lines of code or more- I do not want life to get harder, in that respect, if at all possible, and I think that goes for most of the people making games with Spring. CEGs have been such a successful concept not just because they're pretty, but in large part because they're component parts that make a complex whole, keeping individual elements fairly easy to deal with and modify...

Ask jK to make a LUPS version that uses the same trick
as I've demo'ed (doesn't even require the heightmap
texture, 0.76b1 is sufficient). As most of the work is done
on the GPU anyways, the only CPU usage will be in making
the COB->LUA calls. Using such a setup will provide a
large amount of flexibility (and all that the LUPS++ setup
need to is keep track of the pixels).

Note that the GPU side physics sim need not be limited
to only point sprites. You can attach meshes to a specific
physics texture cell using an unassigned texture coord.
You could also do interpolations between physics texture
cells for deformations.

The LuaRules Explosion() call-in can be used to detect
explosions and block them from producing graphics (just
return "true"). You may want to use a custom
SendLuaRulesMsg() msg to let the synced side know what
the unsynced side is capable of (until an unsynced hook is
provided that allows blocking graphics).

For weapons, a call-out could be added to set which ones
can use lua rendering, and a call-in used to do the rendering.
I guess that this is where the heaviest CPU use would be.

If nothing else, you could use lua to setup the shaders and
textures for advanced hardware particle rendering. Although
yall haven't seen it, a similar setup is used in UnitRendering,
and it works quite nicely (lots of flexibility, almost no penalty).

If LUPS can support this, then I'm sold. I'd tested LUPS previously, and found it wanting, speed-wise, compared to optimized CEGs, but this would make cheaper than using CEGs by far. More pretties for cheap, yay!

Note that the GPU side physics sim need not be limited
to only point sprites. You can attach meshes to a specific
physics texture cell using an unassigned texture coord.
You could also do interpolations between physics texture
cells for deformations.

In English, you mean that we can grab .S3Os and use the meshes as "particles"? Then animate them by moving vertexes around? That'd be very nice, for a few things.

The LuaRules Explosion() call-in

That'd be COB, correct? I.E., in Killed(), we'd call-script luaExplosion(), return true, and voila? What about users who don't support shaders, though? Is there a way to test that, or get that state?

For weapons, a call-out could be added to set which ones
can use lua rendering, and a call-in used to do the rendering.

The other issue there is that the lua rendering would have to take into consideration weapon velocity, etc. That'd make it a major improvement over CEGtag.

UnitRendering, and it works quite nicely (lots of flexibility, almost no penalty).

Does this mean I'm going to finally get to see bumpmapping? I've been waiting on you to release something for months... it'd completely change my workflow, frankly.

I didn't see your submission in my "request for decimated meshes thread".
Give a little, get a little? So far I've received nothing from the one request
that made to the modster community

And no, I meant the LuaRules Explosion() call-in.

PM on the way... just be prepared, it's not what you expect it to be

I suppose any form of notifying the simulation of the particle actions (e.g. hitting a unit) is impossible?

Not impossible, but probably impractical. As an example,
let's say you wanted for particles to bounce off of static
shield installations. You could generate a lookup texture
that held that shield state at every point in the map, and
then use that as part of the ground collision.

Updating all of the unit positions and velocities every
frame is a bit much to ask, but a staggered update
approach be might worth trying.

P.S. Don't forget that none of these collisions
could be reported back to the synced code

I was thinking more about damaging units on impact so yeah.

I've added the gl.ReadPixels() call to the lua OpenGL API.
This will make it a lot easier to develop GPU-side algorithms.
The numbers in the console represent the state of the
particle in the (0, 0) texel.

Also, here's a link to the WIP volcano widget:
http://trepan.bzflag.bz/spring/lua/volcano.lua

Wow. Beautifull - that even beats the Sacrifice Vulcano.

/me wants that volcano widget on aftershock v2 :D