DigiPen Game Engine Post Mortem

The summer semester has finally ended and so I wanted to give a rough postmortem of the engine I worked on as well as describe some cool features.

Architecture
First of all, we made the physics engine more component based than anything I had done before. We split the main components up into the following categories: Collider, Rigid Body, Constraint, Controller, Region, Effects and Spaces.

The collider and rigid body were the two main components. The collider contained the collision data as well as a position. The rigid body contained the center of mass and velocity. Each one also contained more data, but that was the main differentiation. The idea behind the separation was to split the functionality in a logical way. If a collider and a rigid body were placed on an object, then it would behave just as one would expect. However, if no rigid body was present then the object would be static and considered to have infinite mass. Unfortunately, despite trying to separate out functionality, there was still a strange dependency that the rigid body had on the collider. Most notably, a rigid body requires a collider and it also has to be initialized after the collider. Overall, I think this is a better structure than one massive physics object, but further experimentation and tweaks are still in order.
One benefit that we have not pursued yet is to have multi-object bodies. Currently, an object can only have one collider. The plan for this next semester is to extend objects to have one body for a set of colliders. This is a very nice component driven method of handling the non-convex object issue. I personally plan to implement this the upcoming fall semester.

The space component basically replaced a normal engine. The engine still exists, but now it does very little. The engine has a list of spaces and does almost no work apart from updating each space. Each space then in turn updates all its objects. This provides a very clean way to separate out rooms or other such physical space separations. This also allows different spaces to operate on different time scales. We had a timespace component that each space would use to figure out its update speed. This meant we could pause physics but still have UI running in a very clean manner. And yes, we enjoyed making lots of naming puns with the space component such as timespace, spacelink, geospace, etc...

The region was a nifty idea we had to make an area that would affect objects in various ways. How it would affect something was based upon what effects were placed on it, such as a drag or a random force. On top of this, effects could be placed on spaces and colliders. Collider effects would only be applied on the object while space effects would be global. This becomes very useful to apply gravity or drag globally to the world. The one thing we plan to change is to actually remove regions all together. A region basically kept a record of what was inside of the collider that defined it and applied the effects, however we can actually just have a collider do this with less work due to some things mentioned in the constraint layout section below.

The constraint component was exactly as one would expect, a constraint. This made adding all constraints much easier and allowed for constraints to actually be objects themselves. Along with constraints, we created a new system component called a connection to replace the transform. A constraint tends to not have a position, but two objects that it is connected to. This allowed the engine and other systems to understand this connection better, as well as deal with serialization cleanly.

The controller is what would be used by logic to control something, however this is not a component we actually implemented this semester.

Broadphase Tracker
One the coolest features we made we dubbed the broadphase tracker. The idea was to make a manager of sorts for the testing of broadphases. The tracker has two sets of broadphases, static and dynamic. The separation is a commonly made one since some structures can be more efficiently created if they are given a chunk of time up front.

One of the most useful features of the tracker was to track the accuracy of multiple broadphases and compare them. We did this by determining how often the broadphase and narrowphase agreed. This allowed us to figure out how useful a broadphase may be in a given scenario. Also, this allowed us to check if any broadphases had an error. If any broadphase reported that there was no collision but the narrowphase said otherwise, then there is an error since there should only be false positives. Therefore, the implementation of a new broadphase would be less frustrating as a basic N-squared could be used as a comparison to make sure no false negatives were ever reported. This was actually useful as we found an error in my old Sweep and Prune code both by it missing a test and by noticing that its accuracy was not the same as an N-squared bounding box test.

Another benefit that was not fully implemented was the timing of each broadphase. The one other thing we still want to add is a analyzer of sorts. the analyzer would load up lots of broadphases and tracker how well they do. Over the course of time it would drop bad ones and then at the end of a run it would provide the top 3. This would make finding the best broadphase for a game much easier.

Constraint System
The constraint system was what I spent most of my time on. My code was also very heavily influenced by Erin Catto's Box2D. One of the best designs in implementing this system was in the use of an Intrusive Linked List (InList) courtesy of Chris Peters (my boss). This allowed really quick insertion and removal of objects. This was also helpful in the overall structure. Unfortunately, it is a bit hard to describe this structure but I will try anyways. One day I'll make a nice picture or maybe even an ascii picture in the comments...

