bmax2D collision lib
BlitzMax Forums/BlitzMax Programming/bmax2D collision lib
| ||
| I will be releasing a commercial collision detection module for max2d soon - polygon based collision detection. One of the major benefits of this system is the automatic generation of sprite polygons for use in collision tests.. heh..anyway jst thought id mention it ;) cheers! matt/defoc8 |
| ||
| Demos? Examplecode? Screenshots? ^^ |
| ||
| How much faster than BMs multilayer collision method is it and how feature rich compared to it? (the multilayer method gives great advances above anything polygon tests can do if they don't have them) I could be as funny and ask: how fast is it compared to Torque Game builders collision method, but that would be unfair as I don't know any engine / lib with that many features and that performance ;-) |
| ||
| Does it give a resolution vector? Also, price? |
| ||
| First off its not quite ready for release, it still needs some hardcore testing - ive already got a couple of people lined up for this. I might see i can get some screenshots up in next day or so.. I have a couple of collision methods still to write, but the primary shape to shape collision code is quite solid. The shape generation is automatic - the user sets the number of points that the polygon should have - 4 is min. The results from my testing of this feature have been very good.. Speed - its fast, how much faster than the current bmax collision system i dont know - i still need to put together some proper tests - will try to get back to you on this very soon. will - i dont quite follow, what exactly is a resolution vector? Price - probably about £10 - this needs to be discussed with the publisher.. sorry i cant give you that much information at the moment, but despite most of the work having been done..its not finished. |
| ||
| The shape generation is automatic - the user sets the number of points that the polygon should have - 4 is min. The results from my testing of this feature have been very good.. Convex Hulls only I guess? |
| ||
| no..the hulls produced are irregular - they fit the shape as close as possible - so most shapes can produce very good collision hulls - concave or convex - the final shape is built from triangles..so the tests are always convex. of course this is more expensive in processing terms, but it was a design decision im sticking with. |
| ||
| So what will be included? AABB , OOBB , Convex... Are you going to use trees to handle the pair collisions or we are going to have O(n^2) collision checks? Are you planing to suport moving objects or just overlap test like the Max2D collision? |
| ||
| Ok.. Im not using trees to handle collisions, so yes its could potentially be quite slow if a lot of shapes overlap at the same time - once the intial radius test is done, the polygon test is called..having said that, it seems more than fast enough. Im not supporting moving objects - atleast not with the initial release. Im basically creating an alternative to the existing system and adding a few extra collision type methods - for rays etc... AABB may be introduced later - but wont be part of the intial release either.... In short, this is a basic alternative the existing system, not a fix it all, super duper, every feature under the sun system. It wont be expensive + it should speedup your 2D games by a sig amount..I cannot possibly hope to make everyone happy.. anyway - ill try to get something uploaded soon, thanks for your interest. |
| ||
| Right well - i will try to ensure that AABB are included as standard - as well as OABB, infact probably jst the OABB, as its basically the same..apart from OABB is relative to object orientation.. As for trees & poly buckets - im looking into this, but it probably wont be part of the initial release. Im also looking into further optimisation of the generated polygon + more accurrate tri definitions..there are some minor issues with the existing system. sweeping tests - will not exist in the intial release, im not sure i will be implementing this at any point..but i will keep it in mind..so movement will not be taken into account for now anyway. |
| ||
| Speaking of collision detection, I'm not too clear on the how the multilayer CD system (via CollideImage() ) works based on the example code. I like the idea of objects being on separate layers, etc, but how do they get assigned to individual layers in the first place? Russell |
| ||
| Um, Russell, this isn't about the standard Max2D collision detection. You should start a new thread. On another note, here's a quick test thingy I made. Nothing spectacular, but it's good for stress-testing when you've got loads of my balls. Runs all happy-like, so it's fast enough for me. I wasn't keeping count of my balls, but you can have a lot and it'll work. Now I just gotta fix the actual logic part of the code so my balls bounce correctly. Really should've paid attention when doing physics in school.  |
| ||
| Code for the example thingy: |
| ||
| using noels test above - with 100 5 point poly objects - i get 26 fps on this 800mhz duron - at 60 objects its still above 60fps on this system. - noel gets approx 60fps - - on AMD64 3000+ 100 balls = 9,900 checks per frame seems pretty decent... i changed the code to use imagescollide() & clearcollisions() - with only 15 objects, the fps dropped below 60..this - is approx 1/4 the performance. hmmm probably cuz - my processor sucks the big one.. |
| ||
| Edit: Sorry about that Defoc8, tings went overboard. :) |
| ||
| no..the hulls produced are irregular - they fit the shape as close as possible - so most shapes can produce very good collision hulls - concave or convex - the final shape is built from triangles..so the tests are always convex. of course this is more expensive in processing terms, but it was a design decision im sticking with. That sounds quite a nice feature BUT why are you building the final shape from triangles? That decision seems counter-productive to me. |
| ||
| Yeah ... splitting it up to convex subshapes would reduce the tests to a far smaller amount of tests ... |
| ||
| Why not just check the polygons you have already created? |
| ||
| The initial release release will use triangles - this happened to be the simplest way to break up the the generated shape - im refining things as i go - the module will recieve updates/improvements til i feel it has reached a level at which i doesnt need to be improved. Internally the system is built to handle convex shapes, so once i get back to shape generation code..i should be able to improve the situation. Currently i have other problems id like to sort out... At the end of the day if the module makes a difference to your game, and your game is commercial....you will probably make the money you spent on this module back after the very first sale of your game.... On the other hand - you could use an external collision library + build editors to export hulls - giving the best performance possible... My system is a trade off - a balance between speed & ease of use - the hulls produced are not as good as those produced by hand, and the collision is not as robust or powerful as some libraries offer..however the collision is very fast, and the hulls are generated for you..this saves you great deal of time + will be more than good enough for most situations.. Your comments are being taken seriously - and im looking into adding some of these features into the system...but i cannot make promises at this point. |
| ||
| Wow, I had no idea BlitzMax collisions were so slow until I tried this. This is very nippy. Good work, Def. Same sorta results as Noel. No frames dropped with 100 balls onscreen. |
| ||
| On the other hand - you could use an external collision library + build editors to export hulls - giving the best performance possible... Which is what I have already with my poly module. I was really interested in the autogeneration of the hull. Maybe we could trade, my collision code for your autogen stuff. I'm not planning on selling mine anymore so we'll be helping each other out. My Stuff has :- * Rect > Rect * Circle > Circle * Poly > Line Intersect (Reports intersection) * Poly > Poly Collision (Reports point of collision) * Point > Poly A Poly can consist of 3 to 32768 vertices. |
| ||
| Added - quadrant & sub quadtrant mapping funtions, without object storage...object/tri storage for sub quadrants/buckets - seems wasteful of processing time, perhaps it would make a difference for very high volume collision problems..but this isnt really typical. Now you can call pcsGetQuadrants(shape:shape,..transform) - this will perform fast AABB to Quadrant testing, returning - an area mask.. So for every object to be considered for collision, you run through them + grab a quadrant mask...if the mask is zero, you can ignore the object...its not in screenspace, or if object1's quadrant mask anded with object2's quadrant mask is zero..you may also ignore ignore it, they have no quadrants in common... This simple technique will potentially cull a massive number of collision tests using very simple operations.. Still plenty of stuff to add & alter...but the system is slowly improving.. :] cheers! indiepath - ill probably share the concept for shape generation once im done with it - but its not a magic all singing all dancing solution, it has some signficant flaws..but for many cases it produces adequate/good collision hulls.. |
| ||
| Just a note... I kinda prefer making my own collision shapes and this is one problem I have with pixel perfect. This is because for playability's sake you often want a shape that is "fair" rather than super-accurate. In classic shootemups and platform games, the platforms would have a little extra room for you and in shootemups, the player's collision mask would be slightly smaller so you could just squeeze through... |
| ||
| Jack - you dont have to use the original images to generate the hulls.. you could easily produce a new image containing masks + generate hulls from these to use with the sprites..of course this requires building another set of images..but this is usually much easier and less time consuming than building collision hulls for all your sprites.. I will be looking into custom shape building methods too + probably a simple editor..but this will be after ive completed the basic system.. |
| ||
| Yeah, I can definately say its only useful to me if I can define collision shapes somehow myself - id be happy for even an ugly code way to do it. |
   |