JV-ODE Physics Thread 6
Blitz3D Forums/Blitz3D Userlibs/JV-ODE Physics Thread 6
| ||
| Now available for Blitz3D & BlitzMax (Win32) The JV-ODE Physics Wrapper is an advanced user library supporting almost all of the Open Dynamics Engine functions wrapped inside a DLL (Dynamic Link Library). The library can be used with any programming language that supports DLL's, including Blitz3D and BlitzMax (Win32). The Euler rotation system in JV-ODE has been adapted to match the left-handed Euler rotation used in Blitz3D, however functions for accessing Quaternion and Axis Angle rotation systems are also included. The full versions contain all of the necessary files to get you started, including over 30 demos showing the various features found in ODE and a complete Function Reference document. The BlitzMax (Win32) version also features a built-in 'bare-bones' OpenGL 3D engine module and B3D mesh loader module for demo purposes. To view more information and screenshots click here. Options are now available to purchase the wrapper using either PayPal or Share*it. The Blitz3D restricted demo version is now available for download here (169KB) The BlitzMax (Win32) restricted demo version is now available for download here (238KB) Have Fun :) Previous JV-ODE Threads: 1 2 3 4 5 JV-ODE Player Factory Forum Useful Links: ODE.org Website - ODE User Guide (PDF) - ODE User Guide (HTML) - ODE Archives |
| ||
| cannot seem to get collision with trimesh, sphere seems to be colliding with non existant tris. |
| ||
| If you post (or send me via email) the problematic code including the mesh, I'll take a look for you. What mesh format are you converting into a TriMesh? |
| ||
| same prob happens with *.x and *.b3d, emailed ya |
| ||
| Thanks for sending it :) Ok, the mesh appears to be colliding correctly. I think you may be getting caught out by the mirror here, if a mesh is positioned lower than the mirror/plane, the part that's submerged appears as an inverted solid mesh above the plane level. Try the following code with the 'CarDemo-TriMesh-Sphere.bb' demo and add your mesh to the media folder to see the mesh colliding correctly... |
| ||
| thing is, there is no mirror in what im trying, its like there is some invisible plane blocking it (but there isnt in code) |
| ||
| Well, I'm having to speculate as there wasn't any code in the archive you sent over, only two mesh files. I can't find any problems with those two meshes, the mirror was the only obvious cause that springs to mind. Can you resend the meshes with the source code (or an example) so that I can see the exact problem? Your TriMesh sounds like it isn't aligned with the visible mesh, but without seeing your TriMesh setup it's hard to say for sure what's causing the problem. |
| ||
| it seems to work if i dont scale the mesh down, (btw i thought i sent code) but it seems ok if i dont scale.. so i wont edited: was using scaleentity instead of scale mesh on pieces i was cloneing, changed to scalemesh fixed it |
| ||
| Yep, you need to use ScaleMesh. The CreateTriMesh() function uses the source mesh dimensions for its own scale, ScaleEntity doesn't change the actual mesh structure hence the mis-alignment. In your case the visible mesh would be scaled ok, but the TriMesh would be the same size as the original source mesh dimensions prior to re-sizing. I didn't receive any code in the archive, only the two test meshes. I could've saved you some head-scratching if I saw your TriMesh setup code, oh well at least you've cracked it now :) |
| ||
| Hi, The ultimate RagDoll :-) http://www.planetdan.net/pics/misc/georgie.htm Use the mouse |
| ||
| erm, cannot seem to return if a collision has happened on a geo, any ideas? DebugLog dGeom1CountCollisions(MainPlayer\PhysEntity\Geom) |
| ||
| ok ZJP, now do that in blitz+ode ;) btw: ^^ [a http://user.blue-cable.de/ojay/ups.JPG] sorry vip3r, you're damn right :D |
| ||
| Nice RagDoll considering it's made in Flash :) OJay, can you either shrink or remove the image please, it's too damn ugly :P [edit] Thanks ;) erm, cannot seem to return if a collision has happened on a geo, any ideas? DebugLog dGeom1CountCollisions(MainPlayer\PhysEntity\Geom) Well, going on the incredibly detailed explanation of the problem, I can deduce that 'MainPlayer\PhysEntity\Geom' isn't a geom class or it doesn't exist :P Does it give any error or return a constant zero? Are you using single or multiple spaces? Have you tried 'dGeom2CountCollisions(MainPlayer\PhysEntity\Geom)'? Have you tried the 'CarDemo-DetailedC.bb' demo? The more info you give, the better and faster the solution ;) |
| ||
| Can someone please provide an example of a slider joint? Something like a cube on an invisible bungey cord that drops under gravity but is pulled back by the slider joint. According to the docs there's no dJointSetSliderAnchor() to position the joint, and I can't get the params to do what I thought they'd do. My slider works just like a rigid Fixed joint :( |
| ||
| Here you go Shifty... The demo shows how to setup the slider, it doesn't have any spring/dampening yet though. There's no need to specify an anchor position for a slider, it actually has two anchors - anchor 1 is positioned at body 1, anchor 2 is positioned at body 2. |
| ||
| Many thanks. I was trying to attach the Slider to 'the world' with an object on the other end. Adding bungy-bounce was easy enough (dParamBounce). Of course, now I have to think how to create this in my limited joint description system. It's not straightforward referencing a body in a linked-list ;) |
| ||
| any idea on the best frame limiting method? tried out shiftys stuff in another post but it doesnt really work all that well, erm someone must have a solution |
| ||
| The best method is to use a fixed frame speed (30-60 fps etc) for the physics and separate timing for the rendering. Here's a 10 Pin Bowling demo for Jeff... |
| ||
| any idea on the best frame limiting method? tried out shiftys stuff in another post but it doesnt really work all that well, erm someone must have a solution My code was actually about getting the same physics timing with different screen refresh rates. It doesn't help keep things smooth.What's wrong with your system? The only way to really get smooth, constant framerate is to ensure your rendering and updates are completed within the time of a frame. If you split rendering and physics timings, at some point they're going to be executed at the same program cycle and you'll need to render both. If the processing takes longer than a frame you're going to ruin the smoothness. By my reckoning, if there's going to be occassions where physics and rendering are rendered simultaneously, to get that framerate smooth I need to keep physics+render < frametime for those frames. And if I can manage physics+render < frametime for those frames, I can amange it for all frames. Hence in my program I lock to the screen refresh and keep everything executing in 1 screen refresh period (about 16 ms at 60 Hz). Things like frame tweening allow you to calculate only some frames and interpolate the rest at less overhead. I guess in theory it would be possible to render graphics on one frame, update physics the next tweening the graphics, giving more time for processing yet keeping a 60 fps update, though physics would be less accurate. Otherwise, there's no real solution that I know of. I've yet to find a professional full-price game that doesn't have slowdowns and poor framerates at times! |
| ||
| The term 'frame limiting' would imply that there is enough processing time per frame for at least one pass of the physics, rendering and logic. Frame limiting is used to prevent the physics/render/logic updating too quickly on faster machines than the minimum requirements. Let's assume we have our game loop frame time split as follows: Logic: ~3 fps Physics: ~7 fps Rendering: ~50 fps Total: ~60 fps (minimum design framerate) Limiting the frame speed to 60 fps will work fine here on all machines except those which cannot reach the minimum design speed of 60 fps, then we get the poor frame rates. The only time you will benefit from separate timing is if you have redundant processing time available during each frame update. If a machine has a refresh rate of 85Hz in the above situation, we will have 25 fps free per frame to update the rendering or process more logic. But not the physics, which -must- run at an identical frame rate on both the 85Hz machine and the 60Hz machine for the simulation to remain accurate and consistent on both machines. If you need the physics to run faster or with increased accuracy, you will have to sacrifice render/logic frame time, like so... Logic: ~3 fps Physics: ~7 fps (two passes at 7 fps or one at 14 fps) Physics: ~7 fps Rendering: ~43 fps (minus 7 fps) Total: ~60 fps (minimum design framerate) You can't process the physics during any spare frame time available on faster machines, because it simply defies the minimum requirements of the design. It would mean the physics will never run at full speed on the 60Hz machines. In a nutshell, the physics MUST run at a constant frame rate, regardless of render/logic timing and free processor time during a frame. But most importantly, the physics MUST be able to run at full speed (whatever it is) at the minimum design framerate. |
| ||
| I think that dBodyDestroy command doesn't remove objects from the world. How do I remove objects from the world? The ball and the pins that were knocked down should be removed before the next roll of the ball and all pins should be removed and 10 new pins set up before the next frame of the game. In Frame 10, you get three rolls of ball if you get a spare or a strike. |
| ||
| You can't process the physics during any spare frame time available on faster machines, because it simply defies the minimum requirements of the design. It would mean the physics will never run at full speed on the 60Hz machines. In a nutshell, the physics MUST run at a constant frame rate, regardless of render/logic timing and free processor time during a frame. But most importantly, the physics MUST be able to run at full speed (whatever it is) at the minimum design framerate. Which is where my physics timing method works, where the game is 'frame-limited' to the refresh rate. I guess I'm not really understanding what {cYanide} wants. If he's not capped to VWait : Flip, he ought to be to frame limit and keep things smooth and at a constant speed. If he is capped to frame rate and not processing quickly enough every frame so some frames overrun the wait and you get jitters, the only fix I know of is to reduce processing requirements, or cap to a sub frame-rate at say half the screen refresh rate. What other options are there? What's the problem {cYanide}'s having? |
| ||
| i ended up just forcing the physics to run at a certain "fps", works fine, erm one more Q, ive noticed that when 2 or more trimeshes are overlapping the physics time goes rather high, im not really sure this is, as i wouldnt expect trimeshes to be tested against eachother... if thats even whats happening. is there a way to stop this as currently i have to position my map pieces with a lil gap (visible) so it wont inc the phys time like mad |
| ||
| Assuming for trimeshes you mean static scenery, drop them into a subspace and disable internal collisions for that. ODE_world=dWorldCreate() ODE_space=dHashSpaceCreate(0) ODE_scenery_space=dHashSpaceCreate(ODE_space) dSetInternalSpaceCollideMode(0) And create your trimeshes in ODE_scenery_space instead of ODE_space. Create your moving objects in ODE_space so they collide with each other. |
| ||
| that did it;) |
| ||
| I think that dBodyDestroy command doesn't remove objects from the world. How do I remove objects from the world? The ball and the pins that were knocked down should be removed before the next roll of the ball and all pins should be removed and 10 new pins set up before the next frame of the game. In Frame 10, you get three rolls of ball if you get a spare or a strike. You don't need to destroy them, you can re-use them by resetting their position and rotation. When you destroy an ODE body or geom, you must also delete the ODEGeom type objects associated with them (ode\body, ode\geom etc). Btw, where did you learn your manners? because you need a refresher course. the only fix I know of is to reduce processing requirements, or cap to a sub frame-rate at say half the screen refresh rate. Exactly right, the code either needs streamlining or you have to settle for a lower design frame rate. Your alternative timing method is one of the best I've seen so far, but the simulation would suffer from inconsistency across different frame rates ;) |
| ||
| Okay, I see what you're getting out, having experienced a frusting couple of days. With my ODE scaling system, ODE progresses at the same rate on different refreshes, but my custom force functions applied every frame were of course running at different speeds between systems. I've just implemented a straightforward tweening system and it works very well, with the same smooth framerate as I was getting before, yet with physics locked to 50 Hz regardless of system, (50 Hz is every 20 ms, which can be measured properly unlike 60 Hz's 16.666667 ms and won't exceed one update per frame) I'll write a proper explanation later in the Tweening thread. |
| ||
| I've ran against a wall with my current project and hopefully one of you can point me the right direction. I need no ready solution, just some ideas how to do it. Here's the scenario: Plastic coins (Cylinders,2x1) dropping into a 'slimy'/high viscosity fluid(Plane). The coins should penetrate the fluid/swim in it. If two coins collide (one dropping onto another), they should slip off each other (better: the bottom coin should dive a bit into the fluid and then evade to the side while the upper coin slips into the fluid). I experimented a lot with Soft-ERP/CFM, but no matter what I do, either the coins do sink or bounce off with high speed. Any ideas what contactmodes are best for the coins/plane ? Thanks in advance Jake |
| ||
| Have you tried using a box for the slime instead of a plane? The plane might be too 'thin'. It might also be due to incorrect mass/density of the coins/slime. Another thing that could cause problems is the ODE dCylinder geom, when two cylinders are dropped directly on top of each other (end on end, like a stack of coins) it can create faulty contacts causing them to fly off at high speed. The dCylinder isn't part of the original ODE library (like dCCylinder), so its reliability is suspect. |
| ||
| CFM probably isn't ideal as there's a limit on penetration. You'd probably be better off writing your own force routine where if object is in fluid, apply force upwards greater than gravity. |
| ||
| This dCylinder problem is exactly what happens. I'll give CCylinder a try, though this will make collisions appear inaccurate. Maybe I could stick to dCylinder and try to limit this "Fly off" manually. If I manage to get this stable I will let you know and post an example. This could take a week or two due spare time to code. Jake |
| ||
| CCylinders won't work for coins becausae they have spherical ends. A CCylinder is a Pill shape. If you have to use a coin shape (you can't get away with using thin boxes) your best solution is to use several box geometries each rotated slightly, creating a multi-pronged star (still with a cylinder mesh), or more difficult to calculate placing them around the edge with one in the centre for a 16 edge polygon Cylinders aren't well supported in ODE. |
| ||
| Shifty is quite right, the capped cylinder isn't really suitable for coins due to the semi-sphere caps. Another solution is to add a box geom transform to the cylinder geom. You need to make the box slightly larger in height so that the cylinder 'ends' are covered by the box geom and thus won't generate any faulty contacts. The rim of the cylinder will still generate normal contacts. The box corners can remain within the cylinder rim, there's no need to make it cover the entire cylinder end. Let me know if you need any more help trying the above solution, I can knock you up a simple demo to show this in no time ;) |
| ||
| JV-ODE V1.12 Update Released Please check your inbox :) The new update fixes the dSpaceDestroy() MAV issue reported here Please let me know if you experience any problems with the new update. |
| ||
| Thanks VIP3R, Appreciate your efforts once more. Keep up the good work! cheers, Mark |
| ||
| cool. cool. cool. D |
| ||
| Hi, Received. Good job. Thanks JP |
| ||
| Thanks all, you're welcome :) |
| ||
| VIP3R, JV/ODE can load tri-meshes with a mesh, but I'd like to see example of it loading specified layer of and AnimMesh. Be nice to see this included with JV/ODE to give users little more flexibility in dealing with meshes and terrains. I do have some code laying around to do this so it's not too difficult, just a piece I'd like to see added. Please consider adding this feature. Thanks. |
| ||
| Hi Wayne, I'll certainly take a look at it :) Can you send me the code you mention and the necessary media for testing? |
| ||
| Will get it together and send it. |
| ||
Here it is my code to create full trimesh from animmesh. It should be easy to choose what meshes to export and what not:;-------------------------------------------------; Function KODE_dTriMeshCreateRecursive%(space,mesh%) ; USE THIS IF USING LOADANIMMESH ;-------------------------------------------------; tris_count% = 0 vert_count% = 0 RecursiveCount(mesh) vertices_bank% = CreateBank(vert_count * 4 * 4) indices_bank% = CreateBank(tris_count * 3 * 4) offset% = 0 offset_tris% = 0 baseverts=0 RecursiveAdd(mesh) t_data = KODE_dGeomTriMeshDataCreate() KODE_dGeomTriMeshDataBuildSimple(t_data, vertices_bank, vert_count, indices_bank, tris_count * 3) Return KODE_dCreateTriMesh(space, t_data) End Function ;-----------------------------; Function RecursiveCount(mesh%) ; Add to the Global Values the Vertex and Tris Count ;-----------------------------; children = CountChildren(mesh) If (children = 0) For k = 1 To CountSurfaces(mesh) tris_count = tris_count + CountTriangles(GetSurface(mesh, k)) vert_count = vert_count + CountVertices(GetSurface(mesh, k)) Next Else For k = 1 To Children RecursiveCount(GetChild(mesh,k)) Next EndIf End Function Function RecursiveAdd(mesh%) children = CountChildren(mesh) If (children = 0) For i = 1 To CountSurfaces(mesh) sf = GetSurface(mesh, i) For v = 0 To CountVertices(sf) - 1 v1x# = VertexX(sf,v) v1y# = VertexY(sf,v) v1z# = VertexZ(sf,v) TFormPoint v1x,v1y,v1z,mesh,0 PokeFloat vertices_bank, offset, TFormedX() offset = offset + 4 PokeFloat vertices_bank, offset, TFormedY() offset = offset + 4 PokeFloat vertices_bank, offset, TFormedZ() offset = offset + 8 Next For t = 0 To CountTriangles(sf) - 1 For j = 0 To 2 v = TriangleVertex(sf, t, j)+baseverts PokeInt indices_bank, offset_tris, v offset_tris = offset_tris + 4 Next Next baseverts=baseverts+CountVertices(sf) Next Else For k = 1 To Children RecursiveAdd(GetChild(mesh,k)) Next EndIf End Function Cheers, KuRiX |
| ||
| Thanks for the code Kuri, it MAVs for me though on the following line... For k = 1 To CountSurfaces(mesh) ...any idea why? Here's a See-Saw Ramp demo requested by {Devious}... |
| ||
| Testing some slightly modified VIP3R code to load the full animesh, and will send ASAP, things just taking longer today. |
| ||
| No problem Wayne ;) I've not had much experience with animated meshes tbh, how is each frame stored? Is each frame a set of children meshes to the parent mesh? That's what Kuri seems to be doing above, cycling to the last child mesh and creating the TriMesh from that, is this right? |
| ||
| This is untested: |
| ||
| Viper, be sure to load the mesh with loadanimmesh before calling the function dtrimeshcreaterecursive() That is the only function you should call, the others are helpers to that one. Tell me if it works for you! |
| ||
| Yep, it's loaded with loadanimmesh ;) The function Wayne posted MAVs for me too, it's the Zombie mesh I'm testing it with that's the cause of the MAV by the looks of it. I'm sure I had problems finding children in that mesh before. Have you got any animated meshes I could try Wayne? I don't have any meshes here that would be suitable. |
| ||
| Yes I do, T.ED the terrain editor can create animeshes, I'll whipe up a small one right now. |
| ||
| This code appeared to work prefect for me. All that was required was a few small additions to Vip3r code. I'll post a link to the animmesh right after I try loading just one layer. |
| ||
| This function will load single layer (child) |
| ||
| Terrain Editor (T.ED) created the B3d AnimMesh with each layer being a surface. Example: Dirt, grass, rock.. and the last layer representing the entire terrain. By using the animmesh world builders can process the layers separately and add trees, rocks.. sample code fragment: ; Load animMesh mesh=LoadAnimMesh("AnimTer.b3d") ; Load Last child layer (full terrain) into ODE Trimesh trispace tmesh=CreateAnimLayerTriMesh(trispace,mesh,CountChildren(mesh)) |
| ||
| Excellent work Wayne! :) I'll take a good look at it later, are you happy for me to add your new function to the JV-ODE Wrapper? |
| ||
| There are two functions to use and distribute as you wish. I do have application that tests the two functions, it's a little large but I'd like to send it to you. Be my guest to make any changes and apply the Vip3r touch. If you'd like to see the app let me know what email you'd like it sent to. 8) |
| ||
| Thanks Wayne, I really appreciate your efforts :) I've had a good few hours experimenting with the animated mesh terrain, I think we could get away with the second function alone as it can be made recursive to create a TriMesh for each layer if need be. Also, I've noticed part of the code doesn't appear to do anything on your terrain mesh... +EntityX/Y/Z(GetChild(mesh,child),1)? The child positions are the same as the parent in the terrain mesh, so these functions always return a zero. Are they needed? Can the terrain and texture media you've posted above be used in a JV-ODE demo and included with the wrapper? |
| ||
| Remove the stuff that always returns zero. I replaced the texture set with free ones. I reapplied the textures to the original anim. Here is media and b3d for inclusion into JV/ODE: http://www.bz911.com/postnuke/index.php?name=PNphpBB2&file=download&id=67 Screen shot showing animmesh terrain with new textures. (trees, grass not in this demo, next one) 8)  |
| ||
| Looks great Wayne :) Yikes! how big are those textures :O I need to keep the download size as low as possible, can you trim a few KBs off and re-size them to 512x512 or 256x256? The new CreateAnimTriMesh(trispace,mesh,layer) function will be added to the next JV-ODE update, thanks again for your help Kuri/Wayne ;) |
| ||
| Here's the low fat version: http://www.bz911.com/postnuke/index.php?name=PNphpBB2&file=download&id=69 |
| ||
| Manipulating and positioning ODE bodies I believe it would be most helpfull to have the following B3D functions to manipulate ODE bodies. The functions would operate on the specified ODE body as if it were a pivot. The functions would also act on the attached joints and attached bodies to perform the operation. Inaddition the linear and anglular velocities would be set to zero by default. Summary allow simple non physics like functions to quickly setup and position simple and complex ode objects. MoveBody PositionBody RotateBody ScaleBody TranslateBody TurnBody Does this seem usefull to you guys? |
| ||
| Thanks for the updated 'low fat' terrain files Wayne, I'll add them to the new AnimTriMesh demo for the next JV-ODE update ;) |
| ||
| Yep, it's official... JV-ODE is now working in BlitzMax (Win32) TriMeshes are supported but not yet implemented in demo form, the demos will use bare-bones OpenGL routines for the 3D graphics. As there are many options for 3D graphics engines in BlitzMax, it might be best to build-in the basic graphics for demo purposes for the time being. Once some of the engines have matured, dedicated demos for each engine will be looked at. Coming soon... :) |
| ||
| Outstanding VIP3R I'll buy BlitzMax if you're going to get JV/ODE working and some barebones OpenGL for the demos. Will this be a new product ? What is the expected MSRP ? |
| ||
| Nope, the new BlitzMax functionality and demos will be included in the Blitz3D version of JV-ODE. I'm not planning to make additional charges for it at the moment. Any donations would be most welcome and extremely helpful though ;) |
| ||
| I'd certainly consider paying again for MAX support, though the chances of me using MAX are none until it gets aproper, simple 3D method like BlitzBasic. That's what made Blitz so good and without that, MAX sounds like just another language (unless you're doing 2D). |
| ||
| It would be worth paying for again! If you've got it working in Max, this is pretty much perfect timing for me, well done man! |
| ||
| BlitzMax JV-ODE Preview Now Available Please visit the following blitzmax.com showcase link for more information, to download the demos or post any feedback or questions... http://www.blitzmax.com/Community/posts.php?topic=57233 Thanks :) |
| ||
| Update: The BlitzMax version is almost ready for release. All of the Blitz3D demos are now in and working, including fully working TriMesh demos! The only exception is the Zombie demo, the built-in 3D engine can't do animated meshes at the moment. The BlitzMax version will include: All Blitz3D demos converted to run in BlitzMax (except Zombie demo) Built-in bare-bones 3D OpenGL engine (for demo purposes only) Built-in B3D Mesh Loader More soon... :) |
| ||
| VIP3R, I am interested in purchasing this. I have some questions... 1. Is there a manual I could download prior to purchase? 2. Can I use the examples as basis for my application? 3. Are updates free? 4. Also in the sphere demo the balls keep on moving. Is there a way to get them to act under friction, i.e. slow down and stop? |
| ||
| 1. There's an online user manual for ODE here. The full version of JV-ODE comes with a Function Reference which covers every JV-ODE/ODE function, it's not a user manual though. 2. Yes, provided you don't break any of the license conditions. 3. Yes 4. Yes, Shifty Geezer did some nice work in this field. Check the previous JV-ODE threads for more info and code. :) |
| ||
| 4. Could you be a bit more specific there is a lot of posts here :-( |
| ||
| Yes there is indeed a lot of posts, which is why I wasn't more specific. Check Thread 4 about 1/2 way down. Thank the lord for Google. |
| ||
| Whats next.. JV/3D ? 8) |
| ||
| JV-ODE V1.14 Update Released Please check your inbox :) Added new rotation functions: dBodySetAxisAngle(body,angle#,rx#,ry#,rz#) dBodyGetAxisAngle(body) dGeomSetAxisAngle(geom,angle#,rx#,ry#,rz#) dGeomGetAxisAngle(geom) Added CreateAnimTriMesh(trispace,mesh,layer) function Added CarDemo-AnimTriMesh demo Please let me know if you experience any problems with the new update. :) |
| ||
| Nice one Vip3r! Either you are a tiny bit supersticious or you forgot to send me version 1.13 :)))))) Excellent work! Danny |
| ||
| Thanks Danny, much appreciated :) Don't worry there wasn't a V1.13, it's gone up by two version numbers because it's a Blitz3D update and also a new release for BlitzMax. ;) |
| ||
| Many thanks again, new demo works really well. Might have to get into MAX now so i can try the other flavour of JV-ODE..... cheers, Mark |
| ||
| Thanks Mark, you're welcome :) Can't wait for the launch of Tricky Tracks! Maybe we'll see a BlitzMax version of it some day ;) |
| ||
| Hi Vip3r, I understand there are some historical issues with 'cylinders', but what is this exactly about?! I just wanted to make something and found out that a normal cylinder WILL NOT collide with a trimesh terrain! :( and just sink through. I don't think this is a matter of tweaking other values since any other geometry will act normally... When checking your demo's for some inspiration I noticed that you have everything 'except' a trimesh-cylinder demo :) Cheers, Danny |
| ||
| The cylinder geom isn't part of the original ODE package, but an external contribution to ODE. That's why the cylinder functions are listed separately under 'External ODE User Library Functions' in the JV-ODE Function Reference. At the moment cylinder to TriMesh collision isn't supported by the core of the library. The workaround for achieving cylinder to TriMesh collision is to 'sphere-wrap' the cylinders, have a look at the SphereWrapCylinder car demo. The only drawback is that it will only work with cylinders which are at least 2x the radius in length. The demo uses fixed joints to attach the spheres, but geom transforms would probably work better. I need to look at that :) |
| ||
| aha. ok. that does explain a lot yes... funny... I'm no math crack, but you'd think that simple cylinders would be easier to do than capped cylinders.. ok thanks! d. |
| ||
| You want JV-ODE to work with 2D projects eh? No problem :) Here's a 2D JV-ODE Spheres demo... All I've done is restrict motion on the z-axis using two very large slim boxes (barriers). You can think of these two boxes as two sheets of glass in a double glazed window, then the spheres are dropped between them. To make sure the spheres don't snag on the insides of the two barriers, their friction has been set to zero. There is also a plane at the base to stop them falling below ground level. Hopefully this will help anyone trying to work out how to use JV-ODE in 2D, let me know if you have any questions. :) |
| ||
| I rigged a quick 2D ODE engine by just setting Z speed to 0 every frame and Z postion to 0 for each object. That allowed collisions as normal with arbitary shapes and no 'container' overhead. |
| ||
| Are you sure that isn't abusing the simulation Shifty? How well did it work? If you run the 2D Spheres demo without the barriers present, it would still work ok because the spheres never stray off course on the z axis anyway. The barriers are there to prevent the odd chance that a sphere might go off course, only then will a sphere make contact with the barriers. Whether the barriers are used or not, the physics processing time remains the same, so there is in fact no overhead in this particular example. How you approach the problem depends on what you're trying to simulate in 2D. |
| ||
| It worked fine for me. I had a static mesh hitting spheres. Well, i also had static mesh hitting static mesh but we know that's crazy ;). I actually though to implement '2D' meshes, an outline of the 3D object viewed from above turned into a polyhedron, so collisions would always been along the plane with no z component. In theory that alone with zero gravity should be another. But certainly my results were very good. Didn't have any wierdness issues. I may have set rotation in the z axis (or whichever one) to zero each frame too. |
| ||
| Hi, need some help! I am having problems with speed. My game has 64 terrain tiles each 32X32 totalling 256X256 ie 131072 triangles in total. I tried adding all of them but things just freeze up. it dus work when I just add 4 tiles. I still need to add lots of trees a rocks. Here is the problem code. If s=0 Then trimesh(xx,yy)=CreateTriMesh(Space,Land_mesh(xx,yy)) trimesh(xx+4,yy)=CreateTriMesh(Space,Land_mesh(xx,yy)) trimesh(xx,yy+4)=CreateTriMesh(Space,Land_mesh(xx,yy)) trimesh(xx+4,yy+4)=CreateTriMesh(Space,Land_mesh(xx,yy)) dGeomSetPosition(trimesh(xx,yy),1024+(xx*2048),0,1024+(yy*2048)) dGeomSetPosition(trimesh(xx+4,yy),1024+(xx*2048)+8192,0,1024+(yy*2048)) dGeomSetPosition(trimesh(xx,yy+4),1024+(xx*2048),0,1024+(yy*2048)+8192) dGeomSetPosition(trimesh(xx+4,yy+4),1024+(xx*2048)+8192,0,1024+(yy*2048)+8192) EndIf Any ideas to speed things up? |
| ||
| It sounds like your TriMesh tiles are colliding with each other. You need to create a sub-space containing all of the TriMesh tiles... Global Space=dHashSpaceCreate(0) Global SceneSpace=dHashSpaceCreate(Space) ; <<< Sub-Space for TriMesh tiles Then disable internal space collisions to prevent them colliding with each other... dSetInternalSpaceCollideMode(0) Make sure you specify 'SceneSpace' instead of 'Space' in the CreateTriMesh function calls... trimesh(xx,yy)=CreateTriMesh(SceneSpace,Land_mesh(xx,yy)) The 'CarDemo-TriMesh-X4' demo shows the above method in action. |
| ||
| Thanks it's working nicely now. |
| ||
| I have been trying to fix this code but with out much susses. The problem is that the objects vanish and then come back every frame or so. I want the to move to a new location and stay there. he is the code. any help would be gratefully received. For ode.ODEGeom=Each ODEGeom RotateEntity ode\mesh,dBodyGetPitch#(ode\geom),dBodyGetYaw#(ode\geom),dBodyGetRoll#(ode\geom) obx#=dBodyGetPositionX#(ode\body) oby#=dBodyGetPositionY#(ode\body) obz#=dBodyGetPositionZ#(ode\body) ch=0 If obx#>(Local_Player_x#+HalfmapSizeX) Then obx#=obx# - FullmapSizeX ch=1 Else If Rx<(Local_Player_x#-HalfmapSizeX) Then obx#=obx# + FullmapSizeX ch=1 EndIf If obz#>(Local_Player_z#+HalfmapSizeY) Then obz#=obz# - FullmapSizeY ch=1 Else If obz#<(Local_Player_z#-HalfmapSizeY) Then obz#=obz# + FullmapSizeY ch=1 EndIf dBodyDisable(ode\body) If ch=1 Then dBodySetPosition(ode\body,obx,oby,obz) PositionEntity ode\mesh,obx,oby,obz dBodyEnable(ode\body) Next |
| ||
| Try changing the last part to the following: |
| ||
| Sorry did not work. I also need them to keep moving the same direction too. Any other Idears |
| ||
| JV-ODE Users: The video card in my dev machine has just developed a serious fault, or in other words it's @#!*ed and won't display any hardware accelerated graphics :/ I've requested a service call but obviously it limits my ability to help folks until it's fixed, hopefully it won't take too long. |
| ||
| ViP3R, hang in there buddy. Battle Tanks, Need more information. What are you trying to do in general? More code would also be helpfull. 8) |
| ||
| @Battle Tanks: You're going to run into problems if you're manually repositioning objects in ODE. It isn't necessary to tile the ODE geometry, you can create the entire scene in ODE without affecting render speed, then apply your tile system to the visible geometry only. This will avoid the need to reposition the geoms. Btw, it's easier to read code when posted using the codebox tags... [ codebox ] Your Code Here [ / codebox ] - Without the spaces ;) @Wayne: Will do :) |
| ||
| that's bad news... I have a couple of cards (through my day job) which are 'spare' for indefinte loan - let me know if you want one posting today. cheers, Mark |
| ||
| Wow Mark thanks, that's extremely generous of you :) It would be very helpful to borrow one until this one gets replaced, I'll send you an email ;) |
| ||
| This is what I am up to I have created 4 identical worlds, when the player can see the edge of one of the worlds he is transported to an Identical location in the world behind him with out the player noticing what has happed. Using this method the player can keep going in one direction with out running out of land. To get object to work in this system I use the following system. If the object is beyond a 4096 units in x or z from the player the object is then transported to an Identical location on one of the other three Identical worlds. Info: Worlds: 4 Identical worlds in total A world contains 4x4 Land Tiles each with it own Hash Space. All the trees and rocks on a tile have their own Hash Space linked to the Tiles Hash Space. Non of these are ever moved. (Note that no all the surfaces are added to the Physic system as leaves should to be able to stop a Oil barrels) Physic Objects: Are anything that moves except internet controlled objects (local objects can collide with Internet/Lan controlled objects ), Physic Objects are Ai players, Projectiles. Oil barrels, bricks, rocks ect Problems I am encountering are; 1) The more objects I add the more likely the game will crash. The error give is memory violation on this line dSpaceCollide(Space,World,ContactGroup) I have managed to fix the other problem somehow What would be the best way to make a shock wave that knocked other object out the way with out being move its self, just growing is size. Thanks for your help VIP3R. here's a dum question for you, how do you post a picture. |
| ||
| Here is some of the code |
| ||
| The more objects I add the more likely the game will crash. The error give is memory violation on this line dSpaceCollide(Space,World,ContactGroup) Quite a few things can cause SpaceCollide to MAV so it isn't always easy to pinpoint. It can happen if you create geoms inside the boundary of other geoms, for example adding more than one geom in the exact same location (overlapping the previous geom). Another cause can be if too many collision contacts are generated causing memory/stack issues. Here are some things to check that you may have missed... - Make sure all of your Space variables are global or a dim array (I can't see where you're defining the Space64 array). - Check for memory leaks. - Try lowering/raising the max contacts value with dContactSetMaxContacts(maxvalue) to see if that helps, its default is 128. - Make sure your Space64 sub-spaces are not colliding with each other or the ground plane (if used). - Make use of the body auto disable feature so that it cuts down the amount of contacts generated when objects are stationary. I still think tiling the ODE geometry like you're doing will give you headaches, so that may be at the center of the MAV issue. Try destroying and recreating the geometry instead of repositioning, it may work better and should certainly be fast enough. Not sure about the best way to do the shock wave, have you tried adding force to the surrounding objects based on their distance from the epicentre. Be careful changing the geom size while the simulation is running, I'm not sure how ODE will react to that. You can try using the dGeomSphereSetRadius(sphere,radius) etc functions for this purpose. Hope this helps :) Oh, and the forum codes... http://www.blitzmax.com/faq/faq_entry.php?id=2 |
| ||
| I have found where the problem is, well most of it. It seems that the Cylinder to trimesh is the course of most of the crashes. I will add a Spheres to each end and see if that fix’s the crashing problem I am also adding dContactSetMaxContacts(512) I am not moving any of the trimeshes only the Cylinders and Spheres. The crashing stated before I add the code to translate them to their new locations. I was thinking along the same lines with the shock wave thing One thing I would like to do is make a house with bricks and then blow it up. speed will be a problem. I have tried optimising it but still need some tips. I will use about 200 bricks. any speed tips. I will make a demo for you all to mess with. Call it something like Demolition house on trimesh.bb Thanks for your help |
| ||
| You might be better off using capped cylinders if the standard ones are giving you problems. Hmm, speed tips for 200 bricks? Try lowering your dContactSetMaxContacts() value down as low as possible. You could also try increasing the QuickStep step size. Use body auto disable on the bricks. |
| ||
| Credit where credit is due! |
| ||
| Hehe, 24/7... I'm not sure about that but I do check on the troops regularly. Thanks BT :) |
| ||
| Wow 3 hours, you are letting yourself go ;) |
| ||
 Battle Tanks Earth Level. Still early days. |