Each collider has an InList of edges. An edge then points to the constraint it is a part as well as the collider it is attached to. Each constraint then has two edges, one for each object. The edge that is in the collider's InList is one of the ones that the collider owns. From this crazy structure, a collider can figure out all of the objects it has a constraint with which allows islanding. Also, a constraint can remove and add itself to objects in constant time.

One other thing I did for future console extension was to remove as many virtual calls as I could. This was done by putting each constraint into a separate InList on the solver. The main disadvantage to this is the maintenance, but I spent some time to reduce this with macros. The idea was to make the solver define a macro then use it. The thing is that the macro was used in a header that just had all of the name of the constraints. This header would then be included so that some functionality could be done for all types of constraints. This was used for creating add and remove functions, iteration solving and more. If any macro did a large amount of work, a template function was made which did all the real work, such as solving constraints. This also meant that when updating, some of the templates could be specialized if a constraint, such as a contact, needed special behavior. Because of this the work to add new constraints is greatly reduced.
The problem is, due to islanding, constraints have to be added to the solver each frame and I have to figure out which InList to add it to. Because of this a virtual add call is used. This means each constraint still has a virtual call, but it is only once per frame instead of for every call during iteration. To further help this issue, contact constraints were separated and put in its own edge InList. Contacts are the most plentiful constraint, therefore separating it should take care of more than half of all constraints. This also means that it can be easier to check contact only relationships between objects such as the region effects mentioned above.

Materials
We decided to create a material system to define what each collider is made of. The system is rather simple, but it makes life for designers much easier. The material includes friction, restitution and density. We might add more terms later, but this is what seemed useful now. Because of this we can define soft objects or bouncy objects which is what a designer would really want to add. The one main problem is that we can have bouncy heavy or bouncy light, so defining all different types could be painful. To make matters worse, the bouncy heavy could be expanded to be slippery or rough due to friction. Because of this, we decided to only define a few materials and let it be configurable for the user. We thought of maybe using names like stone, but we wanted to avoid names that implied textures since they are completely different systems.

Recap
We did a lot of cool things in this project, most notably is the broadphase tracker. The component splitting also worked very well, but a lot of refining is still needed. As for the constraints, the system works very well overall, but I would like to spend some time to make it simpler and more readable.

I would like to put up a video of some of the cool stuff we have, but I have just recently reformatted my computer and so I do not have fraps or anything at the moment. Hopefully I'll get around to that within the next week.

As for what's next, I plan to continue working on this project next semester, although this is a little contingent on what happens with finding a job. My main tasks for next semester will probably be to clean up and polish some of the constraints and motors, add multiple colliders per body and work on a new broadphase. We might also work on a SSE math library.

Quick update

So unfortunately, I have been to busy to be working on my own physics engine on top of my other projects. I do not expect this to change at all for the next couple of months.

Both of my current projects are coming along quite nicely. The game I'm working on, Redivivus, is doing well, we still haven't found the sweet spot for the game idea yet though.

As for the open source DigiPen engine, that is working out very nicely. It is a completely constraint based engine and has a lot of cool features. I plan to write a postmortem once the semester ends. I'll also make some videos to show what we have.

Update

So the semester at DigiPen has finally ended. I have replaced the old Sandbox download with the most recent version of it that was the final result for my classes. I have not taken the time to strip out the features that are not %100 finished, so some things will not work as desired, most notably is soft bodies.

Also, my game has been finished and now has a new video as shown below:



Now for an update as to what I am doing now. First, I will not be continuing on my current team, but will instead be joining team Semi-Mobile from DigiPen on their game Redivivus to polish it up for competitions.



Exactly what I will be doing on the team is not decided, but I will most likely be doing some tools, along with helping out on physics and wherever else is needed.

Another thing that I will be doing this summer is working on an open source game engine that one of my teachers is making for eventual public consumption. Me along with 2 other guys (one from Redivivus) will be doing the physics, math library and collision tests for the engine.

Along with this, I will still be working on my own Sandbox, but I am currently ripping apart large sections of it and re-doing how a number of things work given that I know how to set things up much better now. I would hope to have a working version of my sandbox within a month. Most likely, nothing will look different, maybe I'll get around to putting shaders in, but most of the changes will be internal structure changes.

Dimension of constraints

So I currently have a very basic motor in, just achieves a certain angular velocity as an equality constraint, but I thought I'd mention an issue I ran into.

