Hi!

So I been struggling with evil evil DirectX 9 code, HLSL and texture atlas. While I still haven't completely figured the texture atlas to work 100% right, I've got everything else:


Now, considering there was a request before, I am going to share my code here, please note, some of it can still be optimized, I just finished.

Let us start with the way I construct my vertex buffers:

1. Before I begin, a class or two which may need some explanation, take a look at these two lines:


All you need to know is what they do in DirectX 9, here is a simplified version deleting most of the internal parts:


Now for the index buffer:


Ok, so now we know what those buffers do and how they really create the DX9 buffers, very simple so far.

Now for the next part, our mesh creation, I will first explain the mesh creation and the problems involved with it due to using triplanar texturing and texture atlas so keep this in mind, then I will go on to showing the shaders such as the atlas shader and triplanar texturing shader:


Here is what this is, my VoxelMesh represent part of a volume, not the whole volume (although they can, just pass them a full region), this function creates it.

Ok, now let's see how it works.


So far all should be familiar, we tell polyvox to create us a mesh.

Now comes the tricky part, with triplanar texturing AND texture atlas combined in DirectX 9 there will be some major artifacts if just rendered as-is, such as:


This is cause because of the following - imagine you have a triangle with one vertex having material 0 which represents grass and two other vertices having material 3, representing dirt.

Now in a 4x4 texture atlas that means that the first vertex would have texture coordinate between 0.0 to 0.25, the second and third vertices would have coordinates between 0.75 to 1.0, since everything that is between the differing materials' vertices gets interpolated this means that color values which are in between the two textures slots would also get it and the values would range anywhere from 0 to 1 interpolating 4 textures into one triangle. This whole a lot of data is also what causes it to appear stretched.

So this kind of a triangle we will now call a problematic triangle and its vertices would be "problemVertices".

Now after we had PolyVox create our mesh and we retrieved this data, we need to deal with our "problemVertices".


Here I initialize a vector to store the indices of our problematicVertices, or triangles actually. floatComparsion is just comparing floats with a slight epsilon to see if they are close enough to count as the same due to floating point precisions. I actually had incorrect identification of "problematicVertices" due to this imprecision, so here is the function:


Now that we have identified our offenders, it is time to have a fix. And how do we fix them? Well, there trick is to first render the offender triangles black, we do this by adding the triangle to the original mesh with a black material, in my case I set the material to be 300 and in the shader I check if a material is over 200 and return a black color if it is (feel free to play with those numbers as suits your use of PolyVox and the number of materials you might have).

Then we render the offender triangles up to 3 more times, each time with one of the different materials (textures) a vertex of the triangle has, with the other two vertices also set to have the same material but an alpha of 1, then the alpha is interpolated over from the vertex shader to the pixel shader and a smooth transition happens when using additive blend.

Here is how I set up our new meshes (please ignore the un-used count value):


Ok, so here what we do is first create arrays and reserve the predicted amount of values to be inserted into them.

Next we go over our problematic vertices, save their materials, set the materials to 300 and add them to the original mesh. That will take care of them being rendered as black later on.

