Remove AABB Asserts for Min <= Max

What it says on the tin: a place to discuss proposed new features.
User avatar
dazKind
Gnoblar
Posts: 24
Joined: Thu May 04, 2006 10:43 am
Contact:

Post by dazKind » Sat Jun 14, 2008 9:21 am

Code: Select all

if (derive) 
{ 
        mWorldAABB = this->getBoundingBox(); 
        mWorldAABB.transformAffine(_getParentNodeFullTransform()); 
}
I had this one, too.

I encountered this assertion when I was implenting a custom scenemanager for a certain propiertary GUI-System.

IIRC it had to do with some screwed up scale-values that were imported and pushed into the scenenode-matrix.
0 x

MattStevens
Goblin
Posts: 239
Joined: Mon Apr 07, 2008 10:27 pm

Post by MattStevens » Thu Oct 16, 2008 7:34 pm

Hello everyone,
I had exactly the same assert than Eugen, related to shadow camera, and I found the reason. In my case, it was because the shadow camera created by Ogre had a FOV bigger than 180 degree, causing the left/right/top and bottom value to be reversed (like 313 for left, and -313 for right), thus asserting in the AABB setExtent function.

It happened because of the line 105 in OgreShadowCameraSetup.cpp

Code: Select all

// set FOV slightly larger than the spotlight range to ensure coverage
texCam->setFOVy(light->getSpotlightOuterAngle()*1.2);
In my case, my spotlight had an Outer Angle of 175 degree, so I just lowered it a bit and it fixed the assert.

- Matt Stevens
0 x

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19261
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
Contact:

Post by sinbad » Mon Oct 20, 2008 3:30 pm

MattStevens wrote: It happened because of the line 105 in OgreShadowCameraSetup.cpp

Code: Select all

// set FOV slightly larger than the spotlight range to ensure coverage
texCam->setFOVy(light->getSpotlightOuterAngle()*1.2);
In my case, my spotlight had an Outer Angle of 175 degree, so I just lowered it a bit and it fixed the assert.

- Matt Stevens
Nice catch, thanks. We can put a test in for that.
0 x

User avatar
eugen
OGRE Expert User
OGRE Expert User
Posts: 1422
Joined: Sat May 22, 2004 5:28 am
Location: Bucharest
Contact:

Post by eugen » Tue Oct 21, 2008 1:42 am

MattStevens wrote:Hello everyone,
I had exactly the same assert than Eugen, related to shadow camera, and I found the reason. In my case, it was because the shadow camera created by Ogre had a FOV bigger than 180 degree, causing the left/right/top and bottom value to be reversed (like 313 for left, and -313 for right), thus asserting in the AABB setExtent function.

It happened because of the line 105 in OgreShadowCameraSetup.cpp

Code: Select all

// set FOV slightly larger than the spotlight range to ensure coverage
texCam->setFOVy(light->getSpotlightOuterAngle()*1.2);
In my case, my spotlight had an Outer Angle of 175 degree, so I just lowered it a bit and it fixed the assert.

- Matt Stevens
Thanks!
0 x

MattStevens
Goblin
Posts: 239
Joined: Mon Apr 07, 2008 10:27 pm

Post by MattStevens » Wed Oct 22, 2008 6:58 pm

No problems eugen, better late than never ;-)

- Matt Stevens
0 x

Lax
Gnome
Posts: 312
Joined: Mon Aug 06, 2007 12:53 pm
Location: Saarland, Germany
x 4

Post by Lax » Sat Nov 22, 2008 4:12 pm

Hello,

we have the same problem. When we rotate an scenenode, the following assertion occurs:

Code: Select all

File: ../include/OgreAxisAlignedBox.h
Line: 246

Expression: (min.x <= max.x && min.z <= max.z) && "The minimum corner of the box must be less than or equal the maximum corner
This error occurs since the new OGRE 1.6 version. Can someone help?

thanks in advance
0 x

TMT
Halfling
Posts: 59
Joined: Thu Aug 23, 2007 8:09 pm

Post by TMT » Tue Dec 23, 2008 8:34 am

sinbad wrote:Nice catch, thanks. We can put a test in for that.
Saw the test added for 1.6.0, but the same situation is in FocusedShadowCameraSetup (twice!). Thought you might want to fix those as well.
0 x

User avatar
wonderswan
Halfling
Posts: 40
Joined: Fri Jul 11, 2008 8:56 pm

Re:

Post by wonderswan » Sun Mar 15, 2009 12:21 am

