Volumes Of Fun
http://www.volumesoffun.com/phpBB3/

PolyVox and Ogre3D
http://www.volumesoffun.com/phpBB3/viewtopic.php?f=2&t=77		 Page 3 of 6
Author:  AndiNo [ Sat Oct 09, 2010 2:50 pm ]
Post subject:  Re: PolyVox and Ogre3D
Wow thanks for the help, that's very kind of you! :)

Here's what it looks like:
I'm using this texture (just for testing):
Image

Look from far away:
Image

Close-up look:
Image

Most of the time the texture is either just yellow or completely distorted, however it works for one specific direction and it's opposite side. In this case the picture is drawn some hundred times but much too small.

Just in case the fault is on my side here's my code for creating the ManualObject:
Code:
    PolyVox::CubicSurfaceExtractor<PolyVox::MaterialDensityPair44> surfaceExtractor(&volData, volData.getEnclosingRegion(), &mesh);
    surfaceExtractor.execute();

    PVWorld = scenemgr->createManualObject("PVWorld");

    uint32_t noVertices = mesh.getNoOfVertices();
    uint32_t noIndices = mesh.getNoOfIndices();

    PVWorld->estimateVertexCount(noVertices);
    PVWorld->estimateIndexCount(noIndices);

    PVWorld->begin("ColouredCubicVoxel", Ogre::RenderOperation::OT_TRIANGLE_LIST);

    // vertices
    const std::vector<PolyVox::SurfaceVertex>& vVertices = mesh.getVertices();
    for (unsigned int i=0; i<noVertices; i++) {
        const PolyVox::Vector3DFloat& pos = vVertices[i].getPosition();
        PVWorld->position(pos.getX(), pos.getY(), pos.getZ());
    }

    // indices
    const std::vector<uint32_t>& vIndices = mesh.getIndices();
    for (unsigned int i=0; i<noIndices; i++) {
        PVWorld->index( vIndices[i] );
    }

    PVWorld->end();
    }


Again thanks for the help so far!
Author:  David Williams [ Sat Oct 09, 2010 3:44 pm ]
Post subject:  Re: PolyVox and Ogre3D
It looks like you are copying the vertex positions from the SurfaceVertex to the ManualObject, but you are not copying the vertex normals. You need to call PVWorld->normal(...).

The shader code uses the surface normals to decide which face it is currently drawing to.
Author:  AndiNo [ Sat Oct 09, 2010 7:58 pm ]
Post subject:  Re: PolyVox and Ogre3D
You were absolutely right :-D
Now all faces of the cubes are drawn correctly. However the problem remains that each cube side has my texture repeated thousands of times. Do I have to change the shader to rectify this or do I have to call PVWorld->textureCoord(...), too? From what I understood the texture coordinates are not taken into account when using shaders, but I could be wrong. I scaled my ManualObject with the factor 100, could that cause that problem?
Author:  David Williams [ Sat Oct 09, 2010 8:30 pm ]
Post subject:  Re: PolyVox and Ogre3D
beyzend wrote:
David,

I know you are probably busy but what do you think about using instancing as a way to optimize the "cube" surface extraction? (Should I start another thread? but I guess this would be relevant to AndiNo also.)

Let's say I have a single vertex buffer which contains a constant number of vertices defined for say a single 16x16x128 region. Let's also assume the vertices are in object space. Then I could simply construct lists of triangles as I extract my surface. Then I render different N sets of triangle lists for N number of regions but all with that one single vertex buffer. In my shader I would transform the vertices into it's final position in world space as I would also pass in a world transform for each set of triangle list. The other optimization is to not have coplanar triangles. I think it's doable.


This is something I have thought about as well but there are a few catches. Firstly, there is more to a vertex than it's position - there is also the material ID and the normal. Actually I'm half-thinking to remove the normal it can also be generated in the pixel shader and will allow for more vertex sharing, but that's really a seperate discussion. The point is that you can have several vertices with the same position but other different properties.

Secondly, it's not good in all scenarios. If someone wants to use PolyVox for the simplest possible task of generating one mesh which corresponds to the whole volume then they have a rather huge vertex buffer.

Although the above sounds negative, I do actually think the idea is interesting. Maybe you can also take it further. Do you actually need the vertex buffer at all? If you know you have a region of 32x32x32 and an index in the index buffer of (for example) 4096, then you can actually deduce that this would correspond to a position of (0,0,4) (I hope I got that maths right). Maybe in a geometry shader or something.

