knew coldet was fast, didnt realise it was so f..
BlitzMax Forums/MiniB3D Module/knew coldet was fast, didnt realise it was so f..
| ||
| fast.... While linepick checks against every collide-able entity and the raypick I'm using in coldet only checks against 1 mesh its of such a magnitude faster its *well* worth using. I dont envy simon his task at writing a linepick function, its just the sort of stuff I loath! I'm in no way criticizing his fine work, but here's why I implemented coldet I wanted to align 30-40 entities so they aligned to the patch of a landscape they were over, my first approach used 3 linepicks per entity. Just in linepicks alone it was taking almost 60th of a second! The landscape mesh I was testing against was 3,000 or so poly's and was the only "active" collidable, even with different setting on octtree didnt improve it I added the model raypick to some previous coldet work I'd done over a year ago and it worked first time, which is always nice! I made 250 tests against the terrain mesh and used less the 15-20% cpu time! heres how to add it to your own miniB3D project grab coldet from sourceforge, (I used the cvs version) in src/sysdep.h add #define GCC add a new file called glue.cpp in the src directory in the main coldet directory make a file called coldet.bmx and finally heres a simple example that positions a sprite on a terrain mesh directly below the camera raytest.bmx While purists will shriek at the idea of using C++ source code I think this would be ideal as a support lib, and it could always be ported to max, all said and done theres plenty of C++ in brl.mod/* and pub.mod/* for them to port too... Not all of coldet is wrapped, but enough to do mesh<>mesh and ray<>mesh collisions |
| ||
| > The landscape mesh I was testing against was 3,000 or so Heightmap based (2D with voxel-line-)collision2boundingbox checks are faster than polygon2polygon (mesh) collision checks. Use Heightmap based collisions instead mesh collsion and the speed is powerfull. So do you not need coldet for high speed. Check google for more tips. |
| ||
| Against a terrain you would probably be better off firing a dummy collider down using sphere collision. Checking the greyscale map will result in staircasing as you need the triangles for the proper alignment. |
| ||
| In any case you both miss the point, you might not see the need for tri/tri and tri/ray collisions that are fast, I do... |
| ||
| had to talk someone on IM through setting this up on winblows comment out Import "src/sysdep.cpp" in coldet.bmx then comment out a few lines in the cpp files that fail to compile (its just timing stuff thats not needed) |
| ||
| What would be wrong with including a lib like that? Actually, I expect the benefit of miniB3D (or BMax for that matter) to be higher if we get working, proven libs to deal with while the developers can concentrate on other things. So thanks for sharing. |
| ||
| I'd prefer to keep everything 100% written in Max, that's one of the aims of MiniB3D. Then it's easy for anyone to modify anything, and prevents MiniB3D becoming something that just glues various libs together. The ideal thing would be for people to look at the picking code in MiniB3D and try to see for themselves if they can make it any faster. If lots of people do this then eventually the routine should be as fast as anything else. I think it's pretty fast already though to be honest, with an octree any size mesh can be picked in a few millisecs. And there are other speed-ups I still want to add. Are there any test results that compares this routine with MiniB3D's? |
| ||
| Simonh, just an idee. why not to add an octree structure on each mesh. ? use the line pick check the position of the pick destination if in a collision about the cell. Maybe the time can decrease because with an octree structure you don't need to analyse all the structure of the mesh. The technique need more precision but it wok fine. I'm using this technique to test object avoidance in Tachyon Storm Project. Where linepick is replaced by sensitive captor. In main case it work. See http://hedgehog.team.free.fr/folder_public/20070219_TsiaPublic.zip Drag and drop xml file Tutoriel12_AvoidanceCollision_visible.xml into Tsia.exe |
| ||
| minb3d's line pick is *very* slow compared with this, a few millisecs is a LONG time at 60 FPS that would be 8 picks and nothing else, I'm using 150-200 raypicks a frame *easily* with coldet... |
| ||
| I don't think coding basic functionality in C/C++/'with libs' is unpure. After all Marks does this, too. As long as it's cross platform, I still think it's a benefit. If I never touch it again, why bother coding it in BlitzMax? |
| ||
| i thinks coldet is a fast! mini use a other dll for fast collisions ! mongia |
| ||
| Anyone ever get the collision normals sorted out in coldet? |
| ||
| what doesnt work can you give a specific example (pushed for time atm so be patient!) |
| ||
| @Chris, How difficult would it be to transfer the whole of coldet over to BMax. (I dont mean Lib it over I mean write it out. And I dont mean would it take a long time, I mean would it be difficult) |
| ||
| if you mean wrap it all I think gman might have done it already but I havent used his coldet module If you mean convert c++ into Bmax, well it would probably be a nightmare, max is missing operator overloading which would make converting some of the code cumbersome and error prone and in any case its tested and working c++ code, why "fix" it? I'd say see if gman's is complete and use that, if not see which is easiest to use and wrap what functions you need, from looking at what we have done it should be straight forward. |
| ||
| any case its tested and working c++ code, why "fix" it? I was just thinking that Simonhs desire to keep MiniB3D as Bmax only isnt a bad thing. And if it was possible to convert over to Bmax then MiniB3D could only get better. |
| ||
| I honestly dont see the point its a working library why "fix" it due to max's lack of operators it would probably be slower and theres every chance of extra bugs minib3d because it uses brl mods already uses a WHOLE bunch of C libraries (and thats not including the C code the brl mods import) chris@chris-desktop:~/dev/flock2$ ldd flock_b
linux-gate.so.1 => (0xffffe000)
libX11.so.6 => /usr/lib/libX11.so.6 (0xb7e4a000)
libGL.so.1 => /usr/lib/libGL.so.1 (0xb7dc5000)
libGLU.so.1 => /usr/lib/libGLU.so.1 (0xb7d4b000)
libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0xb7d45000)
libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0xb7c8b000)
libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7c65000)
libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7c52000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7b1e000)
libXau.so.6 => /usr/lib/libXau.so.6 (0xb7b1b000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb7b15000)
libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7b11000)
libGLcore.so.1 => /usr/lib/libGLcore.so.1 (0xb734e000)
libnvidia-tls.so.1 => /usr/lib/tls/libnvidia-tls.so.1 (0xb734c000)
libXext.so.6 => /usr/lib/libXext.so.6 (0xb733f000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7260000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7254000)
/lib/ld-linux.so.2 (0xb7f22000)
|
| ||
| Got some trouble while compiling coldet It's latest coldet source from cvs |
| ||
| cant remember which version I used but I ended up hacking out all the timing code so it would compile in windows |
| ||
| Could you post the source of coldet.cpp? Or send it to my email. Thanks |
| ||
| just comment out the lines with Inconsistency() that cause the compile error and you should be good to go. |
| ||
| Very fast collisions indeed, thanks for the help! |
   |