Volumes Of Fun
http://www.volumesoffun.com/phpBB3/

Paging Volume (Previously: Streaming Volume)
http://www.volumesoffun.com/phpBB3/viewtopic.php?f=2&t=145		 Page 5 of 15
Author:  ker [ Sun Mar 06, 2011 11:03 am ]
Post subject:  Re: Streaming Volume
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
Author:  ker [ Sun Mar 06, 2011 1:15 pm ]
Post subject:  Re: Streaming Volume
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
Author:  David Williams [ Sun Mar 06, 2011 1:35 pm ]
Post subject:  Re: Streaming Volume
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
Code:
template <typename VoxelType>
   void VolumeSampler<VoxelType>::moveNegativeZ(void)
   {
      //Note the *post* decreament here
      if((mZPosInVolume--) % mVolume->m_uBlockSideLength != 0)
      {
         //No need to compute new block.
         mCurrentVoxel -= mVolume->m_uBlockSideLength * mVolume->m_uBlockSideLength;
      }
      else
      {
         //We've hit the block boundary. Just calling setPosition() is the easiest way to resolve this.
         setPosition(mXPosInVolume, mYPosInVolume, mZPosInVolume);
      }
   }


With
Code:
template <typename VoxelType>
   void VolumeSampler<VoxelType>::moveNegativeZ(void)
   {
      //Note the *post* decreament here
      /*if((mZPosInVolume--) % mVolume->m_uBlockSideLength != 0)
      {
         //No need to compute new block.
         mCurrentVoxel -= mVolume->m_uBlockSideLength * mVolume->m_uBlockSideLength;
      }
      else*/
      {
         //We've hit the block boundary. Just calling setPosition() is the easiest way to resolve this.
         setPosition(mXPosInVolume, mYPosInVolume, mZPosInVolume);
      }
   }


for all the moveXXX functions and replace

Code:
template <typename VoxelType>
   VoxelType VolumeSampler<VoxelType>::peekVoxel1nx1ny1nz(void) const
   {
      if((mXPosInVolume%mVolume->m_uBlockSideLength != 0) && (mYPosInVolume%mVolume->m_uBlockSideLength != 0) && (mZPosInVolume%mVolume->m_uBlockSideLength != 0))
      {
         return *(mCurrentVoxel - 1 - mVolume->m_uBlockSideLength - mVolume->m_uBlockSideLength*mVolume->m_uBlockSideLength);
      }
      return mVolume->getVoxelAt(mXPosInVolume-1,mYPosInVolume-1,mZPosInVolume-1);
   }


with:

Code:
template <typename VoxelType>
   VoxelType VolumeSampler<VoxelType>::peekVoxel1nx1ny1nz(void) const
   {
      /*if((mXPosInVolume%mVolume->m_uBlockSideLength != 0) && (mYPosInVolume%mVolume->m_uBlockSideLength != 0) && (mZPosInVolume%mVolume->m_uBlockSideLength != 0))
      {
         return *(mCurrentVoxel - 1 - mVolume->m_uBlockSideLength - mVolume->m_uBlockSideLength*mVolume->m_uBlockSideLength);
      }*/
      return mVolume->getVoxelAt(mXPosInVolume-1,mYPosInVolume-1,mZPosInVolume-1);
   }


for all the peekXXX() functions. This will let you test whether that really is the problem, then we can worry about fixing the logic :)
Author:  ker [ Sun Mar 06, 2011 3:18 pm ]
Post subject:  Re: Streaming Volume
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 )
Author:  David Williams [ Sun Mar 06, 2011 6:27 pm ]
Post subject:  Re: Streaming Volume
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.
Author:  Xypher Orion [ Sun Mar 06, 2011 10:47 pm ]
Post subject:  Re: Streaming Volume
Since I have no idea how I can help, how about a whoop whoop!!! for your progress? :mrgreen:
Author:  ker [ Mon Mar 07, 2011 6:57 pm ]
Post subject:  Re: Streaming Volume
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
Code:
%m_uBlockSideLength == 0
into
Code:
>>m_uBlockSideLengthPower<<m_uBlockSideLengthPower == m*PosInVolume


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
Author:  David Williams [ Mon Mar 07, 2011 8:39 pm ]
Post subject:  Re: Streaming Volume
Xypher Orion wrote:
Since I have no idea how I can help, how about a whoop whoop!!! for your progress? :mrgreen:

Well moral support is always nice. But it's really ker doing all the work here :)
ker wrote:
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)
.
.
.
if you want I can post the current diff file here and you can play around with it... CubicSurfaceExtractor* works just fine

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.
Author:  Xypher Orion [ Mon Mar 07, 2011 10:03 pm ]
Post subject:  Re: Streaming Volume
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?
Author:  David Williams [ Mon Mar 07, 2011 11:09 pm ]
Post subject:  Re: Streaming Volume
Xypher Orion wrote:
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.
Page 5 of 15 All times are UTC
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/