setVoxelAt() Incompatible with Custom VoxelType?

DJDD · **Joined:** Tue Mar 08, 2011 3:57 am **Posts:** 46

I've created a custom 'VoxelType' class called Block that I use to instantiate and create the volume with as per below:

Code:

PolyVox::Volume<Block> *volData;
volData = new PolyVox::Volume<Block>(144, 144, 1);

I get and set the block data like so:

Code:

Block block = volData->getVoxelAt( 
   (currentCell.X - firstCell.X) * 16 + lx,
   (currentCell.Y - firstCell.Y) * 16 + ly,
   (currentCell.Z - firstCell.Y) * 16);

block.x = gx;
block.y = gy;
block.z = currentCell.Z;
block.blockClass = tileTypeTable[tiletypes[lx][ly]].c;
block.blockMaterial = tileTypeTable[tiletypes[lx][ly]].m;

volData->setVoxelAt( 
   (currentCell.X - firstCell.X) * 16 + lx,
   (currentCell.Y - firstCell.Y) * 16 + ly,
   (currentCell.Z - firstCell.Y) * 16, block);

But unfortunately I get the following compile fatal error:

Code:

1>e:\programming\libraries\polyvox\library\polyvoxcore\include\Volume.inl(243): error C2678: binary '!=' : no operator found which takes a left-hand operand of type 'Block' (or there is no acceptable conversion)
1>          C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\system_error(425): could be 'bool std::operator !=(const std::error_code &,const std::error_condition &)'
1>          C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\system_error(432): or       'bool std::operator !=(const std::error_condition &,const std::error_code &)'
1>          e:\programming\libraries\leadwerks engine sdk\cpp\mathlib.h(82): or       'const bool LE::operator !=(const LE::TVec2 &,const LE::TVec2 &)'
1>          e:\programming\libraries\leadwerks engine sdk\cpp\mathlib.h(83): or       'const bool LE::operator !=(const LE::TVec2 &,const LE::flt)'
1>          e:\programming\libraries\leadwerks engine sdk\cpp\mathlib.h(84): or       'const bool LE::operator !=(const LE::TVec3 &,const LE::TVec3 &)'
1>          e:\programming\libraries\leadwerks engine sdk\cpp\mathlib.h(85): or       'const bool LE::operator !=(const LE::TVec3 &,const LE::flt)'
1>          e:\programming\libraries\leadwerks engine sdk\cpp\mathlib.h(86): or       'const bool LE::operator !=(const LE::TVec4 &,const LE::TVec4 &)'
1>          e:\programming\libraries\leadwerks engine sdk\cpp\mathlib.h(87): or       'const bool LE::operator !=(const LE::TVec4 &,const LE::flt)'
1>          C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\guiddef.h(197): or       'int operator !=(const GUID &,const GUID &)'
1>          while trying to match the argument list '(Block, Block)'
1>          e:\programming\libraries\polyvox\library\polyvoxcore\include\Volume.inl(220) : while compiling class template member function 'bool PolyVox::Volume<VoxelType>::setVoxelAt(uint16_t,uint16_t,uint16_t,VoxelType)'
1>          with
1>          [
1>              VoxelType=Block
1>          ]
1>          DFWorld.cpp(104) : see reference to class template instantiation 'PolyVox::Volume<VoxelType>' being compiled
1>          with
1>          [
1>              VoxelType=Block
1>          ]
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

Any ideas? Is PolyVox Volume incompatible with some custom VoxelTypes?

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

Ok, the first thing to note is that PolyVox already has a class called Block. It's within the PolyVox namespace but I guess there's some chance you have a 'using namespace PolyVox' somewhere in your code. Probably best to rename your class just to be sure.

Also:

Code:

volData = new PolyVox::Volume<Block>(144, 144, 1);

The dimensions of the volume should be a multiple of the Block size (I meanse the PolyVox::Block here) which I think defaults to 32.

Also, what does your custom voxel type look like? Did you base it off the Density or Material classes?

DJDD · **Joined:** Tue Mar 08, 2011 3:57 am **Posts:** 46

1. Ok, I'll see about refactoring my code without a Block class.
2. I'll fix up the volume size.
3. No I have not based it off of the Density or Material classes - Though I think I see now why one should. Any advice on the best way to do that? Can I can use inheritance or something?

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

DJDD wrote:

3. No I have not based it off of the Density or Material classes - Though I think I see now why one should. Any advice on the best way to do that? Can I can use inheritance or something?

Copy and paste, then rename and edit :-)

So far I've wanted to steer clear of inheritance and virtual functions, and the use of templates makes them mostly unnecessary.

DJDD · **Joined:** Tue Mar 08, 2011 3:57 am **Posts:** 46

Is there any further documentation of Density and Material types and what impact they have on all the different functions?

To be honest, I don't get get how to modify the class to suit my own needs.

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

There's not really any documentation... what are you trying to achieve?

If you want to pass a Volume to one of the surface extractors, then currently they all expect the VoxelType to provide both getDensity() and getMaterial() functions. The value returned by getDensity() is used to control the shape of the mesh - the value is compared with a threshold to determine whether any given voxel is considered solid. The value returned by getMaterial() is simply passed into the vertex data so it can be used later during rendering.

If you want to create your own voxel type then you need to provide at least these two functions if you wish to use the built in surface extractors. But if you are writing your own surface extractor then you can make a voxel contain whatever you like... it could just operate on floats for example. You could still store these floats in a Volume (because it's templatised) and then pass this Volume into your own algortithms.

At least this is the principle... you might find you can't actually create a volume of floats because I've made a bad assumption somewhere but we should be able to fix this.

As an analogy, consider how std::vector works. You can store any type in an std::vector, it doesn't need to derive from any particular base class. But some algorithms which operate on an std::vector do require the type to implement specific functionality, for example sorting requires that your type has a comparison operator. Your type only needs this functionality if you actually try to use it. So you could say that Volume is like std::vector, sort() is like the surface extractor, and the getDensity()/getMaterial() are like the comparison operator. Hope that makes some kind of sense...

DJDD · **Joined:** Tue Mar 08, 2011 3:57 am **Posts:** 46

I basically only really want to ADD a whole lot more properties. I'd also keep density/material, but i'd link them to other data(enum'd ints). But unfortunately I don't understand C++ templates as of yet and I don't have the knowledge to modify the MaterialDensityPair function.

I'll keep at it, so don't feel like you have to spell it out for me. However a more voxel-type agnostic engine might be worth looking into in the future. Obviously some of its variable types are critical to how your engine works though, so I understand the limitations.

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

It depends on what you want these extra properties to do. For example, maybe you want to modify the way the surface extractor behaves based on these properties. In this case you can add the property to you new voxel type, and then modify the surface extractor (or create a new one) to query this property and make use of it. The density is an example of this kind of property, in that the density controls the shape of the extracted mesh.

Alternatively you might just want to pass the data through to the extracted mesh. The material is an example of this - the CubicSurfaceExtractorWithNormals doesn't use this property itself, it just sets the material in the mesh it generates. However, this might mean you need to create a new VertexType as well.

And yes, you probably will need to get your head around templates first. Once you do they are a pretty powerful tool for writing fast and generic code

setVoxelAt() Incompatible with Custom VoxelType?

Who is online