error: no match for 'operator<' in '__x < __y'

kattle87 · **Joined:** Thu Mar 10, 2011 10:34 am **Posts:** 19

I am getting this error when I try to compile my code using PolyVox with a custom made class, that is more or less just a collection of integer types...

Code:

class SingleBlock {
public:
   uint16_t VariousData;
   uint16_t cStress;
   uint16_t oStress;
   uint8_t overStressed;
   uint8_t OtherData;
};
PolyVox::Volume<SingleBlock> Field;

It's a strange error for me since I didn't expected my class to need a comparison operand

What is a comparison between voxels used for?

Also, another maybe related question: if I have to loop through all the blocks (and there's quite a lot of them), do I have to care about anything in particular for getting a decent speed?

ker · **Posted:** Tue Mar 29, 2011 7:01 pm

are you using the svn trunk version or the svn RLE version?

also, post the code of the line where the error occurs. and the full error message.

and depending on what other classes (surfaceextractor or similar) you intend to use, don't create your own voxel type from scratch but copy one of the existing types from polyvox.

kattle87 · **Joined:** Thu Mar 10, 2011 10:34 am **Posts:** 19

Well, I actually fixed that error just adding an "operator<" member in my class. It's just that I was really curious about why there should be an operator< in the first place (perhaps for sorting things somewhere internally?) and how much is defining the operator< important for when you are looping on all the blocks

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

Ha, it actually took me a few minutes to work out what was going on here. The VoxelType need to be sortable because in the old version of the volume it is used as a key in a map. The map is used so that for a given voxel value it can find a block of voxels which are entirely that value. It's part of the old compression system which is now replaced in the RLE branch. But thatnks for pointing it out - in the RLE branch this operator isn't needed anymore and can be removed.

kattle87 wrote:

Also, another maybe related question: if I have to loop through all the blocks (and there's quite a lot of them), do I have to care about anything in particular for getting a decent speed?

'Block' has a specific meaning in PolyVox in that it is a collection of voxels. A volume is then a collection of blocks. I suspect you actually you want to iterate over voxels?

In the old system (which it appears you are using) voxels you will get the best cache efficiency by iterating over the voxels 'z' changes slowest and 'x' changes fastest. The same is true when iterating over blocks within a volume. That said, this might change in the future and it also relies on knowing about the internal representation which isn't exposed.

In the future I might add some code which can be used to iterate over voxels in the best order. In the mean time, you should also look at the VolumeSampler if you want read-only access.

beyzend · **Joined:** Sat Sep 18, 2010 9:45 pm **Posts:** 189

David Williams wrote:

In the old system (which it appears you are using) voxels you will get the best cache efficiency by iterating over the voxels 'z' changes fastest and 'x' changes slowest. The same is true when iterating over blocks within a volume. That said, this might change in the future and it also relies on knowing about the internal representation which isn't exposed.

Really? In PolyVox trunk the surface extractors has the inner loop iterate over Xs. So you are saying i should do:

Code:

for(x in region)
  for(y in region)
    for(z in region)

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

Sorry, no, I typed it backwards (fixed now). You should have z on the outside and x on the inside:

Code:

for(z in region)
  for(y in region)
    for(x in region)

kattle87 · **Joined:** Thu Mar 10, 2011 10:34 am **Posts:** 19

Ok, I was in fact iterating over voxels, not over blocks!

Now I hope to get something done here, I'm experimenting with some little nice (and extremely computational intensive

) thing, but I guess I'm not having anything ready for the show before next weekend or perhaps even later. Visualization can be difficult sometime!

error: no match for 'operator<' in 'x < y'

Who is online