Realtime Ogre 1.8 Terrain Component manipulation

drwbns · **Joined:** Wed Jan 11, 2012 7:33 pm **Posts:** 109

David Williams wrote:

How close are you getting? Have you turned off smoothing (removed the LowPassFilter) and you are only setting voxels to max or min densities? If so you should not be more than one voxel away from the correct position. Ker's code may help here, but I believe a new raycast algorithm is needed to get it really accurate.

I basically have the camera's direction and origin just fine now, I think it was an issue with the mouse from OIS being invisible and not locked to the center screen position. The only problem left is that my raycasts are more than 1 voxel away from the surface like in the pictures, I may try ker's code and see if it helps.

Below I'm showing the same screen shot in wireframe and solid modes. The marker is more than 1 voxel inside the surface in some areas of the mesh.

drwbns · **Joined:** Wed Jan 11, 2012 7:33 pm **Posts:** 109

Here's my current code. I'm not really sure how to get ker's code working but here is what I have so far.

Code:

   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);

   PolyVox::Vector3DFloat sig(
            (dir.x < 0)?(-1.0f):((dir.x > 0)?(1.0f):(0)),
            (dir.y < 0)?(-1.0f):((dir.y > 0)?(1.0f):(0)),
            (dir.z < 0)?(-1.0f):((dir.z > 0)?(1.0f):(0))
            );

   PolyVox::Vector3DFloat r = (PolyVox::Vector3DFloat(lastPos) + sig*float(0.5) - start)/direction;

   // grabbed from my source, it shows the point the mouse points at inside the world
   // and its normal
   PolyVox::Vector3DFloat m_vecMousePointPosition;
   PolyVox::Vector3DFloat m_vecMousePointNormal;

   if(r.getX() < r.getY() && r.getX() < r.getZ()) {
     m_vecMousePointPosition = start + direction*r.getX();
     m_vecMousePointNormal.setX(-sig.getX());
     m_vecMousePointNormal.setY(0);
     m_vecMousePointNormal.setZ(0);

   } else if(r.getY() < r.getZ()) {
     m_vecMousePointPosition = start + direction*r.getY();
     m_vecMousePointNormal.setX(0);
     m_vecMousePointNormal.setY(-sig.getY());
     m_vecMousePointNormal.setZ(0);
   } else {
     m_vecMousePointPosition = start + direction*r.getZ();
         m_vecMousePointNormal.setX(0);
     m_vecMousePointNormal.setY(0);
     m_vecMousePointNormal.setZ(-sig.getZ());
   }


   
   // Find the voxel we are looking at.
   
   //PolyVox::Vector3DFloat start(100,100,100);
   //PolyVox::Vector3DFloat direction(0, -1, 0);

   //direction.normalise();
   direction *= 1000.0f; //Casts ray of length 1000
   
   PolyVox::RaycastResult raycastResult;
   PolyVox::Raycast<PolyVox::SimpleVolume, PolyVox::Density8> 
   raycast(volData, start, direction, raycastResult);
   raycast.execute();
   
   if(raycastResult.foundIntersection) {
      mKeyDevices.mSceneMgr->getSceneNode("mEditNode")->setPosition(raycastResult.intersectionVoxel.getX(), raycastResult.intersectionVoxel.getY(), raycastResult.intersectionVoxel.getZ());
   }

ker · **Posted:** Fri Feb 03, 2012 7:45 am

uhm... you need to execute the raycast before my code...

right before this line

Code:

PolyVox::Vector3DFloat r = (PolyVox::Vector3DFloat(lastPos) + sig*float(0.5) - start)/direction;

as lastPos is "raycastResult.previousVoxel"...

but as david properly pointed out:
1. my code is only for cubic surface extractor.
2. my code only improves the resulting position. you need to get the raycast working properly first... for your case using previousVoxel instead of intersectionVoxel should work fine.
3. which volume are you passing for the raycast? the same one you use the surfaceextractor on? or is there any filtering happening between the time of the raycast and the time of the surface extraction?

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

drwbns wrote:

The marker is more than 1 voxel inside the surface in some areas of the mesh.

Can you say how far inside it is? Perhaps print the start and end points? Is it just a few voxels inside or is it hundreds of voxels inside? I can see it's going in the right direction now but I'm concerned it might not be finding the solid voxels at all. Perhaps it's just stopping because it reached the end of the ray (which you set to have a length of 1000)?

If it is only going inside by a few voxels then the density values must be playing up somehow. What happens as you move towards and away from the surface? Does the amount of penetration change? We can try swapping the density volume for a material one but let's get confirmation of what is happening first.

I'll try to elaborate on the precision issues here to give you a better understanding. The Raycast class considers each voxel to be a cube, in the same way as the CubicSurfaceExtractorWithNormals does. The position it returns is the first solid voxel which it encounters, where 'solid' is defined by it having a density greater than the threshold. This is always an integer position because voxels are only defined at integer positions.

This should all be 100% accurate so far. But the point to realise is that this integer position corresponds to the center of one of the rendered cubes. Therefore, even though you have the exact correct position, it is still behind the surface. The center of the cube is always inside the cube, so the marker sphere has to be bigger than the cube in order to be seen.

In other words, the raycast does not give you the position the ray intersects the mesh, it only gives you the position of the first solid voxel. This is where ker's code comes in (I believe, I haven't really studied it). Once the raycast has found the center of the cube, Ker's code backtracks a little to find where it actually penetrated the mesh. But you can't use this until you are hitting the correct cube center every time, and it will only work for the cubic mesh anyway.

All the above is with regard to the cubic mesh, and things are more complex with a smooth mesh so we'll come to that later.

drwbns · **Joined:** Wed Jan 11, 2012 7:33 pm **Posts:** 109

ker wrote:

uhm... you need to execute the raycast before my code...

right before this line

Code:

PolyVox::Vector3DFloat r = (PolyVox::Vector3DFloat(lastPos) + sig*float(0.5) - start)/direction;

as lastPos is "raycastResult.previousVoxel"...

but as david properly pointed out:
1. my code is only for cubic surface extractor.
2. my code only improves the resulting position. you need to get the raycast working properly first... for your case using previousVoxel instead of intersectionVoxel should work fine.
3. which volume are you passing for the raycast? the same one you use the surfaceextractor on? or is there any filtering happening between the time of the raycast and the time of the surface extraction?

Ok, to answer - I'm still using cubicsurfaceExtractor. I've now added your code using previousVoxel and I'm not sure if it changed much of anything. I'm passing the same volume I used the SurfaceExtractor on and I'm not filtering anything at the moment.

drwbns · **Joined:** Wed Jan 11, 2012 7:33 pm **Posts:** 109

SOLVED: My node that I was attaching the mesh to was offset by 20 units on the X plane - doh!

UPDATE: Looks like I found the problem thanks to David. I printed out what voxel was currently being hit and realized it's hitting voxels outside the mesh. I looked further into this and it looks as though the mesh is shifted about 20 voxels away from where the actual invisible voxels are. I'm not sure why or how this happened but I'll post a screenshot showing that voxels and mesh aren't matched up properly, but wrong only in one dimension ( x or z plane I think). So my guess is that somewhere in the voxel to mesh code, the mesh is shifted by 20 ogre units or so.

David Williams wrote:

Can you say how far inside it is? Perhaps print the start and end points? Is it just a few voxels inside or is it hundreds of voxels inside? I can see it's going in the right direction now but I'm concerned it might not be finding the solid voxels at all. Perhaps it's just stopping because it reached the end of the ray (which you set to have a length of 1000)?

It's really hard to answer this question because it varies all over the terrain. On some surfaces it's an accurate hit, on other surfaces it can range anywhere from 1- 10 voxels(an estimate) inside the surface. I'll try to print some numbers soon if you think it will help.

Quote:

If it is only going inside by a few voxels then the density values must be playing up somehow. What happens as you move towards and away from the surface? Does the amount of penetration change? We can try swapping the density volume for a material one but let's get confirmation of what is happening first.

