AABB-related Assert failure on mesh load (eihort final)

Problems building or running the engine, queries about how to use features etc.
Post Reply
User avatar
Lt.CYX
Kobold
Posts: 25
Joined: Tue Jan 18, 2005 7:28 pm

AABB-related Assert failure on mesh load (eihort final)

Post by Lt.CYX »

I looked for this in the forums and only found the post Problems with LiSPSM Shadows, which does seem to be related, but a different problem.

when loading an entity with the code:

Code: Select all

pEntity = mSceneMgr->createEntity(sName, sFileName);
I get an assertion error in OgreAxisAlignedBox.h, line 239:

Code: Select all

"(min.x <=ma.x && min.y <=ma.y min.z <=ma.z) && "The minimum corner of the box must be less then or equal to maximum corner"
turns out the assert is failing, in this case, in the setExtents() function:

Code: Select all

		/** Sets both minimum and maximum extents at once.
		*/
		inline void setExtents( const Vector3& min, const Vector3& max )
		{
            assert( (min.x <= max.x && min.y <= max.y && min.z <= max.z) &&
                "The minimum corner of the box must be less than or equal to maximum corner" );

			mExtent = EXTENT_FINITE;
			mMinimum = min;
			mMaximum = max;
		}
I already ran the meshes through OgreMeshUpgrade, with no apparent effect. Some meshes do appear to be successfuly loaded, however, while others don't.

is this a known issue? what is going on?
thanks.
User avatar
haffax
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 4823
Joined: Fri Jun 18, 2004 1:40 pm
Location: Berlin, Germany
x 8
Contact:

Post by haffax »

Did you run OgreMeshUpgrade with the -b option? This should resolve this issue.
team-pantheon programmer
creators of Rastullahs Lockenpracht
User avatar
Lt.CYX
Kobold
Posts: 25
Joined: Tue Jan 18, 2005 7:28 pm

Post by Lt.CYX »

hmm I'll try that tomorrow, thanks
User avatar
Lt.CYX
Kobold
Posts: 25
Joined: Tue Jan 18, 2005 7:28 pm

Post by Lt.CYX »

Indeed that does really seem to have worked. But now I see no objects on screen. Everything was fine with Dagon, and I haven't been able to show a single mesh on screen since moving to Eihort.

Any ideas?
thanks!
User avatar
Lt.CYX
Kobold
Posts: 25
Joined: Tue Jan 18, 2005 7:28 pm

window->setActive( false ) being called by WindowEventUti

Post by Lt.CYX »

Okay, here is the thing:

for some reason I fail to understand, the method
WindowEventUtilities::_WndProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam)

is being called with uMsg==WM_ACTIVATE and wParam=0, which ends up calling window->setActive( false ). I believe that is why nothing is getting rendered.

is that familiar to anyone?
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 67
Contact:

Post by sinbad »

Did you export that mesh with an old version of oFusion? It generated invalid AABBs for its meshes and Dagon let it get away with it. Eihort doesn't. Update your oFusion and re-export.
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 67
Contact:

Re: window->setActive( false ) being called by WindowEven

Post by sinbad »

Lt.CYX wrote:Okay, here is the thing:

for some reason I fail to understand, the method
WindowEventUtilities::_WndProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam)

is being called with uMsg==WM_ACTIVATE and wParam=0, which ends up calling window->setActive( false ). I believe that is why nothing is getting rendered.

is that familiar to anyone?
That's probably because you're debugging so the render window is inactive. That's not going to be it.
User avatar
Lt.CYX
Kobold
Posts: 25
Joined: Tue Jan 18, 2005 7:28 pm

Post by Lt.CYX »

I did export some scenes with oFusion, we used that in the past. One of the scenes in question, however, was exported with an experimental version of our own .scene exporter, which uses the Ogre 3DS Exporter for writing the meshes. Besides, I did already fix the AABB problem with OgreMeshUpgrade.

Problem now is with the RenderTarget::setActive(), which ALWAYS seems to be called with 'false' every frame. Debugging has nothing to do with it, but maybe our own application is to blame. I guess it's an old problem, and once again Dagon let me get away with it.

thanks, Simbad and haffax.
User avatar
Lt.CYX
Kobold
Posts: 25
Joined: Tue Jan 18, 2005 7:28 pm

Post by Lt.CYX »

Forgive me, Sinbad, you were right. The problem is not related to RenderTarget::setActive(). I'll post problem and solution when I find them.
scanmaster_k
Kobold
Posts: 31
Joined: Wed Mar 28, 2007 8:38 pm
Location: Sweden
Contact:

