Triplaner Texture Minecraft Cubic Mesh in Irrlicht with GLSL

Midnight · **Joined:** Sun May 18, 2014 10:52 pm **Posts:** 43

Ok so for a long time (and some of it I wasn't programming) and something that is probably already known is my work in combining irrlicht and polyvox, I did this probably several years ago now. (with the help of a thread or two from this forum, mostly ogre demos though)

viewtopic.php?f=14&t=593

So following this post I was finally able to get textures working, something I recently set out to finish with the irrlicht/polyvox/minecraft clone thing I've been creating.

viewtopic.php?f=14&t=651

Finally after a bit of searching and learning shaders. And finding examples of GLSL and not HLSL

With cites for these sites. :geek:

WIKI POST about triplaner texturing (which set me in the right direction at least)

And this gem! GLSL triplaner shader/tutorial

I have arrived at this.

UPDATE: So apparently there is another post on that same tutorial site with a fix for their shader.

The link to that is here

One thing to note about it at this point is that it IS using multiple textures, it's literally the shader posted in that tutorial with NO changes yet. 8-)

Code will be Released when it's finished. or, eventually. ^^ actually it's just that unchanged shader that doesn't even require any callbacks or functions from the engine, simply applying the material to the node is enough for the shader to detect it. ENJOY

I will be updating this of course to support even more textures AND different materials, so minecraftopia can be fully achieved. In the contemporary style that minecraft is using. I think the best possible solution without using higher forms of texturing such as those discussed in the wiki would be to have a small shader for each material. Because a texture atlas can only support 256 textures before using more memory anyways, and on my system at least I feel an incredible boost of speed when using any shaders at all. This would also allow for custom model voxels with multiple textures and a seperate class for each world object. Perhaps modifying all the box shaped objects to use a single shader somehow to map the UV only.

I'm still very new to shader programming, but I have learned a lot with this project and now have a clear path to creating a minecraft clone and/or similar minecraft-like game I intend to release free.

Midnight · **Joined:** Sun May 18, 2014 10:52 pm **Posts:** 43

Initially I had resolved the coordinate offset (the texture upper left hand corner was drawn in the center) which I had noticed because I made that pixel red/yellow depending on which texture my compiler was using (different media for debugging). Well the shader undoes my fix, apparently overriding all material settings except the texture itself. So I wrote a quick fix to the offset with the proper values to fix this otherwise mostly unnoticeable bug.

In the future I'd like to write all of the lighting code in the shader as well, but this could help anyone following this before those complex changes are made.

Code:

uniform float offset;
 
void main ()
{
    //Texture Coordinates
   offset = 0.0 - 0.5;
    xcoord = gl_Vertex.x+offset;
    zcoord = gl_Vertex.z+offset;
    ycoord = gl_Vertex.y+offset;

The texture is applied from the bottom of a polyvox volume, so it may appear to have flipped the texture, this is another fix that must be applied at some point in the code.

Midnight · **Joined:** Sun May 18, 2014 10:52 pm **Posts:** 43

OH AND JUST FOR FUN HERE IS SOME EYE CANDY

free upload image

pic host

^^ taking advantage of irrlicht texture layers. displays the shaders ability to use multiple textures.

I have made a semi related change to this in the fragment shader. Which now looks like this.

Code:

varying float v;
uniform sampler2D myTexture0, myTexture1, myTexture2, myTexture3;

void main (void)
{
    vec4 color = texture2D( myTexture0, gl_TexCoord[0].st);
 
    if ( v > 0.0)
    {
        color = texture2D( myTexture1, gl_TexCoord[1].st);
    }
    if ( v < 0.0 )
    {
        color = texture2D( myTexture2, gl_TexCoord[2].st);
    }
     
    gl_FragColor = color;
}

Eventually these will become the different lighting layers, Diffuse, Specular and Ambient as irrlicht originally intended, but since I'm a shader noob it'll serve for different materials until something breaks.

At this point there are two clear ways I can handle breaking the voxels into individially textured cubes.
1. I can extract the surface mesh the same as I am now and be forced to solve the correct vertex/faces for texturing. (Essentially the texture atlas way)
2. I can surface mesh each voxel, find it's polar neighbors, if it has none on one side draw the texture. (seems overly involved, however I'm finding that with voxels this isn't nessesarily an extreme) This seems to be the way texture arrays and the more advanced voxel texturing methods seem to be performed, first this split it into UV, Tris/faces/indices.. and rendering in texture strips, triangle ribbons etc...

I want my application to perform well, but it might be intrinsically faster than minecraft already (who knows) and the 2nd method seems to more advanced way so likely it's more difficult to get fully functional or working in the first place. Surely it's harder to comprehend.

And as such I'll be setting up a texture atlas and exploiting the code as much as necessary. Also I've been toying with the material enum.. namely it seems much simpler to make a block.h class to hold my traveling data so to speak, and dump the volume data whenever possible. Polyvox doesn't really need to be used for anything besides world creation/ changes to chunks. All of the memory polyvox uses could be recycled when not doing those tasks and it makes setting up individual UV coords per block and everything else, such as quick lookups for blocks in the immediate chunk or chunks (4 max on a chunk corner).

Yes, this sounds right to me. So I'll experiment. See you soon.

David Williams · **Joined:** Sun May 04, 2008 6:35 pm **Posts:** 1827

Very nice, I'm glad shaders are working out for you! They really open up a whole new world of options.

Midnight wrote:

At this point there are two clear ways I can handle breaking the voxels into individially textured cubes.
1. I can extract the surface mesh the same as I am now and be forced to solve the correct vertex/faces for texturing. (Essentially the texture atlas way)
2. I can surface mesh each voxel, find it's polar neighbors, if it has none on one side draw the texture. (seems overly involved, however I'm finding that with voxels this isn't nessesarily an extreme) This seems to be the way texture arrays and the more advanced voxel texturing methods seem to be performed, first this split it into UV, Tris/faces/indices.. and rendering in texture strips, triangle ribbons etc...

I think you should be able to get away without having texture coordinates for the vertices. Per-vertex texture coordinates make things complex because, as you say, you have to carefully calculate them to work with texture atlases when you have multiple material types.

Instead of using per-vertex texture coordinates, try to use the world-space position of the fragment (pixel) you are shading. If a pixel has a 3D position of (x,y,z) and you are applying the texture along the +Y face then you might use (x,z) as you texture coordinates. These might be big numbers (e.g. 123.5, 42.7) but you can set your texture to wrap around so it is effectively (0.5, 0.7).

Be sure to read the PolyVox user manual because there is information on both texture mapping and lighting.

Midnight · **Joined:** Sun May 18, 2014 10:52 pm **Posts:** 43

David Williams wrote:

I think you should be able to get away without having texture coordinates for the vertices. Per-vertex texture coordinates make things complex because, as you say, you have to carefully calculate them to work with texture atlases when you have multiple material types.

Instead of using per-vertex texture coordinates, try to use the world-space position of the fragment (pixel) you are shading. If a pixel has a 3D position of (x,y,z) and you are applying the texture along the +Y face then you might use (x,z) as you texture coordinates. These might be big numbers (e.g. 123.5, 42.7) but you can set your texture to wrap around so it is effectively (0.5, 0.7).

Be sure to read the PolyVox user manual because there is information on both texture mapping and lighting.

Well that's basically what the triplaner texturing shader does. In irrlicht things are handled like so. I use the volume data and extract a surface mesh into a dynamic mesh buffer. Then I slap the buffer into a node, and finally I slap a texture on the node. But it only correctly maps to a single side of the voxels, on the other two (or 4 rather) faces of the cube the image is smeared from a single pixel on the edge of the texture. I believe it's caused by reading the incorrect dimension (xy rather than xz).

Rather than try to solve the UV coords, like I said, I slap a texture on and send it off to the shader. Now the shader takes the texture and maps it by world space positioning exactly like you say. But now we have the problem of making "blocks" have the correct material type.

One option seems to be 3d textures, or texture arrays. But the limitations on amount of materials you can place on a mesh require me to either hack irrlicht more materials per mesh, or use another method for passing multiple textures to the shader that I can work with.

I work from learning materials online exclusively, and the modern trends dictate what information is widely available. The only UV, texture alignment, etc code available it seems these days is shader code, so I'm up against a wall and need a quantum leap to a better method entirely.

I haven't decided yet but 3d textures seems legit.

-----------------------------------------------------

There is also a way to do a texture atlas kind of indice buffer, not indices necessarily but the multipass texturing method... essentially I'd use my new block class and blocktype enum to build a chunk sized matrix only. Compute the textures in several passes and each time share the Computed UV coords to the mesh buffer. It's a little bit intensive, because for each chunk or region you rebuild you need an class object to represent with some of the vertex/normal/UV data. It's all sort of on-the-fly extraction and texturing, but I imagine all the other methods would have similar drawbacks or inherent in-reversibility. For example 3d textures don't mipmap well for LOD, so for marching cubes with splat mapping this might work rather well.

The problem is all the information I'm find about voxels are for marching cubes, not cubic.

---

ok little update I think I've discovered how to multi-texture a node in irrlicht, this may be what I need to get the triplaner working correctly, if so that means 1 very compact shader for all chunks.

update: Well it works with irrlicht but not the shaders in irrlicht, rather than rewrite the shader code I think I'm going to attempt to texture within irrlicht, properly this time. If I can get the texturing right than it gets light shaded on top of that, so the texture ends up shaded after all the UV is configured CPU side. This suits mine and other common hardware specs to my liking. The shader then provides a gpu boost all around, but threading could help.

David Williams · **Joined:** Sun May 04, 2008 6:35 pm **Posts:** 1827

Midnight wrote:

Well that's basically what the triplaner texturing shader does. In irrlicht things are handled like so. I use the volume data and extract a surface mesh into a dynamic mesh buffer. Then I slap the buffer into a node, and finally I slap a texture on the node. But it only correctly maps to a single side of the voxels, on the other two (or 4 rather) faces of the cube the image is smeared from a single pixel on the edge of the texture. I believe it's caused by reading the incorrect dimension (xy rather than xz).

The smearing should be hidden, because you multiply each of the three textures by the appropriate component of the normal (as with triplanar texturing). For a cubic mesh only one of the normal components is '1' (the other two are zero) and so only one texture gets seen on each face. The smeared texture is still technically applied but is multiplied by zero.

Midnight wrote:

But the limitations on amount of materials you can place on a mesh require me to either hack irrlicht more materials per mesh, or use another method for passing multiple textures to the shader that I can work with.

Be careful with the term 'materials' here. Typically a 'material' to a 3D engine is a small set of textures and a vertex+fragment shader. If you have multiple materals on an object the engine may split the object and render it in separate pieces.

This is different from a PolyVox/Minecraft(?) material, which is just a single integer. You may have a scene with hundreds of PolyVox materials, but you should use just one Irrlicht material (probably - not familiar with Irrlicht). This single irrlicht material will have your 'triplanar' vertex/fragment shaders and a single texture which is your atlas. The PolyVox material ID is passed as vertex data, and you use this to adjust the texture coordinates in the shader to apply the correct part of the texture atlas.

Midnight wrote:

There is also a way to do a texture atlas kind of indice buffer, not indices necessarily but the multipass texturing method... essentially I'd use my new block class and blocktype enum to build a chunk sized matrix only. Compute the textures in several passes and each time share the Computed UV coords to the mesh buffer.

Again, you should not need to place any texture coordinates in the mesh buffer. You can probably compute them in the shaders (from the world space position) and then modify them according to the material ID (which is passed in the mesh buffer).

But I should emphasise there is no single 'correct' way to so this, and I haven't actually done Minecraft style texturing/material myself. And actually it is a little more complex than I am saying, because you want different textures on each of the faces whereas PolyVox only provides a single material ID per voxel. So if you can do it directly within Irrlicht, or via multipass rendering, etc, that is also fine. I'm just trying to guess how I would do it :-)

Midnight · **Joined:** Sun May 18, 2014 10:52 pm **Posts:** 43

David Williams wrote:

Be careful with the term 'materials' here. Typically a 'material' to a 3D engine is a small set of textures and a vertex+fragment shader. If you have multiple materals on an object the engine may split the object and render it in separate pieces.

This is different from a PolyVox/Minecraft(?) material, which is just a single integer. You may have a scene with hundreds of PolyVox materials, but you should use just one Irrlicht material (probably - not familiar with Irrlicht). This single irrlicht material will have your 'triplanar' vertex/fragment shaders and a single texture which is your atlas. The PolyVox material ID is passed as vertex data, and you use this to adjust the texture coordinates in the shader to apply the correct part of the texture atlas.

That's just it, I was trying to avoid the texture atlas. Minecraft itself no longer uses one. I'm wondering if that's because they use objects for each cube now. (probably not, ignore my crazy talk)

But you're right, with irrlicht materials/nodes system you can ONLY do a texture atlas. And I never did learn how to use multiple textures with a shader yet, except within the layers of the material. But I'm pretty sure there is a limit, and that the limit is = 4. So this is problem 1. textures are limited to 4 texures per block. And even shaders need textures for bump/parrallax.. then lighting, there are 3 needed, that's what they are for in irrlicht. specular/baked lighting etc.

David Williams wrote:

The PolyVox material ID is passed as vertex data, and you use this to adjust the texture coordinates in the shader to apply the correct part of the texture atlas.

Yeah how do you access that exactly? I have already written them into my voxels, far as I got.

David Williams wrote:

Again, you should not need to place any texture coordinates in the mesh buffer. You can probably compute them in the shaders (from the world space position) and then modify them according to the material ID (which is passed in the mesh buffer).

But I should emphasise there is no single 'correct' way to so this, and I haven't actually done Minecraft style texturing/material myself. And actually it is a little more complex than I am saying, because you want different textures on each of the faces whereas PolyVox only provides a single material ID per voxel. So if you can do it directly within Irrlicht, or via multipass rendering, etc, that is also fine. I'm just trying to guess how I would do it :-)

