Debug spends ages building useless edge data.

Problems building or running the engine, queries about how to use features etc.
User avatar
mkultra333
Gold Sponsor
Gold Sponsor
Posts: 1894
Joined: Sun Mar 08, 2009 5:25 am
x 116

Debug spends ages building useless edge data.

Post by mkultra333 »

I'm testing my project in debug mode. At first I thought it was hanging every time it went to render, but instead it seems to be spending an excessing amount of time in edge building functions, in OgreEdgeListBuilder.ccp. It leaves behind logs of the meshes it's build edge lists for.

Why would it be building edge lists for models when I use shadow maps, not stencil shadows? And if edge list building is unavoidable for some reason, is there any way to make the debug version not take so long? It's taking a minute to build the meshes, which kills debugging.

Edit: Tried adding
m_pSceneMgr->setShadowTechnique(Ogre::ShadowTechnique::SHADOWTYPE_NONE) ;
and
MeshManager::getSingleton().setPrepareAllMeshesForShadowVolumes(false) ;
to see if that would stop this weird behaviour, but it didn't help.
"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.
User avatar
mkultra333
Gold Sponsor
Gold Sponsor
Posts: 1894
Joined: Sun Mar 08, 2009 5:25 am
x 116

Re: Debug spends ages building useless edge data.

Post by mkultra333 »

Got it to stop. Had to go through all my entities and add

Code: Select all

 pEnt->setCastShadows(false) ;
I do all my shadows totally manually, via shaders, so telling ogre there are no shadows has no effect.

I'm on Ogre 1.7.3. Seems a bit weird for it to be generating edgelists when ShadowTechnique is set to SHADOWTYPE_NONE and setPrepareAllMeshesForShadowVolumes is set to false. It's generating totally pointless edge lists, a big waste to time with large meshes.

I had a look at the trace, and here's what's going on, in order of execution

Entity::UpdateAnimation
Entity::hasEdgeList
Mesh::getEdgeList
Mesh::buildEdgeList
EdgeListBuilder::EdgeListBuilder

In UpdateAnimation, the following test gets done to see if stencil shadows are needed

Code: Select all

		if (getCastShadows() && hasEdgeList() && root._getCurrentSceneManager())
			stencilShadows =  root._getCurrentSceneManager()->isShadowTechniqueStencilBased();
The hasEdgeList(), even though just returning a bool, is forcing the construction of edge lists regardless of whether they're needed or not. I guess the problem is that it ignores the global shadow setting and just goes by the entity setting.

Edit: Even though I bypass Ogre's shadow mapping and use my own, I wonder what happens to people using the inbuilt Ogre shadow mapping. Since they have pEnt->setCastShadows(true), might that mean that they're also being forced to generate useless edge lists?
"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.
bstone
OGRE Expert User
OGRE Expert User
Posts: 1920
Joined: Sun Feb 19, 2012 9:24 pm
Location: Russia
x 201

Re: Debug spends ages building useless edge data.

Post by bstone »

The automatic edge list building seems to be controlled by a flag that is saved to the .mesh file. Versions 1.3 and older always set this flag to false as the edge lists can be stored in the files if needed. So I guess that either you somehow managed to use a pre 1.3 mesh file format or a somewhat screwed serializer implementation.
User avatar
mkultra333
Gold Sponsor
Gold Sponsor
Posts: 1894
Joined: Sun Mar 08, 2009 5:25 am
x 116

Re: Debug spends ages building useless edge data.

Post by mkultra333 »

I generate my meshes via OgreXMLConverter.exe, the exe date is from April 2010. I specifically select not to generate edge data AFAIK. A glance at the insides of one of my .mesh files has [MeshSerializer_v1.41] at the top. I do sometimes use a modified OgreXMLConverter, but the only difference that made was to modify the material name.

As far as serializers go, I don't think I've done anything with serializers. The meshes are in a zip file, and I just let Ogre handle everything as far as .mesh loading and resource management goes. I'm using a pretty vanilla windows build of Ogre 1.7.3.

Edit: I do pre-process the xml files to change some things, and the mesh.xml files don't have any xml tags for flags in them. Should they?
"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.
bstone
OGRE Expert User
OGRE Expert User
Posts: 1920
Joined: Sun Feb 19, 2012 9:24 pm
Location: Russia
x 201

Re: Debug spends ages building useless edge data.

Post by bstone »

All right then. Since you already traced the whole thing down to EdgeListBuilder then I would suggest you to repeat that effort but stop at Mesh::getEdgeList() and check the content of the Mesh::mAutoBuildEdgeLists member variable. Now I If it's true (i.e. exactly 0x00000001), then you'll have to trace the mesh loading code and see why it gets set to true. If it's some other non-zero value then you just have some rogue code somewhere that trashed it, i.e. it's a bug in the other code.
User avatar
mkultra333
Gold Sponsor
Gold Sponsor
Posts: 1894
Joined: Sun Mar 08, 2009 5:25 am
x 116