Next what we do is set the three corners as I explained earlier, we add the triangle three times, each time with a different material when the corner who originally had that material has it again in its material's triangle (it will have the other materials in the other two triangles [+16]) and the other two vertices have the same material but with 16 added. Why 16 is added? Because I didn't feel like creating and switching over additional FVFs, as well as creating a new structure to add the alpha value in it. This means that in the shader, if a material is greater or equal 16 then it will set the alpha to be 0 in the vertex shader so it is sent to be interpolated in the pixel shader (it will also reduce the material's value by 16 so it can actually be used).

Do note that you should change that number (16) if your application is going to use more than 16 materials/textures.

Next all we do is create the vertex buffer and index buffer for the "fixed" triangles and save the number of faces and number of vertices.

Now two tasks are left for us:
1. Create the original mesh's buffers.
2. Remove the offender triangles' indices from the mesh so they won't be rendered. Remember we added additional black triangles to replace them anyway (the black is so the fixed triangles will render with additive blending over it instead of add with the environment).

Hurray, let's continue with our code then:


Simple here, retrieve our mesh indices and mesh vertices (we changed it a bit, but probably no need to do this again as we did get a reference to it last time, not a copy, optimization note).

Create vertex buffer and index buffer big enough, when creating the index buffer remember we intend to remove some indices (shown in the code)

Now copy the indices to the locked buffer (to the GPU), skip the offenders (room for optimization in this loop).

For the next bit of code all we are left with is copying our vertices to the buffer and obviously saving the number of faces and number of vertices we have:


Done! (additional bit I did was also create a translation matrix to move the mesh from local space to region.getLowerCorner()'s position)

Now we are left with the rendering code (and the shaders):


Here we assign our world's position, assign our texture atlas to the appropriate texture slot, set our material (the color, not the PolyVox related) and then just set our index buffer, vertex buffer and deal with the offender triangles. Here is how we do that.

First we render the original mesh, no alpha blending, no alpha testing, nothing.


Now we need to render our offenders, this we do with alpha blending mode set to additive, source blend would be source alpha and destination blend value would be dest alpha.



That's it for the DirectX part of the program! Rest is HLSL and I will continue this in the next post.

Ok, my "VoxelAtlasShader.fx" requires two shaders, let us start by going over those two before the rest. Do note I have not yet worked much toward fixing the problems coming with texture atlases everywhere, unrelated to PolyVox.

Let us start with our light, basic blinn-phong lighting, which I will not bother to explain:

Filename: BlinnPhong.fx


Now let us continue with the texture atlas function, this is in the "TextureAtlas.fx" file:


First we make sure the UV is from 0 to 1 so there is no bleeding to other textures in the atlas, then we find the coordinates according to how many textures are in the atlas on the X and Y axes and we return it, pretty simple transformation.

Here is my "VoxelAtlasShader.fx", start with the includes and the vertex shader:


Nothing much here, transform vertex, save world-space vertex divided by 1 (input.position.w) for triplanar texturing later on, save material and normal, also check if the material is >= 16 (well 5.5, extra worry due to floats but I guess it is the same) then set the alpha to 0 (and subtract material by 16), otherwise to 1. That's it.

Pixel Shader (and technique deceleration):



First we check to see if we need to return black (remember we added triangles with material 300 to the "original mesh" to render as black so later we can blend on top of them?), if our material is larger than a value we set (200) then we return black.

Next part is about triplanar texturing, we get our texture coordinates from the normal, as well as the blend weights. We transform the texture coordinates to atlas texture coordinates with the function from the TextureAtlas.fx, then we sample the texture and add them multiplied by their weights.

Next we get our lights with our BlinnPhong.fx functions.

Last we return our color with the alpha from the vertex shader. The reason it was set in the vertex shader is so it gets interpolated across the vertices in the pixel shader.

Done! Enjoy

Ok, some notes!

1. There might (probably) be a bug with the lighting because of the division by position.w in the vertex shader (forgot about that when added the usual lighting functions).

2. I do not deal with the usual problems associated with the usage of Texture Atlas, such as texture bleeding, filtering problems and mip mapping.

3. For still unknown reason, there are sometimes black vertices where 3 textures are being blended. The weird thing is that it only happens sometimes. If I will find the solution, I will edit the tutorial. Anyone who might have a solution please inform me

Now I have updated the MLE Tech Demo with the new version of this PolyVox "ground" editor and fixed texture blending. You are free to try it but note that you will still see low quality texture sampling due to the mipmaps problems with the texture atlas and low filtering levels.

(Apologies for the file size, it can be much smaller considering most unrelated features are disabled, but it is the same as the tech demo, where you can press F3 to see other functionalities of the MLE Engine)

Link: http://www.twilightempires.com/downloads/MLE.rar

I hope this tutorial helped someone and I will try to update it as I find solution for more problems.

That's a lot of information, thanks for contributing It was pretty long so I only skim read it but I noticed a couple of things:

You imply that the problems are a result of using triplanar texturing and/or texture atlases but is isn't really true (it would still happen with texture arrays). The problem is simply that if you have a matrial id of 1 at one vertexs and a material id of 100 at another vertex then when you interpolate the id across the triangle it passes through a whole bunch of materials you don't want. Even if you materials were just solid colours you would still see this problem.

Regarding your float comparisons and tolerance, actually I don't think you should need this. The meshes from the marching cubes surface extractor should not have duplicates anyway. You can probably just compare the index of the vertices rather than comparing their positions.

And a couple of typos I noticed:
but an alpha of 1 -> should be 0
well 5.5, extra worry -> should be 15.5