I'm not placing UV in mesh.. what I do is use irrlicht dynamic mesh buffer.. and put it into an irrlicht scene node. It's the way irrlicht handles scenes.

But what I wanted to ask was how much do you know about greedy meshing?
What I want to do is use my new greedy mesher class to read in all the vertex data and build the textures to the appropriate extracted texture mesh we'll call it. I'll split the block material types before hand, feed the greedy mesher one material at a time, it'll draw with minimal amount of vertex require PER TEXTURE, then construct a mesh with UV and properly aligned textures. It's an extra step but reduces the overall load on the GPU and/or ALL VERTEX DATA from that point on.

It already takes a major hit when meshing/converting polyvox to screen. Why not spend a little more time and greedy mesh and produce data that limits shaders to single textures, not per voxel mesh. ... Now I'm rethinking this in favor of "the stupid meshing way" because of lighting. Hmm this is going to take a little more planning I'm afraid.

Greedy Meshing
http://0fps.net/2012/07/07/meshing-minecraft-part-2/

Midnight · **Joined:** Sun May 18, 2014 10:52 pm **Posts:** 43

Well I've solved the multi-texturing problem. It was right there in front of my #%^& face the entire time!

I worked on this code a very long time ago. I guess being stuck with the whole volume handling business made me lose track of the texturing part of whatever example this started from.