I'd like to bump this thread because I too have a problem with intermittent crashes under 1.6.1.
sinbad wrote:@eugen: the problem you highlighted there must be with your own code. Notice how you're breaking in the part that says 'if (mCustomProjMatrix)' - that can ONLY happen if you've called Frustum::setCustomProjectionMatrix, and at that point, Ogre isn't responsible for the contents of the projection matrix anymore, because *you've* provided it ;) Therefore mProjMatrix has garbage in it because that's what you passed to it.
I am not using any exotic stuff at all, pure OGRE calls, no strangeness anywhere. Still I get the assert (with info text truncated in the Windows dialogue), no further information, nothing in the log file. I have no idea where to bug search for this... This is one of the dread problems for me in fact, because it can apparently happen at any time and for no reason I have any hope of understanding.
0 x

hotdot
Gnoblar
Posts: 10
Joined: Thu Nov 22, 2007 9:51 pm

Re: Remove AABB Asserts for Min <= Max

Post by hotdot » Fri Apr 24, 2009 6:20 pm

Hi all,

again another instance of that, we are currently running tests, we are integrating particle systems, we may think that since the bounding is re-calculated often, it may cause the mentionned assert, but its random for us also. Will post result, we are running version 1.6.0.

Thanks for the cues.
0 x

hotdot
Gnoblar
Posts: 10
Joined: Thu Nov 22, 2007 9:51 pm

Re: Remove AABB Asserts for Min <= Max

Post by hotdot » Fri Apr 24, 2009 8:40 pm

We disabled any shadows initialization, we were using shadow maps, and tried to check about the shadow camera, the crash still occurs, did any of you had particle systems in your scenes ?
0 x

User avatar
PJani
Gremlin
Posts: 171
Joined: Wed Dec 24, 2008 7:21 pm

Re: Remove AABB Asserts for Min <= Max

Post by PJani » Sun May 10, 2009 9:44 pm

I have problems with OgreNewt which keeps getting me AABB asserts...any idea?
0 x
| Intel Dual Core 1.8Ghz, ATI Radeon Mobility X1600 256MB, 2GB RAM |
| AMD64 3000+ 1.8Ghz, 2GB RAM, GF6600 GT 128MB |
| Ogre 1.6.4 | VS C++ EE | OgreNewt + Newton 2.xx |
| Win XP || Ubuntu 9.04 | C/C++, Python, VB6, Delphi |

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19261
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
Contact:

Re: Remove AABB Asserts for Min <= Max

Post by sinbad » Sun May 17, 2009 3:40 pm

I work on a lot of Ogre projects and we never see this. I repeat my assertion that this can only happen if bounds are incorrectly constructed by either user code, or a mesh which has had a bad AABB calculation embedded in it. The assert is there to alert you to this problem, because it can cause other problems (visibility errors etc). What you need to do is examine the objects that are triggering it.

Or, just turn it off in a custom build if you don't want to take the time to find the real cause.
0 x

User avatar
AntonTheManton
Greenskin
Posts: 100
Joined: Sun Jan 14, 2007 1:47 am

Re: Remove AABB Asserts for Min <= Max

Post by AntonTheManton » Mon Sep 21, 2009 3:42 pm

I can't work it out - it does seem to be almost at random. Something to do with the angle of the camera is pointing at when seemingly random entities are rotated.
I have loads of copies of the same mesh, but only those in certain positions make Ogre blow up when they are rotated/moved - the others are fine. If I add more meshes then it's a different one or two meshes that are land-mines. I think it must be either some kind of internal overflow - a floating point error somewhere perhaps (Vector3s??) or a badly exported mesh that only causes an error in certain impossible-to-track-down conditions - although none of the tools seem to be able to fix this problem (I've tried everything). So - going with the custom Ogre build approach...fingers crossed
0 x

User avatar
AntonTheManton
Greenskin
Posts: 100
Joined: Sun Jan 14, 2007 1:47 am

Re: Remove AABB Asserts for Min <= Max

Post by AntonTheManton » Fri Sep 25, 2009 12:10 pm

I solved the problem by doing "isnan(value)" checks for everything before I used any SceneNode::setOrientation or SceneNode::setPosition function and working my way back until I found the cause of the NAN values. In my case it was an array in a library that wasn't being properly initialised to 0.0.
0 x

Ripgiblet
Gnoblar
Posts: 16
Joined: Sun Jul 19, 2009 8:55 pm

Re: Remove AABB Asserts for Min <= Max

