Sorry, should have been more clear - we're talking about 32-bit ints here so the possible range is actually -2147483648 to +2147483647

And yes, negative numbers are supported now (also thanks to ker). They work in the same way so you can just pass a negative position to setVoxel/getVoxel.

Just quietly, that's a LOT of potential data.

Yes, and it's just a theoretical limit. Whether you can actually manage that much data (even with streaming) remains to be seen, but the point is the Volume class does have enough range. There's also issues of floating point precision at high ranges.

Actually Notch has been blogging about this recently. Basically Minecraft starts to fall apart when you get a long way away, but it's considered a feature

Until now I passed a width, height and depth. How does it make it negative region then?

How cann I specify -512 -> 511?

So what we discussed about now is the version on svn?

P.S. RayCast and smoothRegion work with the new version? just want to be sure before I update

I committed a few seconds ago. There is a new constructor for the Volume class which takes a Region as a paramater. The Raycast and smoothRegion functions should continue to work though I can't thourougly test everything so let me know if there are problems.

Note that the Region class has changed slightly, in that the width(), height(), and depth() functions have been deprecated and replaced by getWidth(), getHeight(), and getDepth(). These new sizes are 1 bigger than before. Previously a Region going from 0 to 511 would have width() returning 511, but getWidth() return 512. I think this makes more sense.

Ok, but I am using getLowerCorner().getZ(), will it still work as intended?

Plus, in getUpperCorner.getZ() will I need to replace z <= to z < or behavior for getUpper/LowerCorner.getZ remains correct?

Also, will cropTo work properly still?

Also, does it mean the volume data type is changed? until now I used:


Should I change Vector3DInt16 to anything else?

I am going to update my polyvox now

I believe these should all still work as before. The upper and lower bounds are the same. It's just the way the width, etc is calculated which has changed.

Probably... try it and see. You can also use static_cast on the Vector3D class if you need to. Let me know how this works out.

The Raycast class was still returning a Vector3DInt16, I've now updated this to Vector3DInt32 if you update again.

Thank you very much for the support. Updating now

region is still Vector16Int, does it make sense if to quote


Or did you forget to change that?

Edit: Ok, Odd, am I using a different SVN without the streaming version? I think I just got what I already had?

Edit 2: My bad, it wasn't set to the RLE SVN.