So now it's rendering correctly the UV coordinates. And now I'll begin to form some sort of greedy mesher.

UPDATE: One thing I'm thinking having to figure all this out.

What if something like a ComplexVolume or GreedyVolume existed, where the extraction of the mesh broke down into the 3 axis AND VoxelType. It's what you need for meshing anyways, currently I'm using 4 dynamic mesh buffers and a lot of repeat code to break it down after extraction, and it seems like it should be lower level then this.

Just a thought.

Also I should point out that this thread was to help get my cubic voxels textured, I guess the title became a bit misleading, would explain some of your responses.

Midnight · **Joined:** Sun May 18, 2014 10:52 pm **Posts:** 43

I now have, Triplanar Texture Minecraft Cubic Mesh in Irrlicht with OUT GLSL.

And just look how messy it's getting. And this is after removing miles of out-commented code.

Code:

void calcMesh(SimpleVolume<uint8_t>& volData)
{
    PolyVox::SurfaceMesh<PolyVox::PositionMaterialNormal> mesh;
    //Transform voxel into mesh
    PolyVox::CubicSurfaceExtractorWithNormals< PolyVox::SimpleVolume<uint8_t> > surfaceExtractor(&volData, volData.getEnclosingRegion(), &mesh);
    surfaceExtractor.execute();

        std::cout << mesh.getNoOfVertices() << ":Total Vertices.\n" << mesh.getNoOfIndices() << ":Total Indices.\n";// << meshPoly.noOfDegenerateTris() << "\n";

        std::vector<uint32_t> indices = mesh.getIndices();
        std::vector<PolyVox::PositionMaterialNormal> vertices = mesh.getVertices();

        irr::scene::IDynamicMeshBuffer* buffer = new irr::scene::CDynamicMeshBuffer(irr::video::EVT_STANDARD, irr::video::EIT_16BIT);
        irr::scene::IDynamicMeshBuffer* bufferX = new irr::scene::CDynamicMeshBuffer(irr::video::EVT_STANDARD, irr::video::EIT_16BIT);
        irr::scene::IDynamicMeshBuffer* bufferY = new irr::scene::CDynamicMeshBuffer(irr::video::EVT_STANDARD, irr::video::EIT_16BIT);
        irr::scene::IDynamicMeshBuffer* bufferZ = new irr::scene::CDynamicMeshBuffer(irr::video::EVT_STANDARD, irr::video::EIT_16BIT);

        video::S3DVertex VertCoords;
        video::S3DVertex VertCoordsX;
        video::S3DVertex VertCoordsY;
        video::S3DVertex VertCoordsZ;

        video::SColor vertexColor = irr::video::SColor(255, 255, 255, 255);
        irr::video::ITexture* temptexture = driver->getTexture("minecave.png");
        //initialize
        float U = 0.0f;
        float V = 0.0f;
        float cordoffsset = 0.5f;

       buffer->getVertexBuffer().set_used(vertices.size());
       bufferX->getVertexBuffer().set_used(vertices.size());
       bufferY->getVertexBuffer().set_used(vertices.size());
       bufferZ->getVertexBuffer().set_used(vertices.size());

       for (size_t i = 0; i < vertices.size(); ++i) {
           const PolyVox::Vector3DFloat& position = (vertices[i]).getPosition();
           const PolyVox::Vector3DFloat& normal = (vertices[i]).getNormal();
           const PolyVox::Vector3DFloat& material = (vertices[i]).getMaterial();

            VertCoords = buffer->getVertexBuffer()[i];
            VertCoords.Pos.set(position.getX(), position.getY(), position.getZ());
            VertCoords.Normal.set(normal.getX(), normal.getY(), normal.getZ());

            VertCoords.Color = vertexColor;

            //For proper texture UV
            if(fabsf(normal.getX())>fabsf(normal.getY()) && fabsf(normal.getX())>fabsf(normal.getZ())){
                VertCoordsX.Pos.set(position.getX(), position.getY(), position.getZ());
                VertCoordsX.Normal.set(normal.getX(), normal.getY(), normal.getZ());
                U = position.getY()+cordoffsset;
                V = position.getZ()+cordoffsset;
                VertCoords.TCoords.set(U,V);//set the first buffer also
                VertCoordsX.TCoords.set(U,V);
                VertCoordsX = buffer->getVertexBuffer()[i];
            }
            else if(fabsf(normal.getY())>fabsf(normal.getX()) && fabsf(normal.getY())>fabsf(normal.getZ())){
                VertCoordsY.Pos.set(position.getX(), position.getY(), position.getZ());
                VertCoordsY.Normal.set(normal.getX(), normal.getY(), normal.getZ());
                U = position.getX()+cordoffsset;
                V = position.getZ()+cordoffsset;
                VertCoords.TCoords.set(U,V);//set the first buffer also
                VertCoordsY.TCoords.set(U,V);
                VertCoordsY = buffer->getVertexBuffer()[i];
            }
            else {
                VertCoordsZ.Pos.set(position.getX(), position.getY(), position.getZ());
                VertCoordsZ.Normal.set(normal.getX(), normal.getY(), normal.getZ());
                U = position.getX()+cordoffsset;
                V = position.getY()+cordoffsset;
                VertCoords.TCoords.set(U,V);//set the first buffer also
                VertCoordsZ.TCoords.set(U,V);
                VertCoordsZ = buffer->getVertexBuffer()[i];
           }
            //this part makes lots more sense now :P
            buffer->getVertexBuffer()[i] = VertCoords;
            bufferX->getVertexBuffer()[i] = VertCoordsX;
            bufferY->getVertexBuffer()[i] = VertCoordsY;
            bufferZ->getVertexBuffer()[i] = VertCoordsZ;
      }

       buffer->getIndexBuffer().set_used(indices.size());
       bufferX->getIndexBuffer().set_used(indices.size());
       bufferY->getIndexBuffer().set_used(indices.size());
       bufferZ->getIndexBuffer().set_used(indices.size());
       for (size_t i = 0; i < indices.size(); ++i) {
           buffer->getIndexBuffer().setValue(i, indices[i]);
           bufferX->getIndexBuffer().setValue(i, indices[i]);
           bufferY->getIndexBuffer().setValue(i, indices[i]);
           bufferZ->getIndexBuffer().setValue(i, indices[i]);
       }

       indices.clear();
       vertices.clear();
       // Recalculate bounding box
       buffer->recalculateBoundingBox();
       bufferX->recalculateBoundingBox();
       bufferY->recalculateBoundingBox();
       bufferZ->recalculateBoundingBox();

    // Convert the mesh and hand it to Irrlicht
    testMesh = new irr::scene::SMesh;
    testMesh->addMeshBuffer(buffer);
    testMesh->addMeshBuffer(bufferX);
    testMesh->addMeshBuffer(bufferY);
    testMesh->addMeshBuffer(bufferZ);

    testMesh->recalculateBoundingBox();

    levelMesh = device->getSceneManager()->addMeshSceneNode(testMesh,0,26);
    // ENABLE DEBUG BBOX
    levelMesh->setDebugDataVisible(irr::scene::EDS_MESH_WIRE_OVERLAY);
    //levelMesh->setDebugDataVisible(irr::scene::EDS_BBOX_ALL);
    //levelMesh->setDebugDataVisible(irr::scene::EDS_NORMALS);
    //levelMesh->setDebugDataVisible(irr::scene::EDS_FULL);

    levelMesh->getMaterial(0).setTexture(0, driver->getTexture("minecave.jpg"));
    levelMesh->getMaterial(1).setTexture(0, driver->getTexture("wall.bmp"));
    levelMesh->getMaterial(2).setTexture(0, driver->getTexture("sand.png"));

     levelMesh->setMaterialFlag(video::EMF_LIGHTING, false);

    buffer->drop();
    bufferX->drop();
    bufferY->drop();
    bufferZ->drop();
    testMesh->drop();
    mesh.clear();
}