| ||
| Ooh I hope that's a tank game with physics, can't wait to see something like that done with ODE :) PS: Gasp! 9 hours late ;) |
| ||
Can anyone confirm the DSpaceCollide2 function works 100% under BlitzMax? (Sorry, there's no Bmax thread yet so I posted here in hope!)dSpaceCollide2(ray,Space.Space,world.world,group.group) - Memory Exception Error dSpaceCollide2(ray,0,world.world,group.group) - Memory Exception error. Ray, Space,World and Group are all valid. The second line throwing an error makes sense, 0 space. I was toying with it to see if it would allow me to use that instead of Ode's DCollide function. (Could do with that function ;) ) I fail to see why this fails, I can use DSpaceCollide in the same place to collide spaces with other spaces no problem? If i don't bother trying to do this, and call DspaceCollide, then the ray returns values on the next frame so it *does* work, but trying to use DSpaceCollide2 doesn't. Perhaps i've got the wrong function? |
| ||
| You should be supplying two geoms Cygnus, not a geom and space... dSpaceCollide2(geom1,geom2,world,group) [edit] Confirmed, it's working ok in BlitzMax ;) |
| ||
| I see, I thought that would be the case, The official ODE Docs read: void dSpaceCollide2 (dGeomID o1, dGeomID o2, void *data, dNearCallback *callback); This function is similar to dSpaceCollide, except that it is passed two geoms (or spaces) as arguments. It calls the callback for all potentially intersecting pairs that contain one geom from o1 and one geom from o2. The exact behavior depends on the types of o1 and o2: * If one argument is a non-space geom and the other is a space, the callback is called with all potential intersections between the geom and the objects in the space. * If both o1 and o2 are spaces then this calls the callback for all potentially intersecting pairs that contain one geom from o1 and one geom from o2. The algorithm that is used depends on what kinds of spaces are being collided. If no optimized algorithm can be selected then this function will resort to one of the following two strategies: 1. All the geoms in o1 are tested one-by-one against o2. 2. All the geoms in o2 are tested one-by-one against o1. The strategy used may depends on a number of rules, but in general the space with less objects has its geoms examined one-by-one. * If both arguments are the same space, this is equivalent to calling dSpaceCollide on that space. * If both arguments are non-space geoms, this simply calls the callback once with these arguments. So, I need a command where i can check one single geom against a space, like Dcollide or the Official DSpaceCollide2 command. How can I do this? :D |
| ||
| Checking for collisions with spaces using dSpaceCollide2() isn't implemented in JV-ODE, only geoms are currently supported with this function. dCollide() is of absolutely no use externally, hence it isn't wrapped. I can look into whether it's possible to implement space collisions with dSpaceCollide2() for the next JV-ODE update if you wish? |
| ||
| If you can, Yeah, I looked at Dcollide, since it doesnt return any details it is indeed useless. I do need the ability to check geom>Space though so if you could implement that i'd be extremely greatful! :D |
| ||
| Ok, I've just done a few quick tests and it looks like it will indeed be possible with a little bit of work. It would give the ability to check geom/space>geom/space using dSpaceCollide2(). I'll add it to the 2do for the next update. |
| ||
| Thanks Viper. When it comes to customer support, you can't be beaten! :D |
| ||
I think their are three Viper. Entreating , I hear you say, that is what the 3 is for in VIP3R. They each take 8 hours shift answering our questions. So what dues it all stand for? Very Intelligent Person with 3 Replicas. In-fact I think the original one is on holiday. Which I think is very unfair on the them poor Replicas. I think we should start campaign. So come on Viper get back here and do your fare share. Before will let the authority know about your Clones! !We have photo graphic evidence! ;) |
| ||
| [qupte]Very Intelligent Person with 3 Replicas.[/quote] LMFAO! :D |
| ||
| On a more informative note. For all you JV-ODE fans out there eager to get every last bit of speed out of an already fast Physic system, here some speed tips. Speed Tip 1) Only add the surfaces of an model to the Physic system that you really need to i.e. no need to add the leaves of a tree just the trunk Speed Tip 2) Use a program like milkshake to reduce the number of polygons in our models. The DirectX mesh tool is grate for this. Now Export it as a new model something like “phy-(oldname).3ds”. Now in your program when you use the model of a Tree for instance you will and a hi poly model for Eye Candy and a low poly model for the Physic system. I used these two methods on a tree with over 6000 triangles and made a Physic trimesh with 136 triangles, why not try it. If fact it would be really cool if Viper could include a triangle reduction tool like this into the next update. Something like Newmesh=ReduceTriangles(oldmesh, % Reduction) |
| ||
| http://www.blitzbasic.com/codearcs/codearcs.php?code=1285 ;) |
| ||
| :) :) :) |
| ||
| I Did Try that one. It's good but has some bad side effects and is slow. I found the DirectX tool gives the best finish but you have to use it out side of blitz. The code Is a start but needs some work. |
| ||
| you're never satisfied, are you? your poor mom/wife... >;P |
| ||
| I've been helping a JV-ODE user out with AMotor joints via email and thought that this info would be helpful to everyone, so here it is... Creating and using AMotor joints: Attach two bodies using a Ball joint, then attach an AMotor joint to the same two bodies. The Ball joint will keep the two bodies attached to each other and will allow movement in all directions. In the car demo below, you will see that the rear wheels are attached using Ball joints instead of Hinge2 joints like the two front wheels. Without the AMotor joints on the rear wheels, they would collapse as Ball joints move in any direction. Try commenting out all of the AMotor stuff in the SetupCar() and UpdateCar() functions in the AMotor demo and you will see the rear wheels wobble and collapse. One ability of the AMotor joint is to restrict motion on any axis, in the car demo it stops the wheels collapsing by restricting movement of the Ball joint in all directions except the z axis to allow the Ball joint (or wheel) to rotate. The dJointSetAMotorAxis() functions will allow you to set whether rotation is allowed on each axis of the joint. A value of 0 (zero) will not allow movement, a value of 1 (or -1 to reverse) will allow movement. Next, you need to set the 'dParamLoStop' and 'dParamHiStop' parameters with the dJointSetAMotorParam() function to define how much rotation is allowed. The value should be in radians, not degrees. A value of zero for both LoStop and HiStop will not allow any movement. As you can see in the car demo we need full rotation to allow the wheel to spin completely, so it is set with -4 radians for the LoStop and 4 radians for the HiStop which will allow full rotation. Try changing them to -2 and 2 and you will see that the wheels lock after approx 1/2 a rotation. Remember that the LoStop value must always be the lowest value and the HiStop must be the highest value. The second ability is that you are able to supply a force to AMotor joints to make them rotate, like an electric motor. See the third For/Next loop in the UpdateCar() function in the car demo, you can use 'dParamVel' (force) and 'dParamFMax' (torque) to do this. You need to set all of the AMotorAxis and AMotorParam settings for the AMotor joint to function correctly. Here's the AMotor demo... (it will be included in the next JV-ODE update) |
| ||
| hm i always wondered what is the real benefit of using motors instead of using normal joints+applying rotational forces to them? |
| ||
| They're good for simulating stuff like motor servos or can be used as motors for insect legs, that kind of thing. They provide more flexibility for joint control in both restriction of movement and when applying forces. |
| ||
| After looking at (and deconstructing) the cardemo's there's one question I like to ask: First you create a body , then create the geometry for it and then create the mesh. So far so good. Now, let's say I've modeled a car (including the wheels). Would it not be possible to create ODE-objects in a reverse order? Thus: 1) load carmesh (wheels are child-entities within the same file btw) 2) create a body 3) determine size of carmesh (meshwidth,meshheight,meshdepth) 4) position body at location of carmesh 5) use dMassSetBoxTotal as follows: dMassSetBoxTotal ( mass , CarMass , meshwidth*2 , meshheight*2 , meshdepth*2 ) 6) create geometry for carmesh 7) bind geometry to body and because I already know the location and size of each wheel just repeat step (2) through (7) ? This should do the trick , right? Unfortunately I get some strange readings in my debuglog , and my screen shows absolutely nothing. I'll try to reproduce the situation and post a screenshot of it. In the meantime I would like to know if the aforementioned procedure is acceptable or not? Thanks in advance! |
| ||
| I've used the procedure when starting what was "Enginev2". it worked fine, so it is possbile :) |
| ||
| Thanks Cygnus. I'm a happy bunny :D BTW here are a few models I'm using it for (they are not finished yet though)   |
| ||
| JV-ODE V1.15 Update Released Please check your inbox :) The new update includes: Added support for Space collision checking in the dSpaceCollide2() function Added CarDemo-AMotor Added CarDemo-TruckTrailer Changed CarDemo-SphereWrapCylinder to include Geom Transform option Please let me know if you experience any problems with the new update. :) |
| ||
| You *know* i've been staring at this thread waiting. Thanks man! |
| ||
| Thanks VIP3R - looking good as usual. One question, the Amotor method of driving a vehicles wheels would not have the inherent suspension settings that a hinge2 joint would have, would it ? Am i right in thinking that you would need to model the suspension yourself (a little project i've been thinking of for a while). i.e. use the amotor to drive the wheel whilst it's held in position using a system of connecting rods / hinges to mimic a real suspension unit. Mark |
| ||
| Cool... updates just keep coming! :) |
| ||
| Thanks all :) You should be able to use the AMotor as a wheel joint providing you add a separate suspension system as you've decribed. I haven't tried it yet, but the theory seems sound to me. |
| ||
| thx for update! for what is it good the new "dSpaceCollide2()" ? |
| ||
| You're welcome Barton :) dSpaceCollide() processes collisions for all Geoms and Spaces. dSpaceCollide2() processes collisions on only the Spaces/Geoms specified, allowing you to manually select which Geoms or Spaces are checked for collisions. |
| ||
| More control, I like it !! Thanks for update VIP3R. |
| ||
| You're welcome Wayne :) Btw, nice models Atomic Duck. |
| ||
| Nice Car. I was just wondering if I need to create a geom for a body if I don't need the object to spin. I.E. the CreateSprite() could I just us a body for this or is a geom needed anyway. I am making a projectile and as soon as it hits something it is deleted. |
| ||
| Hmm, I'm not entirely sure what you need to do, anyway here's what a body and geom does... An ODE body is affected by forces and mass, like gravity etc. An ODE geom is used for collision detection. If you create a body without a geom it will be affected by forces like gravity, but will not collide with any other objects. If you create a geom without a body it will be static (not affected by forces etc), but it will still collide with other geoms. |
| ||
| So for a round rock that is part of the land I could us a ODE geom Sphere. But for projectile with a Sprite I need both a ODE body and ODE geom to work right. Thanks for the clarification :) I am finding that after a while run my game things slow down for a couple of seconds. I am creating and Destroying ODE body and ODE geom all the time it's running. could it be ODE doing a garbage collection that is temporally slowing things down to a crawl (about 1 to 2 seconds). Is there a command to help overcome this? |
| ||
| Yep, for the round rock you can use a static Sphere geom (with no body). I don't know of any memory leaks etc so I'm not sure why you get those slowdowns. Of course there could be a million and one reasons, but I would double check that you're destroying not only the body/geoms but also any joints that are holding them together. Destroy any unused spaces. As a test you could reposition (re-use) the body/geoms to see if that cures the problem, it may help find the cause. Also check for straying geoms that may have been created beneath the TriMeshes etc as that would probably cause instability or slowdowns. If you're creating static rocks that are in contact with the TriMeshes, make sure they're in the same sub-space with internal space collide mode disabled. Let me know if you need anymore info ;) |
| ||
| I'd also avoid using create and destroy where possible. You have an overhead of managing resources when doing that, with the OS having to manage RAM. Better if you can to move objects off scene. In my engine I set an object to no space to disable it, and set the mesh invisible. Then when I want it back in, add it to the root ODE space and make the mesh visible. So if you're creating bullets on the fly, try instead having an array of bullets and make them active/inactive that way. |
| ||
| Thanks, I will give it a go and tell you how it goes :) |
| ||
| Forgive a JV-ODE noob, I have a question about how to alter/set the centre of rotation for a body. At the moment, all created bodies pivot around their geometric centre - is there a way to make them pivot around some point OTHER than their geometric centres? Do I have to use mass or hinge? At the moment, the object only has body, geom and mesh. yinch'06 p.s. JV-ODE is the just about the most brilliant userLib I have ever found. |
| ||
| This is the only command I could find to set the center of gravity. void dMassSetParameters (dMass *, dReal themass, dReal cgx, dReal cgy, dReal cgz, dReal I11, dReal I22, dReal I33, dReal I12, dReal I13, dReal I23); Set the mass parameters to the given values. themass is the mass of the body. (cx,cy,cz) is the center of gravity position in the body frame. The Ixx values are the elements of the inertia matrix: [ I11 I12 I13 ] [ I12 I22 I23 ] [ I13 I23 I33 ] I have no idea how to use it? What would this be ? inertia matrix:[ I11 I12 I13 ] Anyone up to making an example? |
| ||
| Thanks for helping out BT ;) Hi yinch, Don't use the dMassSetParameters() function, the inertia matrix stuff is a bit complicated. There's another ODE mass function that will move the center of gravity of a body... dMassTranslate(mass,x,y,z) Replace the AddObject() function in the 'Demo-Spheres.bb' demo with this one... If you need a jointed body to rotate around a different point, you need to move the anchor position of the joint. |
| ||
| That's interesting. That could be used to simulate a half full barrel, by slowly moving the center of gravity to the lower end I will have to use that line “Don't use the dMassSetParameters() function, the inertia matrix stuff is a bit complicated.” When I not shore how something works too ;) .It makes you look cleave without giving the fact you don’t know your self ;) I think VIP3R is going to explain it now, or at least look it up and then explain it ;) |
| ||
| Thanks Vip3r, I was starting to use hinges already. But it is useful to know about the mass translate function. Once again - keep up the brilliant brilliant work on JV-ODE, you rock! yinch'06 |
| ||
| You're welcome yinch :) Hehe, Battle Tanks if you really want to understand how an inertia matrix works then here you are, knock yourself out... http://scienceworld.wolfram.com/physics/MomentofInertia.html ...like I said, it's a bit complicated I'm not a professor of physics you know ;) |
| ||
| It's the thread clump of Hebrew and Aztec symbols that realy cleared things up for me ;) I feel so thick now for knot geting from [ I11 I12 I13 ] [ I12 I22 I23 ] [ I13 I23 I33 ] Well back to Superman then, he may not be real but he has laserguns for eyeballs you know ;) |
| ||
| It's allot simpler in two dimensions [ I11 I12 ] [ I12 I22 ] moment of inertia is just the mass times the square of perpendicular distance to the rotation axis, i.e. I = mr2. That point mass relationship becomes the basis for all other moments of inertia since any object can be built up from a collection of point masses. so if we put the center of mass to one side of our circle or Sphere. And that side gets a glacing blow it will make the circle or Sphere spin more rapidly that if it was hit further way from the center of mass. Am I right in saying all it is, is a fence three dimensional lever. Move the short end of the lever and the long end moves the distance the short end moved divided by the length of the short end X the length of the long end. So if the short end was 10 cm long (distance from the pivot) and the long end was 30 cm long (distance from the pivot) if the short end was move 5 cm then the long end would move 3X that (15cm) 5cm / 10cm * 30cm = 15cm It that right or have I got the wrong end of the lever :) |
| ||
| Am I right in saying No, you're not even close. If you had any understanding of what an inertia matrix is and how it works you would know that 'I = mr2' doesn't apply to solid objects and that a circle and sphere both have different moment of inertia algorithms. Let's get something straight shall we, I'm not here to give people in-depth physics lessons. If that's what you desire I suggest you take a degree in the subject. Now, is there anything else I can help you with? :) |
| ||
| Time for a new thread Viper? |
| ||
| THREAD 6 IS ABOUT TO CLOSE Please continue on the new thread located here Thanks :) |
   |