BitMask bug in CSceneCollisionManager::getPickedNodeBB()

[warui]

You are always free to ask. And we are always free to not answer

[jox]

"idBitMask: Only scene nodes with an id with bits set like in this mask will be tested. If the BitMask is 0, this feature is disabled."

The first sentence is ambiguous.

You can read it as:

"Only scene nodes with an id with all bits set like in this mask will be tested."

But the meaning is:

"Only scene nodes with an id with any of the bits set like in this mask will be tested."

So, using you example none of nodes should be picked because NT_PLAYER|NT_WEAPON = 0x000011 and there's no node that has first two bits set.

The nodes get picked. Simply because its checking any of the bits. It's that easy.

And you were proofing this yourself in the other thread (claiming that it's a bug):

There's bug in irrlicht. Actualy it's only checked if one of the bit of the mask is set in a node ID, not all of them.
If we have mask like this:
00110
all of those ids will be treated as ok:
00010
00100
00110

But that's just how it's supposed to work.

If there is both concepts supported (whatever you want to call them) then there is no problem to implement any of the discussed "systems". This is just application level then. The engine does not care.

I dont think it makes sense to discuss this any further. Everybody has stated their point(s). Now it's Nikos turn I guess.

peace!
jox

[Electron]

I don't think there is a right or wrong way. It depends on what you need your application to be able to do and whether you have more than 32 node types. Anyone reading this thread can probably get enough information to modify those functions to accept whatever they want accordign to their preference

[Electron]

I don't think there is a right or wrong way. It depends on what you need your application to be able to do and whether you have more than 32 node types. Anyone reading this thread can probably get enough information to modify those functions to accept whatever they want accordign to their preference

[jox]

Well, I thought about it. And I came to the following conclusion:

The method that Warui proposed can actually make sense! But it's just another concept. It's the third mode if you want.

Here is what it is not:

- the fix of Nikos code
- "better" than the other modes

It was not quite correct when I said it is a bug or wrong. I'm sorry about that!

But if you would go for the "exact match" or "(any) single bit match" idea, then this code will possibly lead to unexpected results (bugs)! (it happend to me!)

As Electron truly stated: "there is a right or wrong way. It depends on what you need in your application"

It's a question of documentation and understanding.




I will now try to explain the 3 concepts (modes):

I though the following names would be appropriate:

Code: Select all

enum E_BIT_MASK_MODE { 
   EBMM_BITMASK_MATCH_ANY,
   EBMM_BITMASK_MATCH_ALL,
   EBMM_EXACT_ID_MATCH
} 

EBMM_BITMASK_MATCH_ANY

The original concept (that I stood up for / I am using).

There are several node types that have one bit each.
For example DOOR, CHAIR, ...

The nodes get assigned one type each (as ID).

While node picking the bitmask will be a combination of one or more types.
If the node you choose is of any of the types it will get picked.

In spoken word the idea would be:

"Let the user pick a node that is of any of the following types: DOOR, CHAIR, ..."

The code would be (as it is V0.6):

Code: Select all

if (current->isVisible() && 
   (bits==0 || (bits != 0 && (current->getID() & bits)))) 

EBMM_BITMASK_MATCH_ALL

The concept that Warui proposed.

Talking about attributes here makes more sense to me.

There are several base attributes that have one bit each. (btw this also requires thinking in 1,2,4,8,...).
For example OPENABLE, MOVABLE, ...

The IDs of the nodes will be a combination of attribute bits.

While node picking the bitmask will be a combination of one more attributes (bits).
If you choose a node and it has all of the attributes, then it gets picked.

In spoken word the idea would be:

"Limit picking to nodes that have all (and not less) of the following attributes: X, Y, Z."
or
"Limit picking to nodes that have the attribute X"

The code (by warui):

Code: Select all

if (current->isVisible() && 
   (bits==0 || (bits != 0 && ((current->getID() & bits) == bits)))) 

EBMM_EXACT_ID_MATCH

The easy concept. No combining but ten thousands of different types possible..

Each type is made of an integer (1,2,3,4,5,...).

While node picking the bitmask will be an ID in fact.
If you choose a node and it has exactly the ID then it gets picked.

In spoken word the idea would be:

"Limit picking to nodes that are of exactly this type: X"

The corresponding code would be:

Code: Select all

if (current->isVisible() && 
   (bits==0 || (bits != 0 && ( current->getID() == bits )))    

I use EBMM_BITMASK_MATCH_ANY because I'm working on an edit system that has for example EFFECTOR and HANDLE node types that you can drag and drop. So both have to get picked but then be treated differently. All other nodes get the DEFAULT nodetype which is 0 (zero) so they ain't get picked at all (not to confuse with the bitmask default of -1!). So the attribute approach is not my way to go here. But it might of course be usefull in other applications!

Does this all make sense? I hope it's clearing things up at least. If not correct me!

I think this is all quite advanced and most irrlicht users will probably not want to bother with this stuff. But perhaps some might be happy to be able to choose between the different concepts.

Ok, my head is now smoking, gotta stick it in cold water.

jox

[Electron]

I think that's clear and concise.