Physics..
Blitz3D Forums/Blitz3D Programming/Physics..
| ||
| Alright so, I'm now working with 3D and what not for the first time and I was wondering if anyone had some ideas on which Physics Wrapper to use. I'd prefer free, but not to much in this world is free...so I don't really expect that. Anyway, Peace. |
| ||
| I like JV-ODE, there is a 'trial' version which is free.... if you like it I'd give a +1 vote for buying JV-ODE, very reasonable for the functionality within. Lots of example code as well to play with! |
| ||
| Here's a free ODE wrapper I made earlier: http://www.blitzbasic.com/Community/posts.php?topic=89067 It's extremely minimalist though, although I might add one or two things in the future. If you need any more features than that I too would just recommend JV-ODE (also, VIP3R is really good with support). Other things... PhysX is probably the best as long as you have the hardware for it, althought it can also be a pain to install. Tokamak is wonderful if you don't use trimeshes, as they still have a memory leak. There's also the old free BlitzODE wrapper floating around somewhere, but it's based on an older, less stable ODE version and is inexplicably missing certain important functions... not really recommended. Alternatively, for amusing silliness, you could consider a homebuilt point-and-spring engine such as this one: (You'll commonly find these called "Verlet" engines although that actually describes the integration model, not point-and-spring.) Such a system can be a good fit for a sufficiently low-demand game, and (last time I checked) was behind the physics in Stevie's Polymaniacs, as well as the older Hitman games - on the other hand it can also look awful, so... Last edited 2010 |
| ||
| I use the Tokamak Wrapper. Even though it's not developed any further it's rocksolid and very easy to use with Blitz3D. |
| ||
| I was going to use something close to what, Yasha said and make my own, but I'm not looking for anything messy. On the other hand I was thinking about using JV-ODE..we'll have to see how things go. Thanks guys. |
| ||
| Hmm, just removing this post thats all. Last edited 2010 |
| ||
| Okay so back on the subject of "physics". This "Verlet" Engine idea...what is the "concept" of it? From looking at a tutorial by "Nate the Great" to me it looks like the "verlet" engine idea works like so: Assign Verlets like "points" on the model then "constrains" pull/move/push other verlets depending on XYZ because they are all linked together? <-probably a little hard to understand that had to summerize it all up atm. A better example..For a "Ragdoll" I'd need to create a "point" on the Hands, Forearm(lower Arm from hand to elbow), Elbow, Brachium(shoulder to elbow), thigh(hip to knee) ,Leg(knee to foot), Foot, Neck, Head. Correct? Last edited 2010 Last edited 2010 |
| ||
| There are two indirectly related concepts here (the code snippet above contains examples of both): 1) Point/Constraint. Your object is primarily represented by a group of individual points or particles. Particles are held in place by links or constraints that limit their movement with regard to other particles. An iterative process of simulating each particle's movement, then correcting based on the constraints, gives the illusion of movement for a complete rigid body as the particles move together. 2) Verlet integration. Note: many people refer to the points in the above as "verlets", because it's catchy, but try not to let this confuse you. Loup Verlet is a mathematician, and Verlet integration actually refers to the method of calculating the position of the particles. It's stable and time-reversible and most importantly, if you filter out all of the unnecessary stuff (from our point of view), very simple and very fast. It works by calculating the next position of a particle based on the difference between the current position and the previous position. The two do work well together, although they don't have to. There are however three collossal holes in "Verlet physics" for Blitz3D: 1) The system makes no provision for collision detection, and therefore no way for objects to interact with each other. This isn't a total show-stopper: see the cubes demo above for a way around it, one which has worked well for Polymaniacs. Essentially it just applies spherical collision detection to the particles, of suitable sizes so that the spheres overlap and fill all the space of the object. This looks OK for highly-dynamic games like Polymaniacs, but doesn't let you do things like stack cubes as there is no support for flat surfaces. The ideal way to deal with this is to have a third class of object, the collision body, and pin these to the constraints, but I don't know if anyone has done this (you can't really do it in standard Blitz3D as you need nonspherical collisions). 2) The system makes no provision for joints and joint constraints; a flexible joint is one where there aren't constraint pins forcing something to be rigid, in which case it can flail around wildly, or have an unrestricted linear movement if you pinned it with two constraints. This makes ragdolls very difficult to design as there's no inherent way to stop limbs flying all over the place. I did some poking about with "sliding constraints" that had some give, controlling the freedom of hinge joints, but the results still weren't very good. The reason why there is no simple solution to this problem is an extension of problem 3: 3) The points are just points. They have position but not orientation. This may sound ridiculous when you first see the demo and the solid shapes are clearly falling over one another, but it just means that the angle of connection between points has changed. In turn, this makes it more difficult to calculate the orientation of the mesh that is attached to the physics object; it's not too hard with a couple of AlignToVectors for cubes and similar rigid shapes, but ragdolls are a whole different story as there simply aren't enough points to get an accurate orientation for each bone (e.g. a forearm is, simplistically, the pin between wrist and elbow points. There's no third point to use to get its roll value). Solving this algorithmically is possible but you'd end up making an inefficient duplicate of most of ODE. It's also possible to simply throw more points at a problem, to give more reference points, but that obviously slows the simulation down. This also means most structures will need to be known by the engine, so no dynamic meshes created at runtime. Anyway, the method isn't impossible to use - it worked for Hitman, (see here: http://www.gamasutra.com/resource_guide/20030121/jacobson_01.shtml ), but most of the solutions to the above presented in that article aren't feasible for B3D, and aren't actually that efficient either. Basically... Verlet physics is good for vehicles, great for liquids... totally inappropriate for ragdolls, I would say. Really it depends what your goals are: do you want to learn about physics engine design, or just implement it for an existing project? (Incidentally, if you were put off miniODE by the lack of ragdoll examples... just ask, I'll take the excuse to add them.) |
| ||
| there is a ragdoll example using miniODE inside of my awc, take a look if you need it, follow my signature (yasha, great post) Juan |
| ||
| My "Goal" is Ragdolls and primitive meshes like Cubes, Cylinders, and etc. Nothing about, MiniODE, threw me off, but you posted "no collision detection information" and if you mean like I cannot tell if the bullet collides with the "arm" then that might be a problem. Then again it might not be if I stepped down and went a little simpler. I'm messing around currently and if I get something going I'll use that. If I don't I'll consider JV-ODE or Tokamak Physics(Donno if I spelt that right) Last edited 2010 |
| ||
| posted "no collision detection information" Ah, that. Yeah... at the time I was already covering collision detection in my own project with ColDet and didn't think anything of the fact that 1) the functionality is right there in ODE and 2) building a full second set of mesh data for a full second library is incredibly wasteful. Rather selfish of me, sorry. I keep meaning to fix this - I'll get on that and add some. I'm only thinking very basic stuff - check whether two geoms collided, get the collision normals and any other information like forces (can't remember now what's included in an ODE collision), and the ability to raypick. Anything else would be the province of a more advanced library like JV-ODE. Charrua - thanks for beating me to it with the example! |
| ||
| Not selfish at all, we all do what we have to do to get by. In all honesty its selfish of me asking you to do it when I probably should myself. Honestly, I see why ODE is used quite alot now. Last edited 2010 |
| ||
| -Another Post I posted without thinking God I can be a idiot. Last edited 2010 |
   |