[fixed]Collision Bitmask Always Selects "Default"

[kkrizka]

Hi all,

I have a scene with several selectable nodes and some background. I accomplish selecting the selectable nodes by giving them an ID of 4 (for example) and calling ISceneCollisionManager::getSceneNodeFromScreenCoordinatesBB with a bitmask of 4. However, sometimes one of the background nodes get selected when they shouldn't.

I figured out that this is because I do not explicitly assign an ID to the background nodes, so they get the default ID of -1. As a signed integer in 4-bit binary, this is 1111. Now suppose my bitmask is 4, which is signed binary is 0100. When collision manager checks the bitmask against the default ID of -1, via bitwise AND, the result is: 1111 & 0100 = 0100. The check passes and a background node is selected.

The same problem occurs for any other bitmask (well, except 0).

Having all nodes "selectable" by default seems quite inconvenient and inflexible, so this seemed like a bug to me.

PS: I'm running Irrlicht from Subversion's trunk.

[hybrid]

Well, but that's the idea of the id/bitmask combination. You'll have to live with this, i.e. set the ids manually.

[CuteAlien]

I have to agree with kkrizka - it's a confusing default (mainly because it's different from the default value of the collision functions). It would help to mention in the documentation of idBitMask in the corresponding functions of ISceneCollisionManager, that scenenodes are by default all colliding as soon as a collision idBitMask is set. It's obvious once you know it - but I remember that it also took me a while until I figured that part out (and I think for beginners it might be even more confusing).

[kkrizka]

I have to agree with kkrizka - it's a confusing default (mainly because it's different from the default value of the collision functions). It would help to mention in the documentation of idBitMask in the corresponding functions of ISceneCollisionManager, that scenenodes are by default all colliding as soon as a collision idBitMask is set. It's obvious once you know it - but I remember that it also took me a while until I figured that part out (and I think for beginners it might be even more confusing).

I agree with you, it might be useful to mention it in the documentation because it might not be obvious for everyone, especially to those that haven't worked with signed bits before.

For now, I've managed to solve the problem by having all the selectable nodes have an ancestor _topNode, and passing that to the collision manager as the root node. That actually worked quite well. Pity it's only available in SVN...

Just out of interest, what are the advantages to having all nodes selectable when a bitmask (which kinda acts as a filter) is applied?

[CuteAlien]

You can solve it easily as hybrid mentioned - by setting all ID's manually to 0.

Maybe the default of -1 for ID's was not chosen for collision masks, but ID's where originally used for identification. But I'm just guessing there :-)

[hybrid]

I still find this pretty handsome - all nodes are found by the collision methods by default. Why would we have none colliding by default?

[CuteAlien]

Well, all nodes colliding by default is certainly fine, that's not the confusing part. The point is rather that this is guaranteed by 2 defaults at different places with different values. So if you disable the default in the collision functions (which ignores ID's and therefore already collides with all nodes) it still does collide with everything. And realizing why not only the nodes where I did set the collision flag but also further nodes still did collide took me a while. And I guess beginners might also have a little trouble doing bit operations with negative numbers, so for them it might be even more confusing.

So it's just something which would be nice if it's documented at the collision functions.

[kkrizka]

You can solve it easily as hybrid mentioned - by setting all ID's manually to 0.

There is a lot of them..... Finding them all (by hand) would take a long time.

I still find this pretty handsome - all nodes are found by the collision methods by default. Why would we have none colliding by default?

I originally though of the bitmask as a filter. If a node passes a filter, then it is checked for collision. But now I understand that it works a bit differently than that.

Anyways, CuteAlien and I are not suggesting to change the default behavior because it is not "intuitive", but just to add a note in the documentation.

[CuteAlien]

You can solve it easily as hybrid mentioned - by setting all ID's manually to 0.

There is a lot of them..... ;) Finding them all (by hand) would take a long time.

He - that's where search functions with pattern matching start to get useful. I think all places to create nodes look like "add[a-zA-Z]*SceneNode" ;-)

[vitek]

... so they get the default ID of -1. As a signed integer in 4-bit binary, this is 1111.

FYI, this is only true with 2's complement arithmetic. Most computers do use 2's complement, but the correct way to guarantee you get all bits set is to write ~0.

Travis

[hybrid]

Ok, note added to all collision methods using bitmask.

[stevebondy]

I spent a couple hours yesterday fighting with this issue. I'm glad I'm not the only one who thought this was odd, and after reading through this thread, I really think this should be re-visited.

I don't mean to sound harsh here, but this is my ten cents worth.

A default ID of -1 guarantees that any bitmask will be useless, unless you explicitly assign an ID to every node. This is not intuitive, and as pointed out, the functions which accept a bitmask to filter nodes, select all nodes by default if the bitmask is 0. So, saying that the ID of -1 makes all nodes found by default is circular logic.

All nodes are found by default if you don't specify a bitmask.
All nodes are found by default if you do specify a bitmask (unless you make sure you've assigned every possible scene node a proper ID).

What are the chances for error there? Pretty much 100% in my experience. I call this a bad design decision. It leaves Irrlicht open to random, unexpected behavior that could easily be avoided.

If the default ID were 0, the entire problem goes away and everything works intuitively.


To say, "well, you'll just have to live with that" is just shrugging off the issue. You are guaranteeing that a lot of people will run into problems with this, and waste time trying to figure it out.

Steve

[vitek]

Personally, I like the concept of a scene node filter to select nodes. Instead of abusing the node id for selection, an external mechanism is created to support selecting nodes.

BTW, changing the default for either the node picking mask or the node id is bound to break existing code that is ported. It wouldn't affect users that didn't rely on the defaults, but it would break many of those that do.

Travis

[stevebondy]

Personally, I like the concept of a scene node filter to select nodes. Instead of abusing the node id for selection, an external mechanism is created to support selecting nodes.

BTW, changing the default for either the node picking mask or the node id is bound to break existing code that is ported. It wouldn't affect users that didn't rely on the defaults, but it would break many of those that do.

Travis

Hi Travis, and thanks for the reply. Yeah, after sleeping on it I see it's kind of a six-of-one/half dozen-of-the-other situation.

Your point about not abusing the node id and using an external mechanism for selecting nodes instead makes sense, and kkrizka's idea of using a single parent node for all collidable items is pretty straight-forward. I haven't upgraded to the 1.6 release yet, but I suppose now's a good time.

Thanks again,

Steve