JV-ODE Physics Thread 3
Blitz3D Forums/Blitz3D Userlibs/JV-ODE Physics Thread 3
| ||
| The JV-ODE user library contains almost all of the ODE functions wrapped inside a DLL. The library can be used in any programming language that supports DLL's, including Blitz3D and BlitzPlus. The functions have been adapted to use euler angles (the same coordinate system as Blitz3D), however functions for accessing quaternion angles are also included. The download contains all of the necessary files to get you started, including some simple demos showing various ODE objects and TriMesh collisions. To view more information and screenshots click here. Options are now available to purchase the wrapper using either PayPal or Share*it. The restricted demo version is now available for download here (222KB) Have Fun :) Previous JV-ODE Threads: 1 2 JV-ODE Player Factory Forum Useful Links: ODE.org Website - ODE User Guide (PDF) - ODE User Guide (HTML) - ODE Archives |
| ||
| JV-ODE Version 1.04 Released Please check your inbox :) The new update features many new improvements including: New optimized DLL Sphere>TriMesh collision improved Cube>TriMesh collision improved CCylinder>TriMesh collision improved QuickStep performance improved Accurate dInfinity value New RagDoll demo Version 1.04 is built using the brand new stable ODE CVS updates (released 2 days ago) |
| ||
| Many thanks, for this and the Trimesh() bounce thing. As advice to anyone else, I've found the source of my recent woes. I was testing the restitution and finding geometries with Restitution of 0.0 were colliding and still bouncing a little. This I took to mean the restitution wasn't being set or used correctly. I tried the demos and couldn't recreate the problem, except in the Trimesh demo. Setting the Trimesh to zero bounce still had bouncing bojects. As VIP3R points out, this didn't have dContactBounce set as the contact mode. So the problem was my code somehow. LOTS of investigation later (I hate, I just HATE debugging :( ), I finally found the one thing different between my system that didn't work and the demos that did, was the dWorldSetERP() value. I had raised this to 0.5 earlier in the engine build during experiments. Returning it to the default value of 0.2, collisions between geometry of 0.0 restitution are virtually dead stops as they should be. The take home advice - the ERP value affects after collision movement and if your objects aren't responding as they should, reacting when they shouldn't, don't overlook the global error rates. Obvious really, but when you're new to a library and don't know confidently if you're implementing it right, it's more likely to look for something you're doing wrong in assigning values at the object creation level than those obscure parameters you poked around with earlier and forget about! |
| ||
| Please can I have a demo of 30 stacked cubes? Thank you |
| ||
| No problem Slenkar, here is a demo showing 30 stacked cubes. It's quite tricky to keep them stable, but I would imagine this would reflect reality. To improve stability, try reducing the dWorldQuickStep(World,0.05) value. Let me know if you need further assistance ;) |
| ||
| excellent thank you |
| ||
| Here's a pyramid: |
| ||
| You're welcome Slenkar ;) Cool pyramid demo Wayne, how are you finding the new update so far? |
| ||
| ** HIGH PERFORMANCE Version of Pyramid Demo ** |
| ||
| The new UPDATE makes the wrapper worth every penny spent on it! Two words come to mind, "it works". I love this wrapper man because it's clean, fast, and followes the ODE documentation. The new commands add control that normally would be reserved for C programmers. Keep up the good work VIP3R. |
| ||
| I second that. Although I've had virtually no time to play yet, the little I've played with has been just incredible. Finally, anyone can do cool car physics and have nice things to bounce around and crash into ... thank you so much for opening this new world, VIP3R. It rocks! |
| ||
| This rocks!! However- Cylinders still seem to jutter around and get flung off- Thats the oly issue i see :) Other than that, Greeeat :D |
| ||
| thanks viper |
| ||
| Well it was real hard work but it was definitely worth it. Thanks for your kind words everyone, it's very much appreciated :) Thanks also for all of the emails of support I've received over the last few days, sorry I couldn't reply to all of them individually. I'm really looking forward to seeing all of your projects. Cheers :) @Cygnus: Is that standard cylinders or capped cylinders? Did you add mass to them? Have you set the mass direction correctly? Lots of things can cause those jitters, let me know and I'll take a look at it for you ;) |
| ||
| A feature request : cold you provide a different way of handling contact bounce qualities between geometries? The existing mean average of two values isn't accurate. eg. Create surface of low bounce (marble) dGeomContactSetBounce(obj\geom,0.2) Create surface of very high bounce (bouncy ball) dGeomContactSetBounce(obj\geom,0.95) If you've ever bounced a really bouncy ball on a hard marble surface, it bounces very high, but in the ODE wrapper the average = 0.575 is only a moderate bounce. Create a bouncy ball of bounciness 1.8 and it bounces well on the marble, but bounces to much off another bouncy ball. Could you provide an alternative maybe where contact bounce value is the maximum between the two surfaces? That might make a better approximation. |
| ||
| I agree, I think that would be better too. So you want the option of both of these... TotalBounce=(Geom1Bounce+Geom2Bounce)/2 <<< Averaged TotalBounce=*Geom1Bounce or *Geom2Bounce <<< Maximum [edit] *whichever is higher (sorry misunderstood your request) No problem, I'll put it in my todo for the next update ;) |
| ||
| I wouldn't use the added value, as 0.9 + 0.9=1.8, where objects would bounce higher than each last bounce! I'd use... TotalBounce=Max(Geom1Bounce,Geom2Bounce) Many thanks for your efforts and the quick updates! |
| ||
| Here's a little game called Pyramid of Destruction. -Enjoy |
| ||
| Pyramid of Destruction II Add your own sounds for that special touch. Select different planets and watch gravity at work. Other features include: Mouse Look, WSAD and arrow keys, Pyramid reconstruction, Mouse pushing, spacebar shooting. -enjoy |
| ||
| Hehe, very nice. And very good stability for the stack. Congratulations! |
| ||
| VERY nice. I did similar to this in ODE, but the stability was fecked, so i converted over to Toka. :) |
| ||
| Faster, better, stronger Runs Physics 66 times a second. -enjoy |
| ||
| I'm off to play with spaces, terrains, and jeeps next. Hold on tight while we explore a small multiplayer demolition game. |
| ||
| several ode function declarations are not consistant. dWorldSetERP(sim,erp#):"odeWorldSetERP@8" dWorldGetERP#(sim):"odeWorldGetERP@4" should be: dWorldSetERP(world,erp#):"odeWorldSetERP@8" dWorldGetERP#(world):"odeWorldGetERP@4" 8) |
| ||
| Already fixed those in the new V1.05 update to be released very shortly... I can't wait to try the multiplayer demolition game btw :) [edit] I hope your 'several' refers to 'two' because I haven't spotted any more ;) |
| ||
| JV-ODE Version 1.05 Released Please check your inbox :) As requested by Shifty Geezer, new functions have been added to give more control over the contact surface collision responses. dSetInternalContactSurfaceMode(mode) - set contact surface mode ( mean / max ) dGetInternalContactSurfaceMode%() - get contact surface mode ( 0 = mean 1 = max ) There are two modes: 0 = mean - default (the same mode as in V1.04) This mode adds the contact surface values for the two colliding geoms and averages the total value. For example: TotalBounce = (Geom1Bounce + Geom2Bounce) / 2 1 = max This mode uses the highest geom contact surface value only and discards the lower value. For example: TotalBounce = *Geom1Bounce or *Geom2Bounce (* = whichever is higher) If both values are equal, the value from Geom 1 is used. Version 1.05 also includes an improved ragdoll demo and a bugfix. :) |
| ||
| Lot of updates in short time! Keep the good work Viper! |
| ||
| how do you create a 'player' e.g. a rigid body that you control, 1.stops suddenly when no keys are pressed 2.bumps into things with no inertia and doesnt push objects around but has sliding collision with objects |
| ||
| Cheers KuRiX ;) @Slenkar: create an ODE sphere, then apply force with 'dBodyAddForce()' when keys are pressed. To stop the sphere suddenly, apply an opposite force on the sphere. For the second item, create the other objects with a much higher mass than the sphere and with zero geom friction. |
| ||
| thanks, ill try that out EDIT-it accelerates the player forwards, instead of moving forward at a certain rate Is there a way to limit the speed? |
| ||
| @Slenkar: Have you tried Psychic Parrots demo? It uses a slightly different method which also limits the speed of the sphere. Here it is... |
| ||
| Woohoo! Another update! Thanks, Vip3r. I'm totally pleased with JV-ODE and I totally recommend it to anyone with Blitz .. it's just an essential thing to have in the blitz toolkit IMO, even if it's just for making things roll around in a cool way! |
| ||
| thanks,I ordered the wrapper by paypal yesterday so maybe Ill get to try out a few alterations to the code with relative-forces and a cube which i was having success with in Tokamak except for the acceleration issue. |
| ||
| You're welcome PP and thanks :) No problem Slenkar, you should receive your wrapper as soon as payment is confirmed. Thanks for your support ;) |
| ||
| Many thanks VIP3R. The new system works great - my bouncy balls bounce! |
| ||
| Got the wrapper now thanks, Can I have a demo of getting collision info for a ray please? I need to use a ray to pick an ODE geom and apply a force in the direction of the ray. The ragdoll demo used blitz picking commands, in games the ragdolls dont have blitz entities at every joint (I dont think you can pick bones, and they are too small anyway) so those commands cant be used. I tried modifying the ragdoll demo to use collision with an ODE ray but I had no luck. Also is there a master list of all the commands anywhere? I have the official ODE manual but I need the blitz-equivalents. e.g. dgeomcollisiony#() That command is not in the official ODE manual but it is a command that can be used in blitz.I need the entire list - thank you. |
| ||
| I'll look into the ray thing for you. The 'JV-ODE.decls' file lists all of the non-ODE commands towards the base and the 'Version History.txt' file also contains some more info for some of these commands. There isn't a manual for the non-ODE commands yet, but most are self explanatory. Some of the non-ODE commands are shown in the demos too, for example the use of dGeomCollisionY#() is shown in the 'CarDemo-DetailedC.bb' demo. |
| ||
| thanks I managed to get all the commands, has anyone managed to construct a ragdoll based on an animated mesh, ????? I think the position of the joints can be found with the position of the bones found with findchild easily enough but then somehow you have to place the rigid bodies between the joints (at global cordinates) blitz can only find the positions of the joints, so I end up putting the geoms and joints in the same place. So the ragdoll ends up looking distorted and moves stiffly. |
| ||
| Hello, I've just got your wrapper and I'm testing it out, nice work. I'm trying to modify the demos to have thin cylinders (like coins) but I'm having some problems, that I'm guessing is to do with ODE itself rather than the Blitz interface. One, if I allow them to drop "straight", when two of them hit each other both of them seem to completely disappear. Why is this? If I put a bit of torque on them when they are created this doesn't happen. But when there is a pile of them, they seem to constantly squish up and down a bit oddly, is there a way to make them a bit "harder"? Finally, I tried to set AutoDisableFlag so they would disable, but it didn't seem to work - I tried turning off the bit of torque and it did start to work (but the disappearing problem returned). Even though they seemed to be lying flat, they would never disable, once I re-added the torque. I'd really appreciate any help with this :P |
| ||
| One, if I allow them to drop "straight", when two of them hit each other both of them seem to completely disappear. Why is this? If I put a bit of torque on them when they are created this doesn't happen. This is a common problem with standard cylinders in ODE. The torque fix is news to me though, good find :) But when there is a pile of them, they seem to constantly squish up and down a bit oddly, is there a way to make them a bit "harder"? Try altering the Geom ERP and CFM values with these... dGeomContactSetSoftERP(geom,erp#) dGeomContactSetSoftCFM(geom,cfm#) or alter the world (global) settings with these... dWorldSetERP(world,erp#) dWorldSetCFM(world,cfm#) Also, try adding mass and density. If you're still stuggling, can you post your code (or send via email) so that I can take a look for you. |
| ||
| @Slenkar: Some of the Ray functions return a vector, maybe that's what you're having problems with. All the Ray functions behave like line pick etc in Blitz with the exception of dGeomRayGetStart(ray) and dGeomRayGetDir(ray) which fill an internal vector. To use these two commands you would do something like this... dGeomRayGetStart(ray) raystartx#=dVectorX() raystarty#=dVectorY() raystartz#=dVectorZ() dGeomRayGetDir(ray) raydirx#=dVectorX() raydiry#=dVectorY() raydirz#=dVectorZ() If you still have problems, post your code (or send it via email) and I'll take a look for you. |
| ||
| denzilquixode : Cylinders are bust! That's the long and short of it. Getting coins to work seems a total no-no. Landing on their round sides isn't too bad, but the flat ends of cylinders are erratic and unpredictable. The only possible solution is a capped cylinder. Embedded a box or three inside the cylinder to function as the flat edges for collisions, while the round surface will still roll. But it's not a perfect solution. |
| ||
| has anyone managed to construct a ragdoll based on an animated mesh, ????? This uses the JV-ODE wrapper : http://webzoom.freewebs.com/smiff/blitz/rged2.wmv http://webzoom.freewebs.com/smiff/blitz/rged3.wmv http://webzoom.freewebs.com/smiff/blitz/robot1.wmv |
| ||
| Can anyone provide an example of a hinge2 joint? I'm trying to create a ragdoll, based on VIP3R's demo code. I'm replacing the single axis hing of the arms with hinge2, to providea full range of side and forwards/backwards motion, where the hinge arm is limited in how much it can raise up. Howver, setting the parameters dJointSetHinge2Axis1(RDJoint(rd,3),1,0,0) dJointSetHinge2Axis2(RDJoint(rd,3),0,0,1) dJointSetHinge2Anchor(RDJoint(rd,3),xp+1,yp-0.75,zp) dJointSetHinge2Param(RDJoint(rd,3),dParamLoStop,-0.50) dJointSetHinge2Param(RDJoint(rd,3),dParamHiStop,0.50) dJointSetHinge2Param(RDJoint(rd,3),dParamLoStop2,-0.50) dJointSetHinge2Param(RDJoint(rd,3),dParamHiStop2,0.50) is variations of, I can't get the arm to rotate +/- 180 degrees forwards and backwards (z axis I think) and +/- 90 degrees from horizontally outstraight. Alternatively a ball and socket joint that could be locked within limits would be ideal, but it appears ball joints are 360 degrees in all directions. |
| ||
| Thanks for your help on cylinders - I thought it would be like that, cylinders are obviously tricky bastards... Right now I'm trying to get the torque of a body, how do I do that? How do I use what dBodyGetTorque returns? |
| ||
| thanks for the help Viper Ill check that out. Hey Smiff, are we able to get source code with pacemaker? (for ragdoll creation) give me a hint, did you use Dcreategeomtransform??? Believe it or not, I am trying to create the ragdoll for the exact same zombie mesh that was in the video! EDIT- I solved the problem by changing the position of the joints to the correct places, i was placing them in the position of the current bone instead of the next bone- which now gives very realistic looking behaviour |
| ||
| @Shifty Geezer: The dParamLoStop2 and dParamHiStop2 constants aren't present in the include file, so unless you've set them elsewhere they won't work properly. Here are the correct constants for them... dParamLoStop2=256 dParamHiStop2=257 I'll add these to the include file when a new wrapper version is released. @denzilquixode: dBodyGetTorque() fills an internal vector which you can get using dVectorX(), dVectorY() and dVectorZ(). To use it, first call the get torque function, then return the values with the vector functions. Like this... dBodyGetTorque(body) torquex#=dVectorX() torquey#=dVectorY() torquez#=dVectorZ() |
| ||
| Thanks VIP3R. That's sorted it. Oh, and for those who don't know (like it took me a while to figure!) the degree values for constraints are in radians, not Blitz's standard cartesian degrees. Here's code for some wigglier ragdolls that can replace the RagDoll() function in the JV-ODE demo. Morw advice please VIP3R! How can Isave the current postion/states of joints? I've got my 'editor' where I can add objects to a scene and save the data to a file, and I can add a ragdoll. But I can't figure how to run the simulation and pause it halfway and sav the ragdoll data. I'm think say add a RagDoll and a chair, and set up the editor to have the RagDoll fall ontot the chair so it's in a sitting position. I then want to save the positon of all the joints. There seems to be no dGetJointPosition() function. The only function that looks like it might be suitable is dGetJointData(), but what does the data hold and how is it structured? |
| ||
| But I can't figure how to run the simulation and pause it halfway and sav the ragdoll data. To pause the simulation, do not call these... dSpaceCollide(Space,World,ContactGroup) dWorldQuickStep(World,stepsize) dJointGroupEmpty(ContactGroup) ...in your main loop. There seems to be no dGetJointPosition() function. To get the coords of a Hinge2 joint you would use the dJointGetHingeAnchor2(joint) function. Any ODE function mentioned in the docs that returns a 'dVector3 result' will fill an internal vector in JV-ODE. To use it, first call the get joint function then return the vector values, like so... dJointGetHingeAnchor2(joint) xposition#=dVectorX() yposition#=dVectorY() zposition#=dVectorZ() I'm planning to document the vector and non-ODE functions, so hopefully they'll be a lot clearer for everyone ;) |
| ||
| Yeah, for pausing what I do (in the editor) is disable all bodies, but then I can move them in realtime ;) And of course, it's the anchor that defines a joint's position. I'm on the case! |
| ||
| to VIP3R : i have bought this product,how to remove text JV-ODE V1.05 at left top of the screen?does the consumer allowed to do it?how? |
| ||
| Change the text in the demo program from: Text 0,0,"JV-ODE Version "+dGetVersion() to this: Text 0,0,"3ch0 ODE Eggstravaganza" |
| ||
| Hey Smiff, are we able to get source code with pacemaker? (for ragdoll creation) Yes - it generates the source code to recreate the ragdoll. |
| ||
| How can we make jointed objects respond correctly with bounces? I've got a doll made up of boxes, made of 'rubber', and I drop it onto a boxe made of 'rubber'. Rubber has a restituion of 0.85. If I drop a rubber box onto another rubber box (or any other surface thanks to Bounce=max!) it bounces high. However my ragdoll doesn't. I set the bounce for each joint to the same as the bounce of the material the doll is made of, so in this case each joint has bounce=0.85, but it's response is very weak. If I set rubber's restitution to 1.85, the doll responds better but of course all normal bounces are crazy. I've just tried setting joint bounce to material bounce * 2 (1.7 in this case) and it looks better. I tried bounce * 3 and the object explodes on impact. It looks as though the individual boxes connected by a joint have no bounce of their own, as though adding a joint set a boxes bounce to 0. Even just two boxes connected with a hinge and dropped don't bounce, even though they should respond very similar to a single box of the same material. |
| ||
| Could you post some example code showing the problem, I've just tried connecting two cubes with a hinge joint and the bounce works fine here. |
| ||
| Here's a modifed Ragdoll demo. At this first test it seems simple joined objects work okay. Not sure why my program seemed otherwise - something to look into (maybe to do with mass?). If you comment out all the object creation and joint creation for all limbs, leaving only head, upper and lower bodies, it bounces as high as the cube. As is, when the doll hits, though the bulk of the body hits and looking at it you'd expect a big bounce, the doll lands dead. Up the torque so it lands on it's head and the bounce is still just as limited. |
| ||
| Memory access violation?? hmm |
| ||
| Hi I've just purchased it and must say congrats on a really nice piece of work. I've got a ball rolling around my trimesh but it doesn't collide with all the objects on that mesh. I'm using 3ds Max, created a plane with plenty of polys and then put lots of trees on it. When I export it using the B3DPipeline it looks correct but the ball only collides with the original plane and not the trees. Any ideas? Thanks scott |
| ||
| How are you loading the trimesh? with loadmesh or loadanimmesh? |
| ||
| thanks for the reply. I'm using loadmesh. demomesh=LoadMesh("media\test.b3d") trimesh=CreateTriMesh(Space,demomesh) dGeomSetRotation(trimesh,0,0,0) dGeomSetPosition(trimesh,0,0,0) I've been playing around a little more and it's gets more odd. One mesh I use kinda works (see above) but when I try another I just fall straight through. It's the exact same code just a different mesh. I've stepped into the createtrimesh function and it's getting the correct number of polys and vertices. oooh. There's a thought. Is there a limit on vertex\poly count for a trimesh? |
| ||
| For what i have tested i have seen no limit for that. The only limitation i have seen is the size of the triangles. Too small Triangles gives you lot of edge collisions, so bouncy results. Too Big triangles gives you penetration through them. The only problem you could have is the normals direction, but this depends on the trimesh you are using. Try applying the normal modifier, and if this doesn't work try exporting to 3ds then importing again and then exporting to b3d. Cheers, KuRi. P.D: You don't need to rotate and position the trimesh to 0,0,0. |
| ||
| Thanks for the help there KuRiX, much appreciated :) @luggage: If you're still having difficulty with your mesh, feel free to email me your code with the bad mesh and I'll take a look at the problem for you (see my profile for the email address). It could possibly be a normals problem as KuRiX pointed out, have you tried UpdateNormals() on your mesh before converting it to a TriMesh? |
| ||
| Hello, it is possible to achieve this with JV-ODE : http://www.mathematik.uni-bielefeld.de/~pserocka/ODE-Plane2D/Plane2D.README I need a full featured single surface physic engine for a "2D-like" simulation. My simulation must work with Trimesh polygons like Soldat (http://www.soldat.prv.pl/) but in a top down way. Thanks ;) |
| ||
| Hi Armitage, I would be very reluctant to add this kind of patch I'm afraid. The reason being that I would need to manually 'hack' it into the ODE library, possibly affecting the whole physics simulation. The Plane2D patch may not even be compatible with the current version of ODE either, as it's based on version 0.39 of the ODE source (JV-ODE is based on version 0.5). As the readme you've posted suggests, there are other ways of doing this but I don't know how successful they would be. You would need to experiment with those and see what kind of results you get (please let me know if you do this). My highest priority is to keep JV-ODE as close to the 'approved' stable source releases of ODE as possible. Doing otherwise may cause complete havok :) |
| ||
| Doing otherwise may cause complete havok :) That may not be a bad thing - Havoc is a pretty good physics system ;) Just want to say that the JV-ODE is the best Blitz related purchase that I have made. Recommend it to anyone looking for a stable, flexible and easy to use Physics library. |
| ||
| Wow thanks Smiff, I really appreciate that :) Yeh, havok is an awesome physics system. The license cost isn't so awesome though at $65,000 to $75,000 per title... yikes! |
| ||
| Yeah. I agree with smiff. This library has bought life to a dying project (even through a rewrite)- Hell, I liked it so much, I bought it twice! (Once without even knowing!!!!! ;) ) |
| ||
| This lib is great, making very easy work of part of my latest project i was dreading! Cygnus: yeah yeah, make fun of me, thinking i dont read these boards :P I didnt read the receipt address! :P |
| ||
| Lol, actually, i never meant it to make fun out of you ^.^ I can't wait to see how it works in your latest project- You know how cool i think it is. ^.^ |
| ||
| I'm having a little trouble saving the current state of my skeleton. My ragdoll's joint positions are successfully saved to an array, so I can save the current state of my ragdoll and revert to it, with one exception. The angle of the joints isn't saved, so all the limbs (boxes) are NOT rotated to fit the alignment of the different joints. The docs mention dGetJointHingeAngle() which returns the current value correctly, but there's some problems. 1) How can I set the rotation of the joint on creation? 2) There is no dGetJointHinge2Angle2() function. How can I record both angles for a Hinge2 joint? |
| ||
| Hmm, I'm not sure that's the correct way to do it tbh. When you recreate your skeleton, you need to restore the position and rotation of all the bodies that make up the skeleton using your saved information. Then you use the joint attach functions to connect them all together using the saved joint position information. When the joints are attached the angles should automatically be calculated from the position of the joint to the position/rotation of the bodies. I think Smiff has done some work in this area, maybe he knows the correct procedure for this? |
| ||
| Maybe yes, I need to restore the rotation of the limb components and the joints are working okay. Only I'm worried about the manual's statement that the angle is set to 0 based on the current position of objects. Let's say a worm is made of 5 spheres, each with a hinge2 joint. On creation the worm is vertical in the air, with all joints at 0 degrees. The worm is dropped onto a table where it half hangs over the edge. Joint two is now 90 degrees... Start position End position Saving the data to an array, we can recreate the positon of the worm by positioning the spheres on and by the table, and create joints at the appropriate places between them. BUT when we create joint 2, it's actually at 90 degrees, but the manual suggests this position will be set as 0 degrees. Hmmm. Think I'll try a test case with the Rope demo and see what happens... |
| ||
| Ah yes, I see what you mean. Joint 2 would set the 90 degree position as zero degrees in your example. Ok what about this (using your example above), create the worm in it's starting position (but NOT in the saved location - maybe high up in the air?). Then once the joints have been attached, set the position/rotation of the bodies to the saved location (the end position). |
| ||
| What VIP3R says is correct - What I do is to have a reference position that is always used to create the joints - once the joints are attached in the reference position ensuring that joint limit angles are correct,you can then rotate/postion the bodies to the desired position with dbodySetRotation/dbodySetPosition. As long as the 'desired' position is not beyond the joint limits it should work fine. If the desired position is beyond a joints limit then the joint will snap to whatever its limit value is. The process I use is: Create rag-doll using the reference values ( this is usually frame 0 in an animated model. Attach joints (except those attached to world)- this makes sure my limits are correct. Position and Rotate all geoms/bodies to current position. Attach joints fixed to world (if any). |
| ||
| Ugh! Thanks for the suggestion. Not an easy solution for my setup. Have to rethink how I store and build the scenes. Still, at least I have a solution ;) |
| ||
| Hi guys, I need a hand with this one. I'm working with the Trimesh car demo and want to use more than one Trimesh. Should I be creating the SPACE, and then creating a new space for each object including trimeshes within that space? The demo works fine if I use just one trimesh, but really slows down with more than one. Just wondering how this should be done. Maybe I'm doing something wrong, or need to tell ode not to compare the trimeshes. code attached All help appreciated, thanks. |
| ||
| Hi Wayne, Do your TriMeshes overlap each other or are they completely separate? (I can't tell without the media) It does sound like they overlap, as this would cause severe slowdown. The reason is because lots of contacts are generated between each TriMesh and it takes a long time for ODE to process them each step. Create a top level space (Space), then place ALL of the TriMeshes into their own sub-space (TriSpace). Then make sure to disable the internal collide mode with... dSetInternalSpaceCollideMode(0) When you've done this, all objects in any other space will collide with the TriMeshes, but the TriMeshes will not collide with each other (meaning no contacts are generated each step) which should cure any slowdown. I've had four TriMeshes in the TriMesh Car Demo running simultaneously without any speed hit whatsoever using this method. Also, for best results put the Plane (when used) into the same space as the TriMeshes, as that can also generate lots of contacts. In the TriMesh Car Demos, there is a very small gap between the TriMesh and the plane (your TriMeshes may be in contact with it). |
| ||
| Hi Vip3r, thanks for the reply. I removed the plane so thats out of the equation. I'll go test that. |
| ||
| Looks like it's working sweet, I'll post some stuff after I check it out some more to be sure. It's wicked fast! |
| ||
| Can you offer a brief example of how to create a top level space and subspaces? I've got inanimate scenery objects, TriMeshes and primitives, that needn't waste time colliding with themselves, so chucking these into their own space would save processor cycles. I thought the latest build had a multiple space demo, but I can't find it in my JV-ODE folder. |
| ||
| @Wayne: Nice one ;) Here you go Shifty Geezer, the CarDemo-MultipleSpace.bb example is still included in the library... |
| ||
| Okay, I did have it afterall :p So dSetInternalSpaceCollideMode() enables/disables all collisions for objects inside that space? And spaces are hierarchical? So I could create WorldSpace, PropSpace(worldspace) and ActorsSpace(worldspace). PropSpace and ActorsSpace would be subspaces of WorldSpace. Everything in worldspace, including everything in PropSpace and ActorsSpace, can collide. Let's say I create a dozen boxes in PropSpace and a dozen spheres in ActorsSpace, these could all bash into each other. Now to disable the boxes from colliding with each other, but still collide with spheres and allow spheres to collide with spheres, I can use dSetInternalSpaceCollideMode(). But how do I specify which spaces this should apply to? Or does it apply to ALL subspaces of the top-level space, so it would disable all cube<>cube and sphere<>sphere collisions? While we're at it, looking for clues in the .decls file, what do... dSetInternalContactSurfaceMode(mode):"odeSetInternalContactSurfaceMode@4" and dGetInternalContactSurfaceMode%():"odeGetInternalContactSurfaceMode@0" do? Also, does dSpaceAdd(space,geom) duplicate a geom's data into space, or just include in that space along with the geom's creation space, like box=dCreateBox(Space) creates the box geom in Space, would dSpaceAdd(PropSpace,box) just add collision calculations inside PropSpace? Or does that move box into PropSpace so it's collisions internal to PropSpace can be disabled? ODE Spaces - the final frontier :D |
| ||
| So dSetInternalSpaceCollideMode() enables/disables all collisions for objects inside that space? And spaces are hierarchical? Yep, internal collide mode only applies to the sub-spaces though (not the top level space). So I could create WorldSpace, PropSpace(worldspace) and ActorsSpace(worldspace). PropSpace and ActorsSpace would be subspaces of WorldSpace. Everything in worldspace, including everything in PropSpace and ActorsSpace, can collide. Let's say I create a dozen boxes in PropSpace and a dozen spheres in ActorsSpace, these could all bash into each other. Yep, the objects within the same sub-spaces will collide with each other unless you disable internal collide mode. Now to disable the boxes from colliding with each other, but still collide with spheres and allow spheres to collide with spheres, I can use dSetInternalSpaceCollideMode(). But how do I specify which spaces this should apply to? Or does it apply to ALL subspaces of the top-level space, so it would disable all cube<>cube and sphere<>sphere collisions? Disabling the internal collide mode will prevent all collisions of objects within the same sub-space. All objects in the top level space will still collide with all sub-space objects. You would specify which objects collide with other objects by the way you design the sub-spaces. The simplest way to think about it is to put all objects that don't need collision detection between each other into the same sub-space. So, you could have all scene objects (terrain, plane, static scenery objects) into a sub-space of space (PropSpace). With collide mode disabled, if you want your actor objects to collide with each other, then you would put them into the top level space (Space). If not then you could create another sub-space for actor objects (ActorSpace). All objects created in the top level space (Space) will collide with the PropSpace objects and the ActorSpace objects. While we're at it, looking for clues in the .decls file, what do... dSetInternalContactSurfaceMode(mode):"odeSetInternalContactSurfaceMode@4" and dGetInternalContactSurfaceMode%():"odeGetInternalContactSurfaceMode@0" Those are the functions you requested, their functionality is described up there ^^ (See the JV-ODE Version 1.05 Released post) Also, does dSpaceAdd(space,geom) duplicate a geom's data into space, or just include in that space along with the geom's creation space, like box=dCreateBox(Space) creates the box geom in Space, would dSpaceAdd(PropSpace,box) just add collision calculations inside PropSpace? Or does that move box into PropSpace so it's collisions internal to PropSpace can be disabled? I think it just adds a copy of the geom to the space (duplication), so you would need to use dSpaceRemove(space,geom) to delete the original if required. |
| ||
| While we're at it, looking for clues in the .decls file, what do... dSetInternalContactSurfaceMode(mode):"odeSetInternalContactSurfaceMode@4" and dGetInternalContactSurfaceMode%():"odeGetInternalContactSurfaceMode@0" Those are the functions you requested, their functionality is described up there ^^ (See the JV-ODE Version 1.05 Released post) Ha ha! Yeah, I've used them already. For some reason I thought they were part of the Space controls, being 'Internal' in name. Thanks for the clarification. I see the top level is for the bulk of objects, with sub-levels for collision optimizations, basically grouping non-colliding objects. Quite an important take-home point for keeping things as fast as possible. |
| ||
| Just made the update to my engine. Very simple to implement and very effective. Note to all ODE users - create static scenery objects inside a sub-space and disable internal collisions!! |
| ||
| Here is the code shell I used to create ODEMARS. It was easy, I created a huge multimesh terrain (64 trimeshes) using T.ED http://www.d-grafix.com/softwareted.html |
| ||
| Hey guys just stumbled across this thread, and tried the demos out, amazing stuff ! :) I take it the wrapper is under constant developent, I am interested in purchasing this lib. Is there documentation for the lib once purchased ? Or does one have to consult the ODE docs ? |
| ||
| Hi Deux, Yes, the wrapper will be developed constantly as the ODE library progresses. I'm working on a doc for the JV-ODE specific functions, but they are simple enough to use without one. The official ODE docs should be used as a guideline. Shifty Geezer is working on some tutorials and if you need any help, just post here and one of the users (or myself) will help you out ;) |
| ||
| thanks for the speedy reply ! I am looking for a viable physics wrapper, and I like what I have seen here, I cannot get tokamak to work (initial setup). Just need to make a decision to buy your wrapper or not :) |
| ||
| There's a demo avialable to try out. For docs I've got my initial tute which includes a basic primitives setup 'engine'. It'll be a while before more docs appear from me though :( The ODE docs provide the glut of info you need. For ODE specifics most been covered here, or just ask. |
| ||
| Thanks :) I would like to ask how one would go about setting up a level ( .x mesh or instance ) ala FPS shooter, so that all objects would react to it using this physics engine. say for instance I have a level more complex than just a cube, a hull I think it is called. I wont bother you with code, would just like to know how possible it is. The demos I have seen have all been basic primitives, which is all very well, would just like to know how complex objects work. |
| ||
| ahh, I take it thats what trimesh is right ? Trying to sift through the threads to find info :) |
| ||
| Yep, you've got it :) You can create a TriMesh from your .x mesh and then spheres, cubes and capped cylinders will interact with it. The full version contains a few TriMesh demos to get you started. |
| ||
| oh man, I really want to buy this now, how far can one get with the "lite" version ? I guess I pretty much got to get it. |
| ||
| well I just bought it !! Cant wait to play around with this now ! |
| ||
| Also add your static scenery into it's own subspace to keep things running top speed (see thread above to explain) |
| ||
| I've just had a mess around and created a primitive 'Pong meets Breakout' in about an hour. It uses my Constructor library that my tute introduced. However, I've found that .pdf is lousy for copy+paste code, so I'll dupe the library here. Save this as 'ODE_Object_Library.bb; And here's the program... I reuse the material names in the ODE_Object_Lib as I couldn't be bothered to change them, but in a proper program you'd obviously spend a little more time documenting and structuring the program. Also note I use an array of objects and store index value to reference different ODE objects. This makes it easy to save and restore level data. I'm sure there's a squillion optimizations and improvements people can make, but it's nice to see how quick and straightforward it is to create a physics based game. There's really no excuse not to include physics in everything!! |
| ||
| saweet ! Gonna give this a bash when i get home. Seeing as all the physics guys are in one place, how important would you think physics is in indie games ? I mean the code above is a perfect example of physics in casual games. Ofcourse FPS is a classic example of where one should use physics. |
| ||
| If you can put it in, do so I say. It adds a dynamic to arcade games, and a sense of reality to all genres. |
| ||
| JV-ODE Version 1.06 Released Please check your inbox :) New functions have been added to get detailed collision information of sub-space geoms when using multiple spaces. The existing detailed collision functions still work the same way and are used for single space simulations. To retrieve detailed collision information for multiple space simulations, use both the existing functions and the new sub-space functions. Here is a modified car demo to demonstrate the new functions in use... New joint parameters have also been added to the include file. Let me know if you have any questions regarding this update. Have fun :) |
| ||
| awsome, thanks Vip3r ! |
| ||
| Another FANTASTIC update Vip3r ... thanks again for all your hard work. |
| ||
| You're welcome :) |
| ||
| Hi all, I'll be including the new JV-ODE docs in the next release, but I wanted to get some feedback from you beforehand if possible... What format would you prefer the JV-ODE docs to be in? Word Document (*.doc) HTML Document (*.html) PDF Document (*.pdf) Please let me know via email, thanks :) |
| ||
| (*.chm) :) or (*.pdf) .Thank`s |
| ||
| Can't do either of those formats tbh, but I might be able to get the doc converted to pdf (hence the pdf option). I'm not buying software to create one doc though, anyone got a chm converter? It might be better to email me with your preferred options, otherwise this thread is going to get a bit clogged up :) |
| ||
| html or pdf please :) |
| ||
| Eyyy :-) So, whats new in the next version? |
| ||
| A minor change in the usage of the dGeomPlaneGetParams(plane) function. Addition of the new JV-ODE specific docs. ;) |
| ||
| Wahey! We're getting our moneys worth! |
| ||
| How can I use collisions when manualling positioning objects? As an example, say I have a cube and a sphere above it. I have my editor that I can click and drag the sphere to position it. With gravity enabled it falls and bounces off the cube. If I turn off gravity and move the sphere down, it penetrats the cube. It's only when a force is applied that the sphere bounces out/'collides'. Can I do a collision test on move and if so, don't move? How would I structure this in code to perform the collision test? |
| ||
| It will penetrate the cube because you're forcing the spheres position even if a collision occurs. The collision detection should still be working though, have you tried the detailed collision functions to check for collision count etc? |
| ||
| No I haven't. I'm not sure how to. Heck, I'm not even sure what those functions even are!! I've looked at the Decls file and spied these likely suspects... dGeomCountCollisions%(geom):"odeGeomCountCollisions@4" dGeomCollisionGeom%(geom,index):"odeGeomCollisionGeom@8" dGeomCollisionX#(geom,index):"odeGeomCollisionX@8" dGeomCollisionY#(geom,index):"odeGeomCollisionY@8" dGeomCollisionZ#(geom,index):"odeGeomCollisionZ@8" dGeomCollisionNX#(geom,index):"odeGeomCollisionNX@8" dGeomCollisionNY#(geom,index):"odeGeomCollisionNY@8" dGeomCollisionNZ#(geom,index):"odeGeomCollisionNZ@8" dGeomCollisionDepth#(geom,index):"odeGeomCollisionDepth@8" My progam loops through all objects each frame positioning the mesh where the ODE_geom is. If the simulation is active I call an advance_simulation() function that's basically this... Function advance_simulation() dSpaceCollide(ODE_space,ODE_world,ODE_contactGroup) dWorldQuickStep(ODE_world,ODE_Resolution#) dJointGroupEmpty(ODE_contactGroup) End Function ...with some rotational dampning thrown in. I'm thinking I need to call dSpaceCollide every frame regardless. then I can use a process... Record object's current position Move object If object collides then move object back where it was Hmmm. This wouldn't be as accurate as ODE's solving as if I move the object fairly quickly it'll pop back where it was, instead of rest up against the surface it's collided with. Would it be possible to have an object press against and correct itself? That is, if a box is moved into another box at an angle, the box being moved rotates to land on the inclined surface?# As you can see I've really got know idea how to tackle the problem. Though I have just suddenly had the quirky idea of using gravity, setting the gravity direction in the direction the object is moved and disabling gravity for all other objects ;) I'll await someone's expert opinion for messing about with my code though. |
| ||
| Take a look at the detailed collisions demo to see some of those functions in action. I'm -nearly- done on the new 'JV-ODE Function Reference' document which will also help explain some of those functions in more detail. It won't be anywhere near tutorial level, but it will give users a better understanding of the JV-ODE specific functions (like the detailed collision stuff). Hopefully that may help with the problem you're having ;) |
| ||
| Anyone had any luck with delta-timing on ODE simulations? I've been using a fixed quickStep of 0.15 and locking the program's main loop to screen refresh. Of course on a slower machine this has a slower frame-rate and the simulation runs in slow motion. I just tried an implmentation where the QuickStep amount is varied based on time since last update, and the movement is both jerky and not as accurate, with a collision penetrations. A simple test of setting QuickStep to 0.13+rnd(0.4) shows collision responses aren't smooth without a constant Quickstep amount. Best I can figure is to set a constant value based on a rough summation of the machine's performance, but i don't know how to best obtain such a metric. Any ideas for keeping simulation rate constant across different spec'd machines? |
| ||
| Multiple timing is the key Shifty. Try separating the screen update timing and the physics step timing instead of using the same timing system for both. That way, the refresh rate will never affect the speed of the physics simulation. I wish I could help more, but I'm still up to my eyeballs writing the docs. Nearly there now though thank the lord, I -hate- writing docs :S |
| ||
| My refresh timing is pretty negligable. The graphics are flat shaded boxes and spheres, 3000 tri's at once on a bad day, 5000 worst day of all, 2 lights and one texture. My code is basically a representation of the physics engine and ODE is the deciding factor. If I chop that bit out I get 60 fps even on a 8 year old PC. Trouble is on slow machines the physics at QuickStep = 0.15 can't be calculated in 1/60th a frame which causes the slow motion. Setting QuickStep=0.25 (or whatever figure I tried) has the slow PCs animation moving at the same speed even at a lower frame rate. It's not the end of the world, and it's not a priority. Good docs are a pain to write I know but oh-so very important! They're more needed than this. But it'd be nice if anyone comes up with a solution (and surely people are writing code to work on slower machines too?) it'd be nice to hear how they've solved this. |
| ||
| Hi Shifty, Post the code and I'll take a look at optimizing. 8) |
| ||
What the ENTIRE progam?!?! Really what I've got is a setup phase, and then a run simulation phase which is nothing more than ODE's update. I hand over to that. At present I use something like...Global ODE_Resolution# = 0.15 While Not KeyHit(1) frame=advance_simulation(frame) For obj.ODE_object=Each ODE_object Update_object(obj) Next UpdateWorld() RenderWorld() Flip Wend Function advance_simulation(t%) ; Advances the simluation, incrementing frame count ; Performs friction calculations ; Disables 'non-existant' objects dSpaceCollide(ODE_space,ODE_world,ODE_contactGroup) ;#Region Apply Rotational Friction For ode.ODE_object=Each ODE_object If ode\body If dBodyGetPositionY(ode\body)<-50.0 dBodyDisable(ode\body) HideEntity ode\mesh HideEntity ode\outline_mesh EndIf If dBodyIsEnabled(ode\body) numjoints=dBodyGetNumJoints(ode\body) If numjoints>0 ; If joined to another body For joints=0 To numjoints-1 ; for all joints attached to body... joint=dBodyGetJoint(ode\body,joints) If dJointGetType(joint)=dJointTypeContact ; If joint type is a collision contact ; Get Angular velocity vector bx#=dBodyGetAngularVelX#(ode\body) by#=dBodyGetAngularVelY#(ode\body) bz#=dBodyGetAngularVelZ#(ode\body) ; Calculate magnitudes ForceB#=Sqr(bx*bx+by*by+bz*bz) If forceb>.01 friction#=ode\mat\rotational_friction*-1.0 dBodyAddTorque ode\body,dBodyGetAngularVelX(ode\body)*friction,dBodyGetAngularVelY(ode\body)*friction,dBodyGetAngularVelZ(ode\body)*friction End If End If Next EndIf EndIf EndIf Next ;#End Region dWorldQuickStep(ODE_world,ODE_Resolution#) dJointGroupEmpty(ODE_contactGroup) Return t+1 End Function Function update_object(obj.ODE_Object) RotateEntity obj\mesh,dGeomGetPitch#(obj\geom),dGeomGetYaw#(obj\geom),dGeomGetRoll#(obj\geom) PositionEntity obj\mesh,dGeomGetPositionX#(obj\geom),dGeomGetPositionY#(obj\geom),dGeomGetPositionZ#(obj\geom) End Function I will be adding a test each frame along the lines of For each object, If Frame = object\Entry_time, object visibile=true, ODE_active=true This loop calls the simulation update once per iteration and so that's called 1/60th or 1/75th frame or whatever depending on screen refresh (which is something I'm a little concerned about, but not a great deal), or less than that if the simulation time overruns one frame. Simulations are nothing complex so it's not an issue on most machines but on the test case at say <30 fps main loop update the simulation runs at about half speed. If I change the quickstep value ODE_Resolution to 0.25 the low spec'd machine runs it nicely but of course it's too fast on anything more up to date. It's not a time critical system and if the program runs slightly faster or slower on different machines that's fine. However I'd like to be able to offer at least a reasonably realistic speed even on slow machines and I know ODE can handle that if only I could figure how to tweak it. |
| ||
| I have a solution to your problem, I'll go get and example. The two examples below are time based and will solve your issues of running too fast on faster machines. |
| ||
| |
| ||
| |
| ||
| Thanks for the effort Wayne. I'm sidetracked with UI at the moment so haven't had chance to test it on el slowmo' computo though. |
| ||
| JV-ODE Physics Wrapper V1.07 Released Please check your inbox ;) Firstly, thanks to all users who took the time to send me their preferred document format choices. For those who are curious, here are the results: DOC/RTF: 15 % HTML: 48 % PDF: 25 % CHM: 12 % Version 1.07 now includes the 'JV-ODE Function Reference', you will find it in the docs folder. All of the functions available in JV-ODE are now documented. You will still need to use the official ODE documentation for the JV-ODE functions that are identical to their ODE equivalents, but the function reference will help guide you to the correct chapter containing this information. The functions unique to JV-ODE are all explained in more detail, including the JV-ODE vector functions and the ODE functions which are either not documented or differ slightly in use. The reference is completely hyper-linked, so you can click each function to find more information thoughout. I really hope it helps you all because it took many, many hours to build it. There has also been a slight change in the dGeomPlaneGetParams() function and a bug fix for the dGeomGetAABBMin() and dGeomGetAABBMax() functions. Check the 'Version History.txt' for more info. A new demo has also been added to show detailed collisions when using multiple spaces. Don't forget to update your 'JV-ODE.decls' file too! Cheers :) |
| ||
| Great, thank You for the Update. I am really happy that i bought this. Very good Support. |
| ||
| Wow! Thats some doc file! I don't envy you having to do all that. Thanks again for your hard work - JV-ODE is well worth the money and, even better, it's great to see you're so 'into' what you're doing here. You're obviously completely committed to making a great ODE wrapper and looking after both it and 'us' ... and you're doin' a GREAT job :) |
| ||
| You're welcome and thanks to both for the compliments, it really means a lot ;) Yeh, I think that's definitely the largest 'doc' I've ever written, it was up to 54 x A4 pages even before adding the html code. I thought it would never end :) |
| ||
| You should market this beyond just Blitz. Go for the DBPro users. |
| ||
| I've never used DBPro, Jedive tried to make a .dba(?) file for the DLL when it was at V1.00 but he didn't have much luck IIRC. What's involved and how does DBPro talk to DLLs, any idea? |
| ||
| great work VIP3R !!! As for db pro, there is a Physics Expansion pack coming out for it. Not too sure when though, but soonish. |
| ||
| Thanks very much for the update. Appreciate your hard work. Funky Frank |
| ||
| Grrrreat - thanks a bunch! Like said here before, I'm glad too that I bought this one... updates are "frequent", demos are great - and you even solved the trimesh thingy without giving up like most would have done and just faded away. Good job! I'm at work, but those docs sound like really usable addition. |
| ||
| You're welcome and thanks fellas, much appreciated :) |
| ||
| Waaaaa HAY! :) You da man! |
| ||
| Hehe, cheers Cyg ;) |
| ||
| I'm using JV-ODE in an application that is quite complex. It (the wrapper - not my app :)) has rock-like stability, is extremely flexible and is easy to implement. Thanks for the update ! |
| ||
| JV_ODE cannot automatic stoping the rolling Cylinder, although rolling resistance is fixed. I have write a Funtion to stopping the rolling Cylinder. but the objects after this, always remain lay in movement and aren't deactivated. AutoDisable is on and Stop Parameter an 1.0 why ode doesn't make this automatically if setting the parameter for rolling resistance & mass ? In Car-Demo also don't stop the rolling Cylinder . |
| ||
| No problem Smiff ;) @Barton: It's most likely due to the settings you've applied to the cylinder (mass direction/friction etc). Which Car Demo did you mean? |
| ||
| I have the problem also without masses & friction setting. with Car-Demo I mean the example in JV_ODE. what must I change in Car demo so that the Cylinders stop ? |
| ||
| I have the problem also without masses & friction setting. You will, they're both zero by default. All of the Car Demos have cylinders, that's why I asked which one you were referring to. Imagine that you have a cylinder made of a hard property (like glass or metal), now imagine your plane as an infinitely flat surface, also made of a hard property. If this cylinder was rolled upon this surface, would it come to a stop in real life? Probably but not for a long while. Now imagine the cylinder is made from a softer rubber, what would happen now when it was rolled? The point is, try to think about how these things would work in reality, after all ODE is a simulation of 'real' physics. The cylinders in the Car Demos can all be considered to have a hard surface, as their contact settings are at default values. Besides the mass, try changing the contact friction, contact bounce, contact ERP and CFM values for your cylinder geoms and make their surface softer like rubber. |
| ||
| VIP3R, I was simulating a huge pyramid with aprox 2,000 blocks at 20 fps on crap machine with crap video card and wanted to see if I could go higher. I used multipass rendering so I didn't have blitz entity count slowdowns. When I try to add more I get a stack error. Do you have some stack options in ODE before you compile the DLL ? Maybe I should just behave myself, post the mamath, and be content with 2000 physics objects. 8) |
| ||
| 2000 is a lot! I think in the rope demo i was getting maybe 200 with big slowdown. |
| ||
| I have tested everything now. The Cylinder still infinitely roll further. i have set the World ERP/CFM/Mass (Values 0.1-100 tested) where can I adjust the friction? i have coded a Funtion to stop the Clinders (LinerAngular - friction#). but this isn't good solution. perhaps does anybody have an example? |
| ||
To prevent roll I use Wayne's example for angular friction
For ode.ODE_object=Each ODE_object
If ode\body
If dBodyIsEnabled(ode\body)
numjoints=dBodyGetNumJoints(ode\body)
If numjoints>0 ; If joined to another body
For joints=0 To numjoints-1
; for all joints attached to body...
joint=dBodyGetJoint(ode\body,joints)
If dJointGetType(joint)=dJointTypeContact ; If joint type is a collision contact
; Get Angular velocity vector
bx#=dBodyGetAngularVelX#(ode\body)
by#=dBodyGetAngularVelY#(ode\body)
bz#=dBodyGetAngularVelZ#(ode\body)
; Calculate magnitudes
ForceB#=Sqr(bx*bx+by*by+bz*bz)
If forceb>.01
friction#=ode\mat\rotational_friction*-1.0
dBodyAddTorque ode\body,dBodyGetAngularVelX(ode\body)*friction,dBodyGetAngularVelY(ode\body)*friction,dBodyGetAngularVelZ(ode\body)*friction
End If
End If
Next
EndIf
EndIf
EndIf
Next |
| ||
| Do you have some stack options in ODE before you compile the DLL ? No, the stack size isn't modified. Are you using dWorldQuickStep()? The other function dWorldStep() makes heavy use of the stack and is much more likely to overload it. I'll keep an eye on this though, thanks for the info ;) Maybe I should just behave myself Hehe, you should indeed :) i have set the World ERP/CFM/Mass (Values 0.1-100 tested) where can I adjust the friction? Those are the world contact settings which are not the ones I suggested earlier, you should be changing the contact values of the cylinder geoms ;) Look at your JV-ODE Function Reference document and read through the 'Unique JV-ODE Functions > Collision Functions' section. You need to use these: dGeomContactSetMode(geom,mode) ; << You MUST set this for these to work properly dGeomContactSetMu(geom,mu#) ; Friction dGeomContactSetBounce(geom,bounce#) ; Bounce dGeomContactSetSoftERP(geom,erp#) ; ERP dGeomContactSetSoftCFM(geom,cfm#) ; CFM Or you can damp the velocity instead like the code snippet above does (thanks Wayne & Shifty). |
| ||
| How can I set the mass of an ODE_mass object once created? I use ... dMassSetBox(obj\mass,obj\mat\density, obj\siz\x, obj\siz\y, obj\siz\z) ...When I create my box, but I want to be able to change it's weight. I've tried... dMassAdjust(obj\mass, 999.0) ...and ... dMassSetBoxTotal(obj\mass,999.0, obj\siz\x, obj\siz\y, obj\siz\z) ...but object mass remains unchanged. |
| ||
| Do you mean you want to change the existing mass of an object? If so, have you destroyed the mass structure? If you want to change a mass later on, don't destroy it until access to it is no longer needed. |
| ||
| No I haven't tried destroying and replacing. I was imagining I could just change the weight of an already existing ODE mass object. There doesn't appear to be a function to delete a mass object (dMassDestroy) either. |
| ||
| You can, it would've really helped if I had some code to go on, even just a snippet :) I suspect you haven't applied the new mass to the body with the dBodySetMass() function after altering the mass properties. Modified Car Demo showing change of existing mass structure... There doesn't appear to be a function to delete a mass object (dMassDestroy) either. There is indeed, not only is it in JV-ODE but it's also described in the new docs ;) |
| ||
| Thanks for that VIP3R. Just returned to this after some UI work and I see it's just a matter of reassigning the mass object to the body. |
| ||
| What's the best way to disable & enable a geom from being involved in collisions? I've got several objects that I want to introduce into the simulation over time. I'll set the entities to invisible so the inactive objects can't be seen, but I also need to set the bodies as not being collidable. One solution is to only create the collision geometry when I want the object to appear into the simulation. Is another to move the object into different spaces, or is that not possible? I couldn't find any suitable command other than dBodyEnable/Disable which is overridden when another geomertry collides with the disabled geometry. checking the docs again, can I use dSpaceRemove and dSpaceAdd without 'damaging' my objects? Can I create my objects in ODE_Space, use dSpaceRemove() to keep the objects but remove them from active ODE_Space, and then when needed just call dSpaceAdd() to place them back into the active space? |
| ||
| No worries! I've got that working. I create the simulated objects geom's without assigning them to any space at creation time, and disable gravity for the body. At the appropriate time to introduce an object I simply add it to ODE_Space() and dBodySetGravityMode(body, true). Pretty straightforward. |
| ||
| I'm told dSubGeomCountCollisions() doesn't exist. It compiles fine but at runtime the userlib function isn't found. I'm trying to set up responses between geoms in different spaces using
If dBodyIsEnabled(temp\body)
numCollisions=dSubGeomCountCollisions(temp\geom)
If numCollisions>0
; For each collision, test if with ground
For n=1 To numCollisions
collision_geom=dSubGeomCollisionGeom(temp\geom,n)
If collision_geom=ODE_object_list\head\geom
a=ODE_object_list\head\geom
; Just a test stop point to check if the collision is being detected correctly
EndIf
Next
EndIf
EndIf |
| ||
| Hmm, that's an odd one Shifty. Can you check to make sure that 'temp\geom' exists and that your 'JV-ODE.decls' file is the most recent, it should be date stamped 07/09/2005 08:40 Also, can you run the 'CarDemo-DetailedC-MS.bb' demo and see if that works ok. Let me know your results, cheers ;) |
| ||
| My bad. Hadn't installed the latest JV-ODE! |
| ||
| Friction's being very awkward. I've a mesg surface with Mu=100, and a sphere of Mu=10 that rolls down ramp onto the table. The ball slides, not rolls to the end of the table. Near the end it starts sliding right over left instead of back over front like a real rolling ball would. When it hits a wall (part of the same table mesh), it spins really quickly almost on the spot. It doesn't get traction with the ground. Setting the sphere's Mu to 100 for MORE friction, when it hits the wall it starts spinning faster and faster and then disappears through the table. I can't get a turning sphere to get traction with a table. |
| ||
| Currently researching this and I think I see where to fix it. The problem is with masses, and mu needs to be set much higher than mass. 10000x even for perfect friction. The difficulty is in setting partial frictions like 50%, which are logarithmically related to mu. In several more hours I'll probably have cracked it. |
| ||
| Yeh, as you've discovered the mass is extremely important with regards to friction. An object with even an infinite amount of friction will not behave as such if the object has very little or no mass, the two are closely related. You should find that increasing the mass (without increasing the friction) will have a similar effect to increasing the friction (but not the mass), but on a different scale. Please post you're findings Shifty, I'm sure it will be very useful and interesting information ;) |
| ||
| Okay, here's my research so far. Dunno how much use it'll be as it seems much of ODE's use can be applied without using about masses and many people don't bother with them, but here it is none the less. As a starting point I took the car demo (which works without any of the complexities of my main program) and grabbed one of it's spheres. I applied rotational velocity to it dBodySetAngularVel() and due to friction it span off into the distance, where I quickly jumped into my virtual motorcar and followed it - whizz! I then assigned the sphere some mass (mass=1.0) and it just started spinning on the spot when the rotational velocity was added. Friction was the standard world friction of 64. I dropped the mass weight from 1 to 0.01 and the sphere showed traction, and with more experimenting I found a relationship between mass and friction where for absolute friction, you need a mu of 10000x the mass. I changed my code to incorporate this, setting mu to 10000*mass and as I changed the mass from 0.01 to 10, the sphere maintained absolute friction. To make sure my experiments were valid I set the world friction to 0, so the floor had zero friction. (Note that the value of mu for the contact joint is the mean average of the two geoms, so the real value of mu for the joint is half the geom's set mu.) Application of Wayne's counter force for slowdown was now working properly (though as implemented it doesn't scale according to energies which is easily fixed), but the problem arises as to how to set an object's friction in terms of something useful? Ideally I'd like a percentage 100% = absolute friction, 0% = no friction. Experiments showed mu=mass*10000 was absolute friction, and mu=mass*1 was no friction. What I took to be half friction was mu=mass*1000, mass*100 was 10% friction, and mass*10 was 1% friction. These aren't accurate figures but just observations. What I eventually worked out was to use logarithms and a gamma curve to specify the relation between a 0-100 range and how much friction changes. Here's working code, and it's working just how I wanted. There's two spheres and a box. The rear grey sphere shows a fixed friction of 10 (something I used to think was a high value!) and the front white sphere shows mu relative to mass. The current values set the sphere's masses low. When you un the program press the INSERT key to apply the rotational velocity. If you run as it is both have friction with the ground and pull away. The resistance forces are quite high in the sphere slowdown code so they come to a stop rather unrealisitically, but it's the friction we're concerned about with this experiment. Now if you up the SPHERE_MASS# to 1.0, you see the problem with the grey sphere. It's lost traction. Wheras the white sphere acts exactly as before, only now with superior mass which affects forces and particularly collisions. Another thing to change is SPHERE_FRICTION#. Set this to a percentage and the white sphere takes a while to gain traction. You can also apply backspan and see the friction work very realistically. Change the lines 136 and 137 to dBodySetAngularVel(sphere_ode\body,0,0,-4) dBodySetLinearVel(sphere_ode\body,-1,0,0) Now depending on your friction value, the sphere will travel left but gradually slow and accelerate right. This behaviour is uniform regardless of the white sphere's mass because of the calculation for mu. The last aspect to play around with is collisions with rigid bodies. Set GRAVITY_ENABLED to false and set lines 133-142 to If KeyHit(210) ; Hit insert key dBodyEnable (sphere_ode\body) dBodySetAngularVel(sphere_ode\body,0,0,4) ;dBodySetLinearVel(sphere_ode\body,-1,0,0) dBodyEnable (sphere_ode2\body) dBodySetAngularVel(sphere_ode2\body,0,0,4) ;dBodySetLinearVel(sphere_ode2\body,-10,0,0) dBodySetGravityMode(box_ode\body,1) ; Change 0 to 1 to have box drop dBodyEnable (box_ode\body) Now when the INSERT key is hit, the spheres roll in mid air and the box drops on. By changing the sphere's friction and box's mass you can see how the force of the spinning sphere throws the box. I've only tested this for spheres but the same principle should apply to other rigid bodies too. The caluation of mu can be easily ported to a function something like... Function SetSphereFriction(geom.ODE_Geom, mass, friction) ; geom.ODE_Object : ODE geometry object ; mass : Object's mass ; friction : Ojects friction as percentage gamma=0.5 ; Change for different relationship between percentage and friction frict#=SPHERE_FRICTION/100 frict=frict^gamma frict=frict*4 frict=4-frict e#=Log10(SPHERE_MASS*10000) e=e-frict dGeomContactSetMu(geom,1*(10^e)) End Function Where this solution is incomplete is in specifying the response to two different objects. Consider a sphere which you want to have absolute friction on the ground and a slide down which you'll send the sphere where you want to be able to set the friction. As an exmple the slide could be set to 0 friction so the sphere slides down without turning, but when the sphere hits the floor friction turns forward momentum into rotational velocity. Setting the sphere's friction to 100% will enforce absolute friction in all collisions, so the sphere will roll down the slide, not slip down it. There needs to be a way to set the interaction between objects to specify the result. In some cases we'll want the lowest value for friction to apply to both objects, in others the maximum. Actually I think this only really applies to static and animated objects. Where you have two animated objects the average is probably okay. As my current 'engine' works I have static bodies in their own seperate ODE space and for me I'd like to be able to specify friction response per static object. As a final point it might be worth adding some features to the JV-ODE wrapper? For one you could have the friction function as an internal function. Perhaps dGeomSetFriction(geom,mass#,friction#). Dunno if people would find this useful or not. As another perhaps the collision responses could be given options, like the Restitution was? Perhaps an option per contact joint to use either the lowest, average or highest mu of the two objects? Anyhow I'd better finish this epic post at some point, so I'll finish it now! |
| ||
| Wow, that's some great info you've posted Shifty, thanks! :) It might be better to add the dGeomSetFriction function to the include file (or let the user add it themselves). There wouldn't be any real benefit if it were included inside the dll as the only improvement would be a slight speed gain, which isn't critical during setup of the geoms. It shouldn't be much of a problem to add the 'use lowest value' option on the contact joints. I need to be careful though, as adding another option to the contact callback function could slow down the collision checking. I'll look into it for you ;) |
| ||
| Nice work shifty. |
| ||
| Interestingly (or annoyingly, depending on how you look at it) the equation for determining sphere friction doesn't work for boxes. Where a sphere's friction ranges from 1x mass=0% friction, 10000x mass=100%, friction, for a box I've found 0.001xmass = 0% friction, 10x mass=100% friction. Also the gamma seems different, and a 0.75 value fits more comfortably than the 0.5 for the sphere going by my very rough observations. Here's a function for determining and setting a boxes friction. Function SetBoxFriction(geom.ODE_Geom, mass, friction#) ; geom.ODE_Object : ODE geometry object ; mass : Object's mass ; friction : Oject's friction as percentage gamma=0.75 ; Change for different relationship between percentage and friction friction=friction/100 friction=friction^gamma friction=friction*4 friction=4-friction e#=Log10(SPHERE_MASS*10) e=e-friction dGeomContactSetMu(geom,1*(10^e)) End Function Strangely in testing it worked the same for all masses ranging from 0.001 to 1000, except for mass=100 where the box stopped slightly short! (??) Odd. Maybe this is one of those arbitary DirectX rounding changes in effect. VIP3R : The addition to the include file makes sense. It's not a time critical function. Is there any convenient way to switch between two implementations, one with optional friction responses and one with static, short of providing two different .dlls? Otherwise it might be worth keeping a trimmed .dll without the extra functionality if it'll add a performance hit when most people don't need it. |
| ||
| I should also add that the slowdown code used on the sphere to stop it rolling forever isn't needed on the box which stops due to conventional friction. Indeed applying the Torque causes all sorts of strange bouncing! Really there's two different behaviours that need to be taken into account for boxes and spheres. Sphere's need rotational dampening per update and a different function for friction than boxes. Cylinders should work the same as spheres at a guess, but I'm not using them and haven't looked into it yet. |
| ||
| Ok, I've worked out a method of doing the max/min/mean contact options without any further speed implications when using the default setting (mean). There will be a slight speed hit when using the max/min settings, but these are much slower anyway due to the amount of calculations performed each time step. The additional overhead by adding the min option shouldn't be noticeable. I'll add it to the 2do for V1.08 ;) |
| ||
| Hello, I'm working in a cannon ball simulator (really basic,pretty much to learn ODE commands). The thing I'm stuck with is that I want to be able to preview the path the cannon ball will follow (before shooting), any idea on how to do this? I've seen a pool game that allows previews of the ball trajectory, though not sure if they are just straight lines. Thank you. |
| ||
| Hi Pax, yeh pool games use simple reversed angles which are easy to implement. Working out a cannon ball trajectory is little more tricky, as there are several things to take into consideration like gravity, wind direction, air resistance, cannon balls weight/mass and the force used to shoot it from the cannon. You can work this out using some math, but it may not match exactly to the ODE simulation (which is what you would want ideally). For best results, I would use ODE to work out the trajectory. Using this method will ensure that the actual ODE trajectory matches the previewed trajectory correctly. What you need to do to achieve this is launch the cannon ball, and track (record) its trajectory/location at several intervals (maybe every 10 world steps?). But do not draw the cannon ball mesh when launching the ball, only track its location. You can use multiple spaces to prevent any collisions during the preview, or fire the cannon ball at a different location in your simulation (out of view). Once you have tracked the previewed trajectory, you can use this data to highlight the path by placing spheres (or whatever object) at each location that you've recorded. |
| ||
| Hi, is there a way todo a stretched Sphere for a FPS Game (a small but long Sphere for the Player Collision). I can see only one Parameter for: dCreateSphere(Space,0.7) In B3D or the Newton Physic Engine i can use 2 Parameters for a Sphere as dCreateSphere(Space,0.7,1.0) Thank You |
| ||
| Not In ODE. You should use two spheres or one dccylinder... |
| ||
| A capped cylinder (dCCylinder as KuRiX mentioned) is essentially the same shape as a stretched sphere, its geometry is like a flat ended cylinder with a semi-sphere attached at each end. |
| ||
| Thank You both, will try it. |
| ||
| To VIP3R, Thanks a Boat load..! Purchased your JV-ODE package last night, well early morning lol, and haven't had any sleep due to being able to accomplish stuff I only beat my head against the keyboard before using straight Blitz3D. First - off I would recommend this package to anyone wanting to experience a new way of "looking" and programming for Blitz3D. Second - Althou there's not a smooth guide to help someone discover the many facets of this Wrapper, it's still quite exciting. i've been gone from the B3D community for ages due to starting up a Gaming Center here in Florida, and doing Modeling and Coding work for a private gaming company that's creating a mod for Zero Hour. But past to now and I dug up my B3D and found an old proggy of a acient Moto Bike style idea, but after taking the JV-ODE and spending a solid 16 hours I've now got a really fun to tinker with beginnings of a MX - ATV style play toy. Now to finish off this BOOK of a post, Thank you again for taking your time to actually produce a worth while item that I am happy to purchase. The support I see seems most excellent and you actually take the time to work with peeps on problems. To which I'll be jumping in and "pestering" you all soon enuff as things get beyond my grasp. ;) Now to start whipping out some models to toss in and get this play toy looking better ;) Topknot :) |
| ||
| Hey VIP3R. Big problematic problem I have encountered, which makes a bit of a mockery of all my friction investigations to date! I've been applying forces to spheres and boxes and getting different results. I've looked more closely and found the dMassSetSphere() and dMassSetSphereTotal() give different results, while setting a sphere's mass seems to set it differently to a box's mass. Look at the following... Press the insert key to apply a force of (0,0,100) to all four objects. There's no friction and they're all the same volume and the same mass in theory, so they should all move at the same speed. Taking the boxes, they both work. They travel at the same speed though one has mass set with Total and the other by density. Looking at the first sphere, who's mass is set by density, it moves slower than the cubes. Thus it appears heavier. Looking at the second sphere who's mass is set by the Total method, it hardly moves at all. Assuming my maths isn't up the swanny and I'm calculating the total mass right ; Mass of sphere = 3/4 Pi.r^3 SPHERE_MASS#=(3.141*(SIZE*SIZE*SIZE)*3)/4 It should act exactly the same way as the first sphere. And given there's no friction, and all objects are supposed to have the same mass, and they all receive the same force, they should all move at a uniform speed, which means the sphere's should move the same as the cubes. To me it looks like the sphere mass calculations are wrong. The SphereMassTotal set's the sphere's mass about 30x greater than it should be. |
| ||
| . |
| ||
| Hey Topknot, thanks for the kind comments it's very much appreciated and welcome back! :) [edit] Removed incorrect info to prevent confusion - Use of both the dMassSetSphere() function and the dMassSetSphereTotal() function is not required, only one of these functions needs to be set. This applies to all geom mass set functions. Thanks to Shifty for clearing that up. |
| ||
| Thanks VIP3R, Now I would also have a question to all you "smarter than me peeps" ;). In working on this little BAJA style proggy to get my hands dirty, I found odd things happen and trying to find answers. 1 - What I want to do it find the "real" speed or vel of the car instead of just accepting the "KeyDown" Forward results. Meaning if you press down on the forward key to go forward of course it's gonna increase the Speed# variable no matter if you're in the Air, or spun out and standing still, the value is still maxed out. What I'm trying to do is find the Actual movement speed of the 'Body' of the car.. 2 - In working with loading up my own somewhat large "land mesh" to incorporate in addition to the "plane" can you only have one "trimesh" working at one given time, or is this an issue where using multi "spaces"/"worlds" comes into view. Still trying to get my head around that ability from the few demos provided and reading the Forum messages. 3 - From what I was able to pick up reading thru hours of the ODE manual there Is a known issues when using say a car simulation in that if the whole entity's moving to fast the wheels start to get freaky. Not I'm not asking to go Speed# = 100 or such, it's maxed out at 20 at the moment just to the point of getting nasty results, anything higher and the car looses stability and if you cut to hard in a turn you get (what should be locked) rear wheels going nutty and turning all over resulting in a very unstable and not to fun simulation lol. 4 - Sorry forgot one more item, in the Detail Demos you show the ability to "detect" what collision the wheels are at, for example "ground plane" or "red ramp" but what I'm trying to find out is when the entitiys in the "AIR" with no contact with any world items. Again I am trying like crazy to wrap my head around the ODE doc's but due to it lacking any serious examples that "show" a property in work is frustrating. Well there's my major issues and still plugging away on it. Thanks for any help provided and again thanks VIP3R for a fun new Blitz3D experience to melt my brain on. Topknot :) |
| ||
| You're welcome ;) I can help you with those questions... 1 - You want the real velocity in 3D space, try this code... 2 - You can use multiple TriMeshes for your terrain etc, to do this you should place all of the TriMeshes into a sub-space (see multiple spaces) and disable internal collisions (to stop the TriMeshes colliding with each other). There's quite a lot of info on this about half way up this thread ^^^ 3 - Yeh, the wonky wheels thing is a known issue in ODE. Too much friction/mass/speed can break the joints causing the wheels to go haywire. I'm hoping to find a decent solution for this, although using spheres for their geometry doesn't help the situation (can't use cylinders due to instability). 4 - You can use dGeomCountCollisions(geom) for that. When the wheels are not touching anything (in the air), the value returned by this function will be zero. The geom parameter is the wheel geom ID that you wish to detect. Hope this helps :) |
| ||
| Thanks yet again VIP3R, Your example was perfect, now I have the actual engine and sfx matching the real world driving and strain while Baja'in around ;) Will Look into Number 2 and (lost) on number three but I think I have your point. If anyone's interested in puttin around with the project so far let me know I'll post WIP links to see. Topknot ;) |
| ||
| @Shifty: dMassSetSphere() and dMassSetSphereTotal() should only be used together. dMassSetSphere() sets Not really :pthe density of the object, but not the mass. dMassSetSphereTotal() sets the mass of the object, but not the density. I hope this makes sense :) First of all looking at the documentation, explaining the Mass creation functions Set the mass parameters to represent a sphere of the given radius and density, with the center of mass ...they both set the mass parameters, but one uses a given mass and one uses a total. Looking at the mass structureat (0,0,0) relative to the body. The first function accepts the density of the sphere, the second accepts the total mass of the sphere. typedef struct dMass { ...there's a field for the total mass, but not one for density. So unless setting the density affects the inertia matrix, which doesn't make any sense to me, there's no field to record the object's density. There's only a mass field, and I'd assume using either dMassSet() or dMassSetTotal() will place a value into this field.dReal mass; // total mass of the rigid body dVector4 c; // center of gravity position in body frame (x,y,z) dMatrix3 I; // 3x3 inertia tensor in body frame, about POR } dMass; As I understand it there are two functions to provide different methods for the same solution. Any object has a mass, and this mass can either be given for the object, or determined from a given density and the object's volume. In the case of density I can specify a material, say wood with a denstiy of 0.8, and create objects using the dMassSetxxx() to let the function calculate the object's mass from the volume, saving me the effort. With different sized objects you'll have different masses with the same density. In different circumstances I may want to set the entire object's mass without worrying about what the density is. I might create 3 spheres of radius 2.0, and want them to be of mass 5.0, 10.0 and 15.0 respectively. For these I'd use the dMassSetxxxTotal() function and not worry about working out the required density. Now if I'm wrong in my understanding (which wouldn't be the first time!), that means for any object I need to work out mass or density myself. In the above spheres example I would need to calculate object's volume, choose my mass value, and divide that mass by volume and set that to the density. I've tried this, following your advice to use both dMassSetSphere() and dMassSetSphereTotal(). In my example program all objects have a volume of 18.846, and with a density of 1.0 and overall mass of 18.846, they should all respond the same to the applied force. In the two spheres, for one I use dMassSetSphere() followed by dMassSetSphereTotal(), and in the other I set them the other way around. But the result is the same as only using the last method, the same as I showed previously. Just using dMassSetSphere() has the same result as using dMassSetSphereTotal() followed by dMassSetSphere(). Likewise just using dMassSetSphereTotal() has the same result as using that function along with calling dMassSetSphere() before it. One sphere, the one with SetSphereTotal applied last, is much, much heavier than the other sphere. And both spheres react differently to the applied force than the boxes, despite all parameters being equal. And both boxes work the same whether I apply SetMass, SetMassTotal or both. So basically I'm utterly flummoxed what's going wrong! How can I create objects of the same volume, mass and density, no friction, and have them respond the same to a force regardless of shape? It still seems to me ODE doesn't work properly, which I appreciate isn't your fault. |
| ||
| [edit] Nevermind, Wayne has found the bug :) |
| ||
| I think I found it! I don't necessarly agree with shifty's numbers but I think he's onto something. 8) After playing with shifty code I believe JV/ODE function: dMassSetSphereTotal is accidentially calling dMassSetSphere but should be calling ode function dMassSetSphereTotal. The following code would seem to show this. * No fool like and old fool, so I hope I'm right ! * |
| ||
| Oh crumbs, I can't believe it... you're absolutely right Wayne :O Very well spotted! The dMassSetSphere() function is indeed being called instead of the dMassSetSphereTotal() function. Looks like the bug has been there since V1.00 of the wrapper. Thanks very much Wayne and Shifty for highlighting this problem, it'll be fixed in V1.08 :) |
| ||
| Good oh. And yes, i see I was doing 3/4 instead of 4/3 for sphere volume which accounts for the lesser differences. While the 30x greater mass I observed was the fact I used a 30x greater volumet, which I didn't notice because I had this wrong sphere volume calculation. So by pooling all our mistakes we found a solution ;) |
| ||
| oh my gawd I was right, let me tell the wife. hehe Thanks to Shifty Geezer and VIP3R for giving me a chance to help out. JV/ODE is a sweet product and I can't imagine using B3D with out it. Yes lads, using ODE will make you smarter! |
| ||
| I hope that's true Wayne, cause right now I'm feeling stupid, lol. Trying to get my head around the multi space idea, in that I'm trying to load a land mesh then dup it in a grid like pattern. VIP3R mentioned multi spaces would enable the usage of multi meshes and everything I'm trying fails. The problem I guess is that the examples included do have multi space style code but for basic primatives and not fully loaded meshes, hense I assume I'm stuck using the LoadMesh and TriMesh. Here's the reasoning behind this. Milkshape, (which is my fav proggy for quick stuff, has a really easy Heightmap terrain generator, and the really nice thing is that the mesh is designed so that you can duplicate the mesh and it lines up on any side exact, hense you can "tile" them with perfect edge matching. Now here's a snipt of the code I thought was to be done for it.
;** Globals First **
Global World = dWorldCreate()
Global Space = dHashSpaceCreate(0)
Global LandSpace1 = dHashSpaceCreate(Space)
Global LandSpace2 = dHashSpaceCreate(Space)
Global ContactGroup = dJointGroupCreate(0)
; ###################################################################
; # Create the Landscape - Using Create TriMesh #
; ###################################################################
Global Dirt = LoadTexture("dirt1.bmp")
LandMesh1 = LoadMesh("TestHill.b3d")
PositionEntity LandMesh1,0,0,0
ScaleMesh LandMesh1,50,2,50
EntityTexture LandMesh1,Dirt
ScaleTexture Dirt,.05,.05
EntityColor LandMesh1,250,0,0
trimesh = CreateTriMesh(LandSpace1,landMesh1)
dGeomSetRotation(trimesh,0,0,0)
dGeomSetPosition(trimesh,0,0.05,0)
RotateEntity LandMesh1,0,0,0
PositionEntity LandMesh1,0,0.05,0
; ###################################################################
LandMesh2 = LoadMesh("TestHill.b3d")
PositionEntity LandMesh2,0,0,0
ScaleMesh LandMesh2,10,10,10
EntityTexture LandMesh2,Dirt
ScaleTexture Dirt,.05,.05
EntityColor LandMesh2,0,250,0
trimesh = CreateTriMesh(LandSpace2,landMesh2)
dGeomSetRotation(trimesh,0,0,0)
dGeomSetPosition(trimesh,0,0.05,0)
RotateEntity LandMesh2,0,0,0
PositionEntity LandMesh2,3200,0.05,0
Now I do get the items and I understand that non-collision is still needed to emulate the checking between the to meshes from eachother, but this just seems to kill the running OR, only the first trimesh works for checking and the second, while there is not able to preform the needed collision checking. So any pointers or guides would really be nice. I did spend the better part of the night reading all the forum postings like VIP3R mentioned and referencing the "Examples" but I truly seem miffed by what's wrong. Topknot #EDIT# Ok breakthru, not sure how it all changes from last night and now but one thing I noticed in the above code was that I didn't have the "Positioning" values matching the actual mesh locations, now went in and poof they are lined up and working for collisions, OHHh one thing VIP3R DID say was to not have them intersecting the PLANE below in that the collision detection would drag and poof spot on, lowered it and now smooth frame rate with no drag and working collisionable meshes that stretch for miles ;) Now to figure out turning off collisions between the meshs and eachother. |
| ||
| Here's a multimesh example I created a month ago using TED to create the landscape, if your interested in seeing it run with media email me. I believe the JV/ODE demos include multispace examples too. JV/ODE http://www.devcode.co.uk/jv-ode.html TED http://www.d-grafix.com/softwareted.html#SCR |
| ||
| Topknot : A couple of things to look out for. First off both your landscape meshes should occupy your landscape space. There's no need to create another Space that'll probably add overhead. You can just add all you unanimated, static scenery objects into the one subspace. You also want a seperate Geom object for each object so that you can clear them or move them or whatever. At the moment you use the same variable name, Trimesh, for two seperate objects. Global Space = dHashSpaceCreate(0) Global LandSpace = dHashSpaceCreate(Space) landmesh_geom1 = CreateTriMesh(LandSpace,landMesh1) landmesh_geom2 = CreateTriMesh(LandSpace,landMesh2) To disable subspace collisions use dSetInternalSpaceCollideMode(0). |
| ||
| Thank you Shifty, Just read up on the dSetInternalSpaceCollideMode(0), and it works like a charm. Got 10 masive test land meshes loaded and runs as smooth as earlier testing with one. Not to understanding on the point about using the different named geom's. Here let me post the code that I'm testing to load in a random series of land meshes to "build" a world.
Dim LandMesh(10)
Global Loc = 0
For HC = 1 To 10
LPiece = Rnd(1,3)
LandMesh(HC) = LoadMesh("Hills"+LPiece+".b3d")
ScaleMesh LandMesh(HC),10,2,10
EntityTexture LandMesh(HC),Dirt
ScaleTexture Dirt,.05,.05
EntityColor LandMesh(HC),Rnd(100,250),Rnd(100,250),Rnd(100,250)
trimesh = CreateTriMesh(LandSpace1,landMesh(HC))
dGeomSetRotation(trimesh,0,0,0)
dGeomSetPosition(trimesh,0,0,Loc)
RotateEntity LandMesh(HC),0,0,0
PositionEntity LandMesh(HC),0,0.05,Loc
Loc = Loc + 640
Next
Now again just testing ideas, but as you can see I only have the "trimesh ='s" in the code and so I'm curious on the reason for making unique names for it. If you could expand on that maybe I'm missing a very important point ;) Topknot |
| ||
| The reason for using unique names for each TriMesh geom is so that you can access each TriMesh individually later on in your simulation. At the moment you can't do this, as once you've created the second TriMesh, you've lost the handle of the first one because you're using the same identifier for all of them (i.e. trimesh=blahblah). All you need to do is add this to your code... Dim TriMeshObject(10) Then change these lines... trimesh = CreateTriMesh(LandSpace1,landMesh(HC)) dGeomSetRotation(trimesh,0,0,0) dGeomSetPosition(trimesh,0,0,Loc) To this... TriMeshObject(HC) = CreateTriMesh(LandSpace1,landMesh(HC)) dGeomSetRotation(TriMeshObject(HC),0,0,0) dGeomSetPosition(TriMeshObject(HC),0,0,Loc) Now if you need to move the fourth TriMesh for example, you can use its unique identifier. Which in this case would be TriMeshObject(4)... dGeomSetPosition(TriMeshObject(4),NewXPosition,NewYPosition,NewZPosition) PositionEntity LandMesh(4),NewXPosition,NewYPosition,NewZPosition |
| ||
| Ahh ok makes better understanding now. So let me rephrase to see if I grasp it. So to be able to go back and say move a "mesh" loaded object it has to have a unique identifier hense the TriMeshObject(HC) needed. Now if it's a static land mass that 's not going anywhere in the future is there a need for this or is it just better coding to go ahead and plop it in. Also question for you all, now that I got something of land masses ploped around, would you recommend using TYPES so that I can pass through a routine to hide and show land meshes based on if they are seen by the camera, hense a cheap LOD style of code.? or can I still cycle thru the Meshes with a simple For Next loop.addressing the LandMesh(HC) and or TriMeshObject(HC). Again thanks for the input, it's slowly getting there. Topknot ;) |
| ||
| There are other advantages for unique identifiers, like detecting/counting collisions on a particular TriMesh for example. It's good practice to use unique identifiers, you may not want to move static objects but you may need to access them for other reasons. If you design your code in this way from the outset, it'll save you a lot of editing later on if you suddenly realize you need to access them. Regarding the second question, whether you use an array or types would probably boil down to personal preference and its application. For a LOD system it may be easier using types but you could still use an array if you wanted to. |
| ||
| Type are ideal for ODE, as you can package all the related objects together into one type. The standard is to have your Blitz mesh, ODE body and ODE geom objects all in a type... TYPE ODE_object Field geom Field body Field mesh END TYPE Then you can reference the object for related activities. eg. Turn make an inactive object invisible
Dim Objects.ODE_object(10)
FOR n = 0 TO 10
IF NOT dBodyIsEnabled(Objects(n)\body)
HideEntity(Objects(n)\mesh)
ENDIF
NEXTWith all your bodies, geoms and meshes grouped together this way, you can easily reference the different parts to an objects with the same index (if they're in an array). Or as in my case create a linked list where you can add and remove objects at will. Without using types you make keeping tabs on your object's activities and making one thing respond to another thing much more complicated IMO. |
| ||
| Hey guys, In the usage of the "dGeomCountCollisions", I have gone over the example included many many times. I believe it's used to check collision info. In the example I was able to add this bit JumpAir# = dGeomCountCollisions(WGeom(count)) So it looks like this in the Example Code For count=1 To 4 WGeomID$(count)="AIR AIR" TEST# = dGeomCountCollisions(WGeom(count)) If dGeomCountCollisions(WGeom(count))>0 If dGeomCollisionGeom(WGeom(count),1)=PlaneGeom Then WGeomID$(count)=" - Ground Plane" If dGeomCollisionGeom(WGeom(count),1)=RampGeom Then WGeomID$(count)=" - Red Ramp" If dGeomCollisionGeom(WGeom(count),1)=BlueGeom Then WGeomID$(count)=" - Blue Block" For count2=1 To 20 If dGeomCollisionGeom(WGeom(count),1)=SphereGeom(count2) Then WGeomID$(count)=" - Sphere "+count2 If dGeomCollisionGeom(WGeom(count),1)=CCylinderGeom(count2) Then WGeomID$(count)=" - Capped Cylinder "+count2 Next End If Next Now I have also duplicated any and all Globals like the example just incase, and yet in the Example code it works fine and reports a "0" when in Air and a "1" when on a collision surface. Would having dSetInternalSpaceCollideMode(0)in my proggy cause this to missfire and not function right? basically here's what I wanted to do. Seem simple at the time, but I want to Play a Landing Crunching sound when you grab air off a hill or bump and Land.!! Like the struts and springs squeaking and such. So I figured I needed to first register if in the AIR and then when Back on GROUND to fire off the FX. |
| ||
| Using dSetInternalSpaceCollideMode(0) only affects collisions of objects within the same sub-space, so as long as you don't put your vehicles in the same sub-space as the static scenery, the collisions & detection will still work as expected. Although using dSetInternalSpaceCollideMode(0) won't affect the collision detection, using multiple spaces does. You need to use both the dGeomCountCollisions(geom) function and also the dSubGeomCountCollisions(geom) function to detect all possible collisions. Check out the 'CarDemo-DetailedC-MS.bb' demo to see this in action. Basically, you just need to do this... TotalCollisions = dGeomCountCollisions(WGeom(count)) + dSubGeomCountCollisions(WGeom(count)) You can also find more info about these functions in the JV-ODE Function Reference. |
| ||
| Sorry if all the questions pester you, but learning as I go is the only way without docs or examples from others, but the point of looking into "SUB" spaces was the ticket. Where as I wasn't acounting for them being in different spaces for the collision reference. Thanks. I keep the JV-ODE Function Reference up on the second monitor while testing and trying to accomplish my step goals, but it doesn't really leave alot of info in example format to assist. Maybe it's just me but I work best with an example of sorts. Not your fault but when your new to using this ODE like me it's a bit harder to fully understand their usage until you figure it out. |
| ||
| Hey no problem Topknot, being pestered is what I'm here for ;) Don't worry, the learning curve seems quite steep to begin with, but you'll be surprised how quickly you get to grips with ODE :) Keep it up, you're doing very well so far. |
| ||
| I agree wtih VIP3R here. Learning how ODE works is quite tricky, but once you get a handle on it it's straight forward to use and understanding then how to reference individual collisions is pretty straightforward too. Just keep reading, writing, getting confused and asking questions 'til you get it! |
| ||
| Alrighty, To take you all up on your postings. The collision issue it just out of my grasp. I've read the Doc's 3x trying to figure out what they mean. and Disected the Car Detailed MC several. If I do register a collision it crashes, or after test changing it doesn't even show a collision. Ok here's the layout to Try and do this right and understand it. First - I have the Car and Wheel Geoms created with CGeom and WGeom(count) "1-4". Second - I have the Plane listed with PlaneGeom. Car and Wheels are in the "CarSpace" Plane in the "LandSpace1" Global are set for: Global CarSpace = dHashSpaceCreate(Space) Global LandSpace1 = dHashSpaceCreate(Space) CGeom, PlaneGeom, GeomGeom$ Dims are set for: WGeom(4) WGeomID$(4) Now I assume I want to just check the collision between the two "spaces" i.e. (CarSpace -v- LandSpace1) But no matter how hard I try to recreate, copy and paste, or go line by line and read definitions in the JV-ODE Reference, I can't see the error of my ways. I tried using a Dummy Object parented to the Cmesh and having it drag under the car to Blitz Collide with the two surfaces. Works great but it can't seem to "update" or push the triggers until I slow to a craw and then proceed. Granted it works but only if you want to drive 5 miles an hour....:( |
| ||
| Probably best you post up a copy of your code. Use the CODEBOX tag instead of the CODE tag so it fits in the window. |
| ||
| @Topknot: If you're experiencing crashes, you're probably forgetting to check a collision has occurred beforehand. Doing the following will cause ODE to crash if there are no collisions detected... GeomX=dGeomCollisionX#(CGeom,1) To solve this you just need to check to make sure a collision has occurred before calling it... If dGeomCountCollisions(CGeom)>0 GeomX=dGeomCollisionX#(CGeom,1) End If This applies to all of the collision functions, including the sub-collision functions. If you're still a bit stuck, post your code using the <codebox> </codebox> tags (change <> for []) as Shifty suggested and we can take a look at it for you. |
| ||
So I assume something like thisFor count=1 To 4 SubWGeomID$(count)="" If dSubGeomCountCollisions(WGeom(count))>0 If dSubGeomCollisionGeom(WGeom(count),1) = PlaneGeom Then SubWGeomID$(count)=" - Water Plane" If dSubGeomCollisionGeom(WGeom(count),1) = GroundGeom Then SubWGeomID$(count)=" - Ground Plane" End If Next This is showing the collision finally after widdling down the Demo Cat MS D example lol. On another note, is there a formula for figuring out the car objects dimensions verse what is actually seen. I read somewhere a 2:1 ratio. For example I use a custom model mesh for the car's body and of course when it flips it buries itself up to the original sizing of the actual ODE object. Experminting at the moment with a hugly stripped down "demo example" to test this. Read in the ODE manual : dMassSetBox (dMass *, dReal density, dReal lx, dReal ly, dReal lz); dMassSetBoxTotal (dMass *, dReal total_mass, dReal lx, dReal ly, dReal lz); Wish they would define things like "dReal density, dReal total_mass". I again am assuming they are absolute values uses in the collision routines...?! If you guys got a simple formula or ratio where a person can match a custom object to the actual ODE object dimensions. On a brighter point I made of found a nice way to reset the car once it flips without the destroy and rebuild option, so far it's nicer to the end user, will post when I think it's worth you're all inspection ;) Topknot ;) BTW dying to show you all what it is that I've been pounding out. granted it's not the fully menu driven, goal playing style yet, but it's hella fun and looks really sharp with my custom models ;) |
| ||
| So I assume something like this Yep, exactly like that :) Right, the dimensions (using ScaleMesh not ScaleEntity)... ODE Spheres vs Blitz Spheres - Same dCreateSphere(Space,3) <- 1x3=3 ScaleMesh mesh,3,3,3 ODE Boxes vs Blitz Cubes - 2x X,Y,Z dCreateBox(Space,2,4,10) <- 2x1=2 2x2=4 2x5=10 ScaleMesh mesh,1,2,5 ODE Cylinders vs Blitz Cylinders - 1x Radius - 2x Length dCreateCylinder(Space,1,10) <- 1x1=1 2x5=10 ScaleMesh mesh,1,5,1 ODE Capped Cylinders vs Blitz Cylinders - 1x Radius - 2x Length minus 2x Radius dCreateCCylinder(Space,1,8) <- 1x1=1 (2x5)-(2x1)=8 ScaleMesh mesh,1,5,1 You specify the dimensions when creating the ODE object, not in the mass functions. When you do use the mass functions, they should have the same dimensions as the ones you used when creating the ODE object. Btw, dReal just refers to a float value in ODE. Looking forward to checking out your demo :) |
| ||
| See that's Perfect...! That little example formulas was a greater help than you can imaging. Hard headed peeps like me need simple "english" ;). BTW Got the X,Y,Z Sizing "bounding area" issue covered, but what do I need to change to raise or lower the actual Geom, or Body.? Hense the Car's up on a higher suspension than a normal car I need to raise the (body/Geom) up. I see dMassTranslate, and I assume it placed the actual mass of the oject and it's center of gravity at a given point , still hunting and pecking thru the ODE doc's online. There's dGeomSetBody, but that get's assigned the Body's values, (i.e. a parenting style link?) Then there's dGeomSetPosition (dGeomID, dReal x, dReal y, dReal z)For setting the martix's? Well still hunting ;) |
| ||
| Well, to raise the suspension you have to consider two things: -> The real suspension position must be set BEFORE the joint attachment. -> You can fake the geom position relative to the body position using dgeomtransform. Look the ode manual to understand the geomtransform, but basically is a geom that encapsulates other geom, so you move the geom to a position of 0,1,0 and using a geomtransform the geom is at 0,0,0 but moved internally at 0,1,0. Good Luck! |
| ||
| what do I need to change to raise or lower the actual Geom, or Body.? Hense the Car's up on a higher suspension than a normal car I need to raise the (body/Geom) up. Try changing the following code in the CarDemo.bb... dBodySetPosition(ode\body,0,CarStartY,0) To this... dBodySetPosition(ode\body,0,CarStartY+1,0) Ok, this thread is getting a bit long now... THIS THREAD IS ABOUT TO CLOSE!!! PLEASE USE THE NEW THREAD LOCATED HERE THANKS |
   |