Realtime Ogre 1.8 Terrain Component manipulation

charlieb · **Joined:** Wed Jan 25, 2012 12:29 am **Posts:** 18

If you have a memory checker like valgrind (only for windows) that'd be the tool to use.

The reason that it doesn't happen in debug mode is because the memory layout is different so the overrun can happen and it'll just write into empty space and nothing will get trashed whereas in release mode all the memory chunks are right next to each other so even a one character overrun will cause havoc.

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

You should also watch out for any uninitialised variables, as these get automatically initialised by the debugger but are uninitialised in release builds.

Overall, the easiest approach might just be to cut your code back until you work out what is causing the crash.

Googleing for 'Release build crash' will also throw up some information - this problem is actually quite common.

drwbns · **Joined:** Wed Jan 11, 2012 7:33 pm **Posts:** 109

I'm pretty sure Valgrind is for linux. I reverted the code to basic cubic extraction and the crash seems to occur after calling cubicSurfaceextractorwithnormals and crashes around this piece of code in cubicSurfaceextractorwithnormals.inl -

Code:

               if(currentVoxel < plusYVoxel)
               {
                  float material = static_cast<float>(m_volData->getVoxelAt(x,y+1,z).getMaterial());

                  uint32_t v0 = m_meshCurrent->addVertex(PositionMaterialNormal(Vector3DFloat(regX - 0.5f, regY + 0.5f, regZ - 0.5f), Vector3DFloat(0.0f, -1.0f, 0.0f), material));
                  uint32_t v1 = m_meshCurrent->addVertex(PositionMaterialNormal(Vector3DFloat(regX - 0.5f, regY + 0.5f, regZ + 0.5f), Vector3DFloat(0.0f, -1.0f, 0.0f), material));
                  uint32_t v2 = m_meshCurrent->addVertex(PositionMaterialNormal(Vector3DFloat(regX + 0.5f, regY + 0.5f, regZ - 0.5f), Vector3DFloat(0.0f, -1.0f, 0.0f), material));
                  uint32_t v3 = m_meshCurrent->addVertex(PositionMaterialNormal(Vector3DFloat(regX + 0.5f, regY + 0.5f, regZ + 0.5f), Vector3DFloat(0.0f, -1.0f, 0.0f), material));

                  m_meshCurrent->addTriangleCubic(v0,v2,v1);
                  m_meshCurrent->addTriangleCubic(v1,v2,v3);
               }

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

I don't really have a good explanation for this. It looks like 'addVertex' is failing to call 'push_back' on the std::vector of vertices. Normally I would say that this was due to an out of memory problem, but that doesn't explain why it would work in debug mode.

But just to be clear, this is still being reported as a 'buffer overrun'? You appear to have debug information available in your release build so can you see anything strange with the std::vector that it being added to? It it huge or size of zero or aything?

drwbns · **Joined:** Wed Jan 11, 2012 7:33 pm **Posts:** 109

m_vecVertices has about 5.3 million entries and m_vecTriangleIndices has about 7.9 million entries. Is this too many that could cause a crash? How could it run before just fine?

I'm just kind of lost now. Neither mode is working. It's also not a buffer overrun anymore after recompiling Polyvox from git and using that. I'm not really sure how I went from a working program to crashes without really modifying much. The call stack looks like I posted but the actual error message is -

Code:

Unhandled exception at 0x7518b9bc (KernelBase.dll) in WorldCraft.exe: Microsoft C++ exception: std::bad_alloc at memory location 0x0041da58..

Thanks for any help David.

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

drwbns wrote:

Code:

Unhandled exception at 0x7518b9bc (KernelBase.dll) in WorldCraft.exe: Microsoft C++ exception: std::bad_alloc at memory location 0x0041da58..

std::bad_alloc means it is out of memory. Try extracting a mesh for a much smaller region of the Volume. Cover the full extent of the y-axis (y is up in your case as I recall?) so that your cover the transition from solid to empty, but reduce the size of the region on the x and z axis.

And yes, your mesh really is large. As mentioned earlier, a size of something like 64x64x64 would be much more common. Even if you mesh is 'only' 100Mb, it needs to be 100Mb of continuous data which can be a problem if your memory is fragmented.

Also, if you want to switch back to the SurfaceExtractor you will probably find it uses less memory than the CubicSurfaceExtractorWithNormals.

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

You could also work with a smaller input heightmap until you have a properly working system.

drwbns · **Joined:** Wed Jan 11, 2012 7:33 pm **Posts:** 109

UPDATE: It seems to crash in release mode in during this section of code -

