2D Collision, Physics, Rigid body dynamics
BlitzMax Forums/BlitzMax Programming/2D Collision, Physics, Rigid body dynamics
| ||
| I think I might have an Idea for a community project. I have spent the last three weeks trying to figure out a system in Max for polygon collision, and rigid body dynamics. After a lot of reading, and trying to interpret C++ code, I'm begining to understand some of it. But I still can't get my head completely around it. So I thought I might see if the Blitz community wouldn't mind helping out :) I think that giving novice game programmers (like me!) an easy to use physics and collision library would bring up the level of quality in our games. I believe that 2d is far from dead and that gameplay should always be considered more important than fancy graphics and eyecandy. So adding physics to games would make them so much better. So does anyone want to maybe start a community project to create a module for 2d physics? To give you a better idea of what I'm trying to accomplish, here is some code and examples of the type of libary I'm trying to create: http://uk.geocities.com/olivier_rebellion/Polycolly.zip The code belongs to Olivier Renault, who has created a pretty effeicient system in my opinion. I thinking about just porting some of his code over to Max, but I'm not sure if I would do it in the best way. There are far better programmers around here then me, but I am willing to dedicate my time in order to see somthing come out of this. Its still just an idea though so any comments or suggestions are welcome. Waddya think guys? |
| ||
| Well, 2d rigidbody isnt really that hard... http://www.blitzcoder.com/cgi-bin/showcase/showcase_showentry.pl?id=andreas_blixt10032003205007&comments=no This is a great example of a rb system for b2d ny andreas blixt |
| ||
| Thanks for the link, I realise that it isn't hard for some people, but I'm sure there are many others who think it is hard, and it would benifit them to have simple, object oriented code that would allow for them to create games with as little or much physics as they would like. I dunno I just think it would be better to have one base module to work from rather than random bits source thrown into a project. I am willing to write my own but so far it's taking me a while. |
| ||
| What about a 3D physics engine which also can handle 2D simulations? That way more users can benefit from it. If done right one could just prevent motion and rotation in the z-axis, not the "hacky" way but actually ignore the z-axis in the actual integration. [Correction] What I mean above was... Only allow movement along the X & Y axis and only allow rotation about the z-axis. :) One way to "ignore" movement along the z-axis is to use an infinite mass for forces acting on the z-axis. The same goes for the rotation but instead use an infinite inertia for x & y axis. However, if the collision-system only reports collisionpoints along the z-xis and the collisionimpulses is aligned with the z-axis you wouldn't even need to constrain the z-axis, but I think small floating point inaccuracies could interfere though. |
| ||
| Sorry for digging up a corpse, but I want to mention that this tutorial is very good. Bot Builder was a little rude. You two are probably not around anymore, but if you are, thank you altitudems for this sourcecode. |
| ||
| Wow that's an excellent tutorial. I've already started implementing something similar in Max, this will just speed me along. If I actually get something up worth showing I'll be sure to share. |
| ||
| a polygon? you think it's faster than lines segments? edit: oh ... this topic was for rigid bodies not for phisics... |
| ||
| The download from the link doesn't work for me - anyone got a mirror? Also, can I port this code for my use in blitzmax? I assume so since the source is provided. |
| ||
| Is this what you wanted? http://soldiers.250free.com/BlitZMax/Polycolly.zip I'll host it for a bit if his server is on the fritz. |
| ||
| Thanks, I'v got it now :D |
| ||
| Altitudems! Sorry that I didn't saw this thread before. This is exactly what I are trying to do. Those demos where might impressive! If we can copy this to Bmax we are almost done already. I do not agree that a 3D library should be used in 2D. The other way around. Let's build a solid 2D Physics library and then we can in the future expand it to 3D. Adding a dimention shouldn't be that hard, seems like most of the work would be in making a 3DVector that inherits our 2DVector. 2D is simpler than 3D and should be the logical place to start. If you want you can always jump to my thread. |
| ||
| Did anyone actually port PolyColly to bmax? it seems quite ideal ish. |
| ||
| I implemented a physics simulation in BB for a project at school, so I researched loads for it. http://www.harveycartel.org/metanet/tutorials/tutorialA.html This is a great link from a great game on separating axis theory. http://www.gamedev.net has loads of great code snippits on finding the center of gravity and moment of inertia for arbitary poly meshes. Its something that I was just about to tackly for the game im working on so I realy would love to help out. I only need a 2D implementation but that doest matter. 3D rigid body physics is much harder, especialy for collision detection and MOI solving, etc. I had a look at PolyColly a little more than a year back on flipcode and its writen realy well so I guess a port wouldnt be too hard. If no one else is willing then I mite take a stab at a direct port not just wraping. |
| ||
| I emailed the author to ask his concent for a PolyColly port as he didnt specify his wishes for the library in any of the source code. I will start to make the port into pure native BlitzMax code, not a wraper. I guess i'll just release the code threw the various stages of the port into the codearchives. If the author doesnt give me the go ahead then that will be that. Who will be interested in the port? Does anyone have any perticular needs/features that they would like to see? |
| ||
| <- interested... the more the better |
| ||
| Pantheon, Definately for a game one would like to be able to create and remove rigid bodies on the fly, and return x,y and rotation values from a rigid body object. Types are ideal for this... Then we can just recall the values any time we wish to draw. Think of a shootemup which needs to scroll new rb items into view as time goes by? do we offset the drawing positions or the rigid bodies? |
| ||
| Ok, i'v started looking at the source code and have writen up a all the method stubs. @ One Eyed Jack: Removing rigid bodys is fine. My concern is that creating rigid bodys would incur a speed penalty as some quite heavy functions are called to find the mass and other important values. A way around this would be to precache the rigid bodies that you would use, rather like a template. You could then insert this into the simulation later with no speed penalty. All your other requirements are met by the origial library. I would still like to know who will be intrested and if they there are any other suggestions, etc. |
| ||
| The only other suggestion I can think of would be anything to make it more maxish and easier to use if possible :) Very large numbers of people want thise sort of thing, they just haven't seen this post by you yet. |
| ||
| Yeah I think im going to change the library interface quite a bit to make it more simple to use (without removing any of its power :). Im toying with the idea of implementing soft bodies and articulation to the library. All the papers I look at on articulation are practicaly impenatrable. |
| ||
| Well your comments have me positively drooling! let me know if I can assist with testing during the development stage. |
| ||
| Will do, :) |
| ||
| Same here...... sounds an excellent project and one that most people would appreciate once completed. me for one ! |
| ||
| If you're looking for encouragement I am happy to give it. A decent 2d physics engine would be wonderful. |
| ||
| /pokes head up and looks about - any news? :) |
| ||
| any news? Well, im back home for the weekend so that gives me a long time to read over loads of game physics related papers. Im concentrating at the moment on the features that I want to be included and how the API should look. Once im happy enough with that then I will start to produce the goods. One of the problems I have is how to supply the simulator with the geometery for each rigid body. Also Is the problem of a terrain callback (just like tokamak). I was thinking of using a vertex array for both, just a pointer to a series of either integer of float pairs (x, y). Its just going to take a little while to get the design right then the implementation should drop in place quite nicely. Polycolly has some problems with stacking that I will need to sort out so its looking more and more that i will take polycolly as a reference and work up a new implementation for the physics. I already have the trivial stuff like the matrix and vector classed coded and a prototype of the API. Food for thought is how you will construct your geometry? remembering that it has to be convex. That is if you decide to use a polygon based rigid body. There will also mathmatical bodies representing spheres and rectangles. They will probably be easiest to implement for someone new to the library or looking for a minimal effort use of the library. Another adition I am planning are sensors (again like tokamak). They can be attached to a body, projecting a straight line onto the next closest body, kinda like linepick in B3D. They should be usefull for many things. Sorry for this post being all over the place, thats just because I have thousands of ideas and stuff floating around my head for this project and its taking its tole as I try to condense them all into something that will work and be reliable. |
| ||
| I'm happy if you let us just compose one rigid body out of several rigid bodies. For example two rectangles making up a cross (treated as one object). |
| ||
| I have abstracted the collision handler so each rigid body objects will specify what collision handlers they support and the simmulator will choose the most optimal one to resolve the collision between the two bodies. This will later let me/us implement soft/non-convex bodies by providing different collision handlers than seporating axis theory EDIT: I had in mind that SAT was strictly convex only but I just realised that it wasnt. That makes things simpler :). If I leave the collision handler in then that will allow 1337 coders to optimize it to their games with perhaps a BSP/portaling engine some how (that for them to decide). I read over a whole bunch of papers on constraints and it looks like implementing joints shouldnt be so hard. Im feeling pretty good about the API as it looks both robust and extendible. Before I start and major work perhaps people would like to look at the API and have their say as this is a comunity project and all. Does anyone have any webspace? I could zip it up and give it to them and they could post a link. I would dump it here but it spans loads of source files. |
| ||
| I do not have webspace at the moment, but I think is fantastic what you are doing. I am not too much of a technical person but it sounds fabulous. Will you be able to shoot like in the pollycolly tech demos? What did you mean by non-convex? that sounds most exciting of all. Could I then define a closed vector area and use those points as the collision? One more question for you: will we be able to for example, have some rigid bodies which are immovable, such as the background or things I would prefer not to budge? |
| ||
| You can create a number of rigid bodys, either from supplied arguments (spheres/rectangles) or from a given set of vertices (polymesh). When an object is convex it has no slight orifaces, all of an objects vertices lie on the negative side of each edge. Non-convex objects are thoes with any form or edge layout. (Im so bad at explaining things) Could I then define a closed vector area and use those points as the collision? Yes. Will we be able to for example, have some rigid bodies which are immovable, such as the background or things I would prefer not to budge? Yes, you can set objects to imobile. They will not be simulated but other objects will still be able to collide with them. Another good point is that objects will be able to be made imobile/mobile when every you like. As for the back ground you have two choises. You could model it with imobile objects or you could use a terrain callback: A terrain callback is a small function that you would provide to the simulator in the form of a function pointer and this would be called during the simulation. The simulator would pass some spatial paramaters to the function and you are then expected to pass back some geometric information that the simulator will use for collision. This is very usefull for instance if you have array bassed terrain, a BSP tree or some other space partitioning scheme. |
| ||
| Well the game I am working on is a shootemup with physics for fun. I haven't worked out if its best to just scroll by offsetting the drawing positions or physically moving everything. Maybe a bit of both, re-using rigid bodies or something as they nearly come on screen. |
| ||
| I have stacks of webspace. If you still need space then mail the file to - binarymooon at gmail.com - and I will setup a download for you. |
| ||
| Weird have lost posts? |
| ||
| I'd like to see some sort of screen-space conversions or way to do easy mouse interaction. Also, some kind of tool for setting these things up, making the poly's with the joints, masses, frictions, etc, and saving / loading them. Great project, keep it up! |
| ||
| Hm, screen space conversions are a good point. Max2D is well, 2D and so something to this effect needs to be thought out. |
| ||
| I'v had a realy tough week at uni and what not so I havent had much time to do anything with this project apart from reading stacks of techincal articles. When I get back to my proper computer then I will get a source forge address and upload a rough copy of the API. Constraints are still doing my head in but im sure that sometime soon they will make sence or that some smart coder can blaze into the project and put them in. Yeah I was thinking about an app to do all the rigging and modeling. Cool, at the start of next week, i'll try and get all this going. |
| ||
| I would just focus on a straight and simple port of pollycolly personally... then build from there. |
| ||
| Ok, I just sent off an application to source forge so I'll just be waiting to hear a reply. How can I create a sticky topic? Here is my description for SourceForge: -- project: "Motive" -- Motive will be a public domain physics simulation library for the BlitzMax programing comunity. The library will handle purely 2D simulations of rigid bodys. It will be implemented in native BlitzMax programing language so as to aid integration/adaptation of the library to suit an individuals projects. Motive will be designed to reduce the learning cure required to use a powerfull physics library. It will also be aimed to be highly modular in implementation where possible to aid the extensions/adaptations by project contributors and final users alike. Some of the inital project goals are as follows: .> Real-Time Simulation of Rigid Bodys in an arbitrary polygonal environment .> Multiple Rigid-Body representations (Polygonal or mathmatical) .> Easy integration into new and currently established games .> A stable simulation core .> Support for concevable libary additions (soft-body, etc) .> Visualy satisfying/plausable simulation of: +--> rigid body stacking --> shock propagation --> collison --> contact --> friction .> Unified and consistant API .> Minimise any extra content creation required from the final users Some future direction of the library include: .> Articulation amongst multiple bodies .> Soft Body simulation .> Unification/Optimisation of the library code .> Inverse Kinematics .> Implicit Animation |
| ||
| How can I create a sticky topic? Stickies are for moderators. Just create a new thread when there's something people can play with and drop me an email (support@...). Looking forward to seeing this project! |
| ||
| Hi there, this sounds very interesting! I've tried to write an verlet engine myself for a jump'n run game but failed. I dident sort out how to do a dynamic to dynamic object collision response. I'm not that good in those math stuff. But if you need any support, i'm in. It looks like its just you developing this, Pantheon? At least i could do graphics or help you code the editor, do something that keeps your hands/mind free for this serious stuff. So, if your interested in some help, just write a mail to: rayzor-s-edge@... |
| ||
| Just came back to BB forum after a while to see this thread. Can't wait to see a good and solid physics-module. @Pantheon: If you haven't solved your webspace-problem yet, leave me a mail. I have plenty of bandwidth available and can host any files related to this project. Jake |
| ||
| Hey guys, Sorry I haven't noticed this sooner, but I am ready to devote some time to the development of this. Pantheon, seems like you have a good idea of what this project should accomplish. Let me know what I can do to help. Has it already been a year? |
| ||
| Wow, thanks guys. I also have some good news. I found a website with papers from the Game Developers Confrence: http://www.gphysics.com/ This guy gave a presentation on his method for game physics and man is it good. The best part is that the maths and algorythms involved are so simple. At least check out the downloadable demo. I think that I may use his techniques for the library. Its starting to look realy feasable. Im gna start coding when I get home. Oh yeah: .> It handles Constraints (Joints that is) .> Friction .> Stacking .> Just have a look... |
| ||
| Nice find, very simple & straight forward. I have always coded my collision code for SAT impulse based response. Obviously his example code is for box>box collisions only but we could easily add in circle>box & circle>circle. I don't think you would need much more than that in a 2d game. Although arguably polygonal collision checks could be helpful. In any case all of these alogarithms are available for the SAT approach. The only really tricky part would be programming the response. I think it would be the most beneficial to create a simple base of code to start from, maybe with just one type of body and minimal collision response, and then work from there. Create something to get people interested, and actually start using the code in test projects. I think if we can do this then we will start to many contributions. I'm excited, physics make programming fun. |
| ||
| Ok, just in case you need it, I just finished porting the mathutils.h file from the Box2d lib. Due to BMax's lack of support for operator overloading some functions have long awkward names. My goal here is just to get the code working, not to make it look pretty. Edit: Updated for consistent naming. |
| ||
| And here is a ported version of Body.h and Body.cpp: Edit: Updated to include BodyList |
| ||
| Thats great! I also started to port some code into an API which I will explain in a minuite. His code uses a seporating axis for the box-box collision and modifying this to work with arbitary polygon shapes should just be a case of rewriting the collision handler to use SAT (ala PolyColly). The final step would also be to create a function to find the center of mass and the moment of inerta (both of which can be taken from PolyColly). Other than that I realy cant see any other great changes needed for the code. I will now give a rough explanation of the API. I thought this project should be called Motive because it was the only thing I could think that was kina cool. Here is a rough sketch of the types: Classes: Simulator { CreateRigidBody:RigidBody( bodytype, vertices:float ptr, numvertices ) CreateJoint:Joint( bod1:RigidBody, Bod2:RigidBody ) CreateSensor:Sensor( bod1:RigidBody ) CreateEvent:Event( bod1:RigidBody ) Advance( timeStep:float, iterations=5 ) SetState( state:int, Flag:int ) } RigidBody (abstract class) + SoftBody (extender) + MathBody ( '' ) + PolyBody ( '' ) { ApplyForce( vector ) SetState( state:int, flag:int ) SetPosition( vec2 ) GetPosition:vec2( ) SetVelocity( vec2 ) GetVelocity:vec2( ) SetOrientation( float ) GetOrientation:float( ) etc.... } Joint (abstract class) + Penalty (extender) + Impulse ( '' ) { Create( blah blah ) etc.... } Sensor { SetCallback( function pointer ) SetPosition( Vec2 ) GetPosition:Vec2( ) SetOrientation( ) GetOrientation( ) SetLength( ) GetLength( ) } Event { This will just specify collision callbacks or joint limit exceeds or huge forces' or something. This could be used for destroyable bodies by breaking joints when huge forces are applyed. } Some other features of the library are that an abstract collision type is made that will interface with the simulator and the rigid bodys. This can be extended to handle SAT or something more bulky for non-convex shapes. Each Body can constain a constant (set of flags) defined by what collision handlers they support. const CollHandSAT:int = $000F '// seporating axis const CollHandNCT:int = $00F0 '// non covex test method For the moment only seporating axis will be used. I was also planning that before release all the vetor and matrix math could be manualy inserted into the code to get speeds simmilar to inline functions (I hate that blitz doesnt have them). That will probably take a lot to diggest because its kinda just a brain spill. I cant upload and code because im at Uni just now. So the question is how do we merge the two? You could keep porting the code directly and then that would make it easy for me to integrate it into the API? I think is great what you have done so far so, I guess you can decide what you wana do. Perhaps we should just directly port his code and then focus on customising and extending it or perhaps I could just work on geting it running with polys? Fun fun. |
| ||
| that's a great start on outlining the api, I will take more time to look at it later. It is debatable whether or not inline functions improve performance, I think we should not worry about inserting vector and matrix code directly into the API. Just make sure that whatever code we use for those systems is extendable, and easily used for other things. I think we should do a direct port for now and just get some code working and a demo. That will get others excited and possibly working on "Motive" (I like the name by the way). Obviously the direct port will be fairly sloppy code. The actual API I think should have very easy to understand code, with variables spelled out, comments explaining logic, etc. This will allow others to contribute more easily and reduce confusion. While we direct port the code, we can plan the API more. The first step might be to just get ridged body physics simulation working for just OOBBs. And then expand from there. Edit: Another thing we should think about is how someone would actually implement this into their game. How will bodies be attached to game-world entities, etc. |
| ||
| Now that sounds like a plan. Ok, lets divy up the files. Unless you have any objections then we could split them up like this: altitudems -> MathUtils.h done! Body.cpp / Body.h done! World.cpp / World.h Main.cpp Pantheon -> Collide.cpp Arbiter.cpp / Arbiter.h Joint.cpp / Joint.h One question is: Are we going to use all the OpenGL commands (It uses GLUT so some slight modifications may be needed (font drawing, etc)) or use Max2D? If you wanna do the Main.cpp file then its your call :) I guess i'll try to stick to the naming convention you used to aid the ease of the merge. I guess that when we have this done then we can realy spot the pros and cons of this system before starting any more work on the full library. I have a few deadlines for Uni so my progress may be a little slow but I will try and have it done in the next couple of days :) Cool, this should be fun. |
| ||
| Ok, Im converting Arbiter.cpp and one problem arrises : If b1 and b2 are pointers then he has just compared their memory addresses. I can only come up with one explanation for this and thats that he wants body1 to have the lower memory address so that he can expect body2 to be in the CPU cache as I presume he accesses that second. Other than that I can see what he could hope to achive by that. Any suggestions? |
| ||
| That break up sounds good, I think I will convert the glut code to Max2d. I did notice that several of the function names aren't very consistent, I will updated that real quick. It seems that he is using pointer arithmetic to determine which body is last in the stack and then test against that first. I think we will end up using lists or arrays instead so we can compare them by their position. If pointers end up being needed for speed we might me out of luck. As far as I know BlitzMax only supports adding and subtracting of pointers. |
| ||
| I just want to say that if it doesn't use max2D, I will definately not use it :) The ideal way would be to have it use a simple 0-100 or -100 to 100 scale, and let us translate the physics to our chosen resolution. Many will use 2D libraries for drawing, 3D engines or even Max2D (I suspect the majority will have graphics engines in place)... So if you fix the physics to a basic simple number system we can choose our own resolutions and engines. |
| ||
| Rite now we are just trying to make a direct port of the excelent Physics Demo created by Erin Catto. It was writen in C++ and used the OpenGL helper library GLUT. I think altitudems is going to convert the demo to use Max2D but as for the final library, I will be API independant, meaning that you have to querie the Simulator to figure out how you should draw your objects. Another posibility is that you just supply a render callback function, but im getting ahead of myself. All this will be addressed later :) |
| ||
| Pantheon, I'm finding it difficult to port any more code because the files I'm working on are dependent on yours. :) I am going to go ahead and port over joint.h/cpp post that here unless you have already completed it. I know you said you are working on arbiter.h/cpp. Let me know if I should do this. |
| ||
| Thats cool, Yeah im still working on Collision and Arbiter so go ahead. I coded up all the stubs of all the functions and types for my compulation. How far are you along? I should be about 75% done by tomorow and possibly have it done by tomorow night. I guess we can just post what we have completed and then spend about 5 muinites joining them en voila. |
| ||
If you need an Arbiter Stub then use this one, i'll have it finished real soon:Rem * Copyright (c) 2006 Erin Catto http://www.gphysics.com" * * Permission To use, copy, modify, distribute And sell this software * And its documentation For any purpose is hereby granted without fee, * provided that the above copyright notice appear in all copies. * Erin Catto makes no representations about the suitability * of this software For any purpose. * It is provided "as is" without express Or implied warranty. End Rem '/** ' * ' */ Const inEdge1:Int = 0 Const inEdge2:Int = 1 Const outEdge1:Int = 2 Const outEdge2:Int = 3 '/** ' * ' */ Type TFeaturePair Field e:Byte Ptr Field key:Int Method New( ) e = Byte Ptr( Varptr( key ) ) End Method End Type '/** ' * ' */ Type TContact Field position:TVec2 Field normal:TVec2 Field separation:Float Field accumulatedNormalImpulse:Float Field accumulatedTangentImpulse:Float Field massNormal:Float, massTangent:Float Field bias:Float Field feature:TFeaturePair; End Type '/** ' * ' */ Function Arbiter:TArbiter( a:TBody, b:TBody ) End Function '/** ' * ' */ Type TArbiter Const MAX_POINTS:Int = 2 Field contacts:TContact[MAX_POINTS] Field numContacts:Int Field body1:TBody Field body2:TBody Field friction:Float Method Update( contacts:TContact[], int numContacts ) End Method Method PreStep( inv_dt:Float ) End Method Method ApplyImpulse( ) End Method End Type Instead of TFeaturePair.e.inEdgex use TFeaturePair.e[inEdgex] ;) |
| ||
Im getting a compilation error with this constructor function:'/** ' * ' */ Function Arbiter:TArbiter( a:TBody, b:TBody ) nArb:TArbiter = New TArbiter nArb.body1 = a nArb.body2 = b nArb.numContacts = 0 '// Collide(contacts, body1, body2) nArb.friction = Sqr( body1.friction * body2.friction ) Return nArb End Function The error is: Compile error: identifier 'friction' not found Its defined in both the TArbiter class and the TBody class. Its probably one of thoes stupid mistakes that creeps up on you. |
| ||
| Great, could you maybe use <codebox> instead? I am only as far along as what you see posted here, I will work on world.h/cpp next. I think there will have to be some time for getting everything working together. I'm sure it won't run correctly right away. Also I'm not sure if we are on the same page with using pointers. I have been converting them into straight variables unless the are being used to manipulate something outside of the methods/functions scope. Ok here is a quick port of Joint.h/cpp: |
| ||
| As far as I know in TBody the friction field is defined properly in the type and initialized in the Body() Constructor. Are you running the code or just building it? |
| ||
| Building it... Im stumped. (Im goin back to my flat now so i'll have to catch you tomorw) |
| ||
| Not sure how far you're on this project. But I figured I'd just throw in the source I have for anyone willing to scavenge something useful from it. It's basically a direct port of Oliver Renualt's 2D physics tutorial (pollycolly) while reading Chris Hecker's Rigid body tutorial. I went back and did a weak attempt of making it more OO a while back. Anyway, Here's the link: www.paradeofrain.com/download.php?id=9 Seems you guys already have a decent framework setup so my code probably won't contribute much. One file of interest some might find useful is Transformation.bmx. It deals with 2D transformation so I guess that's a good start should you want to draw polygons at arbitrary orientations. The code compiles into a simple working demo (compile from Rigid Body Test.bmx). WSAD to move one of the rigid bodies. SPACE resets the body. It's a bit buggy, lacking friction, but I doubt I'll be coming back to this for a while so I figured I'd just release the unfinished code. You'll find folders in the zip of previous more 'concept' demos that follow more in lines with Oliver's tutorials. The 'C' and 'SPACE' key is usually used for those. Hope it's useful. |
| ||
| Thanks very much .Alex, i'll have a good look at the code later. Im sure that will help speed up the process of creating the basic library. altitudems, here is the Arbiter file and a segment of the collision file: I also added these lines to the TVec2 class in mathutils. It was just to simplify writing the vector equations. I will try and get collision finished as soon as i can. I also fixed the compilation error in the constructor function, yeah it was a stupid mistake. I literaly convered the source files line by line so im sure that there will be a few logic mistakes in the above code but they shouldnt be too hard to fix. |
| ||
| Pantheon, That's great. I'm glad you found the problem. I am working on the World.h/cpp file now but because of my lack on C++ knowledge, I'm not sure what the following means: World.cpp typedef set<Arbiter>::iterator ArbIter; Which is later used like this: ArbIter arb = arbiters.find(newArb); Is "ArbIter" something special? I think "arbiters" is basically equivalent to a list right? Also the world class now will hold lists for Bodies,Joints and Arbiters. Edit: Here is a logo mockup I made for the project:  |
| ||
| Its an awesome logo :) |
| ||
| Yeah, that will create a Set (a list) of Arbiter objects stored with the identifier ArbIter (I hate c++ for case sensetivity), and Arbiters becomes a global within the source. In World.h vectors (another kind of list) are also created for Bodys and Joints. As well as another set of arbiters definied within the class. Im not sure why the global arbiter set is there then. I think im the same as you, I know the theory about C++ but I dont have much of a clue about the standard library. I think this part may need quite a bit of conversion. Nice logo, btw, its cool :) Oh, yeah, I have also finished the Collision file but I keep forgeting to put it on my usb drive, the stub should work for compiling now but i'll post the collision tmrw. |
| ||
| Pantheon, that little explanation helped. I think I have successfuly port World.h/cpp now. Please take a look: I'm glad you like the logo. More on that soon. By the way when should we start a new thread? I've got graphics and stuff for that. |
| ||
| I think we should start a new thread when we have this demo working, that way it gives people a chance to see first hand the quality of the simulations possible. This still needs a tiny bit of work, mostly to finish some vector equations and the swap things. I'll just directly change this code as its completed. It compiles any way. So i guess we can sync up all the other classes that use arrays to the main lists by using the TList.toArray( ) thing. Or will that create new instances of each object or something (I guess thats realy implausable). So is that all the files now (after collide is finished)? I have a feeling that loads of bugs are gna fly up when we join these. I cant wait to see it working though. |
| ||
| Ok we will wait to get the demo ported then. I too fear there will be some bugs when we link things together. However I will tell you that I can compile everything together so that's something. The last thing we need to do is port main.cpp. I am starting on that now so it should be done soon. |
| ||
| Cool, ok well I'll finish of the collision file now then. Even if you just port one of the tests then we can test it. This better be cool, I think i'll be equaly scaird if it just worked :) |
| ||
| I WISH THAT BLITZ MAX SUPPORTS OPERATOR DEFENITIONS!!!! BlitzMax + OPPERATORS = Sweet! |
| ||
| Big Ditto |
| ||
| How is it going on collide? Here is the first demo ported over in main.bmx: (Maybe it will work at first go. It builds fine at least.) |
| ||
| Hmm, Its taking a little while partly because of my course work and because I'm having to wade through Vector math without the use of opperators. I'v converted everything apart from the vector math in the last function Collide so I will try and have that done by tmrw then lets see what happens. :) |
| ||
| Keep going..... it'll be really interesting and useful when you've done it. |
| ||
| Pantheon, I understand :) Been there before too. Finish it when you have time. Yes it would be so much easier with opperator definitions. OvineByDesign, Thanks for your support, first demo shouldn't be too far off. |
| ||
| Nice work lads, remember we are rooting for you! |
| ||
| Hi, Just to let you know that im still working on the code, all be it realy slowly. I have loads of course work to submit by tomorow and one peice on friday. Im sorry for this stall but after that then loads of my time will be with BlitzMax. :) |
| ||
| No problem :) Finals week right? Good luck! |
| ||
| Hey, I hope people dont think i've lost intrest in this project. My Uni is just sucking rite now. Im feelin bad about not being able to move forward with this rite now. Just too much to do and not enough time. I feel bad because I realy wana start properly on this. |
| ||
| We have the faith in you |
| ||
| looking forward to it. |
| ||
| Its probaly more fair if I post the code we have so far for others while I am occupied. So here is a complete post of all the files so far. Note: Collide.bmx only needs some vector and matrix equations converted. I've commented out the work still to be completed so it should run, but with major errors however. It should be debugable however. arbiter.bmx body.bmx joint.bmx world.bmx mathutils.bmx main.bmx collide.bmx Oh yeah, and merry christmas :) |
| ||
| any more news on this yet ? ;) |
| ||
| Well, to be honest I haven't thought about this for a while. I was waiting on Pantheon to finish collide.bmx. I might try to finish it tonight, unless Pantheon already has (have you?). But I still want this to go somewhere. Hopefully we can get this first demo running and then invite other coders to contribute to the actual engine. |
| ||
| Very interesting and useful thing! Thanks! I'm making a 2D engine and will use this code (if it's freeware). It seems it'll fit there just right. Why you don't start a worklog? |
| ||
| Well worklogs sort of defeat the idea of a community project. If you want to help us with this just let me know. Also there really isn't anything working right now. You might want to wait until then. |
| ||
| Hmm, are community projects productive? As I have seen so far, one or two people really works on the project while others just speaking or testing (though it helps a few). Well, I was impressed by original engine, but how much is ported to blitz at this moment? And what help is needed? |
| ||
| Hello, Thats my exams out the way now :) sorry to keep you all waiting. So I have the time for this project again. When I tried to run the project as it is so far there were a whole bunch of memory exception errors which isnt too cool. I have bought a £50 book on Game Physics by MK which im progressivly reading. I was thinking that it mite be easier to code the physics library in C++ so as to take advantage of custom operators. The drawback is that debugging is very hard. I think im being put off the direct port slightly due to not full understanding the implementation. It may be easier to code a loose physics framework and slowly build it up with impulse collision handling, which can easily be extended to the catto method. This way the library will be usefull to people with every update. What is your thoughts altitudems? |
| ||
| Sure that sounds fine, I was still hoping to have at least some sort of demo to get people interested though. I know there are other interested in helping in particular the people from the MAX physics threads. http://www.blitzbasic.com/Community/posts.php?topic=52589 http://www.blitzbasic.com/Community/posts.php?topic=52760 If we start working on the engine now we should probably start a new thread. I'm thinking we should include an outline of the project, along with coding conventions, required mini projects, maybe goals? Like I said before I have graphics and logo's we can use. Let me know if you want to start a thread. I wonder if we should use google code for this. |
| ||
| here here .... Im sure theres enough of us that will test it for yer too (and maybe help out if possible) |
| ||
| Outlining coding practice sounds like a good idea. I tried to setup the google code thing a while ago, but it wouldnt give me an option so start a new project so perhaps someone with more experience with it should have a look. If we start on the new engine then we could have a nice (simple) demo working quite soon. We could also post new demos with every feature release. I think more progress would be made writing code that we have designed and thus intrinsicly know. Features I would like to see: o Particle Dynamics o Rigid Body Dynamics o Soft Body Dynamics (the presure body model) o Combining Soft Body Dynamics with 2D metaballs 8D o Soft Constraints (penalty method (springs)) o Hard Constraints (Catto proposed lazy impulses) o Friction, Stacking, etc. Thats all I can think of off the top of my head (in no perticular order). Its all quite scalable and can be distributed easily threw out the development. Each new feature can build nicely on what has been developed before. The Catto demo is realy nice and has most of the features everyone would want from a library. The good thing is that it came with a presentation paper so we can learn exactly what he proposed and extend out library with it.
_____ __ .__ project -
/ \ _____/ |_|__|__ __ ____
/ \ / \ / _ \ __\ \ \/ // __ \
/ Y ( <_> ) | | |\ /\ ___/
\____|__ /\____/|__| |__| \_/ \___ >
\/ \/
|
| ||
| Sounds like we should get started soon then, however I'm going to be very busy at work for the next couple of days, so I wont be able to give any time to the project until after that. Maybe we can spend some time researching more and thinking about exactly what we want to achieve for the first demo? |
| ||
| Ok, i'll try and decypher cattos presentation slides to figure out whats going on. Then I guess we can try and flesh out a road map for the project. Cool |
| ||
| The big advantage of coding physics library in BMax is that every BlitzMax coder then could alter this code to satisfy his needs while making physics engine for his game or something else. Also these modules can be understandable by those who do not know C, but want to khow how it all works. So I suggest making whole thing in BMax and I want to help porting it. |
| ||
| Yeah, im preaty sure that it will end up being writen entirely in BMX. Writing C++ and compiling with MinGW or linking with a lib file, etc cant be debuged, a total turn off. The only think that will bug me is that operators can be used on custom types (sucking majorly). Why dont I just go out on a whim and define my coding standard as a basis. Please comment on this if there are issues for anyone that will be working on this project. - Conditional statements -- A blank line must be included after a conditional statements. -- Tabbing will increment (tabs must be used for indentation, not spaces) after that line -- A blank line does not follow a conditional statements end. - Commenting -- commenting for a single line will be all in lower case and preceed the statement it will reffer to. -- single line comments must be in the same indentation as the code line they reffer to. -- commenting for a function or data type will be done with a comment block as follows: '/** ' * COMMENT HEADER ' * descriptive comment text ' * that spanns multiple lines ' */ -- The comment block must be placed at the same intentation as the declaration that it applies to. - Significant code -- significant blocks of code can be seporated by a blank line preseeding and following the block. -- extreemly significant code can prefixed with a comment block. well I guess that sorts out the formating and layout of the source code (if anyone has beef with it then just shout :). Im no good at naming conventions because I generaly make them up on the spot for whatever mood im in. They will become very important as the project grows and especialy for maths routines (without operators >:). we need something like constants are all capital. Types have capitals for each word in there name. Members start of lower case (java anyone :) and then follow type rule. local and global variables are all lower case (hmmm). Thats just my thoughts though and imo looks nice and neat. |
| ||
/** * * _____ __ .__ project - * / \ _____/ |_|__|__ __ ____ * / \ / \ / _ \ __\ \ \/ // __ \ * / Y ( <_> ) | | |\ /\ ___/ * \____|__ /\____/|__| |__| \_/ \___ > * \/ \/ * * Blitz Max Physics * * Source File : sourceName.bmx * writen by : author * extended by : who extended the file * more people * * description : what does this file provide * */ perhaps this could be the standard file header ? It looks like a realy retro menu screen :) |
| ||
| Anyone wanna try google code? |
| ||
| Sorry Pantheon, I won't be able to give much input today, extremely busy. But things look good so far, I look forward to working on the project tomorrow. |
| ||
| How about a small demo to start ? I suggest a simple line drawn terrain (slopes) with various shapes dropping from the top of the screen ? |
| ||
| I have infact started work on a small demo library to help make sure that I understand all the implementation details that Erin Catto proposed. Work is going well and its being combined with the polycolly style SAT test for polygons. I have also started work on a new GUI to manipulate and edit rigid bodies. I was going to use this to make sure im comfortable with the math behind the code but it could be used for a small demo to launch the project. Its a wee way off though :) |
| ||
| Im sure once you release the engine (in any working state), theres enough of us that are willing to do some demos for it. |
   |