Constraints can only be solved on one dimension at a time in constraint space. Well what does this mean? When a constraint is moved from normal euclidean (or another space) into constraint space it becomes a generalized coordinate. An example of such things is the contact constraint. When we look at it we see that the constraint is in multiple directions, the x,y,z. But in reality the constraint is along one dimension, the normal. So what becomes a two dimensional constraint space problem? How about friction. Friction constrains the movement in the plane perpendicular to the normal. Well there are an infinite number of directions to pick from if you use only one, but if you use two then you can cover the entire space. This brings me to where I actually learned this issue, with motors. If you want to make a motor have a target angular velocity of 1 about the x, 0 about the y and 5 about the z, well you can't, at least not with once constraint. As some may recall, we have three degrees of rotational freedom, so obviously we can only constrain 1 degree at a time. So to take care of this issue we have to have 3 constraints, one for each axis angle we want to rotate about.

I'm trying to get a better way to manipulate my motors, mainly via the arrow keys so I can control a player, but things aren't set up well for that right now on top of the fact that our gold at DigiPen is due in less than a week now. After this semester I might be re-gutting most of my engine, but I'll try to get a basic video up before then.

Constraints Update

So here is a powerpoint on constraints that I created and recently lectured on at the game physics club at Digipen. Slides Download
If anyone has questions on anything in the slides, feel free to ask.

Here are some new videos that are not in debug mode with cooler features.

This is just a cooler looking rope bridge with smaller length constraints than before.


And here is a small "structure" made using stick constraints instead of ropes. Currently, the constraints do not have a "strength" value, so all constraints have an equal strength. This means that when I hang objects from the top, the bottom tends to be violated. I could always add more constraints to the bottom to "reinforce" it, but I would like to give it a strength at some point.

I have also added a lot of other cool features in my GUI that cannot be seen on this video, including deleting specific constraints and editing them as well.

Also a newer video of our game with properly exported character models. I would show the new character, but he can't do much without me networking this...we'll have to record an official video at some point as a team.


I might try to throw in some velocity motors in the near future, but the semester is ending soon and the game will require more attention.

Sandbox Fixed

So I decided to actually try my sandbox on a different computer and it turned out it would crash on XP because of some dll linking issues. After some time I tracked it down to an issue in my crash handler. Anyways, I have fixed it and re-uploaded it. The download links have also been fixed.

Edit: forgot to also mention that I have now included the ability to make distance joint constraints since I have that working now. Instructions for how to use it are in the readme.

Download

Constraints!

So I've been working on constraints for a while and got some stuff working so I thought I'd post some quick video clips. So far I have contact constraints and distance joints working, although contacts still have quite a few issues so stacking doesn't work yet. With the distance joints I was able to build a quick rope bridge that I made some videos of.





Some quick notes about these videos. First, this was my first attempt at making a rope bridge once I just found a big stability issue, so this video was recorded in debug mode. Second, you can see that contact constraints kind of work, but things like friction aren't the greatest in the first video. I had to make the block move slower otherwise it kept slipping off.

Anyways, that's a quick glimpse of what I'm working on. Pretty soon I hope to have contact constraints working well enough to stack and I'll also get up a better video that's in release mode. I will most likely be giving a lecture on constraints for the game physics club at my school soon, so I will be making some slides explaining constraints and the process of making them work.

Sandbox

So I set up a slightly stripped version of my sandbox that is available for download via this link Sandbox. The main thing that was stripped out is the soft bodies, as they currently will not collide properly with the heightmap ground and just fall through. I have not stripped out the code, just the interface in the GUI. In the download, there is a readme that explains the basic controls and how to operate my sandbox. A small bug I found after I uploaded is that after resetting the system, impulses are still used even if constraints is chosen. To fix it, just click impulses then constraints again.

I want to point out also that the constraints being used are not done, in fact they are very much in a trial state, but I wanted to include it incase anyone wanted to see. At the moment there is only a contact constraint, but it shouldn't be too hard to add other simple ones.

Constraints starter

So I have begun the process of constraints and I felt I would share some of my initial insights and things to watch out for when starting.