Re: Debug spends ages building useless edge data.

Post by mkultra333 »

I looked at mAutoBuildEdgeLists but it just says "true" as opposed to giving me a value. It's a bool. how do I check for any value other than true or false?
"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.
bstone
OGRE Expert User
OGRE Expert User
Posts: 1920
Joined: Sun Feb 19, 2012 9:24 pm
Location: Russia
x 201

Re: Debug spends ages building useless edge data.

Post by bstone »

Inspect the memory location, e.g. "*((int*)&mAutoBuildEdgeLists)"
User avatar
mkultra333
Gold Sponsor
Gold Sponsor
Posts: 1894
Joined: Sun Mar 08, 2009 5:25 am
x 116

Re: Debug spends ages building useless edge data.

Post by mkultra333 »

Ah, thanks. It's my first day. (Actually the second regarding the debugger.)

The value is 0x00000001, so I guess that implies it isn't being screwed up by some out of bounds array access or the like in my own code. I'll see if I can dig up some more.
"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.
bstone
OGRE Expert User
OGRE Expert User
Posts: 1920
Joined: Sun Feb 19, 2012 9:24 pm
Location: Russia
x 201

Re: Debug spends ages building useless edge data.

Post by bstone »

Yeah. You'll have to figure out why it's set to 'true'. Maybe debug through loading that particular mesh.
User avatar
mkultra333
Gold Sponsor
Gold Sponsor
Posts: 1894
Joined: Sun Mar 08, 2009 5:25 am
x 116

Re: Debug spends ages building useless edge data.

Post by mkultra333 »

I think I found a possible cause.

First thing MeshSerializerImpl::readMesh does is set pMesh->mAutoBuildEdgeLists = false. So loaded meshes never auto build edges. However, in my program, I load a mesh and then clone it multiple times. This is because of the way certain shaders interact with the meshes, giving them unique emissive effects via custom parameters that doesn't work if all the entities reference the same underlying mesh.

Cloned meshes never go through readMesh, and it seems mAutoBuildEdgeList stays true. Why it is true in the first place, I don't know. But that suggests that maybe if someone is using Ogre's inbuilt shadowmapping, and they used a mesh cloned from one they loaded, it'll generate unneeded edge lists and waste a little processor every time a new mesh is encountered.
"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.
User avatar
Wolfmanfx
OGRE Team Member
OGRE Team Member
Posts: 1525
Joined: Fri Feb 03, 2006 10:37 pm
Location: Austria - Leoben
x 100

Re: Debug spends ages building useless edge data.

Post by Wolfmanfx »

Why do you clone a Mesh? Custom parameters are on the renderable level defined (SubEntity). So when you never change the mesh data you should not clone the mesh just create a new entity with the same mesh.
User avatar
mkultra333
Gold Sponsor
Gold Sponsor
Posts: 1894
Joined: Sun Mar 08, 2009 5:25 am
x 116

Re: Debug spends ages building useless edge data.

Post by mkultra333 »

Yes, actually it's more complicated than that. It's a big program, and I often forget how bits of it work.

In fact, I clone the mesh so that I can put custom data into some of the UV coords, plus I clone materials as well. It all interacts. It's been a while since I worked on that part of the program, so I'm hazy on the details now, but I recall all this was necessary or I couldn't get the effect I wanted.

(Edit: In fact, I may later have changed things so that the custom UV coords weren't needed anymore, I went from sending data via uv coords to sending data via shader custom data mapped to bone indices. However, it's one of those things that, if not broken, I'd rather not rewrite. And I don't think clones should be defaulting to making edge lists regardless... unless there's some decent reason for that choice.)
Last edited by mkultra333 on Fri Mar 30, 2012 1:08 pm, edited 1 time in total.
"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.
bstone
OGRE Expert User
OGRE Expert User
Posts: 1920
Joined: Sun Feb 19, 2012 9:24 pm
Location: Russia
x 201

Re: Debug spends ages building useless edge data.

Post by bstone »

That looks like a bug. It would certainly make more sense for a cloned mesh to copy mAutoBuildEdgeList value from the source. Maybe post it under Papercuts.

The only workaround that doesn't require fixing Ogre's source code is to trade some hard drive space for a quick fix. You can prebuild your models with modified UV coords and save them. Then just load them as different meshes instead of cloning. The memory footprint will remain the same.
User avatar
mkultra333
Gold Sponsor
Gold Sponsor
Posts: 1894
Joined: Sun Mar 08, 2009 5:25 am
x 116

Re: Debug spends ages building useless edge data.

Post by mkultra333 »

Yeah, I think it looks a bit like a bug. For me, it's ok because I have my own custom shadow mapping, so pEnt->setCastShadows(false) fixes it up and I still get my shadows. However for people using inbuilt shadow maps it could be an issue.
"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.