JV-ODE Physics Thread 10
Blitz3D Forums/Blitz3D Userlibs/JV-ODE Physics Thread 10
| ||
| 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 (212KB) The BlitzMax (Win32) restricted demo version is now available for download here (283KB) Have Fun :) Previous JV-ODE Blitz3D Threads: 1 2 3 4 5 6 7 8 9 Useful Links: ODE.org Website - ODE Wiki - ODE User Guide (PDF) - ODE User Guide (HTML) |
| ||
| hi that brake function worked:) I tried this for the force-push TFormVector 0,0,5,car#1,0 dBodyAddForce(car#2,TFormedX()*25,0,TFormedZ()*25) but it didnt work,it created kind of random forces |
| ||
| Hi Vip3r, I not receive the your email with the link of new version of ODE.... Other thing, How is the weight of 1 "mass"??? Example: 1 mass = ??? |
| ||
| Hi EmerGki, I'd removed your email address from the update list because it constantly gives me an error message (Error: 550 - No such domain). It's the same address as the one in your profile here. I've re-sent the link using this address, if you don't receive it then please let me know. Regarding the mass question, a mass value of 1.0 equals 1 kilogram in ODE if you're using 9.81m/s for gravity. |
| ||
| Hi Vip3r, I think I missed the ODE update. Please hit me: cmdrwayne(at)gmail.com Thanks for the great ODE support, it's appreciated. |
| ||
| Thank you Vip3r!!! |
| ||
| @Wayne: Thanks :) The updates were sent to your 'spro.net' address. I've sent your new update links and updated your email address on the updates list. @EmerGki: You're welcome ;) You're email address appears to have worked ok, I've added it back into the update list. |
| ||
| My email really didn't worked between January and May of this year... But for now, everything is ok =D... |
| ||
| hi is there a command to get rid of all rigid bodies and geoms without having to reset the space and world? |
| ||
| It's possible, but not with one function. First, loop through all of your geoms and destroy them individually with dGeomDestroy(geom). Next, do the same with the joints using dJointDestroy(joint). Lastly, do the same with the bodies using dBodyDestroy(body). Neither Space nor World will be affected by doing the above. |
| ||
| thanks, does dworlddestroy get rid of all geoms and bodies? |
| ||
| Yes, dWorldDestroy(world) destroys the World and all of its contents. However, you should destroy all geoms manually beforehand, otherwise you'll get memory leaks. The reason for this is that dWorldDestroy(world) won't delete the collision data which is attached to each geom object, only dGeomDestroy(geom) will do this. |
| ||
| ah yes I did notice that things were colliding with nonexistent objects, thanks |
| ||
| I have a strange problem, when I create a bunch of cubes for the first time the physics take 6 millisecs then I get rid of them and it takes 1 millisecs but when I replace the same cubes it takes 25 millisecs any idea why this might happen? -EDIT d'oh it was my fault again I cant help it if Im dumb |
| ||
| No idea without seeing some code showing the problem. If I create 800 cubes the physics time is 15.0, then if I destroy them I get 0.0, and replacing them gives 15.0 again. Repeating the process several times gives the same results. I can only assume you've not deleted everything properly before replacing the cubes. Did you delete each object from the type collection after destroying the ODE objects for example? [edit] Your fault again eh tut-tut :P |
| ||
| Hm, I don't think i got any updates for this. my e-mail is cnisbet@... |
| ||
| Odd, I've not received any errors from your email address and it's definitely on the updates list. I've re-sent it for you Craig, please let me know if you still don't receive it. |
| ||
| Is there a forum I can goto to get technical help with OLE? I'm making a space combat game with it. Only problem I'm having is that when my ship gets hit by my physics based asteroids in space, my ship starts spinning for infinity. I can control the force on a translation basis, but is there any kind of angular force option so I can calm this effect down this endless rotation? Or possibly a drag option I'm missing somewhere that will make in gradually slow down? |
| ||
| You can ask here about the technical queries. You can also ask on the official ODE mail list at www.ode.org, but keep in mind most of it will be C++ based code over there. Try adding some damping with the following functions (whichever is applicable)... dBodySetLinearVel(body,x#,y#,z#) dBodySetAngularVel(body,x#,y#,z#) There are also several functions for adding forces to objects... dBodySetForce(body,x#,y#,z#) dBodyAddForce(body,fx#,fy#,fz#) dBodyAddRelForce(body,fx#,fy#,fz#) 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#) All of the above functions are listed in the official ODE manual (link in top post) and the JV-ODE Function Reference doc. |
| ||
| JV-ODE V1.24 Update Released Please check your inbox :) JV-ODE is now compiled using ODE V0.8 source. To view the changes made to ODE, please visit the ODE Wiki link located here. A new 'Prismatic and Rotoide' joint has been added, you can learn more about this type of joint here... http://opende.sourceforge.net/wiki/index.php/Manual_(Joint_Types_and_Functions)#Prismatic_and_Rotoide Added new functions: dJointGetUniversalAngles() dJointCreatePR() dJointSetPRAnchor() dJointSetPRAxis1() dJointSetPRAxis2() dJointSetPRParam() dJointAddPRTorque() dJointGetPRAnchor() dJointGetPRPosition() dJointGetPRPositionRate() dJointGetPRAxis1() dJointGetPRAxis2() dJointGetPRParam() The dMassTranslate() function is no longer supported in JV-ODE, as its main purpose was to be used in conjunction with Geom Transforms (which are now depreciated). To achieve the same results, you can use Geom Offsets to offset the geom from the body, which effectively moves the mass center of gravity. A more accurate option is to build objects using multiple bodies giving each an individual mass value, then join them with fixed joints. To remain backwards compatible, the dMassTranslate() function can still be used, but its effect will be the same as using dMassTranslate(mass,0,0,0). During testing prior to release, I noticed some slowdown in the following three demos (Blitz3D version only)... CarDemo-DetailedC CarDemo-JointFeedback CarDemo-MultipleSpace ...these demos make heavy use of the text command, which depending on your graphics card/driver and OS (tested using Vista) could result in the loss of rendering speed. The problem is not related to JV-ODE, commenting out the text lines in the demos will fix the issue. Unfortunately, it can't be corrected as this information needs to be displayed in those demos. Something to be aware of. There is also an updated JV-ODE 'C' include file available on request for registered users who wish to use JV-ODE in C++ using the Blitz3DSDK. Please let me know if you experience any problems with the new update. :) |
| ||
| thanks for the update! the new joint might come in handy in some situations. |
| ||
| You're very welcome OJay, thanks :) |
| ||
| VIP3R, Thank you very much for your continued excellent work. Much appreciated. New joint looks interesting. No problems here, as always, with any of the demos. cheers, Mark PS Sorry to see dMassTranslate() fall out of favour - i made quite heavy use of it in my last project ! |
| ||
| Thanks Mark, very much appreciated :) If you need any help replacing dMassTranslate() with an alternative, please let me know and I'll guide you through it. |
| ||
| Great to have these updates - so long after buying too! Every time I get an update I always go back and have a play (then realise I've forgotten everything and have to learn it all from scratch) :) |
| ||
| Hehe, cheers Caff ;) |
| ||
| Anyone know how to set rotational velocity relative to a bodies orientation? It seems to only be able to set it in world space. |
| ||
| The API only supports setting a bodies velocity in global coordinates as far as I'm aware. I think the correct way is to add relative force and torque to achieve the required velocity instead. You could also try adding a joint to the body with locked rotation axis (dParamLoStop/dParamHiStop = 0), then set rotational velocity using the joint motor (dParamVel/dParamFMax) which in turn will rotate the body. The joint may need attaching to the world for this to work. |
| ||
You'd have to take your local orientation and transform it to global then apply it. You can do this with the TFormNormal command.;Here is the local torque(force) we're going to apply local_torqueX# = 10 local_torqueY# = 0 local_torqueZ# = 0 ;First get the orientation of your mesh in global space TFormNormal 0, 0, 1, mymesh, 0 ;now multiply the torque by the global orientation global_torqueX# = local_torqueX * TFormedX#() global_torqueY# = local_torqueY * TFormedY#() global_torqueZ# = local_torqueZ * TFormedZ#() JVODE_ApplyForce(mymesh, global_torqueX, global_torqueY, global_torqueZ) I may have the mymesh and the 0 reversed in the TFormNormal command. Also, I know the syntax for the JV-ODE command isn't right but you get the idea. This would mean you're applying 10 force of pitch down in local space. That should work. Let me know if it doesn't and I'll try again. |
| ||
| I guess this is really a forum for problems and questions, but id just like to say, ive just got JV-ODE and its great. the best fun ive had in ages. even just playing with the examples and seeing what different things do. thanks VIP3R your wrapper is money well spent! |
| ||
| Thanks Pete, much appreciated :) |
| ||
| I downloaded the demo of JV-ODE and have had some great fun with it, I can see huge possibilities with the car physics.... I've been 'throwing a bomb' with some success in pure B3D, but I can really see the appeal of your Physics wrapper. |
| ||
| Cheers Blitzplotter, happy to hear you're enjoying the demos :) |
| ||
This maybe something fundamental I'm missing, but why aren't the blocks I'm creating as follows 'rigid' ? (I was attempting to create a track (akin to stunt car racer) using your ramp code to jump the car onto the track... But my track doesn't appear very solid... i.e. the car moves through it, instead of riding on top of it.)For z = 100 To 1000 Step 31 ; 31 apart in the z plane ode.ODEGeom=New ODEGeom ode\body=dBodyCreate(World) ode\geom=dCreateBox(Space,2,3,z) dGeomSetRotation(ode\geom,0,0,90) dGeomSetPosition(ode\geom,15,5,z) ode\mesh=CreateCube() ScaleMesh ode\mesh,4,60,20 RotateMesh ode\mesh,0,0,0 PositionMesh ode\mesh,0,0,0 EntityColor ode\mesh,0,100,200 EntityAlpha ode\mesh,1 Next Thanks in advance.... |
| ||
| It's difficult to say with the above code snippet only, but you've scaled the visible meshes wrong so you're probably driving through those as opposed to the ODE geometry... dCreateBox(Space,2,3,z) <<< Are you sure you want the depth (z) larger for each box added? ScaleMesh ode\mesh,4,60,20 <<< The scale is wrong here, each dimension should be 2x ODE like so... ScaleMesh ode\mesh,4,6,z*2 <<< 2x 2, 2x 3, 2x z |
| ||
| Thanks very much for the help VIP3R. I've incorporated some joypad code to your ramp demo, and am now working on a (simple) stunt car racer track. ( http://amigareviews.classicgaming.gamespy.com/stuntcar.htm ) this is the code snippet that creates a track in front of the ramp (in your ramp demo) You've another customer after payday.... a weeks time! |
| ||
| Nice one :) You can omit the 'ode\body=dBodyCreate(World)' on static geometry, a body is only needed for moving objects. In the full version of JV-ODE, you'll be able to place all of those track/fence sections into their own sub-space. This allows you to disable collisions between each track/fence section (at the moment they will be colliding), resulting in a significant speed increase during collision checking. I'll guide you through it when the time comes ;) |
| ||
| Hi just one thing how do change the cars start position in the car demo (trimesh) . ive changed the mesh to a race track mesh i made and moved the camera to an postion so you can see the whole track. it works great ive got the car driving really nice by tweaking the mass and gravity setting, but does the car have to be created at 0,0,0 if so how do i move it to another position because i can move the car but wheels get left behind i know im missing some thing? i would love an example with more than one controlable car, maybe split screen? |
| ||
| You need to move the initial wheel position too. Try adding the following code sections... ...notice the last four lines, they position the wheels. |
| ||
| thanks VIP3R, i understand which bit does what now. should be easy to add another car now. |
| ||
| thanks again VIP3R, looking forward to using the full version..... Modified my example 'somewhat limited', trackcode (I commented out my unneeded static calls). Briefly attempted moving the car myself (simply so my daughter could drive onto the ramp without negotiation) However it resulted in the body being offset from the wheels, which could be (in not so severe a fashion) an interesting way to incorporate damage, so thanks for the above snippet of code. |
| ||
| I've created a (basic!) track in Wings3d, converted it to B3d with UU3D and managed to display it within an 'arena' If it is a simple omission on my part, could you (or anyone...) please let me know what is missing from my code to make the b3d model 'rigid'. The car drives straight through my track/model. The track is very basic, but it is to learn how to code with your brilliant engine. Regards, Blitzplotter. |
| ||
| When you have the full version you will be able to convert the B3D mesh into a TriMesh. The TriMesh will be an identical copy used for the physics collision geometry. Note there isn't any TriMesh support in the demo version, hence the lack of collisions ;) If you change your mind about which version to get (BMax / Blitz3D), you can take advantage of a 50% discount for existing users of either version. |
| ||
| Just downloaded my full version.... have successfully tri-meshed my track, it's lovely and solid, however it bounces around instead of being an immoveable object. I've basically copied the addobject function from the tri-mesh demo, removed the random positioning so I position it where I want. I've had a quick scan around the new example code, could you please point me in the right direction of how to make my tri-meshed track an unmoveable object? I'll post my snippet of add object if necessary, but it is basically the same as the example Tri-mesh code. In the mean time I'm off to build some stunt car racer-esk tracks (;-) I'd like to finish by adding that I haven't had so much satisfaction & fun from coding in 3D in... well... ever! Your Physics engine is great. Thanks in advance, Blitzplotter. |
| ||
| Thanks for the compliments, much appreciated :) Hmm, it sounds like your TriMesh is attached to a body somewhere. Make sure to only use geoms for static objects. |
| ||
| Cheers VIP3R, just created my first Mario-esque (N64, fort block...) tower and drove to the top of it. @Pete Carter: thanks VIP3R, i understand which bit does what now. should be easy to add another car now. Hmmm, I'll do that next... |
| ||
| ive just added a second car with no problems. Im just working on anolog joypad control now. Whats this brake function thats talked about at the top of the thread? |
| ||
| The brake function was discussed at the end of thread 9, it was to show how to lock the wheels up solid like a handbrake. Very easy to do, 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 |
| ||
| very nice! thanks for clearing that up i will have a look though the old threads see if im missing anything else. thanks VIP3R |
| ||
| You're welcome :) |
| ||
| Hey, can you tell me what email address you're sending the updates to because I didn't get this update. >_< I think you might still have my dad's old email which he doesn't have anymore because we changed our ISP. :/ |
| ||
| Can you email me with your original purchase details, along with the new email address? |
| ||
| Sure thing, I'll do it when I get home. |
| ||
| have just tried the truck and trailer code, very cool! Manipulating the zombie is also very impressive. |
| ||
Bit off topic but finally finished my 2D ODE game, using the wrapper of course :) More details at http://exile.ovine.net StuC |
| ||
| Hey congrats Stu, that looks great!!! :) |
| ||
| have you tried stacking cubes in 2d? |
| ||
| Not sure who you're directing the question to, but no I haven't tried it. Are you having problems or just curious? |
| ||
| Yes - in the game above the crates are all cubes, they stack great. |
| ||
| Next venture is going to be using car physics. Any tips/pointers anyone ? Ive only being using JV-ODE in 2D ....... |
| ||
| Depends on what type of car game, are you aiming for arcade or simulation? It's best to begin with a simple body with four wheels like the demos. Next, you should simulate the engine and transmission, for example the revs, 2WD/4WD, gear ratios and torque. The next step depends on whether you want realism (simulation) or a more arcade style. For a simulation you will need to rebuild the car realistically, with weight distributed around the chassis correctly to represent things like the engine block etc. You can also build your own suspension system instead of using the built-in ODE hinge2 joint. With arcade designs this isn't as critical, you can achieve certain handling effects by exaggerating things like weight distribution and transmission. Best thing to do is experiment with different setups until you find something close to what you're after, then refine it. |
| ||
| Sorry for being off topic but I am totally new to JV-ODE and I would like to know how I can setup the car-demo samples with a 'real' car mesh and having the collisions for this mesh and not for a cube. Any related links will help. Thanks! Edit: I have the full version of the wrapper for Blitz3D |
| ||
| Yea Im going more for arcade over full simulation. Ive been messing with the setup of the demo car and also taking some bit from other ODE threads. AT low speed everything looks and works like a dream, but as soon as the car gains speed, it slides, it flips and all sorts. SOme of it I have limited by decreasing the steer rate at higher speeds (which limits the flipping) but Im still getting a degree of slide. On any bump the car tends also to flip over in mid air. I take it I need to create some GeomSetOffsetPosition() geoms to distribute the weight ? - DO these need a mass too ? |
| ||
| @Moraldi: It's best to use single or multiple primitives (like cubes) for the collision geometry of the car. You'll get much better performance this way. To add a mesh, simply replace the visible Blitz3D cube with any mesh. @Ovine: Several things can cause flip problems, for example too much friction and not enough mass. For increased accuracy you can divide the physics steps into smaller segments, the CarDemo-HighSpeed demo does this. You can use Geom Offsets to distribute the mass of a single body (only bodies have mass, not geoms), another method is to create individual bodies with mass and then join them together with fixed joints. So you could add another cube to represent the engine block, give it some mass and fix it in place with the fixed joint. You can submerge a body (engine) within another body (car shell) provided they are jointed. |
| ||
| thanks for the info, shall play more. |
| ||
| what code do you use to create a stack of boxes? I used this: For x=0 To 5 AddObject(x*27) Next Function AddObject(x) ;xp=Rand(-80,80) xp=0 ode.ODEGeom=New ODEGeom ode\body=dBodyCreate(World) dBodySetRotation(ode\body,0,0,0) dBodySetPosition(ode\body,xp,x,0) dBodySetAutoDisableFlag(ode\body,1) ode\geom=dCreateBox(Space,56,28,28) dGeomSetBody(ode\geom,ode\body) ode\r=Rand(255) ode\g=Rand(255) ode\b=Rand(255) Joint2D=dJointCreatePlane2D(World,0) dJointAttach(Joint2D,ode\body,0) End Function but the stack always collapses |
| ||
| There are a couple of things that could cause the collapse in the code you've posted. Firstly you're adding the boxes in real-time and stepping the simulation between each addition, this can cause the boxes to bounce against each other leading to instability. Another problem which will make matters worse is the 1 unit gap in your x variable which will become a 6 unit gap by the time the last box drops, amplifying the bounce problem. For a more stable method, if possible stack the boxes all at once before stepping the simulation. Don't use a large gap between each box, use very small separation units (like 0.0001). Other things that can help would be to reduce, or zero the world/geom bounce parameters and also changing the world/geom CFM to make the boxes more rigid. The default CFM can cause boxes to be a little springy. Note this applies to both 3D and 2D simulations. |
| ||
| Ok maybe ive missed something but im starting to add sound to my little jv-ode car game and I dont know how to trigger different sounds when say the cars ode/body hits the wall it would make a bang sound and if the same car hit another car it would trigger say a metalic scrapping sound? thanks Pete |
| ||
| Have a look at the 'CarDemo-DetailedC' demo which shows how to return detailed collision info, it displays which objects have collided with the car body. You can check each collision on the car body, then play your sound depending on what type of body it has collided with. The functions needed for this are dGeom1CollisionGeom(GeomID,index) and dGeom2CollisionGeom(GeomID,index). |
| ||
| Thanks again VIP3R great as always |
| ||
| Stu, Exile looks and plays great. (;-) |
| ||
| ok i did this; (taking it out of the main loop) dContactSetBounce(0.0) dWorldSetCFM world,0 dContactSetMu(48) For x=0 To 5 AddObject((x*28)+14) Next Function AddObject(x) ;xp=Rand(-80,80) xp=0 ode.ODEGeom=New ODEGeom ode\body=dBodyCreate(World) dBodySetRotation(ode\body,0,0,0) dBodySetPosition(ode\body,xp,x,0) dBodySetAutoDisableFlag(ode\body,1) ode\geom=dCreateBox(Space,56,28,28) dGeomSetBody(ode\geom,ode\body) ode\r=Rand(255) ode\g=Rand(255) ode\b=Rand(255) Joint2D=dJointCreatePlane2D(World,0) dJointAttach(Joint2D,ode\body,0) End Function the blocks still seem very bouncy and slippery |
| ||
| Hmm, the size of the boxes is causing some accuracy problems here. The further you stray from an object size of 1.0, the more chance of these issues occurring. This shouldn't pose much of a problem to convert, as you're using 2D? Change the size of the boxes from 56,28,28 to 4,2,2 or even better 1,0.5,0.5, then scale up the 2D object positions accordingly. Here's a modified cubes demo (including the 2D joint) which uses boxes with 4,2,2 dimensions, it stacks in real-time and will stay stable until at least 10-12 boxes high... To further improve the stability and accuracy, try splitting the time step up in the main loop (see CarDemo-HighSpeed for example). |
| ||
| thanks thats a great help! |
| ||
| @OvineByDesign, your StuntCarRacer images brought a smile to my face, it looks a very good implementation of the one I mentioned a while back.... Brilliant looking work. |
| ||
| Am attempting to detect when the cab of the truck within the truck demo gets within a certain proximity of some particular x, y and z co-ords. With a view to analysing the area that I want to detect the cab is at during movement I am attempting to display the x and z co-ords whilst the truck is driving around. Have had some success with incorporating the detailed car code into my truck demo, however I would like to know the x,y and z of the truck. During my journey to here I've had a rethink on the way forward with my game..... whilst analysing the way different objects are detected as being collided with. does the truck need to collide with something to analyse it's x,y and z co-ords in snapshot fashion as opposed to dynamically? I'm still overawed by the potential of this engine (;-) , my next thang is to add gear change up's of the ilk you'd have with a big artick at certain speeds. |
| ||
| To get the position of any object at any time you can use... dGeomGetPositionX#(ode\geom) for an ODE geom dBodyGetPositionX#(ode\body) for an ODE body You can also use Blitz3D entity coords (EntityX(mesh)) for the visible Blitz meshes (ode\mesh). The Collision X/Y/Z in the detailed collisions demo shows the position of a collision, not an object. |
| ||
| thanks VIP3R, that works a treat. |
| ||
| Hi Vip3r, I'm trying to do a Robotic Arm, but, I think what I need to use Joints to move the arm up and down... How can I control the Joints to move the arm ? (I need to use a joint to make the movement to left and right and other joint to make the movement up and down). |
| ||
| Most joints in ODE have a built-in motor. Depending on the joint used you can use the following constants in the dJointSet[JointType]Param(joint,param,value) functions... dParamVel (force) dParamFMax (torque) You can control up to 3 motors in a multiple joint, for example dParamVel, dParamVel2, and dParamVel3 will set the force on three joint motors (if available). For the Hinge joint (which has one motor), you would use the following code... dJointSetHingeParam(Joint,dParamVel,forcevalue) dJointSetHingeParam(Joint,dParamFMax,torquevalue) |
| ||
| Hi Vip3r, I've tried this: ------------------ Global AJoint2=dJointCreateHinge(World,0) dJointAttach(AJoint2,ode\body,0) dJointSetHingeAnchor(AJoint2,0,6,0) dJointSetHingeAxis(AJoint2,0,1,0) dJointSetHingeParam(AJoint2,dParamLoStop,-0.5) dJointSetHingeParam(AJoint2,dParamHiStop,0.5) Key_Left=KeyDown(75) Key_Right=KeyDown (77) If key_Right=0 And key_Left=0 Force#=0 dJointSetHingeParam(Ajoint2,dParamVel,Force#) dJointSetHingeParam(AJoint2,dParamFMax,1000) EndIf If Key_Right Force#=10 dJointSetHingeParam(AJoint2,dParamVel,Force#) ; ### Force dJointSetHingeParam(AJoint2,dParamFMax,240) ; ### Torque EndIf If Key_Left Force#=-10 dJointSetHingeParam(AJoint2,dParamVel,Force#) ; ### Force dJointSetHingeParam(AJoint2,dParamFMax,240) ; ### Torque EndIf ------------------ Not work, I don't know why. If I only place the command outside "If", work normally. But, I stay without control... :( dJointSetHingeParam(AJoint2,dParamVel,Force#) ; ### Force dJointSetHingeParam(AJoint2,dParamFMax,240) ; ### Torque |
| ||
| It only works outside of the 'If' statement? Hmm, very odd. If you can post or send me the full source code, I'll look into it for you. |
| ||
Hi, Sorry for the noobness of this question, I am trying to apply a texture to a model I have created in Wings within my ODE world. I've textured simple cuboids successfully, however my attempt at adding the texture to a more complex model is as follows - (it fails to compile when I incorporate the Entity Texture command with a memory access violation which I have associated in the past with failing to load the bitmap.) This isn't the case here.:
unction AddMario()
ode.ODEGeom=New ODEGeom
ode\body=dBodyCreate(World)
dBodySetAutoDisableFlag(ode\body,1)
ode\mesh=LoadMesh("wings tracks\track_10_b3d.b3d")
ScaleMesh ode\mesh,15,15,15
RotateMesh ode\mesh,0,0,180 ;*1
PositionMesh ode\mesh,200,0,180 ;*2
EntityColor ode\mesh,Rand(255),Rand(255),Rand(255)
;EntityTexture ode\mesh, build_txt fails to compile if try this
EntityAlpha ode\mesh,1
EntityShininess ode\mesh,0.7
ode\geom=CreateTriMesh( Space,ode\mesh)
End Function
I have unwrapped my model within UU3D, attempted to use UU3D to try and create a mesh? (failed...) then referred to page 90 and 91 of the B3D manual regarding texturing. Any help appreciated, regards - BP. |
| ||
| There's nothing in the code you've posted which would cause the error as far as I can tell. Btw, you don't need to create the ode\body for a static object (track). Do you get any more error info with debug enabled? It's definitely not an ODE/JV-ODE related issue, but a Blitz3D problem. Double check your 'build_txt' texture is loading etc. Creating a TriMesh from a textured mesh entity will work fine. |
| ||
| Thanks for the feedback VIP3r, (I'll remove the unecessary line....) the problem was due to the fact that the function that was attempting to access the non global texture, the function could not see it. The resolution was when I loade3d it to slap global in front of the texture load so the function has visibility of it. Simple but true. I've now textured my 'floor' to boot.... actually got a playable demo of it, end zone truckin. This is my 1000th post ! not that it matters..... It is a testament to the strength of both BRL and this community however! |
| ||
| Hi Jim, I want what only the wheels do not collide with the other cars, How can I do this? |
| ||
| You can prevent collisions between the wheels of one car and the wheels of other cars by placing all car wheels into their own sub-space (WheelSpace), then disable internal collisions with dSetInternalSpaceCollideMode(0). The car bodies do not need to be in the same space as the wheels. Doing the above will only prevent wheels from colliding with other wheels, they will still collide with the other car bodies. |
| ||
| Maybe a silly question but is there any chance of you making a wrapper for ode for linux? linux does have its own version of a dll, i dont know much about it but i uses linux alot and would love to convert my game to max and if it was cross format even better. |
| ||
| Not very likely, sorry. It would involve changing compilers again, plus tweaking the code to be compatible with the other compiler. An awful lot of work for a tiny fraction of potential users. The Linux market is almost non-existent IMO, despite the 'zealots' insisting otherwise. |
| ||
| fair play, i knew it was a long shot. at least you have done the windows one for max |
| ||
| Vip3r, How can I know if a vehicle hit a wall, in a Trimesh... And, how Can I "free" a trimesh during the game? (I've look in the demo "detailed Collisions", but, in all options, One Geom was created to each "box, cylinder, sphere, etc..", and, I want to use Trimesh) Thank you |
| ||
| You can use dGeom1CollisionGeom(GeomID,index) and dGeom2CollisionGeom(GeomID,index) to detect a collision with a TriMesh, in the same way as the detailed collisions demo. They will return the handle of the TriMesh if the 'GeomID' geom has collided with it. Make sure you use a global handle for the TriMesh. The easiest way to detect collisions with walls in a TriMesh is to actually separate the mesh into different pieces and create a TriMesh for each, for example one for the road surface, another for the walls and so on. Then you can detect which TriMesh has collided, the wall or the road surface etc. |
| ||
| Thank You Jim =D! One more great help! |
| ||
| Thanks again VIP3R just had a run though of your wrapper demos for max. I hoping when i get minib3d working, (ive posted in the minib3d forum) to move my driving game over to max, its coming along well but could do with FSAA which works in minib3d plus ive been meaning to make the move for quit some time. A question i know the OpenGL engine that comes with your wrapper is only basic but have you put in any commands for scaling or rotating the b3d mesh once its been loaded? its very fast on my machine which is nice. thanks again loving your work |
| ||
| You're welcome both, thanks :) There is scaling built into the draw functions in the OpenGL engine but not rotation, that has to be handled separately. If you take a look at the UpdateGeoms() function in the BMax demos, you will see that the rotation is handled in there directly. It also shows the full parameters for the draw functions, for example DrawCube(xscale,yscale,zscale). MiniB3D would be the way to go though, the built-in JV-ODE OpenGL engine is far too primitive to be used for anything other than the demos. It's fine for tinkering with until you're ready to plunge into MiniB3D of course ;) |
| ||
| Hello sorry its me again VIP3R. What part of the detailed collision example finds out what body has collided with on object. I want to find out in my multiplayer car game which car crosses the line first and the line is a different trimesh. so when the wheel hits it i want to know which car it was. oh and there are 4 identicle cars if that matters, they are created in the same way as your examples. but with different ids, car1 car2, wheel1(1), wheel2(1) etc i dont fully understand the GeomCollisionInfo(GeomID) function. Pete |
| ||
| Hi Pete, You use dGeom1CollisionGeom(GeomID,index) and dGeom2CollisionGeom(GeomID,index) to detect which geom has collided with another. Ok, first you need to check that the object has collided with something using dGeom1CountCollisions(GeomID) and dGeom2CountCollisions(GeomID). You will get errors on the other collision functions if there are no collisions detected. Next you want to know if the car wheels have touched the finish line mesh. To do this you will need the finish line mesh geom handle ( FinishLineGeom=CreateTriMesh(blah) ) and the wheel geom handles ( Wheel1(CarNumber) ) like so... For CarCount=1 To CarTotal If dGeom1CountCollisions(Wheel1(CarCount))>0 Then CollisionGeom1=dGeom1CollisionGeom(Wheel1(CarCount),1) If dGeom2CountCollisions(Wheel1(CarCount))>0 Then CollisionGeom2=dGeom2CollisionGeom(Wheel1(CarCount),1) If CollisionGeom1=FinishLineGeom Or CollisionGeom2=FinishLineGeom Then Winner=CarCount NextThe above will only check the first collision (index=1) and only the first wheel (Wheel1), you might want to check each collision index and each wheel, but it should give you the idea. The 'index' parameter is the collision number, if an object collides with two other objects at the same time, you can check index '1' for the first collision and then '2' for the second and so on. The maximum amount of collisions will be returned by the dGeom1/2CountCollisions(GeomID) functions. |
| ||
| thanks that helps i give it a go. |
| ||
| Hi, how would you go on creating a waypoint system using ode (how to apply force to the direction of the goal)? Thanks. |
| ||
| It depends on the use, for example if it's a car then you adjust the wheel angles towards the goal to steer the car in that direction. To add force to a whole object, like a spaceship etc, you need to work out the angles towards the goal and apply forces to each vector accordingly, for example to move forwards and diagonally right you would add the same force to fx# and fz#. There are several functions for adding forces to objects... dBodyAddForce(body,fx#,fy#,fz#) dBodyAddRelForce(body,fx#,fy#,fz#) 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#) |
| ||
| Hi VIP3R, thank you. My object is getting off the waypoint and then returns nearer it (a few times, to just get to the point). I have identified angular velocity as the culcript. Is there a way to provide a maximun angular velocity without doing it each cycle? (Currently I set its angular velocity to 0 before adding force again). |
| ||
| The forces are accumulative in ODE so they must be added each cycle (step). Have a look at the following guide, it may prove useful for your simulation... http://opende.sourceforge.net/mediawiki-1.6.10/index.php/HOWTO_thrust_control_logic |
| ||
| Hi, thank you. I will be looking closely into those and the wiki. |
| ||
| Hello VIP3R, Hopefully a fairly easy one for you (ive searched around a bit and not found an answer, so apologies if its been explained elsewhere). Can you switch off collision between two defined 'spaces' ? I have created three spaces, a main one and two child spaces within the main one. I dont want the geoms in the two child spaces to collide with one another - but i want geoms in the main space to collide with everything in the child spaces. Hope ive explained that OK - any ideas ? [edit] Ive had some succes using the dSetInternalSpaceCollideMode(0) command - and then putting all the stuff i dont want to collide into the same space, and stuff ido want to collide into separate spaces. Not ideal though - you know when you feel youre doing something in a way not intended by the designers ?! Another quick question - is there an upper limit to the number of tris you can pass when creating a tri-mesh ? If there is, and you exceed it, does ODE just ignore the excess tris ? If so that would explain some weird stuff thats been annoying me. [/edit] cheers Mark |
| ||
| Hi Mark, Good to see you :) For the first question you could use dSpaceCollide2() instead of dSpaceCollide(), but you would need to check individual spaces (or even geoms) manually doing this. There may be an impact on speed as a result, depending on how many spaces or geoms are checked for collisions. Your alternative will work fine though. The dSetInternalSpaceCollideMode() feature of JV-ODE was designed to be used in that way, so it's optimised for speed. The spaces and objects need to be ordered in such a way for this to work, which can get tricky. Don't forget you can use multiple levels of spaces too, every space (and sub-space) can have further sub-spaces. Regarding the second question, I'm not aware of an upper limit for TriMesh tris. If there was a limit it would throw an error when creating the TriMesh as it has to allocate memory depending on the tri/vert count. Can you describe the weird stuff, you never know it might be something simple ;) |
| ||
| Hi VIP3R, Thanks for the help. I think I understand the dSetInternalSpaceCollideMode() command a little better now, it just seemed a bit awkward at first, but it certainly is fast. Overall I can't believe just how quick the collision stuff is with JV-ODE. Hope you dont mind ive clogged your thread with some screenies, but to explain my 'weird stuff' i thought an image might help :-     Im creating a procedural world, no media, all built internally. Not sure where im going with the project but i liked the look of the planets in 'spore' and wanted to try to create something similar. So far i have a planet with gravity, trees, water and a car in which you can drive around in - to look at the trees and water. I also added a sun and made the planet rotate so you get a day / night cycle. Quick video (5mb / 60sec) : http://www.wildebeestgames.com/JV-ODE/GlobeWIP.wmv Method : First is the planet surface which is a mesh sphere. This is split into chunks and sent to ODE as a series of tri-meshes. No problems so far. Next is some surface detail - trees. As you can (hopefully) see from the image above the trees are in clumps. There are two sets of tree geometry - a complex model for the visuals and simple model for sending to ODE. If the clumps are too large the tri-meshes sent to ODE only partially work. i.e. you can drive 'through' some of the trees (in the same clump) whilst others are solid. By making the clumps smaller (i.e. fewer trees and so fewer tris) then all the geometry becomes solid. Hence my earlier question about an upper limit on the number of tris a tri-mesh will accept. Any thoughts mate ? I will do some tests over the next few days to see if large tri numbers affect the gemetry of the model within ODE. Thanks again for your continued help and support - your wrapper is easily the best thing i have ever purchased for my coding. cheers, Mark |
| ||
| VIP3R I am having trouble using the slider joint. I am trying to use it to attach to the top of the car provided in your Car demo. I previously atached a trimesh object to the front of the car using a hinge joint without problem. After using all of the corresponding commands for the slider joint (except there seems to be no way to specify an attachment point) I can only succeed in raising the car off the ground. This joint is acting as if it were attached to the car and the plane instead of the box and the plane. I have tried turning on and off various parameters without better luck. using dbodyenable on my box before the dparam vel command results in an error: Bad argument(s) (..\..\ode\src\ode.cpp:814) Do you have any ideas on how i can get this joint to work? |
| ||
| @Mark: Don't worry about clogging the thread, they're nice images so they brighten the thread up a bit. Thanks for the kind compliments :) Ok, the first thing to check is to make sure each static object doesn't collide with the others, for example you don't need tree>tree or tree>ground collision checking. To correct this, place all static objects into a sub-space and disable internal collide mode (as you did above). Although there's no limit to the amount of tris in a TriMesh, there is a limit to the amount of collision contacts ODE will process each iteration. If you're scenery TriMeshes are colliding with each other it will make the problem much worse. This will most likely explain the ability to drive through some objects and not others. You can adjust the dWorldSetQuickStepNumIterations(world,num) and dContactSetMaxContacts(max) functions to see if they help if the problem remains after checking the static ojects aren't colliding. If the problem persists let me know, I'd like to discover the cause if possible. The night cycle and headlight effects looked great in the video, actually spore was the first thing that came to mind when I saw the images. @DaveKovaka: For some odd reason ODE doesn't provide anchor points for a slider joint, so they're always anchored to the center of a body, I'm not sure why. You shouldn't get that error from enabling a body before accessing joint parameters so that may indicate a problem with the simulation setup somewhere. Here's a slider joint demo, it also uses dBodyEnable() prior to setting dParamVel... |
| ||
| Thanks VIP3R, I believe you've hit the nail on the head - re: maximum collision contacts processed per iteration. If I mess with dWorldSetQuickStepNumIterations(world,num) and dContactSetMaxContacts(max) i can decrease the frequency with which my car passes through trees albeit with a corresponding increase in processing time per iteration. However I am now using the space method along with disabling internal collide mode which works beautifully. I also think part of the previous problem is that the tri-meshes im creating are occupying the same space (bounding box wise) because they are arranged as a sphere - so the ODE engine thinks they *could* collide - so does the checks each iteration. Thanks again for your help, Mark |
| ||
| You're welcome :) You could also try increasing the accuracy of the simulation by splitting up the time steps in your main loop, as shown in the 'CarDemo-Highspeed' demo. It may catch more collision contacts due to increased timing resolution. |
| ||
| Im having fun trying to get the AI in my game to drive a car round the track, I trying it by using a waypoint system but its very hit and miss at the moment. Have you tried anything like this vip3r? |
| ||
| Your best bet is to follow a tutorial on waypoints, I don't know of any to hand, but there are bound to be a few on the forums here somewhere. Once you have the waypoint system worked out, it should be mostly straight forward to guide the cars to them using their steering and adding forces. If you're having a specific problem, try to explain it in detail, it's difficult to suggest anything without knowing what's happening exactly. |
| ||
| If i get really stuck ill post or send you the code, but its still fun playing with it at the moment. I just wondered if anyone had done something like this before and had any tips on how to handle it. at the moment im using 2 entities attached to the car and using the entity distance of the two entities to deside steering, ive got the car to look for the next waypoint and drive at a lower speed if not pointing directly at the next waypoint. this gets the cars to slow down for bends in the track. if they get stuck at the moment they just ram the object thats blocking them so i need to work on it a bit more yet. thanks VIP3R |
| ||
| Hi I just purchased the JV-ODE yesterday, and its already proved extremely powerful- I'm loving it! However I've run into a problem regarding cylinder > triMesh collision. After scanning through these threads, am I right in thinking that the problem is in the source engine, not the wrapper?... or is it something that has not been implemented in the wrapper yet? And, I know that capped cylinders work, but for my purposes its not really a solution as I really do need a flattened cylinder with no rounded caps. Has anyone else been able to get it working, or knows of any work-arounds? |
| ||
| Hi and welcome :) The Cylinder>TriMesh collisions are not implemented in the ODE core (engine source) yet. There was an attempt to fix this quite recently but it broke other stuff like Cylinder>Cylinder collisions, so I'm waiting until they fix it properly before I update JV-ODE with the new cylinder source. The only workaround is to attach other geoms (like spheres) to the cylinder to provide the collision detection instead. The 'CarDemo-SphereWrapCylinder' demo shows the workaround in action, but if you're creating disc/coin shaped objects you will need to position many small spheres around the rim for this to work. Otherwise just apply the spheres along the shaft of the cylinder as the above demo does. |
| ||
| ok, I'll take a look at that demo and see if I can apply it as a workaround for now. However, I suspect I'll need to wait for a proper fix to the core engine. Its good to know you intend to keep the wrapper updated though, as and when the core changes. And thanks for responding so quickly! |
| ||
| Thread number 10 !!! This is amazing! Congratulations for your work Vip3r. I've been very busy the last months (years?) XD Regards for everyone! |
| ||
| Hey Kuri thanks, it's good to see you :) Hope everything is going well for you. |
| ||
| mr.VIP3R, does your ODE wrapper support cloth?? If so i would like to see some example and in that case, do my happy purchase.. |
| ||
| 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. Here's a quick demo... Note the visible spheres are only there as a guide. Normally you would add a 'cloth mesh' containing multiple bones, then update the bones with the sphere position/rotation coords. |
| ||
| Does the wrapper take advantage of dual/quad core CPUs in any way? |
| ||
| It runs in a separate thread to your Blitz program even on a single core CPU. For multi-core CPUs the threads are divided up between processors, so it should take advantage of both cores in dual core systems and two cores of quad core systems I believe. JV-ODE is compiled as a multi-threaded DLL, although ODE itself is not multi-threaded. |
| ||
| Thanks VIP3R:) As the PhysX wrapper looks dead I may swap to this. Does it have magnets, triggers and particles? Also, how fast is it with say a stack of 800 cubes, I get 58fps with the PhysX wrapper withh 800 cubes. Thats on a quad core+8800ultra |
| ||
| Yes magnets, triggers and particles can be simulated, but they must be created and setup by the programmer. They're not built into the ODE engine like the PhysX engine, so it isn't as convenient. For triggers you can use the detailed collision information to achieve the same results. For particles you just add tiny objects with some mass, then add some force to throw them in whichever direction. For magnets, there's an example in thread 4 by Shifty Geezer, but it will only run in the full version of JV-ODE (with a slight edit to two function names). ODE is extremely fast, but it's difficult to quantify the speed of a physics engine, that's why you don't see any credible comparison charts. If you do see any charts, they're not to be trusted, including the one posted by Agent_J. The speed of physics engines is mostly dependent on the accuracy level used in the simulation. To test the speed of JV-ODE, I would suggest downloading the demo version if you haven't already. Then tweak the cubes demo to drop 800 cubes, but make sure they don't all drop from the same place or you'll get a stack overflow error due to too many overlapping collision zones. It would be interesting to see the results :) ODE is quite different to PhysX, so play around with the demos until you're comfortable it's the right engine for you. Obviously not all features are available in the demo version but if you have any more questions feel free to ask. |
| ||
| Hi VIP3R, Im just starting to use your wrapper at long last. I loved playing with the demos. Anyway I was thinking I would like to have a flag attached to the back of my tanks. The flag would be on pole coming out of the back of the tank (to help identify team members). Hopefully the picture below will better explain : For Picture Click here! Is it possible to make the pole body in JV-ODE. Ideally I would like it to lean back when the tank is moving forward and spring back and forth when it stops. I've looked at the rope demo, but I don't think this is the way to go. Here's hoping you can give me some clues. Cheers, Unc |
| ||
| Hi Uncle, Yes you should be able to create a flag pole, I'll explain more in a moment. Before I do I'd like to give you a few tips to help with the jitter issues etc. I'm guessing you're using TriMeshes for the objects in the tank demo, so please correct me if I'm wrong. At the moment TriMeshes are still a little unstable for moving objects IMO, they're much more suited to static scenery like a terrain. The best route to take is to build up a complex object using multiple 'primitive' geoms, for example the tanks can be made up using a couple a cubes and a capped cylinder for the gun barrel. This is done using Geom Offsets, there are some demos included with JV-ODE showing this feature. It is basically several geoms attached to a single body. There is also a huge benefit to taking this approach, because primitives will be processed by the engine much faster than TriMeshes. It will also instantly remove those odd TriMesh collisions and twitches. Other things that can help with twitchy physics are adding some (more) mass, changing the CFM value and adjusting the collision depth. Other than the mass, you might not need to touch the other settings when using primitive geometry though. Ok, the flag pole can be created using several jointed capped cylinders. It would be similar to the rope demo except for the ball joints which aren't suitable. Here's a modified car demo with a flag pole to give you an idea how it would work, I've used hinge joints here... If you have any questions regarding the above demo or for JV-ODE in general, please feel free to ask :) |
| ||
| Thanks Vip3r, That demo it pretty neat. You're right, I am using trimeshes in my demo. It was just a quick and dirty way to get things moving to test my library. However now I will have to focus on really setting up the physics correctly. I read through how to set up Geom and will have a stab at it over the coming week. Cheers for the your help :) |
| ||
| Hi Vip3r, I've developed a server/client application in Blitz3D, I am hoping to implement a second rig (maybe even more) on my endzone truckin posted higher up. The way I envisage doing it is having a 'server' managing the position of both trucks within the environment. My Server will accept move input from one or many clients and pump out the x,y & z co-ords of each connected client to all clients. The clients will adjust the location of each truck in accordance with the info pumped out by the server. From discussions on this matter I vaguely appreciate that each client may be storing velocity/directional information as opposed to specific x,y & z parameters at every instance. If this is the case I suppose I may need to exert force on my 'rigs' within the clients to get them back towards where the server reckons they are. I've removed the images from higher up to de-clog your thread. I located this thread: http://www.blitzbasic.com/Community/posts.php?topic=69370#775928 , how relevant is this to JV-ODE ? My code is for LAN only... at the moment. I like the card demo with the aerial, I might add an aerial to my Rig. (;-) Any thoughts you have regarding potential stumbling blocks greatfully appreciated, regards, Blitzplotter. @Uncle, I like the look of your tank (;-) |
| ||
| Hi Blitzplotter, I've no experience in networking ODE so I'm not much help tbh. The most difficult part is going to be updating position/rotation/velocity of physics objects on each client. You could try zeroing all forces/torques on objects and move them manually, then re-apply the forces/torques... but I don't know how well it would work, it might upset the simulation too much. The other option is as you say to guide the objects back to the correct coords by exerting forces, not an easy task by any means. Another option would be to have the server send the player control signals to each client (as kronholm mentions in the thread you posted). It should be fast enough on a LAN, but might start lagging on the internet, meaning the above will still need to be implemented to correct the coords. You could also check the KODE and RakNet threads from the Blitz user KuRiX (he posted a few posts up from this one). Kuri has done some work with networked ODE physics I believe, if he's still around he might be able to help guide you. Those threads may have more information in them too. |
| ||
| Another option would be to have the server send the player control signals to each client (as kronholm mentions in the thread you posted). It should be fast enough on a LAN, but might start lagging on the internet, meaning the above will still need to be implemented to correct the coords. Thankyou for this suggestion, I'll use this concept as my first stab. With just control requests going from client to server, then the actual control signals being fired back to the client it will be interesting to see my separate rigs trying to crash into each other on my fort block - on separate computers. I'm using TCP at the mo with 512 byte packets, I can really slim down my packet size now, maybe 30 or 40 bytes tops. I note that TCP uses 96 byte header in B3D as opposed to udp using 64 bytes?... regards - BP. |
| ||
| Hi Viper, me again :O) Ive been continuing on with my car game, its going well but my car skids to often so i setup a if statement so i could change the worldfriction# varible in the game, I increased it and there was little or no effect? Ive tried setting it at 2000 and it has no effect on the car. what am i doing wrong? Is there a friction for the cars tyres? how does friction work? ive had a look in the docs but couldnt even find any friction comands? Pete (EDIT) oh you can't change it on the fly? What other varibles can't be changed in game? |
| ||
| Hi Pete, It's ok to change friction on the fly, the only things you shouldn't manually change are the position and rotation of objects. It sounds like you're using 'Geom' friction for the car wheels? (which is the correct way btw)... 'Geom' friction will over-ride whatever value the 'World' friction is, causing the zero effect. To change it while the simulation is running you need to be tweaking the 'dGeomContactSetMu(geom,friction)' values for each wheel geom. You can leave the world friction at some value for all of the other objects, any object that doesn't have the geom friction setup separately will use the world friction value by default. Let me know if you need more help with it :) |
| ||
| ok ill give that a try, thanks vip3r. |
| ||
| Hi vip3r, managed to get a server running on one computer, started a client on another with the client successfully sending control requests to the server, the server replies with the control info and the remote client runs quite nicely. I've a little hiccup whereby 2 clients running at once causes a freeze but Rome wasn't built in a day........ |
| ||
| Sounds promising :) |
| ||
| found my bug... onwards an upwards. Just strip out my debug and hope the extra delays associated with them were not resolving the TCP/IP chatter bother. Two clients connected to a server, sending control requests and recieving control information (;-) |
| ||
| I think almost there on this one, just need a little help filling in the remaing gap. I have an asteroids clone, I want the rocks and the player to bounce around, got this working. I also want to hand out "damage" to the player/rocks based upon impact forces. I have the asteroids stored in a type. So my presumptions, Each collision is stored in the jointgroup assigned in the dspacecollide parameters? I can access the impact data from each collision using the djointgetfeedbackforce commands? I can determine which asteroids are effected from the djointgetbody command? The gap I appear to be missing is how to search the jointgroup? Is the jointgroup a type, or an array, or somthng else? |
| ||
| The collision data is stored within the geom object itself. You can use Joint Feedback to determine collision forces, single objects like your asteroids will need another smaller body added with a fixed joint. When it collides, the joint will 'stretch' depending on the strength of the collision, this is measured using joint feedback. The 'Demo-CollisionForces' demo included with JV-ODE shows it in use. Using the dJointGetBody function would work ok, or you could check which geoms have collided instead with the detailed collision data. A joint group is just a hierarchy of joints and sub-joints, in the same way as you have spaces and sub-spaces. The dJointGroup related code in the demos is purely for handling the contact joints (ContactGroup) per step, no other joints are grouped. |
| ||
| with just sending control requests wouldnt any latency make a control be out of sink on the different machines, say a cars driving forward, it has a split second to turn to avoid a crash, so the client turns, but the message in the time it takes to get from client 1 to client 2 doent turn, when the packet arives the car turns but it maybe that little bit to late to miss the object. or does the simulation wait if theres no message. well this would give me a big headache. good luck |
| ||
| It should be responsive enough on a LAN, which was the suggested use. Not suitable for wider networks. It won't interrupt the simulation, just as detecting a keypress wouldn't. |
| ||
| yes on the LAN initial results suggest it may well be responsive enough as long as the maximum packet size is not too excessive AND there isn't more than say, 50 or so on the LAN. Time will tell..... just fine tuning the hacked together code now.... |
| ||
| My second truck has landed, with wheels still on... the first truck is moving via control requests via TCP/IP to a server which in turn feeds the control requests back to the client resulting in movement of truck 1. Just need to implement logic on tying the camera to truck one or two dependent on 'truck/client' number and voila multiplayer trucks via Wings TCP/IP code and JV-ODE. Took me 2 mins to glue my wheels onto truck2, simply needed a setuptruck2 function. JV-ODE is great! Link to image: http://www.blitzbasic.com/Community/posts.php?topic=76772 |
| ||
| Hi Jim, How can I FREE Trimeshs during the gameplay ? (I'll need to Load and Free Trimeshs during the game) |
| ||
| Hi EmerGki, Use 'dGeomDestroy(trimesh)' to free a TriMesh. @Blitzplotter: Coming along nicely :) |
| ||
| have discovered niggles with my TCP/IP code stroke different workstations operating at different speeds... too many issues for an indy/hobby coder to resolve. Its not all black though, I've discovered a way of recording input from a user that can be recorded aka racing game replays, then potentially use this for AI 3d ODE competition with way markers within the code to restart AI cars if need be. |
| ||
| Would UDP work better? TCP has given me problems due to the fact it halts program execution, it needs to run in its own thread ideally. UDP doesn't suffer from this problem in Blitz3D as far as I'm aware. Have a look in the programming forum, there's a fair amount of info on these two types of networking. |
| ||
| thanks, will consider udp as an option. |
| ||
| hi there! thanks for your mail response viper! now i got --- 1) is there a way of limiting the movement of the hinge2 axis1? if i set a quite high SuspensionCFM for the joint to achieve a nice bouncy wheel suspension, the wheels are falling quite a lot away from the body when the car is in the air. something like a max- and minoffset for this axis would be ideal... also is there a possibility the GET the offset axis1 has currently? couldnt find any answer to this in forums or the google group :/ --- 2) and while im at it: another issue i got with the hinge2 is, that at relatively intermediate speeds cars are beginning to break out quite easily. i tried several tricks which can be found on the net (including playing around with erp and cfm values, different steppings, setting FiniteRotationMode to 1 and so on...), but no one solved the problem completely. its a bit better now, but still not gone. i didnt integrate materials yet, so maybe adding better friction values to each body will make it even better. but, maybe you know of another trick i could play with to make our cars drive more stable :) --- 3) ok, one last question, then its enough for now ^^ currently im using just one space for everything. the problem i can see is, that even the car wheels are colliding with the car bodies. i believe this is not good :D but, how can i achieve to collide car bodies and wheels with everything (different car bodies with wheels of other cars too!), but NOT let the wheels and body of ONE car collide with eachother? i know its possible to deactivate the internal space collision, but with this solution i would need one space for EVERY car in the game...doesnt sound optimal to me :/ is there another possibily? some kind of 'blacklist' of which bodies are forbidden to collide with eachother? --- btw: thanks for your ongoing and restless support, probably the best 20€ i ever spent :) |
| ||
| No problem, thanks :) 1 - There aren't any parameters to set a lo-stop and hi-stop on axis 1 of the hinge2 joint unfortunately. You could try dJointGetHinge2Angle1Rate(joint) to get the current offset, this may return a value since its last position (rather than the starting position) I can't recall. 2 - When wheel joints start breaking it typically means the joint accuracy is spiraling out of control. Using high mass or friction values will amplify the problem. The best solution I've come across is to split up the time steps, thus improving the accuracy. 3 - Directly jointed bodies in JV-ODE will not collide with each other. If your wheels are colliding with your car bodies, you must be using a more complex car model. For example... Wheels <-1-> Chassis <-2-> Car Body 1 = Hinge2 Joint 2 = Fixed Joint In the above design, the wheels will not collide with the chassis, as they are attached to it. However they will collide with the car body, because they are not directly attached via joints. The best solution for more complex designs like the one above is to place each car in it's own sub-space and disable internal space collisions. You shouldn't notice any difference in performance as it splits them up internally anyway, it may even run a tiny amount faster as you're no longer checking for collisions between the car and its components. |
| ||
| 1) ok, think ill try to get the offset from the blitzmeshes (since the original position is known to the engine) and apply counter forces if need be. this may simulate springdamping as well... 2) yeah i've already done that. using the setup you provided in the samples: some users reporting slight jerks every some seconds, but that might not be an ode issue. do you see any problems with this mainloop? 3) didnt know attached bodies automatically dont collide...cool! no, we're using the most simple car model: body + 4x hinge2 + 4 spheres for the wheels. thats absolutely good enough for our purposes... :) but if you think it gets even faster (currently getting ~5-10ms physicstime for 100 active cars, final game will feature ~20-30 active cars so thats perfectly fine already) with every car in its own space and there arent any problems with >50 spaces, then ill try that too. ps: dont get me wrong: the simulation is quite stable and is looking really great already, i just want the most accurate solution possible :D |
| ||
| Sure, perfection is worth aiming for :) Regarding the main loop, you need to separate the physics code from the 'If k=ticks Then' condition and place it either at the top of the main loop or immediately before the 'RenderWorld tween' call. Otherwise the render timing will interfere with the physics timing, depending on the framerate this could potentially cause noticeable jerks. |
| ||
| yes you're absolutely right about the mainloop...should have seen this myself *rolleyes* im still mixing up, which part gets the frame limiting and which not...maybe i have to write it down to remember: renderworld runs UNlimited. gamelogic runs LIMITED. ok, lets see if it works ^^ so i moved the physics update out of the inner loop. unfortunately i cant see any difference on my system, so ill have to wait for testers feedback to see if it solves the jerks issue... anyway...thx for your answers :) |
| ||
| You're welcome OJay :) Let me know if there are still issues with it. |
| ||
| get cover, its me again :D no seriously: i got an issue with dGeomGetData(). am experiencing random crashes with "memory access violation" if that function gets called; even with debug enabled. testers also reporting these random crashes, and i think i can pin them down to events that call this function. could you please countercheck, that is everything ok with what happens in there? the geoms im passing over to it seem to always be valid... im using this to store the ids of type instances (created with "handle(typeinstance)"), respectively simple 4byte integers. might this be wrong? the official ode reference states that this can be used to store "user-defined data pointer", so a 4byte int should be very ok, shouldnt it? or is calling this function only allowed if actual data was stored in there before, as this might not always be the case in my current solution...but then, shouldnt there be a function to check if there's data and its save to call getdata()? as a side note: i still couldnt win the challenge regarding "limiting the springtravel of hinge2 joints". i can successfully retrieve the current extend of the spring, but had no success with stopping the motion of it. i tried e.g. applying two equal forces (one down on the chassis, one up on the wheel) but that didnt work out as expected. at the moment this got low priority, so im not that concerned right now about this....but still is an issue that has to be solved sooner or later...so, i would be grateful for any ideas you got what i could try :) |
| ||
| Hehe :) Yes the user-defined data pointer is a 4 byte integer. There are two possibilities for receiving MAVs from dGeomGetData(), one of which you've correctly pointed out - they have to be set before you can get them. When you're returning the user data without it being set beforehand, you're returning and using an invalid pointer hence the MAV. I agree it would be convenient to make the function failsafe, the problem is differentiating which have been set and which have not. The reason for this is that they're added to every geom, whether or not they've been set and they always contain a random value (whatever occupied that memory location previously). Zeroing them upon creation to indicate they're not used is one way to achieve it but this would be a bad idea IMO. Another is to declare them to be Null, but his can't be returned to Blitz so you would need a unique custom function to check the status, for example dGeomCheckData(geom) to return zero or one depending on whether the user data is Null or not. There's no built-in provision for this in ODE which is why it was never considered for JV-ODE. It can certainly be added to JV-ODE, but adding/setting a flag to your ODE type and checking its state would work equally well. The other possibility for a MAV from dGeomGetData() is deleting the geom itself and then trying to return the user data, which gets destroyed along with the geom and therefore no longer exists. Regarding limiting of your spring travel, you could try adding physical 'stops' with extra geometry. It depends on your car/suspension design whether that would be viable though. If I come up with anything else I'll let you know. |
| ||
| holy shizzle, that explains alot! will add a flag to my type of course. so wether this is a bad or good behaviour it should be documented somewhere! maybe adding a big red note next to the function in jv-ode reference or something... this takes me to another topic: error handling. it happens quite regularly that i get confronted with several nice unmeaningfull "internal ode error", than "ms visual c++ runtime error", than "unknown software exception in blitzcc.exe" and than again an "ms visual c++ runtime error / abnormal program termination". this is annoying and sometimes i havent any glue as where this madness was caused from ^^ in c++ i would add my own exception handlings, but this is not possible in blitz3d. yet alone those blitz MAVs are delightful enough, but adding another possible mysterious popup message looks quite unprofesional to the enduser. so just as a dumb idea: what about an error handling system in jv-ode? functions like dLastError$(), dErrorCount%() and dGetError$(num) and maybe (to make this optional) a dEnableErrorHandling(enable%) would be a dream! and of course those ode runtime errors would have been catched properly...maybe you could think about it someday ^^ so you suggest adding additional geoms to the chassis which limit the wheels freedom...sounds vicious :D but, how could i make those geoms collide with the wheel only and (of course) NOT with ANY other geoms in the environment? i bet, this is what dGeomSetCategoryBits() and dGeomSetCollideBits() where made for. sincerly the ODE manual isnt very specific on how to use 'em... |
| ||
| The error handling is provided by ODE itself and the error message content is dependent on whether the cause is known. Sometimes it will give a generic error message (the same as MAV in Blitz), which isn't too helpful. In other cases it should give a better idea where things went wrong. For example if the error occurred in an ODE joint, it will normally state 'blah blah... error in ode/joints.cpp' or similar. There is no way for JV-ODE to directly retrieve the error information from ODE, unless ODE provides the functionality to do so. Ouch, I didn't mean adding geoms to collide directly with the wheel geoms, sorry I should have explained a little better. [Edit x2] The more I think about this the more I'm wondering about how much the car and wheel mass is affecting the hinge2 travel issue. Have you experimented with different mass values for both the wheels and the car body? |
| ||
| yes we already found chassis masses and spring strengths, that made the spring act almost limited and only moved to far up/down on extreme cases (jumps in midair and the hard landing for example), so this was nearly perfect. though that limited the softness of the spring quite a lot. e.g. we have a buggy, that needs really soft springs but the wheels shouldnt overlap the chassis and the chassis shouldnt hit the ground... but, lucky me, i got your previous suggestion with the additional slider joint before you edited it out ;) that didnt work out in the first place, since a slider joint doesnt allow the attached body (wheels in my case) to spin/steer. so i added another placeholder body to the slider and attached another joint (ball this time) between that temp body and the wheel. and now believe it or not: this works perfectly and absolutely stable, yikes! setting two different joint settings to the same bodies gives some headache though...feels somewhat hackish...but there where no issue reports by the testers till now so i assume ODE excuses the hack ^^ and btw: no random crashes happened, since i added the check for user data into my code ;) so thanks again, now im really happy with the solutions and im getting excited every day, what our artists do with the physics system :D |
| ||
| Ah, excellent. Part of the reason I removed the suggestion was because I realised it wouldn't allow rotation, resulting in the need for an intermediate body. I was saving it for the next suggestion as it wasn't very straight forward, but you caught it anyway :) Let me know if you need help with anything else. |
| ||
| hmm...yes one small issue remains, if you want one ^^ well, its less an issue than a need for clarification, at least i know WHY this happens, but found no solution/workaround yet.. so, let me explain: in our game, cars can be destroyed. if that happens, the original car with its complete structure (meshes, ode-bodies/geoms/joints, type instances etc) are getting removed from the game. at the position + rotation of the original car, a new entity gets spawned, we call them 'wreckages'. those little beasties consist of nearly the same geometry as its original entity, but split up into several pre-broken meshes (like the wheels, chassis, doors, spoilers and so on...) which are independent each of its own without any joints or the like limiting it. then they get some random forces + torque applied (transformed from the center to the outside) so they explode nicely and all those debris are flying around (may well hit other stuff + shaking/damaging it etc). the geoms of most of the debris are made of simple native classes from ode (mostly boxes, but also capsules or spheres) and a few of them are trismeshes, e.g. the wheels need trimesh geoms, just because there is no builtin flat cylinder class...so far so good. now for the interesting part: the debris using trismesh geoms are coming to rest perfectly, getting disabled and just waiting till their lifespan is over, causing nearly no additional computing time. but the NATIVE builtin geom classes, especially boxes, sometimes are never getting to rest and jitter around a few thousandth of a unit. this happens if they are lying on a complete flat surface. i tried several things, including manually disabling or increasing damping values for them, with absolutely NO success. those nasty boxes are jittering around till they get removed from the game, causing severe slowdowns in larger battles (with ~20-30 wreckages). the only thing i could do at the moment is, decreasing the lifetime of the debris to only some seconds, but this bugs me, because i want to see at least expanse of ruins if i lost all my cars already ^^ and i think i know why this happens: its because contact joints are getting created over and over for them, enabling them on every step the simulation takes...am i right? what to do about it? any tricks left in your drawer? :D eek, there goes another novel... |
| ||
| Yep, you're right about the contact joints theory :) Changing the contact collision depth will eliminate most jitters with boxes, allowing them to come to a rest and auto-disable quickly. To change it use the following function, experiment with the depth to see what works best. The default depth value is zero (no penetration), a value of 0.01 should do the trick but keep it as low as possible... dWorldSetContactSurfaceLayer(world,depth#) |
| ||
| i cant believe it...one function call...problem solved. nice. ^^ i already thought about a way of detecting jittering bodies and do the most evil things with 'em :D ODE is just cool...cant wait for the new features...automatic damping, trimesh-mass-calculation, heightfield-geom...to name just a few...hope they get it stable as soon as possible :) |
| ||
| JV-ODE V1.26 Update Released Please check your inbox :) JV-ODE is now compiled using ODE V0.9 which includes a vast amount of fixes and tweaks. You can view the ODE changelog for specific details here. Added new functions: dJointSetBallParam(joint,param,value#) dJointGetBallParam#(joint,param) dJointSetFixedParam(joint,param,value#) dJointGetFixedParam#(joint,param) dMassSetTriMeshTotal(mass,totalmass#,geom) Please let me know if you experience any problems with the new update. :) |
| ||
| Thx ;-) |
| ||
| Outstanding! Thanks! |
| ||
| wow, this was unexpected \o/ nice bday present, thanks! :D im currently done with the physics stuff, so ill get around to try out the new release just after our next milestone...will of course report all issues then =P hm...one thing i notice: the damping functions (world + body) are not wrapped, arent they? |
| ||
| Thank you again VIP3R - another great update. cheers, Mark |
| ||
| You're welcome :) @OJay: The damping functions are not available in ODE V0.9, they're in ODE V0.10. I've already started testing JV-ODE with ODE V0.10, but I need to make sure it's stable before integrating it (there are a couple of issues at the moment). |
| ||
| ah i see...the ode changelogs are a bit overwhelming ^^ never mind :) |
| ||
| Hi Vip3r, Sorry this is a tiny off topic. Have you given any thought to offering JVODE / BlitzMax customized for Leadwerks 2.1? The reason I ask is LW2.1 is seems to be struggling some with implementing newton, and lacks many examples. I purchased Newton for b3d (itembin) a while back and it rocked, mostly because it was implemented like you have done with ODE, and there were many example just like JVODE. I ask myself why Itmbin can do such a great job with b3d, and LW struggles, perhaps this would be opportunity for JVODE BMX version. Perhaps you would customize a demo or two, and explore the possibilities, since you already have bmx code. Yes, I probably could do it myself, but I'm new to Bmax, would waste bandwidth asking lots of questions, and would rather learn from the master. 8 ) |
| ||
| Sure, I'll look into it :) I will have a chat with Josh and see what we can do as I don't currently own a license for the Leadwerks engine. |
| ||
| JV-ODE V1.27 Update Released Please check your inbox :) Added new functions: dInitODE() dBodySetAutoDisableAverageSamplesCount(body,averagesamplescount) dBodyGetAutoDisableAverageSamplesCount%(body) dBodyGetWorld%(body) dCreateConvex%(space,planes,planecount,points,pointcount,polygons) dGeomSetConvex(geom,planes,planecount,points,pointcount,polygons) dMassSetTriMesh(mass,density#,geom) Notice the dInitODE() function? At one time it was obsolete so was never added to JV-ODE, however it will become mandatory in future versions of ODE. It's still optional in this release but it would be wise to start adding it to your code. If you're using the Blitz3D version of JV-ODE, it has already been added for you at the top of the JV-ODE include file. If you're using the BlitzMax version of JV-ODE, you will need to add it to your code yourself. Another function which had become obsolete has sprung to life again, the dMassTranslate() function is now supported again in JV-ODE. We also now have Convex geom support, don't forget it's new so I'm not sure how stable it is yet ;) Please let me know if you experience any problems with the new update. :) |
| ||
| Thank you for this new update. Keep up this good work |
| ||
| You're welcome :) THREAD 10 IS ABOUT TO CLOSE Please continue on the new thread located here Thanks :) |
   |