JV-ODE Physics Thread 9
Blitz3D Forums/Blitz3D Userlibs/JV-ODE Physics Thread 9
| ||
| Now available for Blitz3D & BlitzMax (Win32) The JV-ODE Physics Wrapper is an advanced user library supporting almost all of the Open Dynamics Engine functions wrapped inside a DLL (Dynamic Link Library). The library can be used with any programming language that supports DLL's, including Blitz3D and BlitzMax (Win32). The Euler rotation system in JV-ODE has been adapted to match the left-handed Euler rotation used in Blitz3D, however functions for accessing Quaternion and Axis Angle rotation systems are also included. The full versions contain all of the necessary files to get you started, including over 30 demos showing the various features found in ODE and a complete Function Reference document. The BlitzMax (Win32) version also features a built-in 'bare-bones' OpenGL 3D engine module and B3D mesh loader module for demo purposes. To view more information and screenshots click here. Options are now available to purchase the wrapper using either PayPal or Share*it. The Blitz3D restricted demo version is now available for download here (211KB) The BlitzMax (Win32) restricted demo version is now available for download here (290KB) Have Fun :) Previous JV-ODE Blitz3D Threads: 1 2 3 4 5 6 7 8 Useful Links: ODE.org Website - ODE Wiki - ODE User Guide (PDF) - ODE User Guide (HTML) |
| ||
| Hi Vip3r my jv-ode.dll AND decls. file are both in the userlibs dir along with all of the examples and I have updated blitz3d to 1.98 runtime and IDE 1.98 file sizes: jvode.dll 230kb \ decls. 26kb as expected... ...and the last line in the decls. file is dregisterODE(key1,key 2,key 3,key 4) : _dregisterode@(number) ..its all there! My JV-ode.bb include has the dregisterode(4 hex? keys) I have no other open programs and virus checker AVG is off.. I downloaded the full 1.21 blitz3d version from devcode.co.uk on Sunday 18/3/2007 at 9:51:39 GMT also I tried putting JV-ode.dll in system32 dir to no avail The JV-ODE.dll version comes up as 0.0.0.0? Should this be right? some of the demos work if i rem out dregisterode() in the include but the dversion() comes up as 1.0??? |
| ||
| Is there any way to parent an ODE object to a regular blitz object? I want to be able to parent my ODE object to my camera so I can drag my object around with the cameras movement and rotation. Also, I'd like it so heavy objects stop the camera from moving if you are trying to drag them... Any chance of a quick FPS style demo? ;o) |
| ||
| I decided to try the demo of BlitzMax with JV-ODE Bmax 1.21 I downloaded the BMAX demo and installed it. I unzipped the JV-ODE Bmax 1.21. Next I followed the JV ODE readme instructions: JV-ODE Installation: Copy the 'devcode.mod' folder and its contents into the 'mod' folder of your BlitzMax (Win32) installation. Open BlitzMax. Click 'Add Project' on the Home tab and select the 'devcode.mod' folder in your BlitzMax 'mod' folder. Next, using the BMAX IDE I opened one of the sample JVODE BMAX programs that were included, I hit build and run. Blitzmax Application Compile Error Can't find interface for module 'devcode.jvode' Lastly, I opened one of the Bmax sample programs and they ran and loaded correctly. Whats broken ? |
| ||
| PROBLEM SOLVED!! The version (jv-ode.dll) I downloaded from the purchase website was an old version even though it states ver 1.21!!(280kb as stated!) I just tried out the demo version of tricky tracks and saw that the dv-ode.dll was 480kb!!!! surely this couldnt be ver 1.21...could it??? yes it was and it accepted my dregister() function call I am finally sorted! (not to mention happy!) So if anyone is having problems like this check yer filesizes against others demos.. I can start coding now..thanx to danny and vip3r for suggestions by the way. |
| ||
| The JV-ODE.dll version comes up as 0.0.0.0? Should this be right? some of the demos work if i rem out dregisterode() in the include but the dversion() comes up as 1.0??? Yep, 0.0.0.0 is normal. The DLL uses a dedicated function to return the version info. If the version info comes up as 1.0, then it has loaded the demo version DLL, not the full version DLL. The latest versions of JV-ODE are much more optimised than the one included with Tricky Tracks, hence the size difference. The full version purchase downloads are the latest version, they get updated within hours of a new version release. You've got your demo and full version DLLs mixed up, the JV-ODE V1.21 DLL is 230KB. If you run into the same problem in future, remove all traces of the demo version of JV-ODE before installing the full version. Anyway, glad you've finally sorted it :) @JA2: Parenting an ODE object to a Blitz object is not possible, it also defeats the purpose of the physics engine, that is to create a physics response to a collision. If you manually position/rotate it, then ODE can't do what it's supposed to do. If you want the camera to move around with the ODE object, then parent the camera to the Blitz object representing the ODE object (the visible geometry). If you want heavy objects to stop the camera object, make sure the heavy object has more mass than the camera object. There's no such thing as a 'quick' FPS demo ;) @Wayne: Nothing's broken, you haven't updated your BlitzMax installation with the full version modules. It's looking for the 'DevCode.JVODE' module (which is the full version), while the demo version of JV-ODE and its demos use the 'DevCode.JVODEDemo' module. If you want to run the full version of JV-ODE in BlitzMax, you need to add the 'DevCode.JVODE' module to your BlitzMax installation. There's another JV-ODE thread for the BlitzMax version btw, check the link in sig below. |
| ||
| I'm confused. I have Blitzmax demo 1.12, it's installed and works with it's included sample BMAX programs. I also have JV-ODE-V121-BlitzMax (Full version) I followed the JV-ODE-V121-BlitzMax readme, and did the following: Copy the 'devcode.mod' folder and its contents into the 'mod' folder of your BlitzMax (Win32) installation. Open BlitzMax. Click 'Add Project' on the Home tab and select the 'devcode.mod' folder in your BlitzMax 'mod' folder. Next, using the BMAX IDE I opened one of the sample JVODE BMAX programs that were included, I hit build and run. I get a window that says: Blitzmax Application Compile Error Can't find interface for module 'devcode.jvode' The program start of the program looked like this: ' ################################################################################################### ' # JV-ODE Car Demo # ' # Code by Jim Williams (VIP3R) # ' # Devious Codeworks - Copyright © 2007 # ' ################################################################################################### SuperStrict Framework BRL.GLMax2D Import BRL.Random Import DevCode.JVODE Import DevCode.JVODEOpenGL Under the home tab I see devcode.mod with children jvode.mod. jvodeb3dloader.mod, and jvodeopengl.mod. C:\Program Files\BlitzMaxDemo\mod\devcode.mod\jvode.mod shows: jvode.debug.win32.x86.a 221kb jvode.debug.win32.x86.i 35kb jvode.release.win32.x86.a 161kb jvode.release.win32.x86.i 35kb output: Building CarDemo-MultipleSpace Compiling:CarDemo-MultipleSpace.bmx Compile Error: Can't find interface for module 'devcode.jvode' [C:/Documents and Settings/HP_Administrator/Desktop/JV-ODE-V121-BlitzMax/JV-ODE Physics BlitzMax/CarDemo-MultipleSpace.bmx;11;1] Build Error: failed to compile C:/Documents and Settings/HP_Administrator/Desktop/JV-ODE-V121-BlitzMax/JV-ODE Physics BlitzMax/CarDemo-MultipleSpace.bmx Process complete The link in your sig returns Internal Error. 8) Not sure what more I should do. |
| ||
| Ah gotcha, you're running the demo version of BlitzMax. I don't know if JV-ODE will run with the demo version tbh. Everything in your mod folder looks ok, I'm guessing the compile problem is due to the old BlitzMax V1.12 demo as it has changed significantly since then. I take it you're not logged into blitzmax.com? If you're logged into blitzbasic.com, you need to use that domain in the sig link instead. The thread is in the 'BlitzMax Module Tweaks' forum. |
| ||
| Hi Im using the blitz3d version. It seems that I cant run 2 blitz programs on the same computer without the second blitz program locking up. Presumably because of the dregisterODE function. Is there an easy fix for this? thanks |
| ||
| I've tried to recreate the problem here with two JV-ODE demos, both from the IDE and compiled EXEs. In both cases they're running fine without any lock ups. I've even tried running four EXEs simultaneously from separate locations, they run fine too, as to be expected they're a little slow but still no lock ups. The register function shouldn't cause a problem, are you sure JV-ODE is the culprit? |
| ||
| I'm having another problem. When I connect 2 objects together, for example a drawer to the chest of drawers, if I click and move the chest then it moves slowly as it has a high mass, but if I click and drag a drawer (with a low mass) then the chest is also dragged along with the drawer as if it weighs nothing... What could I be doing wrong? |
| ||
| thanks for checking it out. As soon as I comment out the include file it works normally so Im pretty sure Its the physics DLL. Im using Win98 so maybe it interacts in a different way to WinXP. |
| ||
| @Chunkations: No problem. I'm not sure what would cause it to lock up, even on Win98, but I suspect it's due to memory conflicts and/or the Win98 OS Kernel32/User32 DLLs. I've managed to reproduce it in Virtual PC, there is a solution but it might not be suitable. You would need to rename the DLL (also in the decls) for the second application and create another EXE using the renamed library. It will then run both 'Test.exe + JV-ODE.dll' and 'Test2.exe + JV-ODE2.dll' simultaneously on Win98. @JA2: If you can send me an example showing the problem I'll take a look at it for you. It might be due to the joint set up. |
| ||
| ok thanks, ill check it out |
| ||
| VIP3R, sent you an email with a quick demo attached. Hope I sent it to the right place, just checked your email addy in your profile and it's different :o |
| ||
| Thanks JA2, I've received the email and spotted the problem. It's related to the way you're applying forces based on an objects mass, I've replied explaining how to correct it. |
| ||
| Thanks VIP3R. It's now fixed so I'm back to breaking it ;) |
| ||
| On the tri-mesh demo, there seems to be a lot jittering between the meshes. I'm having a similar issue with my tri-meshes, especially with collisions, if I drop one on top of another then they kind of explode in opposite directions... Is there a way around this? |
| ||
| Hi VIP3R, I need to Reposition my Vehicles in my game, but, when I Try to do this, the vehicles go insane, jumping, rotating and etc... I'm using the comands: dBodySetRotation(ode\body,RotX#,RotY#,RotZ#) dBodySetPosition(ode\body,PosX#,PosY#,PosZ#) And other thing, How many cars the JV-ODE support in the game? Because I try to use 10 vehicles and the Physics time go to 6 or 7, and, when I try to use 20 vehicles, I receive the message "Stack Overflow" |
| ||
| @JA2: You can adjust the constraint force mixing to improve jitter problems like those. Try adding dWorldSetCFM(World,1.0) before the create light code in the 'Demo-Trimeshes' demo. You can also use the dWorldSetContactSurfaceLayer(world,depth#) function to adjust the collision depth to help improve it. @EmerGki: Make sure you zero the forces on the vehicle/wheels/joints before moving them. It's easier to delete the car and create a new one at the new location. There's no limit on the amount of cars you can use in JV-ODE, but there is a limit depending on your system specs, for example processing power and memory. A stack overflow is normally caused by too many objects overlapping when created, check you're not creating the cars in the same locations. I've tried 32 cars here and it runs fine, the physics time never goes higher than 3, but it's running on a powerful system with lots of memory. |
| ||
| VIP3R: I had a play with the CFM and the contactsurface like you suggested. It has stopped some of the explosion effect but I can't get it to an acceptable level. If you still have the code I sent you, it is the wheelsexample() that I'm having the problem with :( I tried it using a box instead of a trimesh and it works perfectly. Is there an issue with colliding tri meshes? I have even tried making different wheel models to test with but I get the same result. Applying the CFM and contactsurface settings to the demo stops the jittering tho... |
| ||
| Hi JA2, I don't keep other folks code so I no longer have the code you sent over unfortunately. It's entirely possible that TriMesh to TriMesh collisions may still be unstable, the contributors working on ODE have only recently got them colliding properly. They're also notoriously slow, as I warned when they were added to JV-ODE. Anyone who knows physics engines well enough will tell you that triangle soup (TriMesh) collision algorithms are very slow when used in real time and that complex meshes should be replaced with primitive collision geometry (boxes, spheres, cylinders etc) instead. Most complex geometry can be approximated using several primitive geoms, vastly increasing performance. |
| ||
| I'll try and work around the problem for now then. I think most items should be ok with a simpler collision primitive. Fingers crossed for more stable trimesh collisions in the future ;o) |
| ||
| I've made myself a function to make a ring of spheres using geom offset to replace the trimesh for my wheel model. Works great except that I always end up with one sphere in the center. This is the original geom that belongs to the ode type. Is there a way to turn off collisions for a geom? |
| ||
| you can make a geom with a size of 0,0,0 |
| ||
| When using Geom Transforms you needed to use a geom size of 0,0,0. When using Geom Offsets you can offset the first (original) geom. The same method is used to offset the car geom in the 'CarDemo-GeomOffset-Car' demo, which has only one geom contained within the body. |
| ||
| Awesome, thanks guys :) |
| ||
| I know that dSetInternalSpaceCollideMode is used to turn off /on collisions in the same space. Is this just a global setting or can it be set that only certain spaces have it turned on or off ? |
| ||
| It's a global setting, if you need objects to collide you can place them into the top level space or a different sub-space. |
| ||
| Im just interested to know how/if people are using ODE for player movement. Take for example you were moving the Zombie. You would have to place a Sphere at his feet which isnt a problem, but how do you get the rest of his body to interact with the physics engine ? You cant create a stretched box as obviously it cant roll. (well it can but it topples over) Ive tried attaching a rectangle to the sphere using a joint then applying forces to keep it upright. THis is proving nigh on impossible. Viper (god bless him) sent me this link and suggestion :- You can attach it to the sphere with a ball joint, but you would need to apply a small constant upwards force to keep it upright. Or, you could use a different joint (hinge/amotor) and use the joint motors to keep it upright. The car demos use joint motors to provide force and torque to the wheels, so use those for reference. Have a read of the following link too, it does a similar thing but with spring dampening and rays... http://opende.sourceforge.net/wiki/index.php/HOWTO_upright_capsule The other course Im thinking of using (which seems overkill) is to create a car base that a box geom will sit on, this will act as a trolley that can be pushed and pulled into position....... |
| ||
| @OvineByDesign: Have a look on the last thread, Danny made an awesome ragdoll demo using an animated model :) @Everybody: Using the ramp demo for an example, if I change dBodySetRotation(ode\body,0,0,0) to dBodySetRotation(ode\body,0,45,0) for both ramp pieces then still they align perfectly but the joint axis is now incorrect. What would be the best approach for setting joint anchors/axis based on a models rotation? |
| ||
| That's funny, both you guys are talking what I've been messing around with for the last two weeks :) Although with limited success to be honest... @OBD: Yes, you can create a ragdoll setup. And switch between two modes: 1. Animation Mode: Where the bone-animation DRIVES the ode rigid bodies (so you have animation + proper collision detection) 2. Ragdoll Mode: Where you let the ODE simulator drive the rigid bodies - that in turn drive the bones. When a character is walking you'll have it in Animation Mode, when it get's shot or clubbed on the head you detect that foreign collision and switch to ragdoll mode so the character collapses or is blown over.. But as JA2 mentioned, once you want your collapsed ragdoll to go back to animation mode, you'll have to reset all the rigid bodies and joint positions to match a model's "current state". Setting the rigid bodies is easy (just position+rotate them equal to the bones), but I also have serious trouble re-setting a joint's axis when a model has been rotated, etc. ESPECIALLY ""trying"" to restore the axis at such an angle that it's original lo/hi stop values are correct again! And that's the thing I don't seem to be able to tackle. Too much math for my limited brain I guess.. Let's take a knee-joint (hinge) for example. The Thigh and Shin bones are at a certain angle from each other (in their default pose). The joint axis is in Global coordinates - as are the Lo/Hi stop values. BUT as soon as you Attach a joint, it keeps the two rigid bodies 'relative' to their initial angles... So if I set up a rig from default pose, that's no problem. But if I want to re-rig it whilst the character is lying on the floor in a heap for example, I haven't got a clue how to deal with this.... (too many angles, objects, vectors vs eulers, etc.) Does anyone understand what I'm saying here?! :) Let alone possibly have some hints?! thanks, D. |
| ||
| @JA2 - Thanks for the advice - never thought that demo was relivant - but it was ! The forcing of GEOM positioning works a treat for me (as Im primarily working in 2D). @Danny As you've stated before, the idea of moving a body by forces is really the only way you can go with your problem. Sounds like a fair bit of maths to me. |
| ||
| LOL I'm having exactly the same kind of problem as the knee hinge example... I want to make a chest with a lid. Easy enough to set up the hinge joint as long as the chest hasn't been rotated yet :( |
| ||
| Hi folks, The only way I know of rigging a model with the correct joint angles is by rigging it while it's still in its initial position (default pose). Trying to re-rig it when it's in a different position (lying down etc) would be a nightmare, as you've probably discovered. Not sure whether it's even possible tbh, if it can be done then one man who might know is Ricky Smith who designed PaceMaker using JV-ODE. @OvineByDesign: I'll experiment with the upright body problem for you as soon as I've got a spare few hours. If I have any luck I'll let you know ;) |
| ||
| @Vip3r Thanks , the set position of the geom seems to be working tho'. Would be nice to get it done properly. The constant force up seems to work for stationary objects - but as soon as it moves thats when the motors would have to kick in. |
| ||
| @JA2, here's a little test I did trying to resolve 'rebuilding a rig' from an object's (chest/character) current state. I tried figuring out the math's to solve the lo/hi stop values but ... no way josé... But at least this workaround works... It has a chest and a leg rig included which you can select and test... Hit SPACEBAR to toggle between ragdoll & animation mode, and ENTER to kick the object (in ragdoll mode). Hope this helps, D. |
| ||
| Hey that's pretty cool. I see what you mean about the hi/lo stop values. After changing animation/ode driven modes a few times the meshes start to intersect. I have kinda solved my chest problem. I just move the ode object after creating it and setting up the joints. Would it not be possible to record a meshes xyz position/rotation when you change mode, then return the mesh to 0,0,0, re-rig it, then move it back to where it was using the stored info? |
| ||
| "Would it not be possible to record a meshes xyz position/rotation when you change mode, then return the mesh to 0,0,0, re-rig it, then move it back to where it was using the stored info?" That's exactly what the demo does :))) What's different (than what I used to have) is that I can destroy a rig and re-create it only when it's needed. So characters/objects that are way off screen will have their rig purged to save overhead on the simulator.. d. |
| ||
| I feel I have to share my experience with a recent bug that I must have spend 4 hours trying to fix, just in case you come across it. By setting dBodySetGravityMode() on a Geom seriously stuffs the engine in random places (usually in destroying Geom/Body) So dont use dBodySetGravityMode() on GEOMS else you'll waste hours debugging !!!!!! |
| ||
| Thanks for the tip OBD but could you eleborate a bit more?! I intend to use extensive use of dbodysetgravitymode and your comment surprises me a bit. You'd think that disabling gravity in some cases should save ODE a couple cycles calculating.. thanks, D. |
| ||
| To clarify I was using dBodySetGravityMode() on a Non-Body entity......... which obviously is wrong |
| ||
| In other words, don't use the 'Body' functions on 'Geoms', they should only be used with an ODE Body! OBD was doing this... dBodySetGravityMode(ode\geom,0) When it should have been... dBodySetGravityMode(ode\body,0) |
| ||
| I need some help with a bit of code... In the rope demo: dAreConnected(Sphere(1),Sphere(2)) returns true but dAreConnected(Sphere(1),Sphere(3)) returns false. So, how can I loop through all of the ode objects and work out what is indirectly linked to what?? |
| ||
| You can cycle through your body/joints using the following functions... dBodyGetNumJoints(body) dBodyGetJoint(body,index) dJointGetBody(joint,index) dAreConnected(body1,body2) The best way is to use an array or type 'beforehand' so that you don't have to iterate through loads of bodies and joints, thus wasting precious processing time. For example, in the rope demo you know that all bodies in the Sphere(1...10) array are connected using joints in the Joint(1...10) array. If you disconnect any of the joints, set the joint array value to zero for that joint. Now iterate through the arrays until you hit zero, then you have your list of connected bodies both direct and indirect. |
| ||
| Hi i have a problem with cylinder geom is can't collide with trimesh |
| ||
| Post the code Lyon |
| ||
| @Lyon: The flat-ended cylinder geom does not collide with a TriMesh, you need to sphere wrap them for TriMesh collision to work (see the 'CarDemo-SphereWrapCylinder' demo). Or you can use capsules (capped cylinders) instead which do collide with a TriMesh. [edit] What's wrong with these forums, that's the second time I've had to post the same reply. |
| ||
| Thanks. i have an other question, how can i set get car speed in km\h if 1unit=1 meter? |
| ||
| Speed = Distance Travelled / Time Taken It's more of a general programming question tbh, you would probably get a more detailed and quicker answer in the general Blitz3D forum area. |
| ||
| It's been a couple beers since some old geezer tried to explain this to me at school, but: "A BODY CAN NEVER FALL FASTER THAN GRAVITY" (when no other external forces apply) That statement is correct, no?! I'm trying to get deeper into forces, speed, etc. But this little test shows me that a body KEEPS ACCELERATING! That can't be right, can it?! Have I made a silly mistake or missing something entirely?!?? I expect a free-falling object to accelerate to the speed of gravity, but never exceed that speed. My shortest ODE proggy ever: :) Danny p.s. giving the body mass doesn't seem to affect this outcome. |
| ||
| The speed of light would most likely be the upper limit. If you continue to apply a force and object will continue to accelerate, unless acted upon by outside force, like friction. |
| ||
| It's normal for an object to accelerate as gravity pulls on it. I don't know what the 'old geezer' is talking about. Certain factors can affect the acceleration like the strength of gravity force, the mass of the object and any drag resistance from stuff like air. I don't think ODE models air resistance so the drag would need to be implemented manually yourself. But yes, as far as I'm aware objects accelerate when being pulled by gravity. [edit] Cheers Wayne, beat me to it ;) |
| ||
| Ok thanks. yes silly me. I've done a little refresher course in the meantime ;) As you said, it will continue to 'accelerate' (cumulative force) I thought it would sort of level out at 9.8 m/s Shoult haf payd moor attention in skool ;) |
| ||
| Has anyone had any luck using rays to position an object? I've had a look at the blitz max ray example but I can't get it to do what I want... Just making a sphere float in the air by shooting rays downwards is all I need. |
| ||
| How far have you got so far ? What dont you understand about them ? If you want things to float - why not disable gravity on the body, then apply force to it a ray to determine how far above the ground it is. |
| ||
| Well I was reading about making a FPS character using a ray to keep it above the ground. I converted some of the blitz max example to blitz 3d. When I create a ray it just makes things bounce around. I'll continue to play about with it tho... I'm after something similar to a line pick straight down so I can walk my camera up and down stairs etc. |
| ||
| If you want to use the rays as a line pick, you should call the dSpaceCollide() and dJointGroupEmpty() functions separately without stepping the simulation, like the BlitzMax demo shows. Otherwise they will behave like any other physics object and react to gravity, impacts and forces etc. |
| ||
I create 1 main Space and 2 sub-space's like this:PHX_Space=dHashSpaceCreate(0) PHX_StaticSpace=dHashSpaceCreate(PHX_Space) PHX_MotorSpace=dHashSpaceCreate(PHX_Space)PHX_Space = where I create my dynamic items. PHX_StaticSpace = where I have my static trimesh level geometry. If I understand correctly, then together with.. dSetInternalSpaceCollideMode 0..this should prevent my Static mesh's to collide with each other - whilst my dynamic bodies still collide properly with the Static mesh's... Ok so far so good, this has been working well for some time. But now I wish to add another space because I've got some wacky rig I wish to use to (litterally) drive characters around. So I build these geoms in a new subspace: PHX_MotorSpace. The reason for this is that the current design I have forces me to intersect geometries. And since these will collide with each other, lots of nasty thing will happen which I don't want. That's the reason I put them in a new sub-space - with the idea that collision is not checked/performed 'within the same subspace'. _BUT_ the results don't seem to agree with that statement. Am I wrong (again) - if this theory is correct I probably made some other daft coding error. But after 4 hours I give up. Anyone? D. |
| ||
| Your theory is correct ;) When you disable internal space collision with the dSetInternalSpaceCollideMode(0) function, no collisions will occur between objects within the same sub-space. They will only collide with objects in the top level space or objects in another sub-space. So in your example, objects in MotorSpace will collide with objects in StaticSpace and Space, but those objects in MotorSpace will not collide with each other. It's possible you've created the objects in the wrong space or sub-space by mistake, a common copy/paste error. Double check the spaces in the geom creation functions of your objects. Another trick for avoiding collision with intersecting geometry is to add a fixed joint to them, as any objects which are directly jointed to each other will not collide regardless of the space setup. If you're still stuck and you're not comfortable posting the code, feel free to send it to me via email and I'll take a look for you. |
| ||
| Thanks a lot for that (again) vip3r. I'll try digging a bit deeper to see if I can fix my code. I considered the Joint solution but doesn't apply in this situation unfortunately. It's not so much being uncomfortable posting my code, it's just the bits and pieces spread out over 66 modules that would make it a tad complex - if not useless - let alone if anyone could make sense of it :) I like to think it's all nicely modular and structured but sometimes the obvious things don't seem to be that obvious at all ;) But this brings me to another point; When reading over the ode docs before, they use an example where 2 cars with their own setup are 'placed' into seperated spaces. To optimise collision checking and skip a car checking against it's own parts. Say you have a game with 30 odd cars crashing into each other. Do you have any insight if in that example it would be 'smart' splitting each up into it's own unique space? Or is there a trade-off where 'too many spaces' could backfire and counteract the advantage?! I have no intention at this stage to do something like that, but would be interested to know if that could make a difference when dealing with larger/complex worlds?! D. |
| ||
| Ok wait a sec... I double checked my code and both my objects ARE in the same sub-space. But the 'odd' behaviour I'm experiencing might not have to do with 'collision' as such. It's too hard to explain (not completely sure about it myself) but it "seems" that the forces and angular velocitiy of one body ARE affected by the other body intersecting it. When they DO intersect, I have a drag, and both fall through 'static space' objects eventually (internal struggle of some sort). When they DON'T intersect (but still in their own motorSpace) then they behave fine together and in relation to outer space bodies :) So even if this doesn't affect collision "behaviour" (they don't repel each other) I get the feeling that they DO interfear with each other's internal mechanics on the forces/velocity side!! Aghk- forget about it; 5 minutes to install a proper workaround that'll do just fine ;) D. |
| ||
| If there's no collision, there will be no physics response at all, so if the force/velocity of the objects are behaving oddly then I would examine any external forces being added manually (angular velocity damping etc). There shouldn't be any performance disadvantages when using a sub-space per car, possibly a small performance gain if anything. |
| ||
| Do you think that ODE will ever be changed so that SetInternalSpaceCollideMode() will turn off per sub-space ? |
| ||
| Bit o maths help needed. Im trying to set the direction vector of the RAY. Whats the easiest way of translating an angle into a vector that can be used with dGeomRaySet() ? |
| ||
| If you can get the angle from a pivot or other b3d entity can use TformVector 0,0,1, pivot, 0 - to get a forward pointing vector for example. If you got just got 3 variables holding angles then err... sorry left the kettle on.. |
| ||
| ah - unfortunately im in BlitzMax - so will need the maths function todo it ... I shall have a look in the MiniB3D and see if its implemented in there...... |
| ||
| SetInternalSpaceCollideMode() is unique to JV-ODE. It would be easy enough to implement per sub-space, but the reason it's not is because it would affect the performance during collision checking, even if sub-spaces are not used. |
| ||
| This is driving me crazy LOL I have looked through all of these pages http://opende.sourceforge.net/wiki/index.php/HOWTO_upright_capsule and spent a few days playing around with rays. I'm still none the wiser tho... I'm trying to implement a ray casting straight down from my player/camera to keep it in position and so I can make it walk up and down stairs. In the 'how to' section it mentions using the ray as a spring and dampening the forces but I have no idea how to do it... Can anyone help me please? |
| ||
| Hi Ja2, Sorry but I haven't played with rays yet so can't you help on that. It's an interesting demo, but if you look how the player character moves up a ramp (or up the stairs) you can see it's intersecting (submerging) like crazy and slowly corrects itself! I doubt you want something like that happening to a character with actual feet and legs!?! I'm guessing that the ray either has a natural tendancy to 'get out of the collision' thus propelling it upwards (and adjusting to the ramp) - or in code it registers the collision depth and compensates with an upward force. [EDIT] I don't know C++ but looking at the sourcecode (pplayer.cpp, lines 177-190) it clearly looks like he uses the ray (much line you'd do a LinePick) to check the height from the ground and if it's below ground to give it some upward force to correct.... Hope that helps, Danny. |
| ||
| Thanks Danny :) I have looked through the demo source code but I don't know C++ either. I've also tried a simple linepick and then add force upwards which looks awful. I was even manually positioning the body which works ok until you collide with something. Feel like I've tried everything :( Meanwhile, I have come across another problem... If I have an ODE body with more than 1 geom, then how can I test for collisions on all the connected geoms? I'm adding sound effects when 2 geoms collide, but if the collided object has more than 1 geom, the sounds don't work... Any ideas? |
| ||
| If I imagine your situation correctly, you should store the handles to all geometries you use. Can you then not check their individual collisions with dGeom1CountCollision(geom) and dGeom2CountCollision(geom) ?! I'm experimenting with a system loosely based on that "Sphere Demo Using Angular Velocities" by PhsyicParrot (see thread 7). In that I use a sphere for rolling the player. And only use it's position to place my player mesh and keep it upright. I also force a box geom ABOVE the sphere (position is forced using bodySetPosition) which enables me to PUSH other objects out of the way - which is very cool. BUT since that box's position is forced, it will simply 'pass through' any static collision geometry - which is pretty crap, really. Making the sphere the only object that prevents my player walking through static-walls. Which is good enough, but the sphere is of a small radius and no way coveres the full height of the player's body. Meaning if it would walk under a low bridge, it's torso would simply move THROUGH it :( If that makes any sense... What we really NEED is a function/routine that can PLACE any body ACCURATELY at a given XYZ position but internally uses forces (not velocity or dBodySetPosition), so that IT can collide with other bodies, and other bodies can collide into IT... With that you might conclude that if a body did not arrive at the given XYZ coordinates then it must have been 'obstructed' in some way ie. collided with something else... But I'm guessing such a function has to take into account things like mass, gravity, friction, AND the advance speed of the simulator (as a delta time). AND this probably only work on isolated bodies ie. not connected to any joints... Pff... should have finished school. Need more coffee... D. |
| ||
| LOL it sounds like we're workin on pretty much the same thing... I don't store all the geom handles I use, I made myself a GeomCage function that finds all of a models "Geom" children and automatically makes a box for each one, then joins them all together. I'll have a look at that tho. Maybe an array in the ODE type to store its geoms... I was also using PhsyicParrot's demo as a basis for my FPS player control. It drags tho on the ground... Then I tried the forced body method to position the body at my cameras position and then just moved the camera as normal. It worked great except that it doesn't collide correctly. Makes other object explode and doesn't get moved by other objects... I was going to post my code but we had a power cut a few hours back and I lost the past 4 days work. Guess it must have been in the middle of saving or something. After calling my computer a few rude names, I decided that it could have been worse. Now I get to try again with ray casting... I even had working soft bodies that I want to use for things like sacks, mattresses etc etc It would be great if VIP3R could make us a JV-ODE function like you're suggestiong. I vote for a dFPSCreatePlayer() function ;o) |
| ||
| Gosh 4 days work gone sucks big time! Yes I use angular velocity on the sphere to drive it. Linear velocity will make it drive straight through walls. And using force makes it's behaviour too unpredictable (for me at least, cause I don't have the maths to sort it out physically correct :( ) But I do use SetForce to make it jump. Right now I'm trying to sort out a formula that will take into account mass, sphere radius and the simulator timestep. So that it will run the SAME on any FPS! Something I haven't been able to do with ODE before in any way, shape or form. I know you should not use variable-timesteps in ode (and I'm not doing so) but it really makes things difficult to run the same on different systems in different circumstances.. Unless you lock your FPS to a set amount - but that's so 80's ;) Curious to know how you will get along with the raycasting approach. I never touched it since it sounds too much like a pogo-stick to me - and I never got the hang of that either :D Good luck to us both- |
| ||
| What could cause a MAV on the line: dSpaceCollide (Space,World,ContactGroup) I've just added sounds when my geoms collide and also made some objects breakable by removing the first ode object and making a few new ode objects in it's place. Normally it works just fine but I'm having this occasional error pop up... |
| ||
| A MAV can occur in dSpaceCollide() for a multitude of reasons, it isn't necessarily collision related. It commonly means either you and/or the physics engine has tried to access an object (or its properties) that doesn't exist. I'd suggest commenting out the stuff you've just added and gradually re-implement and test it at each stage until you find the culprit. Check you're not accessing collision info for the sounds on any geom that has no collision count or no longer exists, that could possibly cause it. It could also be due to accessing bodies, geoms and joints that no longer exist. |
| ||
| Thanks for the suggestions VIP3R :) I think it's fixed now but it leads me to another question. When you delete an ode object, are the geoms and bodies automatically freed? I ask because I was using dGeomDestroy and dBodyDestroy then deleting the ODE type... Now that I commented out the destroy commands, it works fine. It was definitely the deleting that broke it, tried your suggestion of commenting out all my new bits. EDIT: Bugger, no it isn't fixed :( Wierd that sometimes it crashes but sometimes runs without any problems. Will keep on it... |
| ||
| JA2, It's always best first to destroy every Geom you have, then the Body then the Joint then the ode type itself - in that order. I always do it manually to make sure it's all gone ;) Like Vip3r said, when ODE crashes the debugger often gives a totally different program line (or none at all) than where the actual problem is, so don't necesarily trust that response, the problem might well be somewhere else. Since you added sound effects, are you taking into account that ODE sometimes creates several 'contact points' (collision points) so if you let collisions TRIGGER a sound effect - to make sure you only play that soundfx ONCE (once for every object, and once every x milliseconds) - and not 'for every collision point'. Especially if you do not delete an object after it's first collision, it could trigger like dozens of soundfx in a single frame?! MAYBE that's what's choking it?! OR you're reading collision data when you've just deleted the geom/body ??? d. |
| ||
| Found it :) dGeomTransformSetCleanup TransformGeom,1 I added an array into my ODE type called Geoms[]. Stores up to 99 Geoms per object. When I was deleting the ODE type and 'trying' to destroy each Geom in the array, I got the error. Removing the line above fixed it... Just curious tho, what does that line do?? Danny, thanks for the tips on sound/collisions. I put in a small delay using millisecs to stop it going crazy. Everything else seems to be going smoothly. Back up to where I was before I lost my work. Still got to fix my FPS camera tho... just like you said, it looks a bit like a pogo stick LOL |
| ||
| dGeomTransformSetCleanup performs an automatic cleanup of the geoms when the transform is deleted. It doesn't remove the collision data though leading to potential memory leaks. The reason it's causing the MAV would be due to deleting the geoms manually, then ODE tries to do it too and they're not there anymore. Danny highlighted a problem with this function in JV-ODE Physics Thread 8, about a third of the way down. Have a look at it if you can. The solution to cleanup transform geoms and their data correctly is as follows... First you -must- set the transform cleanup mode to zero (disable) for this to work correctly... dGeomTransformSetCleanup TransformGeom,0Next, when you want to destroy the transform and parent geoms, you should do it in the following order... dGeomDestroy GeomObject dGeomDestroy TransformGeom dGeomDestroy Geom dBodyDestroy BodyNow everything is cleaned up correctly and there's no memory leak. I'd recommend switching over to Geom Offsets instead of Geom Transforms, as they're much easier to manage. If you want to delete entire objects, it's best to delete them individually in the reverse order that they were created... Joint(s) > Geom(s) > Body > Type |
| ||
| Just added those extra bits to my RemoveODE function. Everything seems good now. Before, when I was using dGeomTransformCleanup 1, when I deleted the object, I was still colliding with it... All fixed now tho. Thanks VIP3R :) |
| ||
| Hi sorry to jump in here, I'm not sure where else to post, first I'd like to say what a great wrapper this is, good work! Here is my problem at the moment, I'm trying to integrate the ode engine within my game structure which is fully Object Orientated using BlitzMax, I can convert some of the simple examples which come with the demo, for example the cube creating example, but what I'm trying to do is convert the car demo, I can create the car bosy but I can't create the wheels, here is the code so far: ' SuperCars ----------------------------- SuperStrict Framework BRL.GLMax2D Import BRL.Random Import DevCode.JVODEDemo Import DevCode.JVODEOpenGL AppTitle:String="SuperCars" SetGraphicsDriver GLMax2DDriver() Graphics 800,600,0,0 Global entGeomList:TList=CreateList() Global World:Int=dWorldCreate() Global Space:Int=dHashSpaceCreate(0) Global ContactGroup:Int=dJointGroupCreate(0) ' Car Type -------------------------------- Type TCar Field body:Int Field geom:Int Field mesh:Int Field rgb:Int[] Field scale:Float[] Field CarStartY:Int Field CMass:Float Field Car:Int Function Create:TCar() Local xp:Float Local zp:Float Local count:Int xp=Rand(-10,10) zp=Rand(-10,10) Local ode:TCar = New TCar ode.body=dBodyCreate(World) ode.Car = ode.body ode.CarStartY = 20 ode.CMass = 200 dBodySetAxisAngle(ode.body,0,0,0,0) dBodySetPosition(ode.body,0,ode.CarStartY,0) Local mass:Int = dMassCreate() dMassSetBoxTotal(mass,ode.CMass,3,1,4) dMassTranslate(mass,0,-1,0) dBodySetMass(ode.body,mass) dMassDestroy(mass) ode.geom=dCreateBox(Space,3.0,1.0,4.0) Local CGeom:Int = ode.geom dGeomSetBody(ode.geom,ode.body) ode.mesh=dBoxClass Local CMesh:Int = ode.mesh ode.rgb=[40,80,255] ode.scale=[3.0,1.0,4.0] ' Local wheels:TWheel TWheel.Create(ode:TCar) ' Create Wheels and pass the car ListAddLast(entGeomList,ode:TCar) End Function ' Update Car -------------- Method Update() glPushMatrix() glTranslatef(dGeomGetPositionX(geom),dGeomGetPositionY(geom),dGeomGetPositionZ(geom)) dGeomGetAxisAngle(geom) glRotatef(dVectorW(),dVectorX(),dVectorY(),dVectorZ()) SetDrawColour(rgb[0],rgb[1],rgb[2]) ' ### DrawSphere: radius - slices - stacks ' ### DrawCar: xscale - yscale - zscale ' ### DrawCylinder: radiusb - radiust - length - slices - loops ' ### DrawCapsule: radiusb - radiust - length - slices - loops If mesh=dSphereClass Then DrawSphere(scale[0],14,14) If mesh=dBoxClass Then DrawCar(scale[0],scale[1],scale[2]) If mesh=dCylinderClass Then DrawCylinder(scale[0],scale[1],scale[2],8,8) If mesh=dCapsuleClass Then DrawCapsule(scale[0],scale[1],scale[2],8,8) glPopMatrix() ' Update Camera UpdateCamera(0,3,-12,0,0,0,0) ' ### xpos - ypos - zpos - angle - rx - ry - rz Local PivotX:Float=Cos(dGeomGetYaw(geom)+90)+dGeomGetPositionX(geom) Local PivotY:Float=dGeomGetPositionY(geom) Local PivotZ:Float=Sin(dGeomGetYaw(geom)+90)+dGeomGetPositionZ(geom) gluLookAt(PivotX,PivotY,PivotZ,dGeomGetPositionX(geom),dGeomGetPositionY(geom),dGeomGetPositionZ(geom),0,1,0) End Method End Type ' ************************* ' Setup ODB *************** ' ************************* dWorldSetAutoDisableFlag(World,1) dWorldSetGravity(World,0,-0.98,0) dContactSetMode(dContactBounce) dContactSetBounce(0.1) dContactSetMu(48) ' Setup Scene InitOpenGL(GL_SMOOTH) ' ### GL_SMOOTH - GL_FLAT InitLight(-45,70,70) ' ### xpos - ypos - zpos ' Create plane dCreatePlane(Space,0,1,0,0) Local PTime:Int Local Timer:Int Local PhysicsTime:Float Global alan:TCar=TCar.Create() ' MAIN LOOP ---------------------------------------- While Not AppTerminate() And Not KeyDown(KEY_ESCAPE) ClearScene() For Local p:TCar = EachIn entGeomList p.Update() Next SetDrawColour(230,230,240) ' ### red - green - blue DrawPlane() PTime=MilliSecs() dSpaceCollide(Space,World,ContactGroup) dWorldQuickStep(World,0.1) dJointGroupEmpty(ContactGroup) PhysicsTime=MilliSecs()-PTime EnableGLText(255,255,255) GLDrawText "JV-ent Version "+FixFloat(dGetVersion()),0,0 GLDrawText "Physics Time:"+FixFloat(PhysicsTime),0,15 GLDrawText "Demo Time:"+dDemoTime(),340,0 If dDemoTime()=0 Then GLDrawText "*** TIME EXPIRED PLEASE RESTART DEMO ***",240,70 Flip 1 Wend dJointGroupDestroy(ContactGroup) dSpaceDestroy(Space) dWorldDestroy(World) dCloseode() End So as you can see I need a TWheel Type, but my attempts fail, when I run the code I recieve very nasty errors with no explaination, any help here would be greatly appreciated. I have also added the TWheel Create() in the TPlayer Type, but I've ghosted it out. Thank you. |
| ||
| The bit of code I need to see regarding the wheels you've 'ghosted out' :) The Update method won't work like that, firstly the Update Camera section should be called before any drawing operations (Update Car). The UpdateCamera() function can only be called once for each Flip in the main loop. I don't think the errors are likely due to adding the wheels, much more likely due to the way you've implemented the UpdateCam()/UpdateGeoms() functions from the original demo as a method. Make sure you're code is executed in the same order as the demo. |
| ||
| Okay I'll adjust the code and re-post. I ghosted the TWeel call because I'm not sure how to create the TWheel Type. |
| ||
| Okay here I have managed to create the car as a type and the Spheres and Capsules as Types, this is an example that it is working so far. I will make my attempt to create the car's wheels now, this is where things turn nasty. |
| ||
Does this peice of code 'have to' run before the updates? I think this is probably an obvious question :)dBodySetPosition(Wheel[1],-2,CarStartY-0.5,+2) |
| ||
| Yes, that code sets the initial position of the wheel and must run before the updates. I would highly recommend changing the Update() methods. It shouldn't be used for the drawing operations. Your using it as a method for each object which is inefficient and will lead to problems later on. It would be better to add something like the following method for the Car type instead... Method Update() 'Update Car ----------------------------------- Local count:Int Local angle:Float For count=1 To 4 dBodyEnable(Wheel[count]) Next dBodyEnable(Car) For count=1 To 4 dJointSetHinge2Param(Joint[count],dParamVel2,Force) dJointSetHinge2Param(Joint[count],dParamFMax2,Torque) Next For count=1 To 2 angle=Steer-dJointGetHinge2Angle1(Joint[count]) dJointSetHinge2Param(Joint[count],dParamVel,angle) dJointSetHinge2Param(Joint[count],dParamFMax,400) Next End Method...the other objects don't need methods at this stage. I'm impressed with your determination, but I'd try something a little easier to get to grips with OOP programming. Learning the physics engine alone will need quite a steep learning curve. Adding learning OOP into the mixture will lead to frustration, confusion and lots of difficult debugging sessions. Also keep in mind that you're using the built-in JV-ODE 3D Engine, which isn't advanced enough to use for your projects. It was only designed to run the JV-ODE demos. [edit] Nearly forgot to mention, there's a dedicated BlitzMax JV-ODE Physics Thread in the 'BlitzMax Module Tweaks' forum area ;) |
| ||
| But you cant actually make a game without using Object Oriented Programming? So what your saying is that all the issues I'm having is because it was never really designed for games? I've just put the code together for creating the wheels and it simply crashes, as in the engine crashes. Perhaps ODE isn't for me. |
| ||
| Also the code you have provided above to go into the car update is exactly what's crashing my code, did you try it? |
| ||
| Woah! This physics engine seems to be most populair. I have a question. Can i make a game like BestFriends of Retro64 (www.retro64.com) using this physics engine?? Can i also make a FPS with rag-doll features, breaking glass, tear clothing and slopes and stuff? I have seen the new PhysX engine of AGEIA for Blitz3D. Is it better? |
| ||
| The PhysX wrapper it is better by amount of features. I’m sure that this statement will be confirmed by everyone who has tried my wrapper in action. All the projects that use PhysX SDK" are shown in this table http://rubux.swargo.com/?module=articles&c=articles&b=2&a=1 |
| ||
| The best library isn't just about the features. More important is it's future and the support given by the people who worked on it. With an attitude like yours I think I'll stay away from that Phisx for a while... d. |
| ||
| . |
| ||
| PhysX engine of AGEIA already long time is used in games. These are such games as Gothic 3, Cellfactor, Tom Clancy's Splinter Cell: Double Agent, Unreal Tournament 3 and more others. PhysX has proved to be from the best side. Therefore my choice has stopped on AGEIA PhysX. What physical engine is better, solving to you. |
| ||
| would you please stop hijacking this thread?!? physx is free for non-commercial use only. if you can afford 50.000 bucks for a physics engine to make an indie game, then you're fine. everybody else will stay with ode/tokamak. period. |
| ||
| >would you please stop hijacking this thread?!? OK! >physx is free for non-commercial use only It is old information. Read the License http://devsupport.ageia.com or http://www.gamasutra.com/php-bin/news_index.php?story=11801 Here speak about cost: Costs Free: - Commercial & non-commercial use on PC - Must keep registration information currect - Must agree to the EULA at the time of download (pops up, but is copied below) - Available for Windows & Linux (soon) - No PhysX HW support requirement - PS3 platform (through Sony pre-purchase) - All platforms through some of our middleware partnerships, such as UE3, Gamebryo 2.2, and others $50k per platform: -Xbox 360 - Fee may be waived at our discretion for multi-platform developers providing PC HW support - Fee may be waived at our discretion for some Tools & Middleware providers |
| ||
| It clearly says: "Physics middleware creator and 'physics processing unit' hardware company Ageia has announced new licensing terms, allowing its PhysX SDK to be used and its runtime components distributed in all commercial and non-commercial PC projects for free." Anyway, i want to know if JV-ODE is the way to go or not. So far i can only see a racing-car example. Where are the demo's as they have it in PhysX? |
| ||
| I think it has really good potential, but at the moment there is no examples on how to incorporate the code into your own game structures, or, you have to be a pro to figure it out. |
| ||
| Let's discuss PhysX wrapper in a corresponding theme. Ok? At wrapper there is a full documentation and 54 examples with sorce codes. You can them download in section "Files" of my site http://rubux.swargo.com I think it quite will suffice for studying PhysX wrapper. |
| ||
| But you cant actually make a game without using Object Oriented Programming? Hmm, I'm not sure how long you've been programming but OOP isn't vital for making anything. The method code was to give you an idea of what I was describing you should do with the methods, it wasn't intended to be usable. Have you any idea how long it would take to become familiar enough with other folks code before I could integrate ODE into it. The crashing problems you are experiencing are due to the way you've constructed your code and nothing to do with ODE. If you do the exact same thing with any other engine the same problems will occur. ODE can be implemented using OOP but you need to further understand both OOP and ODE before doing so. You clearly don't, I'm giving you sound advice in the posts above, take it. It simply isn't possible to design examples to cater for every feasible game structure, as most are custom designed and therefore unique. @LevelTen Websites: Download the demo version of JV-ODE, there's a link in the top post of this thread. There are several demos including RagDolls etc that you can try out. Most engines including ODE are capable of the features you've mentioned. @Render: If you want to discuss the PhysX wrapper further then please do... but NOT in the JV-ODE thread! Thank you. |
| ||
| Yes you are right, I haven't been programming for very long, I am fairly new, but one thing I do know, the games I have written in B3D simply could not be done in any other way without be inefficient, the OOP method I was creating my games was vital. eg. using a createPlayer function which is re-usable, an updatePlayer function, updateEnemy function which updates every enemy, without this it just wouldn't work, or not very well. Anyway, I am mostly new with Blitzmax, and reading through tutorials I came to believe that oop in BMax was text book for making games?? Your way more advanced than me so I will take your advice, thanks. |
| ||
| OOP is fine, I'm not saying don't use it, only to get more familiar with it first ;) Try recreating your car example, but instead of implementing the physics, only place the visible geometry objects in the code. Once you have a static scene working with all of the visible car components in place, then add the physics to the objects. You'll quickly discover whether the error exists in the 3D drawing section of the example or in the data management (globals, types, arrays etc) or elsewhere. For example, if you're not using data types with global scope to store the handles of the ODE wheel geometry, you will no longer have access to the objects and you'll get crashes/nightmares. |
| ||
| Okay I'll give that a go, I felt as if I'd tried everything, I was pretty much ripping my hair out :( As far as Globals go the only Globals I'm using are environment. What could be helpfull is some descriptions on all the variables so that I know 100% which Type each one needs to go into. Also, I'm not sure which type the SetupCar() and UpdateCar() functions needs to be setup in, because where you are using Global variables in everything you dont worry whether your going to be able to access them, hence why you have Wheel and Car being called in one of the functions, whereas I'm trying to set them up Types using Locals, I think this is what is going wrong. I need to understand the engine more so that I can make changes to it to work with oop. |
| ||
| verfum, you now talking about PhysX or JV-ODE? |
| ||
No I'm talking about ODE, here is the function with both wheel and car variable calls, showing that you can't use it within one Type, i.e. it can't go into the car Type because of Wheel and can't go in Wheel type due to Car, well it's not straight forward anyway.For count = 1 To 4 ode.Joint[count]=dJointCreateHinge2(World,0) dJointAttach(ode.Joint[count],ode.Car,ode.Wheel[count]) dJointSetHinge2Anchor(ode.Joint[count],dBodyGetPositionX(ode.Wheel[count]),dBodyGetPositionY(ode.Wheel[count]),dBodyGetPositionZ(ode.Wheel[count])) dJointSetHinge2Axis1(ode.Joint[count],0,1,0) dJointSetHinge2Axis2(ode.Joint[count],-1,0,0) dJointSetHinge2Param(ode.Joint[count],dParamSuspensionERP,0.8) dJointSetHinge2Param(ode.Joint[count],dParamSuspensionCFM,ode.SuspensionHS) If count>2 dJointSetHinge2Param(ode.Joint[count],dParamLoStop,0) dJointSetHinge2Param(ode.Joint[count],dParamHiStop,0) End If Next |
| ||
| See for yorself! who is who! here are some tests I've made: PhysX vs Newton vs ODE www.blitzbasic.com/Community/posts.php?topic=68966 |
| ||
| @verfum: I thought you might be using local scopes, which would explain the crashing. All you need to remember with ODE is to use global scope with any handles you access (body/geom/joint etc), how you do it is entirely up to you. If you don't Blitz will send the wrong handle addresses to the ODE DLL and... boom. @Agent_J: Nice work, except the speed comparison depends on the level of accuracy used, making it easy to 'influence' the results. For example, I could double or quadruple (or more) the speed of the ODE tests. You can probably do the same for the other engines too, so the speed comparison is meaningless in reality. Also, collision groups are in ODE. In fact most of the 'No' labels are not entirely true as nearly all of them can be implemented. For example materials, cloth, magnets and water are all possible without much effort. |
| ||
| The ONLY way for a newbee to choose a physic engine is.... EXAMPLES EXAMPLES AND EXAMPLES. Documentation and support are "welcomes" too. ;-) ;-) JP |
| ||
| yes |
| ||
| VIP3R, I see examples in archive. There DeltaTime stands it is almost identical in all engines. It is possible to assume, that the test for speed is exact (true). Then it is necessary to see at speed of work materials, cloth, magnets and water on all engines. Agent_J can make a tests? |
| ||
| >@Agent_J: Nice work, except the speed comparison depends on the level of accuracy used, making it easy to 'influence' the results. For example, I could double or quadruple (or more) the speed of the ODE tests. You can probably do the same for the other engines too, so the speed comparison is meaningless in reality. Well I set Delta Time, for it to be equal (lets say that’s almost equal :)). So the results of speed testing are correct. As Delta Time has got almost the same meaning in each case. >Also, collision groups are in ODE. Ok! I’ll fix it :) >In fact most of the 'No' labels are not entirely true as nearly all of them can be implemented. For example materials, cloth, magnets and water are all possible without much effort. Ridicules I tried making rags with ODE and Newton. What I’ve got was very low productivity. With PhysX wrapper the speed becomes 20 times faster on the rags calculation. And it has got a lot of options (Thickness, Stretching Stiffness, Damping, Pressure, Friction, Bending, Tearable). Also the system of materials is much easy to use. If only other physic engines has got the same :) See for yourself, but PhysX wrapper is my choise…and you know what that’s nice choice :) |
| ||
| @Render Sorry I didn't see your request. As for tests...in some time you will see the result |
| ||
| @Agent_J & Render: No, you misunderstand about the timing. I could double or quadruple (or more) the speed of the ODE tests, regardless of the Delta Time. For example, if you used a fixed update of 60fps and called the physics engine once per loop, I can still make the ODE engine run faster. So, in the case of ODE (and possibly both of the other engines) the speed tests are not actually accurate. It all depends on the accuracy level of the physics engines. The collision speed can also be separately optimised (in ODE, I don't know about the others). Btw, I'm not as biased as you may think, I like all three engines (ODE/Newton/PhysX). I happen to work mostly with ODE at the moment. The more choices available, the better for everybody. |
| ||
| @VIP3R: Just bought your great DLL, I saw there's an example to use in 2D alike thing by limiting one dimension, is it possible to make it work with SpriteCandy or similar things? BTW, when the corss platform/static BlitzMax version will be ready? ppIsaac can be used in BlitzMax/2D but it's not cross platform either. |
| ||
| Welcome yoko :) I've not used SpriteCandy before, but yes it should work ok with those type of libraries. Use a similar shape to the sprite for the ODE geometry and lock it into 2D with the 2D Plane joint. You need to update the sprite position and rotation to match the position and rotation of the ODE object it represents, then the sprites will 'follow' the ODE object. There are no plans for a cross-platform BlitzMax version at the moment unfortunately, I'll be sure to post some news though if circumstances change. |
| ||
| hi just a quick question, what are the arguments for in the dcreateplane function? its dcreateplane(space,a,b,c,d) I know what space is for but what about abcd? also, when drawing 2d bodies to the screen I noticed you had to add 400 to x-drawing position and take away 580 from the y drawing position, I just wondered how you managed to calculate this, because I wanted to change the resolution to 640,480, thanks |
| ||
| It's vector math used to define how a plane is rotated in relation to the gravity, abc are the normal vector of the plane and d is the dot product of abc. You're probably even more confused now ;) The 2D coordinates and dimensions need to be calibrated depending on the resolution of the screen and also the distance of the objects on the z axis. The way I did it was to stack several objects, then adjust each value until they no longer overlap. The 400 and 580 values define the offsets of the screen drawing positions. For example, 400 is 800 divided by two (this is the center of the window at 800x600) and 580 sets the ground plane level (length of the window y axis minus 20). For 640x480 you can try using 320 (x) and 460 (y), that's 640/2=320 and 480-20=460. |
| ||
| thanks, I think Ill just keep the plane at 0,1,0 :) |
| ||
| JV-ODE V1.22 Update Released Please check your inbox :) Changed dGeomTransformSetCleanup(geom,mode) - to prevent potential memory leaks, mode 1 is no longer supported To remain backwards compatible the above function can still be used, but it will silently return to 'mode 0' if an attempt to use 'mode 1' is made. Added new demos: Demo-Iceberg Demo-Water Please let me know if you experience any problems with the new update. :) |
| ||
| nice water demos! |
| ||
| Can someone talk some sense into me and explain what I'm doing wrong. I'm building a rope bridge by placing Boxes, each box is 0.9 wide and are spread 1 apart, in the space between them is where a hinge joint is anchored holding them together. I'm using: dContactSetMode(dContactApprox1+dContactBounce) dContactSetBounce(0.1) dContactSetMu(24) dWorldSetERP(World,0.4) Each plank has a mass of 1 and the whole thing is supported by a geom at each end suspending it. My bridge works fine except that is twitches like crazy. If I drop something heavy on it, it goes down but then keeps twitching to the point where it will shake a heavy object off it. |
| ||
| Stopping the twitching should be as simple as tweaking a few settings. The settings I would need to see are the hinge joint parameters you've used, ideally you need to post an example showing the problem. |
| ||
| McSeb, try if NOT setting these two affects things for the better: dContactSetMode(dContactApprox1+dContactBounce) dContactSetBounce(0.1) In general I have bad experiences with anything that has even a little 'bounce' set to it - especially with joints. d. |
| ||
| Ok, I knocked together a little demo using the Cubes demo, I'm using Blitzmax: |
| ||
| Thanks McSeb :) Ok, firstly you should increase the World ERP from 0.4 to 0.8 to help correct the errors each step. When bodies are attached to each other, they should have some 'mass'. If no mass is present, the bodies will be weightless and the slightest movement will cause them to jump around and jitter. Add some mass to the planks and increase it until they stop jittering. You may need a mass value as high as 2000 for each plank before they stabilise. Once the planks are stable you need to add/increase the mass of the boxes, or they will have no impact effect on the bridge. Try a mass value of 1000 to begin with. Let me know if it helps or not ;) |
| ||
| Anyone done much work with RayCasting for collisions ? I want to cast a ray and it only to collide with 1 hashspace, is this indeed possible ? |
| ||
| Replied to your email OBD :) |
| ||
| Is there any function that can return the total force that's being applied to it from external Bodies ? i.e. a stack of boxes, can you grab the force being applied to the box on the bottom of the stack ? |
| ||
| Hmm, compression force, AFAIK there are no functions in the API for this purpose. If the stacked boxes compress slightly, you could try measuring the distance between them or return the collision depth. Either could be useful to determine the amount of compression involved, giving some indication of the force. You may need to combine the mass/density with this info if the objects are of different sizes/weight. |
| ||
| Im having a major problem with objects penetrating others, thus making them stick together. I am using 2D only and have a flat trimesh. If I place a sphere on the trimesh it seems ok although moving the spehere across this sometimes bumps up and down - the trimesh is a perfectly flat surface. Heres my setup code and main loop. Im only using dBodyAddForce() no setting at all (as that completely screws the engine up) dWorldSetAutoDisableFlag(World,1) dWorldSetGravity(World,0,-0.98,0) dWorldSetERP(World,0.4) dContactSetMode(dContactBounce + dContactSlip1) dContactSetBounce(0.1) dContactSetMu(40) ... . mainloop() dSpaceCollide(Space,World,ContactGroup) dWorldQuickStep(World,0.075) dJointGroupEmpty(ContactGroup) dSpaceCollide(Space,World,ContactGroup) dWorldQuickStep(World,0.075) ... . Ive double checked my trimesh, in fact I reduced my trimesh further by welding verts together and eliminating any "gaps" between verts. Im not using large units and my verts are of a similar small scale ( trimesh has verts every 16units, the sphere im rolling is 12units) Sometimes the sphere will just fall onto the trimesh and it will just penetrate - other times its only when I drop another sphere on top of it. Adding the extra dWorldQuickStep() helped a bit but it still penetrates I have also dabbled with dWorldSetContactMaxCorrectingVel(World,1) and dWorldSetContactSurfaceLayer(World,1) but with little success. Is there any other settings I can adjust ? or is there a problem with small scale trimesh ? StuC |
| ||
| The scale of the sphere compared to the vert spacing is much too close. You can get away with much more spacing between the verts which will help with the bumps. You can also try using 'friction pyramid approximation 1' by setting the dContactApprox1 flag with dContactSetMode() to help with any bumps. The problem though is the flat TriMesh. When the sphere rolls over the verts, ODE detects these as rigid edged areas causing the bump effect. TriMeshes aren't expected to be totally flat in ODE. There are two things which would be better suited, either make the vert spacing much larger (even creating a TriMesh from a simple quad would be better), or create the flat area using a flat box instead of a TriMesh. Another way depending on how your simulation is set up, would be to use the ground plane as the flat area. |
| ||
| VIP3R, are you thinking of lowering the price of your wrapper any time soon? |
| ||
| Email me and we can discuss it further ;) |
| ||
| >The scale of the sphere compared to the vert spacing is much too close Surely its all just maths ? I can see why large polys might cause a problem - but small ones ? I already have the trimesh is made up of a series of quads that are using shared verts (so no gaps) Just trying a box, and the same happens there too. it all seems intermittant tho. |
| ||
| It's nothing to do with gaps, it's due to the triangle boundaries. When the sphere rolls over these shared verts it may be in contact with two triangles simultaneously, causing two contact joints being generated instead of one. When two contacts are made it tries to move in two different directions causing the bump. If your TriMesh is made up of many smaller triangles/quads, then there are many more boundaries making the problem even worse. Making the vert spacing much larger than the sphere means it is less likely to roll over a boundary, hence less chance of the bump effects. Using a single quad or box means there is only one triangle boundary crossing diagonally across the quad. If the sphere crosses over this boundary it will still have the same effect, which is why it may seem intermittent. To solve the problem, remove as many triangle boundaries as possible (make them larger). If you can make the quad large enough so that the sphere never contacts a boundary (so it stays within one triangle), then that will fix the problem completely. |
| ||
| The trimesh is a contour of the floor which is made of slopes and edges, I cant get rid of many more triangles :S There are 2 triangles every 16 units, which doesn't seem alot to me. heres a wireframe version of what Im using  All verts are shared with no duplicates, and did I mention this is all in 2D ?. Ok I understand about the bumping (which is only slight so I can live with it) but what can I try to fix the penetration issues ? The penetration seems to happen when the main sphere is pushed by another. As you can see (in prev post) Ive lowered the worldstep thinking that might have cured it (which it didnt), also im messing around with the MU setting which seems to correct it some but its still happening. vip3r -> thanks for the replies BTW Chroma -> just buy the thing, Vip3r has put alot of effort into the wrapper, help support it ;) |
| ||
| Hmm very odd, have you tried raising the ERP regarding the penetration issue? If that doesn't help then ideally I'll need to see an example showing the problem, as I've never experienced the issue you're describing with those settings posted above. If you can send me an example (with a mesh) via email, I'll look into it for you. |
| ||
| This gets stranger. Once the sphere has penetrated I have put a debug that does a setposition to a height above where it is. The sphere is reporting it has a linearforce but is stationary + adding force to it is ignored ? I have issued a dWorldSetAutoDisableFlag(World,0) in case its turning itself off but its still stationary ? |
| ||
| You say it's in 2D, are you sure the sphere isn't snagging on some geometry? This would explain the forces being ignored too. The fact that you mention changing the friction helps, also leads me to believe this might be the case. Again, it's very difficult to pinpoint the problem without actually seeing it. |
| ||
| I thought it was snagging, but doing a setpositon to a place I know there is no geometry makes me think its not. More experimenting had lead me to a possible solution. Currently im slowing down the sphere by adding a force in the opposite direction (on in the x direction). This value gets very small < 0.00001. If I cap the force to 0.01 the sticking has disappeared............. well it seems to have gone (fingers crossed) The only down force I have is gravitiy (0.98). I'll post you a demo if it continues to plauge me. |
| ||
| Ok, let me know ;) |
| ||
| Well, I'm the proud owner of the JV-ODE physics lib. I got tired of messing around aimlessly in Tokamak. The demos in this one are great and are what ultimately made me decide to purchase. Congratz VIP3R, this is like the first or second app I've ever bought that was made by someone here on the blitz forum. |
| ||
| Thanks Chroma, welcome aboard :) |
| ||
| I just gotta say - WOW! I am very impressed with the wrapper. It took me some time to get a handle on a few things but its actually pretty easy to understand whats going on. I use the ODE users guide for most of the commands and your demos to see how you implemented a few things. Thanks for making things so much easier! Dont spose there are any tutorials out there for frog brains like me? |
| ||
| Thanks, you're welcome :) There's an old tutorial located here As mentioned it's old, so you need to update a couple of lines, for example ' Include "ode.bb" ' should be ' Include "JV-ODE.bb" ' etc. |
| ||
| Awesome tutorial. You got anything else like that laying around? ;) |
| ||
| Unfortunately that's the only one I know of, but the older JV-ODE threads are full of useful tips, so be sure to have a quick read through them. Don't forget to also browse through the JV-ODE Function Reference doc included with the wrapper for more details about the functions unique to JV-ODE. If you get stuck, feel free to gimme a yell ;) |
| ||
| hi i would like to use a trimesh for my car chassis. when I try it throws an error in the 'worldcollide' function. When I put all objects in the space called 'space' nothing can collide but the trimesh function doesnt cause an error any more. |
| ||
| Ideally I'd need to see an example showing the problem, errors in dSpaceCollide() can be caused by lots of things, mostly mistakes in simulation setup. If you're unable to post an example, feel free to send me a copy (including the mesh) and I'll take a look at it. |
| ||
| is there a way to delete the mass on an object without deleting the body ? |
| ||
| Yes, create a new mass with a value of 1.0 (default mass), then add it to the body. So if you had previously created some mass on a sphere body like this... mass=dMassCreate() dMassSetSphereTotal(mass,400.0,0.7) dBodySetMass(ode\body,mass) dMassDestroy(mass) You can effectively remove it by doing the following on the same body... mass=dMassCreate() dMassSetSphereTotal(mass,1.0,0.7) dBodySetMass(ode\body,mass) dMassDestroy(mass) The mass of a body can be updated at any time with the above method. |
| ||
| hi I created some geom transforms, a few boxes to represent a more complex object. It all works fine but I cant seem to use dgeom1collisiongeom to see if it has collided with anything.Only the original geom works with this function. |
| ||
| Ok, firstly have a look at the Geom Offset demos. These are much easier to use than Geom Transforms but are essentially the same thing. You basically add more geoms in the same manner as the first one then offset their position, without creating a transform container each time. Regarding the collision issue, you should also be checking dGeom2CollisionGeom(geom,index) depending on the size of either object. The index is the collision number, it ranges from one up to a maximum returned by dGeom2CountCollisions(geom). See the detailed collision demo to see both 'dGeom1...' and 'dGeom2...' being used. It is possible to return the collision info on Geom Transforms too btw, so you can try accessing the 'dGeom2...' data now. In the long run though you'll be much better off with Geom Offsets. |
| ||
| I got it to work by using geom offset and geomcollision2! thanks loads,youve been a great help |
| ||
| Thanks for the mass tip, thought it was working like that but its best to ask :) (2D) Back to a recent problem I have - where a sphere is being pushed into the object its standing on. It seems that having minute force on the X/Y pushes the sphere so it gets stuck. Ive put a work around so that my dampening doesnt fall below +/-0.1 which is working fine. The problem that I have now is that if the sphere is being pushed by an object, I cant control the force so its adding minute forcex/y to the sphere and its getting stuck again. Any ideas ? I shall get a demo done to demonstrate. (doing that might activate my brain cells and I may also see the solution) |
| ||
| Right as predicted ive spotted the quirk. The sphere was at rest and I had dBodySetAutoDisableFlag(1) set. When I was then trying to move the sphere by adding a force - I was expecting the engine to "un disable" it. Obviously this isnt the case.... trust me to presume :S For others if you are using AutoDisable you must reenable the body using "dBodyEnable()". We live and learn dont we :) - least im happy again |
| ||
| Hehe, nice one :) I'd imagine there's quite a few ODE users presumed that before now, it makes more sense to re-enable when a force is applied. An ODE body that is auto-disabled does re-enable itself during a collision with another object, but not otherwise. @Chunkations: No problem :) |
| ||
| Man I am having problems with this. I have a car, but if I adjust the body or geom position and try to match up the hinge positions to it, it gets really whacked out, I've tried adjusting multiple parameters but I just cant seem to get it. Maybe if I understand the actual Hinge statements. It may help me out a bit. The following code was taken straight from the demo car code... dJointSetHinge2Anchor(Joint(count),dBodyGetPositionX(Wheel(count)),dBodyGetPositionY(Wheel(count)),dBodyGetPositionZ(Wheel(count))) dJointSetHinge2Axis1(Joint(count),0,1,0) dJointSetHinge2Axis2(Joint(count),-1,0,0) The first part I understands attaches a hinge joint to the wheel. Its the set hinge axis that I cant really grasp. Im not seeing the picture of a hinge joint with the coordinates above attached to a wheel at all, its not making any sense to me. Anyone care to help out on this one? Thanks. |
| ||
| The dJointSetHinge2Anchor() function sets the anchor position of the hinge joint. The dJointSetHinge2Axis1/2() functions set which axis the hinge is allowed to rotate on. Only the first function would normally need changing if you're changing the position of the car, but it's already set the same as the wheel position using the dBodyGetPositionX/Y/Z() functions. What you actually need to change are the following (using the Car Demo for example)... ; ### Create car body ... dBodySetPosition(ode\body,0,CarStartY,0) ; ### Create wheels ... dBodySetPosition(Wheel(1),-2,CarStartY-0.5,+2) dBodySetPosition(Wheel(2),+2,CarStartY-0.5,+2) dBodySetPosition(Wheel(3),-2,CarStartY-0.5,-2) dBodySetPosition(Wheel(4),+2,CarStartY-0.5,-2)...only change the positioning of the car and wheel bodies, the joint anchors will automatically be set to the same position as the wheels. |
| ||
| I made a car that had to be bigger to match other models in my game, but it acts like a lumbering beast compared to the standard car that is in the demoes. I had to increased the force to 4400 to get it to move forward at an acceptable speed and 10,000 force to get it to break. I also had to increase the wheel friction greatly to get it to stop sliding about so much. I also had to increase the torque to about 78 to get it to move. The car that comes with the demoes has a lot of friction with the ground, is fast to accelerate and decelerate. Any tips on getting the same performance out of a bigger car? |
| ||
| You might need to lower the mass values of your car and its wheels, it sounds like they're way too heavy. Make sure the car and wheels have a similar ratio compared to the demo, for example a huge 20 ton car with tiny skateboard wheels will handle like one. The best way is to shrink the scale of everything else and make the visible mesh of the car roughly the same size as the one in the demo. |
| ||
| Thanks for the help there VIP3R, I have alot to learn still on the Axis thing, but I got my car rotated and moving properly. Thanks for the help and thanks again for the outstanding library! |
| ||
| VIP3R that tutorial you have linked is pretty outdated huh? Im thinking that alot of the functions used in it have been replaced by new ones or outright deleted? Do you have any documentation specifically setup for JV-ODE that lists each function, what it does and an example of it? I'm finding that trying to alter any of the demo code to fit my needs just aint cutting it for me, prob cause I dont fully understand the functions, hehehehe. Basically Im trying to place collidable meshes on a landscape .b3d model. With JV-ODE you can create rigid bodys or movable bodys? ; ### ODE STATIC OBJECT (Red) ode.ODEGeom=New ODEGeom ode\geom=dCreateBox(Space,18,0.2,40) dGeomSetRotation(ode\geom,-14,0,0) dGeomSetPosition(ode\geom,-20,4.9,40) ode\mesh=CreateCube() ScaleMesh ode\mesh,9,0.1,20 RotateMesh ode\mesh,0,0,0 PositionMesh ode\mesh,0,0,0 EntityColor ode\mesh,255,0,0 EntityAlpha ode\mesh,1 dCreateBox(Space,18,0.2,40), will create a collision box with the dimensions listed? dGeomSetRotation(ode\geom,-14,0,0), will rotate the collision box based on the x,y,z parameters. dGeomSetPosition(ode\geom,-20,4.9,40), will place the collision box at the specified coordinates. ode\mesh=CreateCube() ScaleMesh ode\mesh,9,0.1,20 RotateMesh ode\mesh,0,0,0 PositionMesh ode\mesh,0,0,0 EntityColor ode\mesh,255,0,0 EntityAlpha ode\mesh,1 The above code will create a visible object, the geometry object created before hand will inherit the properties of the visible object? I thought you had to create a body object, then a geometry object, then a mesh object? You tell people to go through the previous posts to find the information that applies to what people are trying to find out, but there are literally hundreds of posts and previous threads that would have to be looked over, and much of that information is outdated also right? Or to ask questions here, which you do a fine job of answering, in a short amount of time. But a full document for the library would be a god send for little guys like me. Thanks again. (EDIT) - I apologize, I have looked at the JV-ode function ref before, but seemed to have missed the actual descriptions. Most people here have learned to ignore about 90% of what I say, you will too. |
| ||
| thanks, Im trying to code a 'reset car' function but the car goes crazy. I tried setting all forces on the car to zero and placing it a few feet above the ground. Had any luck with this kind of thing? |
| ||
| VIP3R that tutorial you have linked is pretty outdated huh? Im thinking that alot of the functions used in it have been replaced by new ones or outright deleted? Nope, all functions in the tutorial still work. You can copy and paste the tutorial programs and they will still run in V1.22 (latest version) of JV-ODE. I don't remove any functions if I can help it, in order to remain backwards compatible with earlier versions of JV-ODE. With JV-ODE you can create rigid bodys or movable bodys? ODE rigid bodies are movable bodies. You actually have either a 'rigid body + geom' or a 'static geom'. Which is why you're confusing the following... I thought you had to create a body object, then a geometry object, then a mesh object? That is correct for all movable rigid bodies. A static geom however does not need a body, explaining why it's not there in the ramp code. ...there are literally hundreds of posts and previous threads that would have to be looked over, and much of that information is outdated also right? No, the vast majority is up to date. If you're looking for something specific, search for relevant keywords in the text of each thread. There's only nine threads, how hard can it be? :) |
| ||
| @Chunkations: Before moving it, make sure you reset the angular and linear velocities on the car (and wheels) with the following functions... dBodySetLinearVel(body,x#,y#,z#) dBodySetAngularVel(body,x#,y#,z#) |
| ||
| thanks heres what I have so far: dBodySetLinearVel(car,0,0,0) dBodySetAngularVel(car,0,0,0) For w=1 To 4 dBodySetLinearVel(wheel(w),0,0,0) dBodySetAngularVel(wheel(w),0,0,0) Next dBodySetPosition(car,dBodyGetPositionx(car),5,dBodyGetPositionZ(car)) dBodySetRotation(car,0,0,0) it still acts crazy though, any more ideas? |
| ||
| VIP3R, you are absolutely correct, I was a bit inflated with some beer last night. I have extensively looked over the tut you sent and it works great. I have also created a pdf with every JV-ODE thread to ease my searching pains and find information alot quicker without having to open all the threads in my browser. Thanks to these docs and your help (and less beer), I'm getting a better grasp on the fundamentals of the library. Thanks! |
| ||
| You're welcome Xyle @Chunkations: The code you posted should work ok. I suspect you might be using KeyHit() or JoyHit() to detect the 'Reset' button. Change it to use KeyDown() or JoyDown() instead, as the simulation needs to complete more than one time step during the reset routine. The car demo gets away with it because the reset process doesn't change the cars heading, it only flips it over. Here's some code you can try in the car demo... If KeyDown(57)=1 Force=0 dBodySetAngularVel(Car,0,0,0) dBodySetLinearVel(Car,0,0,0) For count=1 To 4 dBodySetAngularVel(Wheel(count),0,0,0) dBodySetLinearVel(Wheel(count),0,0,0) Next dBodySetPosition(Car,dBodyGetPositionX(Car),10,dBodyGetPositionZ(Car)) dBodySetRotation(Car,0,0,0) End If |
| ||
| it worked great! how did you become such an expert? thanks |
| ||
| Is there a way to lessen the bounce after jumping the car? Ok, answered myself on that one, Increasing the gravity value worked pretty good. Made those hard landings flip the car over less. Im trying to also setup a flag to tell if car is colliding with anything. Im looking to setup a flag to tell if hes flying through the air or if hes on the ground, ramp, etc. I tried... Text 10,110,"Collision: "+dGeom1CountCollisions(WGeom(1)) This tests if a wheel is in contact with anything, Which prints 1 when car is on the ground, but says 0 when hes driving up a ramp. Thanks for any insight |
| ||
| No problem Chunkations @Xyle: You can try changing the suspension stiffness by modifying the 'SuspensionHS' value in the car demos, which can then be applied to your own code. Regarding the collision flag, see the 'CarDemo-CCount' demo, it does exactly that. Remember to use both sets of collision functions (dGeom1... and dGeom2...) as the demo shows. |
| ||
| Ok, so far things are going outstanding thanks to your pointers and help there VIP3R. Im having trouble rotating the starting position of the car though. I can get the body rotated just fine, but when I move the car, the tires rotate all wrong. Im thinking there is something Im missing in the joint setup to make sure the joints are moving correctly. If I do this... RotCar# = -90 dBodySetRotation(ode\body,0,RotCar,0) and... dBodySetRotation(ode\body,0,RotCar,0) The car looks good, pointing the right way and all that, but when I accelerate the car, the whole car moves to the Positive Z while facing the Positive X and the tires rotate the same way. Edit - I got the car rolling in the correct direction by altering these in SetupCar()... dJointSetHinge2Axis1(Joint(count),0,1,0) dJointSetHinge2Axis2(Joint(count),0,0,1) Now tire #1 and tire #2 still turn when the car is moved. I tried altering these in SetupCar()... If count = 1 Then dJointSetHinge2Param(Joint(count),dParamLoStop,0) If count = 1 Then dJointSetHinge2Param(Joint(count),dParamHiStop,0) If count = 3 Then dJointSetHinge2Param(Joint(count),dParamLoStop,0) If count = 3 Then dJointSetHinge2Param(Joint(count),dParamHiStop,0) and altering these settings in UpdateCar()... angle#=Steer-dJointGetHinge2Angle1(Joint(1)) dJointSetHinge2Param(Joint(1),dParamVel,angle) dJointSetHinge2Param(Joint(1),dParamFMax,400) angle#=Steer-dJointGetHinge2Angle1(Joint(3)) dJointSetHinge2Param(Joint(3),dParamVel,angle) dJointSetHinge2Param(Joint(3),dParamFMax,400) but the wheels dont steer properly. Ill keep pluggin away, thanks again for the help. |
| ||
| Hang on, there's something not right about your rotation code if you need to adjust all of those joint setttings. They shouldn't need adjusting once initially set up. If you try the reset code I posted earlier for Chunkations in the car demo, it shows the car can be rotated without affecting the wheel joints. See code 5 posts above ^ |
| ||
| Hmmm, thats strange, I tried Chunks recommended code before and changed some settings but it didnt work as I intended so I tried other things. Trying it again gives me the results I wanted. Thanks for the pointer VIP3R. |
| ||
| hi, do you know how I can apply a force in the same direction that an entity is facing? i dont mean relative forces, for example, if I have 2 cars i want to apply force to car#2 in the direction that car#1 is facing, like a force-push from star wars also I want to make it so pressing down just stops the wheels turning instead of making the wheels spin backwards I tried: For count=1 To 4 dJointSetHinge2Param(Joint(count),dParamVel2,1) Next but nothing happened |
| ||
| You can apply a force to a body in any direction using the following functions... dBodyAddForceAtPos(body,fx#,fy#,fz#,px#,py#,pz#) dBodyAddForceAtRelPos(body,fx#,fy#,fz#,px#,py#,pz#) dBodyAddRelForceAtPos(body,fx#,fy#,fz#,px#,py#,pz#) dBodyAddRelForceAtRelPos(body,fx#,fy#,fz#,px#,py#,pz#) You haven't posted any torque code so I'll assume there isn't any. You need to significantly increase the torque to stop the wheels, the following code will lock the wheels up solid (depending on mass)... For count=1 To 4 dJointSetHinge2Param(Joint(count),dParamVel2,0) dJointSetHinge2Param(Joint(count),dParamFMax2,1000) Next |
| ||
| thanks, i had a look at the force commands but I cant work out how to turn the vector that car#1 is facing into the right parameters for the dbodyaddforce command,-for car#2 the torque command didnt work, if this works some cool skids could be made(!) EDIT- I got the brakes to work by disabling the updatecar() function if stop isnt pressed |
| ||
| It's probably not a good idea to disable the UpdateCar() function, it's better to use it to control the force and torque from one single location in your code. For example, adding the following code to the UpdateKeys() function in the car demo will lock all four wheels when the 'down' arrow key is pressed, without disabling the UpdateCar() function... If KeyDown(208)=1 Force=0 Torque=1000 Else Torque=24 End If |
| ||
| THREAD 9 IS ABOUT TO CLOSE Please continue on the new thread located here Thanks :) |
   |