Fast rigid bodies
Blitz3D Forums/Blitz3D Programming/Fast rigid bodies
| ||
| My rigid bodies uses links to build a cage out of verlets. This is slow, and the cage can get squished. I need a method to fix a rigid body in its proper shape. It doesn't have to be perfectly accurate, just fast and believable. Let's say I have a box with 8 corners made of verltes, each with its own velocity. I update velocities, and the vertlets no long form the shape of a box. I then need to rotate the box to fit the average shape the verlets give, then reposition the verlets to the box. Once the box is rotated, I just transform coordinates to move the verlets to their proper place. The problem is in the first step. I know the position of the box, because its just the average of all the verlet positions. Let's say I have a box positioned at 0,5,14, and I have one corner of the box positioned at x,y,z. I know that the position of this corner relative to the box should be 1,1,1. How do I rotate the box to fit the position of the corner? If I could figure this out, then boxes, cylinders, or any other shape could be done. |
| ||
The way I did this was to just align the object with two known vectors along the sides of the box:;calculate vector 1 - Z ... ;Align to it AlignToVector sof\ent, result\x,result\y,result\z, 3 ;calculate vector 2 - X ... ;Align to it AlignToVector sof\ent, result\x,result\y,result\z, 1Works a treat, as you have already positioned the object correctly. |
| ||
| That's a good idea. I used that method before...what I did was make an axis out of the bottom-right of the box. The problem is that if a verlet on the other side of the box is moved, the box does not respond at all. Of course, I could do it twice to cover all corners of the box, but that only works for boxes, and there's got to be something faster. I think it's got to be done by adding vectors. I'm going to do some tests in 2D and see what happens. |
| ||
| Not sure what you are talking about. If you move any verlets the box will respond. |
| ||
| The reason my boxes are slow is because they take so many links to be stable. It takes me about 20 links between all the corners to make a stable box that doesn't fall in on itself. |
| ||
| I guess it just depends on the stability of the system. Usuallly a 14 links, 8 verlet box works ok, although it does collapse at high vel. a 16 link, 8 verlet box is even better, and a 18 link, 9 verlet box is Almost uncollapsable. oh yeah, and Masterbeakers method is pretty much the Dmc, Miracle, and I use for positioning the graphical object. We added three verlets to each object. one for origin, and two for two axis. Hmmmm. to slow?? I guess it might be when integrated with a real level, AI etc. What method are you using? The one that is used by the writer of the gamasutra verlet tutorial seems to run very fast. even supports masses with a tiny mod. I didn't mean to say it wasn't a good idea to make a physics system, It's just that saying It's all powerful and greater than everything really really irked me when I've been working on a physics system capable of similar things-if not more optimised. Even more so irkful was that I had seen the impressive results of dmc's/miracles efforts. Anyway, I just wanted to say that the more physics systems the better, especially if the physics system in question has a good possibility of integration into singularity. |
| ||
| I'm talking about orienting the graphical object based on the position of unlinked verlets, and then re-orienting the verlets...without using links at all. This would make it impossible for the object to collapse. It would also allow arbitrary objects like cylinders, without tons and tons of links. I made a rolling cylinder, but it took more links than I can count. |
| ||
| Bot: If I'm not mistaken, the least collapsible shape should be a tetrahedron. You can make a cube out of tetrahedrons with just 8 vertices and 18 links. That's one link for each edge of the cube, for a total of 12, plus just one diagonal on each face, oriented in the right direction, coming to a total of 18. If you don't orient the diagonals on the faces right you would end up not creating tetrahedrons and then be subject to collpase. Halo's suggestion sounds very similar to a suggestion I made in the verlet thread with the little verlet car. I was thinking the same thing, that one could have a static version of the model and somehow adjust the verlets to fit to it. |
| ||
If you have a verlet with three non-zero axial positions relative to the whole object, and a position of the center of the object, there is no ambiguity of the object's rotation. It has to be solvable. If you can solve for one, you can solve for them all, average the solutions, orient the object, and reorient the verlets. |
| ||
| The problem with doing that though is that it may go against the whole way that verlets work. Instead of storing energy when a verlet is compressed when it hits a wall, and releasing this energy over time by relaxing the model, you'd have verlets which are so stiff that no energy is stored, and you're back where you started with needing to do traditional calculations on torque and such. I proposed calculating the average position like you suggest, but connecting the verlets to that, and allowing them to pull it and have it pull back on them. Then they would snap back into position, and be harder to push out of position. |
| ||
| Sounds good. Keep at it halo, im starting on shadow code. |
| ||
| I have no idea how. I took another stab at my cubes. Making them out of tetrahedrons does save a lot of time. Here's a tip that will really help, if you aren't doing it already. If an entity's speed is less than some threshold, (make it fairly high, just below the speed of gravity), then set a flag to disable all physics updates on it. If the object is pushed or hit by another entity, turn the updating back on. I was able to have 30 cubes at 100 FPS because they were all not moving. |
| ||
| halo, not trying to talk you out of it but imagine this very simple scenario. you drop your cube and it makes contact with the floor. the non constrained verlets which represent the bottom of the cube collide with the floor and stop. the top verlets will want to keep falling. so if you align them all to the cube the top verlets will want to keep falling every simulation step. that means that they will need to be "popped" back to the box every step. if you take and average of the verlets each step to align the box you have one set of verlets stationary on the floor and another set that is continually bouncing up and down. how will this affect the boxes behavior? how will this affect the over all "energy" stats of the structure? i think iof you continue down this road that you will have to program so many situational routines that any speed gain will be negated by more routines. im going to take a guess that the code is slow because you had to many constraints trying to keep the structure stable right? if that is correct here is an approach i highly suggest that will improve your stability a great deal (and possibly have a by product of faster execution becuase you wont need as many constraints) use the techniques that are used in rigid body impulse engines where you back up the simulation in time when a collision happens to the moment at which the verlet just barely touches the collision surface. then at thatt moment run a high fidelity collision routine that progress the simulation is tiny steps while running a relaxing routine. this is commonly used by the pros. use low fidelity collision routines for the light duty collisions and a high fidelity only when it is really needed. so if you got that to work well then you could reduce the number of constraints for each entity because it will be handled in such a manner as to never allow it to get into a collsion that would collapse the entity in the first place. think prevention. |
| ||
| hmmm. interesting idea. would definetly allow for very fast physics, as you need few iterations, and the resulting algorithm appears fast. my question is how are you going to go about "averaging" the solution? quats? Also, with just the center and one verlet, the "roll" of the rotation is unknown. Although if you use all the verlets at once to affect the objects angle and correct verlet positions, it should be ok. |
| ||
| Not saying I can do this, because I don't know if I can, but: This is a method of getting the same thing as linked verlets, just without any iterations. My physics code handles individual velocities of each joint, so torque and the spin of the object are not lost. Each joint undergoes the same ball physics updating, and the rotational velocity of the box is just a result of the individual verlet velocities. I am not sure if the other physics routines do this, so you might be coming at it from a different angle than me. You are right about the rolling. You could roll around the vector of the vertex position. Doh! Keep thinking about this, I think it's worth a shot. The problem is this: Given a bunch of points, what is the best approximation of a cube you can construct? |
| ||
| halo here is another way to look at a low fidelity/high fidelity system. so when a cube is falling and in no contact with any other entity why do you need all 30 some constraints? run half that number until a collision is detected. then back up the sim to moment in time it just begins contact then dynamically add in more constraints at that moment. if you did that for every entity imagine the number of cycles you would save. |
| ||
| [a http://www.leadwerks.com/rigid bodies 2.zip]Here[/a] is an update of the rigid bodies demo. When an entity flashes gray, that means physics have been disabled because it isn't moving. |
| ||
| yeah I added that to my physics system. disables the physics on a structure when there's not much movement, has average movement shutoff and single movement shut off, so if there is no particle greater then the single movement shut off, and the average velocity of all the particles is lower than the average movement shutoff, then the structure is disabled. Of course, once another force is applied, it registers it, and restarts physics. I think the idea is feasible, but hard to implement. once implemented it would be VERY cool. |
| ||
| Now with box pushing: www.leadwerks.com/rb3.zip |
| ||
| Oh my god, averaging the box verlet velocities gets rid of all the jitters when the boxes are lying at a weird angle. I don't do a complete average, but take the average of all verlets, then give each verlet a velocity of it's own velocity*80% + the average velocity*20% or so. |
   |