Léna Piquet
Physics in UDK and Colossus
Exil Dev-Blog 1
February 27, 2012
I will try to make updates of my project more often now. Here the first "true" dev-blog post on the project. I will try to talk about my design, problems, and solutions.
This time I’m working on the first colossus of the game and it’s not very easy. My big problem is the physics engine of the UDK.
The physics in UDK is one of the things where you have the less controls. The UDK provide a lot of tools to specify how your character/level will be affected, but you can’t control the physics itself. I say this because I have meet a lot of problems regarding the physics corrections made automatically by the physics engine.
For example, with my climbing system I need to enable collisions on the ledge to get a feedback when I make a raycaster. If I disable the collisions of the mesh I can’t use it. I have quickly solved this issue… well not exactly. I finally found I was able to activate a "touch" event and at the same time to disable the blocking of the collision. At the end I get what I want, my raycaster work and my player walk without being blocked.
But I finally found this issue was not solved. Even if I disable the "block" event, the physics engine will try to push you away from the collision box of the object. Not matter what parameters you use, if you enable collisions, you can’t stuck in it (which from an eternal point of view is totally logical, but not appropriate regarding the settings you have specified).
This was a big problem for me since I needed to merge different objects/collisions together. The UDK can’t use specific filters for the collision. That’s mean you are not allowed to choose who collide with what. You can only decide if this or this collide, not how.
I have finally circumvent this problem by simply put away the collision box while the player is climbing a ledge. That’s mean the animation of the climbing process looks good for the player, but for the physics engine it’s not accurate and this the collision box is a bit away.
It’s a trick, I can’t do otherwise. It’s a limit of what we can do with the UDK. On this point it’s very annoying.
For the Colossus I got quickly stuck on one fact : you can’t walk on a skeletal mesh in the UDK. By default you got some strange rebound which make you unable to stay on the mesh.
Of course you can disable this rebound. I lost one day or two to figure out how since there is not information on this subject. I found the solution by reading all the usage of the variables in the Pawn class. Funny to that my solution was also a nice easter egg :
var bool bCanBeBaseForPawns; // all your 'base', are belong to us
Pretty interesting reading by the way (I think I will read all the default class entirely one day, some lights will switch on).
This point solved, I got an other problem : the pawn position is not updated. For example I fall on the head of a monster, while he is performing an idle animation. his head move up and down. Well, while the head move down, my pawn will fall without any problems (because the default physics system still handle my pawn, which mean if I loose my floor I fall). But if the head move up, my pawn stay where he is : that’s mean his position and physics is not updated with the skeletal mesh. Example (Before & After) :
It’s a big problem since I need to be able to walk on my skeletal meshes, I’m currently making big Colossus where the player need to walk on them. I finally found an other trick : using interpolated actor (or Mover inside the editor). These actors in the UDK are very special, they are often used for making platform, elevators, etc…
It’s because whatever things are touching this actor, their physics is always updated. I have quickly made this video showing of I’m able to walk on my skeletal mesh by the way of these actors :
Hourra ! \0/ I have done this test a long time ago, I was quite happy to being able to circumvent the problem.
Unfortunately, since a few days I’m trying to apply this solution to my Colossus which is now an NPC and no more a simple skeletal mesh decoration. I precise because I got now a new problem. As I said in the section above about Physics in UDK, I got the same problem with the Colossus. Everything I try to attach to the Pawn (Colossus) is pushed away by the Physics engine.
I discovered it’s a special thing proper to the Pawn Class. If I inherit my Colossus for the class above (Actor) I don’t get this problem. I hope to not being forced to do this later, because the Pawn class in UDK have a lot of advantage for making Character movable and so on. Being forced to redo by myself these advantages from a more abstract class will be hard and not perfect as it’s currently done by the Panw class (since it’s mostly native code and well optimized).
I have also tried the per-poly collision of my skeletal mesh, but this system is not compatible with soft-weighted skin. That’s mean whatever is not "static" will not be followed by the collisions. Explanations with screenshots :
The per-poly collisions are finally only usable by the vehicles.
This is why I finally come back to the classic collisions system based on the physics assets. Since I have planned to use the Inteprolated Actor to make my collision I thought it would be not necessary to use other collision. Unfortunately, as an other limitation, if you don’t make this physics asset the engine is not able to know how render or not of your mesh. That’s mean that without this thing, the monster which is front of you can disappear from the current frame to the next one. It’s also mean that the engine is unable to know how to render the shadow of your mesh.
The physics engine is finally my most powerful enemy in this project and with this engine. The UDK is pretty cool otherwise. That’s very annoying that we don’t have more access to the physics. I still like a lot the UDK because on the other sides is still a great tool.
So, I hope I will be able to solve these news problems. See ya for the next dev-blog ! 🙂