Code:

   for(int index = 0; index < vecIndices.size(); index++) {
      const PolyVox::PositionMaterialNormal& vertex = vecVertices[vecIndices[index]];
      const PolyVox::Vector3DFloat& v3dVertexPos = vertex.getPosition();
      const PolyVox::Vector3DFloat& v3dVertexNormal = vertex.getNormal();
      //const Vector3DFloat v3dRegionOffset(uRegionX * g_uRegionSideLength, uRegionY * g_uRegionSideLength, uRegionZ * g_uRegionSideLength);
      const PolyVox::Vector3DFloat v3dFinalVertexPos = v3dVertexPos + static_cast<PolyVox::Vector3DFloat>(mesh.m_Region.getLowerCorner());
      ogreMesh->position(v3dVertexPos.getX(), v3dVertexPos.getY(), v3dVertexPos.getZ());
      ogreMesh->normal(v3dVertexNormal.getX(), v3dVertexNormal.getY(), v3dVertexNormal.getZ());
      uint8_t mat = vertex.getMaterial() + 0.5;
      uint8_t red = mat & 0xF0;
      uint8_t green = mat & 0x03;
      uint8_t blue = mat & 0x0C;
      ogreMesh->colour(red*2, green*4, blue*4);// just some random colors, I'm too lazy for hsv
   }

Release mode is still crashing, even for non-smoothed surfaces. If I use CubicSurfaceExtractorWithNormals, I get a bad_alloc crash, if I use surfaceExtractor I get an access violation. Help?

drwbns · **Joined:** Wed Jan 11, 2012 7:33 pm **Posts:** 109

David Williams wrote:

drwbns wrote:

Code:

Unhandled exception at 0x7518b9bc (KernelBase.dll) in WorldCraft.exe: Microsoft C++ exception: std::bad_alloc at memory location 0x0041da58..

std::bad_alloc means it is out of memory. Try extracting a mesh for a much smaller region of the Volume. Cover the full extent of the y-axis (y is up in your case as I recall?) so that your cover the transition from solid to empty, but reduce the size of the region on the x and z axis.

And yes, your mesh really is large. As mentioned earlier, a size of something like 64x64x64 would be much more common. Even if you mesh is 'only' 100Mb, it needs to be 100Mb of continuous data which can be a problem if your memory is fragmented.

Also, if you want to switch back to the SurfaceExtractor you will probably find it uses less memory than the CubicSurfaceExtractorWithNormals.

So smaller regions are the only answer? It seems as though 100MB is tiny when you have 8 GB of RAM. How can I avoid memory fragmentation? Sorry, but it's seems as though I'm missing an easy answer here. I'm going to try smaller regions and see if I can devise a solution for splitting everything into smaller regions, even for mesh extraction. Also, what is the diffrence between shiftUpperCorner and setUpperCorner?

UPDATE: A smaller volume works just fine. What's strange is that drawing a mesh from a reduced region will still end in a crash if the volume is too large. Are there any code snippets for handling voxel regions?

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

drwbns wrote:

So smaller regions are the only answer? It seems as though 100MB is tiny when you have 8 GB of RAM. How can I avoid memory fragmentation?

You can read about memory fragmentation here: http://stackoverflow.com/questions/3770 ... gmentation

Basically, doing a small number of large allocations is more difficult than doing a large number of small allocations, even when the total amount of memory allocated is the same.

However, for PolyVox the more important consideration is allowing the terrain to be dynamic. I don't know how long it is taking you to run the surface extraction but I'd imagine it is a few seconds. If you have to regenerate the whole mesh when you change just one voxel then this won't be interactive. But if you have a large number of non-overlapping meshes then, when you modify a voxel, you only need to regenerate a small number of surrounding meshes.

drwbns wrote:

I'm going to try smaller regions and see if I can devise a solution for splitting everything into smaller regions, even for mesh extraction.

Yes, that is what you need to do.

drwbns wrote:

Also, what is the diffrence between shiftUpperCorner and setUpperCorner?

setUpperCorner() moves the corner to an absolute position, where shiftUpperCorner() moves it relative to it's current position (i.e. for adjusting it slightly).

drwbns wrote:

Are there any code snippets for handling voxel regions?

You can have a look at the VolumeChangeTracker in PolyVoxUtil for some ideas, though overall you should probably implement something yourself rather than using it directly. PolyVox is only concerned with giving you a mesh for the requested region. Deciding how to manage these, when to update then, etc is all left to the users code as it can vary for different applications.

Realtime Ogre 1.8 Terrain Component manipulation

Who is online