First and foremost, always check what space you are in and make sure that everything is in the appropriate space. Most notably take care with your "r" vector and your inertia tensor. By "r" vector I mean the vector from the point of contact to the center of mass. Along the same lines take into account what direction your normal is facing. You may assume obj1 to obj2 while a paper may assume the opposite. And don't just flip the negative sign and see that it works, take the time to sit down and figure out if that is really the correct answer. That brings me to my second thing to be wary of...points of contacts. Make sure that your collision data is extra accurate as constraints seem to have bigger issues if the point of contact is not actually on the body. And thirdly, do not use the previous integration scheme I mentioned for constraints. By integrating and then reverting positions, the point of contact is no longer on the body which goes back to issue two. Then again, constraints should not need any fancy integration scheme because they can make stacking work on their own. The original Fedkiw method may still be applicable, but other one causes many issues with things other than constraints, such as swept collision. My plan is to use a more traditional approach to integration while developing constraints, and then try out the Fedkiw approach since it should introduce almost no negative effects on constraints or swept.

Now hopefully no one who reads this will fall to some of the same pitfalls that I fell into initially. Once I actually get my constraints working with friction and position correction then I'll post a more in depth blog on how to do constraints. I also plan to try something other than just a contact constraint, so I'll able to get a sense of how extendable my current approach is. Until then...

Stacking - revisted

Now that I've finished putting up previous games and some videos, I think I should go into some more of the details of how I implemented my stacking with impulses. Stacking is one of those things that seems like it should just work, but with computers it doesn't. Therefore it's one of those things that almost every physics developer attempts to make their engine do. So how do you do it?

The main thing that makes all the difference is changing up the integration scheme as described by Fedkiw. The actually implementation I used is a slight alteration of what was done in jiglib. This process is as follows:
Integrate velocity and position (cache previous values)
Detect Collisions
Revert velocity to the beginning of the frame
Resolve Collisions
Revert position to the beginning of the frame
Integrate velocity
Resolve Contacts
Shock Step
Resolve Penetration
Integrate Position

The main difference between this implementation and the Fedkiw approach is the "ghost collision" that happens. When objects are tested for collision, they are tested at where they will be at the end of the frame, but then later moved back to the beginning of the frame. This can cause collision to happen a frame early. Either way, since I am performing discrete collision detection, there will be a visible error. The question is, which is more preferable, too much penetration or too much separation? This approach favors too much separation, which tends to be a harder thing for a user to catch. The one strange caveat I'm working on now is how to fit swept collisions into this. I plan to sweep between the old and the current position (since I will have just integrated) and figure out what the first time of collision is for all objects that are being swept. From there I will just move the object to that time and treat it the same as all other objects. This is not quite a correct answer, but I hope the results will be good enough that no one can tell.

So all you have to do is just swap the ordering of integration and resolution around and you get awesome and perfect stacks, right? Unfortunately, no. I mean, this is stacking, you can't get it that easily. There are some extra tricks, most of which are described in the Fedkiw paper, that you have to do.

So before I delve deeper into the extra things, I'd like to clarify some terminology. A collision is when two objects hit each other with a large separating velocity. A contact is when they have a small relative velocity. You can avoid using a threshold for this technique, however I chose to use some epsilon to denote a "collision" as being either a collision or a contact. Just a note, I will now use the term manifold to avoid confusion with the word collision as demonstrated by the previous sentance.

Now onto the tricks! First, when resolving the manifolds, multiple iterations are required to get good results. I personally iterate over collisions and contacts 10 times each. Now you may be asking yourself, "Why would you iterate over collisions?" The reason in the case of collisions is to propagate energy through the system. Imaging you're playing pool and there's a line of balls next to each other. Without iteration, the first ball hits the second and the frame ends with ball 1 not moving and ball 2 moving. Now if you iterate an extra time, the energy of ball 2 transfers into 3 and so on. Anywhere from 5 to 10 should get accurate enough results for any game. Now to answer the other half of the question, what about contacts? Well first, I must confess that there are more hidden details in iterating over the contacts. When iterating over the contacts, you need to actually use a negative coefficient of restitution. You should start your counter just next to -1 (but not at) and end at 0. This should be written so that it depends on the number of iterations you are doing. Now what does using a negative coefficient actually do? It slows down the objects. The reason we want to do this is so that no object is favored in contact resolution over another and so that no pair of objects is set to have 0 separating velocity initially. Instead, this allows blocks to slowly respond to contacts before their separating velocity is killed. The best example of this is a seesaw like problem. If there is a stack on one side and a block comes flying down on the other side, without the negative epsilons the seesaw won't even move. With one iteration only the top block in the stack will move. This is a harder one to understand than with collisions, but you can think of it as also being for the propagation of energy.