Post by Ripgiblet » Mon Sep 28, 2009 2:14 pm

I am with Nullsquared on this one, it is ok to assert if you are using the Ogre source, but if you are using the SDK, you get no feedback about what caused the error... so you have to download the latest Ogre source compile it etc...
I think better if it error logs it as a serious problem with some information on the values of min and max...

For example today I spent a few hours tracking down this bug... and was caused by me not setting the moveto vector equal to the start vector... so if it compared them and found out that they were not equal it tried to move the SceneNode towards this Vector... this was because I changed a config file... (I have fixed the code now so config files cant break anything hopefully:]) Anyway, was hard to track down...

PS-The Ogre source code is beautifully commented by the way :D (I have realised that now that I am trying to use bullet :( )
0 x

User avatar
AntonTheManton
Greenskin
Posts: 100
Joined: Sun Jan 14, 2007 1:47 am

Re: Remove AABB Asserts for Min <= Max

Post by AntonTheManton » Mon Sep 28, 2009 2:21 pm

I agree - rather than an assert, a logged error of the type "AABB rotation given invalid params, check your scene node rotation values" would be more helpful - especially if it showed you the parameter values e.g. (0, nan, 0), as the min <= max thing is a bit cryptic
0 x

User avatar
Klaim
Old One
Posts: 2565
Joined: Sun Sep 11, 2005 1:04 am
Location: Paris, France
Contact:

Re: Remove AABB Asserts for Min <= Max

Post by Klaim » Mon Sep 28, 2009 3:31 pm

It certainly would slow the application immediately (as there would then be heavy logging) but I agree that it would be really more helpful.
0 x

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19261
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
Contact:

Re: Remove AABB Asserts for Min <= Max

Post by sinbad » Tue Sep 29, 2009 4:40 pm

The power of an assert is that it makes you look at it in development. You get the stack trace - but obviously if it's a derived update it may be divorced from the original source.

Another option is to scatter similar checks in more places to increase the chances of catching it at the source of the original mistake, which I'm open to. It probably won't catch all of them though.

I don't think logging will help you any - you'll have exactly the same problem about how to track it; if anything it's potentially harder because you'll have no context at all. And, it will have massive performance implications - logging in math operations is a major no-no.

I think you're actually asking me to hide it so that you can avoid dealing with it for a while ;) This is a pretty critical thing and deserves to be hunted down sooner rather than later because it's insidious and math errors can propagate all over the place if you leave it.
0 x

User avatar
AntonTheManton
Greenskin
Posts: 100
Joined: Sun Jan 14, 2007 1:47 am

Re: Remove AABB Asserts for Min <= Max

Post by AntonTheManton » Tue Sep 29, 2009 4:52 pm

I tried hiding the problem originally; this lead to vehicles occasionally warping off into the aether - I followed them with a chase-cam and this is when I discovered that the vehicles' positions contained NAN.

I wouldn't say that hiding it would be the best option - but if it were at all possible to complain at the scene node rotation, rather than at the AABB, then it would be much easier to track down.

The really bewildering part is the assert min/max complaint coming from AABB; as this isn't a part of the API that you'd usually have fiddled with as an Ogre user. Crashing at the current assert is useful as it alerts you to a problem, but it would be much more enlightening if there was an error message to go with it, containing some sort of hint as to where/how/why the problem might have occured earlier in the process.
0 x

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19261
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
Contact:

Re: Remove AABB Asserts for Min <= Max

Post by sinbad » Tue Sep 29, 2009 5:08 pm

Yeah, which is why I think sprinkling more asserts around for invalid quaternions and similar might be the best way to cope with it.
0 x

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19261
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
Contact:

Re: Remove AABB Asserts for Min <= Max

Post by sinbad » Tue Sep 29, 2009 8:33 pm

r9139 in trunk adds NaN checks to vectors and quaternions passed to Node, this should assert at the point of the original problem in most of the cases where this has happened in future, instead of later down the line when the AABB is updated.
0 x

User avatar
Kojack
OGRE Moderator
OGRE Moderator
Posts: 7144
Joined: Sun Jan 25, 2004 7:35 am
Location: Brisbane, Australia
x 12

Re: Remove AABB Asserts for Min <= Max

Post by Kojack » Tue Sep 29, 2009 9:31 pm

An extra tip: don't use math functions like acos or asin. Acos in particular is used a lot in angle calculations, which could then be used to rotate a node.
Instead use the Ogre versions of them, Ogre::Math::ACos and Ogre::Math::ASin. They already have built in protection which prevents NANs.
For example, this will always cause the AABB assert:

Code: Select all

Radian angle(acos(1.00001));
node->yaw(angle);
But this won't:

Code: Select all

Radian angle(Math::ACos(1.00001));
node->yaw(angle);
Due to floating point errors, it's possible that a value you think must be in the acceptable -1 to 1 range for acos (such as the dot product of 2 normalised vectors) is really a fraction bigger or smaller than you expect, which will cause a NAN if acos or asin see them.

I just did a check, and there's one place where Ogre does the acos unsafely, inside of Polygon::isPointInside(). It uses acos instead of Math::ACos on the dot product of 2 vectors. Although Ogre itself never uses isPointInside(), but if you call it then the answer could (although it's not likely) be a NAN.
0 x

