getSceneNodeAndCollisionPointFromRay works awfully

[AlexAzazel]

I'm making a strategy game and I need units to get selected when I click on them. So I use the following code to detect if a node got clicked

Code: Select all

 
ray = collisionManager->getRayFromScreenCoordinates(cursorPosCurrent);
scene::ISceneNode* selectedSceneNode =
collisionManager->getSceneNodeAndCollisionPointFromRay(
ray,
point, // This will be the position of the collision
triangle,
IDIsSelectable);
 

But it's horrible, sometimes it works sometimes you really have to click the fvkk out of the node to make it selected so what's causing it? How can I make it selected 100% of the time when it's supposed to?

[CuteAlien]

I really can't help without a test-case that allows to reproduce the problem. I use this function a lot myself, but I guess you do something different. Gimme a few years so I can quickly learn to hack your PC to figure out what you are doing... ;-)

[chronologicaldot]

lol. Translation: he means show us some code and screenshots so we can see what you're doing or doing wrong.
How and when are you getting your cursor position and calling this function? Are there any nodes in front of the nodes you are clicking? You might be selecting something else without realizing it. GUI elements, images, things with alpha channels. There are a number of things. Notably, the selection function you are using requires clicking the exact mesh and not simply the bounding box, so if your camera is quite some distance from the object, you selection could very easily miss.

For a strategy game, e.g. RTS, I recommend implementing your own function - something alot faster than the given collision manager version, which is a recursive-function selection process. Also, you'll want something else if you intend to have multi-select.
Your choice. *shrug*
.02

[AlexAzazel]

I really can't help without a test-case that allows to reproduce the problem. I use this function a lot myself, but I guess you do something different. Gimme a few years so I can quickly learn to hack your PC to figure out what you are doing...

LOL here's the full code:

https://github.com/insanewarlock/irrRTS-RTT

Check inceptumAction.cpp from line 332 to 343. For now it basically moves the node by 3 along X axis when it gets left clicked but very often it doesn't sense that it's clicked

[CuteAlien]

Wow, cool to see the source is in the open. It will probably take a while until I get to that, but maybe I find some time on the weekend.

[chronologicaldot]

I had a look over the code. You're polling the events every cycle, but you don't need to. Since Irrlicht only sends a single event to the receiver when it happens, you can deal with them as-they-come. It'd be much easier (and more efficient) to handle events immediately in the receiver so then you don't have to worry about update function changing some internal boolean before the intended operation's completion.

I couldn't find where you set your event receiver to the device's main event receiver ( via setEventReceiver() ), so that could be the issue except that you're getting events, so that's confusing me... unless you're code online isn't complete.

[thanhle]

I don't use Irrlicht lately, but from my experience this function should be very efficient.
There should also be unit selection code, select by window, floating somewhere here in the forum.

Make sure you disable your camera from being select.

Regards,

[AlexAzazel]

I couldn't find where you set your event receiver to the device's main event receiver ( via setEventReceiver() ), so that could be the issue except that you're getting events, so that's confusing me... unless you're code online isn't complete.

Check 29th line in main.cpp

Code: Select all

device = createDevice(video::EDT_DIRECT3D9, core::dimension2d<u32>(800, 600), 32,
        false, false, true, &receiver);

Of course the code is complete in a sense that you can compile it without errors and it does whatever I programmed it for except for selecting the node.

You're polling the events every cycle, but you don't need to. Since Irrlicht only sends a single event to the receiver when it happens, you can deal with them as-they-come. It'd be much easier (and more efficient) to handle events immediately in the receiver so then you don't have to worry about update function changing some internal boolean before the intended operation's completion.

Hmm, haven't thought of that since all the tutorials do it the way I did. Maybe it's a good idea to call specific functions from Action class in bool MyEventReceiver::OnEvent(const SEvent& event) inside if scopes. I'll try that after I figure out the selection problem.

Make sure you disable your camera from being select.

Didn't help

There should also be unit selection code, select by window, floating somewhere here in the forum.

For a strategy game, e.g. RTS, I recommend implementing your own function - something alot faster than the given collision manager version, which is a recursive-function selection process. Also, you'll want something else if you intend to have multi-select.
Your choice. *shrug*

Yes I was thinking of that I'll search for solution on this forum.

[kormoran]

Hmm, haven't thought of that since all the tutorials do it the way I did. Maybe it's a good idea to call specific functions from Action class in bool MyEventReceiver::OnEvent(const SEvent& event) inside if scopes. I'll try that after I figure out the selection problem.

My spideveloper-sense is tingling, I think implementing event-driven selection would solve your selection problem...
Seriously, this is not the way Irrlicht is supposed to work. This way, your mouseactions() method would end up calling the event receiver many, many events late.

For multiple selection, all you have to do is draw a 2D selection rectangle on screen and trace 4 rays from its vertices. With them create a sub-frustum volume, check which nodes are in it and you're set...

[AlexAzazel]

For multiple selection, all you have to do is draw a 2D selection rectangle on screen and trace 4 rays from its vertices. With them create a sub-frustum volume, check which nodes are in it and you're set...

I created 2D rectangle but I have no idea how to create sub-frustum volume and check which nodes are in it (or touching it). I think if I make that my problem will be solved.

[kormoran]

Well, that's not an Irrlicht function, you need to do the math yourself:
First of all, define a center point for each of your objects.
Every couple of rays defines a plane, with a 3x3 matrix representation.
For every object, test whether its center point belongs to one of the 4 planes.
The belong-to test returns a number: positive, negative or zero.
Zero means it belongs to the plane, positive or negative means it's on one side of the plane or the other.
Combining together the four results will tell if the obj is inside or out.

[AlexAzazel]

Well, that's not an Irrlicht function, you need to do the math yourself:
First of all, define a center point for each of your objects.
Every couple of rays defines a plane, with a 3x3 matrix representation.
For every object, test whether its center point belongs to one of the 4 planes.
The belong-to test returns a number: positive, negative or zero.
Zero means it belongs to the plane, positive or negative means it's on one side of the plane or the other.
Combining together the four results will tell if the obj is inside or out.

Hmm, I've been thinking meanwhile about another way, what if I create a custom scene node like it's done in this tutorial http://irrlicht.sourceforge.net/docu/example003.html but give it a shape of sub-frustum volume and make it invisible. Will I be able to tell if any scene nodes touch or are inside of this shape using irrlicht functions? If not, may Bullet Physics provide any help with this?

[hendu]

Yes, Bullet can do that for you, if you create a ghost box, rotate it properly, and then ask for what hits it. It's about as much code either way, or a lot more if your project doesn't already use bullet.

[AlexAzazel]

Yes, Bullet can do that for you, if you create a ghost box, rotate it properly, and then ask for what hits it. It's about as much code either way, or a lot more if your project doesn't already use bullet.

No, I'm not using it yet but I was planning to go into Bullet anyways.

[kormoran]

On the trivial side, have you set up triangle selectors for all of your objects? Without them, getSceneNodeAnd... returns NULL.
Some nodes create automatically a selector, some doesn't, so check this out