Pre-packaged physics system
Blitz3D Forums/Blitz3D Programming/Pre-packaged physics system
| ||
| Is there a physics system available for Blitz3D that one could buy/download somewhere? I don't want a lot. Just simple sphere/polygon collisions and reactions. Blitz handles the collisions just fine, but it's the reactions I'm mostly interested in. I'd be willing to pay good money for a solid system like this. Any ideas or links? |
| ||
| I have a system I developed a while ago (actually 2 systems: physics and collisions) that I was planning to make friendly enough to release. But, its a job in itself making it usable to others, documenting, and supporting. You can get some idea of it in my old demo here: http://www.marina.cybermog.co.uk/hamsterball.zip Some people have tried using the ODE system as well. |
| ||
| ODE? |
| ||
| James Vorderman wrote a wrapper for the open-source ODE physics system... |
| ||
| Neither of the links to the wrapper work... |
| ||
| Um, the first one works fine. That's what you get when you search for "blitz ode" on Google: http://www.corstorphineonline.com/ode/ |
| ||
| Oh... I thought that the first two links were to the library ITSELF. The last two looked like they were to the wrapper. So I only clicked those. |
| ||
| i started working on a physics system this morning, dont know how far its going to go or even if il finish it... but if i dont il just release the source... heres what i got down in about an hour: Global acceleration; Relative acceleration; Global friction; Relative friction; Bouncing, including the oppurtunity to bounce with any % of the original speed; the bouncing can also include rolling if the surface is smooth enough, although i may try to implement a "rolling collision" method. is it worth me figuring out rotation stuff for this? i really hate it... so im not sure about implementing it. also, it only uses blitz collision techniques - so moving poly to static sphere collisions arent allowed. is there anything else you want? |
| ||
| All the physics systems out there seem to be particle/spring physics, which is great for silly little programs where you want to fool the player into thinking that something bounced for aesthetic reasons. Unfortunately, you can't base a game around particle/spring physics, because it's unreliable: add too much speed to a collision, or let a crafty player fool for too long, and you'll have rediculous and unrealistic things happen - like wooden crates unfolding into big balloons. Spring physics is a poor imitation of real physics and should only be used for looks and/or very simple applications. I haven't run into a single physics system which would be solid enough to make it an integral part of a game. I'm talking about rigid-body physics with rotational torque and all that good stuff. It pains me to imagine all the fun games that could be created easily with access to something like real-world physics. |
| ||
| Well did you check out that ODE physics engine linked to above? I did, and the demos of it working in blitz are pretty impressive, even though whoever made the demos didn't model gravity properly, and didn't set enough friction for certain things. For example, there's a demo where a hundred cubes fall in a straight line down on top of one another, and they seem to collide properly and spill outwards into the surrounding area. Some of them bounce really high and stuff but I have to assume that's the fault of whoever made the demo. There's a bowling demo with a ball that you can set the weight of and if you set it to the highest setting the simulation seems pretty solid, though the pins appear to be far too light. There's also a monster truck demo, but they physics in that aren't very good. The car jitters like crazy going up hills. But I chalk that up to programmer error as well. After all, you can't expect to model the performance of a vehicle and leave out half the suspension system. I'd be willing to bet he took shortcuts and didn't put in all the bits a real suspension system has and that led to zany effects. Anyhow, even with a few bugs, there's a lot of stuff that ODE system looks like it would be great for in games. If all you used it for was to model how objects moved and fell after being shot, that would be pretty cool in and of itself. |
| ||
| Damn Swift, this thing has been around for long and you first heard of it now? Vorderman did those demos. |
| ||
| Thomas Jakobsen used Particle/Spring physics using verlet integration which was used in Hitman with excellent results. |
| ||
| Well it's not neccesarfily that I hadn't heard of it. I just never payed any attention to it because I don't like using DLL's with Blitz, and I never had a need for any real physics stuff. |
| ||
| "but I have to assume that's the fault of whoever made the demo" "But I chalk that up to programmer error as well" "I'd be willing to bet he took shortcuts " Really? Please feel free to do better. Such gratitude. How inconsiderate of me not to provide you with Gran_Turismo.bb. "The car jitters like crazy going up hills" That's a fault between ODE and a certain version of Blitz. On 1.77 it's perfectly smooth. |
| ||
| octothorpe: Hitman is a silly little game with bad physics? Particle/spring based system is more stabile than more realistic rigid body calculations. Try to stack up objects using ODE... you'll see what I mean. Because if you use as real modelling as possible, then if something goes wrong or numbers drift a bit it all comes unstable. check the rigid body thread in user projects. |
| ||
| Oh jeez, you don't have to take it personally. I was merely stating facts. I wasn't trying to bash your programming. I am grateful that you made some demos to demonstrate it. I mean did you completely ignore the bit where I said " I did, and the demos of it working in blitz are pretty impressive,"? I said the demos were impressive. But as they stand, they are not realistic enough simulations to use in a game. They are nice demos, they are poor games. :-) Don't take it so personally! Anyhow, speaking of problems... When I tried to run the EXE's you provided, all I got was a memory access error. I had to compile and run the demos myself. Do you have any idea why that might happen? It's not good that a Blitz program would fail like that, and it concerns me. You mention that it does not work with certain versions of Blitz. Why is that? What changed? |
| ||
| Oh and I also wanted to say that though I think the demos are inadequate, I understamd why they are. I'm sure it's a pain in the ass to set up a realistic suspension system for a care that works right with the physics system. I was merely stating that the reason the demos displayed jittering was because that was likely the case. Of course now that you mention that that is just a problem with a specific version of Blitz I'm not so sure that the setup you provided IS actually inadequate. I'd have to see it running in a proper version of Blitz, but you said it's smooth, so I guess I'll have to beleive you. :-) |
| ||
| 'tis a nice system though.. I do find that the DLL locks up now and again - wouldn't want to use it on a commercial release. Great work, Love the Monster Demo, not too sure about the demo with the Beach Buggy's - seems too buggy :o |
| ||
| Examples lock on my system, that's why I abondened it. It had something to do with something, in some prevoius versions it worked perfectly but 1.8 didn't work so perfectly. Mark didn't know what caused it and he didn't have time to go thru it and check if it was something in ODE |
| ||
| Well did you check out that ODE physics engine linked to above? Yes, a long time ago. It's yet another particle/spring system. Some of them bounce really high and stuff but I have to assume that's the fault of whoever made the demo. No, that's because the underlying physics system isn't very good. Hitman is a silly little game with bad physics? Can you provide an URL or something? I haven't heard of Hitman. Try to stack up objects using ODE... They bounce all over the place, even from a standstill. That's because spring physics are inadequate for most realistic applications. You can't get friction or surface forces to work with particles and springs! PS - the ODE's dll locks up and throws errors all the time too. I wouldn't recommend using it at all. :( |
| ||
| I might be wrong but i think ODE is NOT a particle/spring system. And you are totally wrong... you can easily implement surface forces and friction in particle/spring system. www.kotiposti.net/naama/rigid.zip -> It's 2D, but you'll see the picture. Hitman has the most impressive character physics today. And it's all implemented using particle/spring system and verlet integration. So don't bash if you don't know what you're talking about. www.hitman2.com |
| ||
| "No, that's because the underlying physics system isn't very good." Maybe I'm going out on a limb here, but I read the documentation for ODE, and to me, the guy seems to know EXACTLY what he's doing, and he's doing stuff which is way beyond my own knowedge of physics. So I'd be very surprised if there was something fundamentally wrong with his simulation. "They bounce all over the place, even from a standstill. That's because spring physics are inadequate for most realistic applications. You can't get friction or surface forces to work with particles and springs!" Where does it say that the objects are modeled with springs? I read the docs, and from what I understand, it looks like he says that when an object collides with another object, you (or he, I'm not sure) find the point of the collision, and create a special joint at that location which allows movement only in a direction away from the surface. This supposedly prevents objects from interpenetrating somehow. Since I see the cubes in the cube string demo interpenetrate a lot, I must assume this isn't being done in that demo. The other demo with the falling cubes however seems to be better abou tnot letting cubes interpenetrate. As for locking up and throwing out errors, well I guess that's a price you pay for using a free physics system. Has ANYONE else here written anything more sophisticated though than objects coliding properly? Like simulating stick and slip friction for tires? And all those diffrent kinds of constrained joints he supports? Cause if not, then this seems like the best option at this point to me if I needed a physics system. |
| ||
| Well, the guys at www.Quest3D.com implemented ODE with great success and I don't think they would have implemented it if they believed it was such an unstable system. The creator of ODE was also the mastermind behind the Mathengine system. |
| ||
| I was very impressed by the ODE under Blitz3D!! I will maybe try to use it... The problem is that I experienced some instabilities on some examples (everything freeze). Concerning the stunt car demo, I modified every AlignToVector linked to the car and put a smoothing rate of 0.3 (instead of the default value of 1). The game is then perfectly smooth!! |
| ||
| That AlignToVector command change was something that was introduced in a certain version of Blitz. Without the rate parameter being altered the new versions make the car body jump around all over the place. "I'm sure it's a pain in the ass to set up a realistic suspension system for a care that works right with the physics system" It certainly is. I've not bothered because I don't think ODE's collision responses can effectively simulate the rubber tyre->road reactions that you get in real life. Without going into stuff like the pacejka formulas (http://www.racer.nl/reference/pacejka.htm) the sliding friction and tyre model you get just doesn't allow for a fun car. I've tried many times to get the stunt car demo to behave more realistically, but with little success, and I can't be bothered to try and set up a complete model of the suspension system. |
| ||
| I think the ODE wrapper only works on a previous version of Blitz3D. I'm not sure which version. I liked ODE and it did work great but it locks up under the current version. |
| ||
| I know it works with 1.77, as that's what I used to create it. I believe after the compiler became a seperate thing it all went pear shaped. |
| ||
| Vorder: Well, if I may make a suggestion about the car demo... It seems to me strange that the front of the car when it hits an angled incline just snaps to the right, rolling around the car's Z axis instantly. Now you and some other folks suggest that modifying aligntovector fixes this. But I say that using a value other than 1.0 with aligntovector is a hack which is physically incorrect. The reason is that aigntovector does not make something move with a constant time regardless of framerate. The more often you call your physics, the faster the object will move, and it will move REALLY fast intitally to get to the new alignment, and then slow down really fast to the point where it never quite reaches the alignment specificed. Think of it like so... I have a stick pointing straight up. Now, if I want that stick to lie down, and I use aligntovector with a tween value of 0.5, the first time I call aligntovector for the stick, the stick rotates 45 degrees and is now 45 degress from horizontal. The next time I call it, the stick moves only 22.5 degrees, and is now 22.5 degrees offset from horizontal. The next time I call it it moves only 12.5 degrees and is 12.5 degrees from horizontal. As you can see each time, the distance it moves is half the distance of the previous time, and as a result you can NEVER align to the new vector because it will just keep slowing down more and more. What you need for proper physics is to change vectors with a constant angular velocity, variable by the time taken between physics updates. And it looks to me like it would help a lot if that axis that is being rotated around on the car was a spring. Of course, there should not even be an axis there, but if you're going to use that in lieu of a proper suspension system then it definitely seems like a spring or two to make it rotate back to a neutral orientation and resist being rotated would be a big improvement. (Of course maybe there is a spring there and it just doesn't work in my demo cause of those aligntovector issues which still probably need to be corrected.) I know I could try this stuff myself, but I'm not really interested in simulating cars myself right now, especially not when it's so complicated to set up ned joints and stuff, I just don't have the time. I'm just offering some suggestions on how you could improve your simulation. |
| ||
| Eh? The AlignToVector command has no part in the physics at all - it simply aligns the visual representation of the car body to the physics object (in this case a box) that ODE is using to represent the car. Therefore the AlignToVector 'hack' is no such thing - the behavior of the command was changed between two versions of Blitz, when the rate parameter was added. Thus if you run the demo on a later version of Blitz you need to modify this command to allow Blitz to orient the object correctly. If you don't, you'll see the car body flicking around all over the place. You want the car body to instantly match the orientation of the physics body, you don't want it to slowly turn to get there, because in that case what you see on screen is not really what is happening behind the scenes in the physics. The use of AlignToVector has NOTHING to do with the physics going on. Nothing at all. |
| ||
| Swift is still learning, don't be so hard on him ;) He was skipping some lessons on ODE before and is catching up now ;) |
| ||
| This simple routine will work wonders: x=entity position() moveentity velocity updateworld velocity=entityposition-x |
| ||
| ..but not when linked to an external physics system. |
| ||
| here is just something random, i know its not made with blitz but its sooo cool, maybe he could release an article on how to do it or something because it is a great phisics system http://www.flipcode.com/cgi-bin/msg.cgi?showThread=04-30-2003&forum=iotd&id=-1 |
| ||
| "You want the car body to instantly match the orientation of the physics body, you don't want it to slowly turn to get there, because in that case what you see on screen is not really what is happening behind the scenes in the physics." Yes, that's part of what I was saying. Using aligntovector with a value other than 1.0 to "smooth out" the motion is a hack. The other part of what I was saying may not apply. I haven't taken a careful look at the demo. I thought that the physics sytem might be giving you back a direction to rotate the object with a velocity, or that you were running the physics system at a lower framerate than the actual framerate which means you'd have to interpolate the positions. If that is not the case, okay. But it still looks like the problem with the snapping is that the joint there lacks a spring, and without that it's no wonder the car can't steer around corners when going uphill very well. Of course I am again assuming a mistake was made and that it is not the physics engine at fault, not having seen the code. However, you yourself admitted that you did not build a full suspension system model. So there's no reaosn for me to assume you put a spring in that part of the car. Anyhow, the fact is that if you create a poor model of a car, then it will drive poorly. Same thing goes for modelling planes. When Looking Glass was first making Flight Unlimited, the programmer finished coding all the physics, and all his planes kept crashing into the ground. He talked to another programmer about it, and asked him what was wrong, and he realised that he was modeling airflow over a wing realistically, but the wing model itself was not realistic so it didn't work! The physics were so good that the plane itself being modeled improperly resulted in the physics sending the plane hurtling into the ground everytime... exactly as would happen in the real world. So you'll never know how good a job this physics sytem does modelling vehicle behavior until you actually model a realistic suspension system based on a real car. That's the only way to truly say whether the system can model a car properly. Any other test which results in crappy driving proves nothing at all about the quality of the simulation unless you have a real car built the same way to test against. Of course you do not have to model things exactly, but there is a certain level of modeling you need to do. And if the wheels don't stick to the ground when you go over obstacles, well then you've got a problem. If I recall your tires are each on some kind of a shock... Perhaps if you simply got rid of that pivot in the center of the car it would help. Then at least you'd be modeling an RC car. That pivot could be resulting in some weird behavior with one tire pushing the other tire down into the ground or something. I dunno. Anyhow, I just think you gave up on it too easily. That monster truck demo almost seems fun, and it seems that all that it needs is some tweaking and a wider track you don't fall off of all the time to make it a little better. Like make a big terrain with rolling hills. That would be fun. |
| ||
| Take initial position. Do anything you want to it, move it, update collisions, move it some more. Subtract initial position from current position, and that's how fast it's moving. This will make things slide off walls, accelerate, decelerate, and can be modified to transfer energy or bounce. |
| ||
| My god Halo, why didn't I think of that before! Forget about contrained joints, springs, friction, gravity, torque, lift, drag, side slip, and center of mass! Genius! ... Of course that is assuming the only kind of game you're interested in making is a simulation of Pool or Pong or Asteroids. And a poor simulation at that. What happens when your ball is one inch from the wall the frame before it hits it? Hitting the wall stops it, so that frame your ball loses most of it's velocity and slows to stop. That's not right. The only thing you'd want to subtract current position from previous position for is to determine WHEN a collision occured between frames so that you can then move the ball that extra amount for a slightly more accurate physics simulation. In practice however, such inaccuracies are unnoticable with simple physics simulations but will cause problems with more complex simulations probably. |
| ||
| LOL. Anyhow, the car model in the demo is made from a number of ODE objects and ODE joints - the wheels are spheres (an unfortunate problem but there is no cylinder->poly collision in Blitz at the moment to get around this), and the body is a cube. The wheels are joined the to body by 4 special CARWHEEL ODE joints. These incorporate 2 axes of powered movement (vertical rotation (steering) and a horizontal axle (forward/backward)), and also a springing suspension system that operates along a defined axis (probably vertical in the demo I think). The problem with the AlignToVector use is that the Blitz visual object doesn't get oriented correctly to the ODE box (body) unless the rate parameter is changed on some versions of Blitz. The physics system and subsequent physically actions of the car are entirely unrelated to the use of this command. You can remove it completely and the car will still drive exactly the same as before. In fact, you can entirely remove the Blitz side of things (minus the input routine) and the car will drive the same (albeit without poly collision and thus interacting with ODE objects only). You need to understand how that the physics is totally independant from the Blitz bits - the only feedback added was to force sphere->poly collisions with the track model. This ODE model of the car would drive exactly the same in a program written in C or whatever. Look at the ODE Buggy (C++) demo - the same problems and 'feel' to the car are there too. This is in my opinion the major problem with an external physics system - getting info back and forth is difficult and you have to bully the system into doing what you want. Anyhow, the fact is that if you create a poor model of a car, then it will drive poorly Yes, but it's not the car model at fault, it's the tyre model, or more precisely the complete lack of one. The suspension joints in ODE are prefectly OK, but without at least some form of realistic simulation of rubber on tarmac the car will behave like it's either driving on ice or on velcro. There will be no static->sliding friction changes etc.. that make up a real car model. I really wish someone would package up a "CAR PHYSICS SYSTEM" userlib for Blitz, incorporating all these things. |
| ||
| "Anyhow, the car model in the demo is made from a number of ODE objects and ODE joints - the wheels are spheres (an unfortunate problem but there is no cylinder->poly collision in Blitz at the moment to get around this)" You COULD use meshesintersect though, and toss out the whole Blitz collision system. Cylinder collisions alone will not give you an accurate simulation of a tire any more than a sphere will. Real tires deform where they press against the ground and you get a square cross section of area where contact occurs. That's a lot more contact than you would get with a cylinder which would contact at only a single line. But it may be that for the purpouses of the simulation that is totally uneccessary detail. If that is the case however, then I would argue that the sphere collision model should therefore be just as good as a cylinder model for the tires. "The suspension joints in ODE are prefectly OK, but without at least some form of realistic simulation of rubber on tarmac the car will behave like it's either driving on ice or on velcro." Yeah like I said. But one thing I was considering now is that you're inputting certain values into the physics simulation that take that into account aren't you? I mean, you have to tell it how much the sphere sticks and slips. It doesn't calculate that at ALL using the actual surface area of the sphere that is in contact with the road. So making a more accurate contact model seems like it would really only have an effect when transitioning from flat surface to a hill breifly. Anyhow, you still haven't explained one thing. Why do the front two tires of the car seem to jerk suddenly, rotating to the left or right, and then sticking in that orientation after you go off a jump? That is the problem which I think a spring would solve and which I think would help to improve the driving model. Without a spring there it seems to me that that will cause all sort of prblems, especially on landings. Those front tires should not be so easily forced to rotate like that and once rotated they should spring back quickly to a neutral position while in the air so the car lands on all four tires and not on just three with one at an angle. "I really wish someone would package up a "CAR PHYSICS SYSTEM" userlib for Blitz, incorporating all these things." I thought about doing that once, but simulating physics on this level is about 100x harder than simulating an airplane and I had a hard time juet getting the numbers I needed for a real plane to be able to simulate it and m resulting simulation didn't feel very good. And it took me a week to program. But stick and slip and sliding friction and stuff... These things require a college level knowledge of physics, and a knowledge of calculus to be able to read the formulas online which I don't have. And I don't know anyhting about driving a racecar (or a plane for that matter) and so I don't know what feels right and what feels wrong... which makes it impossible to debug such a simulation. So that's why I haven't done that. :-) I figure if I make a car game eventually I'm going to stick to a simpler simulation. I'll model springs for shocks, and use my ball bouncing physics with variable elasticity for the tires, and add some movement constraints so that there is a lot of friction when the car tries to move sideways but little friction when it moves forward and backwards so that it will be ableto slide sideways if a big enough force is applied, but tend to roll forwards and backwards only. |
| ||
| by "stick and slip" i assume you're all referring to the two different coefficients of friction attributed to a material. don't believe that would be too difficult to get a handle on, but could be a bear to implement. assign the first material "stick" coefficient until a force acting on the vehicle (in a turn - centrifugal force for example) overcomes the resisting force (a function of the "stick" coefficients for the contact materials and the footprint as well as other things like vehicle weight). when the resisting force is overcome, material "slip" coefficients replace the "stick" coefficients and the vehicle would start accelerating sideways (in this example). you would need a cylinder and not a sphere. and deformation would be important; for example, the vehicle comes over a hill while turning (could be just an undulation in the surface actually): - vehicle's downward motion causes the wheel to deform - the increased footprint causes a subsequent increase in the resistant force (i.e. the "stick" coefficient combined with the other properties result in a larger force to be overcome before you can switch to "slip" coefficients) - if the resisting force is too large the vehicle might spin or flip depending on its CG and such - during all this time the vehicle's footprint is changing as it bounces around (primarily vertically) and the resistive force is also changing, so whether it sticks or slips if very much a function of the vehicle's suspension which influences tire deformation there's plenty to consider, but when broken down a reasonable simulation could be achieved. but effectively breaking down the problem and determining how detailed is good enough is the first step. |
| ||
| "You COULD use meshesintersect though, and toss out the whole Blitz collision system. " Unfortunately not - the collision system relies upon Blitz returning collision normals and locations, which then get passed to the ODE DLL and used to generate all the collision contacts. MESHESINTERSECT doesn't return either of these vital bits of info. Anyhow, you still haven't explained one thing. Why do the front two tires of the car seem to jerk suddenly, rotating to the left or right, and then sticking in that orientation after you go off a jump? That's something I've not seen - I can only assume that's one of the by-products of running the demo on a later version of Blitz where the change was made to the ALIGNTOVECTOR command. On my version the front wheels react smoothly and turn smoothly as you steer - there are no sudden changes or flicks at all. and which I think would help to improve the driving model I don't think so - the effect you're seeing must be a visual artefact as I mentioned above, and therefore has absilutely no impact on the phyiscs side of things at all. You need to remember that what you're seeing on-screen doesn't necessarily represent what the physics is doing. Due to that ALIGNTOVECTOR problem the visual wheels can jerk around all over the place, but in the background the physics happily soldiers on entirely un-aware of these things. Actually, having just read what I've just written, a thought occurs - the program uses Blitz's collision system to generate collision normals and points. If the ALIGNTOVECTOR command is screwing up the orientation of the Blitz wheel object, the collisions Blitz generates will be wrong, and this wrong info will then get passed to the DLL and things will go screwy. Of course that will only apply when the truck is driving up on the mesh track - the invisible ground plane is an ODE object and is therefore unaffected by this problem as it uses ODE's internal collision system and is independent from the Blitz-generated collisions. So if you get any visual weirdness when driving on the flat ground plane, then it's not affecting the physics system at all. |
| ||
| "Unfortunately not - the collision system relies upon Blitz returning collision normals and locations, which then get passed to the ODE DLL and used to generate all the collision contacts. MESHESINTERSECT doesn't return either of these vital bits of info." Hm... well then you could write your own meshesintersect function. :-) "On my version the front wheels react smoothly and turn smoothly as you steer - there are no sudden changes or flicks at all." I don't think you understand. Imagine the wheel assembly is like so: o-|-o ..X ..| o-|-o Each of the o's is one tire. Now notice the X. When going off a jump, whatever is at the X acts like one of the wheel joints. It rotates around the center axis of the car. Thus when the left front wheel goes up, the right one goes down. This is where the front wheels are rotating. In order for them to DO that, you must either have placed a joint there or something is not being constrained properly. That X is where I was saying it would be better to have a spring rather than a simple joint, and that no joint at all would be better than having one that doesn't have a spring on it. You coould be right that this is not realted to the physics at all. However, when driivng the car and landing it does seem to affect how fast the car can move forward until it resets itself. "So if you get any visual weirdness when driving on the flat ground plane, then it's not affecting the physics system at all." When I jump off the track, the tires snap-roll to one side. then when I land on the infinite plane this cuases the car to behave improperly, but eventually it sorts itself out and drives around normally. |
| ||
| Ah, I see. What you're seeing is rotation around the actual position of the front carwheel joints - they used to be located at the centre of the wheel they control, as you find in real life (almost), but this gave the car a tendancy to topple over it's own front wheels as it cornered. Therefore I experimented with the position of the joint and moved it backwards and inwards relative to the (front) wheels. To change this, you just need to alter the position parameters of the appropriate CREATEJOINT function call within the Blitz program. The ODE doc I wrote tells you which these are, but it should be simple enough to find it via trial and error anyway - there are only a few parameters. The approach you're describing, where the left wheel goes up as the right goes down, sounds very much like an old live-axle vehicle suspension, which you only find on the rear of cars. As each wheel in the ODE car already has completely independent suspension and springing, I fail to see how this would improve the car model at all - it'd just introduce yet another unrealistic variable into the mix. When I jump off the track, the tires snap-roll to one side. then when I land on the infinite plane this cuases the car to behave improperly, but eventually it sorts itself out and drives around normally. As I said before, I've not seen any of this weirdness, except with the unmodified or incorrectly set ALIGNTOVECTOR command, so I can only assume you still haven't changed it as mentioned before, and there is therefore little I can do to help. You may see it as a bodge (can't see why though - it's just altering the command behavior within specified limits), but it works just fine for me and I believe for most others. |
| ||
| Hm... well then you could write your own meshesintersect function. :-) Well there is a collision system called TRICOLLIDER, that is being used with ODE by many people (outside of Blitz). I've looked at it but it goes a bit above my head. I believe however that somebody else here on the forums said that they were creating their own ODE DLL/userlib, that incorporated this library to give perfect collisions, totally unrestricted by the Blitz collision system. I really hope they have something that can be used - ODE combined with TRICOLLIDER seems to be very robust and reliable. |
| ||
| you guys should check out the ridged body physics system in the code archives under algorithms |
| ||
| Yes, I wrote that one also, and it's just a spring and mass system that can be used to simulate some forms of ridid(ish) or deformable body. It's certainly not any form of full physics system. |
| ||
| has anyone been able to port anything stable to a dll or package something other than a basic Verlet engine? |
| ||
| If someone is going to write a wrapper, do it for this... http://www.tokamakphysics.com/ |
| ||
| thanks for the info brad i will take a looka t this tool |
| ||
| I managed to do a wrapper for Tokamak and used it successfully with Visual Basic. I'm currently making a wrapper for Blitz, but I want permission from the Tokamak creators before going any further. |
| ||
| A wrapper for Tokamak would be great. I hope you finish it. |
| ||
| Sweenie, No doubt! i would be all for that. |
| ||
| Cool, go Sweenie! |
| ||
| http://www.adamdawes.com/programming/tokamak/index.html VERY liberal license agreement 1) The LICENSEE may not redistribute the SOFTWARE, except as part of a compiled software program that is not itself a physics library. 2) The LICENSEE may not use the SOFTWARE to reverse engineer the computer algorithm used by the SOFTWARE. 3) The LICENSEE agrees to credit the use of the Tokamak physics library in any program information, including splash screens, "About" dialogs, program notes or instructions and shrink-wrapped packaging. 4) The LICENSEE agrees to notify Tokamak Physics (the Company) of any products, commercial, shareware or free that incorporate the Tokamak library. 5) The LICENSEE agrees that the Company can refer to any such product as described in item (4) in its promotional material or press releases unless a specific agreement is made with the Company prior to its usage. looks like as long as you: 1. mention and credit Tokamak 2. Tell Tokamak what your did/ are doing 3. allow them to advertise for you! 4. do not reverse engineer or sell/release product as a physics library you are golden. I am sure that if Mark wants to incorporate Tokamak 1.x into Blitz, he very well could with Tokamak's permission |
| ||
| Finally I got an answer from the Tokamak staff. They will let me create the wrapper as long as I don't distribute it myself. That means that as soon as I've finished the wrapper it will be available for download on their website. Starting to get a little nervous, as it feels as alot of people are watching my progress... ;) hehe One thing that is worrying me a little is that the agreement is that I create a dll which in turn calls the TokamakDLL. I'm not sure how much this affects the performance of the physicsengine. I will do some speedtests and if the results show a large loss of speed due to API-call overhead I will beg them, standing on my bare knees to let me integrate the physicscore inside the wrapper. I've already simulated 500 cubes and spheres falling into a hollow box with acceptable framerate. You are welcome to check the tokamak site , but I will let you know on this forum as soon as the wrapper is done. //Sweenie |
| ||
| Sweenie, What will the edn user agreement for those of use who want to use it? If it removes the developers ability to sell a project using it without releasing their sourcecode, or anything like that, then I will continue my plans to eventually release the verlet library i've been working on. |
| ||
| I think Tokamak only requires you put their logo on your game so people know you used it. |
| ||
| Hmm interresting.. will have to see the speed results. |
| ||
| A wrapper for Blitz would be fantastic. For the future, this needs to be a BlitzMax module. Whether written by Mark or someone else, isn't really imperative, but it would make BlitzMax so much more of a saleable product to be able to advertise in-built integration with the Tokamak physics engine. |
| ||
| sweenie. good for u. Are u using any worklogs on this site? |
| ||
| well, I've got my physics engine to the point it can quickly and easily be set up for simulating about anything... cloth, chains, vehicles, grenades, yada yada. :) Going to work on adding boyancy and allowing Constraints to break when they are stressed too far(Aka: blowing doors off hinges, or smashing car doors off.... or.... hmm anything that you want to break apart. After that I have to add ragdoll junk and it's done. Since we dont have fast polygonal collision I'll probably set up a kludge system to allow object stacking realistically. |
| ||
| I just got a good laugh watching the jeep in my game get blown off a cliff by gale force winds :D... HAHAHAHA. ;) Good times for sure. |
| ||
| shattered. have you implemented a friction loss point. ie when your jeep drives around a corner, when the centrifugical force exceeds the friction with the ground, the car slides, or drifts. Other implementations i have seen tend to break loose then grab again immediately. are there any joints and springs? |
| ||
| as for friction, I have the code in another program to allow an object to slide with linear momentum at a certain friction value. So, when the friction value of the tires in contact with the ground is overcome, the vehicle would slide, yes. I think I'll spend more time on the vehicle physics though. |
| ||
| @ShatteredReality, I believe it's like AlmoAtAcclaim says. You should be able to use it how you like as long as Tokamak gets credits for their work. @Baudspeed, I will start using worklogs. The internal speed of Tokamak is fast. On my computer it performs all physics calculations for 256 cubes on 1.9 - 3.5 ms depending on the number of collisions. The speedloss may occur when fetching the position and rotation info for all 256 cubes. Currently i'm doing it the "Blitz" way. GetRBx#() ; position GetRBy#() ; position GetRBz#() ; position GetRBqx#() ; quaternion GetRBqy#() ; quaternion GetRBqz#() ; quaternion GetRBqw#() ; quaternion That is seven API-calls just to get the position and rotation of one rigidbody. It would probably be faster to pass a BlitzBank or a structure/type and fill it with the values. That would bring it down to One API-call. Testing will be done. Perhaps the Object/Handle thingy could be used. *nutch, nutch* But all the talk about their *unofficial* use, makes me a little unsure wether to use them or not. |
| ||
| They are pretty official AFAIK. Mark said he had no plans to change them. They might change in BlitzMax or something? |
| ||
| tokamak is very impressive. Anything I can do to help you finish this, and I'm more then glad to do it. |
   |