kormoran wrote: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
Sure. It wouldn't have worked at all without this. My problem here was that it only sometimes fails to work and I have to click on other parts of the node or change the camera angle and then it works.
OK, glad it works now. I didn't get to look on it this weekend. Size of triangles shouldn't really be a problem. Basically in this kind of problems to debug it I'd have to start reducing it until I have a test-case with a single-line and triangle which should hit but don't.
Hmm... if it's not a problem of tiny triangles, why alexazazel had troubles with selection until he changed function?
Doesn't this means there is a bug lurking somewhere in the get... function?
kormoran wrote:Hmm... mesh triangles too small to be collided? Good to know however
I doubt that's the case, upper part of the mesh (ceiling of the tank) is really big and flat square and very often I couldn't click on it either even when camera was really close. I assume this might be a bug. At least it looks like one.
I just modified the example win32window, stopping the cam, adding a triangle selector to the cube and trying to select & rotate the cube itself by clicking on it: nothing. Can't select the cube...
I haven't read the full thread but as far as I'm concerned I encountered a similar issue a few weeks ago and it was caused by the fact that the farValue of my camera was too big which caused getRayFromScreenCoordinates() to be imprecise and resulted in a bad node selection. Just saying since it might help someone who comes by that thread with that issue.
I'm not sure but if I remember correctly there was a significant difference between the drawn ray and my cursor's position at pretty big values like 1000000+, it can easily be tested with the draw3DLine function if you want.
I just wanted to say it because one might think "i'm going to set a big farValue so I won't have to bother about it" then end up with a RayCast issue and can't understand where it comes from until he thinks about what's actually behind the function, which is what happened to me when I was doing some tests
No, it does not. The ray is calculated from mouse position and far frustum corners. The farValue is not taken into account, at least not directly. It's used to calculate the transform matrix...