Entity's selection of LOD

[Numsgil]

My thread here discusses some issues I'm having with meshes. One of them, the last, I've tracked down to the _notifyCurrentCamera function in the Entity class.

Specifically, this code snippet:

Code: Select all

Real squaredDepth = mParentNode->getSquaredViewDepth(cam);

// Do Mesh LOD
// Adjust this depth by the entity bias factor
Real tmp = squaredDepth * mMeshLodFactorInv;
// Now adjust it by the camera bias
tmp = tmp * cam->_getLodBiasInverse();
// Get the index at this biased depth
mMeshLodIndex = mMesh->getLodIndexSquaredDepth(tmp);
// Apply maximum detail restriction (remember lower = higher detail)
mMeshLodIndex = std::max(mMaxMeshLodIndex, mMeshLodIndex);
// Apply minimum detail restriction (remember higher = lower detail)
mMeshLodIndex = std::min(mMinMeshLodIndex, mMeshLodIndex); 

The problem I have here is that the distance used is between the camera and the scene node. However, in my case, a better distance function to use would be between the camera and the bounding box used in frustrum culling.

Other distance functions could also be imagined, depending on the use. Maybe one based on the bounding sphere to camera distance, or based on the camera's distance to an arbitrary point.

I'd like to suggest either that measuring distance from the camera to the bounding box is the better metric to use, or that the user should be able to easily set alternate LOD measuring schemes.

[Numsgil]

A less ambitious fix, replace the first statement with this:

Code: Select all

Real squaredDepth;
if(getWorldBoundingBox(true).isFinite())
{
    squaredDepth = (getWorldBoundingBox(true).getCenter() - cam.getPosition()).squaredLength();
}
else
{
    squaredDepth = mParentNode->getSquaredViewDepth(cam);
}

It uses the center of the bounding box instead of the scene node if the bounding box is defined. I'd submit a patch, but getting the cvs ogre to compile is an ambitious project for me

[Numsgil]

On further analysis the above code is pretty slow.

[sinbad]

Since LOD transition distances are stored with the mesh, the assumption is that when setting them you take into account the size of the bounding sphere, if that's an important factor. It's a constant so there's no real need to factor it in to the runtime calculation.

[Numsgil]

There is if the scene node isn't inside the bounding sphere/box, as in my case.

[sinbad]

There are multiple reasons why it's a bad idea not to have your meshes centered in object space, this is merely one of them

[Numsgil]

Well, if I'm not doing it a good way, I'd like to know now What other problems am I going to face? Frustrum culling still works, for instance.

There's a single shared vertex buffer, you see, across multiple meshes, representing a section of the terrain. I update the terrain in real time, so this way it's much easier to prevent gaps and inconsistant data. I just update different sections as they change. The scene node is centered at the common center of all vertexes-- the center of the planet.

For the meshes to be centered at the origin, each mesh would need its own vertex buffer, which would require a great deal of sophistication on my part to ensure that the borders between meshes stary in sync. Even then, floating point inaccuracies could cause small gaps.

I could do it if there was a way to specify a local transform for a mesh that gets applied before the entity transfomation.

[Numsgil]

Thought about it some more, and here's what I'm proposing:

Mesh and Entities are given a position bias that the scene node gets transformed by for LOD distance calculations. Set a mesh with an LOD position bias of <0, 100, 0>, and it's like any scene nodes are +100 units above where they really are for that mesh's LOD calculations. Likewise entities would have a similar LOD position bias, which would either override/append with the mesh's.

The performance penalty would be negligable, and neatly solves my problem.