Pie21
Gnoblar
Posts: 13
Joined: Wed Nov 11, 2009 8:07 am

Re: Remove AABB Asserts for Min <= Max

Post by Pie21 » Sat Nov 14, 2009 1:43 pm

I got this same assert about 2 hours ago, and I've read through these threads, but I'm on a whole different level as I only started using Ogre 3 days ago. I used Irrlicht briefly before though so I get what you guys are talking about to an extent, but no idea how to ferret out such problems in my own code.

I have a few issues that seem odd however:
I'm using the Advanced Ogre Framework, and it has been working nicely so far. All of a sudden, pretty much the whole program has started dying.
I'm not doing anything fancy with the camera, lighting, shadows, bounding boxes or anything. Still learning the ropes and getting a decent-sized scene set up.
If I add Kojack's _controlfp_s thing at the start of my main() function, the program will crash from "multiple floating point traps" or something, and the stack will be full of CEGUIBase_d.dll calls.

I understand that there's a very real possibility of ugly numbers getting spread through my code, so I don't want to say I've narrowed it down to one line... but the 'head' of the problem is the results I'm getting from Quaternion::Slerp. If I don't use Slerp (just use instant rotation instead), then I can run without the assert (of course, the _controlfp_s doover still complains).

If this post seems a bit chronologically fractured, it's because it's midnight and I wrote it over the course of half an hour while steadily improving my understanding of the problem. I now have two questions: what is going on with CEGUI that would be throwing floating point trap things, and what am I doing wrong with my Slerp?

Regarding my Slerping, I'm doing pretty much exactly what it says in the Quaternions Primer, but I (FINALLY!) discovered that my Slerped quaternion (delta) was being set to w, x, y, z = -1.#IND000. Is there some obvious reason it would do this, or am I going to need to post code and/or dig? The crazy part is that it has been working fine for a day or two now, and the stuff I changed today was nothing to do with movement/rotation... Sigh.

Apologies, I know this post didn't make sense - I'm dazed, confused, and very tired. Any help will be more coherently responded to tomorrow morning ;) Cheers!
0 x

User avatar
Kojack
OGRE Moderator
OGRE Moderator
Posts: 7144
Joined: Sun Jan 25, 2004 7:35 am
Location: Brisbane, Australia
x 12

Re: Remove AABB Asserts for Min <= Max

Post by Kojack » Sat Nov 14, 2009 2:54 pm

What's the value of the 2 quaternions and the interpolation value which result in a slerp of #IND?
0 x

Pie21
Gnoblar
Posts: 13
Joined: Wed Nov 11, 2009 8:07 am

Re: Remove AABB Asserts for Min <= Max

Post by Pie21 » Sat Nov 14, 2009 6:09 pm

... I don't know, sorry :( I knew that'd be important but I was too flustered to write them down.

That's the bad news. The good news is I can't recreate the numbers because it seems to work now! But from memory, the quats looked fairly reasonable... like <0, 0.58, 0, 0.76> and <1, 0.58, 0.76, 0.58> or something, obviously with more significant figures. I ended up just switching to doing it manually with Euler rotations, since I only need yaw anyway (flat X/Z planes), and it worked straight away with the same structure but less code. I left the quat method commented, and putting it back in now seems to work (however I get that weird 180 degree rotation flip business, so I'll stick with Euler thanks).

For the record, those floating point traps are still there... If I call the _controlfp_s thing as the first call in main(), is that expected? Is it just a few numbers that get sorted out eventually?

Thanks for... giving me somewhere to talk myself through things, if nothing else :P There's certainly a lot of good information in this thread - a big list of errors you might run into with Ogre (and associated threads like this) would make a mighty helpful Wiki article.
0 x

Post Reply