JV-ODE Physics Thread 11
Blitz3D Forums/Blitz3D Userlibs/JV-ODE Physics Thread 11
| ||
| 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 40 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 (207KB) The BlitzMax (Win32) restricted demo version is now available for download here (376KB) The JV-ODE Leadwerks Engine Demo Pack is now available for download here (60KB) Have Fun :) Previous JV-ODE Blitz3D Threads: 1 2 3 4 5 6 7 8 9 10 Useful Links: ODE.org Website - ODE Wiki - ODE User Guide (PDF) - ODE User Guide (HTML) |
| ||
| Thanks for the new update, my 3d Rigs over a network around fort block isn't abandoned... just waiting for my work to back off a bit so I can spend more time hobby coding. Regards, BP. |
| ||
| You're welcome BP :) |
| ||
| Just fired up my rigs, computer 1's rig does move on computer 2 via network control, however am now using your 2 car demo to optimize my 2 player (or more...) TCP server client blah within the twin car demo. Cheers. |
| ||
| thanks for the updates best thing to hit my inbox in years. |
| ||
| Here's a little thing I tacked onto the ragdoll demo as an experiment. The shadows don't look quite right somehow though, perhaps they should fade with distance or something. |
| ||
| You're welcome Pete, thanks :) @KronosUK: Excellent stuff! It's great to see shadows working with the bare bones engine, it's fast too. I might experiment a bit more with that when I update the JVODEOpenGL module. Your ragdolls look like they could do with a bit more food ;) |
| ||
moving forwards with clients chatting to a server for control info to be sync'd between clients.... slowly:- The reason the version is only 1.24 is that I didn't have enough time to get v1.27 onto my usb stick for dev whilst on hols... During development I'd 200 cars all moving in time, didn't half cause some carnage when I started varying the force dependant upon client number (;-) cheers BP. |
| ||
| 200 networked cars, that's impressive! Keep it up :) |
| ||
| Regarding the code below can someone clarify whether the tribank and vertbank continue to be used by ode after the trimesh is created?. In other words you couldn't use this function to create two trimeshs from two or more different b3d's as they would share the same tribank/vertbank. |
| ||
| Once the TriMesh has been created using the banks, they're no longer accessed by ODE. I think at one time ODE needed them to be kept reserved (hence the global scope) but that isn't the case anymore. It still works ok if the banks are local scope only. |
| ||
| I get an unhandled memory exception on the line dSpaceCollide(Space,World,ContactGroup) in the main loop if I make tribank/vertbank Local so i guess Ode still needs them reserved. |
| ||
| Hmm, it works ok here with local scope. The error you mentioned is what used to happen when global scope was required. Are you using V1.27 of JV-ODE (including the modules)? Also, which version of BlitzMax are you using? |
| ||
| Ive copied over the v1.27 dll but still no joy. i think I need to recheck my code as there is something funny happening with my "spaces". |
| ||
| do you mean code spaces, like GGrrr.. underbar spaces in variable names (suffered about an hour from a trailing underbar in a var name within a function associated with the cars steerage - my fault!). If you mean 3d spaces then I can't empathise. Safe to say, I'm now an initial capital fan as opposed to an underbar separation fan. As far as my TCP ing is going, I'm not 100 percent that everyone will be able to be represented on other peoples computers effectively without some dead reckoning wizardry. Never say die.... |
| ||
| Does it have cloth simulation support too? |
| ||
| Yes, but not natively. You need to create your own cloth object using a matrix of spheres attached to each other with ball joints. Any physics engine with ball joints should be capable of this. There's a simple demo in JV-ODE Thread 10, search for 'Cloth Demo'. |
| ||
| Does JV-ODE support soft-body simulation? I saw it in Physx and bullet. |
| ||
| No, ODE simulates rigid body physics. However, certain types of soft body physics are still possible with ODE, for example the cloth physics as mentioned above. |
| ||
| Hi Jim! Can I change the "WorldFriction" in "real time" ? I want to make this to make variations during the game... I have changing the WorldFriction# value and using this command dContactSetMu(WorldFriction), but, Not happen... Can you Help me with this? |
| ||
| Hi EmerGki, Not world friction, however you can use the geom functions to do this in real time instead... dGeomContactSetMu(geom,mu) Here's a car demo with variable wheel geom friction... |
| ||
| Thank You Jim! =D |
| ||
| Good Day, I'm trying to buy JV-ODE but on the website the Buy Now button doesn't show up. |
| ||
| Hi, It seems to be working ok here at the moment, are you using http://jv-ode.devcode.co.uk/ ? Let me know if you're still having problems and I'll look into it further for you. |
| ||
| Yeah that's the site I'm using. I still can't purchase, even on my laptop. There is no Buy Now button. I hope I'm not the only one with this problem. If I am I can't explain it. |
| ||
| Strange, it still works here, maybe your browser cache needs clearing? Here's some direct links to the Share*it product pages... JV-ODE Blitz3D Version JV-ODE BlitzMax Version |
| ||
| Thanks for the links dude. I cleaned the cache, same thing happens. Anyway, I will be buying your software. |
| ||
| I bought JV-ODE for Blitz3D a while ago and now have a new email address. The old email address is defunct and I do not have access to it. How do I download the latest version? I do have the original email with the 1.17 version download as well as my username and password. Mike Felker mike at world-class-multimedia.com www.world-class-multimedia.com |
| ||
| Hi, I've updated your email address with the one in your profile and sent you an email regarding the latest version download. |
| ||
| Got it - thanks. Mike |
| ||
| Someone has created a good "brake system" (for vehicles) with ODE? Can someone help me with this? |
| ||
| Use zero force and lots of torque on the wheel joints. Adding the following code to the UpdateKeys() function in the car demos will lock all four wheels when the 'down' arrow key is pressed... If KeyDown(208)=1 Force=0 Torque=1000 Else Torque=24 End If |
| ||
| Jim, I'm making a "progressive brake", where you can control the "force" of the brake with the pedal... My brake work in a plane highway, but, in a Downhill highway, the brake make my car lose the control, something like the wheel turning for one side... I have tried making the "Force" go down and Torque go up, progressively, like this: Force=Force-0.01*BrakePedal# HingeTorque=HingeTorque+(0.1*BrakePedal#) I believe that I'll need to use another variable to control the brake... |
| ||
| ..I just bought this cute wrapper...so far its all smooth, but I would like to know how to properly use >>dBodyGetLinearVel(body)<<, because when i try to use it, I got 'Illegal type conversion' error...what i did is I just wanted to get Linear velocity by doing this LVelocity=dBodyGetLinearVel(Car) (I tried with one of provided examples).. |
| ||
| @EmerGki: Ah progressive braking, I see. Using force damping like that is like engine braking which might not be what you want. Have you tried using zero force and only progressive torque instead? It's difficult to suggest the cause of the loss of control without seeing it in action, but it could be linked to the levels of mass and friction you're using for the car/wheels/highway. @NA: The dBodyGetLinearVel(body) function returns a vector in ODE, which can't be returned to Blitz directly. You can either use the unique JV-ODE functions to return a specific vector component using dBodyGetLinearVelX(body), dBodyGetLinearVelY(body) or dBodyGetLinearVelZ(body). Or you can get the complete vector by calling dBodyGetLinearVel(body) and then use the vector functions like this... dBodyGetLinearVel(body) LVelX#=dVectorX() LVelY#=dVectorY() LVelZ#=dVectorZ() |
| ||
| ..in order to make my level geometry physics interactive, I have to use trimesh stuff from examples?? or there is another way?? How to make custom shape geometry physics interactive(non static)? |
| ||
| TriMeshes should only be used for static objects in reality, they're too slow compared to primitives. If you want to create non static custom geometry, you need to build composite objects using multiple primitive geoms like cubes, spheres and capsules with geom offsets. Look at the Geom Offset demos to see how it works. Once you've built your custom physics geometry, update your custom mesh (the visible geometry) with the position/rotation of the body or one of the geoms. |
| ||
| JV-ODE V1.28 Update Released Please check your inbox :) All JV-ODE demos have been updated, tweaked and improved. Added new demos: CarDemo-AABB CarDemo-Duo CarDemo-Velocity Demo-RayPick (Blitz3D Version) Demo-Slider Demo-TriMeshes (BlitzMax Version) The following demos now use Geom Offsets instead of Geom Transforms... CarDemo-TruckTrailer CarDemo-SphereWrapCylinder Demo-RagDolls-Zombie (Blitz3D Version) The old Geom Transform demos are obsolete and have been removed, however Geom Transforms are still supported in JV-ODE. The JV-ODE OpenGL 3D Engine module in the BlitzMax version has been completely redesigned to mimic the command set and appearance of Blitz3D. All JV-ODE BlitzMax demos have been modified to use the new 3D engine. It is now much easier to convert the demos to run in MiniB3D, for example to convert the Demo-Spheres code, change the Framework to SiDesign.MiniB3D and comment out the Blitz Plane code - that's it. An updated Leadwerks Engine Demo Pack is also available from the Leadwerks Forums. Please let me know if you experience any problems with the new update. :) |
| ||
| ..nice.. thanks man.. :) you really keeping things updated... |
| ||
After the Version 1.25, I'm getting this error:  How to solve this problem, or, what's wrong?? So, I'm still using the 1.24... |
| ||
| @NA: You're welcome :) @EmerGki: I take it you're using dMassTranslate()? In the recent versions of ODE, the centre of mass must be at 0,0,0 in relation to the position of the body (the origin) or it will throw an error. It has always worked this way but earlier versions didn't throw an error if it was used incorrectly. It's quite complicated and it works the opposite way to how you might think. I've asked the ODE authors about this before and they admitted the function name is misleading. If you create a body and attach two geoms to it, with the second geom off-centre, you have to reposition all of the geometry until the centre of the whole object is at 0,0,0. Then, you translate the mass back to the centre of the whole object which is now 0,0,0. So you don't move the centre of gravity, you move the geometry until it's overall centre is at 0,0,0, then you reset the centre of gravity to 0,0,0 with dMassTranslate(). It's used in one of the ODE examples which you can find here. |
| ||
| ..im a bit stuck with trimeshes...maybe because i use to use all time Physx wrapper so its a different..I just dont know...in Physx if you dont describe object mass, its considered infinite mass, therefore, static..here I had look over demo-trimeshes and it seems that they are dynamic and not static/while mass is not described/..Im wondering what exactly and how to enable parts of my geometry to be static(non uniform geometry, my level practically), with use of trimeshes.. |
| ||
| VIP3R, do you mind to post again cloth demonstration with use of spheres, I lost it..and is it possible to use pivots instead of spheres? |
| ||
| In ODE you have a rigid body which has mass and is affected by gravity and forces etc. Then you have the geom, which is used for collision detection. To create a TriMesh that is non-static, it needs a body like in the Demo-TriMeshes demo. To create a static TriMesh, you only create the geom and omit the body. If you look at the CarDemo-TriMesh-* demo code, you will notice the static terrain TriMeshes don't have a body associated with them. If you don't specify the mass, ODE will use a default mass value of 1.0, not infinity. As there is no body associated with static objects, they have no mass, but behave as if their mass is infinite. The cloth demo is in JV-ODE Physics Thread 10, about two-thirds of the way down. The visible sphere meshes can be replaced with anything you like, pivots, mesh bones etc. |
| ||
| ..okay..I hope im doing something wrong here and its not wrapper issue..I want to set up my level to be static..now..during loading, I pass trough level structure loaded with LoadAnimMesh and store every element in to types so later I have names, and ID for each element on scene. Then I pass trough elements in Type and turn them in to trimesh with Trimesh function provided with samples..and..nothing happen..cubes or other primitives i create for sake of test, simply drop trough my level geometry....I did similar approach with Physx and it was working without any problems...I also noticed that command dSpaceCollide is present in demos while docs said its unsuported...what im missing here?? |
| ||
| ..hmm..I got it work but its extreme slow (4 fps) dropped from 70fps..what i did is, I sliced my level in to 4 chunks and load them separately as use for physics, practically this: Ode1=LoadMesh("Ode1.b3d") trimesh1=CreateTriMesh(Space,Ode1) FreeEntity Ode1 Ode2=LoadMesh("Ode2.b3d") trimesh2=CreateTriMesh(Space,Ode2) FreeEntity Ode2 Ode3=LoadMesh("Ode3.b3d") trimesh3=CreateTriMesh(Space,Ode3) FreeEntity Ode3 Ode4=LoadMesh("Ode4.b3d") trimesh4=CreateTriMesh(Space,Ode4) FreeEntity Ode4 after this, collision working over geometry properly but with funny slow fps..level has 120K polys and same level I use to rig with Physx before worked fine and with no slowdown at all..what I did wrong here?? |
| ||
| To create a TriMesh from a mesh loaded with LoadAnimMesh, you need to use the CreateAnimTriMesh() function instead of CreateTriMesh(). Look at the CarDemo-AnimTriMesh demo, you need to specify which layer to use for the geometry. dSpaceCollide() is not implemented in its original form, the JV-ODE version has different parameters, notice the docs have a link 'Unique JV-ODE Function alternative' next to it. The slowdown is caused by the static TriMeshes colliding with other scenery like the plane or other TriMeshes. You need to use a sub-space for the static scenery and disable internal collisions with dSetInternalSpaceCollideMode(0) to prevent them colliding with each other. Look at the CarDemo-TriMesh-X4 demo and check how the spaces are used, search the code for SceneSpace to see where. First the sub-spaces are added to the top level space, next internal collisions are disabled, then each scenery object is created in the sub-space SceneSpace (not 'Space' which is the top level space). You'll soon have it running like greased lightning ;) |
| ||
| given meshes were collapsed in to one single mesh, thats why I used CreateTriMesh()...however I havent use dSetInternalSpaceCollideMode(0), what may cause problems...because when my car dropped on to scene, its was jumping like a horse until jump becomeso big that carr dissapear on horizon...I just copied same car settings I did without racing track, where things use to work perfect..anyway here is how structure look like..all level entities are stored in here Type Level field ID field Name$ field Trimesh end type so, when I pass trough this structure i wanted to do Trimesh=CreateTrimesh(Space,Entity\ID) , and similar thing working smooth like silk with Physx (but i want to go for ODE because of drivers physix require)..so when i do that on way I show with Ode, program freeze so i had to slice level in few chunks and load separately outside of hierarchy i show just now..then it worked but horribly slow, and car never ever touched track itself(i load already tested and set car, with no scaling or anything, and all previously set in empty scene with plane)..instead car jumping a lot... Now..I set up car on such way that car shell is trimesh, but wheels are primitives(spheres) and wheels shouldcollide as they do just fine on my setup scene...so, im a bit confused because racing track is up to scale with car already set so i havent touch that..ehh |
| ||
| Ok, the car disappearing on the horizon is the simulation exploding, which is caused by a bad setup. It's ok to use a single mesh for the terrain, but you must use the CreateAnimTriMesh() function if you're loading a mesh with LoadAnimMesh. You shouldn't have to slice your meshes for them to work, that's bypassing the actual problem, instead of fixing it. As mentioned earlier, to fix the slowdown, setup your spaces like this... Global Space=dHashSpaceCreate(0) Global SceneSpace=dHashSpaceCreate(Space) dSetInternalSpaceCollideMode(0) ... dCreatePlane(SceneSpace,0,1,0,0) ; <<< If a plane is used Trimesh=CreateTrimesh(SceneSpace,TLevel\TriMesh) ; <<< Use CreateAnimTriMesh here if using LoadAnimMeshNext, don't use a TriMesh for the car shell, build it from primitives (boxes). You can use any mesh for the visible entity, you don't have to use cubes. You should have an ODE body (ode\body), an ODE geom (ode\geom - boxes) and the car shell mesh (ode\mesh - .B3D .3DS etc). Be aware that Physx and ODE work differently to each other. So whatever worked in Physx might need tweaking to behave the same in ODE. If you're still stuck, post some code (or send it via email) so that I can show you where you're going wrong. Or send me the level & car meshes, and I will add them to a simple demo for you so that you can see how to do it correctly. |
| ||
| ...thanks man...I will send you level(its actual model for F1 racing circuit in malaysia), and car with all parts separated(shell, wheels, discs...)...i can use this email jv-ode[no-spam]devcode.co.uk? My scene setup is same as you have been posted...is there any requirement from ODE regarding polygons on geometry or way how is it triangulated, or whatever?? I will send you level+car in next 1 hour.. |
| ||
| ..ok..geometry+ car + some screenshots sent... |
| ||
| Thanks, I've just received it, gimme an hour or two. There are no special requirements for the geometry, every mesh I've tried so far has worked ok. |
| ||
| Ok, I've sent you a working demo with all 958 TriMeshes running at less than 1.0 physics time. That's seriously fast!!! |
| ||
| ..yeah..wonderful..I see why it was slow..or not collision at all..only thing I didnt use properly is Trimesh function(I used one provided with demo scenes)...I luv it..thank you A LOT.. |
| ||
| You're welcome :) |
| ||
| .Vip3r, how to change friction value on the fly? I have tried to change friction value in runtime(depending what car do) with use of dContactSetMu(WorldFriction), while changing WorldFriction value on the fly, but it seems that there is no effect, related to initial set up..how to update world friction on the fly?? |
| ||
| World friction only changes when a new geom is created. You need to use the Geom Contact functions if you want to change the friction in real time... dGeomContactSetMu(geom,mu) There's a demo showing it in use half way up this thread ^ |
| ||
| ...Schön... :) |
| ||
| VIP3R, Once again, thank you very much for your latest update (1.28). Excellent customer support as always. cheers, Mark |
| ||
| VIP3R, have been excercising my VB.net skills in conjunction with a front end for car Demo. Dropped in 1.28 dll to the directory & works a treat. Any thoughts you have with regard to extra buttons to auto configure stuff appreciated. Heres the post: http://www.blitzbasic.com/Community/posts.php?topic=80626 |
| ||
| You're welcome Mark :) @Blitzplotter: How about some buttons to change the mass / suspension / wheel friction of each car. You could use a list box to select the car, then three input boxes for the settings? |
| ||
| Silly question. How do I get this update? It wasn't emailed to me. Thanks. |
| ||
| @VIP3R, could do... need to apply some more thought to the structure of my ini file, as I intend to write out to the ini file from VB.Net with whatever is populated, the B3D exe will read the ini file and run with whatever's passed. |
| ||
| @proud2bme: Your update email was sent to the address you used when purchasing JV-ODE, I've not received any error to indicate it failed. Check your spam filters if you're using one. Let me know the address I have is correct and I'll resend it for you. |
| ||
| All I see in my junk mail folder are emails about Viagra. The original email containing my JV-ODE purchase had no problems reaching my inbox. The address there is the same. |
| ||
| Ok, I've resent the update email for you. |
| ||
| I started looking into physics stuff for my game and started wondering how some shapes (like boxes or barrels) should be initialized? TriMesh? If so... can you provide simple code for creating TriMesh barrel (I'm testing Demo-MultipleObjects, and would be nice to see how it could work with "barrel.3ds") Or... box geoms? But then, is there any easy way to provide physics geom for the barrel mesh? Thanks |
| ||
| TriMeshes should only really be used for static scenery, they're much slower than primitives (boxes, spheres and cylinders). Any meshes can be used to represent any type of ODE object, just change the ode\mesh to whatever you want... ode\mesh=LoadMesh("mesh.3ds") To create a barrel with a custom mesh, you should create a cylinder ODE geom (ode\geom) and use the 'barrel.3ds' for the visible mesh (ode\mesh). |
| ||
| Sorry to say, I still haven't received my 1.28 update VIP3R. I sent you an email and I'm wondering why nothing you sent showed up. I did check my junk mail and, nothing there either. Thanks for any info. |
| ||
| VIP3R, yes, I realize that any mesh can be used to represent... but how can I (relatively) easily make the cylinder ODE geom match the barrel mesh. If I just create cylinder, it doesn't mean that my 2 units wide, 1.73 units high barrel will be okay. And not to mention the other barrel that might have totally different values. Is there any 'easy way' to match those primitives? I wonder if anybody has created an editor for this purpose? (If not, then I suppose I gotta do it :)) |
| ||
| @proud2bme: I haven't received any emails from you within the last 24 hours and I've still not received any errors to indicate your update email failed. Our email accounts are all running ok, I would advise you check whether your email account is working correctly. Let me know if you manage to get it working, or if you want to use a different address instead. @Game Producer: I see, it wasn't clear that was the info you wanted. There are 3 sets of dimensions you need to think about... ODE Geoms, Blitz Meshes and Custom Meshes. The default dimensions of Blitz meshes is 1 unit. The corresponding ODE geom size for a Blitz mesh with default dimensions is as follows... Sphere 1.0 (Same as Blitz units) Cube 0.5 (1/2 of Blitz units) Cylinder 0.5 Length (1/2 of Blitz units) 1.0 Radius (Same as Blitz units) For custom meshes like your barrel, it depends on the dimensions used when it was created. The dimensions of the ODE geom should match the mesh units. For example a barrel mesh with the dimensions of 3.0 units length and 1.0 units radius, would be setup like this... dCreateCylinder(Space,1.0,3.0) If you alter the scale of the mesh in Blitz, you may need to do the same with the ODE geom dimensions. |
| ||
| @VIP3R: Yes, thanks. Then exporting content pack art (which might have different starting positions, and "weird" units that are not possible to know in Blitz side, it would mean manually creating the corresponding ODE geoms). Gotta start making an editor for that (shouldn't be too hard though :)) Thanks for the info! --- Another question came to my mind: is there ready made example on how to get characters (like human) moving with ASWD type of controls? (if the character is made of 'cylinder' for example (and perhaps a cube or something attached in the head :)) What about some sort of "waypoint system", is there examples for these type of controls? --- Thanks again for great support (yeh, I'm a happy JV-ODE customer and have bugged you earlier :)) |
| ||
| You're welcome :) There isn't a character controller demo using capsules/cylinders, but there is something which uses a sphere in the same way... Waypoints are not directly related to physics engines, hence no examples. You'll find much more information about waypoint systems in the Blitz3D Programming forum. |
| ||
| Okay, thanks. I've looked more into this and found some suggestion where 'capsule' should be staying on top of a ray. I'm looking into this example (http://www.enchantedage.com/sites/default/files/raycar/index.html) but any ideas on how to keep the capsule on top of ray would be gladly taken :) |
| ||
| I've don't have any experience with it tbh, never understood why people would use a capsule over a sphere-composite object. An upright capsule would drag across a surface, exactly the opposite of what a physics engine is designed to do with it. Anyway, there's more info here... http://opende.sourceforge.net/mediawiki-1.6.10/index.php/HOWTO_upright_capsule Good luck ;) |
| ||
| sphere is "fat"... you want to have a taller guy and be able to hit the body (not just the low part) (check hit location using ray, or throw stuff towards the guy). I haven't seen many characters that resemble spheres :D with 'ray' you are able to create jumping/crouching too. not sure what you mean by "upright capsule would drag"... since I believe this is how people are doing character movement in games :) thanks for the link p.s. did you check out that ray demo link...? |
| ||
| Okay, getting there... Based on information here (http://www.ode.org/old_list_archives/2006-June/019114.html) I started tweaking the 'ball control' code and added stuff like here: dBodySetRotation(c\body,0, 0, 0) dBodySetAngularVel(c\body,0, 0, 0) dBodySetTorque (c\body,0, 0, 0) ;xforce# = leftforce-rightforce ;zforce# = forwardforce-backforce dBodyAddForce(c\body, xforce#, 0, zforce# ) This works pretty good for moving FORWARD + RIGHT, but for some reason when I try to move down or left, it always moves 'southwest'. I haven't used ray nor spring yet, but will try that stuff at some point. Here's the full code (any help regarding the odd behavior for down/left movement gladly taken): (EDIT: see below for newer code...) |
| ||
| Updated the code a bit... (EDIT: see below for newer code...) Also found this: http://www.ogre3d.org/wiki/index.php/OgreOde_Walking_Character (seemed quite interesting approach) |
| ||
| And now it works! :)' (still need some work, but at least it's decent!) The capsule demo: Sorry for quadruple posting - stopping now;) |
| ||
| I said a sphere-composite, for example a small sphere at the feet and another object to represent the body. Not a sphere to represent the entire character :) Glad to see you have it working now though, it might be a good idea to remove the earlier code posts and leave only the working version. |
| ||
| Ah, sorry. Hasty reading from my part :) Anyway, looks like the capsule thing works pretty neatly (removed older code). Will still look on how to do the ray-thing in the feet (since it should work better with stuff like stairs (compared to ball at the feet) Thanks VIP3R for such quick comments & good support. |
| ||
| You're welcome :) Thanks for updating your posts. I would imagine you extend the rays from the base of the capsule towards the floor, then when the ray penetrates the floor, you raise the capsule until it's no longer penetrating. It should work ok for stairs as long as the rays are long enough. |
| ||
| Aye, thanks again. I'll see if I manage to do that next... |
| ||
| Question about rays: dGeomRaySet(ray,px#,py#,pz#, dx#,dy#,dz#) Ogre docs said: Ogre::Vector3 diff = dest - pos; diff.normalise(); dGeomRaySet(mRay, pos.x, pos.y, pos.z, diff.x, diff.y, diff.z); How do you find out which values there should be for dx, dy, and dz? I'm using the following: px# = EntityX(gun) py# = EntityY(gun) pz# = EntityZ(gun) dx# = EntityX(pivot)-EntityX(gun) dy# = EntityY(pivot)-EntityY(gun) dz# = EntityZ(pivot)-EntityZ(gun) dGeomRaySet(RayGeom, px#, py#, pz#, dx#, dy#, dz# ) EDIT: Managed to get this working. Sweet! :) Here's the "shoot the ground (or that box)" code. |
| ||
| Hmm, another tiny problem: is there a fast way to check the FIRST collidedGeom when you create a ray? (I realize I can loop everything, but it seems bit silly to first loop collided1 and collided2 and then compare distances to find out the first one) This is so that I can shoot something... and the bullet will stop in the wall, and not also hit the guy behind the wall :) |
| ||
| Hmm, have you listed the collision geoms to see how they are indexed. Depending on the types of space used, they may already be indexed in a certain order. I'm sure they're indexed based on their size in hash spaces. You can also try using dSpaceCollide2(geom1,geom2,world,group) to check collisions between two specific geoms (or spaces). |
| ||
| Ok, thanks. I suppose I'll just go through the index. Doesn't require much time anyway so I think it's fine. One more newb question about rays: - should I do call dSpaceCollide(Space,World,ContactGroup) every time I create a ray? - or... can I simply first create X number of rays, and after those are created call the dSpaceCollide (and then after that - delete all rays) |
| ||
| You can create X number of rays and call dSpaceCollide() once to generate the collision information, then delete them. |
| ||
| That's what I thought :) Thanks again! |
| ||
| I've been working on "save/load" functionality, and currently I'm using the following code First I'm disabling all geoms/bodies (looping every single 'ode' object): For n.netobject = Each netobject n\lastUpdateTime = 0 If (n\physics <> Null) If (n\physics\geom) dGeomDisable(n\physics\geom) EndIf If (n\physics\body) dBodyDisable(n\physics\body) EndIf EndIf Next After this, I position/rotate objects all objects:
If (mover\physics\body)
dBodySetAngularVel(mover\physics\body,0, 0, 0)
dBodySetTorque (mover\physics\body,0, 0, 0)
dBodySetPosition(mover\physics\body, x#, y#, z#)
dBodySetRotation(physicsInstance\body, rotation_x#, rotation_y#, rotation_z# )
EndIf
And after positioning, I enable all objects: For n.netobject = Each netobject n\lastUpdateTime = 0 If (n\physics <> Null) If (n\physics\geom) dGeomEnable(n\physics\geom) EndIf If (n\physics\body) dBodyEnable(n\physics\body) EndIf EndIf Next This seems to work fine, and all the objects are snapped to the proper locations when user clicks load. If you move your character, and click 'load' everything goes to proper locations again. There's just one tiny bug: if I've pushed a barrel object (for example), and click 'load' I can see that the barrel goes to the proper location & has the right rotation - but the barrel is still MOVING in this new snapped location. I suppose barrel is having some sort of force applied to it, and continues updating after getting snapped to the position. Any ideas what I'm doing wrong... or how this should be done correctly? |
| ||
| You're missing these two functions in your position/rotation code... dBodySetLinearVel(body,0,0,0) dBodySetForce(body,0,0,0) Let me know if that doesn't help. |
| ||
| Hi VIP3R, have got the front end varying the amount of cars in the world, along with objects and the concentration of capsules and spheres. I am going to invoke/ reinvoke an FPS counter. Can you please help with the following:- How can I superimpose a car's number onto the top and bottom of the cube - I am going to make 100/200 images (dependant on my max car count) with my numbers on then apply the numbered image within my car creation function using my loop count to the 'top' and the 'bottom' of the car. In order to maintain a dead car count do this I want to perform a check on whether the 'top' of the car is touching the 'world' or not, then increment a dead car count - is there a more efficient way to do this, if not could you please show me an example of how to perform is top of cube touching world check - I will be setting a flag in a global array that will ensure once the check is confirmed the car will not be checked a second time..... Regards, BP. |
| ||
| You need to look at texturing the cubes with the car numbers. Only 10 number images are needed (0-9), you can then create the textures with any number. These types of question are not physics related, you would be better off asking them in the Blitz3D Programming forum tbh. Regarding the dead car count, it's easier to detect the 'Roll' angle of the car body to see if it's upside-down or not. Use a counter to make sure it has been upside-down for a few seconds then increase the dead car count. If you want to use collisions instead, look at the CarDemo-DetailedC demo to see how collision information is obtained. |
| ||
| Thanks VIP3R (;-), managed to create two meshes at this post:- http://www.blitzbasic.com/Community/posts.php?topic=81131#914022 Now just gotta correlate it to somehow blending in two pngs.... I'm considering trying to see my car bodies in wireframe to help me apprecaite if there is the necessary meshes created along the lines of the following code: ode\geom=dCreateBox(Space,3,1,4) ; I think this line intelligently makes all the quads to make a cube, whereas the assistance I'm receiving is along the lines of building a 'entity' from the most basic commands:- Somehow I need to maybe extract the information from createbox to pick out the individual sides of the entity.... I'm not sure how yet. |
| ||
| You're missing these two functions in your position/rotation code... dBodySetLinearVel(body,0,0,0) dBodySetForce(body,0,0,0) Let me know if that doesn't help. Excellent, seemed to do the trick! |
| ||
| JV-ODE V1.32 Update Released Please check your inbox :) JV-ODE is now compiled using ODE V0.10.1 which includes several additions, fixes and tweaks. You can view the ODE changelog for specific details here and here. Important Notes: JV-ODE V1.32 immediately follows V1.28, there were no versions released in between them. The version number has increased by 4 because there were 4 major changes made to JV-ODE for this update, two new ODE core updates (V0.10 and V0.10.1) and a wrapper update for each core. The ODE core V0.10 was broken, therefore the core was replaced with the new V0.10.1 bugfix release. The ODE core has been compiled using the new TriMesh>TriMesh collider to give improved results. As previously warned, you must initialize this version of ODE by calling dInitODE() before dWorldCreate(). It is now mandatory and failure to do so will result in an error. The dGeomTriMeshDataBuildSimple() function is not as stable as it was in previous releases, causing faulty collision contacts to be generated. To avoid the problem, the JV-ODE TriMesh creation functions have been modified to use dGeomTriMeshDataBuildSingle() instead, which also has the added benefit of a smaller memory footprint. If you have built your own 'CreateTriMesh()' functions, it is highly recommended you change over to use dGeomTriMeshDataBuildSingle() too, you can use the built-in functions as a guide. The new update includes built-in damping, 'sweep and prune' collision spaces, prismatic-universal & piston joints and multiple thread support (untested). Added new functions: dInitODE2(initflags) dAllocateODEDataForThread%(allocateflags) dCleanupODEAllDataForThread() dWorldGetLinearDamping#(world) dWorldGetAngularDamping#(world) dWorldSetLinearDamping(world,scale#) dWorldSetAngularDamping(world,scale#) dWorldSetDamping(world,linear_scale#,angular_scale#) dWorldGetLinearDampingThreshold#(world) dWorldGetAngularDampingThreshold#(world) dWorldSetLinearDampingThreshold(world,threshold#) dWorldSetAngularDampingThreshold(world,threshold#) dWorldGetMaxAngularSpeed#(world) dWorldSetMaxAngularSpeed(world,max_speed#) dSpaceSetSublevel(space,sublevel) dSpaceGetSublevel%(space) dSpaceGetClass%(space) dSweepAndPruneSpaceCreate%(space,axisorder) dBodyGetLinearDamping#(body) dBodyGetAngularDamping#(body) dBodySetLinearDamping(body,scale#) dBodySetAngularDamping(body,scale#) dBodySetDamping(body,linear_scale#,angular_scale#) dBodyGetLinearDampingThreshold#(body) dBodyGetAngularDampingThreshold#(body) dBodySetLinearDampingThreshold(body,threshold#) dBodySetAngularDampingThreshold(body,threshold#) dBodySetDampingDefaults(body) dBodyGetMaxAngularSpeed#(body) dBodySetMaxAngularSpeed(body,max_speed#) dBodyGetFirstGeom%(body) dBodyGetNextGeom%(geom) dJointSetHingeAxisOffset(joint,x#,y#,z#,angle#) dJointGetNumBodies%(joint) dJointCreatePU%(world,group) dJointSetPUAnchor(joint,x#,y#,z#) dJointSetPUAnchorDelta(joint,x#,y#,z#,dx#,dy#,dz#) dJointSetPUAxis1(joint,x#,y#,z#) dJointSetPUAxis2(joint,x#,y#,z#) dJointSetPUAxis3(joint,x#,y#,z#) dJointSetPUAxisP(joint,x#,y#,z#) dJointSetPUParam(joint,parameter,value#) dJointGetPUPosition#(joint) dJointGetPUPositionRate#(joint) dJointGetPUAnchor(joint) dJointGetPUAxis1(joint) dJointGetPUAxis2(joint) dJointGetPUAxis3(joint) dJointGetPUAxisP(joint) dJointGetPUAngles(joint) dJointGetPUAngle1#(joint) dJointGetPUAngle2#(joint) dJointGetPUAngle1Rate#(joint) dJointGetPUAngle2Rate#(joint) dJointGetPUParam#(joint,parameter) dJointCreatePiston%(world,group) dJointSetPistonAnchor(joint,x#,y#,z#) dJointSetPistonAnchorOffset(joint,x#,y#,z#,dx#,dy#,dz#) dJointSetPistonAxis(joint,x#,y#,z#) dJointSetPistonParam(joint,parameter,value#) dJointGetPistonAnchor(joint) dJointGetPistonAnchor2(joint) dJointGetPistonAxis(joint) dJointGetPistonPosition#(joint) dJointGetPistonPositionRate#(joint) dJointGetPistonAngle#(joint) dJointGetPistonAngleRate#(joint) dJointAddPistonForce(joint,force#) dJointGetPistonParam#(joint,parameter) Please let me know if you experience any problems with the new update. :) |
| ||
| Nice, thanks for the info! |
| ||
| I was just wondering, how can you staticly link the ODE engine to your DLL, and then sell the product? Isn't that in conflict with the GPL license? |
| ||
| no. ode doesnt use gpl... |
| ||
| @Game Producer: No problem ;) JV-ODE uses the ODE BSD license, not the LGPL license. |
| ||
| Am I doing something obviously wrong here, I can't seem to create a box the same size as my mesh as far as the physics world is concerned, is it a problem the 'width' of my mesh is zero upon loading ? |
| ||
| This is probably a little stupid but I read on the news page JV-Ode has a new version. I recently bought it but I cannot find a update link or something. To get it up-to-date again, do I need to buy it again? Thanks! |
| ||
@Blitzplotter: The first three parameters of FitMesh() are positions not dimensions. You don't need to use it anyway though, use ScaleMesh() only instead. If the width equals zero then yes it will cause a problem. You will need to return floats with MeshWidth() etc, not integers. If the width is less than 1.0 then it will return an integer of zero. Return floats instead like this...deep#=MeshDepth(ode\mesh) tall#=MeshHeight(ode\mesh) width#=MeshWidth(ode\mesh) ScaleMesh ode\mesh,width*0.5,tall*0.5,deep*0.5 @Sph!nx: No, each update is free. I send out emails to all users with the new download link to the email address they registered when purchasing JV-ODE. If you haven't received the update email and are still using the registered email address, double check it hasn't been filtered as spam. If your registered email address is no longer used and gives errors when sending emails, it will be removed from the updates list after two failures in succession. If you need to update your registered email address or are still unable to find the update email, send me an email with details of your original purchase and I will update it and send a new download link for you. |
| ||
| Thanks for the clarification VIP3R. I am returning floats now instead of ints, should stop my lego bricks wobbling on the 0 width! That is a great help, once I resolve this I'll be trying out 1.32 cheers! |
| ||
| Thanks VIP3R! I found this e-mail in your profile: ......., I assume it is ......, just checking, cause I intend to send you my initial purchase e-mail so its kinda confidential and I don't want it to end up somewhere else... Edit : Removed email by request. Thanks again VIP3R! |
| ||
| Yep, that's correct. |
| ||
| Ok, I will foreward the e-mail I recieved when purchasing your library. Only proof I have I guess. Edit : Send the e-mail! :) |
| ||
| Ah, you didn't receive an update email because you already have the latest version (V1.32) which was released a few days before your purchase. You will receive an email notifying you when future updates become available. |
| ||
| Oops ... Sorry, I should have checked... Thanks anyway! |
| ||
| You're welcome and thanks for the edit. |
| ||
| VIP3R, I know Ive asked you about this before, but I can't seem to find my notes so apologies if Im covering old ground. Essentially i have been working on a new vehicle based game and have become confused with the ODE / JV-ODE friction settings and i want to get a proper handle on how JV-ODE works, as i think i've misunderstood previously. Ideally i want to create a friction model for a wheel that when loaded sideways i.e. when cornering, loses grip progressively and slowly, rather than a sudden 'got grip now / no grip now' type of curve.  Part 1. Out of the box (See case one on diagram) If i have understood the ode manual correctly (!)...... -When a wheel creates a contact joint with the floor the contact normal is perpendicular to the surface. -The FDir1 and FDir2 vectors are calculated as being perpendicular to the contact normal and to each other. -Since the FDir1 direction has not been specified, the vector can be at any rotation to the contact normal, as long as it is perpendicular to it. In laymans terms (i.e. my simpletons approach!) this means that FDir1 can face in any direction, and will alomost certainly not align itself with the direction the wheel is pointing. This means that the wheels behaviour when it comes to gentle progressive sideways sliding is impossible to set-up (using slip1 / slip2 and mu and mu2, etc). Hopefully i'm right so far ....  Part 2. Setting FDir1 and why i am confused (See case two on diagram) If i have read the ODE manual correctly (a big 'if') you can set the FDir1 direction and so align it to the direction the wheel is facing. The FDir1 vector is still perpendicular to the contact normal with the ground, but now it is rotated to suit our purposes. This means you can set mu and mu2 and slip1 and slip2 to give the required tyre characteristics on different surfaces and at different speeds because ODE knows which way the wheel is facing. In theory this should enable you to create a wheel that progressivly loses grip sideways as its rotational speed increases. This is where i get confused - in the JV-ODE car demo the FDir1 direction is set, at the start, but then remains unaltered in the main program loop. Shouldn't this direction be updated each loop to reflect the wheels orientation or am i missing something ? I have tried to do this myself, by respecifying the FDir1 direction as the car / wheel moves during the game, but this doesn't seem to have any effect. Also, the slip1 and slip2 values are supposed (according to the ODE manual) to be varied depending on the wheels speed, but when i set these values in my program only the first values i pass to ODE are used, any subsequent values i pass seem to be ignored. Many thanks for taking the time to read this :- when you get a moment let me know what you think. kind regards Mark Judd |
| ||
| You've got the concept correct ;) The misunderstanding is probably thanks to the FDir1 demo, it's no longer included with JV-ODE for this reason (after our previous discussions on the subject). In the demo, the friction direction was manually adjusted in order to experiment with the effects of FDir1, but the main purpose of the demo was to show how to setup FDir1 in code. I realised it was too misleading and decided to scrap it a while ago. So, everything you've posted is correct, you do need to adjust the friction direction to align with the wheels for it to work like real tyres. To adjust these values in real time, they must be applied with the Geom contact functions only... dGeomContactSetMode(geom,mode)... dGeomContactSetFDir1(geom,fdir1x#,fdir1y#,fdir1z#) etc Same applies to the slip values. Using the geom functions should resolve those issues, let me know if it still isn't working correctly. The most important part of the ODE docs regarding this problem is this bit... To model this in ODE set the tire-road contact parameters as follows: set friction direction 1 in the direction that the tire is rolling in, and set the FDS slip coefficient in friction direction 2 to k*v, where v is the tire rolling velocity and k is a tire parameter that you can chose based on experimentation. Nice pics btw :) |
| ||
| VIP3R, Ahhh - I see where I've been going wrong. Thanks very much. I'll give this a go and let you know how it turns out. Incidentally the publisher I sold my Tricky Tracks game to decided for some reason to not market it (at least not yet) so Im looking at a newer version which is what this is for. Thanks again. Mark EDIT : Bah! - I thought I had it but its not working - I seem to be really struggling. Any chance of a quick demo VIP3R ? |
| ||
| Hi VIP3R, OK Ive spent some time messing with Fdir and have come to a dead end. The following code is the segment of my program (from inside the main loop just before 'updategeoms') which calculates the direction of each wheel and applies the geom parameters to define Fdir1. (Ive used the common variables from any of the JV-ODE car demos). Problem is it doesnt seem to work. Try setting mu2 to a silly low value (i.e. no sideways grip) and see what happens. Its like the Fdir1 direction is not being set each loop. I think I understand the principle of what i need to do - its just how I achieve it in the code thats stumping me. Hopefully I'm missing something really simple (not for the first time!) Let me know what you think friend - as always - really appreciate your time. cheers, Mark |
| ||
| Hmm, I noticed a few problems. If you examine the x/y/z components during runtime you will see that they don't reflect the angle of the wheels globally, therefore the friction direction will be wrong most of the time. If you drive in circles, what you should see is the x and z components rise and fall depending on the global angle of the wheel. I've created a quick demo using your code snippet with the following changes... * Added World Contact / Mu2 / Slip settings (in addition to the geom contact settings) * Removed the car angle code (not needed) * Changed the wheel angle to use the yaw value (the hinge2 angle is local and it needs to be global) * The friction values are exaggerated for testing, I think Mu and Mu2 are mixed up though, this might be because the yaw is perpendicular to the wheel. I haven't adjusted the slip settings so they might be interfering with the friction (hence the 20000 value). It seems to be working correctly, but needs much more tweaking and testing with those friction / slip values. Anyway, here it is... I've marked the new areas of code with the tag '<<<< Here'. Hope this helps, let me know if you need anymore info ;) |
| ||
| VIP3R, You've done it again ! Thats great, thanks for your help. Works really nicely now - just fine tuning the values to give the feel I'm after. I had really become confused with the global / local angles issue and despite starting from scratch a couple of times seemed to wind up in the same place each time. Once again, many thanks for your excellent support. Mark |
| ||
| Hi, i got a error message ("colliders array not initalized (..\ode\src\collision_kernel.cpp:256")- JV-ODE ERROR 2 - with this source-code. Can somebody confirm this or can help to fix it ? Maybe it is a problem with the JV-ODE 1.32 -Blitzmax-Edition ? Thanks in Advance Jens Blitz3DSDK_V102 Blitzmax 1.30 JV-ODE 1.32 |
| ||
Add the following line after '### Setup ODE'...' ### Setup ODE dInitODE()ODE must be initialized in JV-ODE V1.32 |
| ||
| Thank you very much VIP3R ! Sometimes I am a tiny idiot - if i'd thought about it, i could have managed myself. ;-) |
| ||
| EDIT: Doesnt matter, I've sussed it, while not using JV-ODE! :) Cheers Dabz |
| ||
| Can I use JV-ODE for water/sea physics? Like waves effecting boats and items float on the surface, stuff like that? If so I'll but it now. Thanks. |
| ||
| Sadly not, ODE only simulates rigid body physics. You need a soft body physics engine for 'proper' flowing water. It's possible to do simple water stuff with ODE though, like icebergs etc. |
| ||
| Thanks for the quick reply VIP3R How would I do that in ODE? Can you code a little example for me? I mean the icebergs. |
| ||
| You create a body of water using a cuboid, then give the body certain collision properties. When you drop other solid objects (like an iceberg body) onto the water cube, they will behave as if they are floating on a fluid. You can also adjust the height of the water in real-time, but it will always remain flat (no waves). The water cube can be placed at an angle to simulate flowing water though. It's really easy to do. Wave simulation might be possible with some intensive math, but that's where things get complicated and eventually would go beyond the limits of a rigid body engine like ODE. The full version of JV-ODE has water and iceberg demos, but they won't run in the demo version. |
| ||
| I'm having a bit of trouble repositioning and rotating a rigid body AFTER it has been made. I'd rather 'recycle' Bodies, Geoms & Meshes , instead of destroying them. The general idea is that the distance of all 25 cars is calculated. This list is sorted. If a car is outside the maximum distance, it gets repositioned. Every road in the game has a number of waypoints. Each waypoint has a number, and points towards his next Waypoint. This generates the YAW of that Waypoint. This YAW is used to rotate the rigid body..... Only it doesn't work. :/ I've tried dbodysetrotation , dbodysetaxisangle . I even tried disabling bodies before positioning and rotating, but that didn't work either. This is the code so far: Thanks! :D |
| ||
| You need to zero the force, torque and velocity on the car body and all of the wheels, before you move them... dBodySetForce(body,0,0,0) dBodySetTorque(body,0,0,0) dBodySetAngularVel(body,0,0,0) dBodySetLinearVel(body,0,0,0) Btw, it's forward slash '/' for the codebox end tag ;) |
| ||
| Thanks Vip3R, It works beautifully. :) Btw, it's forward slash '/' for the codebox end tag whoops, sorry about that... I.ve edited it. :D |
| ||
| hi, i have a little problem with a 12 cars race game... sometimes when i start the race and the cmesh touch or collition with an object, the cars bounce to an increible speed, and it goes from 45 to 1600 km/h in that exact moment, and it flies to the space :) it doesn't always happen, when I put more cars on the scenary more possibilities fot this error to happen sometimes too, all the cars constantly bounce maybe i have something wrong with my 3d scenary, but when i use an odeplane, I have the same problem I would like to know the reason why when the cmesh collides the cars bounce at ultra high speed!?? i'm sure this is some problem with my code. thanks and regards. |
| ||
| If I understand correctly, the car meshes are colliding when the simulation is started? That would cause the high speed bounce as you put it. If two or more objects overlap (collide) when you step the simulation, ODE may generate very high collision forces to correct it (the high speed bounce you've experienced). The solution is to make sure they don't collide with anything when they're created or added to the scene. The other issue (constant bounce) sounds like twitchy physics, adjusting things like ERP and CFM can help, you can also try adjusting the collision depth with dWorldSetContactSurfaceLayer(world,depth#). |
| ||
| hi.. i have this screenshot of my racecar track, i only want to know if these triangles distribution works fine with the ode cars.. i can change the polys if there is a best way to do the tracks for the ode system..  thanks VIP3R, your answers are always a big help. another question -> is this the right forum to post this kind of question? or i must post in userlib\? regards!, santiago |
| ||
| Those triangles should be ok. You can post here with questions, it's fine. |
| ||
| i edit this post.. now the only problem i have with my cars, is when the road is go to up or down. when i turn the cars loose grip.. ¿how can i fix that? |
| ||
| It's extremely hard to say without an example showing the problem. Try to describe in detail how the car reacts when there's grip/no grip. If it were a real-life situation, how would the car react compared to your simulation? |
| ||
| Apply a down force based on the velocity of your car. Get fancy, and use some simplified lift equations: L = 0.5 * Cl * A * r * V^2 Where L is lift (in this case, downforce), Cl =lift coefficient, A = area of the body facing the flow, r =air density, and V = velocity of the air flow. CL = 2 * pi * angle angle=-5 degrees A = 3 r=0.074887 I hope you get the idea.. |
| ||
| thanks... Wayne. that is a good idea, i am going to apply that force to see what happens... i'm going to check ode functions, the force i think is not allways like gravity (down direction), because is created in the reality for the spoilers of the cars... vip3r, i'll make some video and post the car data... to show the problem. this is a link with some pictures of the game... (blitz forum link) http://blitzbasic.com/Community/posts.php?topic=83490 |
| ||
| vip3r, i posted a video in youtube showing the car movement, in the half part of the video, when the car reaches the track turns, look how the car makes small jumps. |
| ||
| Hmm, it looks like the bumps in the mesh are causing the car to bounce out of control. I remember the mesh picture you posted previously, from the video it appears that the triangles aren't flat. Try to arrange the triangles to form flat quads in bands around the track, so that the only angles there are at the edges of the quads (not the triangles). Doing this will prevent the wheels bouncing in an alternating fashion, causing the instability. Adjusting the collision depth with dWorldSetContactSurfaceLayer(world,depth#) might also help. Wayne's suggestion sounds ideal if you're loosing too much friction. Outstanding work btw, you can see a huge amount of work has been put into it :) |
| ||
| I looked at the youtube video and saw the wheels really bouncing. How are the track meshes being created? |
| ||
| i have an ode plane for ground. the track is a createmesh, with triangles sharing vertex by color. road, outroad and piano. when i finish the track i use this command to convert the trackmesh to trimesh ode... entityfx trackmesh,2 updatenormals(trackmesh pista_ode=CreateTriMesh(Space,trackmesh) dGeomSetPosition(pista_ode,0,-.5,0) dGeomSetRotation(pista_ode,0,0,0) dGeomContactSetMu(pista_ode,100) plano = dCreatePlane(Space,0,1,0,-.5) dGeomContactSetMu(plano,10) dgeomcontactsetbounce(plano,0)) i change the collision depth but don't see big changes.. im a newbie with ode, maibe in my code have more than one problem about physics... |
| ||
| I'm sure your physics code is mostly fine ;) The mesh needs to be modified to remove those bumps at the edges of the triangles. The built-in CreateTriMesh() function of JV-ODE doesn't use the mesh normals, so updating them will have no effect on the TriMesh. But, you could try changing the CreateTriMesh() function to use the following function... dGeomTriMeshDataBuildSingle1(trimeshdata,vertices*,vtxstride,vtxcount,indices*,idxcount,tristride,normals*) instead of... dGeomTriMeshDataBuildSingle(trimeshdata,vertices*,vtxstride,vtxcount,indices*,idxcount,tristride) Create a bank containing the normals data of the mesh, then use it for the normals parameter. In the same way that the verts and tris data is used. Not sure whether that will help or not, but it's worth a try. |
| ||
| Does the car bounce when you are on the ground plane too ? Have you taken a close look at the track when the wireframe is on ? What are you using for tires on the car ? |
| ||
| wayne, i base my cars in the ode cars samples... the ode wheels are like spheres, the car a cube... i change the ode_properties, mu, mass, dimensions, bounces, etc.. i note the wheels makes a small and fast bounce when the car are stop in the road... i fixed that problem elevating the road.. that problem was because the ode_road and the ode_ground were too close.. and the ode_wheells touch two geometris... now i only need to work in the car bounce because off the track edges differences... to fix that problem i working in the track editor, to make more smoother the triangles edges diferences, and i improve the ode cars propierties. i recieve a lot of information about this problem, in this post and other post in the forum.. in few days i think this is totally solved. |
| ||
| hi, sorry if this is a very simple question, maybe not.. when my car gets out of the road, go to the infinite ode plane i made... the question is, which command i must use to detect when a car touch the grass (ode plane). is to slower procces calculate if a tire is over the grass for ode?, i have 12 cars, x 4 tires each one :p... have you some advice or idea... :) |
| ||
| Something simple to try: Hide all except track and terrain, place camera at tire position, point it down, take a 1x1 picture, get rgb color, if green component is >= 100 this tire in grass, repeat for each tire position. |
| ||
| Unless I'm misunderstanding something, the JV-ODE collision functions should be used to detect if a wheel is touching the ground plane. It would be significantly faster than isolating and detecting RGB values (sorry Wayne :) ). Check the CarDemo-CCount and CarDemo-DetailedC collision detection demos for the necessary functions needed. In those demos, it takes much longer to render the collision information to the screen (using the Text function) than it does to actually detect the collisions. There is no extra overhead when using the collision functions in JV-ODE, because this information is gathered anyway for every object in the simulation, whether you access it or not. |
| ||
| Sorry, was just thinking outside the box. Vip3r always has great technical advice, and were all the better for it. Cheers! |
| ||
| :) thanks vip, i'm going to check the car demos for detect the collision wayne, maybe i can use yout method to create some sprites with the same color of the ground. |
| ||
| Hi Vip3r, just a quick question - Latatoy mentioned the use of 'spheres' as wheels as opposed to cylinders. I've created some wheels from pure cylinders, here: To achieve the best results with regard to adhesion and incremental slipperage would I be better retain pur cylinders (ie the tyre tread is totally flat on the surface) or, would I be better dissecting the walls of the cylinder in 2 (the 'tread' of the tyre/tire) and extruding the 'cirecumference' of the tyre right in the middle so that the wheel is riding on a knife edge as opposed to a large footprint ? Thanks in advance for your feedback, regards, BP. |
| ||
| Real tyres have a square/rectangular 'footprint' so simulating that would be better. The problem is that ODE generates collision contact 'points', rather than a collision zone or footprint. If you examine the collisions of a wheel cylinder on a flat plane, you will notice it always has 2 collision points, these will be on the inner and outer rim central to the wheel. Like a knife edge running across the tyre, but only making contact at each end. If you extrude the cylinder to create a central highspot, the knife edge will now run at the same angle as the wheel, but again only 2 collision points are generated on a flat plane. With spheres there is a single contact point and they're more reliable where collisions with other objects are concerned. None of the above will give an accurate tyre footprint, but it may be plenty good enough depending on your goals. The small number of contact points can cause a sudden (snappy) loss of grip, which some folks wrongly assume is caused by the 'friction model' that ODE uses. You would have to resort to casting multiple rays to simulate the collision zone of a tyre properly, for more information check out the raycar source here... http://opende.sourceforge.net/wiki/index.php/HOWTO_4_wheel_vehicle It's in C/C++ but the ODE stuff has the same syntax as JV-ODE. |
| ||
| Hi Jim! Jim, I'm having some problems here, when I try to reposition a "truck and trailer", I have tried to create the body, setup the wheels and etc, disable the body, reposition the body, etc. But, always my truck gonna crazy, like him have collided with anything... Can you help me to create this code to work with the new position and rotation? |
| ||
| You have to zero all forces and velocities on all objects (truck, trailer and wheels) before you reposition them, otherwise they will continue moving (go crazy as you say). Here are the functions needed... dBodySetForce(body,0,0,0) dBodySetTorque(body,0,0,0) dBodySetAngularVel(body,0,0,0) dBodySetLinearVel(body,0,0,0) |
| ||
| Yes Jim, I have done it too... And, I'm trying to create a new truck in other position/rotation, but, when I create, the truck always starts rolling or rotating :(... |
| ||
| If the truck still moves, there are some forces still active on its components. Check you're not applying any forces in your own code (accelerate/braking etc). Also, make sure you step the simulation at least once after zeroing the forces. |
| ||
| Is there any jv-ode tutorial which include joint lesson, demo, or something ? |
| ||
| Several of the available joints are used in the JV-ODE demos. The ODE manual is the best place to start learning how to use them... http://opende.sourceforge.net/wiki/index.php/Manual_%28Joint_Types_and_Functions%29 |
| ||
| "...The ODE manual is the best place to start learning how to use them..." Hahaha. VIP3R is the best man to ask these questions. ;-) JP |
| ||
| Hello again today i have some trouble with restarting that library.. For example carDemo with simply goto loop: why it doesn't work well ? What's mean Bad arguments (..\..\ode\src\ode.cpp:1723) |
| ||
You're getting errors due to the fact you regenerate a simulation (World) without first deleting the previous simulation...;dJointGroupDestroy(ContactGroup) ;dSpaceDestroy(Space) ;dWorldDestroy(World) ;dCloseODE() ...those should be called before creating a new simulation. You also need to delete any 'ODEGeom' type instances used. Please note it is very bad practice to use a goto loop in that manner. For example, you're repeatedly recalling the following... Graphics3D 320,240,0,2 Graphics3D 800,600,0,2 Include "JV-ODE.bb" dInitODE() ...which are only required once during runtime. You only need to call 'Graphics3D' again if you use 'End Graphics' to close the previous Graphics3D mode. Try to structure the code well or you'll run into all kinds of problems ;) |
| ||
| Hi VIP3R, [edit] fixed that somewhat lengthy problem by taking the kids to a theme park for the day, having some red wine, firing up UU3D and actually resizing my gargantuan wheels. I am still intrigued about struggling to dip the scaleentity below 0.7.... If you know of a reason wht I'd be happy to know - however I have a new issue - my rig/cab does not steer anymore - contrary to what the image with the small wheels shows - the cab at an angle is as a result of a head on collision. Can you please let me know why my steerage is ineffectual, the front wheels are certainly steering - but it is as though they have no traction other than Forwards....? I will delete the excessive text below and the images to stop this thread being bloated - it'd be nice to resolve the steerage problem. Cheers. I've been having a bit of fun this morning importing somewheels I made and attempting to attach them to the truck cab, have had limited success but cannot seem to scale the scale and wheel vars below 0.7? [EDIT... snip snip] |
| ||
| Ok, don't change any ODE code/dimensions from the demo if you want it to behave the same. To add a custom mesh like the wheels, replace the Blitz cylinder meshes only and set their scale with ScaleMesh (not ScaleEntity), you shouldn't need to change anything else. Doing this will not affect the steering or handling in any way. The confusion you're getting into is down to the scales of the custom wheel mesh vs the Blitz/ODE geometry. You need to make your wheel meshes the same dimensions as the Blitz cylinder at 'full size' first (it should be 1.0 unit tall, not 0.7). Then, scale them in code down to 0.7 with ScaleMesh to match the ODE geom dimensions (like the demo). If your wheel mesh dimensions are correct, the original Blitz cylinder and your wheel mesh should match when both are displayed at the same scale. |
| ||
| @VIP3R, thanks for the extra clarification - of to check my wheels/meshes dimensions out, after going shopping with the Mrs.... |
| ||
| Oh, forgot to mention... make sure the wheel mesh is centered properly in your 3D modelling software too, otherwise it may cause the mesh to offset incorrectly when scaled using ScaleMesh. |
| ||
| hi.. i wan't to know about mass... If i have a car that weighs 1800 Kg,what is the correct mass for the car.. where i can find some to read about that? is newton physics? regards... |
| ||
| All weights are relative, for example it depends on things like the gravity value used. The JV-ODE demos use a value of 0.98 Newtons per Kg for gravity, which is a tenth of the real value (9.81 Newtons). A lower value is used as it helps with stability and accuracy of the simulation. If you're using the same gravity as the demos (0.98), for a car that weighs 1800 Kg the correct mass value would be 18000 Kg (multiplied by ten because gravity is a tenth). If you're using the real gravity value of 9.81, it would be 1800 Kg. As it's relative, other settings can be affected, like spring tension/compression (car suspension) and physics timing (the stepping values). |
| ||
| I'm searching, and searching and i can't find anything. Which is the easiest way to create nice explosian efect ? Something like this click |
| ||
| Hmm, there are several ways. One way is to apply a force on the surrounding objects based on their distance and angle from the source of the explosion. The easiest way though is to cheat, create a very small sphere at the center of the explosion with lots of mass, then rapidly increase its size so that it pushes all surrounding objects away. Attach the sphere to the world using a ball joint to prevent it moving about when it collides. |
| ||
| Hi VIP3R, I want to hide the 'pond' that I am creating at a specfic point in my game, tried this to no avail: ;hide the pond HideEntity CapsuleGeom(1) how do I identify it? ;createpond ode.ODEGeom=New ODEGeom ode\body=dBodyCreate(World) dBodySetRotation(ode\body,90,0,0) dBodySetPosition(ode\body,100,2,2800) ;ode\geom=dCreateCapsule(Space,1,8) ode\geom=dCreateCapsule(Space,1,8) CapsuleGeom(1)=ode\geom dGeomSetBody(ode\geom,ode\body) ode\mesh=CreateCylinder(24) ScaleMesh ode\mesh,20,1,20 RotateMesh ode\mesh,90,0,0 ; <<< Mesh X-Axis must be rotated 90 degrees to fix cylinder alignment PositionMesh ode\mesh,0,0,0 EntityTexture ode\mesh,WaterTexture ;EntityColor ode\mesh,Rnd(255),Rnd(255),Rnd(255) EntityAlpha ode\mesh,1 EntityShininess ode\mesh,0.7 ;endpond |
| ||
| It needs to be the Blitz entity (ode\mesh), not the ODE geom (ode\geom)... ode\mesh=CreateCylinder(24) CapsuleGeom(1)=ode\mesh HideEntity CapsuleGeom(1) |
| ||
| hi :) im working in improving the race car game... this car body, with the wheels inside can give me problems with ode? or is ok for ode ? in the samples allways you car have all wheels outside of the car body  |
| ||
| Yep, it's fine to have the wheels inside the car body. |
| ||
| thanks VIP3R. |
| ||
| VIP3R, I've created a trailer like this now, my aspiration (yes, I know I've got high hopes....) is to make the elevated section within the trailer super slippy on top so that as soon as it starts elevating (it will happen slowly... probably both in implementation and execution!) the objects that are on it will slide of the back. A question I have is that for the side pillars, should I create 'imaginary' codified boxes which are the length of the trailer walls rather than attempt to create individual pillars of space within JV-ODE ?  |
| ||
| It depends on how you want the objects to behave if they collide with the sides. Go for the pillars if you don't mind objects getting snagged on them, or if you want a smooth slide then put solid (invisible) walls in place. It won't make much difference speed wise on an individual truck so it will be okay either way in that respect ;) |
| ||
| I guess maybe this was in the worng place, but here's a question for VIP3R regarding JV-ODE http://blitzbasic.com/Community/posts.php?topic=83553 |
| ||
| I don't visit the Content Creation Tools forum much, so I missed it. Replied now though ;) |
| ||
| hi vip3r, i want to know something.. you allways give answers, fast, and you realy give solution to our problems about ode knowldge.. my question is, you write ode?, or is a comunity program?, becouse i see other ode, or newton physics system... but you are the only who nows all about ode. i relative new in this community, 1 year... i realy ultra happy of this product, jv-ode is for me the big tool to make good games... and i want to thank you the fact you allways check this forum to give answers.. another question, i see flight simulator use ODE, for physics. how is that?, use ode for the flight simuation?, or they use ode for simulate the landing land part? regards, and thanks! |
| ||
| You're welcome and thanks :) I didn't write ODE itself, you really need to know your stuff to build a physics library. It was originally created by Russell Smith and is now kept updated by a few contributors. All ODE libraries/wrappers are based around the same core ODE library. Newton is a separate physics library. I would say there are a few folks here who know ODE well, having worked on JV-ODE for 4 years I've gained a lot of experience with it - hence the (mostly) fast solutions. The flight simulators probably use ODE for stuff like thrust control, inertia response etc. They would need to add things like air resistance/drag themselves though because ODE doesn't simulate that. |
| ||
| hi, i have a problem, i made some changes in my program, now ode say "stack overflow" runtime error, in the line dworldquitckstep(world,0.1) what could it be? |
| ||
| ups, i find the solution... in another post... :) A stack overflow in ODE will happen if too many objects overlap when created. It causes too many collision contacts during the stepping process. regards!. |
| ||
| got a problem with dMassTranslate()...it has no effect at all :) is that the correct order for applying masses? mass = dMassCreate() dMassSetBoxTotal( mass, massval, masswidth,massheight,massdepth ) dBodySetMass( ODEbody, mass ) dMassTranslate( mass, massOffsetX,massOffsetY,massOffsetZ ) dMassDestroy( mass ) if i call dMassTranslate() before dBodySetMass() i get a "ode internal error 2: the centre of mass must be at the origin (ode.cpp:500)" i need to offset the mass since i got an object that has several collision shapes, which are offsetted itself... *help* :) |
| ||
| This was asked up there (posts #40 - #41) ^ :) http://www.blitzmax.com/Community/posts.php?topic=79489#904902 If you need more info let me know. |
| ||
| hmm...i must admit, i dont quite get it ^^ and the sample you mensioned uses geomtransforms, which are marked as depreciated :/ also, the sample seems to do something different from what you told in your explanation thats, what the sample does: - moving the geoms like wanted - translating the mass the same amount like the geoms - moving the geoms the averaged amount back plus its original position (?) - translating the mass the averaged amount back (?) but how do i now get the geoms to exactly that position i want? really confusing... :/ small sample code? =) PS: got my mail regarding the trimesh-sphere collision problem? |
| ||
| Yes I agree, it's very confusing. Geom Transforms are depreciated and have been replaced by Geom Offsets which are easier to use. Either method applies in this scenario so it's irrelevant. I would suggest ignoring the dMassTranslate method as it doesn't do what you want it to do (offset the mass), it only centers/resets the mass. That's why the ODE authors admitted its function name was misleading (and confusing). To move the center of gravity you create the body and geom normally, then add some mass. Now, to move the mass all you need to do is offset the geometry. It's the reverse of what you're trying to do with mass translate, we move the geom not the body/mass, but in doing so it will move the center of gravity. Take a look at this modified CarDemo-SeeSaw demo... Normally the demo adds a small continuous hinge force to roll the ramp. In the version above, the forces are commented out. Instead, the ramp geom has been offset by 10 units on the z-axis. This means the center of gravity/mass has shifted back by 10 units, making the ramp heavier on the closest side to the camera. If you comment out the geom offset and move the ramp back to its original position, you will see it balances as the mass is centered. Now you need to apply that method to your object, move all of the geometry to offset it from the body/mass. Btw, I haven't received your latest email. The last one I received was about the mesh with collision holes. |
| ||
| ah ok, got it working...had to fiddle around a bit, because dbodysetposition() takes global coords, and dgeomsetoffsetposition() local ones, but thanks to blitz' tformvector() this was a piece of cake... (after i found out about the global/local thing of course ^^) thx a ton! as for my mail: if its too much work to reproduce the problem for yourself, you may just ignore it for now...ill try to pinpoint it down with a smaller scale sample the next days... just a small side note: dJointSetHinge2Param(Joint(count),dParamFMax,400) doesnt make much sense, because "dParamFMax" is a 0.0..1.0 value ;) at least it seems so, because any value higher than 1 doesnt change anything for the speed of steering in a hinge2 joint...this is a "problem" im currently working on too: there seems to be no possibilty to increase the speed of steering above a hard coded value in the hinge2 joint...any ideas? |
| ||
| doesnt make much sense, because "dParamFMax" is a 0.0..1.0 value ;) at least it seems so, because any value higher than 1 doesnt change anything for the speed of steering in a hinge2 joint Eh? The range of dParamFMax is 0.0 to dInfinity. It doesn't change the speed, it sets the maximum force/torque the joint motor is allowed to use in order to run up to the required speed. dParamVel sets the speed on a joint motor. |
| ||
| hi :).. i need some help.. i have a problem with a ode car, the car wheels bounce like crazy... i have a ode menu, with one ode car... i start the race, with a new ode, destroying all ode data... but when i restart the menu, creating a ode world, car, and dplane, the car bounce like crazy.. to restart and clear the world and ode data i use this commands... For ode.ODEGeom=Each ODEGeom Delete ode Next For car.car = Each car Delete car Next dJointGroupDestroy(ContactGroup) dSpaceDestroy(Space) dWorldDestroy(World) dCloseODE() why might be this happening? the car never stop of bounce and jump like an mexican car :) the strange thing is, always happend after the first time i run the menu.. i use this code to create the ode world.. Global WorldERP# Global WorldFriction# Global World Global Space Global ContactGroup WorldERP# = 1 WorldFriction# = 60 dInitODE() World=dWorldCreate() Space=dHashSpaceCreate(0) ContactGroup=dJointGroupCreate(0) dWorldSetAutoDisableFlag(World,0) dWorldSetGravity(World,0,-1.98,0) dWorldSetERP(World,WorldERP) dContactSetMode(dContactSlip1) dContactSetMu(WorldFriction) dWorldSetContactSurfaceLayer(World,.01) |
| ||
| Hmm, very strange. It sounds like something hasn't been deleted properly. Try manually deleting all of the bodies, geoms, trimeshes and joints with the following functions, -before- deleting the jointgroup/space/world... dBodyDestroy(body) dGeomDestroy(geom) dGeomTriMeshDataDestroy(trimeshdata) dJointDestroy(joint) If that doesn't help, you might need to re-use the world/space instead of deleting everything and re-initialising ODE. |
| ||
| can i use the same world if i use clearworld 1,1,1? thanks vip3r... |
| ||
| ClearWorld only applies to Blitz entities and will have no effect on an ODE world. In the post above, I'm referring to ODE worlds only. |
| ||
| Eh? The range of dParamFMax is 0.0 to dInfinity. It doesn't change the speed, it sets the maximum force/torque the joint motor is allowed to use in order to run up to the required speed. dParamVel sets the speed on a joint motor. but dParamVel is used in your car demos to set the steering angle...? does it have another meaning if used on a hinge2 joint? what could i do about to change the speed of steering? tried nearly all joint parameters and a lot of combinations, without any success yet. sincerly, the ode docs are not very helpful on that... :( sorry to bug you about this...but im really trying to understand it :/ |
| ||
| No problem ;) dParamVel sets the speed at which the joint motor will run, this applies to the first axis of any joints including the hinge2. In the demos, the steering works by increasing/reducing the speed depending on the current angle of the joint axis, it will eventually stop as the Hinge2Angle1 and Steer values cancel each other out. To change the speed of the steering in the demos, you have to increase two values. First is the 'Steer' value in the UpdateKeys() function. The second is the 'Hinge2Angle1' value in the UpdateCars() function. If you want the speed of the steering 10x faster, you multiply both values by 10, like so... ; ### UpdateKeys() If KeyDown(203)=1 Or KeyDown(205)=1 If KeyDown(203)=1 Steer=5 ; <<< HERE (0.5 * 10) Else Steer=-5 ; <<< HERE (0.5 * 10) End If Else Steer=0.0 End If ; ### UpdateCar() For count=1 To 2 angle#=Steer-(dJointGetHinge2Angle1(Joint(count))*10) ; <<< HERE dJointSetHinge2Param(Joint(count),dParamVel,angle) dJointSetHinge2Param(Joint(count),dParamFMax,400) Next At this speed the steering is almost instant, it won't go much faster though because the values won't cancel each other out properly causing the wheels to spin erratically. So there's no difference between each axis in the joint, we are just preventing the steering axis from turning when it reaches a certain limit based on the angle. If you remove the dJointGetHinge2Angle1(Joint(count)) function from the equation, you will see the wheels then turn continuously like they do on the second (rolling) axis. |
| ||
| ah great...seems like i misunderstood the whole steering concept :D i really thought "dJointSetHinge2Param(Joint(count),dParamVel,angle)" would set the actual ANGLE of the steering wheel...but now i understand that this sets the velocity the REACH the desired angle! got a bit mislead by the variable "angle#" here... ok, now all this makes more sense to me...thanks again! surprisingly all my steering code i wrote to date (including calculating steering limits from degrees!) seemed to worked perfectly well, now i dont understand why, but it did...except from the ability to define the speed of steering of course ^^ anyway...rewrote it now, so it reflects the correct way of doing it and it works equally well including the steering speed, excellent! :) now on to the trimesh collision stuff.......you may hear from me soon again... =D |
| ||
Hi VIP3R, I'm looking at creating a hinged door on the back of an articulated trailer flatbed. I am analysing the zombie code to try and see how 'hinges' are implemented, but any assistance you could provide with code between two cuboids that would lock a vertical cuboid(the door) to a horizontal cuboid(the trailer floor) at 90 degrees until the 'move door' key press, then the door would rotate down, on the hinge until it hits the floor. Then, the same key press would rotate the door back up again until it reaches the vertical whereby the door would ' shut' on the back of the trailer. Quite an in depth question, I have looked at various door examples in Blitz 3D but none of them are parenting/hinging a door top the back of a flatbed. Sorry if I ask too much..... I've so far added a setup bones function, although at this point I'm not sure of the relevance of the numbering system related to bones:Function SetupBones() SetBone(1)=1 ; ### Left hand side of door to flatbed rear left hand side (lower) SetBone(2)=2 ; ### Right hand side of door to flatbed rear right hand side (lower) end function I am attempting to analyse the setupnodes function but it is a bit beyond me at the moment....., am also analysing the cloth demo within thread 10 for sphere conections.... |
| ||
| Forget the bones stuff, that was used for the animated mesh (zombie model). Have a look at the CarDemo-SeeSaw demo, the ramp uses a hinge joint with a continuous force pushing the ramp down on one side. To create your door, add the door body/geom/mesh in the closed position on your trailer. Now create the hinge joint and anchor it at the base of the door. You only need one joint, but you can use two if you want. Set the required axis with 1 or -1 to allow movement on one axis only (X, Y or Z). dJointSetHingeAxis(Joint,1,0,0) Now add some joint motor stops to restrict the motion of the door. You only want the door to open outwards so keep the 'LoStop' at zero (the start position), then set the 'HiStop' to the maximum angle you want it open to (normally the ground should stop it before it reaches this stop). The angles used here are in radians, not degrees. dJointSetHingeParam(Joint,dParamLoStop,0) dJointSetHingeParam(Joint,dParamHiStop,2) To move it up/down, just add force and torque to the joint motor with... dJointSetHingeParam(Joint,dParamVel,force#) dJointSetHingeParam(Joint,dParamFMax,torque#) There are several ways to lock the door shut, you can apply a continuous force/torque to hold it shut. Or, detect the angle of the joint and apply zero force with lots of torque to lock it into position. To allow it to move freely, you would use zero force and zero torque. If you need more help with it, let me know. |
| ||
| Thankyou for the swift feedback VIP3R, very much appreciated - if I was on the PC that had B3D on it I'd try your solution now. I'll try implementing it tomorrow, I'm tempted to do it now but family duties need tending (;-) |
| ||
| hi vip3r.. i goint to try to reuse my ode world in my game... the question i have, is , which one is the correct way to delete for example, my race car, and track to use the same world in the menu... there is an example of deleting ode objects in the ode samples? regars! |
| ||
| The correct way is the reverse order in which they were created, for example... Create Order: Type Reference Body Geoms Meshes Joints Delete Order: Joints Meshes Geoms Body Type Reference |
| ||
| thanks vip3r.... :) very important data.. another thing.. i finish the first downloable version of the game.. i am using ode, sometimes, the cars come crazy and start to bounce... we talk in this post about that... please, can you play the game, and help me with that?.. to download the game... www.simplerace.com.ar in download links. i post a topic about the bugs of the game and advices here http://blitzbasic.com/Community/posts.php?topic=85344 regards, and thanks for the learning... this post of jvode is like a school for me... :) thanks.. |
| ||
| Ok, I've downloaded and tried the demo. Excellent work so far. The only bouncing I noticed was when the car goes over the joints in the track mesh. It seems quite minor to me, is that the bouncing you mean? The only cure for that would be to smooth the ridges of the mesh joints. Are the mesh triangles large? Do you have a wireframe option in the demo? It might make the diagnosis easier. A couple of other things I noticed... The demo crashes after completing a race (2 laps) with a 'Userlib not found' error. The SimpleRace website button on the right says 'DONWLOAD' instead of 'DOWNLOAD'. |
| ||
| THREAD 11 IS ABOUT TO CLOSE Please continue on the new thread located here Thanks :) |
   |