Good Collision\Physics Engine for Blitz3D?
Blitz3D Forums/Blitz3D Programming/Good Collision\Physics Engine for Blitz3D?
| ||
| I just recently discovered that Blitz3d collisions can't handle moving on moving collisions without the help of an LIB or DLL or whatever - pretty sad that I didn't know until now, huh? Anyway, is there any recommendation for good physics/collision engines compatible with Blitz3d? |
| ||
| well if you updateworld after every entity move then it might be working. advanced physics are ode, tokamak and newton. several wrappers were released in the past, such as the one for ode by devils child if i recall correctly. see also userlibs section. |
| ||
| I just recently discovered that Blitz3d collisions can't handle moving on moving collisions From my tests, it can. But you have to use a collider sphere against a collider sphere. And set them as both emitter and receiver. This means that you can't set a moving collider as being part of a group of colliders, instead each moving collider is his own group (has its own constant) Then each moving collider must be set as an emitter against all others moving colliders. It is not easy to manage but doable. About physics engines, i recommend Bullet and JVODE. |
| ||
| Can you show me your example, RemiD? I can't replicate it from the way you're explaining it. |
| ||
| I've actually created a psuedo moving object collision system using the entitydistance command |
| ||
| ...And it proves to be glitchy and unreliable-_- |
| ||
Hi, there is a dinamic collision lib made by Harrison:; Dynamic collision lib by Simon Harrison (si@...) ; You are free to use this source code how you like, however a credit in any programs that use it would be appreciated. ; Feel free to email me any questions you might have about the code, however please don't necessarily expect a reply. ; Limitations: ; Only works with spheres as source entities ; Only works if the source entity is colliding with one dynamic entity at once here is the lib and a sample code i made long ago for testing it (no media needed) https://dl.dropboxusercontent.com/u/78894295/dco_demo.exe hope it helps Juan |
| ||
| Incredible! This was all done purely using Blitz3d code? |
| ||
| Using a physics engine will be good for your project in the long run as they're generally both faster and more robust than collision. Si's code is really cool and definitely usable for simple things though (I have the feeling it may not scale too well if you want thousands of fully dynamic objects with more than two interaction directions, but most games don't actually need that so it's fine). A very fast-and-light solution also worth checking out is ColDet. Technically it's an intersection library rather than a "true" collision library: that is, where Blitz can detect both a) that the line of an entity's movement took it through another collider, and b) adjust its position according to slide parameters if necessary, ColDet merely tests whether two colliders are currently intersecting or not. Essentially it's like MeshesIntersect, except with the advantage that its mesh intersection check is faster than B3D's sphere collision check. In practice intersection combined with some "hard" position checks (i.e. "am I outside the universe? if so, reset") is perfectly adequate for games where objects move at a limited speed, as the linear collision is only truly necessary for situations when objects are moving more than one object-length in one frame, and therefore might skip an intersection check. |
| ||
| So basically, Yasha, ColDet won't actually determine "collision" as in stopping the two moving objects, but will still internally recognize when the two moving objects have intersected? |
| ||
| Indeed, it won't stop objects from moving - in fact it can't, since it's a DLL and isn't integrated with the B3D movement engine but rather maintains its own internal collision entities. It's not really too hard to write some code around this though (if you do decide to use ColDet, I can post up a simple wrapper I wrote around the commands to make them work like B3D stop-collisions). |
| ||
| Then ColDet is exactly what I needed! I downloaded it just a couple minutes ago and I'm still looking over its functions - trying to figure out how it works and all. Do you have any advice or anything of that kind? |
| ||
| ColDet works by creating and maintaining a second logical universe with its own set of entities, which are dedicated colliders. You move these entities in accordance with the entities in your main B3D universe, then check to see what the collision consequences of the movement were, potentially updating the B3D scene as a result. The ColDet universe is completely separated from the B3D one and therefore all of the movement and collision results and so on needs to be explicitly expressed in your code. Some of the functions are exposed directly from the DLL, others are wrapped by B3D code in the BB file. It's not important which is which (unless you want to hack on it), so much as it is important to remember which are the "main" API and which are "internal" and generally to avoid in high-level code. -- ColDet_Start and ColDet_End create and destroy the separate colliders' world space. -- ColDet_Make creates a collider mesh from a B3D mesh. -- ColDet_Finalize frees a collider entity. -- ColDet_SetMatrix updates the position of a collider to match its B3D counterpart's current world position. You probably want to loop through all of your dynamic entities and call this somewhere in your main loop. -- ColDet_Collision returns true if two ColDet collider entities are currently intersecting. -- Sphere-mesh and ray-mesh collisions are also supported; the former is probably good for optimising low-detail scenes and the latter is good for ray picks. -- The collision-information functions work similarly to their B3D counterparts. Calling ColDet_Colliding_Verts or ColDet_Collision_Point sets up which data will be returned by the information functions themselves. Here is a wrapper-wrapper that makes a pathetic attempt at recreating some of the B3D commands (this code is pretty bad, several of the command loop through all entities twice or more - I wrote it for a program with a small number of highly detailed meshes where the loops didn't matter because they were short, don't use it for a large system). It's a drop-in replacement for ColDet.bb: My additions are between "New functions" and "Coldet functions". The principle is just to store an object's old position, test if moving it causes an intersection, and if so, stick it back where it was before. This is fine for systems that are a) simple and b) have movement slow enough that the small gap between surfaces that this causes isn't visible. If point b is a problem you might work out some arrangement that progressively moves objects towards the target... (this is getting into the sort of thing that makes B3D collisions slower though - "stop" and "slide" collisions are inherently slower than no-response collisions). I advise against using the Move and Turn functions as they're really loop-heavy; you could work out something much more efficient that only does a lot of the work once. Also, B3D-style capitalisation for the DLL functions: I don't know about you but I find this much easier on the eye. Anyway after getting used to the basic subset, take a look at the bundled examples again and they should make more sense, and then you can hopefully use things like ray picking with relative ease. |
| ||
| I don't know why, but I keep on getting a Memory Access Violation error whenever I follow the steps of the ColDet examples. |
| ||
| Hello. I think we can add a "looks good enough" sliding-response to that library if we can retrieve the normal of the contact between 'object' and 'obstacle' (by looking at those functions, it seems we can). You should also add the pure Blitz3D functions to that DECLS. Functions like "Collision_Point_X#()" etc. so that they're also highlighted when typed. On the sliding response. You have your 'object' moving with 'old vector', and you want to find out the sliding-response's 'new vector' to move this object with. These vectors are formed by a magnitude (a "strength", or "speed") and a direction (an orientation). - To find the magnitude of the 'new vector', you modulate the magnitude of 'old vector' with the normalized Dot product of 'old vector' and the obstacle's collided triangle's normal. Since the normalized dot product is a value with a range [-1, +1], you'd need to map it to the range [0, +1] for it to be easier to modulate with (so it becomes a value you just need to multiply with the magnitude of 'old vector' to find the magnitude for the 'new vector'). - To find the direction of the 'new vector', you do a cross-product two times in the following way: First store the resulting vector of the cross-product between 'old vector' and the obstacle's collided triangle's normal. Take this resulting vector and cross-product it again with the obstacle's collided triangle's normal. If you normalize the result from this second cross-product, you can multiply each component of it with the new magnitude you obtained in the previous step. The resulting vector is the sliding-response you need to translate your object with. |
| ||
| Wait, is it true that ColDet functions don't work with types? |
| ||
| Wait, is it true that ColDet functions don't work with types? It is untrue in the sense that this question doesn't actually mean very much. The DLL has no knowledge of B3D's types because it is written in C, which is (obviously) a different language with its own types (although B3D's types are designed to perfectly interact with C structs where possible). The code in the .bb file would be a tad more efficient if it used type objects instead of banks internally, but it's not a particularly big deal and not really worth fixing (it works right now...). The wrapper functions do not use types, instead exposing int handles for ColDet entities the same way B3D exposes int handles for B3D entities. A user-defined type would be an excellent choice to link the two into render-collider entity pairs. ColDet does not use them because it chooses not to use them. The extra commands I showed above actually do use types internally, which shows that this is simply a choice on the part of EliasT and does not impose anything on the end user. |
| ||
| TaGames... about the MAVs... you did turn debugging mode on? |
   |