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

Realtime Ogre 1.8 Terrain Component manipulation
http://www.volumesoffun.com/phpBB3/viewtopic.php?f=14&t=312		 Page 13 of 13
Author:  ker [ Mon Feb 27, 2012 3:41 pm ]
Post subject:  Re: Realtime Ogre 1.8 Terrain Component manipulation
drwbns wrote:
Since LargeVolume doesn't have a set size, how do I go about splitting it into mesh regions?


well... exactly like before, just only compute the mesh regions you actually need.
it depends completely on your setup... there's no universal way...

drwbns wrote:
UPDATE: I just passed some initial sizes to my volumeSplitter function instead of the volume sizes and that works fine but still, my raycasts are failing on the LargeVolume, no intersection is found?

but the raycasts worked before the step to LargeVolume? (I don't remember, you probably said something earlier in this thread)

David Williams wrote:
Except in the case of it being '0' we can test for that... maybe we should consider changing the behaviour of LargeVolume so that if these handlers are not provided then it will never do paging and will just run out of memory? I can't think through this in detail at the moment as I'm focusing on other parts of PolyVox, but maybe something for the future?


hmm... maybe largevolume should be stripped of the paging feature and there should be a second one (PagingVolume)...

LargeVolume would then require something like eraseEverythingOutsideRegion(Region reg) to make sure memory could be freed.
flush and prefetch become unnecessary in that case.

PagingVolume would require those callbacks and allow all the current features, but be more difficult to use properly

I would actually be using both... PagingVolume on the server side and LargeVolume on the client side.
Once the git becomes less stormy, I'll reopen this issue in some thread to collaborate and implement the changes.
Author:  drwbns [ Mon Feb 27, 2012 3:43 pm ]
Post subject:  Re: Realtime Ogre 1.8 Terrain Component manipulation
Yes, the raycasts worked perfectly before changing the volume to a LargeVolume..I called like this -

Code:
   OIS::MouseState ms = mKeyDevices.mMouse->getMouseState();
   OIS::Keyboard *kb = mKeyDevices.mKeyboard;

   ms.Y.abs = mCamera->getViewport()->getActualHeight() / 2;
   ms.X.abs = mCamera->getViewport()->getActualWidth() / 2;

   Ogre::Ray ray =  mCamera->getCameraToViewportRay((float)ms.X.abs / (float)ms.width,  (float)ms.Y.abs / (float)ms.height);   
   Ogre::Vector3 pos = ray.getOrigin();   
   Ogre::Vector3 dir = ray.getDirection();   
   // Find the voxel we are looking at.       
   PolyVox::Vector3DFloat start(pos.x,pos.y,pos.z);   
   PolyVox::Vector3DFloat direction(dir.x, dir.y, dir.z);

   direction *= 1000.0f; //Casts ray of length 1000
   
   PolyVox::RaycastResult raycastResult;
   PolyVox::Raycast<PolyVox::LargeVolume, PolyVox::Density8> raycast(&volume, start, direction, raycastResult);
   raycast.execute();

 if(raycastResult.foundIntersection) {
...
}
Author:  David Williams [ Tue Feb 28, 2012 9:45 am ]
Post subject:  Re: Realtime Ogre 1.8 Terrain Component manipulation
It still makes me a little nerveous that you are using LargeVolume with these empty handler functions. Be sure to read the LargeVolume documentation and understand what these handler functions would normally do, because by passing empty ones it means PolyVox may simply throw away some of your data if it is short on memory. This could explain why your intersection fails.

If you do want to use the LargeVolume then at least define you overflow handler like this:

Code:
void dataOverflowHandler(const PolyVox::ConstVolumeProxy<Density8>&, const PolyVox::Region&)
{
   std::cerr << "Warning: Throwing away data" << std::endl;
}


And watch out for this warning. Alternatively add an assert()/breakpoint.

Otherwise, try again with the Simple Volume. It should support negative coordinates, and even if the ray leaves the volume it shouldn't crash as voxels outside are just considered to be zero. The interfaces to the LargeVolume and SimpleVolume are quite similar (except for the handler functions), so it is easy to swap between them.
Author:  drwbns [ Tue Feb 28, 2012 5:18 pm ]
Post subject:  Re: Realtime Ogre 1.8 Terrain Component manipulation
The warning is being triggered by raycasts, so how do I stop the data being tossed?

I'm not sure I really understand what's going on at this point. I wouldn't have changed to a LargeVolume if SimpleVolume was working for negative indices. It was constantly asserting when searching for a previousVoxel at the edge of the volume - therefore leading to this asserting in simpleVolume.inl -

Code:
   template <typename VoxelType>
   bool SimpleVolume<VoxelType>::setVoxelAt(int32_t uXPos, int32_t uYPos, int32_t uZPos, VoxelType tValue)
   {
      assert(this->m_regValidRegion.containsPoint(Vector3DInt32(uXPos, uYPos, uZPos)));
Author:  David Williams [ Wed Feb 29, 2012 9:29 am ]
Post subject:  Re: Realtime Ogre 1.8 Terrain Component manipulation
drwbns wrote:
The warning is being triggered by raycasts, so how do I stop the data being tossed?

The LargeVolume will store as much data as it can but sometimes there is too much. When there is too much data the LargeVolume calls the dataOverflowHandler which is provided by the user. The users implementation of this function is supposed to do something with this data (like saving it to disk) so that it can be provided back to the LargeVolume later if it requests it (via the dataRequiredHandler).

Providing empty functions here is risky because you claim (to the LargeVolume) that you are handling the situation, but actually the data is just being lost.

You can disable the handlers but I'm a little hazy about what it then does in the case of an overflow (ker has more experience here).

drwbns wrote:
I'm not sure I really understand what's going on at this point. I wouldn't have changed to a LargeVolume if SimpleVolume was working for negative indices. It was constantly asserting when searching for a previousVoxel at the edge of the volume - therefore leading to this asserting in simpleVolume.inl -

Code:
   template <typename VoxelType>
   bool SimpleVolume<VoxelType>::setVoxelAt(int32_t uXPos, int32_t uYPos, int32_t uZPos, VoxelType tValue)
   {
      assert(this->m_regValidRegion.containsPoint(Vector3DInt32(uXPos, uYPos, uZPos)));


Can you try this again and have a closer look at the callstack when this assert occurs? The Raycasting code never calls 'setVoxelAt()' so it can't be quite as you describe. Perhaps you had some code which was trying to modify one of the voxels based on where the user clicked, or something like that?

That said, I did just try some experiments with SimpleVolume and negative coordinates and there does appear to be something weird going on. Maybe there is a bug in there but I don't have time to investigate further at the moment.
Author:  ker [ Wed Feb 29, 2012 9:43 am ]
Post subject:  Re: Realtime Ogre 1.8 Terrain Component manipulation
David Williams wrote:
You can disable the handlers but I'm a little hazy about what it then does in the case of an overflow (ker has more experience here).


The current implementation of LargeVolume will drop data in the case where there are no handlers.

I'd love to fix this for everyone (I have a better LargeVolume locally), but I do not want to get the latest git and put that better LargeVolume in there until david annonces that it's "safe".

What you can do right now, is call setMaxNumberOfBlocksInMemory for a large number (if your constructor's third argument is 32 (and since you use Density8), then if you call setMaxNumberOfBlocksInMemory(32768) your Volume will use a little more than 1 gigabyte of memory before discarding blocks (uncompressed, it will most likely be a lot less).
you can put that number arbitrarily high, but expect out of memory crashes if your world gets really big.
Author:  drwbns [ Wed Feb 29, 2012 1:49 pm ]
Post subject:  Re: Realtime Ogre 1.8 Terrain Component manipulation
David Williams wrote:
Can you try this again and have a closer look at the callstack when this assert occurs? The Raycasting code never calls 'setVoxelAt()' so it can't be quite as you describe. Perhaps you had some code which was trying to modify one of the voxels based on where the user clicked, or something like that?


Yes, I'm doing exactly that - modifying voxels based on a mouse ray hit location

Code:
   std::map<Vector3DInt32,Polymesh>::iterator it;
   if (ms.buttonDown(OIS::MB_Left)){
      if(raycastResult.foundIntersection) {
         Vector3DInt32 newVoxel = (raycastResult.previousVoxel) / divisor;

         //volume.setVoxelAt(newVoxel,VoxelTypeTraits<Density8>::MinDensity);
         if( raycastResult.intersectionVoxel.getX() > 0 && raycastResult.intersectionVoxel.getY() > 0 && raycastResult.intersectionVoxel.getZ() > 0 )
            if( raycastResult.intersectionVoxel.getX() < volume.getDepth() && raycastResult.intersectionVoxel.getY()  < volume.getHeight() && raycastResult.intersectionVoxel.getZ()  < volume.getWidth() )
            volume.setVoxelAt(raycastResult.intersectionVoxel,VoxelTypeTraits<Density8>::MinDensity);

            if(newVoxel != intersect) {
            it = polyMeshes.find(Vector3DInt32(newVoxel.getX(),newVoxel.getY(),newVoxel.getZ()));
               //TODO add check for size of array, if too small, resize array to a larger value;
            if(it != polyMeshes.end())
               PolyvoxMeshtoManual(it->second);
         }

         it = polyMeshes.find(Vector3DInt32(intersect.getX(),intersect.getY(),intersect.getZ()));
         
         if(it != polyMeshes.end())
         PolyvoxMeshtoManual(it->second);
      }
   }


David Williams wrote:
That said, I did just try some experiments with SimpleVolume and negative coordinates and there does appear to be something weird going on. Maybe there is a bug in there but I don't have time to investigate further at the moment.


I'll switch back to SimpleVolume to try to get a call stack picture
Author:  drwbns [ Wed Feb 29, 2012 2:02 pm ]
Post subject:  Re: Realtime Ogre 1.8 Terrain Component manipulation
ker wrote:
David Williams wrote:
You can disable the handlers but I'm a little hazy about what it then does in the case of an overflow (ker has more experience here).


The current implementation of LargeVolume will drop data in the case where there are no handlers.

I'd love to fix this for everyone (I have a better LargeVolume locally), but I do not want to get the latest git and put that better LargeVolume in there until david annonces that it's "safe".

What you can do right now, is call setMaxNumberOfBlocksInMemory for a large number (if your constructor's third argument is 32 (and since you use Density8), then if you call setMaxNumberOfBlocksInMemory(32768) your Volume will use a little more than 1 gigabyte of memory before discarding blocks (uncompressed, it will most likely be a lot less).
you can put that number arbitrarily high, but expect out of memory crashes if your world gets really big.


I tried your high value (32768) and that works great for displaying the mesh correctly and correcting the raycasting problem, I'm still testing dynamic resizing of the volume though. I need a create a method where I can come up with a PolyMesh region based on the previousVoxel position, if of coarse that PolyMesh doesn't exist already which is only a matter of checking if it's already in the PolyMesh vector.
Page 13 of 13 All times are UTC
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/