Hello, I am new to this engine and I'm interested in using it. I looked at the collisions example, but unfortunately it does not work too well, at least on my end. I often get stuck on nothing and have to mash the arrow keys to "un-stuck" myself, this would be unacceptable for an FPS game. I am curious, is this a recognized fault in the example or something on my end, and how much would I have to write myself to create simple FPS movement?
Thank you.
Bad collisions in the collisions example
-
FelineFallacy
- Posts: 1
- Joined: Tue Dec 12, 2023 3:12 pm
Re: Bad collisions in the collisions example
Hm, first question: Do you use Irrlicht 1.8 or use svn trunk version? The latter has improved a few cases.
But it's still not without problems. Like this open bug: https://sourceforge.net/p/irrlicht/bugs/399
I spend some time on that once, but couldn't figure it out back then. Likely was about every horizontal polygons getting hit considered as something which should disable gravity instead of just those around the feet.
I know you could also get stick at lamps sometimes, not sure right now if that's still the case in the svn trunk version.
edit: I just tried again and it gets stuck a lot even in svn trunk :-(
Coincidentally I'm also working at another collision bug this week, but not a case used in the example.
I'm not sure I'd use the default one for an FPS game. Depends on how "professional" I want it to be maybe. It works for a quick demo and if you create extra collision geometry instead of using real models you can probably avoid most of the tricky cases.
There are better algorithms out there. No one has coded a nice GJK algorithm for Irrlicht yet for example. Also I guess what's in Irrlicht could be improved. Thought the basic idea for the CollisionResponseAnimator (using capsule collision) isn't so bad. Not sure what's going on in the test that it behaves so bad there. Sadly I never used that one in my own projects, so I've not yet spend that much time on figuring this one out.
If you do a quality shooter instead of just a quick demo you will likely use a physics engine. And use whatever collision system comes with that.
But it's still not without problems. Like this open bug: https://sourceforge.net/p/irrlicht/bugs/399
I spend some time on that once, but couldn't figure it out back then. Likely was about every horizontal polygons getting hit considered as something which should disable gravity instead of just those around the feet.
I know you could also get stick at lamps sometimes, not sure right now if that's still the case in the svn trunk version.
edit: I just tried again and it gets stuck a lot even in svn trunk :-(
Coincidentally I'm also working at another collision bug this week, but not a case used in the example.
I'm not sure I'd use the default one for an FPS game. Depends on how "professional" I want it to be maybe. It works for a quick demo and if you create extra collision geometry instead of using real models you can probably avoid most of the tricky cases.
There are better algorithms out there. No one has coded a nice GJK algorithm for Irrlicht yet for example. Also I guess what's in Irrlicht could be improved. Thought the basic idea for the CollisionResponseAnimator (using capsule collision) isn't so bad. Not sure what's going on in the test that it behaves so bad there. Sadly I never used that one in my own projects, so I've not yet spend that much time on figuring this one out.
If you do a quality shooter instead of just a quick demo you will likely use a physics engine. And use whatever collision system comes with that.
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm