ISceneCollisionManager::getCollisionPoint() change in 1.6

[rogerborg]

In 1.6 (i.e the current SVN trunk) ISceneCollisionManager::getCollisionPoint() now returns the scene node that was hit, via an out parameter. The use case for this is in meta triangle selectors, where you otherwise wouldn't know which actual selector (and scene node) was hit.

This is an API change, and will require you to update your apps. The change is minimal; just define a "const ISceneNode* hitNode;", pass it in, and ignore it (or better yet, use it). See example 07 and the Demo app for usage.

[FuzzYspo0N]

sounds logical, good idea

[Eigen]

Seconded. I need just that functionality and currently, I pass the received triangle to another function to compare to triangles of all my models (of course rejecting those that are too far) to find which one it hit. But I imagine my method isn't very fast.

[Nox]

Hmm why no default param like 0? So nobody is forced to change his app and the out param could (but dont have to) be used.

EDIT:
what about
getCollisionPoint(const core::line3d<f32>& ray, ITriangleSelector* selector, core::vector3df& outCollisionPoint, core::triangle3df& outTriangle, const ISceneNode** outNode = 0);

[rogerborg]

Hmm why no default param like 0? So nobody is forced to change his app and the out param could (but dont have to) be used.

EDIT:
what about
getCollisionPoint(const core::line3d<f32>& ray, ITriangleSelector* selector, core::vector3df& outCollisionPoint, core::triangle3df& outTriangle, const ISceneNode** outNode = 0);

Mmm, I went back and forth a few times. However, the Irrlicht idiom is to pass references by & rather than *, so it's a choice between breaking the idiom or breaking backwards compatibility.

The former will stay with us; the latter is a (very small) one time hit, so I went for the long term solution.

There now; we've both spent longer discussing it than it would take to update our source.

[Nox]

Hmm okay if it is an idiom....although i dont like "useless" vars in my code for just satisfying the param list , but you have to know what to do

[Eigen]

I have a problem with the new getCollisionPoint using a metaTriangleSelector. If I add a mesh and a terrain to the selector, I can select both of the nodes. If I add terrain first and then a mesh, clicking on the mesh results in selecting the terrain. If I add mesh, terrain, mesh (in that order) I can select the first mesh and the terrain but not the second mesh as it results in selecting the terrain. So somehow the terrain triangle selector must mess up the results that come after that. I don't know why though.

I add my terrain triangle selector like this

Code: Select all

    ITriangleSelector*terrainTS = smgr->createTerrainTriangleSelector(terrain, 0);
    terrain->setTriangleSelector(terrainTS);
    
    triSelector_All_Editor->addTriangleSelector(terrainTS);

and the code I use to check the clicked node is

Code: Select all

if(cManager->getCollisionPoint(targetRay, triSelector_All_Editor,
                                                          targetPoint, targetTri, hitNode))
{  
     do stuff..

I hope someone can shed some light on this issue.

Edit:
I think the cause is that in getCollisionPoint only a small amout of triangles are returned by getTriangles and when passing the index to getSceneNodeForTriangle the comparison doens't work. It expects all the triangles. So I think it's an indexing issue.

Here's an example of what I think is happening
There are two triangle selectors.
Selector 1: Lets say 10 triangles are returned from 60 possible
Selector 2: 3 of 25 are returned.

So in the end there are 13 triangles. Now when you compare triangle 12 it is considered to be in the first selector, not the second because of the index.

[Mel]

I've been wondering.. is it too hard to retrieve in the triangle structure of the collision methods, besides the points, their mapping coordinates, and or vertice colors?

The case of use of something like this would be to get, perhaps, the lighting color which could be stored within the vertices, so, if we, perhaps, had a mesh which was put over a coliding mesh, and tested the closest triangle in the ground, for simplicity's sake, we could also, set the ambient color of that model to the interpolated color, so, the lighting of the model could be consistent to the location the model is placed in.