JV-ODE Physics Wrapper
Blitz3D Forums/Blitz3D Userlibs/JV-ODE Physics Wrapper
| ||
| 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. Have Fun :) Useful Links: ODE.org Website - ODE User Guide (PDF) - ODE User Guide (HTML) - ODE Archives |
| ||
| I'll send out the new wrapper tonight to all existing users in the user list that Jedive sent me. [edit] * New wrappers have now been sent to all users on my user list. Check your inbox :) * |
| ||
| Could you show some demos?? (with an executable) |
| ||
| I'm going to talk with Jedive and see if we can make a restricted dll for demo purposes. I've been a bit busy getting the wrapper up to speed lately, so I haven't had chance just yet ;) |
| ||
| VIP3R, How about creating a demo package on the web site with the following: B3d Demo program sources B3d Demo program executables ode.dll That would fit with the license and give people a quick first look. Besides cylinders needs your attention. 8) |
| ||
| The user list I sent you contains all the JediveODE users, so I don't need to send it to anyone else. About the demo, I'll contact you this afternoon, Viper (I just have to go to make an exam). I'll have a few relaxed days, so I'll add a few things to the lib for the next update. I want to change some things in collision code, so each geom can have it's own bounce, cfm, erp, etc, parameters. |
| ||
| @Jedive: Ok, no problem - Good luck! :) @Wayne: Is this a new cylinders issue or a known one? |
| ||
| JEDIVE and VIP3R: Thank you for a great job... /Alienforce |
| ||
| Nice ideas jedive :) There is a bug though! cubes and trimesh: cubes fall through the trimesh often. The cube parameters are the same as in your other demo.... Spheres are ok with trimesh. |
| ||
| Your welcome Alienforce :) Thanks for the feedback Flying ;) Hint for everyone: look at the known issues at the top of the thread... |
| ||
| Thanks Viper. *feature request* it is necessary in a lot of circumstances - such as a snooker game, to get a list of other bodies we have collided with. These could just be the body handles if you like. Somehow, you'll need to query a list per object. For example the wrong ball is hit in Pool. I have no idea how you'll do this, but you could possibly make this constant by using SetMaxContacts as a guide. For example the programmer could then make a bank for each object, and that bank will be filled with a GetCollisions(bank,rigidbody) command... And then it will be a list of int handles to each rigid body which collided with us. This is a powerful way to quickly build a list without callbacks. |
| ||
| Ok flying. As I am extending the collision system, I'll add what you are requesting too, no problem. |
| ||
| Thank you very much :) |
| ||
| Wayne posted a nifty little addition to the UpdateGeoms() function in the old thread which will help optimise it, so I thought I'd pop it in here where it belongs. I've had to edit it a little though as it needs to detect enabled geoms not body/meshes. Cheers Wayne :) Don't forget to activate the auto disable feature when using this. |
| ||
| Have you noticed spheres falling through meshes or behaving weirdly? |
| ||
| Not falling through meshes, but if they are created 'inside' a TriMesh they will shoot off like a rocket when they collide with it. Can you describe the problem you're getting? |
| ||
| They tend to fall through it. Or react strangely, but I cannot tell if thats bad ode settings or the wrapper so I'll keep trying in the meantime... Also, do you have functions for AngularDampening and Linear Dampening? Function LinearDamp(body,damp#) dBodyAddForce body,dBodyGetLinearVelX(body)*-damp,dBodyGetLinearVelX(body)*-damp,dBodyGetLinearVelX(body)*-damp End Function Thats one I made up, which seems to damp but the result is incorrect as it will eventually go in a straight line! Tokamak has angular and linear dampening and I'm wondering how to make this happen in ODE... |
| ||
| Try playing around with the mass settings of your spheres. I've not played around with dampening yet, but I think you can use ERP and CFM to control it on individual bodies in ODE. Check the 'Concepts' chapter of the ODE User Guide for more info about this. Jedive is going to add the ability to control these on a per body basis, so you should be able to do this soon. Are you designing a snooker/pool game then? |
| ||
| I've done pool/snooker games in Blitz3D before and I want to do it as a learning exercise. Then I'll progress to a puzzle game involving physics that I have in mind. Maybe! :) Correct me if I'm mistaken, but CFM and ERP won't enable a ball to roll to a stop. |
| ||
| Rolling Friction Or Aerodynamic Drag http://q12.org/cgi-bin/wiki.pl?RollingFrictionOrAerodynamicDrag |
| ||
Thanks Wayne - thats what my function above is supposed to do but I'm probably missing something ...Function LinearDamp(body,damp#) dBodyAddForce body,dBodyGetLinearVelX(body)*-damp,dBodyGetLinearVelX(body)*-damp,dBodyGetLinearVelX(body)*-damp End Function |
| ||
| Willy, I see your cut and pasting is causing you trouble (x,y,z). 8) Function LinearDamp(body,damp#) dBodyAddForce body,dBodyGetLinearVelX(body)*-damp,dBodyGetLinearVelY(body)*-damp,dBodyGetLinearVelZ(body)*-damp End Function ps. Thanks for the code assist VIP3R. |
| ||
| LMAO HAHAHAHAHA you're RIGHT :) Cor.... hows I miss that? |
| ||
| Jedive - perhaps the collision stuff should detect geometry collision instead of rigid body (for trimesh as well etc) |
| ||
| dBodyGetForce(ode\body) not loading vectors ?? I'm using the following code snip: Not dampining angular momentum yet.. 8) |
| ||
| Here is all the code in context: |
| ||
| This modified sphere Demo shows one way to do linear and angular damping to simulate friction. I'm sure there are other ways to do this too. Some primitive 3d sound concepts commented out. enjoy |
| ||
| Cheers Wayne, I'll take a look at that code now. @Flying: I may be confusing ERP & CFM, they're used for dampening forces on springs mainly. |
| ||
| Just one question .. does it freeze like the previous attempts to do this? I LOVE using ODE and if this is stable it will make my YEAR! :) |
| ||
| Arkon's wrapper did the freezing thing... this is competely different wrapper done by different ppl. And this one WORKS. |
| ||
| Hello PsychicParrot :) No freezing in this wrapper you'll be glad to hear ;) |
| ||
| Then consider me a customer :D WOOT! |
| ||
| In fact .. cha-ching! I AM a customer :p |
| ||
| :) Issues I would like to see dealt with: * a bank of collisions so we can loop through all the collisions in a similar format to countcollisions on blitz - returning the GEOM we collided with (as trimesh and others often don't have bodies) * per-rigidbody mass and friction settings - including setting the bounce for trimesh SEPERATELY from the bounce of rigidbody to rigidbody. The response between 2 rigidbodies will often be very DIFFERENT to the response with trimesh for example. ie. pool - the perfect example. The pool table dampens bounce by around 0.6 but ball to ball transfer is more like 0.99 in dampening of the energy transfer (or bounce = .99) Therefore for many simulations we'd like a lot more information and feedback. I know that jedive said he was working on this, and that makes this library VERY attractive to buy. So if it happens, I'll start really recommending it as it's a lot more extra work for jedive and viper. |
| ||
| cha-ching! Nice one PP :) @Flying: Per-body mass should already be working, we'll definitely see what we can do for the other bits and bobs too ;) - I'm looking forward to seeing that snooker game btw. @Wayne: Thanks for sorting the codebox stuff mate, and nice work with those demos ;) |
| ||
| Welcome PP |
| ||
| Thanks Viper! I also need to set the bounce of the trimesh seperately from the rigid bodies - is this possible? |
| ||
| i think that the linear and angular dumping is better doing this: dumpfactor# = 0.8 ; (value between 0-1) vx# = dbodygetlinearvelx(b) vy# = dbodygetlinearvely(b) vz# = dbodygetlinearvelz(b) dbodysetlinearvel(b,vx#*dampfactor#,vy#*dampfactor#,vz#*dampfactor#) And the angular the same but using getangular and setangular... I use them in my car demo and then i set the dumpfactor# as i need. |
| ||
| The reason ADDVEL is used instead of SETVEL is because setting the velocity or position is considered more unreliable as the simulation is in progress. |
| ||
| Thanks, Wayne! Having started with Vodermanns ODE, gone to Tokamak, moved to 'other' ODE then over to this one .. it's getting really hard to keep track of my damping velocities!! I really hope this is the end of my physics journey - so far, so good :) |
| ||
| All of those setting velocities directly should note: The ODE User Guide specificly states that you should avoid setting velocities directly every time step where possible (except initial setup). You will end up abusing the built in physics model (forcing ODE to do something rather than let it happen naturally). If you set everything up properly using force, friction and torque, ODE should do all of the hard work for you. For more info on this, read the ODE User Guide (link in top post) Section 12.6. Just some food for thought ;) |
| ||
| I'd like to see a demo using multiple spaces like talked about in the ODE manual. I've included the section from the manual here: A collision detection ``world'' is created by making a space and then adding geoms to that space. At every time step we want to generate a list of contacts for all the geoms that intersect each other. Three functions are used to do this: * dCollide intersects two geoms and generates contact points. * dSpaceCollide determines which pairs of geoms in a space may potentially intersect, and calls a callback function with each candidate pair. This does not generate contact points directly, because the user may want to handle some pairs specially - for example by ignoring them or using different contact generating strategies. Such decisions are made in the callback function, which can choose whether or not to call dCollide for each pair. * dSpaceCollide2 determines which geoms from one space may potentially intersect with geoms from another space, and calls a callback function with each candidate pair. It can also test a single non-space geom against a space. This function is useful when there is a collision hierarchy, i.e. when there are spaces that contain other spaces. The collision system has been designed to give the user maximum flexibility to decide which objects will be tested against each other. This is why are there are three collision functions instead of, for example, one function that just generates all the contact points. Spaces may contain other spaces. These sub-spaces will typically represent a collection of geoms (or other spaces) that are located near each other. This is useful for gaining extra collision performance by dividing the collision world into hierarchies. Here is an example of where this is useful: Suppose you have two cars driving over some terrain. Each car is made up of many geoms. If all these geoms were inserted into the same space, the collision computation time between the two cars would always be proportional to the total number of geoms (or even to the square of this number, depending on which space type is used). To speed up collision a separate space is created to represent each car. The car geoms are inserted into the car-spaces, and the car-spaces are inserted into the top level space. At each time step dSpaceCollide is called for the top level space. This will do a single intersection test between the car-spaces (actually between their bounding boxes) and call the callback if they touch. The callback can then test the geoms in the car-spaces against each other using dSpaceCollide2. If the cars are not near each other then the callback is not called and no time is wasted performing unnecessary tests. If space hierarchies are being used then the callback function may be called recursively, e.g. if dSpaceCollide calls the callback which in turn calls dSpaceCollide with the same callback function. In this case the user must make sure that the callback function is properly reentrant. |
| ||
| Kurix, I like that simple method for some simulations. It's great we have the flexibility to be simple or complicated. I'm playing around with Air, Water, Ground, and Ice to see what kinda MAYHAM I can create. *cheers* |
| ||
| Only a question:Is there any documentation about the commands ? Thanks |
| ||
| Is there any documentation about the commands ? http://ode.org/ode-latest-userguide.html PDF: http://ode.org/ode-latest-userguide.pdf |
| ||
| I learned that one should check collisions before stepping the world. The article is here: http://www.cambrianlabs.com/mattias/DelphiODE/UsingDelphiODE.asp Revised Spheres Demo to collision check before WorldQuickStep, and add friction on each collision contact. Not sure if autodisable is working for me in this example or not. Nice simulation. Lots of new ODE stuff to learn and try. |
| ||
| Not sure if autodisable is working for me in this example or not. No, auto disable is turned off by default. It won't be working in the code above as you haven't activated it. This will tell you the current state of world auto disable: Text 0,30,"Auto Disable:"+dWorldGetAutoDisableFlag(World) You would do this to turn world auto disable on: dWorldSetAutoDisableFlag(World,1) ; <<< 1=On - 0=Off [edit] Ooops, forgot to mention these... The following will return the current state of a body auto disable: dBodyGetAutoDisableFlag(ode\body) You would do this to turn a body auto disable on: dBodySetAutoDisableFlag(ode\body,1) ; <<< 1=On - 0=Off |
| ||
| Below, I was proposing that you show a demo version of your wrapper. But I forgot that in this case you have to distribute the dll, and that's obviously not good. So I have another proposition: make a movie of your engine in action, in different situations. With the code that's used for this demo. I think it could be a good replacement... |
| ||
| I hope the JV-ODE guys will compile the demo programs and distribute the B3d demo source, B3d demo exe, and ode.dll. This would allow people to see the demo in action and view the source. This would not allow people to compile new stuff because it's sans the decls. Distributing the ode.dll is a normal part of distributing your game software. |
| ||
| I've already made a restricted demo DLL that works on a time limit, which should be safe to distribute. The demo will contain: ode.dll (restricted version) ode.decls (restricted version) ode.bb .bb demos I don't think it would be wise to distribute demo exe's, the main reason for this is that the user will have a much larger download to deal with. Once Jedive ok's it, I'll release the demo version. |
| ||
| Demo Version Now Available! Ok, Jedive has given the green light for the demo version. I've placed a download link in the top post of this thread. |
| ||
| Being a total noob to al this, I'd like to ask one maybe dumb question; Could this sort of physics be used to keep a model slot car's guide "in the groove" ? I am pondering if a bunch of us could get together and come up with such a system. Be an unusual community learning process I'd imagine. Been a long tme since there was a good open source community project for slot cars. Good for model makers and track designers alike too I suspect. |
| ||
| First off I'd just like to weigh in wih how great this wrapper is! Good Job Jedive and VIP3R. I just have a quick question since this problem is starting to drive me crazy! Has anyone come up with a good way of modelling the physics of a standard fps or 3d platformer type character using ODE. I've been experimenting using a sphere but I can't stop it from rolling around like a drunk skateboarder :). Any ideas here would do a great deal to preserve my sanity. Thanks |
| ||
| I think once the bug with cubes/rectangles vs trimeshes is fixed that doing fps/platformer stuff will be very straightforward... the guys have done such a great job with this wrapper and I don't want to hassle 'em, but it is a fairly big ommission. Your other option is to keep all platforms as cubes, rectangles or spheres but you'll have to make physics objects for every platform. Once the trimesh>cube stuff is sorted, you'll be able to use an 'collision cube' to just jump and run around a level you make in whatever 3d package. They're working on it .. so I will wait quietly. If they've got this far, I'm sure they can sort it out :) |
| ||
| I don't think ODE will provide a totally stable simulation in this instance as at high speeds it will be dependant on the polygon density of the grooves. Instead I believe you should fake it by a mixture of ode and on-rails code. |
| ||
| The theme is make it stop. I made a number of changes to the car trimesh demo including UpdateGeoms(). Now everthing that moves will turn green and when stopped will turn red. This new demo shows friction damping, and use of autodisable with thresholds. enjoy |
| ||
| Thanks Willy, what terms should I search for to learn more of on-rails code? Do you think it's in this vast forum somewhere? I mean I'll try the obvious search terms of course, but if anything particular comes to mind then I'd like to hear about it? Would this be true for say a marble running down a channel too? (I'm gussing they are similar, although maybe that's more likely to be slow/dense enough to be ok there?) I'm ok with modelling objects but the coding is new for me in this stuff. |
| ||
| Talking of mesh density, how do you go about getting your own externally built mesh to work with ODE? Using the slot car analogy I used earlier, I can make a terrain and a slot cut into it and a car with a guide post, but how on earth would you load them up and get ODE to know about it all in the first place? And what of hanging the tail out in bends etc? Seems so tantalisingly close yet so far from grasp! |
| ||
| I think the best way to do this is build a list of scalectric style track parts in 3D - including grooove, but make the groove twice as deep as it normally is. Then we use the CreateTriMesh code as seen in the examples, toy convert our list of track parts into a single mesh and output the result to ODE. Then, you could get away with having a proper car with pin in the groove. To this end, you'll need to start playing with the examples.... I think it can be done in ODE if you're careful and you make the slots deeper than they need to be (and pins slightly longer) to give ODE more of a chance to remain stable. |
| ||
| I think I'm now in a bit of a "catch 22" situation, I have been watching the JV-ODE threads with great interest and noted that the tri mesh may still have some issues; and so have held off actually buying into it, but I have last night grabbed the demo, and sadly I can't see if it can do what I'd like before buying into it as far as I can tell. (having said that it is early days still.) As for making the track, yes, that's completely trivial for me. As for depth of slot, then if told the depth to make it, then it wil be that depth. If only I could code well enough and had enough confidence to try that side of it then this could be in the bag. I got the impression you have been waiting on this wrapper to get on with your own projects, and as such you'll prbably be very busy about now, but if you or anyone else here feels cosy enough with it to have a go, the I'd be happy to make tracks and cars (which is the really easy bit for me!) I may not be able to contrubute to coding yet, but in the meantime I can do those bits I really know about. BTW, if it were to follow the slots well, then yoiu'd not be limited to "scalextric" types, you could easily make the pro types which can be far more fun to drive. I also suspect that a net play mode would be a total winner too assuming the networking side is up to it (these little cars can move very quickly indeed when given enough room!) Normally you'd have to go split screen, but net play means you could easily race 8 cars at once I'd imagine, as each polayer has their own screen and own camera setup, thus freeing this genre from it's past limitations. Sorry, got a bit carried away there, but this represents a bit of a break through for this area of gaming! ;O) I'm up for designing custom USB controllers too! ;O) |
| ||
| well that sounds very interesting. The pro stuff is brilliant as you can probably set them off on remote and the speed changes... some professional kits hook up to the pc. I can't promise I'll get involved though I'd like to look at the basic physics + trimesh thing if I get time. |
| ||
| I discovered that boxes and cylinders are not colliding with the trimesh, but spheres are. The following car trimesh demo shows the problem. |
| ||
| @Wayne; Thanks for the heads up. Appreciated. @Willy; Since there seem to be some issues about whether or not it can work just yet, the best thing I can do to be practical is to get on and make some demo models of track and cars and then watch this space to find out when the trimesh thing gets fixed and then allows further progress. I'm not a fan of low poly myself, but do I NEED to be a bit squeamish to get good results with ODE? I understand that the slot interiors might benfit from higher poly count from what you said though. I guess the same would go for the guide running in it too? Right, now to model "slots" from 30/35 years ago (from memory!) This could prove interesting. Retro leading edge it is then! ;O) |
| ||
| Wayne: I discovered that boxes and cylinders are not colliding with the trimesh, but spheres are. These issues were mentioned in the top post of this thread when the wrapper was released. Please read Known Issues In V1.00. This isn't a problem with the wrapper itself, the original C++ ODE demos suffer with the exact same issues regarding the TriMesh. We are however working very hard on resolving the TriMesh issues. I'm gonna make a big flashing neon 'Known Issues' sign first tho... ;) |
| ||
| Well I have total confidence that you will be able to solve these issues. Arkon's wrapper allows collision between cylinders, cubes and the trimesh as well so it definately can be achieved. I look forwards to your hard work, and given the amount you are both obviously putting into it, I am sure it's worth more. My current feature request list is like this: * cylinder and box to trimesh resolved * a countcollisions() sort of thing similar to blitz where the body or geom of my choice will return the collisions with other geometries... I say geometries because you can have collisions with geom without a body (for the level or trimesh etc)... for immovable things. * some way of setting the bounce, mass and friction on a per-object basis * being able to set an id per tri for trimesh or something... so we can make bits slippery or find out if the player walks on metal for a clanging sound etc... not essential but nice... * different bits of trimesh have different physics? maybe going too far here! A mate of mine was using trimesh and ode in C++ and he claims that by adding lots of seperate trimeshes, the ode simulation slows down to a crawl. Might be something to consider... Anyway good luck with this! |
| ||
| dont you think its a bit cheap to sell a wrapper for something someone else released for free, shouldnt you give the ode guy some with each sale. |
| ||
| The directX SDK is available for free, but Blitz3D, effectively a friendly wrapper around DirectX, costs money - you pay for the efforts of the person who wrote it and so you don't have to write it yourself, and in many cases because you couldn't write it if you wanted to. |
| ||
| VIP3R, Sorry I missed the known issues DOH!! |
| ||
| If you don't want to pay for their work, go ahead and download ODE, and see how easy it is to convert to a DLL yourself. Or hire someone to do it for you and see how cheap it is. |
| ||
| I got no problem paying what they ask in principal, far from it, I'm dying to use the plastic to both of our good. However I have got to wait to see if they fix it up enough so that it does what I want of it before buying into it. I've every confidence that if they got this far they can go the rest of the distance. If I don't wait, then experience has taught me there will be some clever so and so pointing out that I should have researched it better before buying and then I'd have known it can't yet do what I want. Having said this I do wish it would hurry up and make it clear that it can do what I want it to! ;O) Busting for a proper play with it all! |
| ||
| I wish I took polygoon's advice because right now it cannot do what I need. |
| ||
| @ Willy, sorry to hear that; what was it you wanted it to do? |
| ||
| most essentially: * cylinder and box to trimesh resolved * a countcollisions() sort of thing similar to blitz where the body or geom of my choice will return the collisions with other geometries... I say geometries because you can have collisions with geom without a body (for the level or trimesh etc)... for immovable things. * some way of setting the bounce, mass and friction on a per-object basis For example, a snooker ball will bounce off a cushion differently from bouncing off another ball. You also need to know when things collide to play sound effects, incur damage and so forth. ODE is fairly useless at the moment for anything but a tech sim. |
| ||
| Fellas, it's really disheartening to read this stuff :/ You know full well we are working hard to add these features you've requested Flying. Please try to stay positive and patient while these issues are addressed. |
| ||
| I think you're being a little bit sensitive. ODE right now isn't suitable for a game, it WILL be of course, but I'm answering his question which was "Willy, sorry to hear that; what was it you wanted it to do?" And so I said it's fairly useless at the moment -- bearing in mind I'm talking about my project. I didn't mean to hurt your feelings. |
| ||
| Jedive and VIP3R, I wanted to say you guys are doing great! Having purchased early on I understood this work in progress may take some time. I accept that because I strongly believe ODE is the best game in town. The added development time gives me the opportunity to learn more about ODE, experiment with the demos, and appreciate physics in general. ODE makes physics fun! Thanks guys, you guys have my support and if there is anything I can do to help please let me know. |
| ||
| What I suggest is higher standards of support (which they are working on) as well as higher prices. |
| ||
| Thanks Wayne, it's good to hear you're having fun playing around with the physics :) @Flying: No problem, you didn't hurt my feelings. It's just a little frustrating for me to read that you think in its current form the wrapper is of no use to you for anything other than a tech sim. I feel the wrapper is doing its job very well so far, that is to provide access to almost everything the ODE library can offer. It's also important to note that the current TriMesh collision and cylinder issues are due to the original ODE code, not the wrapper itself. Speaking of support, I do wish that Jedive would participate in this thread a little more tbh, but I guess he's still too busy with exams at the moment. |
| ||
| @ Willy, yeah, I reckon they will make you smile before you know it. Your best interests are thier best interests after all! @Wayne, agreed I'm sure they will get there, they got a track record with this thing after all, and so afr it speaks of overcoming adversities. @VIP3R, I know you'll get it, would some nice mesh to play with be a positive enough incentive? I'll do it if it helps. |
| ||
| Viper - so you're carrying the can solo? damn man, up the price! |
| ||
| Hi guys. I am extremely busy these days with my last exams, and I haven't checked this thread. I will finish them tomorrow, and in two days, I'll post here about how the next update is progressing (the collision stuff flying willy requested and that), and my plans for future updates. Except for the box/cylinder to trimesh collision bug, the rest of the stuff is pretty easy to do. I hope that for the end of this week, we can have a new update ready. Sorry for all the inconveniences these days, but apart from coding, I also have a job, and am trying to finish my career. Once my exams are finished (this is, tomorrow), getting the next JV-ODE update ready is my first priority. More soon! |
| ||
| I just bumped into this proggy (haven't tried it yet): http://odeed.org/ |
| ||
| @polygoon: Sure, if you want to make a mesh for the TriMesh testing feel free. |
| ||
| Here I am again. Yesterday, I finished my exams. After a long session of sleeping :), I am ready to continue the work on this library! In the few time I had these days, I were trying to write a .dba file to use JV-ODE on DarkBASIC Pro, but there seems to be a bug in DBPro when catching a float value returned from a Dll. I'll take a look at it later, but for now, I have other priorities. I have currently added the following functions to the library: dGeomContactSetMode(geom,mode):"odeGeomContactSetMode@8" dGeomContactGetMode%(geom):"odeGeomContactGetMode@4" dGeomContactSetMu(geom,mu#):"odeGeomContactSetMu@8" dGeomContactGetMu#(geom):"odeGeomContactGetMu@4" dGeomContactSetMu2(geom,mu#):"odeGeomContactSetMu2@8" dGeomContactGetMu2#(geom):"odeGeomContactGetMu2@4" dGeomContactSetBounce(geom,bounce#):"odeGeomContactSetBounce@8" dGeomContactGetBounce#(geom):"odeGeomContactGetBounce@4" dGeomContactSetBounceVel(geom,vel#):"odeGeomContactSetBounceVel@8" dGeomContactGetBounceVel#(geom):"odeGeomContactGetBounceVel@4" dGeomContactSetSoftERP(geom,erp#):"odeGeomContactSetSoftERP@8" dGeomContactGetSoftERP#(geom):"odeGeomContactGetSoftERP@4" dGeomContactSetSoftCFM(geom,cfm#):"odeGeomContactSetSoftCFM@8" dGeomContactGetSoftCFM#(geom):"odeGeomContactGetSoftCFM@4" dGeomContactSetMotion1(geom,motion#):"odeGeomContactSetMotion1@8" dGeomContactGetMotion1#(geom):"odeGeomContactGetMotion1@4" dGeomContactSetMotion2(geom,motion#):"odeGeomContactSetMotion2@8" dGeomContactGetMotion2#(geom):"odeGeomContactGetMotion2@4" dGeomContactSetSlip1(geom,slip#):"odeGeomContactSetSlip1@8" dGeomContactGetSlip1#(geom):"odeGeomContactGetSlip1@4" dGeomContactSetSlip2(geom,slip#):"odeGeomContactSetSlip2@8" dGeomContactGetSlip2#(geom):"odeGeomContactGetSlip2@4" dGeomContactSetDefaults(geom):"odeGeomContactSetDefaults@4" This basically allows to define contact parameters for each geom, instead of global ones. So now each geom can have different bounce values, etc. After that, I will make each geom store in a list all the collisions detected in the last collision test. You will be able to retrieve the number of collisions for each geom, the geoms it has collided with, and the standard contact point information. That's what I am currently busy with, and I don't think it will take much time. I hope we can have a new release this weekend. Once I am done with the new collision commands, I'll try to find out why some geom classes fail when colliding with trimeshes. I'll try to have it fixed for the new update. |
| ||
| Excellent new Jedive, I got a car more or less finished to my satisfaction. Next I'll start on the track. Then I'll make the "guide post" for the slot in the track. Then we'll be in a postion to out if the lib can help make multiplayer networked slot car racing a reality! I really would like to see it happen as I suspect it could be a lot of fun to play with. |
| ||
| Jedive & Viper .. The whole reason I bought the lib was because I believe in what you are doing and (thanks to the mighty Vorderman) I love the ODE physics model. I don't expect everything to be done overnight and I know that there are projects I can put the lib to good use on, so I'm happy and I'm sure you will get nothing but support from those of us who 'took the plunge'. Programming indie style is about having most of the solution, then having to use our imagination to make it good :) |
| ||
| yup, what PsychicParrot said. I agree 100%... thumbs up! |
| ||
| Thanks for the support fellas, both Jedive and myself really appreciate it :) Here is another little demo to play around with, this one shows a simple rope effect using ball joints. Notice the top sphere joint is attached to '0', which means it's a static joint and won't move from its set position. |
| ||
| Added hanging light to end of rope. 8) |
| ||
| Cool! |
| ||
| New and improved light on rope. |
| ||
| Hey, I like that light on a rope idea Wayne, good stuff :) I've modified all of the demos slightly to correct the main loop sequence. I thought it would be better to call dWorldQuickStep after UpdateGeoms(), the same as the car demos. I've updated the rope demo code above to show this. The key detection routine has also been moved out of the main loop in that demo now. The updated demos should be available in the next update. |
| ||
| I'm hoping box/cylinder to trimesh collision stuff can be resolved easily. I have a project that could use the box trimesh collision thing the most. The additional Jedive functions make it really sweet. I'd like to test changing physics on the fly based on the terrain the body is over. So terrains with water, mud, ice, rock and so on can all play a role in the interactions. |
| ||
| i'm trying to understand this - a little difficult because of lack of docs. why in the car demo in UpdateCar() do you do this? For count=1 To 4 dBodyEnable(Wheel(count)) Next dBodyEnable(Car) the ode docs claim that unless you disable a body, it is enabled. what is the purpose of this code, then? it works fine without it. |
| ||
| cannot wait for collision detection code! this silent colliding is creepy! just my 2 cents. i am liking this package, glad i bought it. |
| ||
| i have to ask more questions - before i bother to use physics for everything, the question is - should I? should i run 30 cars around the screen at once, colliding with each other, using ode, or will it start to get too slow? should i use physics on the bullets i'm shooting at those cars, or is that taking it too far? i have no sense of the impact this engine will have on my game so any insights would be appreciated! |
| ||
| the ode docs claim that unless you disable a body, it is enabled. what is the purpose of this code, then? The body enable code was left in so that the car doesn't become disabled if a user decides to activate the auto-disable mode while playing around with the demo. Glad to hear you are enjoying the wrapper :) |
| ||
| i have no sense of the impact this engine will have on my game so any insights would be appreciated! The best advice I can give you is to experiment with different ideas, there would be no point in using ODE for situations where you don't really need it. Also, if you look at the demos you can see a physics timer in the main loop. You can use this timer to help judge the impact of the physics engine. Try to keep the physics time as small as possible as this will obviously affect the overall speed of the game. |
| ||
| please excuse my beginner questions! (it seems like we need a multi-threaded group for this wrapper, not just one thread!) if i have a level made of various objects, and i want my car to interact with them, i need to make all those objects be handled by ODE, is that not correct? is there something in ODE that keeps it from running unecessary collision calculations when objects are nowhere near each other? i would *assume* so.. |
| ||
| Yes, let ODE handle your objects. Yes, there are several somethings in ODE to keep unnessasary calculations in check. ; First, inform ODE your going to disable objects once they become idle. dWorldSetAutoDisableFlag (World, 1) ; Second, inform ODE which bodies will be allowed to auto disable. dBodySetAutoDisableFlag(ode\body,1) ; Third, optionally define what idle means. dBodySetAutoDisableAngularThreshold(ode\body,.05) dBodySetAutoDisableLinearThreshold(ode\body,.05) dBodySetAutoDisableSteps (ode\body, 1) ; Lastly, I modify the B3D routine UpdateGeoms so it doesnt do extra work. The manual covers the topic very well: ------------------------------------------- 6.5. Automatic Enabling and Disabling Every body can be enabled or disabled. Enabled bodies participate in the simulation, while disabled bodies are turned off and do not get updated during a simulation step. New bodies are always created in the enabled state. A disabled body that is connected through a joint to an enabled body will be automatically re-enabled at the next simulation step. Disabled bodies do not consume CPU time, therefore to speed up the simulation bodies should be disabled when they come to rest. This can be done automatically with the auto-disable feature. If a body has its auto-disable flag turned on, it will automatically disable itself when 1. It has been idle for a given number of simulation steps. 2. It has also been idle for a given amount of simulation time. A body is considered to be idle when the magnitudes of both its linear velocity and angular velocity are below given thresholds. Thus, every body has five auto-disable parameters: an enabled flag, a idle step count, an idle time, and linear/angular velocity thresholds. Newly created bodies get these parameters from world. The following functions set and get the enable/disable parameters of a body. void dBodyEnable (dBodyID); void dBodyDisable (dBodyID); Manually enable and disable a body. Note that a disabled body that is connected through a joint to an enabled body will be automatically re-enabled at the next simulation step. int dBodyIsEnabled (dBodyID); Return 1 if a body is currently enabled or 0 if it is disabled. void dBodySetAutoDisableFlag (dBodyID, int do_auto_disable); int dBodyGetAutoDisableFlag (dBodyID); Set and get the auto-disable flag of a body. If the do_auto_disable is nonzero the body will be automatically disabled when it has been idle for long enough. void dBodySetAutoDisableLinearThreshold (dBodyID, dReal linear_threshold); dReal dBodyGetAutoDisableLinearThreshold (dBodyID); Set and get a body's linear velocity threshold for automatic disabling. The body's linear velocity magnitude must be less than this threshold for it to be considered idle. Set the threshold to dInfinity to prevent the linear velocity from being considered. void dBodySetAutoDisableAngularThreshold (dBodyID, dReal angular_threshold); dReal dBodyGetAutoDisableAngularThreshold (dBodyID); Set and get a body's angular velocity threshold for automatic disabling. The body's linear angular magnitude must be less than this threshold for it to be considered idle. Set the threshold to dInfinity to prevent the angular velocity from being considered. void dBodySetAutoDisableSteps (dBodyID, int steps); int dBodyGetAutoDisableSteps (dBodyID); Set and get the number of simulation steps that a body must be idle before it is automatically disabled. Set this to zero to disable consideration of the number of steps. void dBodySetAutoDisableTime (dBodyID, dReal time); dReal dBodyGetAutoDisableTime (dBodyID); Set and get the amount of simulation time that a body must be idle before it is automatically disabled. Set this to zero to disable consideration of the amount of simulation time. void dBodySetAutoDisableDefaults (dBodyID); Set the auto-disable parameters of the body to the default parameters that have been set on the world. |
| ||
| Hi, just started using this wrapper and it seems very stable :) I wondered if anyone knows a good way to push/pull an ODE object around, I want to be able to slide a rectangle over a plane by pushing/pulling? |
| ||
| Hi CopperCircle, Yeah, you can do that by adding force to the object like so... dBodyAddForce(ode\body,10,0,0). You would also need to set the world friction quite low to stop it dragging too much, which will cause it to roll over. There are a number of commands related to moving an object like this: dBodyAddForce(ode\body,fx#,fy#,fz#) dBodyAddTorque(ode\body,fx#,fy#,fz#) dBodyAddRelForce(ode\body,fx#,fy#,fz#) dBodyAddRelTorque(ode\body,fx#,fy#,fz#) dBodyAddForceAtPos(ode\body,fx#,fy#,fz#,px#,py#,pz#) dBodyAddForceAtRelPos(ode\body,fx#,fy#,fz#,px#,py#,pz#) dBodyAddRelForceAtPos(ode\body,fx#,fy#,fz#,px#,py#,pz#) dBodyAddRelForceAtRelPos(ode\body,fx#,fy#,fz#,px#,py#,pz#) Feedback Needed: There have been a small number of reports where users are getting 'userlib function not found' errors on the World=WorldCreate line of the restricted demo version. I'm looking into this, but it would be very helpful if anyone who has experienced this problem could give me some feedback. As soon as I have more info on this, I'll post an update here... More soon :) |
| ||
| Ok, all the new collision stuff is ready. It should have taken less time to finish, but it seems it was a problem with the std::vector object in Dev-C++, which I used to store the list of collision points. Two days ago, a new version of Dev-C++ (4.9.9.2) were released. I installed it and everything compiled fine, so I could finish the functions. I have just sent the new update to VIP3R. If he says it is OK to release, I'll make a new .zip file and send it to everyone. The list of functions to get detailed collision information is as follows: dGeomCountCollisions%(geom) ;Number of collisions the geom got in the last dSpaceCollide() dGeomCollisionGeom%(geom,index) ;The geom with which this geom has collided. Index starts at '1' dGeomCollisionX#(geom,index) ;Global X coordinate where the collision occured dGeomCollisionY#(geom,index) ;Global Y coordinate where the collision occured dGeomCollisionZ#(geom,index) ;Global Z coordinate where the collision occured dGeomCollisionNX#(geom,index) ;X component of the collision normal dGeomCollisionNY#(geom,index) ;Y component of the collision normal dGeomCollisionNZ#(geom,index) ;Z component of the collision normal dGeomCollisionDepth#(geom,index) ;Depth of the collision |
| ||
| Coolness! Does it include also somekind of a demo-let that shows all these new collision stuff in action? |
| ||
| This modified sphere demo lets you push and pull the balls around with the mouse. Also demonstrates the autodisable feature to reduce physics overhead. enjoy |
| ||
| Bah, I've downloaded the new C++ compiler and it's broken (the compiler not the wrapper) :/ As soon as I've got it working again (shouldn't take very long) I'll test the new dll to make sure everything is ok. Once I've done this I'll get back to Jedive and give him the green light for release. @Mustang: Yeah, we'll be adding some new demos to show the new collision and contact stuff. We can either release the update now (once tested) without the new demos, and release the demos in a few days. Or... We can get the demos ready first, then release the whole thing early next week. Whatever you guys are happy with... let us know :) |
| ||
| I'll take the code now and demos next week. Keep it flowing man.. 8) |
| ||
| Yeah, release the stuff now and add demos later... although I personally would like to get my hands on those contact / collision demos very much since I'd like to see how to do those properly with JV-ODE. |
| ||
| SEND THE CODE ! Collision stuff looks simple to me. 8) |
| ||
| Ok, once I'm done testing the new version will be released without the demos initially, as long as Jedive is ok with that. I'm still having problems with the compiler at the moment, tried for several hours to get it working last night. Hopefully this will be resolved very soon, I'll let you know how it goes later. Btw, that pull/push demo is pretty cool Wayne, nice job ;) |
| ||
| Sorry for the delay everyone. Well the good news is I've finally managed to fix the broken compiler problem. The updated wrapper was causing a problem with the old compiler initially, so Jedive upgraded his compiler and found it cured the problem and of course advised I did the same. But after I did the upgrade it broke completely, which obviously meant I couldn't compile the new dll and test it. I've spent endless hours trying to sort it out without success, so in desperation I switched back to the old compiler to try and fix the problem Jedive originally had. I've finally figured out how to fix it so I can now test the dll properly. Now I remember why I hate C++ so much ;) I've tested the new wrapper briefly and everything is looking great so far. The new collision and contact stuff appears to be working really well, Jedive has done a fantastic job! I'm going to finish the testing over the next few hours and if all is well then we can get the new wrapper out sometime later today/tonight. The new dll is slightly larger now (739KB) so I may try and compress it some more. I'll post here as soon as I'm done... more soon :) |
| ||
| I'm really excited about the next release :D Can't wait!! |
| ||
| Me to :D Go VIP3R, Go VIP3R, Go VIP3R, Go Jedive, Go Jedive .... :) /Alienforce |
| ||
| Well, why we're all sitting quietly .. can anyone help me to understand mass settings on a sphere? I confused myself to levels of epic proportions!! I got.. mass=dMassCreate() dMassSetSphere(mass,1,0.7) dMassSetSphereTotal(mass,WMass,0.7) dBodySetMass(another\body,mass) dMassDestroy(mass) I took that ^ from the car demo (one of the wheels) but when I try and pop it into my own game, where I have a sphere on a trimesh, the sphere instantly disappears into oblivion so I can't even see what it's doing! .. how does the dMassSetSphere and dMassSetSphereTotal commands work? What do they want from me? ;) I can't seem to find anything in the ODE docs, so I just wonder what the params are .. which ones are weight and which are sizes?? Is that how it works? You create a mass object that you 'build' the same size as your physics obj, then apply the mass obj to the physics obj? :S <pop goes my head> Any help anyone can give would be fantastic .. otherwise, I'll just carry on sitting here quietly ;) Thanks! Parrot. |
| ||
| @PsychicParrot: In the car demo the mass settings are like this... dMassSetSphere(mass,1,0.7) Here the '1' is the density of the sphere and the 0.7 is the radius of the sphere (same as the radius of the geom). dMassSetSphereTotal(mass,WMass,0.7) Here the 'WMass' is the total mass of the sphere and again the 0.7 is the total radius. The only things you would need to adjust are the density, radius and total mass. If the sphere shoots off when hitting the TriMesh, either you have the mass or density set too high or too low. Don't forget the total mass is relative to the mass of all other objects and also relative to the gravity and world settings (including the TriMesh). I'll try and make a demo to explain this better over the coming days :) I'm building the new update zip now so it should be ready in an hour or so, I'll post here later when it's released... :) |
| ||
| JV-ODE Physics Wrapper V1.01 RELEASED! Please check your inbox ;) I've sent out an email to every user. If for any reason you have not received it, please let me know. Have fun :) |
| ||
| WooHoo! The list of changes looks great. The demos look nice and clean, great job. I'll be hacking on the demos shortly to show off some interesting effects. Also looking forward to cubes and cylinders with trimesh. Great going guys, I'm really sold on this purchase and can't imagine anyone not taking advantage of this. I hope this will work with BlitzMax too, or I'll have to buy it again. 8) I can't wait to try the new stuff. Thanks Jedive and Vip3r Heres a recap of the changes: JV-ODE Physics Wrapper Version History Note: The current TriMesh/Cylinder issues will be worked on for the next release. With the new collision functions added in V1.01, these issues could be resolved by using a 3rd party collision system if preferred. ### Version 1.01 ### Functions added in V1.01: ### Wrapper --- Now you can set contact parameters per geom, instead of global ones --- dGeomContactSetMode(geom,mode) dGeomContactGetMode%(geom) dGeomContactSetMu(geom,mu#) dGeomContactGetMu#(geom) dGeomContactSetMu2(geom,mu#) dGeomContactGetMu2#(geom) dGeomContactSetBounce(geom,bounce#) dGeomContactGetBounce#(geom) dGeomContactSetBounceVel(geom,vel#) dGeomContactGetBounceVel#(geom) dGeomContactSetSoftERP(geom,erp#) dGeomContactGetSoftERP#(geom) dGeomContactSetSoftCFM(geom,cfm#) dGeomContactGetSoftCFM#(geom) dGeomContactSetMotion1(geom,motion#) dGeomContactGetMotion1#(geom) dGeomContactSetMotion2(geom,motion#) dGeomContactGetMotion2#(geom) dGeomContactSetSlip1(geom,slip#) dGeomContactGetSlip1#(geom) dGeomContactSetSlip2(geom,slip#) dGeomContactGetSlip2#(geom) dGeomContactSetDefaults(geom) --- Added functions to get detailed collision information --- dGeomCountCollisions%(geom) ; # Number of collisions the geom got in the last dSpaceCollide() dGeomCollisionGeom%(geom,index) ; # The geom with which this geom has collided. Index starts at '1' dGeomCollisionX#(geom,index) ; # Global X coordinate where the collision occurred dGeomCollisionY#(geom,index) ; # Global Y coordinate where the collision occurred dGeomCollisionZ#(geom,index) ; # Global Z coordinate where the collision occurred dGeomCollisionNX#(geom,index) ; # X component of the collision normal dGeomCollisionNY#(geom,index) ; # Y component of the collision normal dGeomCollisionNZ#(geom,index) ; # Z component of the collision normal dGeomCollisionDepth#(geom,index) ; # Depth of the collision ### Blitz Demos Corrected all older demos (bounce / auto disable / main loop) Added new AutoDisable demo Added new BouncyWorld demo Added new CarDemo(AutoD) showing how to add body auto disable when static objects are used Added new CarDemo(CCount) showing basic collision counting of geoms Added new Rope demo Many more demos are planned and will be released shortly... ### Version 1.00 ### Initial Release Copyright © 2005 - Javier San Juan Cervera & Jim Williams |
| ||
| Wow - cooooooooool! This is looking SO nice update... have to fire up my main PC, I'm on my laptop right now (no email or Blitz in it). This collision stuff is really important, I have many planned uses for it... just have see if those can be done. Great job! One thing that's good too IMO about JV-ODE is all those demos; I do use physics engines at work but our coders have smoothed the burden of setting low-level settings and stuff considerably and I usually tweak just very few values / settings via script files... so although I know how physics engines work, JV-ODE is the first time for me when I can / have to do low-level set-ups and such... so good demos are very important to me even if I already have years of "experience" (3DMark2001 car gamelet was my first physics enabled game I have "made"). So please, keep those demos coming, they are very valuable! |
| ||
| Wow, this is really good stuff. |
| ||
| Great! wow! This is really looking good.. /Alienforce |
| ||
| Awesome update, guys :) I'm having a blast! Thanks for the help on the mass stuff, Viper - I'll have a proper play in a min. Keep up the great work! |
| ||
| Nice work guys :) downloaded the update this morning thanks. cheers, Lee. |
| ||
| Thanks for the demos guys, they seem to be pretty stable. You know, I sooo much would like to start a new project. I would like to do a cartoonish game including crazy physic everywhere!, but I must finish my other thing first.. Do you remember that cartoon taxi car in the Roger Rabbit film? I loved it :) Have a look a this demo, it is a modified version of the car demo, I hope you don't mind guys |
| ||
| @Eurythmia When you hit the space key on your demo (after the first reset) the car will spin and disassemble itself into nothing. |
| ||
| when are u guys gonna release a full demo of physics on a static mesh, this will be the crucial factor for me on using this physique module. |
| ||
| @Eurythmia: We don't mind you playing around with the demos, that's what they're there for - enjoy ;) @TigerZ: There is already a demo showing static mesh collisions, check out the Car Demo of the restricted version. If you meant a TriMesh demo, this isn't available in the restricted version. There are no plans to add TriMesh stuff to the restricted version at the moment as this is a more advanced feature. The restricted version is intended to show the basics only. Also, there are currently issues related to the TriMesh, take a look at the 'Known Issues' segment in the top post of this thread. |
| ||
| *stops counting* 2 minutes 3 seconds for this thread to load...... Time to start a new one? |
| ||
| How long? I'm on 56K modem here and it still loads faster than that :) I'll create a new thread when this one hits around 140 posts... There is now a dedicated forum area for JV-ODE at the Player Factory... thanks to Beaker! Feel free to post anything JV-ODE related over there too. You can find the Player Factory forums here. |
| ||
| Must just be the network at work :/ seems okay today, plus i noticed the posty count is only medium-high... How long do you think those box>trimesh cylinder>trimesh issues will take to sus out? Im waiting to start Cygnus Car Engine v2. Great bit of work here though! |
| ||
| Thanks Cygnus :) I'm not sure how long it will take to sort out the TriMesh stuff tbh. Hopefully not too long, I want to use them too ;) I'm still working on the new collision/contact demos at the moment, as soon as those are out the way I can concentrate on the TriMesh problem. |
| ||
| Okiedokie. I will stick with what ive got for now, and play with the car engine stuff. I Had some major issues with Arkons, seems to be gone here, but it needs a solid test ;) Really, really enjoying this! |
| ||
| Hi, I am loving the wrapper and find it very stable, just a couple of problems: 1. When I try to use dWorldSetContactSurfaceLayer I get a Memory Access Violation. 2. How can I get a value out of dBodyGetForce etc... if I try to put the result into a variable I get Illegal Type Conversion. Cheers, keep up the good work. |
| ||
| Hi CopperCircle, Ok, no problem. 1) You may be using dWorldSetContactSurfaceLayer incorrectly if it gives you a MAV (see code below) 2) Good question, dBodyGetForce along with some other functions don't return a value directly which is why you receive an Illegal Type Conversion error. You must call the function like this... dBodyGetForce(ode\body) Then you call the vector functions to return the value from the dBodyGetForce(ode\body) function... forcex#=dVectorX() forcey#=dVectorY() forcez#=dVectorZ() It's a little complicated at first, so I've modified the Rope Demo to show both the dWorldSetContactSurfaceLayer and dBodyGetForce functions in action... Let me know if you need any more help with this :) |
| ||
| Hmm, i dont know why, but mine is freezing :'( Im trying to create a cube, thats all :S |
| ||
| ; Retrieve Accumulated Force Vector dbodygetforce(bodyid) Fx#=dVectorX#() Fy#=dVectorY#() Fz#=dVectorZ#() |
| ||
| Can you post some code showing the problem Cygnus? |
| ||
| Hey Viper, I'm new to all this physics stuff, and I was wondering if you and I could just have a chat some weekday night (or weekend) and you just explain to me what I really need, the important stuff from beginning to finish, and then give me insight on how to set everything up and yadadada. I just need someone to teach me one on one and answer questions I have. If you would be willing to do this, please let me know, I'd really appreciate it, or know of someone who would do this for me. Thanks, Chad |
| ||
| Vip3r.. It seems to be me creating something wrong. I will look tomorow and update. Basically, i upped the worldstep to double (and used proper worldstep) and when the car went upside down after jumping, it hung solid. I had to reboot. Same thing quite a few times. i HAVE modified this code though, so before anyone starts thinking his stuffs unstable, its most likely my naff coder skills :P All ive done is make a createobject function: Function createObject.ode_object(obtype,x#,y#,z#,Length#,height#,width#,mass#) compatible near enough with the original ode. I make a single cube... and thats when the crashes happen. IM using the standard car demo with this. |
| ||
| Hi Chad, I can try my best to help answer your questions, no problem. I'm a little too busy for a complete guide to ode at the moment though. Currently I'm working on the new demos and the TriMesh issues, once those are finally sorted out I'm planning on making some sort of beginners tutorial for JV-ODE. But if I can help with any questions in the meantime, feel free to post them here or at the Player Factory. It may also help others too, whereas the one on one tutorial wouldn't. If you haven't read it yet, take a look at the ODE User Guide (link in top post of this thread), it may also help you. @Cygnus: dWorldStep() will make Windows curl up and die, I strongly recommend using dWorldQuickStep() instead. I haven't found any benefit from using the former, it just causes memory problems, hence the lock-up you had and it's slower (with only a slight increase in accuracy). |
| ||
| * ERASED DUE TO MY OWN STUPIDITY! * |
| ||
| dWorldStep() will make Windows curl up and die, I strongly recommend using dWorldQuickStep() with dworldquickstep, everything starts shivering like its got flu or somert :P so i had no choice. ....okay i just realised something With the original ode wrapper i was calling my own update function; updatephysics(1). I assumed i had done it as a simple wrap to worldstep(1). nope.. i was dividing by ten. Thats much better, (update by .2 not 2!!!) :D Problem sorted ^.^ |
| ||
| Righty .. heres my little key controlled sphere thingy that I thought might be of use to someone :) Use the arrow keys to move, space to 'jump'. This could easily be applied to a trimesh perhaps for some kind of physics-powered 3d platform game or similar .. ?? Any offers to do 3d platform game modelling to ... ;) Ta daaaa! There does seem to be a problem with the autodisable, although it may be something I'm doing wrong. For seemingly no reason, ODE seems to disable to body sometimes, so I commented out the autodisable detect in the updategeoms and set autodisable to 0 in the 'world' settings. |
| ||
| Nice one Mr P! Marble-Madness 3D Here i come ;) For issues with autodisable, set both the angle autodisable and linear autodisable threshhold so that you get full control ;) i have no problems with it :) |
| ||
| Feel free to fix my code, mate ;) :p Thanks Cy .. I'll attack it in a bit! |
| ||
| And now .. a slightly different way of doing things, this time using angular velocities to move the ball around rather than forces. This allows a greater control of the ball. Now using my newfound mega-code ;) I'll go away and make a game!! :D BTW: Thanks Cy for telling me about codebox :) |
| ||
| If you still get problems with it i will be around perhaps on saturay a bit. Lookin good there Mr P! [edit] This is the most amonut of times i've seen you post on this forum so far. you MUST be enjoying yourself! [edit] [codebox] [ /codebox] |
| ||
| Cy- I'm having a blast, mate! Reminds me of when I started messing around with Vordy's ODE lib .. I spent days watching things fall over then, too :) |
| ||
| Cygnus: with dworldquickstep, everything starts shivering like its got flu or somert :P so i had no choice There are ways of preventing the 'jitters', but if you've got it working ok with dCreateWorld() then that's good news. Nice one ;) @PsychicParrot: That demo is great! I'll bet that method could be useful in an FPS too :) |
| ||
| ....[edit] I copied PsychicParrots Actions......... |
| ||
| PsychicParrot code updated to use autodisable, and added damping. |
| ||
| Expanded Spheres Demo Features: Autodisable, Applying forces to push and pull spheres with the mouse, Selecting bodies and creating joints between them, Applying forces to attract and repulse. enjoy |
| ||
| Nice work, Wayne :D Thanks! |
| ||
| Yay.. i got cygnus car engine v2.0 started. very nice! no shaking, no slowdowns.. propper collisions.. SMOOTH :D ..up to 32 cars on my system without slowdown, and thats cuz of rendering speed not CPU :) only up to 12 on my old one! |
| ||
| I believe it would be usefull to create a small physics editor. Something that would let us position bodies, set joints, and parameters. Also be nice to run physics simulation in the editor. Output B3d code to initialize these objects in our programs. What you guys think ? |
| ||
| @Wayne. That would be awesome, are you offering to write it, or asking someone else to do it? (Not upto the job myself :( ) |
| ||
| I'll create some specifications for a small one and post it here. I'll write it. I'll create a new thread for it. |
| ||
| Thanks for this Great Wrapper VIP3R. is it possible importing the Terrain-Geometry Datas in ODE ?? (Terrain created with Create Terrain) |
| ||
| Cheers Barton :) It isn't possible to use Blitz Terrains directly with ODE as their geometry constantly changes with LOD. There is a solution though, you can create a terrain 'mesh' from a heightmap (same as Blitz Terrains) with a utility like FLE. You can then supply this terrain mesh to ODE using the TriMesh functions. You can find FLE in the toolbox area of the Blitz website, note that only the full version of JV-ODE supports the ODE TriMesh functionality. |
| ||
| Thanks, i have yesterday about Shareit buy your ODE Wrapper. :) |
| ||
| @VIP3R: must one initialize ode after every Level restart once more? or only once after start of the EXE ? I using the 2. Method (only once start of Exe) and i destroying all Types and Bodys/Geom's manual (after Reload the Level), and recreating new Objects after start new Level. is this Right ? (no problems till now) or should I delete completely and initialize newly ode every time? (but I then get "Memory Access Error" so. Line dSpaceCollide(ODESpace,ODEWorld,ODEContactGroup)) what is better? |
| ||
| I bought your ODE wrapper, so please keep supporting it.. Thanks VIP3R |
| ||
| Barton. Deleting all objects and creating new ones should do fine. Anyway, in the game I am doing with ODE, using the Cipher engine, we are shutting down ODE each time the client exits (at the end of each level), and initializing again when a new level starts. |
| ||
| @Barton: You should be able to use either method without problems, both would work equally well really. If you're getting MAV errors on that line above, make sure you have destroyed joint/space/world properly before re-initializing ODE... dJointGroupDestroy(ContactGroup) dSpaceDestroy(Space) dWorldDestroy(World) Let me know if you still get MAV problems and I'll take a closer look at it. @HyderMan: Of course, welcome aboard :) |
| ||
| I have already deleted ode before I have initialized it newly before. funny... [EDIT: i think, is a Bug in DLL] MAV Error always on Line: dSpaceCollide(Space,World,ContactGroup)) although everything is initialized and destroying before. I use also global variables for World, Space and ContactGroup. hmmm.... |
| ||
| Would you make a small source example which reproduces the error? |
| ||
| look at my example below... |
| ||
| i have create a sample code with this MAV Error.... restart it with SPACE Button and it crashing after reinitialize ode. If you use the other Clear_ODE () method (see sample) with destroying bodys and geoms before destroy/close the ode , then crash the sample after many restarts...ca. > 3-20 test it! i think, is a Bug in DLL. Leaks in communication with Destroying objects / close ode ? only solution short-term: Initializing ode only once and destroy only Types,bodys and geoms. It Works without Problems...but a fault in this nevertheless is. With My Method , ode runs very stably without closing ode and new initialization. I Destroy then only the bodys and geoms and creating new Objects. Works fine, without problems. whether this remains so? 50x Reloading the Level and no problems. Here the Working ODE_CLEAR () Function: Function ODE_CLEAR () For ode.ODEGeom=Each ODEGeom dBodyDestroy(ODE\body) dGeomDestroy(ODE\geom) Delete ode Next End Function AppTitle "JV-ODE - Cubes Demo" Include "ode.bb" Type ODEGeom Field body Field geom Field mesh End Type ; ################################################################################################### ; ### Setup ODE Global World Global Space Global ContactGroup Global Light Global Camera ;============================================= .RESTART Graphics3D 1280,1024,32,2; 800,600,0,2 INIT_ODE () Light=CreateLight() RotateEntity Light,45,-90,0 LightColor Light,255,255,255 AmbientLight 130,130,130 Camera=CreateCamera() CameraClsColor Camera,0,0,0 CameraRange Camera,1,1000 PositionEntity Camera,0,20,-50 RotateEntity Camera,30,0,0 dCreatePlane(Space,0,1,0,0) Plane=CreatePlane() EntityAlpha Plane,0.8 ClsColor 0,0,0 Cls ; ################################################################################################### Close=0 Cls FlushKeys While Close=0 PTime=MilliSecs() If MilliSecs()-Timer>100 AddObject() Timer=MilliSecs() End If UPDATE_ODE () PhysicsTime#=MilliSecs()-PTime UpdateWorld RenderWorld Text 0,30,"PRESSS SPACE TO RESTART or ESC to Quit" Flip If KeyHit (1) Then Close=1 If KeyHit (57) Then Close=2 Wend CLEAR_ODE () ClearWorld 1,1,1 If Close=2 Then Goto RESTART EndIf End Function INIT_ODE () World=dWorldCreate() Space=dHashSpaceCreate(0) ContactGroup=dJointGroupCreate(0) dWorldSetAutoDisableFlag(World,0) dWorldSetGravity(World,0,-5,0) dContactSetMode(dContactBounce) dContactSetBounce(0.1) dContactSetMu(48) dCreatePlane(Space,0,1,0,0) End Function ;--------------------------------------------------- ; ODE Crashing after restarting it 2x ;--------------------------------------------------- Function CLEAR_ODE () dJointGroupDestroy(ContactGroup) dSpaceDestroy(Space) dWorldDestroy(World) dCloseODE() For ode.ODEGeom=Each ODEGeom Delete ode Next End Function ;------------------------------------------------------- ;Other Clear Method > ODE CRASHING AFTER RESTARTING IT > 3 - 30 (many restarts) ;------------------------------------------------------- ;Function CLEAR_ODE () ; For ode.ODEGeom=Each ODEGeom ; dbodyDestroy(ode\body) ; dgeomDestroy(ode\geom) ; Delete ode ; Next ; dJointGroupDestroy(ContactGroup) ; dSpaceDestroy(Space) ; dWorldDestroy(World) ; dCloseODE() ;End Function Function UPDATE_ODE () UpdateGeoms() dSpaceCollide(Space,World,ContactGroup) ;>>>> MAV ERROR LINE dWorldQuickStep(World,0.1) dJointGroupEmpty(ContactGroup) End Function ; ################################################################################################### Function AddObject() xp=Rand(-10,10) zp=Rand(-10,10) ode.ODEGeom=New ODEGeom ode\body=dBodyCreate(World) dBodySetRotation(ode\body,0,0,0) dBodySetPosition(ode\body,xp,30,zp) dBodySetAutoDisableFlag(ode\body,1) ode\geom=dCreateBox(Space,5,5,5) dGeomSetBody(ode\geom,ode\body) ode\mesh=CreateCube() ScaleMesh ode\mesh,2.5,2.5,2.5 EntityColor ode\mesh,Rand(255),Rand(255),Rand(255) EntityAlpha ode\mesh,1 EntityShininess ode\mesh,0.7 End Function ; ################################################################################################### Function UpdateGeoms() For ode.ODEGeom=Each ODEGeom If dBodyIsEnabled(ode\body) RotateEntity ode\mesh,dGeomGetPitch#(ode\geom),dGeomGetYaw#(ode\geom),dGeomGetRoll#(ode\geom) PositionEntity ode\mesh,dGeomGetPositionX#(ode\geom),dGeomGetPositionY#(ode\geom),dGeomGetPositionZ#(ode\geom) End If Next End Function ; ################################################################################################### |
| ||
| has one already tested the code? :) ---- i have experiment with Original Freeware ODE Wrapper and Same Sample. Result: it Works ! Download Same Sample with Original ODE Wrapper: http://racer.bhmotorsports.com/index/Files/C/Same_Sample_Original_B3D_ODE_Wrapper.rar Seem to be a fault in your DLL. But, your JV-ODE Wrapper is faster and better. :) |
| ||
| Hi Barton, I've had a look for you, the problem seems to be caused by the dSpaceDestroy function. This function isn't really necessary here though, because it basically does the same thing as dGeomDestroy does in your CLEAR_ODE() function. Using dGeomDestroy is probably the better way to do it. Anyway, try this function and see if it works any better... Function CLEAR_ODE () For ode.ODEGeom=Each ODEGeom dBodyDestroy(ode\body) dGeomDestroy(ode\geom) Delete ode Next dJointGroupDestroy(ContactGroup) dWorldDestroy(World) dCloseODE() End Function It seems to work fine here, let us know if you still have problems with MAV's at your end ;) |
| ||
| Thanks for this alternative Solution. It work so without MAV Errors ! (also in my game) The dSpaceDestroy works then therefore not correctly. Will soon there be a correction of dSpaceDestroy Function in your DLL ? (actually is no longer necessary) the question Which solution is last better,healthier and sure ? which advantage does the new initialization have? - with ODE_INIT/CLOSE - or only destroy bodys and geoms ...before reload the Level. hmmm,difficult decision. I need advice. ---- JV-ODE ist the Best. :) |
| ||
| I have almost finished my first project using your excellent wrapper. Do you know of any tips to increase stability & reduce elasticity in large collections of ODE objects? http://www.blitzbasic.com/Community/posts.php?topic=45044 Thanks. |
| ||
| @Barton: The dSpaceDestroy function in the dll uses the original unmodified ode code (ode handles the process internally). It may be that the geoms should be added to the space manually to make this function work correctly? The ODE User Manual will give you some more info on adding geoms to spaces. I'm not sure which way would be best though, that depends on how JV-ODE is being applied to your project. Personally I would build both methods then test them fully to see if there are any issues with each one. Let us know how you get on with it :) @CopperCircle: Nice game :) For the elasticity, I would experiment with the new geom contact settings to alter the bounce, erp and cfm etc... dGeomContactSetMode(geom,mode) dGeomContactGetMode%(geom) dGeomContactSetMu(geom,mu#) dGeomContactGetMu#(geom) dGeomContactSetMu2(geom,mu#) dGeomContactGetMu2#(geom) dGeomContactSetBounce(geom,bounce#) dGeomContactGetBounce#(geom) dGeomContactSetBounceVel(geom,vel#) dGeomContactGetBounceVel#(geom) dGeomContactSetSoftERP(geom,erp#) dGeomContactGetSoftERP#(geom) dGeomContactSetSoftCFM(geom,cfm#) dGeomContactGetSoftCFM#(geom) dGeomContactSetMotion1(geom,motion#) dGeomContactGetMotion1#(geom) dGeomContactSetMotion2(geom,motion#) dGeomContactGetMotion2#(geom) dGeomContactSetSlip1(geom,slip#) dGeomContactGetSlip1#(geom) dGeomContactSetSlip2(geom,slip#) dGeomContactGetSlip2#(geom) dGeomContactSetDefaults(geom) ... also you can try changing the mass of the objects and gravity settings. To increase stability you can raise the maxcontacts parameter using the dContactSetMaxContacts(max) function. The default is 128, so you could try 256 or 512 or something like that. Don't raise it too high though as this too will make it unstable. You can also reduce the time steps, but this may have an undesirable effect on the overall simulation. Time for a new thread I think... :) |
| ||
| NEW THREAD Please continue on the new thread here... http://www.blitzmax.com/Community/posts.php?topic=45048 Thanks :) |
   |