JV-ODE Physics Thread 5
Blitz3D Forums/Blitz3D Userlibs/JV-ODE Physics Thread 5
| ||
| 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 (185KB) Have Fun :) Previous JV-ODE Threads: 1 2 3 4 JV-ODE Player Factory Forum Useful Links: ODE.org Website - ODE User Guide (PDF) - ODE User Guide (HTML) - ODE Archives |
| ||
| Here's a Car & Trailer Demo as requested by EmerGki... |
| ||
| hm. you know what? why always make standalone demos of different features of ode? shouldn't we try to do a library, which would simplify the creation of complex simulations? i'm thinking about something like: myRagdoll = dCreateRagDoll(2,2,1,0) ; creates a ragdoll with 2 arms, 2 legs, 1 head and 0 trails myCar = dCreateCar(2,true) ; creates a car with 2 axes and frontwheel-steering etc for all a lot of other types of physics wouldn't that be something? |
| ||
| Well, this is difficult, a car is something more than 2 parameters. You must decide masses, sizes of geom, suspension, etc... Perhaps if you make a 20 parameters function... |
| ||
| The standalone demos are better for showing new ODE users how to access individual parts of the ODE library. If anyone wants to make some prebuilt functions for creating different complex objects that's fine with me :) |
| ||
| Very Thanks Vip3r, I'm Very Happy with this =). Thank's Again! A Great Embrace! |
| ||
| Is it just me or do regular cylinders ignore collision with trimeshes?? Edit: sorry, didn't entirely read the past threads. |
| ||
| @EmerGki: You're welcome :) @Dripht: You're correct, only capped cylinders are currently supported for TriMesh collisions in ODE. There is a demo included in JV-ODE that provides a workaround for this problem. Take a look at the 'CarDemo-SphereWrapCylinder.bb' demo, in this demo spheres are used to provide collision geometry to collide correctly with a TriMesh. Or alternatively you can use capped cylinders instead ;) |
| ||
| I like OJay's idea but in that you get blocks of information that would help people understand what parameters are available and in what way they work best for a certain simulation. Like in the field of automotive projects, knowing which ODE functions can be incorporated into for use or not use based on the extent of the proggy. I've yet to find a descent doc or online source that would break down a car type object and help assist what can be incorporated into it. @VIP3R, thanks for the updates, no problems with it so far ;) Topknot ;) |
| ||
| hm. you know what? why always make standalone demos of different features of ode? shouldn't we try to do a library, which would simplify the creation of complex simulations? I created a basic 'library' in my tute. I don't have a link but I posted it on a forum at VIP3R's request, so maybe he can link to it? It uses an object system where you load a set of properties into an object type and then an ODE object+mesh is created. The simple version I provided is only good for spheres and cubes, but can be extended. My current version has a ragdoll object where you supply some properties like size and a ragdoll is created, for example, ising the box creation functions from the library and some joints. I rejigged the whole system to use a linked list instead of an array, and added a joint object to my ODE object so an object can be joined to another. This system is limited to one joint per object (though you can link multiple objects to one other, so say add four limbs to one body). I'm about to add a seesaw (teeter-totter) object and hopefully my structures are suitably designed that this won't be too difficult.myRagdoll = dCreateRagDoll(2,2,1,0) ; creates a ragdoll with 2 arms, 2 legs, 1 head and 0 trails myCar = dCreateCar(2,true) ; creates a car with 2 axes and frontwheel-steering wouldn't that be something? I can't really provide it as a useful library though because it's the mainstay of my program and hence somewhat 'jury-rigged' to work for me without being particularly lean and well structured. Still, the idea works and it isn't *too* much trouble to adapt my starter library to add more features. Edit : Okay, I followed VIP3R's links and found it here... http://www.davidcoombes.f2s.com/ode_for_newbies.pdf Annoyingly .PDFs have lousy copy and paste options, but you can still use the code straight out of that as a starter for your own library. |
| ||
| yeah your lib is pretty usefull to setup some simple simulations fast, but it gets complicated when moving to more complex ones... so, at the moment i'm thinking towards XML, hence Collada. since it's an industry-standard for defining 3D worlds it would be really cool to just extend the existing b3d-format with xml-data. also, there's already an b3d<->xml converter in the code-archives, so this could come in handy as well... but as stated above, im still thinking about a concept best suited. so expect no solution before holidays or something ^_^ (have some other projects to complete before the end of this year, too. so my timetable is pretty much at full capacity at the moment...) would like to hear your opinions about that plan, of course :) |
| ||
| I mentioned Collada to Kurix too. Great minds... ;) Actually from the sounds of it Kurix's editor is halfway there. It has XML output, so a parser could create objects. Like my current system you could have a list of primitves and a list of joints, load an XML file, say for a ragdoll, and for each object you'd call primitive functions to create a block or joint. Ideally a Collada parser would allow those with 3D apps that support Collada to use those to create scenes, which would be getting pretty advanced. |
| ||
| I'm finding a host of new error messages, all from VB and I guess in theory they could be useful. I see some things are more particular, such as now I can't set a box to a negative size without a VB error. However these don't provide any use for tracking where they occur. Just now I had a 'bad joint argument' when I referenced a non-existent joint, whereas before Blitz would flag the error and show me where in my code it occured. Can the ODE error trapping be integrated more closely with Blitz? |
| ||
| Hi. My support for xml was based on the XML-ODE format from the java community. Powerful but not complete. Other idea would be to extend the b3d format with custom properties. I don't know if this can be done, but i think it can be. So you can have a b3d format with full physics. Some people suggested me to include such exporter in kode, but then we should need to do a special b3d importer in blitz. Good ideas anyway... |
| ||
| @Shifty: You mean VC? I'm not getting anything other than 'Memory Access Violation' when referencing a non-existent joint. Setting a box to a negative size doesn't produce an error here. Are you using the latest build (480KB)? |
| ||
| I need some feedback from JV-ODE users if possible :) KuRiX and I have been talking about the creation of a JV-ODE add-on, a plugin/importer system for use with 3D modelling software (for example 3DS Max etc). You would be able to create JV-ODE objects from within the 3D modelling editor, then using the importer, load them directly into Blitz3D for use with JV-ODE. The plugin/importer add-on would be made available as a separate optional system, it wouldn't be included with JV-ODE. We would like to know if this would be useful for JV-ODE users? Also, what would you expect to pay for the plugin/importer add-on? Any suggestions and comments welcome. |
| ||
| Nice Idea, But I have for my 3D Engine programmed a Level Editor with ODE Support. I can import, create and adjust ode-objects in the Level Eitor and then load in B3D. so I can build even houses and stack the ode-objects. Work fine. :) Because of this I cannot use the Plugin. but others will be very pleased about it. |
| ||
| Plugin ... not for me for nearly the same reasons as Barton mentioned: Own Level Editor, Model Editor, etc. See my eMail I sent to you some days ago There are many other things much more important, in my view... For instance make the system more realistic - materials that have the abilities they should have, realistic gravity, and most of all, make it computer speed resistent - faster computer, higher framerate means bigger trouble!!! This should be fixed ... (delta timing that works between 60 and 300 FPS ruins everything above 500, because the steprate has to be changed - what on the other hand causes trouble on lower rates) |
| ||
| > We would like to know if this would be useful for JV-ODE users? YES! > Also, what would you expect to pay for the plugin/importer add-on? ~$25? Maybe even more if it rocks (creates easy rag-doll/car setups) and of course supports the right modeling software (XSI5). Dot xsi would be good: http://www.softimage.com/Connect/xsi/dotXSI-FTK.htm#dotxsi |
| ||
| didn't you read my posts over all? |
| ||
| @About the Importer/Loader: Well, the idea is to make some standard for physics world creation, using simple objects, not specific plugins. So in fact you could use ANY modeller to add jv-ode support, and create ragdolls, cars, and full worlds just using standard meshes and/or pivots. @RagR: I have solved the step problem using the frame control from the castle demo, where you force the computer to run a number of frames per second. Then you split the control frames and the render frames. The control frames are always the same (for example 50 per second) then the rest of the time in a second is for the render frames. So you will have the same speed in any computer you run it, and only the fps (display) is affected. |
| ||
| Well I've already voiced my ideas on this. I think any long-term JV-ODE user has created their own editor of sorts by now that fits in with their structures, but I know mine is far from full-featured and would look to get a much better alternative if available for future projects. You'd need a very solid engine and well worked structures for collating object property information. In my case I've got materials that define friction, density, restitution, magnetism, texture/colour, alongside customizable per-object material properties. There's plenty of scope for more complex objects too, beyond the old TYPE ode has Body, Geom and Mesh fields, such as including directionable forces for blowers. But of course the more features you add, the slower it gets, so these need to be optional and yet full featured. Actually in my engine it's easy to code out the magnetism or blower forces so it might be not too hard to have optional properties for more complex simulations. |
| ||
| I am still not sure how to do it, but one possible solution would be: - You create your world, then create pivots (or helpers) that contains physics properties that you can attach to your objects, so then exporting just .b3d or .3ds and loading with the "new importer" the scene is loaded with all the assigned values. For example you create a box, then a pivot named "friction 30" that you attach to the box. Or you create an object called "joint ball" that you attach to two objects. So any exporter would work... Then the importer will parse all the scene to types so you can manage it perfectly, change properties, etc... and the loading of the scene will be just one line. What do you think? |
| ||
| Not a bad idea Kurix- Kind of extending the B3D extensions. Either way, This is something i'd find terribly useful if i was to stay with blitz. |
| ||
| @Shifty: You mean VC? Yep, latest build creted 20th November. If I callI'm not getting anything other than 'Memory Access Violation' when referencing a non-existent joint. Setting a box to a negative size doesn't produce an error here. Are you using the latest build (480KB)? dJointGetHingeAnchor(UI_object\joint\joint_object) and the object doesn't exist, Blitz complains. But if I set UI_object an object that hasn't a valid Hinge joint, I'm told ----- ODE INTERNAL ERROR 2 bad joint argument (..\ode\src\joint.cpp:883) ----- Followed by ----- Microsoft Visual C++ Runtime Library Runtime Error! Program ...blah blah...\bin\blitcc.exe ----- If I create a box with a negative length, on calling dCreateBox() I get ----- ODE INTERNAL ERROR 2 bad joint argument (..\ode\src\collision_std.cpp:142) ----- I only find this by stepping through my code. It doesn't nicely tell me the offending command, nor break into the Debug window to show me the wrong line, nor open the library and set me to the offending line. Could this perhaps be an issue with ProteanIDE which is .NET based? At the moment I'm getting 'can't have body1==body2' when I reload my data. The problem must be to do with my new joint operations, but finding the problem is a good deal harder with such unhelpful error messages! |
| ||
| @RaGR: Eh, what needs fixing? The physics time stepping should be controlled by the programmer of the simulation. Restrict the time steps to 60 fps as KuRiX mentions and not every render frame. @OJay: Not sure if you meant me? I read all user posts. Your idea is good and I've already looked into doing something similar (read the previous threads). I found it would be easier for users to set up their own functions based on their particular needs, instead of a global creation function that will probably be unsuitable for most people without heavy modification. @Shifty: The latest build is 23rd November (not 20th), there is an easy way to check. The old build of 'JV-ODE.dll' was 524KB, the new one is 480KB. The new build shouldn't give any of those error messages, leaving Blitz to point to the errors. Make sure you have the latest build. Please note: The development, sales and support of the plugin/importer system will all be done by KuRiX as a third party add-on for JV-ODE. If he decides it's worthwhile creating of course ;) |
| ||
| Yeah that's it. Good-oh! |
| ||
| @Vip3r Ahh, that's the way you handle it ... good to know ... first ask people to write what they think and then answer some rubbish ... but I am used to it... I invested in at least 25 "Blitz Addons" and at most 5 were useful in the end ... ... maybe its time to switch to Filax Easy-TOK ? ... stuff I bought from him I must say was always useful ... and I never got a lousy answer from him I don't want to restrict timesteps to 60 fps !!! And if you would have read what I wrote you would have at least thought a second for a solution or at least had a question back... but if you are not interested and have no time ... your decision. |
| ||
| @Vip3r Ahh, that's the way you handle it ... good to know ... first ask people to write what they think and then answer some rubbish What part of "Restrict the time steps to 60 fps as KuRiX mentions and not every render frame." is rubbish exactly? KuRiX has ALREADY answered your question, do you want me to echo the exact same answer? The very same answer I gave you via email a while back? If you're not happy and want to try another physics product, that's fine with me... your decision. |
| ||
| Setting the Physics Evolution to a constant rate per second is ALWAYS the best solution. Seconds are seconds in pentium1, pentium2, pentium3, amd, china, russia, australia, eeuu, gameboy, psp, ps2, xbox, etc... so the physics will run exactly the same in every computer, which i think is great! Graphics are other words... What's the problem about doing this? What do you want to do exactly? |
| ||
| I think your doing a great job guys. I got this a month ago, haven't touched it yet (am not at that point in my project yet), but know it will be very handy. Glad I could help out the effort with my purchase! |
| ||
| Any thoughts on porting this for Blitzmax? |
| ||
| Thanks for the support Dark Half :) I will look at getting the DLL working with BlitzMax (Win32 only) but I'm not sure how successful this will be yet. I'm waiting for the BMax updates to settle down and stabilize a bit first, I don't want to get into the situation where I have to release a fix for every BMax update. Then there's the problem of deciding which 3rd party 3D engines are complete enough to use for demos etc. It might not be worth making an ODE module if Mark is already creating one (there's a beta ODE module available for download). As soon as I've looked at this more closely, I'll let everyone know. |
| ||
| Does anyone have any links or information on the parameters that can be effective to give an auto better handeling.??? Seems that with current abilitiy's the auto's are limited greatly to very low top speeds, and anything higher than say 30 gives wobbly wheels, and such. So looking if anyone's got better information on improving a car's handling and aspects. Thanks Topknot ;) |
| ||
| Well, i have been working on ode's cars for more than one year. You need to make lot of tuning to get what you want. Now i have a very good model, but you need to choose between arcade cars or simulation cars. Some aspects are: - Low the center of mass of the chassis - Give the chassis a big mass - Decrease the value of CFM to avoid wheel problems at high speeds - Use very low time step - Use spheres for the wheels - Etc... Good Luck. KuRi. |
| ||
| Topknot: 30 what? ;) Ive not had these issues, in JVOde though they do exist. You want to see wobbly wheels? use the orignal ode wrapper. THEY were wobbly ;) There are functions in ODE to fix the problem with the wheels going a bit lop-sided- I dont remember which ones to mind. |
| ||
| @Topknot: The wobbly wheels issue is a common symptom in ODE. It usually only affects the rear wheels at high rotation speeds. In the car demos, the speed of 30 is quite high if it were converted to real world speed. The cause of the problem is the joint that holds the wheels. When the wheel rotates at very high speeds, the joint starts to break away. I've not seen any info available that gives guidelines for a solution to the problem. But there are many gotchas to watch out for: Too much friction Not enough ERP Too much CFM Too much mass pressure on the joint Not enough wheel mass Time steps are set too high I've had varying degrees of success with other methods, but I'm still looking for the perfect solution. I do have a new idea which I'm going to experiment with, but it's more complicated than using single joints for the wheels. It involves changing the Hinge2 joint for a Hinge joint and a separate suspension unit. |
| ||
| TopKnot, What they said above, and you might try the following method which I've had some success with. In essence (if i understand correctly) you are finding the wheels axle orientation and then forcing the wheel to match it. So when the wheel is tempted to wander off because of errors introduced by the high rotation speed this little function 'snaps' it back into the right place. Please note, this seems to help, but not solve the issue. You need to mess with the other settings as well to get a result satisfactory for what you are trying to achieve. Assuming you are looking at the car demo from VIP3R, When you create the wheels add this :- dBodySetFiniteRotationMode(ode\body,1) for each wheel and then when you update the car (i.e. in the UpdateCar() function :- For count=1 To 4 ; get wheel hinge axis dJointGetHingeAxis(joint(count)) wxa#=dVectorX() wya#=dVectorY() wza#=dVectorZ() ; apply To wheel dBodySetFiniteRotationAxis(wheel(count),wxa#,wya#,wza#) Next Hope this helps, Mark |
| ||
| Well some things I notice when trying to find a half way descent setting is: - The Faster you go the less turning ability you get back no matter what your turn variable is set to. - Trying to discover additional functions to generate things like "rear wheel sliding" "different friction based on surface" @kurix, I've had problem making the mass too heavy, and is there a formula to figure out mass, gravity, and the rest of the variables ?. At the moment it's been wild ass hair guesses and tons of frustration at not fully understanding the effects or interloping these variables has to eachother. By time step I assume you're refering to the CFM & ERP values?! The "ETC..." is what I'm interested in ;) @Mark Judd, Thanks will give is a go and see, tried weeks ago to understand that but will ingage it again. Thanks all Topknot ;) |
| ||
| By time step I assume you're refering to the CFM & ERP values?! No, he means the dWorldQuickStep() function in the main loop. Lowering the step value improves the accuracy of the simulation (like wheel joints), but it also slows it down. So you have to balance the other settings to compensate (gravity/forces/torque/mass etc). Patience, it takes time to develop a good car setup. Keep using the ODE manual as a reference for info on ERP, CFM and the other functions. Learn as much as you can about them, experiment with them. :) |
| ||
| @VIP3R, I totally agree, lots of testing, but here's the stickler. To be handed a ODE doc that give 3-4 line brief descriptions without any pratical examples, makes defining functions very slow and annoying. For example in the Blitz3D forums you can find a ton of examples, refinements, and posted bits of functions to demonstrat using Blitz3D. Something I was refering to was like a Doc, or Tut that builds a solid car, then helps the user to "Understand" what's going on. very much like the ODE PDF tutorial that was posted ages ago. That was formatted to explan thing to a person diving into ODE quite well. As an example I set dBodySetFiniteRotationMode(ode\body,0) Set it to 0 and now I can increase the limiter on Speed# to things like 125 and the rear wheels hold fast. Why..I got no idea lol. Like you said there more function to think about but "Knowing" which and how they work is the kicker with the limited ODE doc's available and very few examples. This isn't a complaint, just a desire for more indepth details instead of short spurted answer quoting to "read" the almighty ODE docs. @Mark Judd, Tried your bit of code, and oddly it produced even greater problems in that even at lower speed the wheels would start to flatten out and turn into a "hover" "Back to the Future style" car lol. But setting to 0 seems to stop it totally for much higher speed?! Odd. I'm trying to make something stable enuff to post and let you tinker with it, it's just the frustrations that keep it on testing format. Topknot ;) |
| ||
| I understand Topknot believe me :) What do you think I learned ODE from, Yoda? :P In fact it was the very same vague 3-4 line description manual we all use. I've not found any other worthwhile ODE docs, I'd be the first to post them if I did. |
| ||
| Maybe as a force to increase usage and desire for ODE and mainly JV ODE usage, everyone could contribute small bits that could be compiled and exchanged for the better of this community. I'd be happy to spend the time compiling and writting up a doc pack if information is posted. Then this could be packaged with the JV-ODE suit and make it more attractive for new and old users ;) My biggest puzzlement is that in all the searching thru the ODE's main sight I find so little information on these things. Topknot ;) |
| ||
| Hi friends. As i promised here it is a small video of my racing engine. Although FRAPS is limiting the capture to 60fps the game runs at 120fps without problem on geforce fx 5200 128MB. www.lcuriel.arrakis.es/kracing1.avi It is using my wrapper, but this can be done with jv-ode perfectly the same. If you want more videos let me know! |
| ||
| @Topknot: The ideal thing would be some kind of beginners guide. I'm the WORST person to create something like that though. I understand the complex stuff quite well, but I'd have serious problems translating it into something beginners would understand clearly. Btw, if I refer somebody to the ODE docs, it's because some questions ARE well explained in the ODE docs and sometimes it becomes obvious that very little effort has been made to research the problem beforehand. Take ERP and CFM for example, there are two entire sections devoted to these parameters in Chapter 3. Why should I need to explain the details of these, when the docs already do this? I help people a lot with JV-ODE, not just on these threads but also directly via email. It takes a LOT of time and effort, I do the best I can with the limited amount of time I have available. |
| ||
| Docs take time. There's no getting round that. IF you are to do a seriously useful piece of tutorial you're going to need to invest several hours at least. I for one just don't have that time, and can only post snippets up here as I discover them. |
| ||
| @VIP3R, Now let me state before statements are misread, First off I'm not attacking your's or anyone elses skills or knowledge, I understand many good things are "printed" in the ODE Doc's but it's like asking someone to read a book on Quantium Physic's and state that's it's easy to understand lol....By your own statement you understand the higher functions better than most, hell you wrote the DLL wrapper, so again I'm posting from a newbie's understanding of the ODE. From being an instructor at a Tech College I am quite familiar with how simple basics that I see as child's play are hard for new students to grasp right off the bat without tutorials and explainations. @KuRiX Very interesting vid, I take is that the models and such are in testing stages hense the lack of textures and details..? I'd be willing to do some resources in exchange for some tips on getting ODE under controll ..;) @Geezer I agree, Doc's do take time to compile, refine, and make understandable for new peeps, but at the same time I'm also willing to take peoples input and samples and start building Doc's that could be included and eventually incorporated into the Blitz3D's Help section in similar fashion as the standard commands. Btw all, I do read over and over and hunt and compare both the ODE Doc's and the JV-ODE manual html for hours before just splating questions here, usually I come here as a last hope to figure out problems. Maybe others here can read once and totally understand the functionings of ODE, but my skills lie on other avenues. I have worked professionally in generating contractable resources and such for other company's in the gaming industry, but now in working with the exciting avenue of ODE with Blitz3D, I end up doing all sections of a program. Hell I've rebuilt 6 different styles of tracks, worlds, and environments just to find a nice mix with what little bits of ODE I understand ;) Topknot ;) |
| ||
| @Topknot: We are developing a full 3d map of our real city, building by building. That map was only to show you some ode in action, hehe. What kind of resources can you offer? Because we plan to use 1000 poly's vehicles to support 20 or 30 players at a time... Thanks for the comments anyway! PD: Take a look at my ode editor, the demo can tell you lot about ode and its parameters! |
| ||
| I forgot to mention, you may find some VERY useful info in the ODE archives. There's a link to them in the top post of this thread. You can read it online or download the entire archive and search it offline, you can also google stuff like 'ode car setup' and it'll return results from the archive. It isn't easy to understand some of the posts, but there's a lot of useful info available which could help you. |
| ||
| @KuRiX, Name it and I can model it. Althou the one spot I am a bit slower with is real life organics. Most of my contract work has been for military and civilian vehicles, buildings, and environments. I have the ability to model, UVmap correctly lol, animate, and texture per look or feel. My true speciality is in low poly reduction to fit most major game labels were 100's of units or such were needed. Best I could say for you is to toss me a few project items you want and let me return resources for review. Just a really cheap cap of two of the cars I built to tinker with in my proggy, each measures in around 2200 polys including wheels. Still plenty of room for trimming but more focused at this stage on ODE coding ;)  @VIP3R, Will do, didn't realize I could download the entire past postings as such for offline research. I've been collection almost anything and everything I find into a collection to try and learn. |
| ||
| Thanks for the info Topknot. 2200 polys are too much for me. I have cars with wheels, glasses, driver, and interior with just 1500 total. See if you can beat it, it would be great! ;) |
| ||
| Damn, I couldn't watch the video Kuri, I don't have the right codecs installed. I heard it though, sounds nice :) Those cars look great, nice work Topknot ;) |
| ||
| you can download them from www.divx.com although i suggest you to search for codecs divx 5.1 (they include no adware)... Cheers! |
| ||
| Better yet nab XP-Codec Pack: http://www.xpcodecpack.com Ace Codeac Pack: http://www.softpedia.com/progDownload/ACE-Mega-CoDecS-Pack-Download-6778.html and never have to worry about finding codeacs for anything ;) Thanks on the cars, sadly you can't see the details due to overlighting for the fast snap lol... Oh an KuRiX, trust me I wasn't shooting for low poly in those two cars that I use for testing purposes. But if HAD to I could easly meet a 1500 total poly count with your stated objects ;) |
| ||
| nice video kurix! any chance to get infos about, how you did the friction- and collision-sounds? |
| ||
| About the sounds? they are the easy part of the engine!. For the friction sound i got a looped friction sound from the web, then i calculate the perpendicular linear vel of the wheel, so if greater than a value a loop the sound, and if lower, i stop the sound. For the collision, i just check for collision between bodies (chassis) every frame, and if i get a collision with enough speed, i play the sound ( i got it from some web too, hehe), and i don't play it again until i get a new no-collision -> collision. Good Night for me now. Cheers, KuRi! |
| ||
| Hey OJay, Not sure if this helps you with the collisions, but here a Function I came up with to both play a "Crash" sound file and Slow the car down and also put Particles at the point of collision: Function ShowCarBodyCollisions() ;### Check if a Collision has happened between Car and World Objects ### If dGeom1CountCollisions(CGeom) > 1 ; ### IF YES a collision grab the X,Y,Z of the point of impact ### XPos# = dGeom1CollisionX(CGeom,1) YPos# = dGeom1CollisionY(CGeom,1) ZPos# = dGeom1CollisionZ(CGeom,1) ; ### If The collision happens at speeds Greater than 6 then play Sound and Cut Current Speed in Half ### If Speed# > 6 PlaySample(Hit01,0) Speed# = Speed# / 2 EndIf ; ### If the Velocity of the Car (float) is fast enuff then create a random (1 of 3) particle at point of collision ### If Velocity# > 0.5 I = Rnd(1,3) CrashParticle(0, HitSpark(I), 4, XPos#, YPos#, ZPos#, 1, 5, 1, 2, 1, 4, 0.1, 1.0) EndIf EndIf So basically you have to be moving fast enough to play the sound and generate a sparking particle, otherwise if your just puttering along slow and nudge a wall or rail you just bump it. Oh BTW, here's the Function that the crew here, I believe VIP3R posted to help me figure out the car's velocity: Function CalcVelocity() PositionEntity PrevPosPivot,PrevX,PrevY,PrevZ Velocity# = EntityDistance(CMesh,PrevPosPivot) PrevX# = EntityX(CMesh) PrevY# = EntityY(CMesh) PrevZ# = EntityZ(CMesh) End Function As for the Friction, that's something I'd also be interested in knowing how to preform or suggestions for it, it's my next step to try to generate for drifting corners...:) Topknot ;) |
| ||
| Thanks for the codec links, got it working now :) Nice video Kuri ;) |
| ||
| Hi Vip3r, now I have other trouble, how I make one car Sepparated in 3 pieces? like this image: www.dynamicgames.com.br/images/carro.bmp |
| ||
| The best is to use just one body for all, then you make 3 separate geoms, and attach two of them using geomtransform geoms... |
| ||
| @EmerGki: You can use geom transform which as Kuri suggests is probably best, or you can attach each object using fixed joints. It might be a good idea to make a demo of Geom Transforms, I'll see what I can come up with ;) |
| ||
| Here's a demo showing the use of Geom Transforms. Each object in the demo contains 1 main sphere geom (White) and 3 sphere geom transforms (Coloured). |
| ||
| Here's another Geom Transform demo using sphere & box geoms (White) and 3 to 5 sphere & box geom transforms(Coloured). |
| ||
| Hey VIP3R, Sorry if this is an old question, but I noticed in your two new demo's that you use a slightly different car values in the setting up of it, and was wondering if there is a layman's formula to knowing how to match up the values to make them exist nicely with eachother? Meaning is ther a Golden Rule to what the values should be based on eachother? Thanks Topknot ;) |
| ||
| No formula really, it's just a process of 'test driving' the car and tweaking the settings where necessary. If it's flipping over or gripping too much (over steering) on a sharp bend, lower the friction settings slightly. Changing the suspension hardness/softness settings will also affect the over/under steering making it handle better (or worse). Testing and tweaking is your key to getting the car handling how you want it to. All of the settings mentioned in previous posts (ERP,CFM etc) should be tweaked and tested until you're happy with the setup. The easiest method is to tweak only one setting at a time and see if you feel a difference in the handling, then make a note of the changes. Once you've experimented and listed the results from each setting change, you will have all the info needed to tweak it to perfection. Each kind of car simulation would require totally different setups, for example F1, Touring Car, Rally etc... It also depends on whether you're making a realistic simulation or an arcade style racing game. A set of 'perfect' values doesn't exist, until you discover it through the above process, there's no shortcut. After all, only you know how you want your car to handle ;) |
| ||
| To add to what Vip3r said. while developing Cygnus Car Engine, (3 years or so now?)- 75% of the time was spent fine tuning values. Even a difference of 0.0001 can make a difference to the handling. |
| ||
| Hey all, just wanted to show a couple of quick videos (divx) of the project I've recently started since I got back into Blitz3D. The car is a work in progress Audi TT, no texture (hence the funny looking chrome HDRI). City is something I threw together in 3DWS. I have to say that JV-ODE was well worth the purchase. I'm having a blast... http://www.strafed.net/stuff/dr1ve-2005-12-10-divx.avi http://www.strafed.net/stuff/dr1ve-2005-12-10-2-divx.avi |
| ||
| Honda Civic this time... slammed into the wall especially for you all :) www.strafed.net/stuff/dr1ve-2005-12-11-3-divx.avi |
| ||
| looks good! congratulations markd. Too much drag... but good! |
| ||
| nice one. reminds me in the old midtown madness :) any demo plans? (you know that i had to ask ;)) |
| ||
| Those car physics are looking great so far ;) I've been lucky enough to see an early WIP of this one and it's fast and smooth during play, could it be the video render speed that gives the impression of excessive drag? Anyway, keep up the good work :) Now, who was it that said 'holding a drift is impossible' in ODE... hmm... :P |
| ||
| thanks. yeah there's some drag, working on it. bit of a balancing act :) |
| ||
| quick hack, not sure why some box's are doing random spinny behaviour.... jvode.bmx |
| ||
| ehem, oops glDepthFunc GL_LEQUAL glEnable GL_DEPTH_TEST after graphics command! |
| ||
| hmmm autodisable doesnt seem to work either... |
| ||
| ehm...Chris C: this is a Blitz3D forum! i doubt anybody can help you in here with BlitzMax... ;) and did you notice the [Edit]-Button in the top right of your posts?!? |
| ||
| Yeah well somone wanted jvode working with max... wish I hadnt bothered now. |
| ||
| I'm glad you bothered, Chris. I don't think he meant to be offensive. What you posted was pretty cool! |
| ||
| interestingly with spheres as well the spheres disable but not the box's... |
| ||
| sorry chris, surely didn't want to offend you! i just wanted to say, that someone who looks for ode-stuff for blitzmax, won't look into a blitz3d forum! why not open a separate thread in the bmax-forums? |
| ||
| Does VIP3R have BlitzMax for development purposes? |
| ||
| Nice work Chris and thanks for posting it, I'll take a look at the code and see what I can do to help ;) @Shifty: Yep, I've got BlitzMax ;) |
| ||
| How does BlitzMax compare at the moment for overall usefulness and reliablility versus Blitz? Not that I'll swuitch on my current project, but I'm interested in how well cross-platform works and whether the better structuring (from what I hear) helps a lot. The lack of a 'proper' default 3D engine and Blitz's wonderfully simple entity system has me thinking it'll be a lot more effort to get the same results. So how does say writing porting an OE project (or writing a similar one) compare? |
| ||
| Hmm... In BlitzMax, reliability is no where near the level of Blitz3D yet. The cross platform feature is ok, providing you also have a Mac system and Linux set up. Due to the vastly different code structuring, it's easier to write a BMax project from scratch rather than port older Blitz projects over. (IMO) Also, Win32 DLL's (including JV-ODE) won't work on the Mac and Linux platforms. |
| ||
| VIP3R: Is it possible todo a zerogravity simulation with JV-ODE .. I have tried but i cant get it working. Do you have any idea/exemple ?? |
| ||
| Set gravity to (0,0,0). Or disable gravity for any objects you don't want affected by gravity. |
| ||
| Doh!!! (smacking the head to keyboard).. I shall try that, thanks Shifty. :) |
| ||
| vip3r i see a demo with a terrain (blitzterrain i hope) and balls on http://www.devcode.co.uk/jv-ode.html where is the bb demo ? |
| ||
| new video up. i can barely drive my own car :) www.strafed.net/stuff/dr1ve-2005-12-17-4-divx.avi edit: updated video... added (90% finished) manual transmission emulation. |
| ||
| Hi Panno, the terrain is made from a static mesh (ODE TriMesh). It isn't possible to use Blitz terrains directly, but you can generate a static collision mesh from a heightmap easily (see FLE in tools). The TriMesh is only supported in the full version of JV-ODE. @markd: Nice video, keep 'em coming ;) |
| ||
| Here's a modified car demo capable of much higher speeds. The rear wheels are extremely stable when splitting the physics steps each frame (see the Main Loop), resulting in vastly improved accuracy of the simulation. |
| ||
| Here's a car demo showing Geom Transform of the car body, it's a very good alternative of using mass translate to lower the COG and prevent flipping. |
| ||
| dJointGetHingeAngle() seems to return the same vector values (from dVector..()) as dJointGetHingeAnchor(). I've a seesaw with hinge at (0,20,0) that returns (0,20,0) for both functions, even after it's tipped one way and rotated. Does dJointGetHingeAngle() populate the dVector() values correctly, or is there some other similar bug? |
| ||
| dJointGetHingeAngle() isn't a vector function, it returns the angle directly... angle#=dJointGetHingeAngle(joint) ;) The dJointGetHingeAnchor() function is a vector function though, it fills dVectorX(), dVectorY() and dVectorZ(). |
| ||
| :D |
| ||
| VIP3R, Just messing with the friction settings and am trying to get to grips (!) with the mu2 slip2 settings etc. Can't seem to find any way of setting the fdir setting though - this is where you specify the contact joint direction and i think it might help with the 'drifting' question that keeps cropping up. Is this facility available in JV-ODE or am i missing something ? (again!) cheers, Mark |
| ||
| I believe you're supposed to set fdir to the forward axis of the wheel, then ODE can apply mu1 and mu2 appropriately - no idea how you calculate fdir on the fly though, as I think it's a world vector and not local to the wheels. |
| ||
| Can't seem to find any way of setting the fdir setting though The fdir1 vector is currently only accessible internally in the wrapper, it shouldn't be too much trouble to add some new functions for this though. I'll add it to the 2do for V1.10 ;) |
| ||
| Vorderman, I was kind of hoping to set the fdir direction to the orientation of the wheel and then use slip2 and mu2 to vary the sideways slide of the wheel. I may have misunderstood the ODE docs though! VIP3R, Thats great - thanks very much. cheers Mark |
| ||
| Vorderman, I was kind of hoping to set the fdir direction to the orientation of the wheel and then use slip2 and mu2 to vary the sideways slide of the wheel. Yeah that's what I said (or at least, what I meant to say :) ) |
| ||
| Merry Christmas everyone :) I've been experimenting with the new JV-ODE FDir1 (friction direction vector) functions and I'm amazed how much fine control it gives for an objects friction. Friction can be set individually on each axis so you can control sideways friction/slip etc. It's perfect for setting up good powersliding conditions in car sims! It also makes good car setups of any kind much easier to achieve. Coming very soon in V1.10 Thanks to Mark Judd for the suggestion ;) |
| ||
| Hi, I'm quite new in JV-ODE and I'm working on a car sim. I have tried to make a restart button, but every time the car gets positioned in it's start track, it continues in the same speed as it was. For example, if I've just gone round a corner and I press restart, the car gets pushed round and lands so its facing the wrong direction. I have tried to use a command which is called "dBodySetForce", but it did not work! Can somebody help me? Alan (or TWH...) |
| ||
| Are you resetting the speed and torque etc to zero when the restart button is pressed? It sounds like you're still adding power to the wheels after the restart. |
| ||
| you need to use the next functions: dbodysetangularvel dbodysetlinearvel for every object and set them to zero! |
| ||
| Thanks alot!! |
| ||
| TWH, Don't forget to re-set the angular and linear velocities on the wheels as well as the car body, as well as their direction when you restart the car. I found it useful to do a small loop where the values are re-set several times, this seems to give the simulation time to sort itself out. Hey VIP3R ! Looking forward to 1.10 very much - but don't forget to eat a few mince pies in-between sessions, wouldn't want your sugar levels dropping too low...... Looking forward to huge powerslides now ! cheers Mark |
| ||
| JV-ODE V1.10 Update Released! Please check your inbox :) The new update includes: Added new Friction Direction 1 contact functions... dContactSetFDir1(fdir1x#,fdir1y#,fdir1z#) dContactGetFDir1() dGeomContactSetFDir1(geom,fdir1x#,fdir1y#,fdir1z#) dGeomContactGetFDir1(geom) Added new demos... CarDemo-FrictionDirection1 CarDemo-GeomTransform-Car CarDemo-GeomTransform-Cube CarDemo-GeomTransform-Mixed CarDemo-GeomTransform-Sphere CarDemo-HighSpeed Don't forget to update your 'JV-ODE.decls' file in the Blitz3D Userlibs folder! Please let me know if you experience any problems with the new update. Happy New Year :) |
| ||
| Thanks VIP3R! You should add "new years" fireworks demo with particle / physics stuff to the package :P |
| ||
| Thanks very much - travelling home today so will try this tonight. Once more - cheers for all your work, Mark |
| ||
Good Work Viper! Now that you can access fdir1 i have decided to release here the code to make proper wheels friction:
Vector3 front;
Vector3 up;
dReal const * vel = dBodyGetLinearVel( wheel );
int inv = 1;
// Compute fDir1 if a wheel
dReal const * R = dBodyGetRotation( wheel );
front = Vector3(R[2] * inv,R[6] * inv,R[10] * inv);
up = Vector3(R[1] * inv,R[5] * inv,R[9] * inv);
// Set Slip2
contact->surface.mode |= dContactFDir1;
float v = sqrtf( vel[0]*vel[0] + vel[1]*vel[1] + vel[2]*vel[2] );
//contact.surface.slip2 = TIRE_SLIP * v;
// re-tweak mu and mu2
//contact.surface.mu = contact.surface.mu2 = TIRE_MU;
// The theory is that it doesn't matter if "front" points "up"
// because we want fdir2 to be orthogonal to "front" and contact
// normal. Of course, if "front" points in the direction of the
// contact, this can be a problem. In that case, choose "up".
if( fabsf( dDot( contact->geom.normal, &front.x, 3 ) ) > 0.5f )
{
((Vector3 &)contact->fdir1) = up;
}
else
{
((Vector3 &)contact->fdir1) = front;
}
Dvector3 is float[3] and dReal is float. The code is based on the cardemo of official ode threads, and it is c++, but it should be easy to be included by Viper on the wrapper or by anyone in Blitz3D! Happy Holidays Everyone! |
| ||
| Is it possible to get trimesh<>trimesh collisions to work as well as trimesh<>geom collisions? Here's a little test program and two simple meshes... http://www.davidcoombes.f2s.com/TriMesh.zip Move the Arrowish shape with the cursor keys. You can crash into the boxes well, but when you hit the drum thing, trimeshes often get stuck and spin off crazy-like. Is this unavoidable? And when abouts might we get JV-ODE export/Kurix import from [K]ODE? |
| ||
| Well, trimesh-trimesh collision has been always a problem in ODE. They exists, but they have well known stuck problems... There is some demos in the official ode source that shows the problems... About the exporter... Viper... did you look at the code i sent you? |
| ||
| Yeh, TriMesh to TriMesh is still way too unreliable in the 0.5 build of ODE unfortunately. Maybe they'll have more success when the new Convex Hull stuff is completed. Do you mean [K]ODE exporter / JV-ODE importer? I'm still looking at the exporter stuff, I'll be contacting Kuri about that as soon as I've decided how best to implement it. |
| ||
| Hi Viper, Do you think about one demo with one Character with Bones to show how to do this with ODE? |
| ||
| Hi EmerGki, I'm working on one at the moment as it happens, I'll make it available as soon as it's complete. Btw, if anyone needs any help with the FDir1 stuff please let me know, there isn't much info available on FDir1 in the ODE manual. The 'CarDemo-FrictionDirection1' demo shows the basics of FDir1 using friction 'mu' only, but friction 'mu2' can also be specified separately. If 'mu2' isn't specified then 'mu' will apply to both friction directions (1 and 2). To use FDir1, you need to set your friction mu (and mu2 if needed). Remember to add the FDir1 flag in dContactSetMode(dContactFDir1+dContactSlip1). Next you specify how much friction should be applied to each axis using the dContactSetFDir1(fdir1x#,fdir1y#,fdir1z#) function. In the FDir1 car demo fdir1x is the forwards/reverse axis (X), fdir1z is the sideways axis (Z). Lowering the fdir1z value will result in the car sliding sideways more. From the tests I've done with FDir1, it seems that the range for fdir1x, fdir1y and fdir1z is 0.0 to 1.0 (1.0 being 100% friction as set with mu or mu2). |
| ||
| Hey Markd, Today I've take some minutes to see your videos, Are Very Nice =). I have one question, About the scenery, What programm you use to make the roads? Have any specific tool? |
| ||
| thanks, i haven't messed with it in a week or two. got sidetracked... short attention span :). am i the only one with a short attention span here? seems to run rampant in the dev community lol. anyway, i use 3dsmax to build tracks. lofting works best as it creates the UVs coordinates automatically and you can work with bezier curves, smooth curves, etc. google "3ds max lofting track tutorial" or something similar (if you have 3ds max that is). |
| ||
| Markd Your cars looks very stable, How you do this? |
| ||
| just tweaking the numbers i guess. they're not 100% stable, but definately stable enough for a semi-realistic driving game. i wish someone would make a JV-ODE editor with sliders so you could set the numbers and then export/load. |
| ||
| As promised, here's the Zombie RagDoll demo I've been working on recently. It still needs some tweaking but it's good enough to show one way of adding ODE physics to a boned animated 3D model. How you approach the problem depends on how and where the bones are placed into the model. In the demo model, the zombies arms aren't straight on the vertical (Y-Axis) so it's difficult to align the ODE geometry properly without distorting the mesh. Another possibly easier method would be to use spheres for the arms, legs, feet, hands and each of their joints. [edit] New download added below |
| ||
| yeah a good start! but the limits are a bit too hard, making the ragdolls moving like pinocchio or something ^^ human arms and legs are much more flexible! but thanks again for your hard work. must've been a pain in the ass setting all these joints by hand! |
| ||
| Thanks OJay The joint limits are part of the 'tweaking' I was referring to ;) It wasn't too much of a pain setting it up surprisingly, but I'm aiming for a universal system that can be applied to any boned meshes. I'm still experimenting with the methods used, so it'll be a bit pointless tweaking this one to perfection. Forget editors, with a universal system you could select the bones to use and the code will do the rest for you automagically :) |
| ||
| Good Job, this will help-me a lot =). Thanks |
| ||
| Thanks and you're welcome :) I've uploaded a new version of the Zombie RagDoll demo with improved joint limits and an optimised UpdateNodes() function... [edit] New download added below |
| ||
| Really Great Stuff! I was not able to do skinned meshes with ode... How have you set up the model, the bones, etc??? congratulations viper! |
| ||
| WOW!!! Great Viper!!! |
| ||
| I'm Having trouble with place two or more cars in the ODE, anyone can help-me? I want to create one Function like Function CreateCar(Model,PosX,PosY,PosZ). |
| ||
| Thanks both :) @Kuri: The demo uses the standard bones which were added by the author of the model (Psionic3D). The code is configured to use only certain bones within the model, then the bone positions and rotations are updated using the ODE geom/joint info. @EmerGki: You need to make sure you duplicate each setting the cars use, for example you would use Force(car1), Force(car2), Torque(car1), Torque(car2) etc for all settings. It would be best to post some of your code so that we can help you properly, use the [ codebox ] [ /codebox ] tags without the spaces. |
| ||
| I've uploaded a new version of the Zombie RagDoll demo with fixed geometry alignment using Geom Transform and new hand joints/geoms... [edit] New download added below |
| ||
| Thanks Viper, My problems is whit the reposition the car, I tried all "SetPositions" commands, but, not happens :(. What I need to do, to reposition the cars? |
| ||
| Don't forget to reposition the wheels too. You should use the dBodySetPosition(ode\body,x,y,z) function when repositioning the car body and the wheels. Can you post some example code showing the problem? |
| ||
| yeah vip3r, THATS IT! really cool mate :D |
| ||
| Vip3r, Very Thanks, Now Work Correctly =). |
| ||
| Thanks OJay :) You're welcome EmerGki, glad to hear it's working ok now ;) |
| ||
| [edit] New download added below |
| ||
| I've uploaded -yet- another new version of the Zombie RagDoll demo... The new download contains the final version which will be added to the main wrapper download. The horrendous mesh glitches that no-one seemed to notice are now fixed ;) |
| ||
| Thanks VIP3R. I purchased your excellent wrapper a few days ago and am having great fun with it. Keep up the good work! |
| ||
| I'm having trouble with object penetration. Consider a seesaw of a plank witha rotational hinge. Just above one end of the plank is a ragdoll made of blocks. Dropping onto the other end is a cube. The ragdoll blocks are disabled at the beginning of the scene so they don't drop. When the block hits the one of the seesaw, it tips and hits the feet of the ragdoll who is catapulted. My problem is that with high friction on the seesaw plank, the ragdoll's feet pass straight through and get caught. Even with a QStepSize of 200 this happens. If the ragdoll is enabled, collisions work much better but of course it drops through gravity. Any suggestions to enable a ragdoll to stand upright and get catapulted from a seesaw without getting stuck in it? |
| ||
| Hi Shifty, Would you post that fun example ? |
| ||
| I've cobbled together an example, cannabalising the ODE Ragdoll demo. It's using quite different parameters to my engine, different ragdoll, etc. Run this and see it working properly in slow motion... Now if you increase dWorldQuickStep() to speed things up, to say 1.2 you should get passthrough. At least I do! Likewsie changing the gravity to speed things up messes things about. I've found with a few tests that at QStep=1.2, when gravity =0.95 speed is about 'realtime' and the collision works (though with a different result to slowmo mode) but at g=0.94 or 0.96, is bust. dWorldStep() actually performs worse. If you remove the first dBodyDisable() in the ragdoll creation, the ragdoll drops due to gravity and the collisions are pretty much problem free at higher speeds. It's like the enabling skips a frame's worth of collision so the second frame after the collision, the objects have already penetrated. |
| ||
| wow is that cool or what. checking it out further. |
| ||
| Hey you need a smaller time step to catch the collision, so try this: I changed gravity to: dWorldSetGravity(World,0,-0.98,0) and The time step to: For x=1 To 4 dSpaceCollide(Space,World,ContactGroup) dWorldQuickStep(World,0.05) dJointGroupEmpty(ContactGroup) Next |
| ||
| Ragdoll jumper, just for you shifty. Thanks for sharing. -enjoy |
| ||
| @Avon: You're welcome and thanks :) @Shifty: Wayne is correct. The problem is the speed of the collision compared to the length of time QuickStep passes. Speeding up the simulation by raising the step time will cause ODE to start skipping the contacts, regardless of the QuickStepNumIterations value. It has to do this to keep the simulation stepping in sync with real time. Also, setting the max contacts to '1' with 'dContactSetMaxContacts(1)' will help stop some of the penetration but not much. So, what's the solution? How do we speed up a simulation and still maintain the accuracy? The answer is to perform the 'complete' step process multiple times, so that it doesn't miss any contacts. For example, to speed the example up by 100%, you should call the QuickStep twice in the main loop... dSpaceCollide(Space,World,ContactGroup) dWorldQuickStep(World,0.1) dJointGroupEmpty(ContactGroup) dSpaceCollide(Space,World,ContactGroup) dWorldQuickStep(World,0.1) dJointGroupEmpty(ContactGroup) ...and voila, it's twice as fast without penetration. If your simulation ever gets penetration, lower the QuickStep value until it's no longer penetrating. Then start adding multiple QuickSteps with the same stable value to speed up the simulation. :) |
| ||
| Thanks! I thought that was what the numIterations did, seeing as that's what the name implies. Easy solution though, which is very encouraging! |
| ||
| wayne : Thanks for that! Good for playing, and I've found, at least in that example, two iterations is enough. VIP3R : What exactly do the numIterations() do then? I can see that that wasn't iterating the collision tests which is where the fault lied. If I drop the numIterations down to 3 the simulation works well, with less variation than using 200 iterations. ODE defaults to 20 but if 3 is enough, isn't 20 wasteful? How much processing overhead does adding iterations have and have does it affect results? Edit : Actually I can see instability in the seesaw at lower iterations, so I guess it's accuracy of the resolving that numIterations pertains to. I've also lost my reliable results for no reason! In theory I'd have thought with the same setup, the outcome of the physics solution should be the same for all run-throughs. I've heard one explanation of why this isn't the case that's DirectX changing rounding methods on the fly, but it is odd. |
| ||
| That's it. As Viper says, the best way to achieve fast simulations with great accuracy is multiplying the steps per frame. But as the manual says (and i have checked it very well): QuickStep(0.2) != QuickStep(0.1) + QuickStep(0.1) From what i have tested, doind several the gravity is heavier and the forces too. Then you must know that the physicstime will be almost doubled, because the time of the calculation is the same whatever the timestep. Anyway, after some tuning, the results are better. |
| ||
| I also do a lot of custom collison tests such for magnetism. In theory these ought to be duplicated too per ODE step, but at the moment I'm only applying them once in the first Step and then repeating a couple of Steps on the collisions. Seems okay so far but without extensive testing. I could duplicate the processes but I'm not sure what sort of impact on performance I'd have though. |
| ||
| Thanks for sharing Shifty. I'm glad I was able to help, as you've found numIterations() controls the accuracy of the simulation, typically 20 is best, but if you want speed at the expense of accuracy then go lower. Lots of great support from the rest of the guys too. 8) |
| ||
| Breakable Joints I was thinking it would be interesting to see breakable joints. I thought I could examine the joint forces and break them when desired but the following not supported by JV/ODE: void dJointSetFeedback (dJointID, dJointFeedback *); dJointFeedback *dJointGetFeedback (dJointID); I also found this interesting: http://www.q12.org/pipermail/ode/2003-August/009620.html Comments? |
| ||
| You can break the joint. Just attach it to zero,zero and the joint is broken. For example, do it when too much force to the bodies attached to it... |
| ||
| Ok, I think my memory has returned and I should be able to create a nice breakable joint function. let me see now.. |
| ||
| Yes, breaking the joints is simple, but knowing when too much force is applied is more difficult. dbodygetforce(), and dbodygettorque() do not work as expected, and joint feedback is not supported. I can break joints by examing the magnitudes of linear and angular velocities, but it's the sudden stop that tears body parts off. The breakable joints contribution I posted above is interesting. 8) JV/ODE doesn't support this: void dJointSetFeedback (dJointID, dJointFeedback *); dJointFeedback *dJointGetFeedback (dJointID); During the world time step, the forces that are applied by each joint are computed. These forces are added directly to the joined bodies, and the user normally has no way of telling which joint contributed how much force. If this information is desired then the user can allocate a dJointFeedback structure and pass its pointer to the dJointSetFeedback() function. The feedback information structure is defined as follows: typedef struct dJointFeedback { dVector3 f1; // force that joint applies to body 1 dVector3 t1; // torque that joint applies to body 1 dVector3 f2; // force that joint applies to body 2 dVector3 t2; // torque that joint applies to body 2 } dJointFeedback; During the time step any feedback structures that are attached to joints will be filled in with the joint's force and torque information. The dJointGetFeedback() function returns the current feedback structure pointer, or 0 if none is used (this is the default). dJointSetFeedback() can be passed 0 to disable feedback for that joint. Now for some API design notes. It might seem strange to require that users perform the allocation of these structures. Why not just store the data statically in each joint? The reason is that not all users will use the feedback information, and even when it is used not all joints will need it. It will waste memory to store it statically, especially as this structure could grow to store a lot of extra information in the future. Why not have ODE allocate the structure itself, at the user's request? The reason is that contact joints (which are created and destroyed every time step) would require a lot of time to be spent in memory allocation if feedback is required. Letting the user do the allocation means that a better allocation strategy can be provided, e.g simply allocating them out of a fixed array. The alternative to this API is to have a joint-force callback. This would work of course, but it has a few problems. First, callbacks tend to pollute APIs and sometimes require the user to go through unnatural contortions to get the data to the right place. Second, this would expose ODE to being changed in the middle of a step (which would have bad consequences), and there would have to be some kind of guard against this or a debugging check for it - which would complicate things. |
| ||
| I managed this fun little creation by watching for sudden changes in linear acceleration. Shifty, I hope you don't mind the abuse I'm putting your code thru. *currently just supports one body part the head. Don't lose your head! 8) -enjoy |
| ||
| Wayne, I just wanted to say thanks for your various code examples. They are both fun and educational, and without your input I would not be enjoying JV-ODE as much as I am. Keep it coming! :) |
| ||
| Fantastic stuff. By all means give that ragdoll as much grief as you want! |
| ||
| In Seattle we have and American football saying, 'Bring the rain, bring the pain', so with that in mind here is the fully breakable RagDoll ( be gentle now ).  |
| ||
| Hehe, nice demos there Wayne :) Ok, the dBodyGetForce() and dBodyGetTorque() do appear to be working ok. [edit] Edited to show correct use Add the following code to the main loop of the 'Demo-Rope.bb' demo... before the 'dSpaceCollide()' function... dBodyGetForce(Joint(1)) : JFX#=dVectorX() : JFY#=dVectorY() : JFZ#=dVectorZ() dBodyGetTorque(Joint(1)) : JTX#=dVectorX() : JTY#=dVectorY() : JTZ#=dVectorZ() before the 'Flip'... Text 0,50,"Joint Force X:"+JFX Text 0,65,"Joint Force Y:"+JFY Text 0,80,"Joint Force Z:"+JFZ Text 0,105,"Joint Torque X:"+JTX Text 0,120,"Joint Torque Y:"+JTY Text 0,135,"Joint Torque Z:"+JTZ I'm very reluctant to add the contributor (Breakable Joints) code to JV-ODE, doing this could seriously affect reliability of the wrapper (it modifies at least 9 ODE source files). As you've seen in the RagDoll demos it's possible to break a joint anyway. I'll look to see if the dJointSetFeedback() / dJointGetFeedback() functions can be added to JV-ODE and let you know my findings. One thing I need to watch for now is how it would affect speed and memory usage. Talking of RagDoll demos, here's the latest version of the standard demo which will be included in the next wrapper release. It now includes hand joints and a slightly different joint limit setup (to match the Zombie demo)... :) |
| ||
| Thanks Viper, I had the wrong parameter when I tested dbodygetforce and dbodygettorque, sorry about that. I agree with your approach to dJointSetFeedback and ode performace. Checking your new ragdoll stuff out. Thanks for the great support. |
| ||
| Very fun stuff. What'd be quite cool is a shooting gallery, where you can pop limbs of ragdoll. Perhaps something like clicking left mouse button to fire (apply a force at the object under the mouse, or at the end of a targetting beam) and using mouse y speed to determine shot velocity. I might give this a look, but at the moment my attention's all on work. I'm finally nearing the end of my project! |
| ||
| Viper the documentation says: const dReal * dBodyGetForce (dBodyID); const dReal * dBodyGetTorque (dBodyID); but you have: dBodyGetForce(Joint(1)) dBodyGetTorque(Joint(1)) Body or joint ? |
| ||
| You can use them for both AFAIK :) [edit] Ok, you must call dBodyGetForce() and dBodyGetTorque() before dSpaceCollide() in the main loop for the functions to work correctly. The dWorldQuickStep() process will zero their value, so they must be called before it. Here's the Rope demo showing dBodyGetForce() and dBodyGetTorque() being used correctly with both the Body ID (rope sphere) and the Joint ID (rope joint)... |
| ||
| Breakable joints I cleaned up the code some, added comments. Features dbodyGetForce, dbodyGetTorque, and timer based physics, mouse look, and rendering. This should run at the same speed on most machines. As always many ways to accomplish these things. |
| ||
| Wow! Great Wayne! |
| ||
| Hehe, excellent stuff :) Imagine how much fun it would be to line a few of those breakable RagDolls up and blow them all to pieces with some heavy weaponry! |
| ||
| Update: I've got the dJointSetFeedback() / dJointGetFeedback() functions working well in JV-ODE now. The new functions will return all force and torque data for each axis of a joint via the JV-ODE Vector Functions. Feedback will be enabled on every joint by default, but it can be disabled thus having no impact on speed and memory if joint feedback is not required. Coming soon in V1.11 :) |
| ||
| wow, great stuff Viper ! I'm looking forward to seeing that addition. I would think the default should be 'feedback disabled' and thus not effect any of the demos or current working in progress. Advanced users who need this function could turn it on knowing the memory and speed impact. JV-ODE Just gets better every day. Thanks VIP3R! |
| ||
| Cheers Wayne :) I agree, it might be best to disable joint feedback by default. I'm thinking about adding dJointSetFeedbackMode() and dJointGetFeedbackMode() functions. When set to '0' (disabled - default), no joints will have feedback (as it is now). When set to '1' (enabled), all joints will have feedback by default. If enabled, you would still be able to disable individual joints using the dJointSetFeedback() function. From the testing I've done, the impact on speed and memory would be unnoticeable in most cases, of course it's all relative to the quantity of joints in the simulation. :) |
| ||
| Update: After more testing I've decided to scrap the default joint feedback idea using dJointSetFeedbackMode() and dJointGetFeedbackMode(). It would be much better to enable or disable joint feedback on any individual joint, at any time during the simulation. The new dJointFeedbackEnable(joint) and dJointFeedbackDisable(joint) functions will allow you to retrieve joint feedback as needed. I'll also be adding a dJointFeedbackIsEnabled(joint) function to return whether feedback is currently enabled or disabled on an individual joint. There will be a modified car demo to show the Joint Feedback functions being used to return force and torque data from the wheel joints. |
| ||
| I agree VIP3R as it gives us more control of the simulation. The joint forces should be interesting , i'm looking forward to it. |
| ||
| Hi, Great job Wayne. Now you are ready for a "car crash-test demo". :) LOL |
| ||
| JV-ODE V1.11 Update Released Please check your inbox :) The new update includes: Added new joint feedback functions... dJointFeedbackEnable(joint) dJointFeedbackDisable(joint) dJointFeedbackIsEnabled(joint) dJointSetFeedback(joint,feedback) dJointGetFeedbackForce1(joint) dJointGetFeedbackTorque1(joint) dJointGetFeedbackForce2(joint) dJointGetFeedbackTorque2(joint) Added new demos... Demo-RagDolls (Update) Demo-RagDolls-Zombie CarDemo-JointFeedback Don't forget to update your 'JV-ODE.decls' file in the Blitz3D Userlibs folder! Please let me know if you experience any problems with the new update. :) |
| ||
| I know JV-ODE is primarily being used in Blitz3d. However, It states on the web page that it can be used with any compiler that supports dll's. Anybody try it with iBasic, Purebasic ,Darkbasic or VB6 etc ...? I am curious because I need a physics engine for a vb6/truevision3d 6.2 app and if this will work I will buy it asap. It would be nice to have a one stop for physics regardless of which environment I am tasked to use :) Thanks, Allan |
| ||
| All functions in JV-ODE use the _stdcall calling convention. Providing that those languages can successfully transfer and handle the data (essentially floats and ints) from the DLL, then JV-ODE should work with them. I do not currently have access to any of the above languages, so it's not something I've tested personally. When JV-ODE was first created, Jedive attempted to create a .dba(?) file for DarkBasic but IIRC he didn't have much spare-time/luck with it. To find out if you can use JV-ODE in the desired language, you need to create a function declaration file for the 'demo version' of the DLL (like the .decls file in Blitz3D). If the demo version works, there's no reason why the full version wouldn't. All the info you need to do this should be contained within the 'JV-ODE.decls' file. If the language doesn't use a declaration file like Blitz and DB, you would probably need to use a similar method to the one BlitzMax uses. There's an example of this above (posted by Chris C). In the full version, you will of course need to add and convert the 'JV-ODE.bb' include file, especially if you need access to the TriMesh functions. I'll help with the technical stuff if anyone would like to take a shot at it. |
| ||
| Hi, To VIP3R. Nothing in my inbox. :-( Zali Jean-Pierre at zali@... Share-it ref : réf. : 33791435 |
| ||
| Hi ZJP, Your email server is refusing to accept it... This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. The following addresses failed: <ZALI...removed> SMTP error from remote server in greeting: host mail.cgit.com[194...removed]: 501 Le domaine doit être résolu ...do you have another address? |
| ||
| Greetings, I got ODE this morning and already forgot about 3 painfull years of tokamak! ;) I've been having tremendous success with ODE so far, really cool and quick results! Got one problem though (only one?), I'm use a trimesh (to replace my 'StaticMesh') for my static scene. But for some reason I have a problem for bodies to 'come to rest' on it. Most of the time they keep bobbing around, or jittering (millimeters) and most of the time refuse to auto-disable themselves. Especially when I've got e.g. two boxes stacked ontop of each other, they keep bouncing between themselves (very minute). As if they keep trying to sink through the floor. I'm using normal scale models (box = 1 cubic unit, mass=1). Got all the bounce parameters to 0.1, world friction to 80, world erp at 0.2. And just like in the CarDemo-TriMesh-Cube.bb. I use two spaces, one for the staticmesh/trimesh's, and one for the objects (simple boxes). But for some reason my boxes won't relax!... :( Any hints on what to tweak? cheers, Danny |
| ||
| Welcome aboard Danny :) Try this function after creating your ODE World with dWorldCreate()... dWorldSetContactSurfaceLayer(World,0.1) ...raising the value will reduce jitters and lowering it will increase jitters (it's 0.0 by default). |
| ||
| Welcome Danny, My self I like to take command of the objects with these: dWorldSetAutoDisableFlag (World, 1) dBodySetAutoDisableFlag(ode\body,1) ; Set the value where you want object to go quiet. dBodySetAutoDisableAngularThreshold(ode\body,.05) dBodySetAutoDisableLinearThreshold(ode\body,.05) ; Set how fast you want to settle on the threshold 1-Fast, 2-n allow more settle time. dBodySetAutoDisableSteps (ode\body, 1) |
| ||
| Thanks Wayne & Vip3r, Yes I've been playing with those settings as well. With reasonable luck. The SurfaceLayer function Vip3r mentions does sort of work, but seriously (!) eats away accuracy (0.1 would mean I lose 10cm's of detail / objects will sink into the floor comfortably). I can't afford that. Also, when using trimesh's I also notice when bodies fall on the (trimesh-)floor, that they easily sink into it for a little bit/intersect as if falling on soft foam before coming back up to their proper level... :( But regardless of those settings/functions, I still have trouble to 'relax' bodies that are stacked on top of each other... I'll post a little demo in a minute that I made with broken tables. (I'll use a new thread - I think it's time to put this one to bed (again) ;)) cheers, Danny |
| ||
| The '0.1' was an example figure, you need to gradually increase/test it from '0.0' to get a good compromised value. In the TriMesh-Cube car demo, a value of '0.001' will prevent the jitter effect. Regarding the sinking geometry, a few things can cause those kind of problems. The usual suspects are: The TriMesh triangles are too large (compared to colliding object) Adding too little mass to an object (not enough density) Adding too much mass to an object ERP contact setting CFM contact setting dWorldQuickStep() step size is too large You can also try changing the max contacts setting with dContactSetMaxContacts(max) and see if that helps, the default value is 128. |
| ||
| Thanks for that Vip3r, I keep playing and tweaking and slowly things are becomming more clear - and more predictable! There's just too many functions to play with and absorb all at once ;) ...need to break more tables... |
| ||
| Hi, TO VIP3R ;-) New mail address : prisme99@... Thanks for the release Jean-Pierre So, any suggestions to drive these models http://www.3drt.com/3dm/drop-ship/d-ship-shots.htm I'm working on a flying simulator. |
| ||
| Email sent and you're welcome :) Do you want me to use the new address for future updates? |
| ||
| Hi, To VIP3R Update ok. You can use this address now. Sorry, poor english, french people. ;-) JP |
| ||
| @ZJP: No problem, your new email address will receive future update notifications :) Here's a modified car demo which uses Ball/AMotor Joints for the rear wheels. It's another method which can be applied to prevent the infamous wobbly rear wheel problem. In the demo the rear wheels have no suspension when using these two joints, I'm not sure if it's possible without resorting to adding separate suspension units. Most importantly it gives everyone some idea of how the AMotor can be used. |
| ||
| Hi everyone, Some ideas to "flying" a cube like an elicopter ? JP |
| ||
| Apply a relative velocity to body pointing in the body's Y direction (or whatever you have as up). Vary the size of the force to vary lift. Tilting the cube will divert some of that force to forward momentum. Just like a real chopper! You'd need to add some resistance though so when you start moving forwards, you gradually decelerate when the 'helicopter' is level and the force is only providing lift. For controllers, you'll need rotor-speed (force value), pitch, and roll, and maybe yaw if you're feeling adventurous. |
| ||
| Does someone have some JV-ODE code for cardriving like the "VERLE CAR". I think the car demos for JV-ODE is really good for simulation but i dont get the "player/game friendly" feeling. This is no criticism i just need some more "fiendly" code for a kid´s game. |
| ||
| You should be able to setup a JV-ODE car with a very similar feeling. Although, which car do you mean? There are several different cars in the VERLE demo :) JV-ODE is not much different to the physics engines in games like GTA3. Endless different types of vehicle handling can be achieved by altering the mass, suspension, wheelbase, grip, torque, gear ratios, FWD/RWD/4WD transmission etc. The problem here is perspective, can you describe what aspects of the handling in the VERLE demo you like the feel of? |
| ||
| I will give it one more try and then post my code and maybe get some feedback/help :) |
| ||
| Strangely and surprisingly, there appears to be no SetRelativeVelocity for bodies. Is the option to set linear velocity only global? Bit of a pain, but I can (theoretically) transform an absolute force into relative based on the direction the Blitz mesh is pointing. Edit : I've just found dBodyVectorToWorld() which does the job, though it is surprising there's no Relative speed option. |
| ||
| THREAD 5 IS ABOUT TO CLOSE Getting a bit long now ;) Please continue on the new thread located here Thanks :) |
   |