Post by scanmaster_k »

Hi, I have the same problem, but all my bounding boxes are correct. The min is lower or equal to max.

Is there anything else that can cause this problem?



Thanks
Scanmaster_K
User avatar
haffax
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 4823
Joined: Fri Jun 18, 2004 1:40 pm
Location: Berlin, Germany
x 8
Contact:

Post by haffax »

The very same? Or in another place? What's the stack trace? You see the assert condition in the first post. It can't possibly be false for a valid bounding box.

So the code file where you hit the assert is important here. :)
team-pantheon programmer
creators of Rastullahs Lockenpracht
scanmaster_k
Kobold
Posts: 31
Joined: Wed Mar 28, 2007 8:38 pm
Location: Sweden
Contact:

Post by scanmaster_k »

This is the call stack:
  • > msvcr80d.dll!_NMSG_WRITE(int rterrnum=10) Line 198 C
    msvcr80d.dll!abort() Line 59 + 0x7 bytes C
    msvcr80d.dll!_wassert(const wchar_t * expr=0x110fc6a0, const wchar_t * filename=0x110fc7e0, unsigned int lineno=239) Line 212 C
    OgreMain_d.dll!Ogre::AxisAlignedBox::setExtents(const Ogre::Vector3 & min={...}, const Ogre::Vector3 & max={...}) Line 238 + 0x57 bytes C++
    OgreMain_d.dll!Ogre::AxisAlignedBox::transformAffine(const Ogre::Matrix4 & m={...}) Line 510 C++
    OgreMain_d.dll!Ogre::MovableObject::getWorldBoundingBox(bool derive=true) Line 275 C++
    OgreMain_d.dll!Ogre::Entity::getWorldBoundingBox(bool derive=true) Line 451 C++
    OgreMain_d.dll!Ogre::SceneNode::_updateBounds() Line 268 + 0x28 bytes C++
    OgreMain_d.dll!Ogre::SceneNode::_update(bool updateChildren=true, bool parentHasChanged=true) Line 88 + 0x12 bytes C++
    OgreMain_d.dll!Ogre::Node::_update(bool updateChildren=true, bool parentHasChanged=false) Line 199 + 0x16 bytes C++
    OgreMain_d.dll!Ogre::SceneNode::_update(bool updateChildren=true, bool parentHasChanged=false) Line 88 C++
    OgreMain_d.dll!Ogre::SceneManager::_updateSceneGraph(Ogre::Camera * cam=0x00d9a0b8) Line 1738 + 0x24 bytes C++
    OgreMain_d.dll!Ogre::SceneManager::_renderScene(Ogre::Camera * camera=0x00d9a0b8, Ogre::Viewport * vp=0x00d99cd0, bool includeOverlays=true) Line 1128 + 0x16 bytes C++
    OgreMain_d.dll!Ogre::Camera::_renderScene(Ogre::Viewport * vp=0x00d99cd0, bool includeOverlays=true) Line 397 + 0x2c bytes C++
    OgreMain_d.dll!Ogre::Viewport::update() Line 197 C++
    OgreMain_d.dll!Ogre::RenderTarget::update() Line 112 C++
    OgreMain_d.dll!Ogre::RenderWindow::update(bool swap=true) Line 76 C++
    RenderSystem_Direct3D9_d.dll!Ogre::D3D9RenderWindow::update(bool swap=true) Line 916 + 0xf bytes C++
    OgreMain_d.dll!Ogre::RenderWindow::update() Line 67 + 0x14 bytes C++
    OgreMain_d.dll!Ogre::RenderSystem::_updateAllRenderTargets() Line 106 + 0x26 bytes C++
    OgreMain_d.dll!Ogre::Root::_updateAllRenderTargets() Line 1025 + 0x1a bytes C++
    OgreMain_d.dll!Ogre::Root::renderOneFrame() Line 743 C++
    Divinity_d.exe!Core::execute() Line 163 + 0xe bytes C++
    Divinity_d.exe!main(int argc=1, char * * argv=0x003faa80) Line 12 C++
    Divinity_d.exe!__tmainCRTStartup() Line 597 + 0x19 bytes C
    Divinity_d.exe!mainCRTStartup() Line 414 C
    kernel32.dll!7c816fd7()
    [Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]
    Divinity_d.exe!CrossHair::update(float deltaTime=1.074e-038#DEN) Line 162 + 0x16 bytes C++
It breaks at row 198 in the file crtmsg.c which states:

Code: Select all

if (rterrnum != _RT_CRNL && rterrnum != _RT_BANNER && rterrnum != _RT_CRT_NOTINIT)
            {
                if (1 == _CrtDbgReport(_CRT_ERROR, NULL, 0, NULL, rterrs[tblindx].rterrtxt))
                    _CrtDbgBreak();
            }
In the console, their is where a get the min max assertion.
It has been hard to trace where it brakes in my code but this is where it seems to break.

Code: Select all

crossHairPosition = start + (rayDirection * _raycastRange);
crossHair position is a vector3 which I use in the code below.

Code: Select all

_crossHairNode->setPosition(crossHairPosition);
And this is the bounding box of the crosshair min -14-6, -0.72, -5.37 and max 0.17, 0.87, 5.37.
User avatar
haffax
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 4823
Joined: Fri Jun 18, 2004 1:40 pm
Location: Berlin, Germany
x 8
Contact:

Post by haffax »

This has to be something simple. The bounding box you listed won't hit this assert. You see the assert condition, it is pretty obvious.

I am sorry, I don't know what raises this and since this happens during rendering it is hard to track down.

I know that there is a bug in Ogre 1.4.0 that under some conditions creates an invalid bounding box with some shadow techniques. (Don't know the details)
The bug is fixed in CVS now.

But if you can rule shadows out, than this is something different.
team-pantheon programmer
creators of Rastullahs Lockenpracht
scanmaster_k
Kobold
Posts: 31
Joined: Wed Mar 28, 2007 8:38 pm
Location: Sweden
Contact:

Post by scanmaster_k »

Disableing shadows didnt seem to work.



Thanks for your help.
Scanmaster_K
User avatar
haffax
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 4823
Joined: Fri Jun 18, 2004 1:40 pm
Location: Berlin, Germany
x 8
Contact:

Post by haffax »

The obvious question: Anything interesting in your log? Does it complain about mesh files not yet updated? If so, you could try to update them and see if this helps.
team-pantheon programmer
creators of Rastullahs Lockenpracht
scanmaster_k
Kobold
Posts: 31
Joined: Wed Mar 28, 2007 8:38 pm
Location: Sweden
Contact:

Post by scanmaster_k »

The only funny stuff in the log is that some models have vertices without bone assignment.
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 67
Contact:

Post by sinbad »

It's simply that the mesh you've loaded has an invalid bounding box, most likely it was exported from an old version of oFusion that had this bug. The stack trace shows it's not the custom shadow projection issue.

Either update oFusion and re-export or use OgreMeshUpgrade -b to fix the bounding box. The crosshair stuff is all irrelevant, the problem is with the mesh it's trying to render there.
scanmaster_k
Kobold
Posts: 31
Joined: Wed Mar 28, 2007 8:38 pm
Location: Sweden
Contact:

Post by scanmaster_k »

But I have used ogreMeshUpgrade -b on all the meshes.

But mayby all should just re export them all with updated exporters.



Thanks
Scanmaster_K
User avatar
Paulov
Greenskin
Posts: 126
Joined: Tue Apr 04, 2006 5:18 pm
Location: San Sebastian / Europe
Contact:

Post by Paulov »

I´ve been using the latest 1.8 oFusion in the max9 and my meshes have keep dissapearing in the MAX viewport and in the visualization.

I uninstalled max 8 and oFusion and restarted the computer, to ensure nothing was left of the previous version, and instllled max 9 and oFusion 1.8.

We tried to run compiling everyting with ogre 1.25 and 1.4 and in both cases we have had dissapearing meshes.

The "solution" was to attach the meshes that where dissapearing to stable meshes that never dissapeared.
This was ok for the visualization day, but is not the way to work.

I think that ther might be a bug in the exporter, or something like that.

That is all i can say from my artist point of view.

bye _ _ _

Pablo.
________________________________________
pablo vidaurre sanz
www.ikernor.com
User avatar
Lt.CYX
Kobold
Posts: 25
Joined: Tue Jan 18, 2005 7:28 pm

Post by Lt.CYX »

sorry for the delay.

in my case, the solution was actually different: for some reason, before, I got an OctreeSceneManager when asking for an INTERIOR scene type. It probably had to do with the order the scene manager hashtable was looked, which seems to be reversed now. So I was actually getting a BSP scene with no bsp information, which always gave the camera an empty list of things to render.

all is solved now by changing INTERIOR to GENERIC. It wasn't an interior scene anyway.
Post Reply