Spring RTS Engine

Apparently if I want splatting I am going to have to do it >:|


so... I was doing some reading. there is a blender example but I don't see his shader script:
http://www.yofrankie.org/glsl-splatting/


Then there is this thread on the irrlicht forum:
http://irrlicht.sourceforge.net/phpBB2/ ... 3182cb0e29


So I guess my really thoughts are, lets start simple...


how would I apply a tiled texture with an alpha to control overlay. Zwzsg, I know you have done some serious work with spring and rendering the map in lua..

let's say for simplicities sake, most of the map will no be deformable. The areas that will be deformable will use the underlying smf textural info...

however for now... how would I tile a image across a map with an alpha to control the overlay?

For those not in the know, this is what I want to do:

All I did was a gadget to disable the regular Spring ground rendering, and replacing it with my own tile drawing code. (And also procedurally generate the heightmap, but that's not the subject here). I didn't do anything with alpha and overlay.

See \LuaRules\Gadgets\BalladiumMap.lua inside http://springfiles.com/2114
The tiles are in \bitmaps\kpmaps\kpmaptiles.png

Basically, for each layer, you'll want to send the alpha texture and the diffuse texture, and use GLSL to control blending per fragment (you can do it in fixed-function, but it will be considerably slower).

There are a couple of ways to do that. Probably the easiest is to build the display list and for each quad, store its X,Z position in the grid array in one of the multitexcoords, then read it back in the shader, giving you the X,Z texture coordinates of the blend texture to read (btw, this means that, amongst other things, the blend textures could be arbitrarily sized, assuming the math operates on the assumption of 1:1 correspondence with heightmap -1). I use a similar technique in P.O.P.S., after jK explained that that is a very efficient way to do things, and it works well.

Another idea that occurred to me is that if you build multiple display lists as square "chunks", you don't even have to tile the texture, which may make it run a lot faster, since chunks not in POV could be culled before they go through most of the CPU steps.

smoth wrote:For those not in the know, this is what I want to do:

Isn't this exactly what sm3 does?
And btw this method is only efficient for just screen filling renderers.
It waste a lot performance when you have a large map and limit a lot of texture splatting on small areas (the texture lookups for each texture layers needs always to be done on the whole map, but you will just render a 1-2 layers per maptexel -> waste of time).
So such a technique needs a lot of optimizations to perform well on very large maps with many texture layers.

jK wrote:Isn't this exactly what sm3 does?

yes but sm3 doesn't work.

smoth wrote:

jK wrote:Isn't this exactly what sm3 does?

yes but sm3 doesn't work.

^^ This.