JV-ODE Physics Thread 7
Blitz3D Forums/Blitz3D Userlibs/JV-ODE Physics Thread 7
| ||
| Now available for Blitz3D & BlitzMax (Win32) The JV-ODE Physics Wrapper is an advanced user library supporting almost all of the Open Dynamics Engine functions wrapped inside a DLL (Dynamic Link Library). The library can be used with any programming language that supports DLL's, including Blitz3D and BlitzMax (Win32). The Euler rotation system in JV-ODE has been adapted to match the left-handed Euler rotation used in Blitz3D, however functions for accessing Quaternion and Axis Angle rotation systems are also included. The full versions contain all of the necessary files to get you started, including over 30 demos showing the various features found in ODE and a complete Function Reference document. The BlitzMax (Win32) version also features a built-in 'bare-bones' OpenGL 3D engine module and B3D mesh loader module for demo purposes. To view more information and screenshots click here. Options are now available to purchase the wrapper using either PayPal or Share*it. The Blitz3D restricted demo version is now available for download here (198KB) The BlitzMax (Win32) restricted demo version is now available for download here (268KB) The ODE For Newbies tutorial from Shifty Geezer is now available for download here (79KB) Have Fun :) Previous JV-ODE Threads: 1 2 3 4 5 6 JV-ODE Player Factory Forum Useful Links: ODE.org Website - ODE Wiki - ODE User Guide (PDF) - ODE User Guide (HTML) |
| ||
| Thanks for going the extra mile and explaining it to me. :) You are still the best! a very clever sense of hummer too. I nearly didn’t get it. :) |
| ||
| Unlike Easytok, ODE can implement physics into any level right? That means I can take a .b3d level and place a ragdoll in it? Just curious. |
| ||
| Yep, you can use any mesh type with JV-ODE, including .b3d meshes. |
| ||
| Wow, then I may seriously think about buying it. Does it come with a detailed documentation? I'm afraid I might be too inexperienced to use it. |
| ||
| It comes with some real cool examples a lot more than in the Demo, which cover most things you would want to do. pdf ODE manual here! this userguide uses some C examples but I still find it very useful There is a document that come with is it cover the differences between using JV-Ode/(Blitz3d or BlitzMax) and Ode/C When you get stuck Vipers support comes in very handy :) best £10 I’ve spent in a long time :) |
| ||
| I am looking for the best way to use JV-ODE for compensating for Game lag in an Internet or LAN Game. This is the system I am thinking of using. Each computer has it’s own copy of JV-ODE running. The host Computer keeps the Master/Control Copy of All Ai players, their projectiles and any other Physic objects in the current map. It also has the Master/Control Copy or any human player that may be using the host computer (like on a LAN game) All the other human players have the Master/Control Copy of there tank and any projectiles they have fired on their computer JV-ODE simulation. This would work Perfectly fine on it’s own if the communication between each computer was instantaneous. Back in the real world this is never going to happen. :( So to compensate for this delay I was planning to recorded every positions, velocity ect ect of each object every step. When a update comes in from one of the other computers it is checked to see when the updated information was created then compared to it’s ghost objects positions, velocity ect data at that time. If they are out of sink with each other then Ghost object is moved to the correct positions for that time and then run thought and separate JV-ODE simulation to catch up with the object in the local simulation. There is obviously a processing hit and inaccuracies can creep in will this method. Any other ideas, comments or suggestions? |
| ||
| The JV-ODE demos don't work though. He leaves out the function in the restricted demos lol. |
| ||
| You can’t blame Viper for protecting his hard work can you! Even with The demos limitations you can tell JV-ODE is the best plug-in that you can get for Blitz. Well worth ten times the asking price. Well I think you know that JV-ODE is the one to go for. It's fast, versatile, stable and ease to use. |
| ||
| Great! Well one last question... How easy is it to take an animated .b3d model and make it ragdoll (insert joints and all)? Is this even possible? If this is possible, I will definitely buy it :D |
| ||
| @Battle Tanks: I haven't done much work with networking in ODE, so it wouldn't be fair for me to advise you on it tbh. However, I know it's definitely possible with great results. Both KuRiX and Cygnus have done some excellent work with networking ODE sims, they might be able to help you if you can grab their attention. Also, check out KuRiX's free RakNet networking library too. @IKG: Something like this?...  I wouldn't go so far as to say it's easy, but the demo above is included in the full version. It's more or less the same as the standard RagDoll demo with some extra code to parse the bones, so that joints can be created and parented to them. |
| ||
| But how would that work with a rigid animated model exported to .b3d? Same way? Also, if it's not particularly easy, do you still think any beginner can learn it by using the demos and documentation? Thanks again. Edit: I just found this quote from another physics thread: Just play with connecting rigid bodies with joints and you'll get it. I would say first start off with the framework layout of joints and geometries, then play with the joint inertia settings, and limits. Is that how it can be done? |
| ||
| The zombie model you see above is an animated b3d model which is also included with the full version, you can find the model here... www.psionic3d.co.uk I think as long as you use the demos as a guide and experiment with them for a while, you should be able to pick it up quite easily. The quote you've posted pretty much sums it up, although most of that is already done for you. You just need to tweak the geometry dimensions and joint limits as needed. The same applies to the animated zombie version. Have a good play around with the demo version, take your time and if you need more info then feel free to ask :) |
| ||
| Great :D I'll be purchasing it tonight (or tomorrow the latest). You seem like a very helpful person; would you be able to help me out here and there if I ever got stuck? Thanks again. |
| ||
| Thanks Viper for the RakNet tip will give that a go :) And wellcome to the JV-ODE family IKG. I know you will enjoy using it, I do! |
| ||
| Just bought it. I'm really looking foward to using it :D |
| ||
| would you be able to help me out here and there if I ever got stuck? Sure, if you need any assistance let me know :) |
| ||
| VIP3R, do you have AIM or any other kind if instant messaging service? |
| ||
| No, I don't use instant messaging. I prefer it if people ask me questions here tbh, that way other users can benefit from the information posted. |
| ||
| Ok, well I was just embarrassed to ask such small, stupid, questions. - Is there a tutorial or something on where to really start when adding the most basic object that needs physics, into your game? Or should I do the following: 1) Take a look at a simple demo like "Cylinders" and study the function: Function AddObject() xp=Rand(-10,10) zp=Rand(-10,10) ode.ODEGeom=New ODEGeom ode\body=dBodyCreate(World) dBodySetRotation(ode\body,0,0,0) dBodySetPosition(ode\body,xp,30,zp) dBodySetAutoDisableFlag(ode\body,1) ode\geom=dCreateCylinder(Space,0.5,10) dGeomSetBody(ode\geom,ode\body) ode\mesh=CreateCylinder(8) ScaleMesh ode\mesh,0.5,5,0.5 EntityColor ode\mesh,Rand(255),Rand(255),Rand(255) EntityAlpha ode\mesh,1 EntityShininess ode\mesh,0.7 End Function I see a lot of this type of code in the other demos too. Is this the basic way of setting up any kind of object? I still love everything so far though. Glad I bought it. Now all I have to do is take it easy and try to learn :D Edit: I played around with the demo some more, and answered my own question. Well, sort of. The code above can easily be explained, but the rest of the demo has me boggled. How can I figure out on my own, what it takes to get everything working? I ha te just copying and pasting someone elses work. Where do I begin? Oh and by the way, what does "RD" stand for? |
| ||
| Don't be embarrassed, everyone is a noob when they start out :) I'll break the function down for you so that you can see what's going on... First the body is created, which is affected by forces like gravity etc. You can also attach mass to the body. Next the geom is created to define the geometry of the object. A geom is used for collision detection. It's then attached to the body. Lastly the mesh is created, which is the visible part of the object. The mesh is not an ODE object but a Blitz object used for drawing purposes. An ODE object should always be created in that order. There are cases where you don't need a body, for example if you want to create a static object, like a building. In that case you can omit the body sections of code and only create the geom and mesh. You can see in the car demo that the ramp is created in this way. Because the ramp has no body, it doesn't fall to the ground or get pushed around by other objects. It does still collide, as it has geometry (geom). I'd recommend reading through the ODE User Manual, there's links to it in the top post of this thread. Even if you don't fully understand it, it will help you get a grasp of the basics. If you find parts of it are too complicated, skip over to the next part and come back to it later on. If you have any questions, no matter how trivial, please feel free to ask here. Also read the previous JV-ODE threads as they could really help too. |
| ||
| Wonderful! I suppose I'll start off small before heading to ragdolls. Do you think I'll be ready for ragdolls once I understand the entire rectangles or cylinders demo? I keep looking at the zombie demo, and there is just so much to take in. What do you recommend I read or learn that will make everything seem as easy as it is to you? The ODE manual is way too advanced for me. |
| ||
| I'd begin by getting used to creating different objects. Try to mimic the simple demos like the spheres demo and cubes demo. Once you've familiarised yourself with creating moving objects, try static ones. Then have a go at creating and attaching joints to two bodies. Take it one step at a time, don't try to run before you can walk. Make sure you read through the previous JV-ODE threads as there's some good simple info in them. |
| ||
| It would be great if you could make an actual tutorial on how to set up your own ragdoll. In fact, that would be fantastic :D |
| ||
| I've already covered that subject in a previous JV-ODE thread ;) Once you've reached the stage of jointing bodies and you've experimented with the joint limits etc, a RagDoll would be no problem at all. |
| ||
| There's a fair bit ot get your head round to understand JV-ODE, and if you don' understand you won't be able to use it. It's not like some systems where you can hack a few demo code snippets to create your wanted results. You could try this guide for newbies to get you started. http://www.davidcoombes.f2s.com/ode_for_newbies.pdf |
| ||
| That's just the kind of thing I needed, Shifty! Thanks a bunch :D |
| ||
| Holy smoke Shifty, how did I forget your tute? Is this a newer version to the one I read before? It's very well made IMO, really explains things clearly. Is it okay to link to it in the top post? Or even to distribute it? |
| ||
| I just bought this 10 minutes ago. Now I need to wait the 48 hours. :/ Time to mess around in the demo some more! |
| ||
| It's the same tute made yonks ago. I had to go looking for the Player Factory link to find it as I forgot the link myself ;) By all means link to it or distribute it. If it's useful it'd be worth including with the JV-ODE distro I think. Though if you want to do that I'll change it so it's not in .pdf and people can actually copy and paste the code examples! |
| ||
| Yeh, that would be great Shifty thanks! I'll add a link to the PDF in the top post here and include the updated version with the wrapper. Thanks again, much appreciated :) |
| ||
| Alright, I'm messing around with the demo and I'm trying to make a simple bowling game. So far I can move the ball side to side and when I hit space, the ball goes forward, but it doesn't knock over the pins. My code's below: |
| ||
| Yay, I'm downloading the full version right now. That didn't even take 24 hours with Pay Pal! More like 19. |
| ||
| Ok, you're trying to force the position of the ball manually. You can't do this in ODE after you've setup and started the simulation. ODE should be left to position the objects itself, otherwise you're abusing the simulation. Hence, no collision response and the ball doesn't roll etc. You need to 'push' the ball by applying force to the ball body. Here's a fixed version of your code... Also, you shouldn't translate the ball mass as it will move the center of gravity, causing an uneven roll. |
| ||
| Awsome, it works! Thanks a lot! |
| ||
By the way shifty, don't you mean:Include "JV-ODE.bb" not Include "ode.bb" Great tutorial though. Well, up to the part where you start adding crazy stuff in heh. That just got a little confusing. I read up to the part where you get 1 working cube. I guess from here I'll just explore the demos more. Think you would ever write a ragdoll tut, Shifty :D? Edit: Ugh, I'm having so many problems. I've been trying to do something as simple as loading my own mesh and making the camera able to push it. I set up collisions with the camera and mesh, but how can I make it so that the camera is a "force" against the mesh? There is still so much more I have to learn. I'm so way in over my head :( |
| ||
| Yeh, the include filename changed after Shiftys tute was made. Patience IKG, it'll come ;) If you need any help, ask some specific questions or post a bit of code. Update on cross-platform ODE module: I've been weighing up the pros and cons of developing a fully cross-platform ODE module for BlitzMax over the last few weeks. The conclusion... it's -very- unlikely that I'll be pursuing development of a cross-platform module for various reasons, lack of the necessary hardware being one of them. Note: The above doesn't affect JV-ODE in any way. |
| ||
| I know where you're coming from VIP3R. I have Mac owners asking for ports of my graphics plugins, but the cheapest macs are like £400 even on eBay and then you need development tools on top of that. Unless you can be sure of getting returns on the investment, it's not economically viable. Perhaps though you could start a wishlist and if a certain number of people put their names down, consider it worthwhile. That way anyone who wants a Mac version can register their interest and see from the list of names whether it's a fair thing to expect from you. |
| ||
| How can I setup collisions with my camera and the meshes/objects that are being created? I've tried a few ways, but none of them have worked so far. I've tried creating a type for the camera and I've also tried the old-fasioned way (B3D collisions). Any ideas? Also, I'm starting to learn a lot more but there's still something I don't understand in the "RagDolls" code: xp#=-8+(rd*4) yp#=7 zp#=4 It's at the beginning of the "CreateRagDoll" function, which is then seen throughout the rest of the function. |
| ||
| Yeah, I'd be willing to donate to a VIP3R Mac fund to get JV-ODE on the Mac :) You can get a min-spec Mac Mini on Ebay for around £250 or so. |
| ||
| Cheers for the support Shifty :) @IKG: The easiest thing you can do for the camera collisions is to create an ODE object for it. Create the camera object at the location where you need it (3rd person view etc), then disable the gravity effects on the camera object by using 'dBodySetGravityMode(camerabody,0)'. Now all you need to do is add an ODE joint between the camera object and the player object. Once you've done this, the camera will follow the player and collide with the scenery etc. The joint can be either fixed, or you can use hinge or ball joints. To allow the camera to move about slightly or restrict its motion, you can set the dParamLoStop and dParamHiStop parameters (the joint limits). It can be tricky, so it might be worth leaving this until you've got used to using ODE a bit more. However, if you're feeling brave then go for it and give me a yell if you need more help ;) The code you posted is the x/y/z positions of the RagDoll and 'rd' is the RagDoll ID number. When each RagDoll is created, they're all created at the same height (yp) and distance from the camera (zp). The x position (xp) is calculated as... -8 + (RagDollNumber * 4). For RagDoll(1) xp = -4 (left), for RagDoll(2) xp = 0 (center) and for RagDoll(3) xp = 4 (right). The xp/yp/zp variables are used to make it easier to change the position of the complete RagDoll, to move them you would only need to change the values in the section of code you've posted, rather than change the position of every RagDoll body, mesh and joint individually. @simonh: Hehe, the VIP3R Mac Fund, I like the sound of that. I'm not so keen on the Mac Mini on Ebay idea though, it's probably an empty Mac Mini box and manual :P |
| ||
| I couldn't find a Mac Mini for less then about £400 when I went looking a few days back. There a few up now at nearer the £300 mark but there's still ime for bids. You might be lucky and get one for less than £300. If Mac JV-ODE goes for £10 a license, it'd need 30 purchases just to cover the cost of the hardware. Perhaps if 50 people were to commit to it, it might be something to consider, at least in having the economic restrictions solved. There's still the time and support needed, perhaps learning something of a new OS to provide support, and the question how many people are going to use BlitzMAX to write Mac games? Is it that popular that enough people will buy the product? I've no idea what the Indie/MAX situation for Mac's is like, but I can't imagine most Mac owners wanting to buy Indie games. |
| ||
| I got my hands on a Mac Mini recently, however it didn't boot up, or even turn on for that matter. |
| ||
| If I have an animated model which already has bones inside it, how would I make it ragdoll when it dies? I know the demo uses shapes in a model that isn't animated. |
| ||
| well having the bones only, it wont work...you need some more information to turn a rigid into a ragdoll (join dimentions, -limits, -masses etc). so either you do this by using special-named pivots parented to the respective bone, which would be a pain in the ass to setup and parse... OR you're using a additional file to your b3d model (e.g. with the same name) and defining these informations within that file. XML would be fine. then all you have to do is to load go through all bones of your model (findchild() etc) and make a lookup into the XML-file to get the setup of that specific bone. should be pretty easy to implement... hope this gives you an idea of how you _could_ do that :) cheers |
| ||
| @IKG: You should create all of the ODE body/geoms in the RagDoll when it's in its default (start) position. Before you begin animating it etc, you should be able to disable the ODE bodies attached to it, so that the physics simulation doesn't influence them. When the RagDoll dies, you need to enable the ODE bodies attached to it so that the physics can take over. I would consider this is an advanced ODE subject, so it may seem a bit overwhelming to those new to ODE. Make a backup of the RagDoll Zombie demo and practice with that first. Remember that the RagDoll animated mesh and the ODE RagDoll geometry must co-exist, you just need to switch between 'Anim/No ODE' to 'No Anim/ODE Active'. |
| ||
| Got it working! Heavily modified the "ragdolls" demo ;) 2 more questions for now Vip3r: - When you were setting up the "ragdolls" demo (not the zombie one) how did you know where to place and position each part? Simple math/thinking? - Joints...yeah uhh where should I start? I was going to attempt to make a simple ragdoll until remembering about the joints. I know how joints work, I just don't know how to set them up. |
| ||
| First you should comment out the dWorldQuickStep() function to 'pause' the simulation. This will allow you to set it up without the body parts moving (even with no joints). Positioning each body needs some simple math using the dimensions of each body part, for example you know the x position of the arms would be half the width of the upper body + the radius of the arm. For the joints, you create the joint you want (hinge etc), then you attach the joint to the two bodies you want to join together. Next you specify which axis you want to allow rotation on and the position of the anchor. To enable rotation on an axis you would use 1 (or -1 to reverse) or use 0 to disable rotation. The anchor is the position of the joint axis, where the hinge joint swivels. It's easy to work out the position of the anchor, you can create an elongated Blitz sphere to use as a marker. Position the marker until it's in the correct location (elbow, knee etc), once done the markers position will be the correct coordinates for the anchor. Then you specify the joint limits using the dParamLoStop and dParamHiStop parameters. Remember these parameters use radians, not degrees. Look at the CreateRagDoll() function for more ideas, the top of the function defines the body parts, the base of the function defines the joints. |
| ||
| Great :D Another thing, what do you recommend I do to make the whole "geom ragdoll" 1 entity? I tried using all the ode\ fields as entities I could control, but it won't work. I want to move him around while he is frozen, if that that is even possible. I know it will work once I am using an actual loaded mesh, but for now is there any way I can do this with the guy you made out of geom peices? |
| ||
| For the 'whole one entity' you can use arrays or separate types (or extend the ODEGeom type) to keep track of each individual RagDoll, the demo shows arrays being used to track the bodies and joints... RDBody(rd) and RDJoint(rd). You would get better ideas if you posted this kind of question in the 3D Programming forum tbh as it's more of a general programming subject. Make sure you create the RagDoll in its starting position. To move it, disable and zero any forces on each body part, then reposition all of the RagDoll components. |
| ||
| Can someone please tell me why I am getting the message "failed to open C:/Program Files/BlitzMax/Mod/devcode.mod/jvode.mod/jvode.bmx" when I build and run my program. It compiles ok and I have followed instructions regarding copying the devcode.mode folder to mod and adding project The demo programs run fine from their own folder but not when I move to a different folder. Thanks oops: never mind jvode.dll not in folder |
| ||
| I'll try a different question. In the demo's I don't understand this bit LoadB3DMesh("media/terrain.b3d") Local TriMesh:Int TriMesh=CreateTriMesh(Space,1.0,0.7,1.0) I don't understand how LoadB3DMesh is linking to the CreateTriMesh command I'm a blitzmax user so I don't have access to b3d meshes or anything and I am currently writing a simple trimesh loader using data from an array. |
| ||
| I had a question about this code but I've got it working so never mind. I'll leave it up in case other biltzmax jvoders find it useful edit: I removed the code as it doesn't work see below for working code |
| ||
| Hmm, I initially kept the CreateTriMesh() function closed for the BlitzMax version to save folks getting confused about its use, as it's dependent on the JV-ODE B3D Loader Module. But, it looks like that might have been a bad idea. Here's the CreateTriMesh() function from the BlitzMax Module for reference purposes, I'll add the following source to the next BMax update... |
| ||
| Has one a sourcecode for construction of a BlitzTerrain TriMesh ? (Get data from a Blitz Terrain and create a Tri Mesh) This would be brilliant! |
| ||
| Hi Barton, If you're using a heightmap to create the BlitzTerrain then there's a way of doing it. You need to create a static mesh from the heightmap and create the TriMesh from the static mesh, then you use the BlitzTerrain for the visible geometry. There are some tools here that can do the conversion, one is F.L.E. which should be in the Toolbox section. I think there is also some source code in the code archives that can create a static mesh from a heightmap too. |
| ||
| Any chance of a tutorial for vehicle construction ie adding wheels and joints to a body, explaining each step?. I'm following code from the demo's but getting nowhere..slowly. I can sort of understand each step but putting it all together ends up with a vehicle with wheels spinning in all the wrong directions and no actual vehicle movement, except when it decides to shoot off at high speed to infinity!! Also the quadratic space function, does that work on a per triangle basis or an object basis ie if I have a large terrain mesh and add it into quadratic space does ode regard it as one object or a collection of triangles. I'll leave the falling thru the mesh problem for another day |
| ||
| I don't have the time to write tutorials tbh, I prefer to create demos to show the features of ODE. It's quite easy to set up a simple car though. Firstly you need to add and position the wheels next to the car body, this is labelled 'Create car body/wheels' in the car demo. You also add mass to the car body and wheels during their creation. Next you set up the joints to attach the wheels to the car body, this is done in the SetupCar() function. The dJointSetHinge2Anchor(Joint(count),x,y,z) positions the joint anchor. The dJointSetHinge2Axis1(Joint(count),0,1,0) function defines which axis are allowed freedom, 1 = allow freedom (-1 = reversed) and 0 = no freedom (locks axis). Then you set the suspension parameters (ERP/CFM) and set the dParamLoStop/dParamHiStop parameters to define how much rotation is allowed on the free axis in radians (not degrees). That's the set up done. Now you just need to apply forces to the joints using dParamVel/dParamVel2 and dParamFMax/dParamFMax2, see the UpdateCar() function. There's lots of info in the ODE manual covering the joint basics. There's also lots of info in the previous JV-ODE threads regarding joints so read over those too. The quadratic space works per object not per triangle. Falling through meshes can be caused by incorrect mass settings (like applying box mass to spheres etc) or the triangle size of the mesh maybe too large. There are other causes but those are usually the most common. Also, remember that flat ended cylinders don't collide with TriMeshes... only spheres, cubes and capped cylinders do. |
| ||
| ok thanks for that. I've made a little progress. It seems when I set up a vehicle at the origin it works ok but if I try and reposition the vehicle afterwards using dgeomsetposition or dbodysetposition it does the flying off to infinity thing. It seems like ode numbers need a very light touch, one little change and it all goes drastically pearshaped. |
| ||
| once the geoms are attached to the bodies, you only to need to position one of them, not both... |
| ||
| Yeh, as Kuri says you normally only need to reposition the body, the geom is already attached and will move with it. Make sure you cancel out the velocity (force/torque etc) when repositioning them to prevent the simulation exploding. As you've discovered even tiny value changes can have very large effects on the simulation, so make very small adjustments. |
| ||
| With the same initial conditions will the simulation always reach the same solution? I am starting on a very basic crossfire (old board game where you fire bearings at a puck and try to score in an opponents goal) game and I am trying to come up with a networking strategy before I start. I would like to just have the programs passing the smallest ammount of information possible, the angle the gun is pointed at and if a bearing has been fired. But this will only work if the simulations on both machines stayed in syncronisation. |
| ||
| It depends on the resolution of accuracy used. Make your simulation step size (dWorldQuickStep) as small as possible. You could also try using dWorldStep which is far more accurate but will use much more memory. You can test how accurate it is by doing a few runs with the same angle and measure the coordinates of the bearings. If they end up at the same position you should be fine, but I would recommend performing the same tests on another machine to make sure. |
| ||
| What will happen when my ragdoll mesh has geom peices placed inside it, but needs to move around and be animated? This would be while forces are disabled, like I mentioned before. |
| ||
| What will happen? I'm not sure what you mean, you need to disable the physics while animating, then re-enable it when you're not animating. When you switch from animated to non-animated the physics will take over. Something like this... Animated - Physics disabled / Update geom positions to match RagDoll mesh positions Non-Animated - Physics enabled / Update RagDoll mesh positions to match geom positions There's more info in the previous JV-ODE threads regarding animated RagDolls IIRC, that might help point you in the right direction. |
| ||
| That's exactly what I mean. How would you update geoms to match an animated mesh? Or will the geoms just follow the body through animations all on their own? |
| ||
| Regarding objects and large triangles I have been playing around with one of the car demo's and it seems one can scale the trimesh up to about 32X without too many problems although some jitter is detectable. I think there must be something wrong with the trimesh loading function which I am using, which is basically same as the one I mentioned earlier in the thread. I made a heightmap that was flat except for some tall square areas, like skyscrapers, of differing sizes. Apart from alot of terrain snagging the other curious thing is the alignment of the drawn terrain against the invisible trimesh. Travelling the z axis + or - into a skyscraper the collision is perfect but when I do it in the x axis there vehicle stops in front of the wall by a certain amount. I initially thought that this was due some kind of terrain displacement..but this happens in either direction when travelling East or West into the side of a skyscraper which I don't understand. I've tried changing the order in which triangles are read into the trimesh etc but this doesn't seem to help. Anybody got any thoughts on why this might be.Is there some trick to reading in the triangles that I am missing? I am happy that my terrain drawing function works as in my un-oded version it is pixel perfect. |
| ||
| @IKG: No, the geoms will remain in their original set up positions during the animations unless you update their position/rotation. You need to track the position/rotation of each bone node and update the geom position/rotation to match them. It's basically the reverse process of the RagDoll Zombie demo, which performs the non-animated process only. It's quite tricky to do but I know it's possible as Smiff used the same procedure for the outstanding PaceMaker application. I haven't actually tried to do this personally otherwise I could've given you some code to study. @KronosUK: ODE is picky about how a TriMesh is constructed, I would highly recommend you use the same method as the function I've posted above. Although it will draw perfectly doesn't mean that ODE will build the TriMesh with the same vert/tri ordering. I suspect that is the most likely cause of the strange behaviour. |
| ||
| Man, that really sucks :( This is a very important part to my game. I hope I find some sort of solution. Thanks for you help though. |
| ||
| Do you need to do this in real-time IKG? I know it would be the best technical solution, but it's far from the easiest. Have you looked at the PaceMaker application I mentioned earlier? It might provide a simple workaround for your animation stuff, although it's difficult to say without knowing what you're trying to accomplish. Anyway, here's the link to PaceMaker, I hope it will help... www.goddysey.com |
| ||
Finally......got heightmap loader code to work. Mesh now lines up with drawn terrain and no snaggies.
Function TriMeshCreate%(mterrain:terrain,dspace:Int)
Local tris_count% = 0
Local vert_count% = 0
tris_count = 2*(mterrain.mapwidth-1)*(mterrain.mapheight-1)
vert_count = mterrain.mapwidth*mterrain.mapheight
Global vertices_bank:Float[vert_count*4]
Global indices_bank:Int[tris_count*6]
Local a:Int =0
For Local i% = 0 To mterrain.mapwidth - 1
For Local j% = 0 To mterrain.mapheight- 1
vertices_bank[a+0]= i*mterrain.mapscale
vertices_bank[a+1]= mterrain.height[i,j]
vertices_bank[a+2]= j*mterrain.mapscale
vertices_bank[a+3] = 0
a:+4
Next
Next
a= 0
For i = 0 To mterrain.mapwidth-2
For j = 0 To mterrain.mapheight-2
'first triangle in quad
indices_bank[a+0]= i*mterrain.mapwidth+j
indices_bank[a+1]= i*mterrain.mapwidth+j+mterrain.mapwidth+1
indices_bank[a+2]= i*mterrain.mapwidth+j+mterrain.mapwidth
'second triangle in quad
indices_bank[a+3]= i*mterrain.mapwidth+j
indices_bank[a+4]= i*mterrain.mapwidth+j+1
indices_bank[a+5]= i*mterrain.mapwidth+j+1+mterrain.mapwidth
a:+6
Next
Next
Local t_data:Int = dGeomTriMeshDataCreate()
dGeomTriMeshDataBuildSimple(t_data,vertices_bank,vert_count,indices_bank, tris_count*3)
Return dCreateTriMesh(dspace, t_data)
End Function
|
| ||
| Nice one Kronos, thanks for posting the updated function :) |
| ||
| Yeah, I took a look at it earlier. Still have no idea how I could update the geoms with the mesh while it's moving and animated. Thing is, this is by far my most important goal to accomplish. I must find a way to do this. What would happen if I tie the geoms to the body with EntityParent? What makes them stick to the body in the first place, in the demo? Is it because time is not stopped, and TransformMesh is enabled? Thanks once again for all this help Viper. I won't forget it ;) |
| ||
| You won't need to keep moving the geoms while the RagDoll is animating as they should be disabled during the animation, but you do need to keep track of the position and rotation of the bone nodes (the bone nodes are the actual joints in the animated model). Only when you switch from animated to non-animated should you apply then new rotation and positions for each geom and re-enable them. You're thinking along the correct lines for the EntityParent idea, but unfortunately an ODE geom cannot be assigned as a Blitz3D entity so technically it won't work. The reason the demo works in this way is because it's doing the opposite of what you need to do, so EntityParent is doing all of the complicated stuff for you. Here's something to try... Instead of tracking the bone nodes directly, you could try tracking the position and rotation of the visible geoms (ode\mesh in the demo) and place the ODE geoms in the exact same position/rotation as those. Remember you don't need to relocate the geoms until the switch to non-animated, once switched you should update them every loop. |
| ||
| Now I understand what you want me to do. Only problem is, I have no idea how to calculate something like that. The nodes/joints are placed manually in the demo since the ragdoll is in 1 position. How would I ever know where a limb or body-part is in the middle of an animation? I know you already said you don't know how, so this is pretty much pointless repeating again. Too bad EntityParent doesn't work for geoms. And what you said about how the demo does the exact opposite of what I'm trying to do; Does that mean the demo code will not work with my idea? If that's true, then I'm wasting my time trying to figure this out if I can't even use the code given :( Edit: I added the following code to the Zombie demo to test what would happen if I moved the first zombie while frozen: If KeyDown(18) Then MoveEntity RDmesh(1,0),0.5,0,0.5 MoveEntity RDmesh(1,1),0.5,0,0.5 MoveEntity RDmesh(1,2),0.5,0,0.5 MoveEntity RDmesh(1,3),0.5,0,0.5 MoveEntity RDmesh(1,4),0.5,0,0.5 MoveEntity RDmesh(1,5),0.5,0,0.5 MoveEntity RDmesh(1,6),0.5,0,0.5 MoveEntity RDmesh(1,7),0.5,0,0.5 MoveEntity RDmesh(1,8),0.5,0,0.5 MoveEntity RDmesh(1,9),0.5,0,0.5 MoveEntity RDmesh(1,10),0.5,0,0.5 MoveEntity RDmesh(1,11),0.5,0,0.5 MoveEntity RDmesh(1,12),0.5,0,0.5 MoveEntity RDmesh(1,13),0.5,0,0.5 MoveEntity RDmesh(1,14),0.5,0,0.5 EndIf I held down "q" (my button that freezes everything) and then held down "e". Everything moved together while frozen. Would this not happen if the mesh was animated? Looks like it might :D Edit 2: I just realized this works only because the geoms are what move the mesh. With an animation, the mesh would be the one moving. Maybe there's some way to switch this around? To get everything to follow the mesh while disabled, without having to calculate and replace everything when re-enabled again. Another thing, when I try to move the entire mesh by refering to it as RagDollMesh(1), it only moves a single dot/part away which warps it. Is this why I would need to disable all the joints and geoms, not just the time? Is that why you were saying why "EntityParent" in the demo was used the wrong way? Uh oh..so that means the geoms and joints are in control, not the mesh. Ok, so my way won't work... The long way of accomplishing this would be to configure everything manually, for each frame of animation. That way everything would be reset to the right parts of the mesh, according by what frame it is currently being animated by. But that would take far too long... |
| ||
| And what you said about how the demo does the exact opposite of what I'm trying to do; Does that mean the demo code will not work with my idea? No, it will work fine with your idea. Don't forget there are two stages, one for animated and another for non-animated. The demo code is the non-animated stage so you can use that as is. The part you are trying to do is the animated, where the physics are disabled. To understand it better I would advise you add a couple of lines in the RagDoll Zombie demo immediately before the Flip in the main loop... Text 0,80,"Neck Bone - Bone(1,10):" Text 0,130,"X Pos:"+EntityX(Bone(1,10),1) Text 0,145,"Y Pos:"+EntityY(Bone(1,10),1) Text 0,160,"Z Pos:"+EntityZ(Bone(1,10),1) Text 0,180,"Pitch:"+EntityPitch(Bone(1,10),1) Text 0,195,"Yaw:"+EntityYaw(Bone(1,10),1) Text 0,210,"Roll:"+EntityRoll(Bone(1,10),1) Text 0,250,"Head Mesh - RDMesh(1,0):" Text 0,270,"X Pos:"+EntityX(RDMesh(1,0)) Text 0,285,"Y Pos:"+EntityY(RDMesh(1,0)) Text 0,300,"Z Pos:"+EntityZ(RDMesh(1,0)) Text 0,320,"Pitch:"+EntityPitch(RDMesh(1,0)) Text 0,335,"Yaw:"+EntityYaw(RDMesh(1,0)) Text 0,350,"Roll:"+EntityRoll(RDMesh(1,0)) The top part of the above code will track the position and rotation of the neck joint on RagDoll number one (on the left). To try different joints change the 10 for another number (use the SetupBones() function for a guide). Also note that the above function calls for the bones use the global flag (,1). The second part of the above code tracks the position and rotation of the visible Blitz mesh used for the head, again you can try different meshes by changing the 0 to another number (see the CreateRagDoll() function for a guide). Now, you can track the position/rotation of the bone nodes then update the geoms from those, which might be more difficult to do as it will probably require some math to get the geoms into the correct positions etc. Or, like I mentioned earlier you can track the position/rotation of the Blitz meshes (the visible green/red/white body parts). With the mesh method you might be able to simply update the ODE geoms to match the position/rotation of the visible body parts (Blitz meshes). Don't worry you should get there if you persevere, but it will take a lot of effort and trial/error before you succeed. It isn't something I would recommend to someone new to ODE/Blitz3D though, it's much too complicated tbh. |
| ||
| I think I did it! I went back and replaced each geom positioning with the correct bone coordinates using EntityX/Y/Z() for each geom (changing the bone each time of course) Everything runs just as smoothly as before. I'll do the same with rotation now. So basically, instead of positioning each geom with xp,yp, and zp, I now use "each bone for each geom" coordinates. Here's an example of what I did for a random geom, commenting out the parts I replaced: ; ### Create Right Leg (Lower) ode.ODEGeom=New ODEGeom ode\body=dBodyCreate(World) RDBody(rd,13)=ode\body dBodySetRotation(ode\body,0,0,0) dBodySetPosition(ode\body,EntityX(Bone(1,18),1),EntityY(Bone(1,18),1),EntityZ(Bone(1,18),1)) ;xp-0.6,yp-6.25,zp+0.25) dBodySetAutoDisableFlag(ode\body,1) ode\geom=dCreateCylinder(Space,0.00001,0.00001) dGeomSetBody(ode\geom,ode\body) ode\mesh=CreateCylinder(8) RDMesh(rd,13)=ode\mesh EntityPickMode ode\mesh,2 ScaleMesh ode\mesh,LegLRad,LegLLen*0.5,LegLRad RotateMesh ode\mesh,-8,0,-4 PositionMesh ode\mesh,0,0,0 EntityColor ode\mesh,0,125,0 EntityAlpha ode\mesh,geomalpha TransformGeom=dCreateGeomTransform(Space) GeomObject=dCreateCylinder(0,LegLRad,LegLLen) dGeomSetRotation(GeomObject,-8,0,-4) dGeomSetPosition(GeomObject,0,0,0) dGeomTransformSetGeom(TransformGeom,GeomObject) dGeomTransformSetCleanup(TransformGeom,1) dGeomSetBody(TransformGeom,ode\body) So I think I did it! I'll have the mesh placed first standing up so I can setup all the bones. I will then update all the geom's positions to their correct bones each loop. I'm almost sure this will work. What do you think? Edit: Now I'm starting to wonder how this changes anything. I kind of lost track of the whole problem I was trying to solve before. If I try to animate the mesh itself, will the bones follow? It looks to me like the mesh is still not in control because of this peice of code: EntityParent RagDollMesh(rd),RDMesh(rd,1) AHH! Then I haven't made any new progress! |
| ||
| Re-read the post above, I edited it while you posted. Yep, the bones should change position/rotation during the animation sequence. You must -not- call the UpdateNodes() function at all during the animated stage, only during the non-animated stage. Keep tinkering with it ;) |
| ||
| I understand it all now! Thanks so much Vip3r. As soon as my game is finished, I'll be sure to give a donation via PayPal ;) |
| ||
| The method VIP3R describes is basically what I use in PaceMaker. When the model is animating the physics are disabled(rag-doll destroyed).The joints are controlled by the animation. When the animation is stopped I build the rag-doll using a reference position and set all axis and limits. I then move/rotate the geoms to the global position of the joints as they were. From that point the geoms are updated and the joints moved/rotated to follow. This way the transition is seemless and the joint limits are set correctly no matter what pose the model was in when killed ! |
| ||
| whats this like for doing 2d based physics ? |
| ||
| Hi skn3, It can be done quite effectively by limiting one axis (Z or Y axis for example). Here's a 2D Spheres demo that you can try with the demo version of JV-ODE... In the demo I've restricted motion on the z-axis using two very large slim boxes (barriers). You can think of these two boxes as two sheets of glass in a double glazed window, then the spheres are dropped between them. To make sure the spheres don't snag on the insides of the two barriers, their friction has been set to zero (full version only). There is also a plane at the base to stop them falling below ground level. Have a tinker with it and see what you think ;) |
| ||
| @Smiff / @IKG Smiff, I understand what you're saying between switching between ragdoll-controlled and animation-controll models. BUT when your model is in 'animation mode' will it still respond to external collisions??? I.e. WHEN do you decide to go from one to another?? I'm also trying to setup an animation system where you have a keyframed character walking around, but as soon as it get's hit by an external body, it should switch to ragdoll mode so as to 'suffer the impact' of the collision... If possible I want to limit 'minor collisions' to certain limbs e.g. a hit on the hand will affect the arm and not make the ragdoll fall over completely. But when he get's hit on the leg, he will lose control over his walk cycle and hit the dirt face first... hope this makes sense ;) Danny |
| ||
| ODE collision response will only occur when the physics are enabled (non-animated), if you disable the physics then you'll also disable the collision response. There's no reason why you can't use Blitz collisions for the animated stuff, then switch over to ODE collisions when you re-enable the physics. |
| ||
| That's exactly my point viper. So you're saying that during animation-mode you'd use Blitz to 'detect a collision' then read that coll info (direction vector, force?); re-enable the ragdoll and feed the blitz collision info onto the relevant ODE bodies in order to get an accurate response from the ragdoll? A possible theory but pretty tricky stuff... What you'd actually want is bodies/geometry that are 'idle' (when it comes to forces and gravity) and are 'moved along' with the model's bone structure but remain sensitive to collision, and if so, re-enable their properties (weight, gravity, friction, etc) and let ODE do it's thing..... ?! D. |
| ||
| No, that would be much too complex. I would envelope the entire RagDoll inside a Blitz collision 'bubble' to detect the initial contact and enable the physics, so that by the time the colliding object is about to collide with the RagDoll itself, the physics will takeover the collision response. You can try your second suggestion, I'm not sure how well it will work though. ODE objects can have the gravity effects disabled per body and you can cancel the forces per body. The problem is, although this method will detect collisions, it won't apply any collision response because you're cancelling them out. By the time you reactivate the collision response, the object would probably have passed right through the RagDoll. |
| ||
| That's a pretty cool idea with that collision-bubble! Got me thinking again... cool! I should have some time this week so I defenitly are going to get deeper into this matter... "i'll be bak!" ;) d. |
| ||
| I see that I can use JV-ODE to give me the contactpoint of a collision between a ray and a trimesh but can I use it to tell me what the vertices of the struck triangle are? edit: never mind a possible answer has come to me. knowing the position of the contact point is all the info I actually need. As my trimesh terrain is symmetrical in x and z axes all I need to know is the x and z position of the contact to ascertain the triangle thats been hit. |
| ||
| Do any of the current demo's use rays? If not could we have one please? |
| ||
| Regarding the ragdoll stuff above: A possible theory but pretty tricky stuff... You needn't do it that way, but that is how you had to do it in the old ODE wrapper. What a headache! Lucky enough there was a little demo showing how to use the collision info with ODE. The best way would be as Viper said, put it in a blitz collision sphere and when that collides, enable physics :-) |
| ||
| Thanks Cygnus, yes I'm pretty confident that i'll work. Currently I've managed to create a routine that converts a rigged b3d character (originally from Lightwave) into a default ODE ragdoll-skeleton (rigid bodies and hinge joints). So now I'm building a quick editor to tweak & change things before animating it... l8rs,- Danny |
| ||
| @Kronos: None of the existing demos use rays. Here's a simple ray demo for use with the BlitzMax (Win32) version... |
| ||
| thanks Vip3r.. dunno what i was doing wrong in my experiment but my ray wasn't registering any collisions |
| ||
| Hi All, I've just purchased JV-ODE for Blitz3D and have a few questions. Please bear with me if they have been asked and answered before. I did review the threads but didn't see an answer. I'm working on a platform type game and would like to use ODE for all the collisions and interactions including the player. What is the best way to use a primative to represent the player? I was thinking that I could use a sphere and push it forward and back according to the up and down keys and rotate it using the left and right keys. I have forward and back working but wasn't able to rotate it. I did get the sphere to go left and right relative to the screen by applying forces but that's not what I want. I want the forward motion to be relative to the rotation of the sphere. Should I not being using a sphere? I hope that made some kind of sense. Thanks. |
| ||
| Hi Physt, Have a look at PsychicParrots great angular velocity sphere demo. The method used in the demo would provide a decent solution for controlling the player in a platform game... Hope it helps :) |
| ||
| Thanks! I'll try it out as soon as I get home tonight. |
| ||
| VIP3R - Perfect. Exactly what I was looking for. :) |
| ||
| Nice one :) |
| ||
| JV-ODE V1.17 Update Released Please check your inbox :) JV-ODE is now compiled using ODE V0.6 which was released recently. To view the changes made to ODE, please visit the following ODE Wiki link: http://opende.sourceforge.net/wiki/index.php/Changelog All depreciated functions (dCreateCCylinder, GeomTransforms etc) are still supported in JV-ODE, but it's recommended to use the new equivalents (dCreateCapsule, GeomOffsets etc). Added 40 new functions... As it's a major update, the JV-ODE version number has increased by two digits (there was no V1.16)... Please let me know if you experience any problems with the new update. :) |
| ||
| Wo-hoo! Thanks for the 1.17! :) |
| ||
| Awesome! Thanks for your great work. [EDIT] I'm having some problems with 1.17. I have copied JV-ODE.decls and JV-ODE.dll to C:\Program Files\Blitz3D\userlibs. Then I try to run the included CarDemo.bb. But I get a "User lib not found" error. In debug mode, the error seems to be coming from jv-ode.bb, on the dRegisterODE line. |
| ||
| Hi VIP3R, Same problem here i'm afraid. (As Ervin above) Looking forward to trying the capsules (so to speak !) Mark |
| ||
| Same issue here. On a side note, I always copy JV-ODE.dll , as well as any other support dlls that I use while programming, to my windows/system32 folder. That way your executables will always find it. |
| ||
| Ok, thanks for the reports, I'll look into it. I haven't had any problems at all while developing V1.17, can you post your system specs. Personally, I only copy the decls files into the userlibs folder and leave the DLL in the project/demos folder. Can you try that too? Mark, does it happen with the BlitzMax version on your system? The only possible cause I can think of is the DLL compression. Can someone try the demo versions of JV-ODE and see if they work or not? They have different compression ratios to the full version. |
| ||
| Hi VIP3R. My specs: HP Pavilion zd8000 notebook P4 3.4 Ghz 2GB RAM Radeon x600 256MB Windows XP SP2 Blitz3D 1.96 I tried putting only the decls into userlibs and leaving the dll in the project folder, but that didn't change anything. I tried using the latest demo version of JV-ODE, and that gives me the same error. I then tried using the full version of 1.15, and that worked without any problems. |
| ||
| Hi ervin, Thanks for the specs and info :) I've had confirmation of the DLL working ok in BlitzMax so I suspect this is indeed a compression issue upsetting Blitz3D. Works ok here though, weird. I'll build you a test DLL shortly and email it to over if that's ok? |
| ||
| I'll build you a test DLL shortly and email it to over if that's ok? That'll be great! Thanks. |
| ||
| Ok, I've sent the test DLL for you :) |
| ||
| The test DLL works! |
| ||
| Hmm, as I suspected... I wonder why the original DLL works here, must be decompressing fast enough for B3D to detect it? Thanks ervin :) New update coming very soon! |
| ||
| The new JV-ODE V1.17 update has now been re-released. Please check your inbox :) |
| ||
| Excellent - works beautifully now. |
| ||
| Thanks VIP3R, all fixed. Excellent support as usual. Sorry I couldn't try the MAX version - don't have it installed at the moment. Cheers again, Mark |
| ||
| New one works just fine. Thanks for the quick response. |
| ||
| Thanks all, you're welcome :) |
| ||
| Hi Viper, how I know when my Car are with two wheels only on the floor? Or, Have some way to do the Car Run with Only Two Wheels? |
| ||
| Hi EmerGki, Take a look at the 'CarDemo-CCount' demo included with the wrapper, it checks for collisions on each individual wheel of the car. When there are no collision counts on a wheel, then the wheel isn't touching the floor. |
| ||
| Vip3r, I've trying to do my car run in two wheels only, but, I'm having trouble, I'm not achieving keep my car in two wheels. Have some idea in how I do this? |
| ||
| Hmm, that's going to be very difficult to do (same as in reality). You could try moving the mass of the car body sideways/lower when you want it to stay on two wheels, making it very heavy on the side you want to keep on the floor. There are two ways to do this... One way is to use the 'dMassTranslate(mass,x#,y#,z#)' function, you can see this function being used in the car demos to lower the mass of the car body. This would be the easier option. A better method would probably involve using geom transforms (or the new geom offsets), you can see this in the 'CarDemo-GeomTransform-Car' demo included with the wrapper. When you move the mass sideways/lower, it will act as a stabiliser making it much easier to keep the car up on two wheels. Don't be under any illusions though, it will take a lot of tweaking to get it working well. |
| ||
| I have purchased the JV-ODE library and it is very impressive.I would like to implement physics in a flying vehicle ( helicopter or airship ), VIP3R do you know if are there any example about it? |
| ||
| Hi, There are no helicopter/airship examples that I know of, but it's very easy to do. You need to apply a vertical force (y-axis) on the helicopter body to make it rise and then let gravity allow it to fall again. You can use dBodyAddForce(body,x,y,z)/dBodyAddRelForce(body,x,y,z) to do this, add a positive value to the y parameter. To move the helicopter while it's in the air, apply a force on the x and/or z axis. |
| ||
| does anyone know how to get a cube within a cube? and be able to move and rotate the container cube? |
| ||
| Do you mean move and rotate it manually or let the physics move and rotate it? |
| ||
| manually. Id like the container cube to not react to physics. I cant remember the name for an object that doesnt react when hit, er... terrain or something. and the inner cube to be a rigid body. So if i manually turn the container cube the little cube will slide about inside. Thanks for the help |
| ||
| Ok that's what I thought you meant, unfortunately you can't move stuff manually in ODE because it abuses the physics simulation. But you might be able to do what you want using other methods, it's hard to say without knowing your exact requirements. An object that doesn't react to physics is called a 'static geom'. Using a static cube geom won't work though as the collision detection will only prevent objects penetrating it from outside, it won't prevent objects within from escaping. Instead you could try building the container cube from 6 flat square ODE cube 'panels'. Note that you should only create the ODE geoms for the panels, don't create bodies as they need to be static objects if you move them manually. The hard part is keeping all of the six panels aligned when rotating the container cube, it will require some serious math. You could cheat though, when you create the static geom panels, you should also create their associated Blitz meshes (like ode\mesh in the examples) and parent them to each other. Then to move the container object, move the Blitz mesh entities and update the ODE geom panels to match the position/rotation of the Blitz mesh entities. In theory it should work, but ODE really isn't designed for this kind of thing (moving objects manually) so you may find collision penetration or other issues when you try it. |
| ||
| Hi all - hope you are all having a great weekend. I've been trying to iron out a glitch in my games testbed for a couple of weeks now but I just can't shift the bugger. I've got a static, non-animating trimesh and a sphere but the sphere is colliding irregularly with some of the edges of the trimesh polygons. It tends to happen more frequently at low speeds and acute angles but I've also seen it happen at higher speeds and larger angles. Most of the last two weeks have been spent tweaking variables like ERP, CFM, timestep size, trimesh and sphere scale etc and this does have some effect but has never cleared the glitch completely, only lessened the frequency of it occuring. I've also tried meshes created in 3d Studio, Lightwave and Blitz but it happens on all of them. Reading through the ODE Archives I have seen that it appears to be a relatively common problem (or at least a problem that other people have encountered) but none of the fixes mentioned on that forum, that I understand, have really helped. One theory was that the normals of the trimesh were wrong but I don't think it is that - they are reporting back correctly (the trimesh is completely flat). Another theory was that multiple contact points between the trimesh and the sphere confused the simulation but it is only reporting a maximum of one collision. The code below demonstrates the glitch (hold SPACE to apply random force to the sphere - TAB resets the sphere - LEFT CTRL turns on the trail showing the spheres path - LEFT SHIFT toggles wireframe mode)... The values in the above code don't represent my best effort at tweaking, by the way, they are just the latest set of values I have tried. Any advice would be very much appreciated. I'm practising my embarrased face, just in case someone is kind enough to take a look and gets this working with a tweak or two. All the best to you all (big thanks to VIP3R for his ongoing work and support + the thread regulars for their contributions) |
| ||
| thanks viper you helped me out a lot there |
| ||
| Hi TMG, Unfortunately I don't know of any complete cure for the glitch with flat mesh edges. ODE 'sees' the edges as a ridge rather than a flat surface, so the contact joint is created at an angle causing the ball to go off course. The problem only appears with a flat mesh though, so to fix it you will need to use a different approach. The best way would be to use a plane instead of a mesh, but it depends on whether that would suit your needs. Another way is to make the mesh triangles large enough so that the ball never encounters any edges, you would only need one large triangle or quad. This method may not work well though as large mesh triangles can cause penetration problems. There are quite a few issues with the code you posted. Using high friction/gravity/mass values will give you problems, try to keep them lower if possible. Some of the other tweaks used (like Soft ERP/CFM) will probably cause more problems in this instance too. Here's a tweaked version of your code that has more stable values, I've marked the tweaks with '********' so that you can see the differences clearly... @Slunkar: You're welcome :) I forgot to mention that you may need to place the container cube panels into their own sub-space (see multiple spaces) and disable internal space collisions to prevent them colliding with each other. Check out the previous JV-ODE threads, there's lots of info about sub-spaces and disabling internal space collide modes. |
| ||
| Thanks for the reply, VIP3R - much appreciated. I'll look into ways around it, particularly re-evaluating the mesh construction as a plane won't suffice unfortunately. I am hoping to use quite detailed trimeshes in the final game and the ball trajectory has to be really quite precise to make the game workable. Once again, thanks for your time and effort - top man! |
| ||
| You're welcome TMG :) Another method you could try is to make the flat mesh using lots of smaller triangles, maybe 10x-20x the amount used in the code you posted. It may prevent the ball from snagging on the triangle edges. I'm not sure if it will help but it's worth a shot, let me know if you need more help with it or if you find a decent solution ;) |
| ||
| hi thanks for the help, that was the pinball table set up! However I have been trying to create flippers for 2 days with no luck. When I go into the rope-demo and reduce the number of balls to 1 it fails to move. I changed the joint type to a hinge and move the joint about 10 units above the ball. So theoretically the ball should move as if it is connected to 'the world' by a hinge. Thing is when I add 9 other balls to the first one the first ball reacts as I expected! I dont get this at all. |
| ||
| Ok, what's happening is that the top rope object is auto-disabling when there are no other objects attached to it. When the other rope objects are attached, they move it very slightly, enough to stop it from auto-disabling. There are two ways to stop this behaviour: You can either turn off the auto-disable of the rope object by changing the 1 to 0 in the following line... dBodySetAutoDisableFlag(ode\body,0) Or, the best solution is to make sure that the rope object is enabled before you move it. To do this, change each line of the UpdateKeys() function like so... If KeyDown(203) Then dBodyEnable(Sphere(1)) : dBodyAddForce(Sphere(1),-10,0,0) Note that you will need to add lo/hi stop values in the hinge parameters to limit the movement of the hinge... dJointSetHingeParam(joint,dParamLoStop,-1) dJointSetHingeParam(joint,dParamHiStop,1) With the above settings, the hinge will move from -1 through to +1 radians, 0 will be the center of movement. You can increase or decrease the values to allow/limit whatever movement you need on the hinge joint. The lo stop value should always be lower than the hi stop value. |
| ||
| I've put together a quick demo to show how to create some pinball flippers which you can use as a guide... |
| ||
| Hey Thanks! I tried the same thing but high speed balls kept passing through the flippers. Yours works great. It looks like the 4 collide - step calls in succession is what's needed. Mike |
| ||
| wow thanks, that's a truely amazing demo well done |
| ||
| Thanks both, you're welcome :) |
| ||
| Just wondering if there are any completed blitz games available that use JV-ODE? |
| ||
| Yep, I don't know of all of them but here's some completed software using JV-ODE... Tricky Tracks - Game  PaceMaker - Application  |
| ||
| I just bought JV-ODE physics engine, and must thank Viper for handling everything smoothly. The whole package seems great, and I've already managed to drop in some shadows and have boxes dropping around ;) I would have a problem... I'm going to make a 3D hand (to replace mouse cursor) and I'm going to drag stuff... but I don't know (yet) how to do that. Is it possible to create dBoxes in the world, and then attach them (as joints) to 3D hand object? Or do I have to play with applyForce thingies? Thanks. |
| ||
| well, i would destroy the ODE-object, when a box is dragged, attaching the blitz-entity to the hand and create a new ode-object and attach it to the Blitz-Entity when the box is released... in general, its not a good idea to move a ODE-Object by hand! |
| ||
| Hmm... but I would like to see the object swinging when I drag it all around... :) |
| ||
| Hi Juuso, You can try it, but as OJay says it may cause problems because ODE doesn't like an objects position to be manually forced. The problem isn't the boxes, but the hand object which is manually positioned by the mouse. The main issue you may have is penetration of other objects, but you probably won't want the hand object to collide with other objects anyway. If you want to try it, do the following: First you will need to create an ODE body and position it at the location of the hand. Make sure you disable the effects of gravity on the ODE hand body with dBodySetGravityMode(body,mode). You don't need to create a geom for the body, it is just used so that you can add a joint to it. Each frame you will need to position the body at the same location as the hand object. Now, when you want to grab an object you can create a joint between the box and the ODE hand body. To release it again, just break/destroy the joint. You may get an error in the UpdateGeoms() function because the ODE hand object has no geom, to fix this make sure a geom exists before the position/rotation of the meshes like so... See if that works ;) |
| ||
| What IF I want the hand to collide as well? Would it make it any easier? :) I'll try that... |
| ||
| Okay... looking good so far... next thing is to create the joint.... |
| ||
| Alright... I managed to do *something* http://www.gameproducer.net/public/demo.zip The system works like this: - click left mouse to attach joint to the NEWEST block - click right mouse to break joint thingy I still have couple of problems - like when you grap something, it goes fine - but then the piece starts to slowly move down... I don't understand why. It looks like my joint is very strecthy :) Some code - create mouse ODE, joint etc: Function createMouseODE() GFX_mouseMesh = CreateSphere() ScaleEntity GFX_mouseMesh, .2, .2, .2 EntityColor GFX_mouseMesh, 200, 0, 0 ode.ODEGeom=New ODEGeom ode\body=dBodyCreate(World) GFX_mouseODEbody = ode\body DebugLog "creating mouse ODE body: "+GFX_mouseODEbody dBodySetRotation(ode\body,0,0,0) dBodySetPosition(ode\body,xp#,30,zp#) dBodySetAutoDisableFlag(ode\body,1) ;ode\geom=dCreateBox(Space,1, 7, 3) ;dGeomSetBody(ode\geom,ode\body) dBodySetGravityMode(ode\body, 0) ;SetShadowMesh(ode\mesh) ;create joint RDjoint = dJointCreateHinge(World,0) dJointSetHingeAxis(RDJoint,1,0,0) dJointSetHingeAnchor(RDJoint,xp-0.5,yp-5.5,zp) dJointSetHingeParam(RDJoint,dParamLoStop,-0.25) dJointSetHingeParam(RDJoint,dParamHiStop,0.25) End Function attaching joint (pickODEbody is the body of latest box) dJointAttach(RDJoint, pickODEbody, GFX_mouseODEbody) code - positions: ; position update PositionEntity GFX_mouseMesh, CAM_cameraPickX#, CAM_cameraPickY#, CAM_cameraPickZ# PositionEntity GFX_mouseMesh, CAM_cameraPickX#, 0, CAM_cameraPickZ# dBodySetPosition(GFX_mouseODEbody,CAM_cameraPickX#, 15, CAM_cameraPickZ#) Questions: 1) Is there anything I could do to join the box and mouse with a less flexible joint? (to prevent box from falling down...) 2) How could I grap the box from the other end - rather than in the middle of the box? Thanks in advance. |
| ||
| The hinge joint probably isn't the best joint to use for this purpose, try either a ball joint or a fixed joint instead. A joint will always attach to the center of a body. If you want to grab the box from a different end you would need to create each box using several smaller boxes (sub-boxes) and attach them all together with fixed joints, then you can grab or attach the joint to whichever sub-box is closest to the end. |
| ||
| Well, I tried RDjoint = dJointCreateBall(World,0) but it seems to do no good :) Is the gravity code okay? dBodySetGravityMode(ode\body, 0) Am I attaching the joint properly? dJointAttach(RDJoint, pickODEbody, GFX_mouseODEbody) (previously made joint is put between picked box and mouse?) How can I make the joint so that it isn't so flexible or anything? |
| ||
| Yep, the gravity code is ok. Normally you can use ERP and CFM to adjust the flexibility of a joint, a high ERP (0.8) and low CFM (less than 0.001) will make it rigid. You can read more about ERP and CFM in the official ODE User Guide. It looks like manually forcing the position of the hand ODE body is causing your problem, as previously predicted. It's considered abuse of the physics simulation as ODE is designed to handle the position and rotation of objects itself. The only safe way to do it would be to apply forces to the hand ODE object to move it instead of manually re-positioning it. |
| ||
| Hmm... but why in the rag doll demo the rag dolls always get attached nicely when you press F1 / F4? |
| ||
| Uh... I played with the rag doll demo... auch. Apply forces seems to be the way to go. Auch again. Now this gets interesting - I need to calculate mousemovement... and add force to objects depending if they are "picked". Yaiks. Has anyone did this before? :) |
| ||
| The RagDoll demos use static joints, they don't use manual re-positioning. Static joints are created between a body and the world (represented by a zero). Ouch indeed, it's not going to be easy at all. I've no idea if anyone has tried it before with ODE, you could try searching through the ODE Archives located here. |
| ||
| I'm going to see if I can work things out... at the moment I decided to stick with destroy/create new geom/body - and it works ok. Thanks VIP3R for patiency and help :) One additional question: Is it possible to create a room mesh (like .3ds) and then have some sort of automatic way to make the ODE physics work? (So that when I model a door way... objects wouldn't collide there, but they would collide in ceilings and walls etc.) Thanks in advance. |
| ||
| No problem ;) Yes, the ODE TriMesh which you create from your 3ds mesh will determine the collision geometry used by ODE, so objects will only collide with the visible areas of the mesh. |
| ||
| Ooh... TriMesh. Is that fast/slow compared to "normal collisions"? How can I make the mesh so that objects collide with it, but I won't want it to move (like if I make a room - I want the walls/floor etc stay where they are even if objects hit the walls :) |
| ||
| They're the same speed as normal collisions. The following code (included in the JV-ODE TriMesh demos) shows how to create them... Notice the Y Position of the mesh and TriMesh are set at '0.05', this is a quick way to prevent the static mesh from constantly colliding with the ground plane. The correct way to prevent this would be to use multiple spaces with internal collide mode disabled. Read through the previous JV-ODE threads as there's a lot of info which will help you with multiple spaces and other advanced subjects. |
| ||
| Hello Viper, I have a question: I want to control a flying vehicle with rotations,what is the best way to turn the vehicle?. Is it possible using ODE rotations(dBodySetRotation,dBodySetAngularVel etc.)? Thanks. |
| ||
| No, you shouldn't use the 'Set' functions while your simulation is running unless you're resetting an object. If you want to move an object in ODE you should apply Force and Torque only, either to a body directly or via joints ;) The best way to turn a flying vehicle would probably be adding relative force... The following will rotate to the left (left wing down): dBodyAddRelForce(ode\body,-40,0,0) The following will rotate to the right (right wing down): dBodyAddRelForce(ode\body,40,0,0) |
| ||
| Hi All, What's the way to get the 'amount of force' back when two geometries have collided?! I'm trying to decide in my code that 'minor collisions' or objects 'bumping into each other' doesn't count, but bigger collisions (higher impact/force) will result in damage... I tried using the Collision normal (dGeom1CollisionNX/Y/Z) but that vector is normalized... dGeom1CollisionsDEPTH is not the way to go either I believe, so.... any suggestions? Thanks, Danny. |
| ||
I did manage to come up with this one; getting the difference between the two body's velocity. I can't use their 'forces' because if a body is parented to something else, it would have a force of 0! For example: The car body when attached to some wheels..dBodyGetLinearVel(body1) nx# = dVectorX#() ny# = dVectorY#() nz# = dVectorZ#() vel1# = Sqr#( nx*nx + ny*ny + nz*nz ) dBodyGetLinearVel(body2) nx# = dVectorX#() ny# = dVectorY#() nz# = dVectorZ#() vel2# = Sqr#( nx*nx + ny*ny + nz*nz ) deltaVelocity# = Abs(vel1# - vel2#) But this contains two SQR's which I'm obviously not happy with since it will cost me serious FPS when done on a couple dozen entities per frame.. Any other ideas? Being able to measure the force would also be a good way to determin the volume for a collision-soundeffect... ?!? |
| ||
| dGeom1CollisionsDEPTH is not the way to go either I believe, so.... any suggestions? Yep, dGeom1CollisionDepth() and dGeom2CollisionDepth() The higher the depth, the harder the impact. ;) |
| ||
| err....hookay... Is this like a cheeky workaround or actually 'The Way' to do it? "inter-penetrating depth" (shutup Beavis, huh huh) is more an effect of the simulator's ""inaccuracy"", isn't it?!? Since 'theoretically' body's should NEVER penetrate - since they're 'solids'. ?! For example, should I increase the substeps of the simulator, shouldn't this inaccuracy decrease?? Anyway, i'll have a go at it. cheers viper! |
| ||
| Right, I've some some quick tests and I think I'm right in what I guessed in my previous post.. My tests weren't very scientific - but I think it's safe to say that the value returned by CollisionDepth() also heavily depends on what type of shapes are colliding. For example: a Box colliding with a Cylinder will return a different value (at the same speed of impact) when a Box collides with another Box shape! Also, the fact that dWorldSetContactSurfaceLayer() will DRAMATICALLY affect the scale of the value returned by dGeom1CollisionDepth() [by a factor 10 or 100] - leads me to believe that using that function is not a safe or reliable way to check the force of a collision. Especially to ensure the same effects on computers with different specs.. any other idea's or suggestions?! thanks, Danny |
| ||
| This may be of some interest Danny, Check this thread: http://www.blitzmax.com/Community/posts.php?topic=53490 Breakable joints and these functions: dJointFeedbackEnable(joint) dJointFeedbackDisable(joint) dJointFeedbackIsEnabled(joint) dJointSetFeedback(joint,feedback) dJointGetFeedbackForce1(joint) dJointGetFeedbackTorque1(joint) dJointGetFeedbackForce2(joint) dJointGetFeedbackTorque2(joint) |
| ||
| Thanks wayne, Even though me eyes are bleeding reading that thread again I did pick up a thing or two ;) But I'm looking to be able to measure/know the force of impact when two bodies collide (note both could be moving). But I think I've sort of figured it out now. Back to the old F=M*A (force equals mass times acceleration). So; At the time of collision, I get their linearVelocity ('A') and know their Mass ('M') and thus can get the force ('F') of each body. By the subtracting them I get the difference between the two bodies - and that amount gives the 'amount' of impact of the collision. Correct no??? (I'm too old for this sort of math's ;) The only bummer here is that to obtain both velocities I'll need to do two SQR's (cause velocity is given as a vector, and I need it's magnitude) so when 10 objects are hugging each other (...) I'm afraid it might come at a cost.... :/ d. |
| ||
| I don't know of any other way to do it on a single body, but collision depth should be plenty accurate for returning collision forces to filter out the minor 'bumps'. You just need to scale the depth values accordingly. Of course, if you're going to change the surface layer depth then the entire simulation will change too, not just depth values. The amount objects penetrate each other is incredibly small and it's normal behaviour, it depends on the mass, speed and the properties of the body (soft/hard etc). Adjusting the time stepping will result in higher accuracy which could affect the depth results, but again you just need to scale them as required. |
| ||
| I used somthing similar in eariler version of JV ODE. Doing ten sqrt are not going to hurt at all. 8) If you outline what it is your hoping to do we can help, and forgive me if I missed it in and earlier post. I only had time for the following bit. (Hi Vip3r , great to see you). I think your on the right track Dan. Here is a code fragment that may help, or not. |
| ||
| Thanks wayne, Yes that's what it comes down to, similar to the break joints idea. 10 Sqrs is no problem, but I've also got pathfinding and real-time vertexlighting and some other things going on at the same time, so I've already had to make some 'load balancing systems' on each of those things to prevent sqr's killing my game! :) It's funny how that 1 single sqr function has always been a thorn in the eye for as long as I've been programming :) I was hoping some internal ODE function could give me the same result and expecting since that was done in C++ it would be more effecient than using my own code... I would like to know the impact force in order to do things like: - Have a ragdoll (litterally) lose an arm when his arm gets hit with a great force > x.. - Have a ragdoll NOT lose his arm when the force is NOT big enough, and simply get some damage.. - Create sound effects based on objects falling or bumping into each other.. - Create particle effects when certain objects collide at a certain force or more.. - break/explode objects if they fall or are hit with a certain force. That sort of thing :) But I think the above should work, so I'm gonna do some tests and think this will work - and stay reliable on different systems (ie. fast/faster computers)... @Viper, you're right in what you say, but I don't know enough about the simulator and how it behaves on different computer specs in such a way that the values returns are within a constant range. For example, should I decide at some point to tweak my simulator, then ALL these 'penetration depth' values would chance as well! I need something that works on a constant scale so that a force of '5' or '25' is the same on every system in similar situations - if you know what I mean. Thanks both! |
| ||
| How's it going Wayne, good to see you :) @Danny: As long as the different spec machines can run your simulation at full design speed, there will be no differences in the physics regardless of depth values etc. I would use Joint Feedback for the following in your list: - Have a ragdoll lose an arm with a great force > x - Have a ragdoll NOT lose his arm when the force is NOT big enough - break/explode objects if they fall or are hit with a certain force (when jointed) You can try collision depth (or sudden velocity changes as you are now) for these: - Create sound effects based on objects falling or bumping into each other - Create particle effects when certain objects collide at a certain force or more - break/explode objects if they fall or are hit with a certain force (when singular) Collision depth would be much faster if it's suitable ;) |
| ||
| Dan, In case you missed this demo posted from and eariler thread I'll repeat it here. Breakable joints I cleaned up the code some, added comments. Features dbodyGetForce, dbodyGetTorque, and timer based physics, mouse look, and rendering. This should run at the same speed on most machines. As always many ways to accomplish these things. |
| ||
| Thanks viper, I'll have a deeper look at playing with the collision depth. @ Wayne, Yes i've played a lot (like, REALLY a LOT! :)) with those breakable joints! Simple but good fun! d. |
| ||
| hi! i just wanted to know how to weld to physic meshes...  ^^ i have seen it in kODE, 4 legs added to the table. this is getting very close to polygon-to-poylgon physics. but how to do that? i tried to add a new geom to a body, but it didn't work :(... |
| ||
| @Devils Child: Not sure if I understand your question... but have you tried TriMesh? QUESTION REGARDING ODE COLLISIONS: I tried dGeomCollisionGeom, but there's no function for that? I also checked depth and collision position... but no luck. Q) Is there a way to get the X/Y/Z of a collision point (so I could throw out some particles)? And how can I find out how big impact it was (so I could play sound and adjust the volume accordingly?) |
| ||
| no, trimeshes are static! i mean rigid bodies! i tried to add two geoms to a body, but only the last one was acting like a physical mesh... |
| ||
| @Devils Child: You use Geom Transforms, included with JV-ODE are 3 demos showing how to use this feature. I tried dGeomCollisionGeom, but there's no function for that? ? dGeom1CollisionGeom() and dGeom2CollisionGeom() Check the 'Unique JV-ODE Functions > Collision Functions' section of the JV-ODE Function Reference doc. The 'CarDemo-DetailedC' demo shows them in use. Q) Is there a way to get the X/Y/Z of a collision point (so I could throw out some particles)? And how can I find out how big impact it was (so I could play sound and adjust the volume accordingly?) See above ^ dGeom1CollisionX() ..Y() ..Z() and dGeom2CollisionX() ..Y() ..Z() |
| ||
| sry, but i am still using the 0.5 beta because the lastest version above gets out of demo time after a minute. i have commands like that: |
| ||
| sry, but i am still using the 0.5 beta because the lastest version above gets out of demo time after a minute. If you want support for BlitzODE I would suggest you request it from the author of BlitzODE. The JV-ODE threads are NOT for general ODE support for folks who have no interest in JV-ODE. |
| ||
| but isn't there any jv-ode version which has no time limit?? |
| ||
| Yes, the full version of JV-ODE. Check the 'Readme.txt' in the docs folder of the demo version. |
| ||
| well, since i am programming an open source physic engine based on blitzODE i cannot use jv-ode because it couldn't be open source any longer.... thank you anyway :) bye |
| ||
| THREAD 7 IS ABOUT TO CLOSE Please continue on the new thread located here Thanks :) |
   |