Replacing Blitz3d collisions?
Blitz3D Forums/Blitz3D Programming/Replacing Blitz3d collisions?
| ||
| Admit it: Blitz3d's collision engine sucks. Is there any sort of DLL or engine out there that can replace Blitz3d's crappy collisions with something actually reliable? I really hope no one takes my opinion to personally - I'm dipping my feet into some real dangerous waters by posting this on its own. |
| ||
| Coldet is the fastest but I'm still learning how to use it myself. http://telias.free.fr/3d_blitz3d.html |
| ||
| Can't say I've ever found reliability to be the problem, but the performance is quite poor and it doesn't really do very much. It's perfectly fair to look for something else if it can't do what you need! Aside from ColDet (which is incredibly fast but you have to write the responses yourself), you could just try a full physics engine. Even something relatively old like ODE should still give you a performance improvement, and instead of being limited to one-way slides and stops, you get full rigid body dynamics. You've got other options too, but this is a huge "depends what you want it for" area. |
| ||
| Blitz3d's collision engine sucks. Is there any sort of DLL or engine out there that can replace Blitz3d's crappy collisions with something actually reliable? I say learn to debug and you will see that Blitz3d collision system is not crappy and is reliable, even if it has limits and some weaknesses. From my tests Blitz3d collisions works well and are fast enough. I have had only 2 problems : ->when a collider emitter is created and already intersects with a collider receiver. Then when the collider emitter moves, it goes through the collider receiver. ->when i try to retrieve the normal of a collided point and the collided point is near the side of a triangle (for example the side of a cube) the retrieved normal does not seem to be what it should be. (maybe because the mesh is not unwelded ?) I won't say that Blitz3d collision system is the best but it does what it is supposed to do. If you don't like it, you can use another one... |
| ||
| How about JV-ODE? I downloaded the demo zip and liked what I saw. Does anyone have any experience with the DLL? I just wanted to know if it would be a good replacer for Blitz3d's collision functions. |
| ||
| Admit it: Blitz3d's collision engine sucks. A wise man once said It's not about the engine, it's about the person, and how he uses it. Can you be any more specific about what you're trying to do, what Blitz cannot do or what problems you are experiencing? It's hard to make recommendations without knowing your requirements. It may even be that collisions are not your best bet (eg: for very fast moving small projectiles, a raycast might be much more useful). |
| ||
| It's not dangerous, and it's not a pain to anyone unless you're just complaining to vent. In this case, it's more like the squeaky wheel gets the grease, and the whole reason Blitz3D has so many great addons is because of people doing what you've done here. As for the collision system actually sucking, I solved a lot of my biggest problems with it by just doing a bunch of trial and error. There are quite a lot of variables to work with afterall. For my uses, I ended up settling on a spherical collider shrunk by x and z and stretched by y, so it's like a pencil, and I don't remember what for the other settings, but just keep playing around with it. Some of my best modules took tons of trial and error, but then you finally get it right and it's just awesome! I once made a previous move independent mesh rotator... yup, every vertex had a place in a txt file! Not an overnight project. But if anyone needs it, just ask and I'll post it. Speaking of, as eluded to in the previous post, for those times when your brain just short circuits, you can always post your code here for someone else to take a crack at it. One of the biggest reasons I got Blitz3D was I kept hearing over and over online that it has such a great support community, and that's been true all along. |
| ||
| Honestly, I've completely side-stepped usage of the Blitz collision system all together, using entity distance and checking if the object is within the radius. However, the given variance needs to match that of the object movement to compensate for precision, aka each distance that's moved from update to update. Arrow : Travelling at 4 Units a Tick. For Traditional Mesh to Mesh Intersection: ;Main Arrow=CreateCylinder() Movement=4.0 - Distance the object will move each update. ;Somewhere in Loop MoveEntity Arrow,0,0,Movement >---> X=EntityX(Arrow) Y=EntityY(Arrow) Z=EntityZ(Arrow) -Debug Purposes Object "collided with" O ; Not Moving / But can be. X2=EntityX(O) Y2=EntityY(O) Z2=EntityZ(O) -Debug Purposes { DeltaX=(X2-X)*.2 DeltaY=(Y2-Y)*.2 DeltaZ=(Z2-Z)*.2 ;Cap all Movement If DeltaX<0 If DeltaX<Movement Then DeltaX=-Movement else If DeltaX>Movement Then DeltaX=Movement endif If DeltaY<0 If DeltaY<Movement Then DeltaY=-Movement else If DeltaY>Movement Then DeltaY=Movement endif If DeltaZ<0 If DeltaZ<Movement Then DeltaZ=-Movement else If DeltaZ>Movement Then DeltaZ=Movement endif TranslateEntity Arrow,DeltaX,DeltaY,DeltaZ -Moves Object "arrow" to the postiion of "O" 20% of total distance determined in one Tick. -Capped to 4 units a sec. } If EntityDistance(O,Arrow)<=Movement ;EntityCollided with O - A Place to Setup a Trigger Event ;This compensates for the speed of the arrow and makes sure to "Grab it" EndIf However, the above lines are if you're using a delta system to move the object. ; -Note, this is for mainly projectiles and only objects that may be moving too fast for blitz collision systems to accurately determine if they collided without changing an entity's collision radius in realtime and cannot be used with Terrains, Nor any dynamic mesh aka Map level mesh. However, if you place a Pivot along the Predicted path of the projectile it can be used to determine if hit it's mark. For Terrains: ;Main Terrain=LoadTerrain() Pivot=CreatePivot() ;Somewhere in Loop PositionEntity Pivot,entityx(arrow),erntityy(arrow),entityz(arrow) RotateEntity Pivot,entitypitch(arrow),entityyaw(arrow),entityroll(arrow) MoveEntity Pivot,0,0,Movement If EntityY(Pivot)<TerrainY(Terrain,entityx(Pivot),0,entityz(Pivot)) MoveEntity Arrow,0,0,-Movement - Incase You'd like the object to stick into the terrain. EntityParent Arrow,Terrain ;EntityCollided - A Place to Setup a Trigger Event Endif ; Note: I'm just doing this for the concept not legit code. I hope maybe it helps someone understand ways to work around the blitz collision system. None of my projects use the system. Everything is done with math, that's efficient and stable. Arrow Predicted Path Object >---> ----------------------------------------------------------------- O/ Regardless of surface. Each one of these methods can be utilized quite easily. Avoids linepicks (very slow), avoids all realtime blitz collision detection (slow). Though it may not be perfect clear optimizations can be made. I was only putting up suggestions. The best bet when you do use Blitz's collision system is avoid a lot of objects colliding/updating their collisions at one given point, allow for things to "rest" and then when they are needed within a collision "activate" them and once they're no longer needed simply put them back to "rest". I don't believe Blitz's collision system "sucks", i just prefer to do everything in a way in which I know exactly how the object will act. |
| ||
| The problem with Blitz3d collisions system is that you can't use it only when you want (activate/desactivate ellipsoids colliders) and as you want (collidables affected to different zone or step by step (one collider at a time) collisions detection) and sometimes it seems that an ellipsoid collider can go through a collidable even if the response is stop (which is probably a bug ?) So after many tests, i find it easier and more reliable to use linepicks and pickables. |
| ||
| I'm dipping my feet into some real dangerous waters by posting this on its own. Yep, as you said it, and I think it's not because you fake to assume it that you're forgiven for the way you ask for it ^^ I'd love to see a guy coming on a boxe ring and yell "Hey, boxing sucks, where can I find real fighting lessons, like Karate ?" (BTW, the day you wish to go for a suicide on the boxe ring, just tell it to me, I'll come with a camera ^_^) Whatever ... There is so many contexts for requiring to deal with collisions that there is actually no engine that will fit any needs for anyone, but there are a lot that will fit most of them for almost every body (rigid or not) That's kind of a law of "generic", and it also applies to engines like Bullet, Ageia physX, Newton or othe ODE, tokamak etc ... ps : Blitz collision system is made for beginners. It's a very good stuff for them and it perfectly does the job. If someone need a physic engine, he goes for a physic engine, not a simple collision-detection system. So ... it doesn't suck in any way, and it's pretty robust regardless of the performance. ps 2 : Try and say what you're really looking for, instead of a way to make something that will solve (or not) what you're looking for -> implenting a physic engine is a way to get something, it's not the "something" you want get done. |
   |