UPDATE
So after thinking this through all morning and last night, I've come up with a plan, but to understand the value of my plan, first, you must know my problem.

The Problem: When building custom mesh/models you're forced to realign the UV coords, and map all the UV for different textures. When building custom models in Irrlicht, you're forced to make a new mesh buffer every texture, and everytime you repeat the texture.. like say onto another axis.

3 axis (not including mirrored sides) times the number of materials (minecraft has hundreds) equals lots and lots of buffers.. namely 3x hundreds in this case. So to solve this problem took a bit of thought, because if I wanted to do some greedy meshing, then I needed to hold all of these material buffers in memory until the greedy mesher was done.. or at least it seemed that way.

The Solution: or at least MY solution, is to create a material buffer, a single buffer that will be reused until all materials have been properly applied to the model. This seems obvious in hindsight, however, most things do. Originally I had bad ideas, somehow thinking that the axial UV correction and the material assignment had to be in the same loop, however I've retained the 4 original buffers from the axial code because I realized that once those UV are set, any material could be applied AFTER and the UV will be mapped correctly. And that is another key element of this design is that the material assignment must be done AFTER the axial UV alignment.

Even this update seems a little silly to post now that it's worked out, but having a bit of a journal helps to stream this process along for me. And there is a technical challenge here, but this time not too hard of a solution to the problem. And having said all that I'll stop trying to explain the details of it and just leave you with "The Plan". Next post I'll show my progress with this.

