Triplaner Texture Minecraft Cubic Mesh in Irrlicht with GLSL

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

Hi, I realise you are moving on to other things, but I thought I should respond for the benefit of anyone else who comes across this thread. But I realise I didn't check what version of PolyVox you were on, so in the responses below I assume you are using the latest develop version (not the last released version)

Midnight wrote:

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.

The 'CubicVertex' is defined as follows:

Code:

template<typename _DataType>
struct  CubicVertex
{
   typedef _DataType DataType;

   // Each component of the position is stored as a single unsigned byte.
   // The true position is found by offseting each component by 0.5f.
   Vector3DUint8 encodedPosition;

   // User data
   DataType data;
};

Note that it holds the vertex position, and also a 'data' member. This 'data' is the value which is copied from the voxel and stored in the vertex. If you have a 'material ID' for each voxel then it will be copied to the extracted mesh and you could use this to index the correct texture in your texture atlas.

Midnight wrote:

But what I wanted to ask was how much do you know about greedy meshing?

PolyVox already implements greedy meshing (at least if you are using the latest develop version). The 'extractCubicMesh' function has a parameter called 'bMergeQuads'.

Note that it doesn't generate a mesh per material, but it does make sure that merging does not occur across material boundaries. Given this single greedy-meshed output you can then use the 'material ID' stored in the 'data' of the vertex to index the correct part of your texture atlas in the shader. At least that is the idea. As mentioned, I haven't actually tried Minecraft-style rendering or texture atlases.

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

David Williams wrote:

Hi, I realise you are moving on to other things, but I thought I should respond for the benefit of anyone else who comes across this thread. But I realise I didn't check what version of PolyVox you were on, so in the responses below I assume you are using the latest develop version (not the last released version)

Think of it as less "moving on" and more like taking a break. For some reason voxels keep sticking in the back of my mind. I DO want a clone of minecraft with my own twists, however, I had hit a bit of a roadblock with the texturing. And I'm proud that someone actually considered the educational value of this post, as that is it's true purpose.

David Williams wrote:

Midnight wrote:

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.

The 'CubicVertex' is defined as follows:

Code:

template<typename _DataType>
struct  CubicVertex
{
   typedef _DataType DataType;

   // Each component of the position is stored as a single unsigned byte.
   // The true position is found by offseting each component by 0.5f.
   Vector3DUint8 encodedPosition;

   // User data
   DataType data;
};

Note that it holds the vertex position, and also a 'data' member. This 'data' is the value which is copied from the voxel and stored in the vertex. If you have a 'material ID' for each voxel then it will be copied to the extracted mesh and you could use this to index the correct texture in your texture atlas.

Midnight wrote:

But what I wanted to ask was how much do you know about greedy meshing?

PolyVox already implements greedy meshing (at least if you are using the latest develop version). The 'extractCubicMesh' function has a parameter called 'bMergeQuads'.

Note that it doesn't generate a mesh per material, but it does make sure that merging does not occur across material boundaries. Given this single greedy-meshed output you can then use the 'material ID' stored in the 'data' of the vertex to index the correct part of your texture atlas in the shader. At least that is the idea. As mentioned, I haven't actually tried Minecraft-style rendering or texture atlases.

I never did get much past that point with the texturing. The problem is that I couldn't get multiple textures loaded into the shader, probably a limitation of irrlicht's simplistic shader interface. And at the time I lacked the ambition to build a texture atlas framework but that would have solved the multiple texturing issue.

Part of the issues with a texturing atlas was indeed the separation on the whole mesh, and that is what lead me to the greedy meshing information. I'm not sure why I thought that reducing the mesh would help, or wasn't already possibly implemented, but I do remember you or your brother mentioning it at some point I thought. It's good to have a guide into that a bit.

I may work with this and see if I can get a functional texture atlas working. will report my findings then.

UPDATE:

Forgot the whole reason I responded.. meant to share my polyvox version... which is NOT recent.. it is an old development version. Perhaps even an unreleased one I obtained from one of you??

I think I'm using a year old repository development version. Because when it comes to programming everyone else is a mechanic and I'm the guy with the junkyard. :lol:

the date on some of the files.. 5/9/2014

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

Ok quick question now that I've completely broken the only working example of my triplaner thingy...

Code:

