Checked out revision 338 and compiled engine and collision example. I'm pretty sure there is something wrong with collision detection or response in Irrlicht 1.2, when running on Mac. The FPS camera gets stuck all the time.
We originally noticed this issue when working on Mac support for the BMax Irrlicht wrapper (by GMan), but it is also present when I compile with Xcode.
[MacOS X] Collision broken in 1.2
Thanks for the advice, but no, there is a huge difference between the Windows and the MacOS X versions. The camera really gets stuck all the time in v 1.2 on Mac. It gets stuck in the middle of the first room (collisions demo) for no reason at all. I'm not talking about getting stuck when sliding along walls or up a ramp. I'm talkning about the camera coming to a complete halt on a plain level floor. This has to be a bug or glitch.sgt_pinky wrote:I would say this is normal behaviour. My FPS camera constantly got stuck on stairs, etc, in Windows Irrlicht. Did you try fiddling with the slip parameter?
Perhaps I should add that I'm using a PPC Mac. It might be some byte order thing that has not been sorted out yet. I have no Intel Mac so I haven't been able to test if it is just a PPC issue. Hopefully this can be addressed soon. I'm getting really addicted to Irrlicht! I'm starting to get the hang of it and will hopefully soon be able to help out with the Mac version in a more hands-on way. For now I'm just not sufficiently familiar with the source.
-
hybrid
- Admin
- Posts: 14143
- Joined: Wed Apr 19, 2006 9:20 pm
- Location: Oldenburg(Oldb), Germany
- Contact:
Maybe you could try to print the collision test values and find out which values are complete weird. Because most of us don't have a PPC and thus this kind of bug hunting is quite hard. Moreover I cannot imagine an endian issue with these algorithms - it's usually down to mesh loading when endianess is important.
I will try to help out to the best of my ability. Any special data that would be useful?hybrid wrote:Maybe you could try to print the collision test values and find out which values are complete weird. Because most of us don't have a PPC and thus this kind of bug hunting is quite hard. Moreover I cannot imagine an endian issue with these algorithms - it's usually down to mesh loading when endianess is important.
Making sure I'm not hunting ghost bugs, I downloaded revision 384. A lot of files are missing compared to the Xcode project file I'm working with. Could someone confirm these changes.
- ITriangleRenderer2.cpp
- ITriangleRenderer2.h
- CZBuffer2.cpp
- CZBuffer2.h
- fast_atof.h
- IZBuffer2.h
Thanks, yes I noticed!hybrid wrote:There should be even more files missing or have to be deleted from the project file. But I guess that the officila 1.2 SDK has the same behavior, so you could also use that one which has fewer changes to the project files.
I did manage to fix the project and compile the latest revision in Xcode.I have made a lot of tests. The strange thing is that it works in 1.0. I'm not sure when it stoped working, but something must have changed since 1.0. You are right about endian issues. I havn't found anything in the code that might explain why it doesn't work on PPC Macs. On the other hand I have no Intel Mac so I can't say if it is a PPC-specific problem.
I can confirm that it is not just the FPS camera that acts up. I have the same problem if I attach the CollisionResponseAnimator to any node. I'm currently doing tests with a third-person camera. I can't find the problem though. Perhaps it has something to do with the TriangleSelector. The problem is present with all kinds of TriangleSelector (OctTree, Terrain etc.)
I did fiddle with the slide value, but it doesn't seem to help. If I increase it the problem gets worse, decreasing it doesn't seem to do anything. Slide value is not documented and the ellipsoidRadius example code in the 1.2 API documentation seems to be out-of-date. Could someone please explain what this parameter does.