I got it all to work and posted the shaders and a code sample in the wiki.
hopefully this is of any use to somebody.
note: it only works for opengl, if someone wants to convert it to cg I'd be happy to help.

also, I'm rendering a single mesh in a single batch. and the number of triangles does not change compared to the regular mesh.

http://www.thermite3d.org/dokuwiki/doku.php?id=glsl_ogre_for_triplanar_texturing_and_multiple_textures

How did you handle the blending problem with one batch?

read the wiki entry ^^

I created 3 new vertices for every triangle with 2 or 3 textures. and then I pointed the index array to the new vertices. so I ended up with a few more vertices, but it's not that much

Very nice, and not an approach I had thought of. You're basically doing a single opaque pass and handling all the blending in the pixel shader. It seems like quite a heavy approach (lots of texture samples, conditional logic, and extra vertex data) so I'm not convinced you'll actually get better performance with this, but it's worth investigating. And maybe it is beneficial when you are batch bound but only profiling will tell for sure.

Edit: I only skim read it so sorry if I misunderstood!

nope you understood it correct.
but I have actually improved this method since yesterday.

1. I changed the 3 alpha values of the triangles that have only one texture to 1.0,0.0,0.0 (before it was (1.0/3.0, 1.0/3.0, 1.0/3.0) which causes no more blending to be happening.
and the 3 alpha values of a triangle with 2 textures to (1.0,0.0,0.0) for the first 2 vertices and (0.0,0.0,1.0) for the third vertex. (before it was (0.5,0.5,0.0) and (0.0,0.0,1.0))

2. and I modified the ManualObject::textureCoord calls to end up only using 2 (one for material and one for alpha, the actual texture position is derived from the world position in the vertex shader)

hmm... how would I do any profiling on this? I mean the graphics card does all the pixel shading by itself.
would checking, how long the renderOne call takes to complete, work?

The most accurate method would be with a tool like gDEBugger. I've never used it but I have used similar tools. They will typically give you a break down of time spend rendering each batch, time spent in pixel vs vertex shaders, etc.

There's also glslDevil though the official homepage is down for me.


Not really, that will just be the time taken to submit the data to the GPU. You can measure the frames per second though, but a better approach is to take the inverse to compute (milli)seconds per frame.

gDEBugger crashes on me while trying to create a project ^^
i'm checking glslDevil now.
there is a page here, but that's really broken and half the stuff missing: http://cumbia.informatik.uni-stuttgart. ... glsldevil/

the google cache shows the correct page at your address...
it's really odd...
I wrote them an email about it, because I read in some boards that others have the same problem with it working sometimes and sometimes not

After reading this paper:
http://origin-developer.nvidia.com/docs ... hBatch.pdf

And considering that all meshes in my engine pretty much use hardware geometry instancing, I decided it is affordable to try a different solution to multi-texturing. Here I am sharing it

Again, if one remembers, the problem with multi texturing is usually inherited to the use of the atlas, another problem is the number of texture sampling done in pixel shader.

Now, considering geometry shaders are the least expensive and fastest in our GPUs and the only real problem with them as actually in the CPU, how many times we call a "DrawSubset/DrawPrimitive" or any of the such, due to a overhead when the CPU is sending the request to the GPU, and taking into consideration that most engines today (mine included) use the Vertex Shader 3.0 ability for geometry instancing...

Now if you read the paper it seems the hundreds, even thousands of draw calls can be quite fine, also taking to consideration that in games you rarely have hundreds of DIFFERENT models in the screen and considering that every model which appears multiple times is simply batched via geometry instancing (so no additional draw calls)...

My solution to get rid of texture atlas (and all the brain-aching problems it brings with it, unless using hardware which supports texture arrays and therefore Shader Model 4.0/DirectX10-11/OpenGL I dunno, I don't use OpenGL) is to simply divide the mesh!

All triangles with the same material (read texture) I split to one draw call with the specific texture, no multi texturing. All triangles with multiple textures I put in another draw which uses simple texture splatting (3 textures) and that's it.

Draw calls increases by insignificant amount taking into consideration that areas usually have few dominant textures. Considering every other geometry is instanced (as I said before, 1 draw call for X entities of same model) the impact of the batches is not important.

Also taking into consideration that at least in the case of MLE we seem to be more GPU bound than CPU bound with all the post processing pixel shaders etc we're doing there, CPU is only used for Havok Physics, AI and game logic which doesn't take too much it seems (for now).

So that's it, I just wanted to share with you my new point of view on multi-texturing PolyVox geometry and the new data I gathered on the subject.

Feel free to tell me what you think, and good luck!

Advantages of this method:

Unlimited textures
No more texture atlas headaches (mip mapping/wrapping/filtering)
Simple to implement
Reduced Texture Sampling in comparison to texture splatting everything (as ker suggested)
Shader Model 2.0
GPU workload relief (due to shorter shaders, reduces texture sampling, reduces branching)

Disadvantages of this method:

Increased Draw/Batching calls

Recommended use in:

More GPU bound than CPU bound engines
Engines which already have high geometry instancing usage
Environments/Engines/Levels with low amount of Draw calls (be it due to low number of objects or geometry instancing of the objects)

This is a perfectly valid approach, but whether it is beneficial will depend on a number of factors as you identify. Most people use a texture atlas in order to reduce the number of batches which are drawn, but if you can spare the extra batches then drawing from regular textures does solve the filtering problems.

You may even be able to even combine the two approaches, perhaps using texture atlas on more distant geometry and separate textures when close up. Or maybe only use texture atlases when blending between two different materials.

Yes, this too is possible, but for the blending ones you add geometry and batching anyways and the problem again remains with the mip maps.

In this case I think performance is still a bit in my favor because you add the geometry up to 3 times and use blending mode, as far as I remember, which means the number of texture sampling is the same (up to 3) and you got a bit more geometry.

I'd also dare and say that the good old texture splatting is able to deliver better result with less headache (mipmaps/filtering)