Now that I have unveiled those hidden facts, I should bring up the order in which these collisions should be resolved. To get a stable stack, it tends to be best to work from the ground up. To do this in an efficient manner, a contact graph is needed. With the graph you can topologically sort your collisions and get the appropriate order to resolve them in. The way I represent my contact graph is with a Hash Map for nodes, for in edges and for out edges. To sort the graph, you just need to work your way down the in edges until there is nothing below you. From there you add all of your out edges and work your way back up. If done correctly this will ensure that no object gets resolved before anything that is below it. Now I've been told that iterating over the stack in a consistent pattern can lead to slow drift over time. The solution to this would be to alternate between iterating forwards and backwards, but I have not done this so I can not attest to the results.

So, the last ambiguous step, the shock step. What is the shock step? Well it's just a step where you treat the bottom object as if it had infinite mass. This will make the stack suddenly stabilize by forcing the top objects to get out of the way of the bottom ones. This step tends to be crucial, as most stacks will not stand for very long without it. The problem with this is that it is an incredibly over-aggressive stabilization attempt. The issue is that this allows any object that would fall if it were on the top of the stack to not fall if it is in the middle. This can lead to towers that would normally fall being able to stand upright. You can get the "staircase" issue, which is when you have a tower of blocks going off to one side that will not fall. The shock step forces a quick local solution that causes some global behavior to be ignored. However, this tends not to be a huge issue for games because the "staircase" tends not to happen naturally.

Now the last thing that should be done to get good stacks is sleeping. Sleeping is a two-fold benefit, it helps stabilize the stacks and it speeds up the simulation. The are many different ways to sleep an object, but the approach I use is to put the object to sleep if it has a linear and angular velocity below some threshold for a set amount of time. Unfortunately, these values tend to be simulation dependent, so toy around with something until it looks good. Even if you have good stablitity in your stacks without sleeping, add it in for speed. There's no point in checking and object that is not moving for collision with another non-moving object. Now that we've put objects to sleep, we have to somehow deal with waking them up. Obviously, if an object is hit hard enough, it will get a velocity imparted into it that should bring it above its threshold for sleeping. So waking up an individual object is not a hard thing to do. But what if there was an object on top of a sleeping block? I'm sure you've seen games where you can knock out a bottom block and the top ones float, well that's exactly this situation. In order to correct it you need to somehow know if there is an object above any other object. If only we had some way to know this, oh wait, we have our contact graph. So now, if we wake up a sleeping object we can wake up anything that is above it, which will in turn wake up those above it.

So that's most of what you have to take care of to get good stacks with impulses. These stacks will not be as good as one with constraints, but constraints are a lot harder. However, constraints can also do a lot more. Once I get my own constraint system up I'll post something up on those too. Maybe I'll even have some power-point slides...

Games

Well now that you've seen some of my personal stuff, how about my team stuff? Well first I had a freshman text based rogue game, but I don't feel like digging it up and making a video of it at the moment. Instead, I'll just start with my sophomore game.



My sophomore game, Barrel Bros, was my first attempt at making a physics engine. I started out trying to be "fancy" by doing what was more or less a continuous engine, although I had no idea that's what it was at the time. At the end of the first semester, I had realized how bad of an idea this was. I'm not saying that continuous engines are bad, just a lot more complicated than they're worth most of the time. So over the break I converted this to a discrete engine that worked with impulses. Even though I had started down a better path at this point, I still had a very simplistic engine. Most notably, I had no rotation. So all of the barrel "rolling" was faked with game logic. The one cool thing that I had in this game though was "curves" for the barrels to roll on. I say "curves" because they were really just line segments being approximated as curves, but they achieved a good enough affect.

At the end of the year I decided to start work on my 3D engine for Junior year. This time though, I had a good idea of where to start and how to do things. I even decided to tackle the challenge of rotation...which isn't that bad. Here's a small video of our Alpha build:



Now this is me once again using my trial version of fraps to record this. Once we get to the later stages I'm sure we'll get a more official video, until then this will have to do.

So the first task I took on was collision detection. So I first set up the basics, sphere sphere. I then set up impulses to get those resolving correctly without friction. From there I decided to be extra adventurous and implement a new collision detection scheme I had heard about, MPR. MPR, or Minkowski Portal Refinement, is a collision detection algorithm that works on arbitrary convex polygons. It took me most of summer to get this working, but the results were quite nice. Unfortunately, MPR has some issues with long thin objects, and I also wanted better speed. So about 1 month ago I replaced most cases with specialized SAT tests. So at the moment MPR is not being used anywhere...But after that I had decided to do stacking which took a large amount of time.