// Oh. My. God. Template horror...no wonder all examples with this use auto.
// No auto on my watch, though.
#define DecodedType PolyVox::Mesh<PolyVox::Vertex<MeshType::VertexType::DataType>, MeshType::IndexType> 
#define MeshType PolyVox::Mesh<PolyVox::MarchingCubesVertex<PolyVox::SimpleVolume<BYTE>::VoxelType > > 
    
    // Extract and decode mesh
    MeshType mesh = PolyVox::extractMarchingCubesMesh(_voxelVolume, _voxelVolume->getEnclosingRegion());

    DecodedType decodedMesh = PolyVox::decodeMesh(mesh);

    p_manualMesh->begin("SimpleTexture", Ogre::RenderOperation::OT_TRIANGLE_LIST);
    {
        const std::vector<PolyVox::Vertex<MeshType::VertexType::DataType> >& vecVertices 
            = decodedMesh.getVertices();
        const std::vector<uint32_t>& vecIndices = decodedMesh.getIndices();

Sooo... it keeps throwing an error saying that .getIndices() and .getVertices() aren't part of the class/namespace.

Any idea how to fix it? And what is all this decoding nonesense?

this was the only actual example available for the new polyvox. And you've ruined me. heeeellllppp!!

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

Well I've worked through some of the template hell problems. Using auto.

But the issue now is getting actual vertices and indices from polyvox, my std::cout says that there are none, and they create segmentation faults on both the mesh and decoded mesh... my question now is what the heck is the mesh and decoded mesh? differences? do I even need a mesh buffer now or will only opengl accept the decoded format?

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

Midnight wrote:

Sooo... it keeps throwing an error saying that .getIndices() and .getVertices() aren't part of the class/namespace.

The Mesh class still contains std::vectors but this is hidden now (it is an 'implementation detail'). You can access the individual vertices and indices with getNoOfVertices(), getVertex(), etc.

Midnight wrote:

And what is all this decoding nonesense?

PolyVox now uses a more compact format for it's vertex data. For example, a surface normal would usually be three 32-bit floats (x,y,z) but for the MarchingCubesVertex we encode it in only 16 bits (approx 5 bits per component). Before being used this data needs to be decoded to a more conventional format. You can do this decoding in one line using the decode() function, and in this case PolyVox should behave similarly to before. Advanced users can upload the encoded data to the GPU (to save space) and do the decoding there in a shader.

I strongly recommend you use the built-in decode() function for now.

Code:

// Create an empty volume and then place a sphere in it
RawVolume<uint8_t> volData(PolyVox::Region(Vector3DInt32(0, 0, 0), Vector3DInt32(63, 63, 63)));
createSphereInVolume(volData, 30);

// Extract the surface for the specified region of the volume. Uncomment the line for the kind of surface extraction you want to see.
auto mesh = extractCubicMesh(&volData, volData.getEnclosingRegion());
//auto mesh = extractMarchingCubesMesh(&volData, volData.getEnclosingRegion());

// The surface extractor outputs the mesh in an efficient compressed format which is not directly suitable for rendering. The easiest approach is to 
// decode this on the CPU as shown below, though more advanced applications can upload the compressed mesh to the GPU and decompress in shader code.
auto decodedMesh = decodeMesh(mesh);

The decoded mesh contains instances of Vertex, which has a conventional position and normal:

Code:

template<typename _DataType>
struct  Vertex
{
   typedef _DataType DataType;

   Vector3DFloat position;
   Vector3DFloat normal;
   DataType data;
};

Midnight wrote:

this was the only actual example available for the new polyvox. And you've ruined me. heeeellllppp!!

Have a look at the BasicExample to start with. It shouldn't be much more complex than old versions of PolyVox if you use the decode() function.

Midnight wrote:

Well I've worked through some of the template hell problems. Using auto.

I agree the template stuff gets a bit too crazy. I was thinking of adding some template typedef's to make it a bit clearer.

Midnight wrote:

But the issue now is getting actual vertices and indices from polyvox, my std::cout says that there are none, and they create segmentation faults on both the mesh and decoded mesh...

Maybe you can show the code where you create and extract the volume?

But overall, yes, a lot has changed since the previous version. In the next few weeks we will make a new PolyVox release to fix this situation where the 'official' version is so old.

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

I worked out a lot of the problems last night. It's reading some of the vertex and index now, but seems to be merging too much??? not sure yet, tried many methods to get the proper vertex, all of them produce same result.. looking into the merging now, and fixing my shader, hoping to fix this.

Seems like the old approach to the meshing no longer works.. but should find a solution IF I can get proper vertex counts. We'll see where it's heading from here. 8-)

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

Sorry for the slow reply but I'm glad you've made some progress :-)

Midnight wrote:

...but seems to be merging too much???

Can you simplify the test case as much as possible? What if you have only a single solid voxel? What if you have two solid voxels? Etc? Can you print out the list of vertex positions and indices in this case to see if they make sense (there should only be a few)?

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

So this one time I figured out this difficult issue, and I made this really cool error just before fixing the riddle.

So I thought I'd share. 8-)

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