I think there's definately something along these lines happening, but how voxels are being rendered properly but raycasts are screwy is where I'm confused. Towards and away from the surface makes no difference, so it's definately nothing to do with ray length, as the amount of penetration does not change.

Quote:

I'll try to elaborate on the precision issues here to give you a better understanding. The Raycast class considers each voxel to be a cube, in the same way as the CubicSurfaceExtractorWithNormals does. The position it returns is the first solid voxel which it encounters, where 'solid' is defined by it having a density greater than the threshold. This is always an integer position because voxels are only defined at integer positions.

I'm not really sure I have any kind of threshold with my code but maybe I do? I didn't have any range of density from what I know, just solid or empty.

Quote:

This should all be 100% accurate so far. But the point to realise is that this integer position corresponds to the center of one of the rendered cubes. Therefore, even though you have the exact correct position, it is still behind the surface. The center of the cube is always inside the cube, so the marker sphere has to be bigger than the cube in order to be seen.

As you can see from the pictures, my marker is about the width of 10 voxel cubes, so I don't think this is the problem.

Quote:

In other words, the raycast does not give you the position the ray intersects the mesh, it only gives you the position of the first solid voxel. This is where ker's code comes in (I believe, I haven't really studied it). Once the raycast has found the center of the cube, Ker's code backtracks a little to find where it actually penetrated the mesh. But you can't use this until you are hitting the correct cube center every time, and it will only work for the cubic mesh anyway.

I think ker's code hasn't made a difference because I'm somehow hitting the wrong cube in certain areas of the mesh - being off by 10 voxels instead of hitting the suface voxel

Quote:

All the above is with regard to the cubic mesh, and things are more complex with a smooth mesh so we'll come to that later.

I agree completely, I definately just want the cubicSurface working before moving on which is why I've got minimal code in place.

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

drwbns wrote:

SOLVED: My node that I was attaching the mesh to was offset by 20 units on the X plane - doh!

It's always something obvious, huh ;-)

Well I guess you can now try switching back to the smooth SurfaceExtractor and see what kind of behaviour you have. I think you should still get within one voxel of your desired point, but I'm not certain about this. Maybe this is enough for your application, but if you want more precision you'll need an improved Raycast which understands the concept of densities better.

@ker - I think it might be worth integrating your code snippet into the Raycast class. It seems it could be useful for other people so I've added a note to the todo list.

ker · **Posted:** Sat Feb 04, 2012 12:33 pm

David Williams wrote:

@ker - I think it might be worth integrating your code snippet into the Raycast class. It seems it could be useful for other people so I've added a note to the todo list.

sure, but most of my raycasts do not use this as I just want to check if two points can see each other, not where the raycast hit the world. It's not like it's much overhead, but still unnecessary in many cases.

About the topic... I misread the problem... I didn't know that the hit position is many voxels off the correct position.

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

It should be optional of course, but I think might be useful for some applications.

Perhaps the code can be simplified though (at least the part which builds the plane). A point on the plane can be found as the average of the current and previous voxels, and the plane normal is the vector from the current voxel to the previous one. I think that gets rid off some if statements.

Untested, and I'm mostly writing it down for when I come back to this thread in the future.

drwbns · **Joined:** Wed Jan 11, 2012 7:33 pm **Posts:** 109

I'm not sure when it happened, but now I get a buffer overrun crash in Release mode. Debug works fine but takes a really long time to do the smoothing and surfaceExtraction. What's weird is it crashes after creating a frame listener in Ogre, basically initialization stuff. I'm not really sure how to debug this since the debug version works fine - do you guys have any tips?

Code:

A buffer overrun has occurred in WorldCraft.exe which has corrupted the program's internal state. Press Break to debug the program or Continue to terminate the program.

For more details please see Help topic 'How to debug Buffer Overrun Issues'.

I've also tried building with _SECURE_SCL=1 but I just find strange garbled strings, is this normal?

Realtime Ogre 1.8 Terrain Component manipulation

Who is online