Limit on Collisions?
Blitz3D Forums/Blitz3D Beginners Area/Limit on Collisions?
| ||
| Can anyone tell me how many EntityTypes and/or entity collisions Blitz3D can keep track of at once? Is there a limit or is it just dependant upon the computer the game is running on? Two Types with a total of two entities works fine but I'm running into some weird world coordinate problems when I introduce two EntityTypes over a total of Twenty-one entities. It almost feels like integer wrapping. |
| ||
| Are you using a large world scale? I heard this can produce floating point errors, the further away from 0,0,0 the collisions happen. Can you post any code, or a demo of this problem? |
| ||
| Yes I am using a large scale but I am moving the world around the camera (and not vice-versa) by using a world pivot to keep the camera at or near 0,0,0. The collisions are very near the camera as well. This large world works perfectly (absolutely no floating-point errors) until I introduce MULTI-entity collision checks. I'll try to post code without posting the entire (large) project. |
| ||
| Seems unusual to move the camera around the world. The position of the camera shouldnt be a problem to the collision detections (even if the collision is miles away from the active camera). |
| ||
| Blitz supports 999 different collision entity types numbered from 1 to 999. Can you give a more detailed description of the problem you're having? If your entities are not ending up where you want them to end up after initially positioning or teleporting them, try using 'ResetEntity' on them after you have radically repositioned them. This will prevent intervening collision enabled geometry from interfering with the repositioning of the entity. Also, why are you using a larger world scale? As stated above, this will introduce floating point errors and may increase the chance that during collision checks your entity's centerpoint will line up with a polygon seam, allowing the entity to slip through. If you're using a large world scale to allow you to use a small near camera range to avoid z-buffering issues then this is counterproductive as this issue is ratio based rather than distance based, so in scaling up the solution you also scale up the problem. |
   |