verlet physics update
Blitz3D Forums/Blitz3D Programming/verlet physics update
| ||
| Okay I went through version 4 of the verlet VW code and i did a massive cleanup of the code, reformatting it, adding comments where I could, adding comments telling you when I haven't got a clue what is going on in a particular area so that someone else can comment it, and seperating the demo from the verlet lib itself. Still needs a lot of work, but at least now the code isn't triple spaced. :-) I included all the media and stuff in case anyone wants to try it out who hasn't already downloaded that stuff. Doesn't include any of the newer media cause the version 4 demo didn't use that. http://home.earthlink.net/~sswift/verlet-001.zip Also, if you can, try to link to code instead of posting it in the thread or we'll have to start a new one. :-) |
| ||
| Mr. Swift, You're a gent - thanks. IPete2. |
| ||
| Hm... I'm trying to figure out how to get the car to reverse in the right direction now, but it's proving to me more difficult than it should because of the extensive use of globals that I don't know where and how they're being used. I wonder what the best way to remove all those globals and do the steering is... Hm. The steering I think is kinda funny the way it's implemneted now. I think that when you steer, it should just rotate the wheels, and then each update acceleration should be applied to the wheels alone, and not to the body of the car like it is now. Then the tries can slip or stick individually based on whatever their own current speed is. |
| ||
| thank you swift for taking the time to do clean up and host it. originally, when i was trying to figure out how to provide player contol to a structure that has no clue about its orientation, i parented everything temporarily to a pivot, moved the pivot, then unparented it. well this is not a good way to do it. so i started to move player control to a per verlet calculation. the forward/backward (z axis)acceleration was partially finished (thats why its such a mess), and i never had time to finish converting the left/right (x axis)turning over to per verlet calculations. but the heart of how it works is basically this. the center verlet is used to locate a master pivot to the entire structure. this pivot initially only follows the xyz movement of the center verlet. now two verlet "sets" help orient that pivot to the overall orientation of the structure. one set of two define a z vector and the other set define a x vector. now we can orient the master pivot to those vectors so we can derive an yaw,pitch, and roll value. now that we have these orentation value we can then transform the "global" xyz vectors of each verlet relative to the master pivot. once we have transformed the vectors we can then do some math on them that makes sense to a vehicle. so in the do verlet function youll see two sets formulas, those relative to the master pivot (which btw is called player_pivot) that are used for the wheels and another set that dont care about any orientation that remain global vectors for the body verlets. for the wheels we need to do passive calculations, like the wheel slip to both the current and old values or else the vehicle will widly spin out out of control. for the active calculation like steering we simple add them to the force accumlator because they are the acceleration value we talked about in the prior post. i never finished the conversion from the hack i was using of parenting to doing it the right way as i just tried to describe. ok the way im doing wheel slip or static friction for the wheels is, i define a threshold and a max value in the wheel force function. this is only for the x vector relative to the player pivot after transformation. the values that you can plug into the wheel function are currently based on crude way of calculating how much force is being applied to the x axis of the wheel from turning. the threshold is the point at which the wheel begins to slip and max is the vlue at which the wheel is allowed to fully slide. the out put of the wheel force function is 0 to 1. where 0 is no slip (x velocity is multiplied by 0 hence no slip) and where 1 is full slip (x velocty multiplied by 1 hence its the whole value). another part that prolly doesnt make sense is the fact that i have different mass value for different axis (relative to player_pivot). let me try to explain why. since i couldnt find a way to control the actuall stiffness of a spring (constraint) i did notice that if i changed the mass of y axis of the wheel to MUCH lower than the verlets it connects to that the end result was a squishy suspension. but i only wanted it to be squishy in the z axis (relative to the player_pivot) and not the other axis. so for both x and z its a higher number. thats all i got time for now. i will help try to answer any questions as they come up. once again thank you swift for the work you have done. |
| ||
| Hmm... I think maybe I'm gonna just write my own verlet system from scratch, because there's just too much extra stuff in this system and I want to fully understand this whole thing. I found this website. It's by the guy who wrote the article on Gamasutra, and there's an additional verlet realated presentation which I think presents some new information like how to do angular constraints and hingers and pin joints, though I didn't go back to check the original article to be sure. http://www.ioi.dk/Homepages/thomasj/publications/index.htm I want a system which will work in a physically accurate way with the wheels themselves actually providing the thrust, because that's really the only way to create a generalized system where you can simulate anything, and I like generalized code. :-) Here's an updated version of the verlet test program. I just basically did some more code formatting, moving the particle, camere, and input code out of the main loop to clean it up. http://home.earthlink.net/~sswift/verlettest-003.bb |
| ||
| You cant really do rolling motion using particle phased method (unless you use huge amount of particles as a circle)... so that's (allmost) impossible to make the wheels to provide the thrust... You have to use the good old ODE solver to do that, where you actually calculate rotation. |
| ||
| double post... sorry |
| ||
| Good stuff! It is much easier to understand and use the vertlet stuff now that you've cleaned it up and separated the vertlet code from the rest. I just uploaded the code from my demo to www.moondoggieent.com/blitz_racer.bb My primary additions to the code are the added speedometer and improved chase cam (both things you might want to add to your cleaned up code.) The chase cam in particular I like a lot because I introduced a little lag so that the camera doesn't turn exactly along with the car, smoothing out the camera movements. |
| ||
| "You cant really do rolling motion using particle phased method (unless you use huge amount of particles as a circle)... so that's (allmost) impossible to make the wheels to provide the thrust..." The way he does things now I think, the tires have a collision sphere, and if that collision sphere is colliding with the ground, the car can move forward. But all thrust is applied to the car. I'm not really advocating making the itres themselves roll, and having that rolling motion provide the actual thrust. Instead what I am suggesting is a method like the above, but where the TIRES themselves are allowed to provide thrust to themselves when they touch the ground individually, and in turn their contrained connection to the car, via springs, is what actually pulls the car's body forward. This would allow each tire to slip and grip individually which is needed when you whip the back end around cause the front tires aren't moving much when that happens and they should still be in stick mode. Also, in the current system you get just as much thrust if one tire is touching the ground as you do if four are. The result seems to be that the car jumps if a tire touches the ground by itself, and flips around uncontrollably. Hm... There is one thing that confuses me though. When I dump the car over on it's side, I can make it spin around in a circle. Is that possible if the thrust isn't being applied to the tires themselves rather than to the car body? Hm... "(both things you might want to add to your cleaned up code.)" I would prefer that people just add stuff to the cleaned up code themselves and work off that. I don't have the time to add lots of stuff to this engine, I just thought I'd help out a bit since I wanted a cleaner version of the code to look at myself so I could better understand what was going on. |
| ||
| hmm. yeah. I'm trying to write a generalized verlet system. (As I've brodcasted many times) Anyway, If you have any problems, ask me. I've been working on mine for quite some time, and have done most of the things outlined in the Thomas Jakobsan articles-verlets,constraints, some friction, and my own collisions. Of course, no demos as impressive as dmc's buggy. Oh yeah, and I might post a list of comment-corrections/removing the "what does this do?" comments. |
| ||
| swift you wrote: "The way he does things now I think, the tires have a collision sphere, and if that collision sphere is colliding with the ground, the car can move forward. But all thrust is applied to the car." your partially correct. the part that is true is thrust is only applied when the wheels are in contact with the ground. but if you look closely you will see that there is an if statement that checks if its a front wheel or rear wheel. i only apply thrust to the wheels not the entire body. this is for the z axis. so its basically a 4 wheel drive car. "Instead what I am suggesting is a method like the above, but where the TIRES themselves are allowed to provide thrust to themselves when they touch the ground individually, and in turn their contrained connection to the car, via springs, is what actually pulls the car's body forward." that is how it is working now. "Also, in the current system you get just as much thrust if one tire is touching the ground as you do if four are." in the original code it did exactly what you describe, but i turned it off because the wheel bounces so much that car did not maintain its speed very well. so this is very much on purpose for playability reasons. |
| ||
| I don't think that moving the application of force from the car body to the wheels or vice-versa would make much difference. The ODE cars had the thrust provided by the front or rear or all four wheels, using rotational movement (what you describe as the ideal case), but the car still swapped ends in an instant and was generally not that much fun to drive. ODE even allowed soft contacts, but still you couldn't get a realistic car model because in the end the friction between the wheel and road was constant, and it either gripped and stuck or it bounced, leading to an on-off grip situation. A "rubber tire -> ground" friction model is what the simulation needs. As I understand it - if you look at the force a tire experiences when it corners, it can grip and grip until a certain level of total loading is reached, whereupon it starts to break and gradually or rapidly (dep. upon the tire) starts to slide and the traction level drops right off. The total force upon the tire must then be reduced (by slowing down and/or turning the steering) until the level is reached where the tire can grip again. Note that the regaining grip level is lower than the level at which the tire broke in the first place (presumably due to the way in which the tire reacts as it slides and heats up etc...?) Have a look on the net for tire force-circles and you'll see the effect. Alternatively, download Richard Chaney's excellent car demo and you can see the force circles displayed on the screen. Note that even in his demo, the car still displays a tendancy to flip into oversteer. http://homepage.ntlworld.com/richard.chaney/cardemo.zip |
| ||
| "But if you look closely you will see that there is an if statement that checks if its a front wheel or rear wheel. i only apply thrust to the wheels not the entire body. this is for the z axis. so its basically a 4 wheel drive car." ""Instead what I am suggesting is a method like the above, but where the TIRES themselves are allowed to provide thrust to themselves when they touch the ground individually, and in turn their contrained connection to the car, via springs, is what actually pulls the car's body forward."" "that is how it is working now." Okay, I didn't look at the code yet, but assuming what you're saying is true, then it's working more like I want, but not exactly like I want. Right now, you are calling the function, passing it the car, and the acceleration for the car. Then, I guess if what you say is true, you're acting on the WHEELS inside the function when you passed it the car. The way I see a proper system functioning would be to call DoVerlet once for each verlet object in the world, or for none at all, having the function iterate through them seperately and add any acceleration you want added this frame. That way I could easily change the code on the fly to apply force only to the front tires, or only to the back tires, and there would not be a difference ebtween tires at all, and I could make a six wheeled vehicle with two sets of turning tires if I so desired. Also, because you only have one acceleration parameter, you don't have the ability to specify an acceleration in any direction you want to. So for example, there's no way to suddenly give the body of the car a sudden vertical push if it goes over say, a fan, or to give the tires a sudden downward push to shove them into the ground which should make the car jump. ""Also, in the current system you get just as much thrust if one tire is touching the ground as you do if four are."" "in the original code it did exactly what you describe, but i turned it off because the wheel bounces so much that car did not maintain its speed very well. so this is very much on purpose for playability reasons." Okay, but I suspect that this is because you modeled the tires in a funny way. You don't have any actual springs connecting them to the body, and they don't have a correct mass because you used the mass to fake a spring effect. The thing about springs is they're used in cars to keep the tires sticking to the road even when the tire goes over a bump. So I think that exchanging the stick constraints with a spring constraint would solve that problem. If I knew which constraints in the code were the sticks connecting the tires to the car body then I could attempt to create a spring constraint and test it out. I need to know which ones go up and down. I'm guessing that you chose to use a single constraint that can go up and down. I need to know which one that is for each tire. Another way to connect the tires to the body would be with two stick constraints and a spring, in a tetrahedron type of formation, connected to a triangle of sticks which are fixed in position on the car. Then you wouldn't need an axis constraint on the spring. I dunno if that would make things more stable or less stable though. |
| ||
| "I don't think that moving the application of force from the car body to the wheels or vice-versa would make much difference" It's not mainly about changing the driving model. It's about fixing the system and the model so that it works in a logical way. You don't want to have to have a specific function for doing the physics for a car, and a specifc model for a rig, and a specific mdoel for a six wheeled moon rover with really springy shocks. So that's why I want to seperate the force the tires are exerting from the car. Personally, I like the driivng model like it is now. Actually, I kinda liked version 3 the best. The version I put up, when you turn sharply the car doesn't lose traction and spin around. I liked that, I just thought it needed a little tweaking so it was a little harder to do. Also in this version you can't turn as sharply when you're moving at a high rate of speed, which may be responsible for the lack of ability to spin the car around. In fact, I would like a driving model where the car only rolls over so far and then stops. It's no fun if the player flips over onto the roof when going over a jump. Unfortunately, I don't know if it will be possible to do that... Then you couldn't make the car go around loops! :-) But I guess one could forgo the loops since it doesn't seem like the car is going to be able to go around a loop without a lot more physics. :-) |
| ||
| I would have thought the car could do loops as it is. It has problems with banking and such like though, as the polygon seams (ie. the bits where one poly joins the next at an abrupt change of angle) cause the wheels to loose grip and / or bounce. It's currently pretty hard to corner on the raised spiral thingy, due to the harsh poly angles. Unfortunately there's no way around this apart from a) increasing the poly count to smooth edges, or b) making the contacts slightly soft (ie. allowing penetraction). I quite like being able to flip the car over (currently though it's a bit too easy to do). |
| ||
| "I would have thought the car could do loops as it is." Well, right now if you fly at the tall curved wall really fast, then the physics breaks if you hit it too hard. And I'm guessing that even if the tires didn't flip around, the car would still either get stuck, or would not make it around because the forces wouldn't be balanced right and the wheels would stop touching the surface halfway around the loop. Of course I'm just guessing, but as the car can't even go off a jump at high speed now properly or consistently, I think my guess is a good one. By properly or consistently, I mean that when I go off jumps at high speed a lot of the time the car isn't launched into the air properly, and as a result doesn't fly as far as it should, or just flips end over end. Of course it's not so bad as to be unusable. It just isn't very physically accurate. "b) making the contacts slightly soft (ie. allowing penetraction)." I think you mean penetration. :-) Actually now that you mention it, on that site I listed, it shows a method for calculating friction based on the amount which an object penetrates a surface. I don't think this code currently does that, but I'm not sure. I think it's more accurate if you do it that way instead of just using a generic ground friction when the wheels are in contact with something. Maybe it would help make the steering more realistic. |
| ||
| I like the ability to roll it too, though not when it comes too easily (and it would be better if it was (more) possible to roll back up the right way. BTW I take it you guys have read the Marco Monster tutorial? This covers the tyre[/tire] stuff in detail that even I can almost grasp... http://home.planet.nl/~monstrous/tutcar.html |
| ||
| Another brilliant link, thanks for that one :) Where do you get all these links? |
| ||
| That code of Marco's is the stuff I converted to Blitz way back in the dim and distant past, which is in the code archives. Yes, I did mean penetration. Whoops! I think it would help make the movement more realistic and predictable. |
| ||
| some more answers i hope are helpfull for you swift. "Okay, but I suspect that this is because you modeled the tires in a funny way. You don't have any actual springs connecting them to the body" im not sure what you mean. if you mean code that uses correct physics for a spring? if so then yes i dont have that. but each tire does have many constraint springs connected to verlets that represent the body. heres a list of what the connections are for the tires. verleta and verletb are front tires. verlete and verletf are rear tires. verlets c,d,g,h form the roof of the car body verleti is the center verlet that the player_pivot is tied to. so here is one of the front tires, verleta, is connected. the following 3 are consider edge connections (imagine the edges of a cube) Constraint2(verleta,verletb) from tire a to tire b (parrelel to x axis) Constraint2(verleta,verletd) from tire a to roof body d (parrellel to y axis) Constraint2(verleta,verlete) from tire a to rear tire e (parellel to z axis) the next 3 are cross face connections (imagine a dice, look at a face on the dice and draw a line diaganol corner to corner across that face) Constraint2(verleta,verletc) tire a to roof c Constraint2(verleta,verletf) tire a to rear tire f Constraint2(verleta,verleth) tire a to roof h the next one is a connection that travels thru the middle of the imaginary cube. (hold a dice so that you are looking directly at one face. pick a corner of that face and draw a line thru the middle of the dice to a corner of a face on the opposite side) Constraint2(verleta,verletg) tire a to roof g the last type of connection is the easiest. every verlet is connected to the center verlet. you also wrote: "and they don't have a correct mass because you used the mass to fake a spring effect." actually if you think about it the wheels having a much lower mass is very realistic. how much does a tire/wheel weigh? lets say 75 pounds. how much does the body of the car weigh? a ton? so that part is correct. you DO want the wheels to have a low mass. the part about faking a spring effect, yeah i admit i have abosultely no clue how to code a real spring. so maybe if you know how to do that it could take the sim one step closer in realism. "Also, because you only have one acceleration parameter, you don't have the ability to specify an acceleration in any direction you want to. " it is typical to accumulate all your forces, or in our case accelerations, before you send them to the integrator. the code has one line that is messing this all up. if i fixed it you could accelerate the car in any vector direction by storing them in the accululator, vGrav.Vector = Vector(0.0,9,0.0). the reason it isnt working properly is i am resetting that accumulator in the main loop. thats one of the bugs that needs to be fixed. but it is a VERY easy fix. |
| ||
| I have played with all the demos for this thing you guys have put out (thus far), and have to say, alghough fun, its very very unrealistic. I dont mean this as a complete cut, but more in refference to what Sswift has said, "It needs to be fixed to act in a logical way". I have driven off road many a times, and played many a game where they try to simulate it. To me (aside from looking at the code, which I am not going to do at the moment) it seems as if everything is being based on collision (wheels colliding with this, body colliding with that, etc) and not on force (or not enough forces involved to affect the result). Things to always consider: Weight of the body Weight of each tire Tension of Springs Pull flex of springs (they can go further then their pre-made length) Bounce of the body (There is some flex in the frame, and in the metal, weather it shows damage or not, a bounce of a car frame does rely on the flex of the frame). Bounce on the wheels Points of refference (with a veichle, the wheels of course, and also a few key points on the body ie: 2 along the roof, one on each side of the body, 2 in front, and 2 in the rear). This gives you roll forces, and opposing forces (which creates roll inertia). Grip factor on the tire (and indirect formula with torque vs ground speed to apply the grip) This also applies movement based on collision (angle of polygon collided with direction of pull on body (intended direction of wheel)) Just a few things to factor into a good driving sim. I'd be happy to help out with some of the math, however I am scared to get too side tracked (it always pull me away from my current project, and you know how that goes).. |
| ||
| no offense dark half but we already have enough people pointing out its weaknesses. thats easy, anybody can do that. it would be MUCH more productive to contribute code rather than sit safely back and pick it apart. |
| ||
| Dmc I think you're taking this too personally, I think his suggestions for how to improve the model are useful. Though I personalyl don't have an interest in creating the perfect driving sim. I just want something that drives in a fun way, and is in fact, unrealistic. For example, I like how the car bounces off walls when it hits them. Getting stuck up against a wall is really annoying in Crazy Taxi. |
| ||
| no offense dark half but we already have enough people pointing out its weaknesses. thats easy, anybody can do that. it would be MUCH more productive to contribute code rather than sit safely back and pick it apart. Fine. You'd be interested to know that I DID start my own version of the program (about 4 hours ago), just because I think the model would come in when i do persue a driving sim. Tell you what though, just because of your comments, I doubt i will contribute the code to this thread (weather its an improvement, or not, YOU'LL never know)...... Good Day , I think his suggestions for how to improve the model are useful. Though I personalyl don't have an interest in creating the perfect driving sim. I just want something that drives in a fun way, and is in fact, unrealistic. For example, I like how the car bounces off walls when it hits them. Getting stuck up against a wall is really annoying in Crazy Taxi. Weather its the perfect model or not, with more advanced forces (and control), you CAN do wacky things with the physics (IE you want to make the car bounce like its on a pogo stick, merely up the flex var for the body, and for the shocks, or you want to have the car do big air jumps, down the force of the gravity, and down the drag). The point is, with more control over forces (and more forces), you can really pull off some cool demos (pure fun) |
| ||
| people can throw all the darts they want, but god forbid i try to defend it. on a more productive note, and vorderman you may be interested in this, ya know how the wheels start to bounce and that causes problems getting a clean slip? well i just did a test and the results are interesting. i took out the portion of the code that checked if the wheels left the ground which would then prohibit the state change code to take place. the bounce effect while under forces from turns has dropped off significantly. it appears that if the code had a way to predict the difference between it just oscilating up and down fast versus it really leaving the ground for more than a couple millisecs that the perfomance of the wheel slip routine really starts to look good. |
| ||
| "people can throw all the darts they want, but god forbid i try to defend it." But they're not throwing darts. They're just saying what could use improvement. I just think you're being TOO defensive. Surely people will present some ideas you may not have thought of. But if you act so defensive when folks offer suggestions then they might not feel safe in making comments. "The point is, with more control over forces (and more forces), you can really pull off some cool demos (pure fun)" Well yeah. But I like stuff to be simple. I made a a simple flight sim, and the number of variables to control became overwhelming when trying to make a model which worked well. |
| ||
| "it appears that if the code had a way to predict the difference between it just oscilating up and down fast versus it really leaving the ground for more than a couple millisecs that the perfomance of the wheel slip routine really starts to look good." Hm... That may be so, but I don't like the idea of averaging things over several frames to dtermine the outcome. I would prefer to find a solution which involves forcing the tires to stay on the ground with springs. Maybe the solution is to use two springs. A short squishy spring to simulate the rubber of the tire, and a stiffer longer spring to simulate the shocks. The squishy spring would compress easily, and would expand quickly, keeping the tire ont he ground longer when the car lifts off the ground. The stiffer srping would allow a lot more motion, but respond more slowly to changes. |
| ||
| thats an interesting idea.... i think i see what your saying. heres an odd thought along those lines swift.... instead of using a spring to represent the rubber could you vary the radius of the collision entity using spring math? and if you did vary the radius would that break the blitz internal collision functions? |
| ||
| woo. heated discussion. Anyway, I think that the major thing to fix would be unreasonably far bounces. bouncing on collision isn't to bad of a thing, but when the car decides to spontaneously shoot of into the sky, that's rediculous, and not very fun. If everything was realistic, it wouldn't be very much fun. You wouldn't make insane stunts or jumps. I think one minor adjustment would be to implement more realistic air friction. I forgot the equation, but I think it's either drag=coef*vel or drag=coef*drag^2 . Maybe try both? simply apply this to the verlets. this way, even if it does try and go shooting off, it will radically slow down. |
| ||
| Maybe, instead of using Blitz collision on the wheels which instantly forces them to be in perfect contact with the ground, you can use a sphere->poly check to find out whether the wheels are penetrating the ground (or other objects) and then move them back along the collision normal, at a speed dep. upon how bouncy you want the rubber tires to be. Maybe that would simulate soft contacts? Basically that's how it works in ODE - you set an error correction level that allows intersection but works it out and resolves it over a number of frames, so objects penetrate but then slowly (or quickly dep. upon how you set it up) push apart from each other. I think you'd need to log the normal of the first collision and then use that until the objects were apart. Having just written that produces all sorts of images in my mind of situations and geometry where it'd fall over. Hmmm. Maybe log all collisions and normals and average them? |
| ||
| "instead of using a spring to represent the rubber could you vary the radius of the collision entity using spring math?" As you said, if you alter the collision radius of an object in Blitz, it's very likely that the collision code will mess up and the object will pass through the ground without registering a collision. "this way, even if it does try and go shooting off, it will radically slow down." Another thing one could do is cap the velocity of any verlet at some max value that's beyond what any object would be expected to travel at. Would have to be a constant you could change though cause everyone uses different units of speed. |
| ||
| sswift i have time today to do a pass thru the code and comment and further clean it up. is there a way i can get it to you so you can host it? i dont have web hosting. all im doing is making more understandable (i hope) and improving some of the basic systems. not making huge changes in functionality. |
| ||
| dmc stated that there are verlets for the roof of the vehicle to which the wheels are connected. Could we not have a verlet for each wheel, which connects to the tire? This would be additional, and would only connect to the tire and across to the corresponding wheel. It could act like an axle. (Example. The two verlets for the front wheels would connect to each other and the tires.) |
| ||
| Didn't I post in here about how to make a spring constraint? Or am I going nuts? |
| ||
| Thanks for the code guys (especially for dmc for starting it all). I had been thinking about making a small stunt racer style of game and this will help immensely. I've spent a lot of hours going through the code to clean it up and make it easier to read for myself. I've gotten rid of most of the global vars (by adding them to the VObject which I think is where they really belong) and fixed the reverse steering issue. Once I'm done I think I'll look at modifications etc. (this is a learning process for me as math has never been my strong point) I was reading one of the links posted here on car physics and I might try changing the DELTA_TIME value to see if that stops the wild out of control values that can happen in certain collisions. In any event, just wanted to thank you all for your contributions. |
| ||
| "Didn't I post in here about how to make a spring constraint? Or am I going nuts?" Evidently you're nuts. :-) "is there a way i can get it to you so you can host it? i dont have web hosting." Just email it to sswift@... |
| ||
| Okay, so here's how to make a spring: Instead of having the constraint routine automatically force two verlets to be exactly the constraint's distance apart, you modify the routine so that for some "springy" constraints it'll only move the verlets a fraction of that distance per iteration. A rigid spring would move the verlets, say, 80% of the distance; a soft one, only 20% or so. This way the verlets will slowly go back to where they ought to be instead of snapping taut. |
| ||
| Here is stuff I have written down on how springs work. Don't ask me what a "logarithmic impulse formula" is for. I don't know. I just copied down equations that looked important. -------- SPRINGS -------- http://www.pcug.org.au/~apurdam/doublespring/doublespring.html two masses, connected by one spring: M1, M2 = masses k = coefficient of stiffness of the spring x1, x2 = the displacements of the masses from their positions of equilibrium x1'', x2'' = the acceleration for M1 and M2 r = viscous damping x1', x2' = velocity of masses (from previous frame?) x1''= k / (M1*(x2-x1)) - r*x1' x2''= k / (M2*(x1-x2)) - r*x2' misc notes: Logarithmic Impulse formula. Impulse = Log(RestSpan) - Log(CurrentSpan) Note: this is a different from the usual linear spring formula which is taught in physics classes. With the logarithmic formula, it should be impossible to completely compress the spring. It also means that springs that have long rest lengths vibrate much slower than short ones. |
| ||
| Did some research on the impulse method. apparently it's good for rigid bodies/ basic articulated bodies, but not good for say people or mechs. Perhaps you could have it as another type of constraint??? Though it appears that the main focus of the system is rigid body, so it should be fine. |
| ||
| Hi ! I'm french and my english is very bad. I ve spent a lot of time to understand how it works . . I try many different parameters to see what happenend, but i dont' really understand how it's work, If someone have link on Verlet physic to help to undesrtand , thank ? thank to DMC and Sswift to share this ... |
| ||
| this? You'll just have to register to gamasutra. |
| ||
| bot builder: be ready for some hard maths then... verlet "physics" is very easy compared to all traditional approaches. "Perhaps you could have it as another type of constraint???" You can't have it as "another constraint", as it's entirely different method of handling rigid bodies. |
| ||
| "You can't have it as "another constraint", as it's entirely different method of handling rigid bodies." Are you saying that you can't use springs in a verlet based system, instead of using only sticks? Because I read the article by the guy who came up with all this stuff, and he indicates that you can use springs and angular constraints and all that good stuff just fine. |
| ||
| I was talking about the impulse based method of handling rigid bodies. As for constraints as springs and joints. They are easy to implement. You already have them. Springs are what keeps your verlets together. If you want flexible sticks, just make them contract over several frames. If you want hinge joint, just fuse a couple of non colliding verlets together by using a stiff spring with normal lenght of zero and voila! Angular constraints are just springs working only one way.. they keep points from coming too close, but don't restrict movement to the other way. In my 2d engine... these were easy to implement, but friction was hard, as I noticed you are strugling with it also. After a few days of trying I managed to come off with very good friction modelling, but in your case (the tires) it's much more difficult. Good luck. |
| ||
| "Angular constraints are just springs working only one way.. they keep points from coming too close, but don't restrict movement to the other way." Only to a degree. If I want to connect to verlets and keep the angle between them from becoming less than 45 degrees, then yes, I can do that. But if I want to constrain the verlets to between 45 degrees and 90 degrees apart, then I need to do a little more than just make sure they don't come together. :-) Also, there's more to doing springs than just "making them contract over several frames". You have to do it a certain way to keep the speed the same regardless of how many iterations you do, or whether those iterations take different lengths of time. And yeah, making hinge joints and pin joints is easy. But what about a joint which is like a tube on a rod, with a rod sticking out of the tube? Slide up and down, and rotate around the axis, but can't pivot up and down. There's a lot of more difficult types of constraints to implememnt that you might not be able to make with simple verlet constructions. :-) |
| ||
| Perhaps I misunderstood the whole impulse thing. I was under the impression that it was simply a more complex method of handeling springs. I guess then that it is an integrator scheme? sswift: One way you might handle the rod and tube situation is to create a constraint that takes three verlets. two to define the position and angle(just pitch/yaw) of the tube, and one to define the end of the rod. then have some values giving minimum distance, maximum distance, and possibly movement friction. then simply check if the end of the rod is below the minimum or maximum, and reposition. Finally, check if the end of the rod is in the line represented by the two tube verlets. moderatly complicated, but it outa work......... as lon as you don't have a negative minumum. then you might require 4 verlets...... Oh yeah, I know that verlet is simple. no calculas or anything like runge kutta etc... Yet it is surprisingly stable and fast so it's a pretty good choice for games. |
| ||
| I think that verlet is the best choice for games... Try using any other method to stack, say 10 boxes or whatever objects... it's impossible. For example in ODE you can't stack anything and expect to be stable :) Srping physics using verlet integration + Simple + Stable + FAST + With enough iterations and good collision handling, it's also very accurate. - Perfect friction modelling hard to implement - Balls are very hard to model, because particles don't have orientation. - Accumulation of kinetic energy because of spring-structure. Makes it hard to control elastic properties of an object. (this one is the most anoying) - Exploding of objects (not a problem with more timesteps and properly placed constraints) |
| ||
| I definatly agree on verlet being the best known integrator games. Yeah. that's a pretty good summary of pros and cons. Another pro is that even if you already have a system handeling non-physical movement(blitz), it's easy to continue the motion of an object before physics was turned on. I'm not entirely sure of the first part of the most annoing problem, but I think it may have been solved by the author of Advanced Charachter physics. Infinitely strong strings. immediate correction. |
| ||
| Even though the springs connecting the particles are infinetely strong, that doesn't solve the problem. When you solve multiple constraints, the kinetic energy still accumulates to the object, because when you correct one spring in a multispring body, it will make some other constraint to go out of limits. This is why you have to use more iterations. The more complex constraints, the more iterations you need for the constraints to be satisfied correctly globally. In hitman it certainly hasn't been solved. They use as many as 10 iterations for the bodies. And in Hitmans case it really is not such a problem anyway, because there's no body to body collisions, only body to static scenery, where the kinetic energy doesn't become a problem. You start to see problems, when you stack lot's of different weight objects on top of each other with high gravity. With little iterations they interpentrate a little and when you suddenly take of gravity they all go flying in the air. That's because the kinetic energy is released, which is formed by the constraints not been solved globally. But 4 iterations is enough in most cases to solve very complex scenario if the objects are moving at reasonable speeds. |
| ||
| Back to the inverting verlet problem for a second ... what would happen if you did a movement phase and then a constraint phase each iteration? Say, you did four iterations of quarter-speed movement with a constraint go-round after each iteration? That wouldn't put too much strain on the system, and would allow you to travel four times as fast before you might knock the verlets out of kilter. We may have a problem in that Blitz collisions are too perfect. You can't move a pivot with collisions active so it'll partially intersect something, and you don't actually have any control over where the pivot will end up, so you have to code around that inflexibility. It also makes a difference whether you're using full-stop or sliding collisions. There may be advantages to one over the other in certain situations or control schemes. I dunno. Needs more thought. |
| ||
| That's why I'm not using blitzes system. It's to inflexible. Which makes it easy to use, but in this case it screws things up. the other advantage to custom collision systems is that you can get important values such as penetration distance etc. The main problem is that it takes a while to put together the system, and it would most definately be slower. Unless of course you did specialized optimizations, which is what I'm attempting. This makes it much harder, but hopefully it'll make the system run at a reasonable speed. |
| ||
| heres a little update i have some time right now to work on the code. i was just going to do a little more clean-up but i decided to give it a major overhaul instead. currently i have yanked out almost all the car specific stuff like the part wheel body etc. i have broken down the do_verlet function into a series of sub functions like it should be. so basically the code is WAY more generic right now. im trying to solve the collapsing problem right now it turning into a real stinker. i tried what you said miracle but it screwed up the handling so bad i abandoned the attempt. in summary the good news is its way more generic the bad news is the inversion problem is gonna take time to solve right. |
| ||
| Just one question, may I use this code in a commercial game? |
| ||
| spot, personally i formed an opinion on that just yet. im not sure anybody could stop you even if they were against it. but ill go with the majority vote. see how the others feel about it. |
| ||
| another update: made some great progress on the inversion problem. right now its many many times more stable than it was. but it still needs some work to be "fool-proof" if i can even reach that point. the handling characteristics are getting a little out of whack so at some point im going to have to re-tune the whole vehicle. |
| ||
| Can the direction be determined and then just flip it? If a point is supposed be below another point and the calculations would move the point to the other side, can the code just put it on the proper side? |
| ||
| Have you guys looked at this? http://home.planet.nl/~monstrous/tutcar.html ------------------------- http://www.hpl.hp.com/techreports/2000/HPL-2000-124.html |
| ||
| dangerdave99 wrote: "Can the direction be determined and then just flip it?" its not quite that simple. ill give you an example. lets say you drop the car from 1000 feet. as it falls towards the ground the entire system is building up alot of energy as it travels faster and faster. when it does finally hit the ground the energy that was built doesnt have any way to dissapate. so if we detected that the wheels flipped on the roof and we tried to flip them back much of that downward force still exists for a number of simulation cycles. the very next fram the wheels will be right back on the roof again. so the approach im currently coding is to first detect that a collapse may happen and freeze the simulation, well more accuratly divert to seperate loop, and bleed off the excess energy and allow the springs to relax. by using this method it is possible to prevent the structure from almost never getting into a inversion state to begin with. so to put it simply. rather than try to fix it after its broken, my choice is to prevent it from happening in the first place. so far it working 90 percent of the time. the last ten percent is the hard part. |
| ||
| Here's some ideas: Imagine a tetrahedron. A pyramid with a triangular bottom. Now imagine your tire is connected to the top point of the terahedron. The bottom three points form a plane. You can determine which side of that plane the top point is on. Therefore you can push the top point back if it gets on the wrong side of this plane, just like when you push the point back when it collides with the ground. But when you have a single verlet conencted to another single verlet, or a single verlet connected to just two other verlets you still have a problem. Hm... I wonder if you could somehow give the verlets a quaternion orientation and then use that to determine the location of other verlets realtive to it. Or maybe... You have two verlets connected. Verlet 1, and Verlet 2. Verlet 2 is in motion. Verlet 1 is not. We will call then V1 and V2. But V2 has two positions. V2a, which is where it was, and V2b which is where it's going. That means we have V1, V2a, and V2b... which are three verlets, though two of them are just different locations of one of them. Because we have three, we can calcualte the plane in which they lie. Then once we have that plane, we can determine if V2b is clockwise or counterclockwise from V2a. And if we do a dot product between vectors V1,V2a and V1,V2b, then we know how far apart in angle they are. Hm... Perhaps this information would would enable one to determine if the verlet has suddenly flipped around to the other side of a verlet. That would indicate the spring/stick collapsed completely and inverted, and you could then fix it by going back and collapsing it almost all the way but not enough to have the verlets on top od one another which would destroy the directional information. Hm... Hey wait a minute... I always thought you needed three points to define a plane. But do you really? If you take V1, and V2 in their initial locations in the model, And imagine that V1 lies in the plane, and that the two points goether represent tha plane's normal, then you know how that plane is oriented in space. You don't know what it's ROLL is, but do you need to know the roll of a plane? I'm not sure. I don't think that even if you have three points that that defines a roll at all. |
| ||
| Your right sswift, you only need two points/vectors to define an infinite plane (I don't think Roll is applicable if it's infinite). The first 'point' defines a place in space that the plane crosses through. The second, as sswift mentioned, defines the normal, thus defining the plane. |
| ||
| With a plane, each point has a function. two points defines a line. a plane could intersect the line from many directiions. add another point, and you have the definition of a plane (geometrically speaking). sswift: your method is basically the same as my inversion-solution. an infinite plane on the car body that the wheels have to be below. the only problem is that the physics engine/blitz collisions keep on popping it back on top. |
| ||
| swift heres a more detailed explanation of im doing (and most importantly it is working well). prep phase 1) build the verlet structure 2) store off each verelets position relative to the structures CG. 3) create a distance value that defines if the verlet is about to collapse. we will call this DangerDistance 4) create a distance value that defines if the verlet HAS collapsed. we will call this CollapseTrue begin simulation 1) each simulation tick record how far the verlet has travelled. 2) if the verlet has travelled beyond the DangerDistance but less than the CollapseTrue distance, run a loop that relaxes the structure and updates collision information per iteration of the loop. 3) if the verlet has travelled beyond CollapseTrue then reset its position from the original stored location and relax structure this technique is often used in physics simulation. the way it basically works is you use low fidelity collision information until it reaches a critical threshold, then you turn on the high fidelity collision routines to gain frame by frame control. my method is not perfect for sure. still could use alot of refinement but if you try not to allow the structure to collapse in the first place the springs will auto-solve the problem for you. now to make this even better we should start to use the techniques of sim time control that are common in impulse based physics simulation. basically what happens in impulse based sims, is you run it using low fidelity as stated above and when a collision is detected you back up the simulation until the entity is just barely in contact with the colliding surface. then you run a high fidelity collision response code. im currently not using any impulse time correction. thats for the next go around. what i got coded right now is working for 90 percent of the situations. that last ten percent will be corrected later with impulse time control. |
| ||
| added downforce to vehicle as speed increases. omg what a difference! |
| ||
| post a new demo??? |
| ||
| Seconded! |
| ||
| Thirded! Glad you're still working on it, dmc! |
| ||
| well before i post new demo heres what i need to finish. the wheel spin code has been using a hack for a formula. i need to look up the right way to do it. i think its something like circumference/velocity finish wind resistance. finish the tweaking of the steering controls re-tune the entire car. |
| ||
| Fourthed! I'm in the process of tinkering with the code I got from sswift's post but it sounds like you might be further along. I'd like to compare what you have done with my comments and modifications and share them with you if they are different. Later, Joe |
| ||
| im in the process of re-tuning the vehicle. this is the fun part =) this version is almost done folks. heres a preview of what you can use to tune the vehicle ;steering Const maxturn=130 ;maximum turn force, how tight you can turn. higher = sharper Const TurnRate#=6; how fast you can achieve max turn rate. higher = faster Const TurnReturn#=1.03 ;how fast the steering returns to nuetral. a value of 1 will leave the steering at last value. higher for return to nuetral ;gas pedal Const SnapResponse#=.1 ;value from 0 to 1. how fast max gas pedal is reached Const GasReturn#=1.01 ; how fast the gas returns to nuetral. a value of 1 will leave the gas at last value. higher for return to nuetral ;suspension Const front_stiff = 20 ; This is actually the mass value for the front wheel. lower mass = suspension less stiff. caution will collapse Const rear_stiff = 20 ; This is actually the mass value for the rear wheel. lower mass = suspension less stiff. caution will collapse ;tire slip Const FrontSlipMin# = 2 ;the value at which the front tires will begin to slip Const FrontSlipMax# = 3 ;the value at which the front tires will slip completely Const RearSlipMin# = 2 ;the value at which the rear tires will begin to slip Const RearSlipMax# = 3 ;the value at which the rear tires will slip completely ;tire size Const FrontTireSize# = 5; this the verlet collision radius Const RearTireSize# = 5; this the verlet collision radius ;rolling friction for tires Const RollingFriction#=.02; how much friction on the tires when they are in contact with the ground ;body friction Const BodyFriction#=.07;how much friction on the body when they are in contact with the ground ;wind resist Const AirDensity# = .8 ; density of air for wind resist function Const DC# = .3 ;Drag coefficient. how streamlined the car shape. used for wind resist Const CA# = .5 ;Cross sectional area. how large an area the wind is running across. used for wind resistance ;down force Const DownForce# = 1 ;how much down force is allowed. value from 0 to 1. zero= no down force, 1=max downforce ;power of engine Const VM = 10 ;Vehicle Mass. Fictional mass value used for acceleration calculations on player_pivot. Const HP = 1000 ;Horse Power. Fictional force value exerted on z axis, local to pivot, of verlet for acceleration calculations |
| ||
| Ok folks the new version has been sent to swift. so hopefully he can post it soon. first i want to thank everyone for there input. sometimes i get defensive but i do value it. im sorry for not having a "credit" section. frankly i forgot who all had contributed. i hope you dont take offense. somebody asked earlier in this thread if they could use it for a commercial game. personally i guess ive decided that it can be used any way anybody wants to. it is my hope that this demo will further the success of blitz and its users. the code is definatly not an "accurate" simulation of physics. it was never intended to be. but i did want to try to show how to use the principles of physics to make something fun. it is not optimized. ive prolly botched the formating in a bunch of places, and im sure its got bugs =) nuff for now. swift please let the community know when the new version is posted =) |
| ||
| oohhhh ahhh. looks good. Now all we need is one of those vehicle UI with several different chassis with different parts that affect the stats! Well, maybe we should implement some sounds first... :) Is DC# frontal air resist? and CA# sideways? in that case, it sounds really good. probably fairly negligible, but still a reasonable addition. |
| ||
| bot builder im cheating so its using one "profile" for any direction. so its neither frontal or sideways. its every direction. to make it accurate is some nasty math that would calculate the cars cross sectional area as it appears to the wind and direction of penetration of the wind. thats an insane amount of work that most users wont even notice. those values are from the basic air resistance formula of: Fdrag = 0.5 * Cd * A * rho * v2 |
| ||
| DMC, Well FUN is what this is all about. I have to tell you I have spent lots of time just playing with the results of what you guys have developed here. As you say it doesn't matter if it is not true life physics, it is fun! Games are about having fun. A commercial game written using the verlet code here would have a great kick start advantage. I think it is great that so many programmers can learn from what you're doing here - brilliant work... Ipete2. |
| ||
| Here's the links: http://home.earthlink.net/~sswift/verlettest-005.bb http://home.earthlink.net/~sswift/verletlib-002.bb You know, you coould just post the code in the code archives and update the archive post each time you release a new version. :-) The car seems to slide better now, but I liked the older versions better. Because: 1. It was harder for the car to do seemingly impossible things, like flip over suddenly, or fly into the air. The first thing I did in this demo was hit a ramp a tthe wrong angle because the car was ward to control and it went flying miles into the air. 2. The car now is very very hard to control because it slides around like mad. These things aside, the new physics do seem better. The car slides around better now, and I imagine the issues above can be corrected by tweaking some of the settings for mass and slip and friction. |
| ||
| Hmmm............. I get a message the domain is for sale. |
| ||
| swift i sent you a bug fix. did ya get it? its version 5 |
| ||
| Links updated/fixed. Please post future updates to the code archives! :-) I don't have time to keep posting updates of this. :-) |
| ||
| hahaha cool. much better physics. sliding is less than desirable, but at least you aren't having the wheel inversion problem. I'm laghing cause I added another constant-shocklength. it's just how far down to position the wheels. now you can make monster trucks with giant wheels and big suspensions. Heh. there's another thing badly needed. suspension models. especially for monster trucks. heh. I'm happy cause I just solved a bad problem in my code. none of the quad collisions were suddenly working (oh horror), and I had no idea what was wrong. and after about an hour of debugging I discoverend I had left out a small chunk of an extremly long if statement. You might expect to be mad to have wasted that much time debuging a small bug, but I'm just happy to get it to work. Oh yeah, and I had some more collision ideas. 1)Image based collisions. somthing like bumpmapping, only for collisions. I don't think it would be to hard, and it should run fast. all you have to so is take your verlet's current position, check the value of the pixel reflecting the position, and see if it is within the collision area. then figure out the closest point out of the collision-image(hard part) 2)friction maps. Apply a friction map to a collision type, and lighter areas would be mor frictive, and darker areas less. Much easier to implement than #1. |
| ||
| hmmm.. as a slight hijacking of this thread, I've got a question. With usual blitz comands you can create a pivot, create a mesh parented to the pivot, and then find out the meshes positition local to the pivot through entityx(mesh,0).... what I want to do is do that purely mathamatically. I have one type structure holding a position, a pitch, yaw, and roll. I want to be able to give a global position and recieve a position local to the pivot. I would be very grateful if anyone has a good fast solution to this. |
| ||
| bot builder you know about tformpoint right? i think that will do what ya want. swift dont worry im done. that latest release is good enough to get people starting on there own stuff. thanks for hosting. any further development will be my own from here on out. p.s. you know its sliding alot because i wanted to simulate dirt =) but ive already done asphault and with the tuning variables you can totally control the amount of slide. cya folks. |
| ||
| Hmmm. I was going to post back that I can't us Tformpoint because I'm using a non-blitz,simply mathamatical pivot, but I decided that it might actually be better to make my pivot a real blitz pivot, and use it for Tform stuff. It's probably faster, and less error-prone anyway. |
| ||
| I was disappointed at first because of the sliding, but after playing with the tweak parameters (both xxxSlipMins at 2 and both xxxSlipMaxes at 4, a little more horsepower and higher return-to-centre steering), it's clear that this version is much more solid and can be made to work just how you prefer. Nice -- thanks dmoc & co! |
| ||
| Wow, a real measure of how much the physics have improved: you can now (slowly) drive the car right up to the top of the spiral! |
| ||
How come this works in the test code:DoVerlet(car.Vobject, accelerator) when the function definition is this (I don't see any default values here): Function DoVerlet(name.Vobject, verlet_element.VerletPack, GlobalForces.vector, rfox#, rfoy#, rfoz#, GlobalFriction#, rfrx#, rfry#, rfrz#) I tried applying the code to a new VObject and keep getting too few parameters errors (even though I've included all of the globals). |
| ||
| ntense i have no clue what your talking about. whos test code? your test code? it aint my test code. |
| ||
| Ahh, woops, sorry.. I was taking it from an older version of the Verlettest(v.003). My bad. :/ |
| ||
| jhocking Your code for blitz racer has an include for Swift Shadow System - 080.bb Where can we get this file so that we can run your program? Randy |
| ||
| You have to purchase Swift's shadow system. that's probably why he didn't post the code. |
| ||
| Thanks bot, so where do I find more info on Swift's shadow system? |
| ||
| Look for any SSwift post and check his signature. IPete2. |
| ||
| Ok, cool. I just commented out the shadow code for now so I could play around. But I do like the shadow system and it would be well worth the purchase considering the time it would take to program it myself. As far as the verlet physics that dmc, sswift, and others have done here, I have to compliment them on their work. I'm impressed and this has at least given me some ideas on how to improve on my game. I am working on a dirt racing game (sprint cars, late models, etc) and I have a lot of the car physics as far as handling, but wasn't sure how to go about handling collisions and making the car roll over and stuff like that. I am shooting for something realistic, but I am not looking to make it a pure simulation where everything has to be perfect. I just want it to be believable and fun. There are die hard sim junkies who will criticize every little thing they can find that isn't as realistic as real life racing, and then those who just prefer arcade type racing - I'm shooting for something in between. |
| ||
| This is just the trick. Really happy with this code. Thanks lads! who do we credit with what work? |
| ||
| I suppose we should start out crediting Thomas Jakobsen for the original tutorial. This particular code is based on a demo I wrote, but there's so little of my original stuff left I could almost be left out. :) While I was working on it there was lots of input from Dev/T-Bogard and Bouncer, and Chroma wrote the 3D vector lib it was all based on. From there, DMC took up the ball and ran with it, which is where botbuilder and sswift got involved, among others. ... Maybe it'd be easier to credit the "BlitzBasic forums." |
| ||
| no way miracle, without your original help i would still be stuck in mathematical hell. see ive been trying to learn physics on and off for a couple of years. my math schooling is only up to pre-elgebra and although i can write code that uses more complex math, everytime i try to do some research its always written at the college level and i just dont know the language of math. the symbols that are used just confuse the hell out of me. so that has been a serious limiting factor for me. i started a full blown rigid body simulator two years. i was trying to do it the "right" way using quaternions for rotation and runge kutta integration and real torque forces etc. after it reached about 3000 lines of code it became apparent that my lack of understanding of the language of high level math and time constraints made the project impossible to continue on. so the day i came across your demo with the falling sphere groups was an obsolute god send. no way i couldnt have done this stuff without your work. |
| ||
| I didn't really help with the verlet physics in this demo at all. All I've done is reformattred the code to look nice. :-) |
| ||
| THANKS LADS! One thing I've been stuck on so far is: how do we "neatify" it so that we can make as many individual cars as we like? I tried to use banks to make individual verlet cages per car then realised they can't hit each other... and so on. |
| ||
| Rob, making new cars is easy so i assume you really want to just focus on collision between non static objects such as other cars. what i had envisioned was to use the verlets current x,y,z coords as a vertice for a real-time build on the fly deformable mesh. this part concept was completed in a much earlier version of the verlet code that is no longer shown here. but it did work and worked well for that matter. it has the benefit of being very low in poly count (as opposed to using the highly detailed mesh of the car for collision) and it would conform to the points we would collide against for the verlets. now for the hard part =( blitz's internal collision routines do not allow for two, or more, moving non sperical entities to collide. it will simply pass right thru it. so you would have to write your own collision routines. if im not mistaken only two routines are needed. 1) moving sphere to moving poly (the sphere is the verlet of vehicle 1 and the poly is the polymesh of the second vehicle whos vertices are the coordinates of the verlets) 2) moving poly to moving sphere (just a reversal of the above) but it gets more complicated... if the sphere collides with a mesh the sphere is moved, the verlets position is updated to the new location of the collided sphere and energy, or velocity, is added to the system. this part works. but what about the poly on the second vehicle that the firsts vehicles sphere collided against? best guess i have is that the poly AND ALL its connected verlets are moved and each connected verlet is updated and velocity is inferred. not a very good solution but it may work assuming you had the above described routine. currently i dont have a clue how to write such a routine. ohh last thought. the problem is not collision detection between the two cars. the old code i had did that. it used meshesintersect to detect if one poly cage collided with another poly cage. however the problem is how to react after a collision is detected. |
| ||
Using sphere to sphere collisions as illustrated works well for car to car: |
| ||
| Blitz collisions may not be what you want to use for car-to-car impacts, because one thing colliding with another will only affect one of them. You'd probably be better off writing a sphere-to-sphere algo of your own which pushes both particles equally to separate them. That'll impart the proper momentum to both behicles. |
| ||
| The snooker code I have will work wonders here - the first hit will impart more mass and less feedback for some interesting crash dynamics! This vehicle/verlet/constraint stuff is addictive coding..! It's still quite difficult for me to understand how verlets work. |
| ||
| Skid, do you use verlet physics at all in your game, or is it a more custom thing? |
| ||
| Yeah, Skid how did you do those physics? Will you ever do a tutorial? What you've done feels really solid. I love the collisions with the trucks. It's very tight. |
| ||
| Come on! |
| ||
| Congratulations to sswift, dmc and the others. A very good job! this tutorial: http://home.planet.nl/~monstrous/tutcar.html have a explanation of how gearbox works, but my English and physics knowledge are very poor :( Somebody had tried to make the physics for gearbox ? Many thanks for sharing !!! Fernando.- |
| ||
| blackway thats one of the items on my VERY long list of things i would eventually like to do. unfortunatly all my time is devoted to a complete re-write of the constraint system and its proving to be very hard. |
| ||
| Maybe it's the first of your list! ;) Keep up the good work.....! |
| ||
| dmc - how far are you on the rewrite? |
| ||
| well since nothing has worked yet i suppose not very far at all lol. that im trying to wrap my brains around is a way to add a real spring model that has the ability to assign a host of variables per the constraint AND the direction of travel. also to add dampening, a non linear spring rate, make it time dependant and allow for differening masses. i already have a spiffy spring model but its hard locked on one end. what we need here is a spring with 2 masses, one on each end. and its driving me batty lol. im very pleased with my friction code and the tire model is working really well. but the suspension just sucks. so anyways thats an update. |
   |