verlet max polygon physics are here!
Community Forums/Showcase/verlet max polygon physics are here!
| ||
| well I hit a major milestone today when I finally got polygon physics working very well and almost flawlessly too. Concave objects work well as well as 'open objects' objects that dont close completely. Soft squishy objects are surprisingly stable and boxes don't gitter. I am surprised at how well this worked out so far. The next milestone will be a fluid engine (which I already have the maths done) to go along with it and a few optimizations to the polygon collisions. Heres the video: http://www.youtube.com/watch?v=bnK9hl4WUEg edit: better video http://www.youtube.com/watch?v=tEGBqZdaee0 nothing new to the physics world but it is a milestone for myself and verlet max. On a side note the polygons are 6 pixels thick, this eases collision maths a lot more and helped it be much more stable. Friction also works very well as I figured out the correct way to do it this time! |
| ||
| I'm glad you're still working at it. I haven't been doing much Blitz3D lately, I've gotten sucked into Unity3D. |
| ||
| Thats really interesting but the distance between the objects is a little heavy... what happens when you drop that distance down? Also, how are you controlling timing? I was using a delta system until I read an article in Game Programming Gems II that said making sure your game was predictable was paramount... especially for networked games. So now I use a stepper system that will only recalculate positions once per game tick no matter what. The delta system is still available but all the sprites, particles etc work on game "ticks" now. That might apply here as well... computer speed could be effecting the calculations making them unpredictable... just a thought |
| ||
| @skully I can decrease that distance but then the engine has to do steps to prevent things from overlapping and its not worth the efficiency I would lose for the same result. the only problem this system has is you cant make objects less than 12 pixels thick which I dont think is a problem really for a physics engine built for in game use. on the flip side you could also call it buggy drawing because the lines are not drawn where the actual collisions occur but where the constraints are. Implementing proper drawing into the engine is next on the list after fluid dynamics. I actually got pixel perfect collisions working but it was so much easier for objects to pass through eachother and needed some extra math and it wasnt worth putting the time in for a less efficient result. Believe it or not the update time when I fill the screen with boxes is 0 to 1 millisecs and with the blobs it is 4 millisecs so maybe i could spare some efficiency :p edit didnt see your timing question I am simply updating the physics a standard number of times per frame. the download is updated 3 times a frame. I think I will add delta timing as an option though in the future after more stuff is worked out. Basicly what this means is the method of timing will be up to you. If you want to call physics 100 times a frame with a delta of .01 then go for it or if you want to call physics once a frame with different delta's depending on the speed your game runs at then that will work too. |
| ||
| ok theres a new video, this time the polygon width is much thinner, only 2 pixels, and much more stable with practicly no jitters.. It is also worth a note that it updates 1200 times a second in the video at 60 fps so its really fast, so with all this new stuff I made a cool tower that I destroyed. Video here: http://www.youtube.com/watch?v=tEGBqZdaee0 |
| ||
| Really seems accurate and smooth whilst fast too. Well done, Nate this is great stuff |
| ||
| thanks Malice! if anyone happened to read the info on the video it said something about a bug but fortunately that has been solved and the best part is it was 2 lines of code away from my last bug except this time it was a simple logic bug not the wrong equation. |
| ||
| looks good |
| ||
| Nice work! Question: Nate, how are you recording the video? |
| ||
| thanks slenkar and _Skully @Skully, I use cam studio http://camstudio.org/ its free and it doesnt leave a watermark like hypercam or fraps |
| ||
| Is there some kind of award category, like the programming equivalent of the Emmys or something? Only, I think I'd like to nominate Nate for best newcomer. I can remember when you were just starting out, and already you're producing really impressive things like this and the fluid simulation, and it's really cool stuff. I've been doing this a lot longer than you, and I wouldn't know where to start with stuff like this. I'd like to see a game from you involving all these physics concepts though. Perhaps more than one type of physics. Done right, it could be a big Indie hit like Crayon Physics or Rag Doll Kung Fu. |
| ||
| haha its not worthy of an emmy award... but I guess I improved a lot. I wish I had a screen shot of my first game in qbasic... it had a giant lizzard that would chase and eat you... as far as physics goes, I think the physics stuff just came naturally after stevie g and pongo taught me how it worked, its my favorite subject after all and unfortunately I have not been able to take physics in high school until this year :p aparently I hadn't taken enough math courses which is really ironic. I'd like to see a game from you involving all these physics concepts though. Perhaps more than one type of physics. Done right, it could be a big Indie hit like Crayon Physics or Rag Doll Kung Fu. well thats what I have been planning while making these demos and working on the engine... Of course I want it to have fluid physics combined with 'normal' physics. At first I wanted to do a physics puzzle game but that might be too much like LBP and then pixeljunk shooter got me into writing fluid physics. Now I think the game will be more like an exploration game with puzzles and action where everything interacts and things like plants and possibly the entire level grow and change. That is a bit idealistic but it would definitely be cool. Of course while I finish off the fluid engine and the rendering engine and the physics body editor im sure I will get new ideas and inspirations. |
| ||
| Thanks Nate.. maybe I can make some demo videos of TileMax in action 8) |
| ||
| That's looking really good. There's something about the way things move in the newer video that just says 'quality'! It's so smooth. |
| ||
| Ya and not having the great gaps helps a lot too! :) Awesome work... I so want to put physics in TileMax but the way things are I'd be looking at some significant changes... or transposing the code to mine Yikers! |
| ||
| thanks BlitzSupport! @Skully Ya and not having the great gaps helps a lot too! :) yeah I like it more like that too. Awesome work... I so want to put physics in TileMax but the way things are I'd be looking at some significant changes... Yeah I think a tile engine built starting with a physics engine would be the way to go for full physics support but thats just the way I would do things. You can always incorperate physics like objects colliding with no rotation pushing things etc with no physics engine. Then again if you look at that metagolf game someone was making (cant remember who) it was tile based but also had a lot of physics on top of that. IDK exactly what they did that but I think they based the whole thing around box2d. or transposing the code to mine that sounds like a daunting/impossible challenge. |
| ||
| Nice. I don't know about Emmy's but one computer programmer won an Academy Award. Ken Perlin, the inventor of Perlin noise. So it's not impossible Nate! BTW, Perlin's page is awesome and quite inspiring: http://cs.nyu.edu/~perlin/ |
| ||
| Wow! The tower of dominoes is very impressive! Looks stable. Lots of stacked objects ;) I've been playing with the code in Nooboody's (Benedickt Bitterli) verlet physics tutorial trying to make it faster using a quadmap inorder to compare fewer objects when doing collisions, the seperating axis theorem collision takes 90-95% of the cycles in my program!. The n-pixel minimum limit... Is this because you are using sort-and-sweep aka sort-and-prune when finding collision pairs? Would like to know what kind of broadphase and nearphase methods you are using. Hm. Just did a quick search for "verlet physics as3" and found some very interesting works, maybe you know them: http://www.emanueleferonato.com/2010/01/18/flave-a-new-open-source-as3-physics-engine/ http://www.cove.org/flade/ |
| ||
| Thanks Axel Wheeler, thats a cool page, it has a ton of programming variety. That guy is pretty good at programming just about anything. @TWH yeah stacked objects are awesome... I actually did not use any seperating axis stuff because I want concave objects to fit in and I found a way I like more personally but it was an interesting article.. For now checking collisions is brute force but as soon as fluid physics are done I will implement some sort of grid system to minimize wasted collision steps. It is surprisingly fast with brute force collision checking but that wont be the case for long. The n-pixel limit makes life easier on me and anyone using the physics engine. When you set up an object for instance it doesnt matter what order you declare the constraints 'solid' or collidable. You can have open objects as well and concave objects need no special managing. Self collisions will come easily later with the grid and you will simply set a self collision flag for each object :) It makes it more of a set it and forget it with a lot of what are usually 'special cases' for physics engines and I am pretty sure it takes less cpu time but I was never able to get a side by side example to work properly so I just chose the best looking option. The minimum is 1 unit (pixel = unit for now - things will be scalable later when I start working with the graphics) width which is basicly the same as no thickness in a game but 2 or 3-pixel widths make any simulation much faster. I am not sure what broadphase and nearphase methods are... some collision method? It is all brute force while I work on the fluid physics but a general grid method will be in place after fluids are done. edit: well this website nailled it (pun intended) the first part is pretty much exactly what I am planning. Use a grid to determine likely collisions and then calculate the collisions http://www.metanetsoftware.com/technique/tutorialA.html |
| ||
| Nate, I'm using something like that... I use the tiles as the "cellular division method" and each sprite connected to the cells uses the cellular division method for collisions... I don't know if you recall that tilemax connects the tiles using a recursive Nav[2,2] technique... anyway.. example: The first cell thats processed is the first cell that the first sprite (in my case) occupies... it then compares that cell to its neighbors (all sprites within). When its done it tags the cell as complete (the source) . it also tracks which direction was complete using: Field Collided[2,2] ' where 0,0 1,0 2,0 ' \ | / ' \ | / ' 0,1 --- 1,1 --- 2,1 ' / | \ ' / | \ ' 0,2 1,2 2,2 When the tile is processed against its neighbor the reverse reference is set to an iteration counter as well as the forward one (changes each iteration) If the next sprite is in the same cell its ignored (as its already been done). If the next sprite is in one of the adjacent cells, it will only compare that cell to the ones next to it that have not been processed. So far its working pretty good.. too much overhead in the sprites to be used for fluids though (I think) I hadn't thought of that method until I saw verlet Max...so thanks for that. The difference in my implementation is that the sprite actually updates its own position on the tiles instead of them being sorted at collision time. Cheers |
| ||
| I hadn't thought of that method until I saw verlet Max...so thanks for that. The difference in my implementation is that the sprite actually updates its own position on the tiles instead of them being sorted at collision time. dont give me credit for that idea, im pretty sure it has been around since before I was born! But I have to say it is very useful. |
   |