Collision: what's your advice?
Blitz3D Forums/Blitz3D Programming/Collision: what's your advice?
| ||
| Okay, so I'm currently using MeshesIntersect just as a stand by in my game. I wa basically going to leave it in until it became a problem because of it's slowness, and then look at the other collision options in Blitz3d. I didn't realise just how slow that command was. It seems to really hit frame rate if used just once or twice per frame, and now that I'm starting to make things "solid" I'm interested in installing the "proper" collision routines. On closer examination, however, I realise my options are a bit more limited than I thought. Here's what I've got so far: MeshesIntersect: far too slow. My code probably needs tightening up, but it's, as stated in the help docs, not a fast routine. Ellipsoid to <whatever>: I was all set to use this until I found that I could only set the ellipsoid intwo dimensions. I thought maybe I'd be able to state the Z axis too. Even stating the Z axis instead of the Y axis would be handy. When a lot of my ships are longer than they are tall, and wider again than they are long, I could really do with a command to make this a little more figure hugging. Guuuhh, I dunno: Been considering all kinds of vague methods. Is there any standard way for this kind of situation? Does anyone else have a secret, cunning, third way? Thanks for reading! |
| ||
| The standard way is with multiple collision entities. That is, instead of a single collision sphere/ellipse around the ship, use several pivots parented to the ship. |
| ||
| Thanks! Good thinking, I may well go with that! Why didn't I think of that one? Cool, any others? |
| ||
| I've not delved into the collision commands much. I've had to roll my own collisions a couple of times now, and it looks as though I'm gonna have to do it for both my new projects too. Sigh. However, as I understood it, the collision ellipsoid doesn't rotate with your mesh, so even if there was a z radius, it wouldn't help you with a spaceship. It's difficult give good advice without good information. I don't know anything about your project ( maybe I just don't keep an eye on these things. ) Nuclear Glory's collision DLL offers quite a few advantages over Blitz collisions. Tokamak has improved collions, but that may be more than you need. Multiple collision entities, as Joe suggests, is a good one too. BTW You do realise that MeshesIntersect() would be a lot faster if you used invisible proxy collision meshes with much lower polycounts, right? I don't know how much faster, but I know I managed to use it quite extensively in an asteroids game I wrote when first learning Blitz. |
| ||
| IN SOME CASES WHERE YOU ARE CHECKING FOR SHIP TO SHIP COLLISIONS YOU CAN SIMPLY USE an ENTITYDiSTANCE CHECK.. and then do your own reaction code if they are withing colliding distance. |
| ||
| Using EntityDistance is pretty much identical to using a collision sphere. Thus, that won't help him. BTW, what's with the all-caps? |
| ||
| entitydistance doesnt require you to set up an entitytype, and you can cut out soMe cpu time with your own custom checks. In my cuRrent project i have a train that runs on its tracks.. I have pivots set at the beginning,middle and end of each train car. I go through a loop and check the distance from each pivot to the other entities that can colllide with it. What i think helps save cpu time is that I only check one pivot per car, per game cycle. each cars checks the front, then middle then rear pivot for collisions.. so every pivot is checked within 3 cycles This might not work for everyone but i know that therre is no entity in my game that will move more in 2 frames that the radius of the collision checks. nothing up with those caps above, i was just to lazy to go back and retype it after realizing what i did. |
| ||
| who knows how fast exactly the blitz collision system is - but it's probably faster than a recursive entitydistance check. For one thing, blitz probably splits everything up into sectors etc. even if the sectors aren't the most intelligently placed. it probably also handles speed better than using entitydistance. Plus most likely it's written in optimized c or ASM. Their might be ellipsoid-elipsoid dlls available, and with a little effort I could right a not-so-great one. |
| ||
| Sybixsus: Yeah, I was wondering about using very low poly hidden meshes with MeshesIntersect, but I wasn't convinced it would provide that much of a speed boost. Then I took a look at my models and realised just how many polys are in them. Fighters now use boxes (from 250 ploys to 12: not bad, huh?) and I managed to shave quite a few off the buildings. It's running, dare I say it, silkily, for now. But then, I'm not done making the world solid, yet! Thanks for the suggestions, folks, you've all been most helpful. I expect I'll be using them all at some point. |
| ||
| I'm having the same problem, and I'm also looking towards the proxy-mesh solution, like wrapping a very simplified model just inside the actual model. I find it helps to make your collission zones a bit smaller than the actual object (whether you use ellipsiods or meshes), because it's a bit more forgiving towards the player and doesn't trigger the inevitable 'BUT I DIDN'T HIT IT!!!'-response when the collision is one pixel off. Glenny: how would you rate the difference between your original collision methods and the new one? I haven't implemented it yet myself. |
| ||
| I'm using boxes in places, because there's no way the player can see with pixel perfect precision in the circumstances of my game. With that in mind, the improvement has been, thus far, dramatic. The buildings are pretty faithful to their original shapes, and as such the checks are usually a 12 poly box against a 50-70 poly building, but it seems to be perfectly fine. As long as one of the items is very low detailed, like a box, the majority of the speed issues seem to be solved. |
| ||
| As far as collisions go, I'm currently makin the move over Tokamak....also, wouldnt Tokamak's Cylindric collision work good with spaceships? |
| ||
| Tokamak is looking very interesting, and I will definitely look into that. But for now I'm just creating an R-Type'ish 2.5D shooter, and using a complete physics engine would be a bit like using a canon to shoot a mosquito (as we say in Holland) |
| ||
| I looked at Tokamak, and it looked pretty impressive. Seemed most suited to FPS's. I didn't notice commands for cylindric collision, though. Maybe I'll take another look. |
| ||
| hmm. yeah. tokamak could handle your physics pretty well as well - depending on how realistic you want it. in real life their is alot more sliding around in space. For different ship designs you could also mix collisions ie a sphere in the back, and a cylinder in front etc. This is cool because you can also simulate blasts from rockets, lasers, etc. with the tokrb_applyimpulse2 command which applies a force at a location, at a direction. |
| ||
| Tokamak does sound pretty cool. I've got pretty basic physics in my game right now, but I'm happy with them and the way things handle. The game is actually set in an atmosphere, so there's a little momentum shift when you change direction, and it feels fairly natural. I may set some missions in space, at a later time. For the next project, I'll most likely look into Tokamak. |
   |