MESH class broken for descending value lod strategies

Discussion area about developing or extending OGRE, adding plugins for it or building applications on it. No newbie questions please, use the Help forum for that.
User avatar
coreSOLO
Gnoblar
Posts: 9
Joined: Tue Apr 06, 2010 10:08 am
x 1

MESH class broken for descending value lod strategies

Post by coreSOLO »

While working with descending value LOD strategies (like PixelCountLodStrategy) I came across this:
  • While we create a MESH as well as when we do "removeLodLevels", "lod.value" is reset to "mLodStrategy->getBaseValue()" while "lod.userValue" is reset to 0 for highest detail mesh. This works fine for Ascending value LOD strategies, but totally breaks Descending value LOD strategies as you will see.
  • When I add custom lod levels, their "lod.userValue"s (and "lod.value"s) are set as per my preference. All good here.
  • Now when I save this mesh using "MeshSerializer", only "lod.userValue" are written and not "lod.value". Hence for all other LODs (except highest level LOD) proper values are written. However for highest level, ZERO is written. This is fine for Ascending value LOD strategies, but it should have been highest float value for Descending value LOD strategies.
  • When I load this file later, "lod.value"s are initiated from "lod.userValue", hence for highest level mesh, "lod.value" becomes zero rather than LOD strategie's base value.
  • Hence for Descending value LOD strategies, "getIndex" (which internally calls "getIndexDescending") always returns index ZERO and LOD never transits.
I believe in "Mesh::Mesh" and "Mesh::removeLodLevels", "lod.userValue" for highest level should be reset to "mLodStrategy->getBaseValue()" just like "lod.value".
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66

Re: MESH class broken for descending value lod strategies

Post by sinbad »

Hmm, sounds reasonable, can you submit a patch so this doesn't get lost?
JordanWeber
Gnoblar
Posts: 7
Joined: Fri Feb 01, 2013 1:18 pm
x 1

Re: MESH class broken for descending value lod strategies

Post by JordanWeber »

I can confirm this bug still exists.

The issue is with the mesh serializer and LOD list:
sample meshLodUsageList / values
  • 0 -> 0
    1 -> 50
    2 -> 25
So when getIndexDescending is performed, on first loop:

Code: Select all

if (i->value < value)

if ( 0 < currentLodBias ) //always true
I've never submitted a patch, and don't know what to fix in the serializer, but I can look into submitting this into the bug tracker for now.

Edit: I found that the first LOD (0) when getting auto generated is actually FLT_MAX and not 0, so a sort on the list won't work.
OgreMeshSerializerImpl.cpp / OgreXMLMeshSerializer.cpp / OgreMesh.cpp will need to be looked at.

Code: Select all

MeshSerializerImpl::writeLodInfo(const Mesh* pMesh)
// Loop from LOD 1 (not 0, this is full detail)
        for (unsigned short [b]i = 1[/b]; i < numLods; ++i)

void MeshSerializerImpl::readMeshLodInfo(DataStreamPtr& stream, Mesh* pMesh)
		// Loop from 1 rather than 0 (full detail index is not in file)
		for (i = 1; i < pMesh->mNumLods; ++i)

	void XMLMeshSerializer::readLodInfo(TiXmlElement*  lodNode)
...
// Parse the detail, start from 1 (the first sub-level of detail)
		unsigned short[b] i = 1[/b];

void Mesh::_setLodUsage(unsigned short level, MeshLodUsage& usage)
assert(level != 0 && "Can't modify first lod level (full detail)");

I believe both loops should start at i = 0, the assert should be removed (not sure what the assert is there to prevent though). Not sure what else needs to be patched, but I probably missed something :S.

I dont believe void Mesh::_setSubMeshLodFaceList needs to be modified since that only pertains to submesh info.