Update: Switched from using shaders to assigning uvs when building the manual object. Below has the solution.

My guess would be that the problem is in your shader code rather than the C++ code. Have you got it working correctly if you apply a single texture rather than trying to pick out part of a texture atlas? If not you need to start there. Then bring in the texture atlas code but on a texture atlas with only 1 texture. Then a texture atlas with two textures, etc. Build it up slowly.

Also, in your vertex shader you are doing direct comparisons with floating point values ( != 0.0). This is generally bad practice due to floating point inaccuracies.

Try to see into my latest post and decided if texture atlases actually worth it, although for cubic terrain I guess there is no real use for my method as there shouldn't be problems with wrapping/mipmaps/blending(?)

viewtopic.php?p=1642#p1642

Interesting approach, I by no means need a texture atlas, i'm just trying to get any form of per voxel textures working.

If you only have a small number of textures, you can also pass them in as different texture units (using texture_unit in your material script) because a shader can have a number of different textures bound simultaneously. You can then pick which texture to sample based on your material.

Which leads to branching in pixel shader which is quite slow Try to read my post, I think we should compare the techniques sometime and figure what might be most recommended technique.

In my technique I described in the post multiple texture slots is used only for triangles which require multiple materials for blending, other than that every uniform triangles are drawn without more than one texture sample.

Then again the drawback is additional batching (draw calls) which I explained my preference for quite a bit in the post.

Probably, but the point is he just needs to get something working first. Using separate texture units is probably simpler than using texture arrays.

Depends what you mean, multiple texture units sure is more simple than texture atlas or texture array, but I wasn't recommending those

The question is Texture Splatting vs Separating the mesh. And I'd say Texture Splatting is indeed simplier and requires less code than what I presented.

I've recently come back to this project of mine, and I my goal is to not use shaders at all.
I have textures working but 2 faces of the 4 sides on a cube have their uv's rotated 90degrees :{

The arrows should all be pointing UP


I'm sure it's something simple but I'm not sure where I am going wrong. Here is how i create the manual object and assign UV's.




I'm sorry for asking to be spoonfed a solution, but I don't have a very good understanding of constructing primitives based on vertex data. I assumed each face was constructed in the same order of 4 points, so I don't understand why half the faces are rotated.

If I manage to figure it out, I'll post it so other people can see the solution.

This is an interesting question. There's no problem with your code, it's actually the triangles generated by PolyVox which are in an inconsistant order.

Off the top of my head I couldn't tell you what order the vertices are in, and I didn't give it much thought when writing the code, for the simple reason that it's not possible to get all three axis to line up. Think of it like this, even if the arrows on your walls did line up, what would happen if you also drew arrows on the floor? Because your walls are at 90 degrees to each other, the arrows on the floor would not be able to line up with both sets of walls. The best you could do would be to have the arrows on the floor line up with one set of walls.

What I'm really saying is that in the general case there is no 'correct' way to assign the texture coordinates, which is part of the reason PolyVox does not provide texture coordinates. However, your case is more specific than the general case - you know that two of your axes represent walls and the that the textures on these should be aligned, and the the other axis represents floor/ceiling and the alignment here doesn't matter.

Hopefully that justifies why it behaves in the current way. The good news is it shouldn't be hard for you to get the behaviour you want - you simply need to consider each of the six faces seperaty based on the normal. This code is untested but should give you the idea:



Note that I've replaced your 'texCoords' array with six new arrays - one for each face ('texCoordsForPositiveX', etc). Start of with each off these the same as your original texCoords array, and the tweak the values for each face until you are happy.

Let us know how that works out. There may be a better way as I haven't given much thought to doing this on the CPU rather than in shaders, so feel free to experiment.