nono, that's the only negative direction I added... (z-axis)
it appears on x and z.. y i didn't test

yes they are missing,not black

and it's only the negative problem, I'm pretty sure that the streaming has nothing to do with it... but I should check that first maybe

ok it's definitly not the volume.
and as I understand the whole setup, it's not surfaceextractor either

I'm relatively sure it's VolumeSampler's fault.
the peek and move functions must either mess up at the lower or upper border of a volumeblock, because they use % instead of bitshifting and subtracting.

the blocks in the negative range are accessed one voxel off the actual position...
I have not dumped anything yet, these are just guesses, but the problem probably occurs to some variation of the following:

for a block size of 16 you have blocks at:
0,0,0 to 15,15,15
16,16,16 to 31,31,31
this thinking leads to blocks from:
-16,-16,-16 to -1,-1,-1
when in fact the following block is used:
-15,-15,-15 to 0,0,0

Yep, that sounds possible. It also explains why the CubicSurfaceExtractor is not affected as it doesn't use the VolumeSampler (though it should). But the use of % is just in the optimisations - you can comment out the 'if' part and make it always call the 'else' part which calls setVoxel().

That is replace


With

for all the moveXXX functions and replace



with:



for all the peekXXX() functions. This will let you test whether that really is the problem, then we can worry about fixing the logic

jup that was the problem.
the move commands work fine. it's only the peek commands that are an issue.
also it's only the positive movement that's a problem, the negative one works (I checked with peekVoxel1px0py0pz vs peekVoxel1nx0py0pz )

Great, I suspect the negative move function will have the same problem but I'm not sure it's actually used anywhere - it's just there for completeness I think.

If it's not clear how to fix this code then you can just leave it commented out while you do the streaming and I'll look at it before we merge back into the trunk.

Since I have no idea how I can help, how about a whoop whoop!!! for your progress?

progress is: Streaming works, negative chunk borders are still messed up, as I was too lazy so far to test out what I need to do to fix the issue (and still have some speed optimization)
I mean there are 27 functions I need to edit sorry, it'll take some time (optimizations are not fun at all)

basically what I need to do is to create an if/else in every peek function that tests if the coordinates are < or <= to zero depending on whether I'm moving upwards or downwards... and then use 2 different methods of obtaining borders for below zero and above zero...

OR change every into

which is kindof weird considering the two bitshift operations that might instead be replaced by a bitand operation for some bitmask equal to(m_uBlockSideLength-1) (which again might not work on all systems)

if you want I can post the current diff file here and you can play around with it... CubicSurfaceExtractor* works just fine

Well moral support is always nice. But it's really ker doing all the work here

Yep, I'm happy to look at this VolumeSampler issue - it makes more sense because I know the code. Can you give me a patch which I can apply to the current head of the RLE branch, so I can recreate the problem myself? If so I'll see what I can do about fixing those optimisations. In the mean time you can just comment them out while working on your streaming stuff.

Just a blind shot in the dark at the backside of a lego barn, but might this be a similar reason that Ogre::Terrain uses power of two plus 1 heightmaps?

Power of two sizes are often used because they allow operations such as division and modulus to be replaced by faster bitshifting operations. This is the reason they are using in PolyVox and also why power-of-two textures are preferred in graphics cards (or at least they used to be, not sure how much it matters now). I'm sure Ogre will have the same kind of logic.