Midnight · **Joined:** Sun May 18, 2014 10:52 pm **Posts:** 43

So apparently, instead of this

Code:

            //For proper texture UV
            if(fabsf(normal.getX())>fabsf(normal.getY()) && fabsf(normal.getX())>fabsf(normal.getZ())) {
            cordx = position.getY();
            cordy = position.getZ();
            VertexCoords.TCoords.set(cordx,cordy);
            }
            else if(fabsf(normal.getY())>fabsf(normal.getX()) && fabsf(normal.getY())>fabsf(normal.getZ())) {
            cordx = position.getX();
            cordy = position.getZ();
            VertexCoords.TCoords.set(cordx,cordy);
           }
            else {
            cordx = position.getX();
            cordy = position.getY();
            VertexCoords.TCoords.set(cordx,cordy);
           }

I can instead do this

Code:

SceneManager->getMeshManipulator()->makePlanarTextureMapping(newMesh, 2.0f);

Which is interesting, but not really helpful at the moment.
Still cracking away at this, splitting materials was more or less failure. Perhaps though if I align the UV, use the mesh manipulator to triplanar, and a texture atlas than I may just be able to pull something off.

On another note reducing the size of my volume to 16 has improved re-extraction speed 5X

UPDATE:
Ok so I've answered most of my own questions, and the main answer here is that you need to do a texture atlas despite any drawbacks, it does provide 1 very fast texture/draw call.

Conclusion is adding the functionality is a bit difficult, and I've got other projects to work on so I'm giving this a rest for now. See you next time I pick it up, if ever.

Triplaner Texture Minecraft Cubic Mesh in Irrlicht with GLSL

Who is online