REQ: OPCODE collision engine into B3D
Blitz3D Forums/Blitz3D Programming/REQ: OPCODE collision engine into B3D
| ||
| Please BR guys, give us the OPCODE collisions engine in B3D! www.codercorner.com/Opcode.htm It's feature list: - C++ interface, developed for Windows systems using VC++ 6.0 - Works on arbitrary meshes (convex or non-convex), even polygon soups - Current implementation uses AABB-trees - Introduces Primitive-BV overlap tests during recursive collision queries (whereas standard libraries only rely on Primitive-Primitive and BV-BV tests) - Introduces no-leaf trees, i.e. collision trees whose leaf nodes have been removed - Supports collision queries on quantized trees (decompressed on-the-fly) - Supports "first contact" or "all contacts" modes (à la RAPID) - Uses temporal coherence for "first contact" mode (~10 to 20 times faster, useful in rigid body simulation during bisection) - Memory footprint is 7.2 times smaller than RAPID's one, which is ideal for console games with limited ram (actually, if you use the unmodified RAPID code using double precision, it's more like 13 times smaller...) - And yet it often runs faster than RAPID (according to RDTSC, sometimes more than 5 times faster when objects are deeply overlapping) - Performance is usually close to RAPID's one in close-proximity situations - Stabbing, planes & volume queries (sphere, AABB, OBB, LSS) - Sweep-and-prune and radix-based box pruner - Now works with deformable meshes (OPCODE 1.3) - Hybrid trees (OPCODE 1.3) keep a maximum of 16 triangles per leaf and reorganize client triangle lists, to eventually need roughly 16 times less ram than OPCODE’s standard trees. In the best case, this goes down to 1.25 byte / triangle, which is 115 times smaller than RAPID’s OBB trees (using floats ! else it’s 168 times). Speed hit is often negligible, and volume queries can actually run faster than OPCODE 1.2 due to less cache misses (reorganizing clients arrays also helps in this regard). They’re also faster for deformable meshes. Free to use for commercial and non-commercial and a whole lot better than the Blitz collisions. It'd be nice to have proper collisions :) Tracer |
| ||
| I think we already have that... Below is a list of known projects or companies using OPCODE-- Tokamak http://www.tokamakphysics.com ODE http://opende.sourceforge.net/ ... http://www.codercorner.com/OpcodeUsers.htm |
| ||
| Both wrappers are non-complete and both don't do the job that way they should.. We shouldn't have to rely on half completed third party DLL wrappers. Besides, both are Physics wrappers, i want collisions, plain and simple. I don't give a crap if the ball rolls left or right off the mountain.. i just want it to collide decently with a MOVING mountain ;) I gave up on the physics wrappers after my ragdoll started twitching like it was having a MASSIVE orgasm after it's death and most of all, no two computers doing it the SAME. This was the Tokamak wrapper, which obviously is more dead than alive. The ODE wrapper was never even NEAR completion and is deader than a rusted doornail in a roman dig, considering it's author prefers to wrap 70,001 other things instead of the ODE dll :). We were promised better collisions a long time ago for B3D, if all it takes is implementing a free ready-to-go collision system, then, go for it i say. Mark doesn't even have to touch the code, Simon is quite capable of doing it i think. In other words, no, we don't have it. Dead, orgasming ragdolls, and not producing the same results on different computers is what we have (and that DLL is seemingly dead as well) and a 9.917457432% completed ODE wrapper that's been discontinued. Tracer |
| ||
| Read some c++ tutorials and help us out then. |
| ||
| Stop dissing the wrapper writers will ya! ODE is perfectly usable! Ive only played with tokamak, but its usable too, just not with cars... Jeez..... |
| ||
| Write one yourself then. Make some $$. |
| ||
| I disagree about the Tokamak wrapper, sweenie done a great job on it, any problems with it are the fault of Tokamak. I've almost finished adding breakages (got sidetracked a bit, one of my better..erm.. skills :), and the second static mesh function works without memory leaks. |
| ||
| You guys are funny. Falling cubes, spheres and cylinders is not 'usable' as a straightforward collision system. nor are those sad 'car physics' things done in them (logical, as both DLL's are not made for cars). It's impossible to get any sort of poly->poly system going with either physics system (fast enough anyway), let alone something as advanced as the OPCODE system as it is meant to be used. Breakages in Tokamak are easy, my ragdoll already flies apart.. of course, then you have lots of limbs twitching like mad and making the whole thing look like a cheap horror movie :) Of course, how much twitching there is you never know as every PC screws everything differently :) Sweenie, i would love to 'wrap' OPCODE.. however, as the Blitz system is mostly closed as Fort Knox and those hacks into it don't really help much with that sort of implementation.. the only people who can implement something like that collision system is those with the actual B3D source code.. You know yourself that not everything in Tokamak for example can be implemented because of the limited access to Blitz internal data. If you even manage to get a decent callback system going, it's going to be slow as hell. Tracer |
| ||
| I agree with the fact that Mechanics libraries are not the same as collision engines. If you want to define your OWN controls (not pushing objects by "forces" but just by moveEntity,positionEntity) you *cannot* use Tokamak or Ode! Okay, you can (animated bodies) but then you are still using the physics world (costs CPU) for nothing, just the collisions! That's just plain silly. We indeed need a "normal" collision engine, better than Blitz own library. The only alternative is Nuclear Glory's engine, but since version 3 I personally got nasty performance issues. |
| ||
| IMHO Nuclear Glory is not a decent solution at all. Version 3 is slower than v2 which was never that fast anyway. They will be introducing optimisations and mesh-mesh "soon". |
| ||
| Tracer, check out coldet in the archives. I use it for vivid. It's very fast, has linepicks, poly to poly etc etc. I recall the author(Of the wrapper, not the .dll) telling me it was a lot better than opcode. I may have just invented that in my head to make my story sound more belivable tho. If opcode is better, i'll do it in vivid. (You don't need to be the engine writer Tracer. You just pass mesh and matrix info over. It would be the same internally or in b3d) |
| ||
| @Antony - oddly enough, I think that 3DSMax exporter I recommended to you for Vivid about 12 hours ago is by the same people that made Opcode... Yep : http://www.codercorner.com/News.htm |
| ||
| Yeah, and novadex..the guy's got a finger in everypie. though the guy i'm working with on a game or at least will be soon informs me flexiporter isn't a worthwhile option these days, and suggested igame instead. so not so sure about that anymore. |
| ||
| of course, then you have lots of limbs twitching like mad and making the whole thing look like a cheap horror movie :) Well in the right setting that's not nessecarilly a bad idea witness:Exhibit a) Tribes Vengence; the twitchy ragdoll implementation in Tribes Vengence is obviously incompatible with the setting of the game and totally imappropriate. Exhibit b) DOOM3; the twitcy (and in my experience worse than Tribes Vengence) ragdoll implementation was over-interpreted as additional ambience. It's not a bug, it's a feature. Use your bugs to your advantage. Everyone else does. |
| ||
| That's rich. Our game's physics suck...let's call it a feature. Sucky physics sdk v1.0. |
| ||
| lol |
| ||
| Collision: 2d or 3d its the Devil of our lives. were doing plane intersections in Matyhs just now... Might develop my own ideas out of that (in a few years time) |
| ||
| Tracer: Tokamak is NOT a collision library. Physics libraries are not suitable in situations where you want to manualy move things, by their nature, they need forces applied to items to make them move, and make their collision work correctly. It's impossible to get any sort of poly->poly Tokamak convex meshes to static mesh/convex mesh works, but once again, it's a physics engine, not a collision library. Breakages in Tokamak are easy, my ragdoll already flies apart.. of course, then you have lots of limbs twitching like mad and making the whole thing look like a cheap horror movie :) Most ragdoll systems will break if: you don't fine tune them, increase iterations/time steps. Or, if you apply massive forces to joints. Don't expect many physics engines to work well @ <30hz (that's why Tokamak has substeps, have you even looked into that? :) Twitching can be eliminated! b.t.w, Check the 'Flat Out' demo, try the ramp jump...I've seen legs & arms on the character stretch if they get caught while the body moves fast. Tom |
| ||
| Tom Dude.. please read my posts.. If you read my posts correctly.. what i am saying is that TOKAMAK and ODE aren't collision libraries! MUSTANG is the one who claims they are! And yes, the ragdoll breaks intentionally, because i WANT em to do that.. If i shoot a grenade up a terrorist ass, i want the terrorist to break apart.. In other words, what my previous post stated that the ragdoll BREAKS, not as in bugging out, no, actual BREAKING. :) Twitching CANNOT be eliminated, that's almost a direct quote from the Tokamak developer! Apparently there's a reason Havok is so expensive, and that reason is apparently NO TWITCHING if implemented right. He also said that differing physics responses are normal on different computers. You also do not want to have stretching arms on a ragdoll.. a real arm won't stretch more than a 10th of an inch, after that muscles tear and bones get pulled apart, or the body gets pulled towards the arms. And with this response to someone who seemingly can't read ;) we still remain at the point where we heard nothing from the Blitz Team, Mustang thinking that physics are collisions and a lot of crap talk in the mean time ;) Tracer |
| ||
| I can read fine, I've misunderstood you, sorry. Stick your light hearted dig ...in a shadow. Tom |
| ||
| no worries man, it was just that, a light hearted dig. It would be nice to have a better collision system in B3D, i think we can all agree with that (except for Mustang of course). Tracer |
| ||
| I havent seen a physics lib in a commercial game not twitch to be honest. Maybe they just kill the physics after the limbs have mostly stopped animating with some kind of damping. Untill it colides with something again. Most games with ragdoll aren't all that lifelike in certain situations, (bouncy limbs if arms and legs fall funny and can't decide if they should fall off an awkward perch like a chair arm rest etc). and the orgasm things isn't at all uncommon in games like um... DX, thief, Riddick, Max payne 2. Tread on a guy or drag him and sometimes they flop aroudn like they had the old heart starting shock treatment. It's just not so bad that you can't ignore it figuring its just a game. |
| ||
| A fully implemented OPCODE would be goooood :) |
| ||
| well done :) very nice indeed. If this looks very promising and just what were all missing as far as shadows casting on animated objects :) |
| ||
| Uh, wrong thread Evak? Tracer |
   |