Midnight wrote:

I used .getNoOfIndices() directly after extracting the mesh etc. (in other words entirely polyvox basic demo stuff) so why is it only outputting 4 vertices, and 4 positions?

Any chance your single voxel is near the edge of the Volume/Region? May sure it is near the centre for now. Here is the simplest example I can come up with which generates the correct behaviour (8 vertices and 24 indices representing a single cube).

Code:

RawVolume<uint8_t> volData(PolyVox::Region(Vector3DInt32(0, 0, 0), Vector3DInt32(63, 63, 63)));
volData.setVoxel(32, 32, 32, 255);
auto mesh = extractCubicMesh(&volData, volData.getEnclosingRegion());
auto decodedMesh = decodeMesh(mesh);

std::cout << "Vertices:" << std::endl;
for (int i = 0; i < decodedMesh.getNoOfVertices(); i++)
{
   std::cout << "    " << decodedMesh.getVertex(i).position << std::endl;
}
std::cout << std::endl;

std::cout << "Indices:" << std::endl;
for (int i = 0; i < decodedMesh.getNoOfIndices(); i++)
{
   std::cout << "    " << decodedMesh.getIndex(i) << std::endl;
}

And here is the output:

Code:

Vertices:
    (31.5,31.5,31.5)
    (31.5,31.5,32.5)
    (31.5,32.5,32.5)
    (31.5,32.5,31.5)
    (32.5,31.5,31.5)
    (32.5,31.5,32.5)
    (32.5,32.5,31.5)
    (32.5,32.5,32.5)

Indices:
    4
    6
    7
    4
    7
    5
    3
    2
    7
    3
    7
    6
    1
    5
    7
    1
    7
    2
    0
    1
    2
    0
    2
    3
    0
    4
    5
    0
    5
    1
    0
    3
    6
    0
    6
    4

Can you get that cube to render correctly?

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

Code:

RawVolume<uint8_t> volData(PolyVox::Region(Vector3DInt32(0, 0, 0), Vector3DInt32(63, 63, 63)));
volData.setVoxel(32, 32, 32, 255);
auto mesh = extractCubicMesh(&volData, volData.getEnclosingRegion());
auto decodedMesh = decodeMesh(mesh);

std::cout << "Vertices:" << std::endl;
for (int i = 0; i < decodedMesh.getNoOfVertices(); i++)
{
   std::cout << "    " << decodedMesh.getVertex(i).position << std::endl;
}
std::cout << std::endl;

std::cout << "Indices:" << std::endl;
for (int i = 0; i < decodedMesh.getNoOfIndices(); i++)
{
   std::cout << "    " << decodedMesh.getIndex(i) << std::endl;
}

Whoa you solved it and posted just seconds before me hahaha!

Nice though, it includes the solution.

And below is what I was doing wrong.

Code:

RawVolume<uint8_t> volData(PolyVox::Region(Vector3DInt32(0, 0, 0), Vector3DInt32(63, 63, 63)));
volData.setVoxel(32, 32, 32, 255);
auto mesh = extractCubicMesh(&volData, volData.getEnclosingRegion());
auto decodedMesh = decodeMesh(mesh);

std::cout << "Vertices:" << std::endl;
for (int i = 0; i < sizeof(decodedMesh.getNoOfVertices()); i++)
{
   std::cout << "    " << decodedMesh.getVertex(i).position << std::endl;
}
std::cout << std::endl;

std::cout << "Indices:" << std::endl;
for (int i = 0; i < sizeof(decodedMesh.getNoOfIndices()); i++)
{
   std::cout << "    " << decodedMesh.getIndex(i) << std::endl;
}

Excellent now that I'm updated to the latest model of polyvox I can continue texturing and getting the decoding done via GPU.

So one thing that I've learned is that the old polyvox "Master" Branch, is really just the old 2013 branch of polyvox. The "Development" Branch is however the newer version which does GPU decoded texture arrays, for "multitextures" like actual layered images or something. It does the greedy meshing as well which is screwing me up at the moment but was the optimization one needs for any minecraft-like. It also doesN'T require any build macros, it just compiles as headers now. So moving along this is the current state, since it's not documented anywhere else ATM.

Edit; One thing I just thought of is that your greedy mesher will force a single texture. The greedy meshing should be performed after the texturing phase, or you're committed to texturing those segments with singular textures and not per voxel as I understand it. You're forcing the use of texture atlas, and texture arrays, but leaving no room for custom implementations that don't rely soley on marching cubes and triplaner approaches. I'm forced to work with the greedy meshed outputs am I not? They are visible in the sphere image I posted above.

Triplaner Texture Minecraft Cubic Mesh in Irrlicht with GLSL

Who is online