Skipping forward to now, the main tasks I have left for this game in physics is to get raycasting to work efficiently for picking of objects and to write some swept collision tests since our player moves so fast. At the same time I'm working on constraints for my Physics class project. Hopefully I'll be able to get that running in the near future so I can get some videos of that up.

Soft Bodies

Soft Body dropping on ground:


Soft Body being poked on the ground:


I've decided not to fight blogspot for now and just go youtube...
Also a note I forgot to mention on the last post, to keep the size of the video down I'm recording at 30 fps. The actual simulation runs just fine at 60...

This is a video of my pressure model soft body.
First of all, this is all done with debug drawing. The black points are the point masses, the white lines are the springs, the red triangles are the faces, and the black lines are the normals of the faces.
Secondly, this is using Euler integration. I'm sure the results will look a lot better with Verlet or some higher order integrator. Another interesting thing I could do at some point is to construct the sphere using a geosphere instead of the standard stacks and slices approach. For all who do not know what geospheres are, they are spheres made of equilateral triangles. Doing this will make the simulation work a bit better because the lengths of the springs will be more standardized. The same issue will still crop up as seen on the video with the top of the sphere, since many points have to connect to one point. This causes extra osculation that is hard to get rid of with just an Euler integrator.

So how does it work? Well a soft body is very close to a cloth. Well how's a cloth made? A cloth is basically a set of point masses connected by springs. That's it, you just have to make sure that you have all the necessary springs (like next next neighbor) to make a cloth function properly. Now a soft body is just a wrapped cloth, without the next next neighbors, that you put a wind force inside of. More details are in these papers on the actual implementation:
http://www.ep.liu.se/ecp/010/007/ecp01007.pdf
http://panoramix.ift.uni.wroc.pl/~maq/soft2d/howtosoftbody.pdf

But basically you just apply forces to the points on each face while enforcing the ideal gas law pv = nrt. The exact specifics, as I've said before, I'll not go into details on because the paper does a better job than I will. Now how do I do collision with this thing? Well first, I just approximate the volume with the AABB of the soft body, which is used for the pressure model. I then use that as an early out to test with other objects AABB's. If the two AABB's intersect, then I just do point vs. object and resolve the impulse. At the moment I have the intersection limited to just OBB's, but I will add more at a later date.

So in conclusion for now, soft bodies are a very cool thing to have and something I would highly recommend implementing. The only issue is that it's hard to get any good use out of them or make them a key feature in a game. Also, if you use Euler, stability can be a bit of a problem as springs like to explode if you set values to high or to low.

Edit: was just bored so I re-added the ability to poke soft bodies, but this time I actually ray cast with each face and apply a force on those points...video link added to the top.

Stacking

So I decided to upload a small demo video of my stacking. Due to using the trial version of fraps, this was limited to 30 seconds.




This was a stack of a 2 x 20 x 2 tower of blocks. There are a number of things I'd like to point out in the video so that no one gets confused, most of which are related to debug drawing. The most notable one, the color change of the blocks represent them being put to sleep. Shortly after I turned wire-frame on, I turned of the ability for objects to sleep so that other debug info could be shown better. The small points and lines being drawn represent the collision point and normal. Combined with the ability to pause and step through the simulation, which I did not show here, these debug drawing features make it much easier to observe a whole scene and determine if anything is amiss.

Just a small note on how I am doing the physics in this simulation. First, collision detection is done using Separating Axis Theorem. Then collision response is done using impulses with a modified version of the resolution scheme mentioned in the paper "Non-convex Rigid Bodies with Stacking" which switches up the order of integration and resolution then follows up with a shock-step. The order to resolve and sleep objects is done with the aid of a contact graph which topologically sorts the collisions along the y-axis. In the near future I will put up a small videoof a pressure model soft body.

First Blog: Who am I?

Hello all who may read this, this is a blog to introduce who I am and what I'm passionate about. First of all, I'm currently a Senior at DigiPen Institute of Technology. Although I'm officially a Senior, this is my third year at DigiPen . This means that I'm on my third game, my Junior game.

For the past two years, I've been doing physics on my game teams. Sophomore year I had a simple engine with 2D spheres colliding with cubic bezier curves approximated as line segments. This year, I've moved up in the world of game physics and a dimension (3D now). I enjoy game physics both because of the challenge it provides and because of how fun it is to play around with. Hopefully I'll be able to get a demo or some videos soon so you can see what I'm working on, along with my past games.