HLSL rules!

Texture splatting using my own shader program is now ready. I must confess I should have migrated to shaders a long time ago. I’m always afraid to have to deal with hardware incompatibilities, but benefits are huge. The same result (even better) with less texture units… and so programmable pipelines can be faster than fixed ones!! I realized too that I now have extra “space” to add further  terrain effects on a single pass in the future.

Nothing is perfect… I’d like Nyne to be able to run on aging laptops, so I’m dealing with old shader version restrictions. But that’s still simpler than the old way. Moreover, I still have plenty of data space directly on vertex… and so more improvements to come!


Alpha with fragment shader

Still working on my HLSL fragment program for terrain splatting. Above is my alpha map.

alpha    = alpha*alpha + alpha * dupCO.r * dupCO.g ;
alpha    = sqrt( alpha ) ;
alpha    = clamp( alpha , 0 , 1 ) ;

Simple process with the under laying texture to avoid a too smooth texture transition. Not perfect… but it’ll be my starting point !

Fixed pipelines s*cks

Up to now, splatting was achieved using the fixed-pipeline. But 1/ PSSM needs for itself 3 texture units so I won’t be able to integrate this on a one-pass texture. And 2/ Fixed and programmable pipelines can’t deal together… I have to say good-bye to my old beloved fixed texture unit functions and switch to a full vertex shaders solution. That’s life…

Splatting: done!

I got finally my own splatting working. Here is the rendering while flying approx. 2000 meters high. I still need to generate the whole texturing of planets, but I’ve got definitively my 256 textures system working.

I always benchmark any of my functions and I was quite surprise of dynamic texture generation time, not what I expected. Either I didn’t understood clearly enough mode definitions, or there is some drivers issues!

Ogre::HardwarePixelBufferSharedPtr pixelBuffer = mDynTexture->getBuffer();
// pixelBuffer->lock( Ogre::HardwareBuffer::HBL_DISCARD ) ;    // slow version
pixelBuffer->lock( Ogre::HardwareBuffer::HBL_NORMAL ) ;   // Fast!

Tiles puzzle

I’m still working on alpha texture generation. The splatting of two textures is child-proof. But upgrading this to mix dozens or hundreds of textures for a whole planet is… rather… painful!

Because of differents LOD for tiles, there is 2^16 (65536) different alpha combinaisons. No way to keep a such amount of textures in memory, of course. Dynamic creation itself is simple as possible: a basic texture alpha, then a bunch of memcpy(). But the thing is to create splitted alpha map. Like unpredictable portion of the terrain, at any scale.

I never been a puzzle game addict… ^^’

setColourOperationEx maniac!

I can only manage 2 textures for now, but my texture recipe is clean. I need very slow transitions, while very detailed textures. I think I’m OK with this quality.

The basic material uses from 6 to 8 texture units (#3+4 are optional, only for maximum splatting quality).

// down texture

// down texture details

// base alpha

// detailed alpha 1 (optional)
3->setColourOperationEx(LBX_SOURCE1, LBS_CURRENT);

// detailed alpha 2 (optional)
4->setColourOperationEx(LBX_SOURCE1, LBS_CURRENT);

// up texture
5->setAlphaOperation(LBX_MODULATE,LBS_MANUAL, LBS_CURRENT,detail_alpha);

// up texture detail

// lighting

Splatting the world…

Step by step. Now, let’s paint the world. The point is to mix different textures smoothly. I’m not gonna need a lot of textures on small scale, but rather a huge amount on large scale. From a technical point of view, it should be more simple. But from a cognitive one, sure it’s gonna be a complete headache 😉