Léna Piquet
March 14, 2012
Second dev-blog, back to you with some news.
Environment test for the climbing
Yeah, I will talk again about the physics on the colossus. I have made on new discover on the physics in UDK, especially with them interacting with a Pawn actor. If you don’t use the per-poly system in the UDK for your skeletal mesh, you must use the system called "Physics Asset" if you want them to collide.
This collision system is simply a mix of 3 basics shapes that you can fix on the bones of your mesh. You are allowed to use a sphere, a box and/or a sphyl. of course these collision are not exactly accurate but for a real-time purpose there are almost perfect who most of their usages.
Almost… Well in my case I discovered that the sphyl and the sphere shape doesn’t interact with the pawn actors AT ALL. It’s a pawn only problem : these collisions are made to collide with the world interactions (such as bullet, crates falling, etc).
Why is it a problem ?
Since my previous blog post, I have decided to use the interpolated actor. Even if I will use most of them to make proper collisions with the player and the Colossus, it’s not perfect. This is why I would take the chance to use the physics asset (since I already need them for the camera and the shadows). Mixing interpolated actor (for allowing the player to walk on the Colossus) and the classic collisions (physics asset for pushing away the player) is important. But the sphere and sphyl are not working, so we need to use the box shape. The problem is that the box are the most expansive shapes for computing the collisions. At the end, my custom physics system will become more expensive than the basic physics assets provided with the UDK. However, since I’m using this technique only for the Colossus which is more or less an environment rather than a character, it’s will be probably fine in term of cost regarding the whole scene.
I have finally managed to attach the collisions of the colossus based on the bone location. For the bone rotation, I have quickly figured out that the engine was returning to me a quaternion instead of a simple rotator. I have started to try to convert this quaternion into a rotator for correcting the rotation. Unfortunately this task asked me to do too much advanced maths (at least for me). I have finally switched to the socket system of the UDK. Since that I use the bone location for setting the position of the Collision mesh, and then correct his rotation with the rotation of the socket. It’s trick, but it works very fine. Quick test of the player walking on the shoulder of the colossus while is he in idle :
The collisions follow the Colossus movement without any problems.
You can walk on it. 🙂
On the other side, I’m also trying some render tests. I try for the moment to get a good render for my rocks. I make the high-poly inside zBrush, I do a quick polypaint (for highlighting the edges, making some color variations). The next step is a retopology inside Maya with my custom script (I have a new retopolgy script, much more powerful than my old one). Finally I bake the normal/AO/polypaint with xNormal and merge them inside photoshop. I add some texture variation by inserting some photo texture of rocks.
Here a quick result inside the Marmoset Toolbag :
For a quick process I get a pretty nice result, I guess that with more time I could improve a lot the render with a manual paint over the diffuse.
I try to be more prepared than before. Currently I’m working on a lot of design document, trying to clarifying a lot of data to be sure that everything is right and well prepared. It’s my "pre-production" phase in fact ! I have finished the document which resume all the gameplay phase of the game for example. I need a new one now for explaining all the gameplay mechanics. I’m also strongly thinking about the main character. I currently work on its concept, it’s hard to find a character well designed for the gameplay. You must mix some graphical aspects with some gameplay facts and logic. A character which will run along all the game will not be using a corset for example.
I try to design at the same time some clothes which will be easy to interact in game. Since the clothes would be destroyable, I need to think in a way that allow me multiple clothes at the same time (layers of clothes). I have done in the past some tests with multiple topology superimposed. Unfortunately when come the time to animate and skin the character, you get a lot of problems. It’s mostly some bad interpenetration with the multiple topology.
I also want to add some dynamism in the clothes of the main character driven by physics. Using something like a dress (just an example) which follow the movements of the player. Maybe I will test the APEX system of the UDK, but the setup of this type of mesh looks very complicated.