However, for now I won't be taking that route. But I will try and spend some time over the next few week improving the performance of the CubicSurfaceExtractor. I am sure I can make the meshes many times smaller, but I don't know so much about the execution time. I might me bounded by memory access - i.e. the time to simply read each voxel from memory. I'll let you know how I get on.
Author:  David Williams [ Sat Oct 09, 2010 8:33 pm ]
Post subject:  Re: PolyVox and Ogre3D
AndiNo wrote:
You were absolutely right :-D

;-)
AndiNo wrote:
Now all faces of the cubes are drawn correctly. However the problem remains that each cube side has my texture repeated thousands of times. Do I have to change the shader to rectify this or do I have to call PVWorld->textureCoord(...), too? From what I understood the texture coordinates are not taken into account when using shaders, but I could be wrong. I scaled my ManualObject with the factor 100, could that cause that problem?


The shader is using the pixel's world-space position as a texture coordinate. So yes, the scaling will make a difference. You can divide the texture coordinates by an amount to make the textures larger. For example:

Code:
col = tex2D(heightMap, inWorldPosition.yz / 100.0);


I didn't try compiling that but that's the idea.
Author:  AndiNo [ Sat Oct 09, 2010 8:58 pm ]
Post subject:  Re: PolyVox and Ogre3D
David Williams wrote:
I didn't try compiling that but that's the idea.

Bingo. :-D
Image

BUT:
Image

The ManualObject is at Position 0,0,0. But the texture on the cubes is shifted by a constant offset, how do find out how much this is so I can change it in the shader? Or better, how can I avoid that entirely?
Again thanks for the continuing support!
Author:  David Williams [ Sat Oct 09, 2010 9:27 pm ]
Post subject:  Re: PolyVox and Ogre3D
Try adding 0.5:

Code:
col = tex2D(heightMap, (inWorldPosition.yz / 100.0) + 0.5);


It's because the origin of the voxel is in it's center, rather than it's lower left corner.
Author:  AndiNo [ Sat Oct 09, 2010 10:26 pm ]
Post subject:  Re: PolyVox and Ogre3D
Victory is ours! :lol:
Image

It's clear that you're a good amount of time ahead of me in shader experience. I would have not achieved this in this short time without your help. I'll remember your name for the credits if my game gets finished :) Thanks again!

I'll try to figure out how to use the shader with a texture atlas. If you however have a shader at hand that does something similar I wouldn't say no ;) My searches so far have not brought up a shader like this.
Author:  David Williams [ Sat Oct 09, 2010 10:57 pm ]
Post subject:  Re: PolyVox and Ogre3D
AndiNo wrote:
Victory is ours! :lol:
Image

Great work!

AndiNo wrote:
It's clear that you're a good amount of time ahead of me in shader experience. I would have not achieved this in this short time without your help. I'll remember your name for the credits if my game gets finished :) Thanks again!

Thanks. It's partly just experience, and partly that I have the advantage that I wrote PolyVox so I know exactly how everything works ;-)

AndiNo wrote:
I'll try to figure out how to use the shader with a texture atlas. If you however have a shader at hand that does something similar I wouldn't say no ;) My searches so far have not brought up a shader like this.


Have a read of this:

Improve Batching Using Texture Atlases

Note that you don't have to use texture atlases and they have some significant problems with linear texture filtering (I assume this is why MineCraft uses point filtering).

An alternative is to simply split up the SurfaceMesh into several different meshes - one for each material. You get more batches (so slower) but you might find it easier. The surfaceMesh class has a function called 'extractSubset' which you might look into. It not that well written and I can't be sure it works with the 'Cubic' surface extractor, but it's a starting point.
Author:  AndiNo [ Sun Oct 10, 2010 9:04 am ]
Post subject:  Re: PolyVox and Ogre3D
David Williams wrote:
An alternative is to simply split up the SurfaceMesh into several different meshes - one for each material. You get more batches (so slower) but you might find it easier.
I already thought of that. However the way I imagined things wouldn't work with that I think. If I want to display a 256^3 voxel world consisting of 512 32^3 volumes, that would make 512 batches. In the worst case every volume has some 20 different materials in it, that would result in a batch count of 512*20 = 10240. At least if the whole world is in the field of view. But even if I can only see a part of the world this would still mean a batch count of about ~2500. I'm not sure if I should try that...
Page 3 of 6 All times are UTC
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/