getSceneNodeAndCollisionPointFromRay works awfully

[kormoran]

Of course. But the ray (the line3df) is calculated by X/Xmax Y/Ymax ratios, so it SHOULD remain the same no matter the frustum length. If setting a farValue too big hinders the ray calculation, there is something wrong...

[CuteAlien]

I can reproduce it, but didn't find the reason yet. Need more time to debug this.

But some other stuff I noticed is that you are reading/writing outside your arrays. In c++ arrays start at index 0, so if you have an array of size 2 you can only read/write into index 0 and 1. For example check your MouseDown and wheel arrays in MyEventReceiver.

Another thing that might help you in future - when you do drawings with draw2DLine (currently you have them commented out, but in case you enable them again) you should make sure you reset the material and transformations of the driver once. So you should do before them something like:

Code: Select all

 
irr::video::SMaterial lineMat;
lineMat.Lighting = false;
driver->setMaterial(lineMat);
driver->setTransform(video::ETS_WORLD, core::IdentityMatrix);
 

Another thing is about naming. You should rename "Action" to something else. Maybe "Game". The reason is that "action" is used a lot in games to for when units do something (for example move to some place or shoot something). Then people generally talk about actions. So it's confusing to other coders seeing that used in this context.

edit: One more. Don't put .cpp files into the resource files folder in your project. That's for resources files (like .rc or files needed by .rc files). It compiles, but is also just confusing other programmers.

I'll try to find some more time to debug why it doesn't collide with triangles. I'm also not so familiar with that code that I have an immediate idea, but have to work on something else now.

[AlexAzazel]

Thanks a lot CuteAlien. I knew I should have used 0 and 1. I'm just used to coding in Matlab and I forgot.

Should I rest materials per every frame or should I make it once outside the game loop?

And I'm bit confused where to put .cpp files. Is the naming of the folder "INCEPTUM" improper or should its contents be outside the folder all together?

[chronologicaldot]

And I'm bit confused where to put .cpp files. Is the naming of the folder "INCEPTUM" improper or should its contents be outside the folder all together?

Generally speaking, programs keep .h files in a folder named "include", .cpp files in a folder named "src" or "source", and images and other miscellaneous items in a folder named "rsrc" or "resource". This, of course, does vary on a per-project basis. Irrlicht, of course, is an exception. Interfaces (what the library user "sees") are in the folder "Include" and the implementation classes (.h and .cpp files) are in the folder "Source".
The point is, unless you're working on a small project, it's best to keep files in folders, separate from things like "readme". It's easiest to organize by file type, but have a look at how other people organize their files. If you like how you can find everything so easily, copy their organizational pattern.

[CuteAlien]

You have to reset once before calling driver draw functions - so inside the loop. The reason is that the 3D drivers (opengl or d3d) are always having one active state for the material and for the transformations and use that state until it's changed. So after you called drawAll for the scenemanger or the guienvironment it will be in whatever state the last thing drawn had needed. So for example the last node might have used transparent vertex alpha - then it would still be in that state. Or if the world transformation was not reset to 0,0,0 then all draw3d functions would be moved to some other positions.

Cpp files are usually in the source folder in VS (besides your main.cpp). You can create sub-folders in there if you want.

I still don't know why that collision is not happening - the line is clearly going through the model. Maybe something in the model is strange.

[AlexAzazel]

Maybe something in the model is strange.

Haha, wow. You know why? I made it and it was my first model. I only watched two 15 minute tutorials before making that. But that doesn't quite explain it until I know what exactly is wrong with the model.

[CuteAlien]

Ok, I think it's related to meshbuffer transformations which skinned meshes can have. I didn't know about those so far, but noticed those got also ignored in the display of debug normals. Have to stop for today, but it's likely an Irrlicht bug. If so ll try to fix it soon in svn-trunk (edit: or maybe even in Irrlicht 1.8, risky changing stuff there, but I can't think of a situation where the current solution is more correct, so it shouldn't break anything...).

So your model is correct - it's just using an unusual feature. As workaround for now you might want to use a static model format for testing instead of an animated one.

[mongoose7]

I think debug normals are correct for skinned meshes. The AnimatedMesh functions actually reference the transformed vertices and normals. Triangle selectors would be another matter; I've never used them.

[CuteAlien]

@mongoose7: They are correct now (I checked in the fix for the debug normals yesterday). There is an additional per mesh transformation for skinned meshes which other animated meshes do not have. It's already been handled for all other debug-output, but for the normals it was missing. I guess we simply didn't have a test-model so far which used that.
Actually I was lucky that this bug in the debug output was in there, otherwise finding out about the problem with collisions would have been harder ;-)

[kormoran]

If you have really fixed that, could you please share the patch or apply it in the trunk ASAP? I'm going to need it soon... thanks

[CuteAlien]

I only fixed the debug-output so far (that's already in trunk). I hope to fix the rest (the collision stuff) on the weekend (need to write some code for testing that better first).

[CuteAlien]

There's now a bugfix in svn trunk r5270. Unfortunately I can't backport it to Irrlicht 1.8 as the bugfix requires an interface change which wasn't in 1.8 yet (IMesh::getType - back then only IAnimatedMesh had getType which is not enough to fix this). Testcode triangleselector_animated.cpp at https://bitbucket.org/mzeilfelder/irr-p ... -micha/src

AlexAzazel, I've put your 3D model as well in my test-repository - I hope that's fine.

Workarounds if you don't want to switch to Irrlicht trunk:
- Don't use skinned meshes for the models
- Avoid per meshbuffer transformations in your animations. Per vertex transformations are fine (I don't know how transformations per meshbuffer are created, so I can't give any hints there).
- Write an own triangle-selector.

[kormoran]

Thank you CuteAlien

Workarounds: do we need to adopt all three or just implement one of them?

Next Irrlicht version release date?

[CuteAlien]

Just one workaround necessary, any of those would work. No release date (most time is spend/lost on unexpected stuff anyway).

[AlexAzazel]

AlexAzazel, I've put your 3D model as well in my test-repository - I hope that's fine.

Absolutely.