Physics engine
Blitz3D Forums/Blitz3D Beginners Area/Physics engine
| ||
| Has anyone here ever made a simple physics engine before in B3d. I decided to make one just for a fun little project. If you have some simple code or helpful tips that would help please post them. I know it wouldn't be very fast or efficient and it would take a while to program, but I have too much free time and it would help me to get more familliar with b3d. ;) |
| ||
| I'm working on one, but i'm stuck on vertex commands. |
| ||
| Yeah that's where it gets complicated. Can you post your code so far? I don't mind if it is incomplete. |
| ||
| [edit] Never mind |
| ||
| I have started on a new verlet physics engine myself,... I'm about to move things into 3d right now, but here is my 2d verlets for dummies code. Note: This is based on some code from the code archives, so some things may look similar to those. When I am trying to learn something new I strip it down to the very bare essentials and start building up to where I need it. This is about as basic as I can get it. The next phase will involve getting collisions working between different objects. There are a few extra lines of code in here dealing with the collision code I have already started on. Edit: see my following posts for a version with collisions, and a full 3d version as well. |
| ||
| Another example ... http://www.blitzbasic.com/codearcs/codearcs.php?code=2105 |
| ||
| Thanks for the examples those will help. I will post my code when I get cubes working. :) Might be a few days. |
| ||
| Ok I Have a problem. Here are my types
Type vertex
Field mass
Field x#,y#,z#
Field vx#,vy#,vz#
End Type
Type rigidbody
Field entity,x#,y#,z#
Field xv#,yv#,zv#
Field xrv#,yrv#,zrv#
Field xr#,yr#,zr#
Field mass#,cx#,cy#,cz#
Field ID,IDL
Field v1.vertex
End Type
How would I make some rigid bodies have 6 vertexes and others have 20 vertexes. |
| ||
| I guess you'll have to either roll your own linked list of vertices in the type or have an array of vertices in the type. |
| ||
Here is my substitute for the slow meshesintersect functionFunction NMeshesIntersect(e1,e2) EntityPickMode e1,0 EntityPickMode e2,2 Surfaces=CountSurfaces(e1) For s=1 To Surfaces Surf = GetSurface(e1,s) Triangles=CountTriangles(Surf)-1 For t=0 To Triangles v1 = TriangleVertex(surf,t,0) v2 = TriangleVertex(surf,t,1) v3 = TriangleVertex(surf,t,2) v1x# = VertexX(surf,v1) v1y# = VertexY(surf,v1) v1z# = VertexZ(surf,v1) v2x# = VertexX(surf,v2) v2y# = VertexY(surf,v2) v2z# = VertexZ(surf,v2) v3x# = VertexX(surf,v3) v3y# = VertexY(surf,v3) v3z# = VertexZ(surf,v3) tent = LinePick(v1x#,v1y#,v1z#,v2x#-v1x#,v2y#-v1y#,v2z#-v1z#) ;If tent <> Null Then If tent = e2 Then Return True Else tent = LinePick(v2x#,v2y#,v2z#,v3x#-v2x#,v3y#-v2y#,v3z#-v2z#) ;If tent <> Null Then If tent = e2 Then Return True Else tent = LinePick(v3x#,v3y#,v3z#,v1x#-v3x#,v1y#-v3y#,v1z#-v3z#) ;If tent <> Null Then If tent = e2 Then Return True EndIf ;EndIf EndIf ;EndIf EndIf ;EndIf Next Next Return False End Function It works faster than meshesintersect on my computer. I can also use pickedx and pickedy and pickedz to determine where the collision was. I am currently trying to get it to figure out which vertex was hit. |
| ||
| You may already be on top of this, but you should also do a basic bounding box or radius check first, to see if you even need to calculate further. |
| ||
| Yes That's a good Idea I'll update it when I have that built in. |
| ||
| I just realized that you have to use positionmesh and rotatemesh rather than positionentity and rotateentity. Can someone fix this please? |
| ||
| How about a bit of code to look at? It would help to see what you are doing. I've started adding collisions into the code I posted above, but things are not quite right yet. Collisions are working great, but the response is incorrect, so things tend to stick together. When I get this bit worked out I will post the updated code. |
| ||
| [EDIT] As you just realised .. Your intersection function will not work. Vertex info is in local space coords so you'd need to transform these into world space before doing the linepicks. e.g. This : v1x# = VertexX(surf,v1) v1y# = VertexY(surf,v1) v1z# = VertexZ(surf,v1) Should be : tformpoint vertexx(surf,v1), vertexy(surf, v1),vertexz(surf,v1), e1, 0 v1x# = tformedx() v1y# = tformedy() v1z# = tformedz() That said, it will be faaaaaaar too slow to use in game even using a broadphase bounding box or sphere checks. You'll need to rethink your collision detection as this method is not practical as you'll soon find out. Stevie |
| ||
| Here is all of the code I have put together. Sorry nothing works yet. I just started doing this yesterday. feel free to add to it please post your improvements. stevie G, As I said in my first post, I know it will be slow, however I am just doing this for fun and for the experience. also it is pretty fast for now. 3 spheres colliding but not bouncing off of each other = 60-80fps |
| ||
| here is a version with working collisions between verlet objects. Edit: updated code with Stevie's modification,... Thanks! |
| ||
| How can I calculate the rotation velocities of an object after it is hit. Here is how I calculated the x y and z velocities for the mesh as a whole. I averaged all of the vertex's x, y, and z velocities to get the final x, y, and z velocity. This makes the movement of the rigid body's look natural however I can't figure out how to make them spin naturally. Here is the code I figured out the velocities with. avgx# = 0 avgy# = 0 avgz# = 0 cnt = 0 For v.vertex = Each vertex If v\id = r\id Then cnt = cnt + 1 avgx# = avgx# + v\vx avgy# = avgy# + v\vy avgz# = avgz# + v\vz EndIf Next r\xv# = avgx#/cnt r\yv# = avgy#/cnt r\zv# = avgz#/cnt r\x# = r\x# + r\xv# r\y# = r\y# + r\yv# r\z# = r\z# + r\zv# |
| ||
Sorry Troy, couldn't resist ..For vv.verlet = Each verlet If v <> vv And v\id <> vv\id; if not the same verlet or group dx = v\pos\x - vv\pos\x dy = v\pos\y - vv\pos\y dist = Sqr ( dx*dx + dy*dy ) TotalRadius# = v\radius + vv\radius If dist < Totalradius Diffx# = ( dist - TotalRadius ) * ( dx / dist ) Diffy# = ( dist - TotalRadius ) * ( dy / dist ) ;to do list ;get the velocities of v And vv ;use them to find the new vectors for v and vv ;for now just do a quick cheat v\pos\x = v\pos\x - Diffx * .5 v\pos\y = v\pos\y - Diffy * .5 vv\pos\x = vv\pos\x + Diffx * .5 vv\pos\y = vv\pos\y + Diffy * .5 ; v\pos\x = v\old\x - v\vel\x ; v\pos\y = v\old\y - v\vel\y ; vv\pos\x = vv\old\x + v\vel\x ; vv\pos\y = vv\old\y + v\vel\y v\collide = True EndIf EndIf |
| ||
| I am assuming that figuring out the yaw pitch and roll velocities will require calculus which is a bit above my head considering I am in 9th grade. (taking pre calculus next year) :) |
| ||
| Stevie,... that's what I was looking for,... thanks. Can't believe how close I was several times. I have updated the code above to include this, and it's working nice now. Nate,...you really won't need to figure out any of that if you use a verlet system like the one I have posted, or the link that Stevie gave earlier. Knowledge of how vectors work will help. Verlets are a very good physics solution that do not require heavy cpu, and can also be easily adjusted for softbodies as well. Here is my quick explanation of how they work. With a verlet system, you work with the physics at the point level, rather than calculating out all the rotations. At the core of a verlet system is just a system that allows individual verlets (particles) to move with physics like velocity, mass, gravity,...etc. None of these have rotation, and are simply points in space. Next is where the magic happens,... the constraint system. This simply links verlets together at a certain distance. You can make these more elastic, but for simplicity now lets just call them fixed distance. The constraint system cycles through each link, and moves each appropriate verlet towards or away from it's linked verlet. This is done several times per loop, and the result is that the other verlets get pulled around by the overall mass. Let's walk through a simple example of a square. 1. first, the lower right verlet has a force applied to it, and it moves to the right. This is the verlet update phase, and none of the other verlets move. 2. now the square no longer looks like a square, because the verlet is out of position. 3. now we run the constraint system. This will adjust all of the edges to the correct length again. By doing this, each time you adjust one side, another will be off a bit, but this is ok. What ends up happening is like an averaging of the mass, and moving a single point will pull around the entire mass with a rotational force. This is why we run the constraint system several times per loop. (If you only had 2 points, it would be perfect after one loop, but more points are going to squish around a bit more.) Usually a number between 5 and 10 is sufficient. Hope this helps and doesn't confuse more. I would try to diagram this, but don't have a way of posting images right now. |
| ||
| Thanks pongo. I will try your method of verlets but the only flaw I can see is that if you make the sides long enough the verlets just pass through the lines inbetween verlets. I am inexperienced in this field but I like your explanation. I think mabey to move it into 3d and eliminate the flaw with the verlets going through the linesegments, you could do a linepick between the verlet's old xyz and its new xyz to see if it went through something. maybe this could be a community project so people that just started learning blitz3d could see how a physics engine might work. Please post your code if you convert it to 3d It would be neet to see how it works out. |
| ||
| Wow. Programming a 3d verlet system is very easy compared to the way I did it. Thanks pongo!!! P.S. I will post the code when I get basic physics and constraints.(may be a few days) |
| ||
| Here's the 3d version. I'm really happy with this so far, but I still have a long way to go. If you plan your verlets, you should not have to worry about the line intersections. You can increase the radius of the verlets to close the gaps. Try changing my code so that the verlets are a size 10 instead of size 3 and you will see what I mean. for example,...change this Global v1.verlet = CreateVerlet (10,0,10,3,1) to this Global v1.verlet = CreateVerlet (10,0,10,10,1) Remember that these would be invisible in the final code, and would drive the rotation of a mesh object. I have made the verlets and constraints visible just for the sake of seeing things work. Also, the verlets only need to represent to basic shape of the more complex object and things will work well. |
| ||
| Ok I have a bad bug!!! Here is the code. You should see the bug if you run it. P.S. I borrowed some code from you, pongo. Thanks! |
| ||
| Hurray I solved the problem by combining our code!!! to do list: 1. get collisions working (might have to use more of your code) :) 2. make it so there are never any dark lines down the edges of the mesh (small bug) 3. get mass to affect collisions |
| ||
| Feel free to use as much of it as you need, that's why I posted it. This is my first verlet engine. I started writing it just a few days ago, but I've been kicking ideas around in my head for quite a while. I found that developing things in 2d first helped me out quite a bit. It was a very simple matter to move into 3d once things were working. Here are a few suggestions I have. -Consider building primitive cages of verlets instead of using the whole mesh. It may work ok for cubes, but will struggle with more complex geometry. -you don't need to connect every verlet to every other verlet. Too many constraints will hurt performance, however you will need enough to make sure the structure does not collapse on itself. This is a bit of trial and error as well as drawing things out on paper. -Mass can be done on the verlet level. This lets you do things like have a heavy verlet in the base to keep things right side up. You can also do a light verlet that has the opposite effect. |
| ||
| pongo Thanks for all of the advice. I was working on building a program that figured out the most efficient constraints to use. Also you do need quite a lot of constraints to keep blacklines from forming on the seems of your mesh. This is why I connected every verlet to every other verlet on the cube. here is the most recent version. The only problem is that the cube deforms as it hits. |
| ||
| Here is the version that automatically takes away the black lines and some of the squashing. :) |
| ||
| I think you still need to change how you are doing things. Right now you are manipulating the individual vertices of the mesh which is going to be slowing you down. That is also why the black lines are appearing, because you are pulling the faces apart a bit. You are also using a very high number of iterations, which will slow things down as well. Higher iterations are more accurate, but can be time expensive. Here is how I would suggest to change things. - Don't manipulate the vertices of your mesh. - instead, build a verlet cage that is not rendered, and attach the mesh to it. By doing this you do not need to edit your mesh on the vertex level, since it is merely along for the ride, and the verlets are doing all the work. This way, the verlet cage may flex a bit, but your object will not. Verlets will naturally flex a bit, but the beauty of the system is that it will correct itself over time. Hope this is making sense. |
| ||
| Makes perfect sense thanks. How would I build a verlet cage and attatch the mesh to it? That is a good idea considering that if you change the Createcube() to Createcylinder(32), it is not only slow but makes the cylinder look liquidy the only problem is that I have no idea of how to attach a mesh to the verlet cage. also if you haven't noticed manipulating the vertices makes the lighting of the mesh mess up p.s. On your verlet program, are you going to take out the verlet radius thing because it seems like that might cause things to start looking funny in 3d for example, a cube might look like it was floating in mid air just above the ground. |
| ||
| This is very interesting. I have created a 2d physics engine that is totally different from this verlet thingy. It uses vectors that create the outline of the object and uses line intersects to detect collisions. No 3d commands are used, so it is not tied to meshes. Objects have mass points, that sum up to total mass and they are used to calculate inertia also. I'm not sure what this verlet thing is ideal for. Do I understand correctly, that it isn't good for fully rigid objects? For bouncy objects this is kinda nice idea, like a variation of the rubber band force. |
| ||
| I use a verlet hybrid for both of the below. As you can see, with a bit of effort - it works just fine with rigid bodies. I only use 4 iterations of the contraint relaxation routines and it's very stable. http://www.blitzbasic.co.nz/Community/posts.php?topic=80032 http://www.blitzbasic.co.nz/Community/posts.php?topic=71891#804067 |
| ||
| Thanks for this thread guys, and pongo for your code. I've always been interested in verlet physics, as it seems pretty customisable. You have explained it quite well :o) |
| ||
| The reason I started to make my own physics engine is because I was inspired to by polymaniacs. Can you post some of the code for the physics in polymaniacs or tell me how it works exactly. P.S. still working on the physics engine :) |
| ||
| Can you post some of the code for the physics in polymaniacs or tell me how it works exactly. I can't post any code at this point - I've spend a looong time getting to this point and until I finish my game I'll need to keep my secrets. Besides, without seeing how it all hangs together in it's entirety, specific functions wouldn't make much sense to you. That said, it isn't a million miles away from what Pongo is doing although I am correctly applying external forces ( friction / drag / gravity / thrust / lift / buoyancy etc.. ) and have a load of functions to prevent verlet cages braking, body/body collisions, turning physics off on static objects and self-righting vehicles. Keep in there with Troy - he knows what he's doing and you will understand it better having built it from the ground up. Stevie |
| ||
| can't post any code at this point - I've spend a looong time getting to this point and until I finish my game I'll need to keep my secrets. I can understand that. It's nice to know that someone has already done what I am trying to do so I know it is possible. P.S. I really like your physics in your game and wanted to compliment you on how realistic it looks. I am having trouble aligning the meshes to their verlet cages though. I might have to rethink how I am doing this |
| ||
| Hey,... I've got some things to add, but unfortunately not enough time to write them up right now. (at work) Keep in there with Troy - he knows what he's doing and you will understand it better having built it from the ground up. Thanks for the support! You are the inspiration for most everyone in here. I'm still in the process of building things here, so I want to get it right before I go adding things. Right now I'm going to be changing things a bit so that verlets will be children of another type,... that will be where I will store the group ID and the mesh that will be attached to the cage. I am actively working on this, but the next few days might be a bit crazy for me (Wife and I are expecting our 3rd child any day now) Jasu- any examples you can post? I'm interested in seeing how it works. |
| ||
| Ok I don't have a lot of time for the next few days (math and english tests) Off topic -is it a Boy or Girl? |
| ||
| It's a,.... surprise! We have a boy and a girl already, so we wanted to have the surprise this time. Depending on how things go, I'm either going to have a lot of free time, or very little free time. You can probably judge by how far I get with this over the next week or so. |
| ||
| Yeah From my experience babies can be quite time consuming. Good luck! :) P.S. Got hit by a hurricane Ahhhhh! I love getting hit by hurricanes because the wind is so fast and there is no damage where we live because as it hit us, it turned into a tropical storm! You may call me crazy but I love going outside when the wind is blowing really fast yet nothing gets hurt. P.S.S. big Umbrellas + Hurricane = pull you off the ground. This really happens! Learned the hard way |
| ||
| I can't even imagine what a hurricane must be like, but we lost our roof and garage due to a tornado 2 years ago. One of the scariest things I've been through, and we had about 30 seconds of warning. Anyways, to get back on topic,... I'm building a new verlet cage the uses a cube instead of the pyramid that is in the code above. Those will be my main cages that physics are applied to, since they will fit most objects in some fashion. For the linking the mesh, you can use the verlet positions. There is an example of this in the blitz samples,... the driver.bb file in the mak directory specifically. In that example, a mesh body is aligned to four wheels. It is the same process to link a mesh body to a verlet cage. Here is the code section that does the aligning What is happening here is that you need to get a vector along the x axis, align the mesh, and then get a z vector and align it again. |
| ||
| There is something terribly wrong with my program. It is something about the atan2 math. If you can't figure it out then I guess I'll use your method which I don't quite get. p.s. Hurricanes last forever... well mabe 12 hours of rain and wind isn't forever but it is pretty long |
| ||
| How would I use the aligntovector command? I don't get how I could put it in my code. You might be buisy but could you(pongo) or anyone else put it in my code or your code so I can understand it better? Also If someone knows what is wrong with the math in my program could you change it so it is right. I don't know exactly how to use atan2 Thanks P.S. How did you solve this problem stevie? Are we going about it the right way? |
| ||
| Ok I got the physics rotation working, it just has one flaw :( |
| ||
| Yes, this is how I also do it. 0 = center 5 = top front left 6 = top front right 7 = top rear right 8 = top rear left ;align mesh to verlet cage PositionEntity b\Align , EntityX( b\p[0]\pivot ) , EntityY( b\p[0]\pivot ) , EntityZ( b\p[0]\pivot ) x# = EntityX( b\p[6]\pivot ) - EntityX( b\p[5]\pivot ) + EntityX( b\p[7]\pivot ) - EntityX( b\p[8]\pivot ) y# = EntityY( b\p[6]\pivot ) - EntityY( b\p[5]\pivot ) + EntityY( b\p[7]\pivot ) - EntityY( b\p[8]\pivot ) z# = EntityZ( b\p[6]\pivot ) - EntityZ( b\p[5]\pivot ) + EntityZ( b\p[7]\pivot ) - EntityZ( b\p[8]\pivot ) AlignToVector b\Align, x,y,z,1 x# = EntityX( b\p[6]\pivot ) - EntityX( b\p[7]\pivot ) + EntityX( b\p[5]\pivot ) - EntityX( b\p[8]\pivot ) y# = EntityY( b\p[6]\pivot ) - EntityY( b\p[7]\pivot ) + EntityY( b\p[5]\pivot ) - EntityY( b\p[8]\pivot ) z# = EntityZ( b\p[6]\pivot ) - EntityZ( b\p[7]\pivot ) + EntityZ( b\p[5]\pivot ) - EntityZ( b\p[8]\pivot ) AlignToVector b\Align, x,y,z, 3 |
| ||
| Thanks Stevie G!! Just what I was looking for but haven't gotten a chance to try it yet. Will modify my code to fit yours thanks! :) P.S. Has rained constantly for 48 hours(predicted 24 more hours) and I only have electricity for a little while until another car crashes into a telephone pole Has happened 3 times already and lost electricity each time Hurricane season :( |
| ||
| You need to lose adding a verlet at each mesh vertex as it's too impractical. For example, a standard create consists of 24 unwelded vertices, so has 3 verlets for each corner and none in the center so isn't stable. You only need 9 and this will fit most shapes. |
| ||
| @Pongo What sort of examples you want? I have my physics engine implemented in a game I'm working on and it's currently in a status that I don't want to share it around. In a few weeks maybe. Also there are so much physics code there, that it isn't good idea to put it all here. I'm not even sure do I want to reveal the inner workings of the game just yet. In code level that is. Here are the basics on how it is built: - All objects are built of vectors creating the outlines, and points of mass which are used to calculate total mass, center of mass and inertia - Collisions are detected by checking line intersects between outlines of two objects - When a collision is detected, object positions are back tracked to a moment when objects barely touched each other. Then I calculate collision normal (very hard thing to do) and use collision response math to get new directional and rotational velocities for both objects. - There's also functions to calculate forces on objects. As my game takes place in space, I'm talking about thrusters on space ships. Basically it calculates effects on directional and rotational velocities when a certain amount of directional force is applied on a point on the object. The same code is used to apply directional thrusters (ahead, reverse, strafe) and rotational thrusters (turn left, turn right). It's just a matter of placement and alignment of the thruster to determine the outcome (effect on speed and rotation). The engine is simple (compared to physics libs out there) and fast. I can have 20 AI players and 200 asteroids floating around and colliding with each other, still having game logic calculation in around 4-7 ms. And about half of that is used by AI... |
| ||
| @ Jasu, I assume you use SAT to calculate the collision stuff. |
| ||
| The shapes the vectors create are not convex hulls. So projection cannot be used. I had to go with the intersections. |
| ||
| Sounds good - when are we going to see it in action - can you post a video? |
| ||
| Collision demo, no sound, captured with fraps (a little less than 2MB download) If you want to see action, here's some: Scish gameplay Sorry about poor quality of picture and sound. |
| ||
| Not bad. I can't really see the need for complex collision detection though. Maybe I'm missing something but most of the objects there look like they could be handled as sphere / sphere or sphere / capsule and still be accurate enough in the heat of battle. |
| ||
| Here is my verlet code that allows the object to align itself to the verlets. Has some serious flaws Edit: I think it is something to do with aligning the cube using stevie's method |
| ||
| Jasu- Nice! I wasn't particularly interested in anything specific, just the overall technique. It sounds a lot like something I had looked into a while back. Right now I'm pretty focused on the verlet technique, but I like to spread my knowledge when I can. I haven't gotten anything done the last few nights,... trying to wrap up all the loose ends at work before I'm gone for a bit. |
| ||
| Jasu-I can't get the avi to work!!!??? I'm not sure what is wrong. I am trying to open it in Vista |
| ||
| The avi is XVid, so you need a codec that can play it. Like ffdshow. I didn't want to put this on youtube because of the poor quality and fraps logo. I know the collision detection is a bit of an overkill for this game type, but this is not a commercial project, so the purpose is not to do things easy/quick way. It's for learning stuff and a personal playground. It has my own physics engine, my own particle system, bitmap font system, data archiving system, AI code, pathfinding... well, all of it. |
| ||
| @ Nate - why have you commented out the second part of the alignment process? This is probably why it doesn't work. |
| ||
| It was just the same as the other part. wasn't it? |
| ||
| No - it's not the same - what on earth would be the point in that?! Have a closer look at what I posted. Stevie. |
| ||
| Ohhhhh... thanks stevie will change my code later buisy right now bye |
| ||
| Solved the problem sorry stevie g I got the vertex's mixed up now it works!!! :) |
| ||
| Here is improved code with camera movement and the verlets are spheres they are unstable for some reason. so it messes up the physics :( Just change alph to 0 in the function applyphysicscube if you want to make the spheres go away. |
| ||
| Tired,... so very tired. Big news though,... Gabriella Rose,... born 8:08 am this morning. Started around 1:00 last night. Off to sleep now,...hope to rejoin the living soon! Nate,...I'll take a look at what's going on when I am better able to think. |
| ||
| So its a girl :) Ok I think there is a slight flaw in the code that allows the verticies that are touching the ground to slip a little because it only updates their position if they are not touching the ground Good luck with the baby! :) |
| ||
| I seem to have fixed the problem by allowing transformation after a certain loop. |
| ||
| There is still a flaw with stevieg's code and the rotating thing but here is my attempt to make two cubes collide using the physics engine and a line picking method. |
| ||
| ok now stevies code is giving me a headache I can't get it to align right. Here is code that shows the flaws in stevie's code. stevie any ideas as to why your code doesn't work? It seems like it should work |
| ||
| My code works just fine. It is your implementation of this code which is flawed. Look again at what I posted - your code is not the same. First thing I notice is that I refer to pivot 5 as front/top/left. You create it as front/top/right. I'd imagine that some of the others do not match either. Also, you are creating verlets at each vertex in the surface - you are already creating 9 verlets so you shouldn't be doing this. You are also aligning the visable mesh to a combination of top and bottom verlets. Pick the top or the bottom - not both. You collision stuff is seriously flawed. There are examples of collisions in the archives. Stevie |
| ||
| Congrats on the baby! Still an interesting thread guys, cheers! |
| ||
| sorry I am new to this so I may be a bit slow to catch on to what you are saying sorry I if I don't understand |
| ||
| Ok I will search the blitz website to see how other people did collision stuff... I found that most people used the blitz built in collisions and their physics engines worked well Would this be a good Idea? @Stevie G Did you use the blitz collisions to make polymaniacs? [edit] Maybe I could make the pivots a collision type and the actual meshes another collision type but then the pivots would react to their own meshes so I would have to make a different collision type for each mesh and its pivots [edit] Stevie, is your helicopter an animated mesh? If so, How did you do the collisions on it It seems that you can't get the vertex coords for animated meshes. |
| ||
| I found that most people used the blitz built in collisions and their physics engines worked well Would this be a good Idea? Yes. I think you've answered your own question there. I only use one collision type for the pivots which make up the rigid body. I do use blitz collisions for body / level collisions but for body/body I use something similar to SAT( separating axis theory ) with mass weighting. The helicopter is an animated mesh in that the rotors are separate entities which I turn independently. Collision volumes are built at runtime, I do not need to know the vertex coordinates for collisions. The collisions for the helicopter are the same as the other body / body collisions. It has a very specific mass structure with lift and thust forces being applied in a specific way to keep it stable in the air. |
| ||
| I have applied the blitz collisions here is the code sorry it has some major flaws |
| ||
| Just took a quick skim through your code,... are you accounting for a size at the points at all? I didn't see anything, and since the collision only happens at the points, then things will fall through easily. |
| ||
| Hi pongo Long time no see I set the entityradius to 1 just to make sure it worked but unfortunately it doesn't work right how is your verlet engine coming along |
| ||
| @ Nate, rather than adding to seriously flawed code I think you should take a step back and look at the entries in the code archives better and get the basic single object against a plane collisions working correctly. You really need to have more structure to your code so that if you need help in the future people will be able to follow it. At the moment you have unused variables and alot of what your doing can be simplified a great deal. You should do this for your own benefit. For example, You create 8 verlets - one after the other - a repeat process. Write a function which creates the verlet ... something like this ..
Function VERLETcreate.verlet( r.rigidbody, x#, y#, z# , Radius# = 1 , Mass# = 1 )
v.verlet = New verlet
TFormPoint x, y, z, r\Ent, 0
v\x = TFormedX()
v\y = TFormedY()
v\z = TFormedZ()
v\ox = x
v\oy = y
v\oz = z
v\Mass = Mass
v\Piv = CreatePivot()
PositionEntity v\Piv, v\x, v\y, v\z
v\Ent = r\Ent
EntityType v\Piv , C_VERLET
entityradius v\Piv, Radius
Return v
End Function
Then you can set up all your verlet like so ... Type rigidbody field v.verlet[8] field etc... end type r\v[0] = VERLETcreate( ... ) r\v[1] = VERLETcreate( ... ) As I've pointed out a few times. You are not creating a central verlet - this will lead to collapse with heavy collisions. If you need to constrain every verlet to all others ( which is overkill for a cube btw ) then do something like this .. For l = 0 To 7 For m = l+1 To 8 CONSTRAINTcreate( r, r\v[l] , r\v[m] ) Next Next Again, use a function to create the CONSTRAINT as you are going to be creating alot of them. Function CONSTRAINTcreate( r.rigidbody, v1.verlet , v2.verlet ) c.constraint = New contraint c\p1 = v1 c\p2 = v2 c\Length = EntityDistance( v1\piv, v2\piv ) c\Ent = r\Ent End Function I realise that everyone has their own coding style so if you're happy with what you have then just ignore me. I can say this from experience that while the physics in Polymaniacs may look simple it took me a loooong time to get things working the way I wanted. Don't expect everything to fall into place overnight. Stevie |
| ||
| I prefer to have fewer and longer functions. I guess that's just how I program. One quality I wanted to have in my physics engine was for it to work flawlessly for any purpose I needed it for in the future. P.S. When will polymaniacs be released I will certainly like to buy it!!! :) |
| ||
| I prefer to have fewer and longer functions. I guess that's just how I program. Fair enough. I can't work with or follow messy bloated code myself ( probably a form of OCD - see function list image below ) so I'll probably be no help from here on in I'm afraid. Good luck to you though. It'll be a while before I'm done with Polymaniacs - alot still to do. |
| ||
| One quality I wanted to have in my physics engine was for it to work flawlessly for any purpose I needed it for in the future. I think it would really help if you would step back a bit and try to get a more simple example working. Right now you are adding in a bunch of extra code without getting the underlying collisions working. If you look at my last example again, I have everything working that is in there. The next steps will add quite a bit of complexity to the code, but I know that everything works at this stage. If I screw things up, I know what portion of code is messed up, and I can return to the last known working version. If you looks at my examples, I have done this entire project with that method. Here have been my major steps: 1. Individual verlets can moved around and can collide with each other. 2. Build a constraint system so that 2 verlets can be tied together 3. Expand the constraint system to any number of constraints. 4. Groups of verlets can be moved as a single mass 5. Collisions between groups of verlets 6. Now do it all in 3d and so on... At several of these steps I re-wrote code so that it was cleaner and more efficient. Through this refinement things have gotten very light code-wise, yet do everything I want, and is very stable. Look at Stevie's example,... about the 6th post down here. It's an awesome structure to use, and I have learned tremendously by ripping it apart to figure out how it works. |
| ||
| I added a lot of comments and added some functions and gave the plane a collision type to test if it worked. I think it would really help if you would step back a bit and try to get a more simple example working. Just did that! :) you will notice that it is kind of bouncy but I like it like that. It makes it look more homemade and that is good Pongo, how is your code? have you changed it recently or gotten 3d meshes to align themselves to you verlet cage? I would like to see how far you have gotten @Stevie G. and Pongo You have both been a great help so far thanks for all of the great advice and advising me on how to create a physics engine. I would have given up a long time ago if it wasn't for you |
| ||
| @ Nate, Your welcome. However, it's clear from your latest version that you are not listening to either of us and seem insistant on doing things the hard way. Wrapping re-used code into a function is a basic principle of programming and it's a good habbit to get into. |
| ||
| sorry but I don't understand how far you want me to step back or what you want me to do I am having a hard time understanding you. Do you want me to re-write my whole physics engine or just modify the one I have. Wrapping re-used code into a function is a basic principle of programming and it's a good habbit to get into. I am currently working on that but I only have time on the weekend. Please explain what you mean by I am doing it the hard way. What way should I be doing it. Sorry if I am slow to understand what you are saying. |
| ||
| Nate, you need to be the one to determine haw far back to go. I personally like to start with extremely simple examples, and get each of the small examples working perfect before I put things together. I have an entire folder of this type of code, usually 50-100 lines of code max. Then when I need to refresh my brain I can load up one of these and see things very clearly without going through pages of code. That is how I work, but everyone works a bit different, so you need to figure out what works for you. I would suggest forgetting about the aligned mesh for now,... get the underlying physics working first. I do not consider myself much of a programmer (I'm an artist), but I'm not even thinking about attaching meshes to things until I get the basics working exactly how I want. Right now I'm expanding my code to allow for new things, and I have restructured things a bit. I'm also trying to optimize verlet positions and constraints to get structures that are both efficient and do not collapse. |
| ||
| Ok I have made a desicion to go back to the drawing board (I am really using a white board) unless I accidentally fix my old code. It will most likely be finished in a few days. I will base it on the verlet system which is the only system I know how to make. If I encounter any problems and post on this blog, it will probably be completely different code than my old code. Wish me luck. I will post it when I am at least half-way finished. Thanks for the help. @Pongo Have you added to your verlet system yet? It would be interesting to see how it is coming along. P.S. I found some neat code in the archives that uses car.x from the driver sample file. here it is. :) |
| ||
| Oh Great another hurricane is going to hit!!! I may not be able to post over the weekend depending on how bad the hurricane is. |
| ||
| Here is my code rewritten and revised to have a lot more friction when things collide :) This is only part of it so far. Stepping back really helps!!! I figured out what I believe is the most efficient way of making very stable verlet structures. |
| ||
| this is way cool, much better than i could do right now :) but i wanted to know what entity i need to apply transformations to to make it move. if i try "cube" or "r\ent" or r\c\ent it fails, why?? what am i missing? |
| ||
| Thanks but it still has a long way to go As for the problem. I am working on a MovePhysicsEntity function soon but with the code above, You will have to stick with transforming it before you use the Applyphysics function sorry I am working on adding some terrain collisions at the moment. :) |
| ||
| check in tommorrow maybe I will have it fixed up a bit. |
| ||
| ok thanks! |
| ||
| @Nate the Great Me likes.. but just to let you know if you don't already, if you change the CreateCube to CreateSphere it goes wonky. |
| ||
| Oh yeah sorrry about that glitch but too many vertcies too close together makes it act funny. try createsphere(4) |
| ||
| Is there a limit of 100 posts per topic? If there is then I should move this to a new topic because it is getting close |
| ||
| Here is the code that deals with terrain collisions!!! you need a bmp file called heightmap1.bmp you can find it here [a http://files.filefront.com/heightmap1bmp/;11773113;/fileinfo.html]Heightmap1.bmp[/a] Here is the source code press space bar to add a sphere use arrowkeys and a and z to navigate. If you can figure out how to improve it or make it faster please tell me. Enjoy |
| ||
| Stevie G, How do you use SAT for your collisions I attempted this but could not figure out how to do it. |
| ||
| Ok I have basic verlet sphere-sphere collisions working proporly using the concepts from some of pongo's code. it still needs heightmap.bmp you press the space bar for more balls to appear over the terrain you can use yhgj for the controls of the first ball that you put on the map P.S. It is much faster now I haven't gotten to measure the fps recently though :) |
| ||
| This thread is so long and is taking to long to load so I will move it to another thread called verlet Physics 2 |
   |