The Supers (working title) update
I’m about a month or so behind schedule so I might as well talk about why:
Implementing deformable collision is HARD
My giant robots require skinned collision (collision geometry deforms while the bones are animating) for the superheroes to walk on. Most physics engines will not allow non-static collision meshes to deform/animate and not only will they not allow that they won’t calculate physics afterwards.
I’ve had to create a low-resolution collision mesh that deforms and matches the visible mesh. All of this was expected and planned. At every frame, I grabbed the skinned/deformed data from the graphics engine and update the collision mesh. Performance-wise this sucks. This wasn’t planned. Mesh-to-mesh collision is slow and expensive. The hero is a sphere/capsule and the robot is a mesh, there shouldn’t be any problems, right?
Wrong.
Mesh-to-mesh collision occurs when the robot interacts with the buildings of the city… this results in an immediate frame drop to 5fps or worse. The robot’s 50K polygons try to collide with 3000 polygons of a building The results are brutal.
There are multiple solutions to this problem, but none that pleasant:
- Mirrored physics worlds with ultra-low resolution geometry
- Pro: Speed, separation from main physics
- Negative: Sync issues with duplicate physics world, adding complexity to the art pipeline
- Extending the physics engine to accommodate for multi-resolution collision detection
- Pro: One unified physics world, can make-do with procedurally generated collision meshes (requires no artist)
- Negative: Very complicated to modify the design of physics engines (i.e BULLET)
My solution is a mix of the two. I’ve created ultra-low resolution collision geometry for the robots using a script and while I’m not extending the physics engine, I’m using its facilities to filter out collision between two classes of objects. It’s not ideal, because this filter is accomplished closer to the narrowphase level.
Designing vertex/fragment shaders is HARD
Months ago, I roughly mapped out the look and feel of the heroes and robots. I knew I wanted a GI look of spherical harmonics and to avoid lambert + blinn rounded white hilights + specular.
So I designed shaders to use BRDF textures. I started with one BRDF texture then two then three… each to control different viewer vs. light setups. The result is a shader that can emulate toon shading to satin - while avoiding the circular hilights of lambert. Every new feature I added (normal maps + hardware skinning) had to be properly integrated into the existing shader which was time consuming.
The worst part is taking these HLSL/Cg shaders and migrating them into your engine, because it’s not as easy as 1-2-3. Each engine has their own methods of binding lights/cameras/matrices to shaders. In OGRE the binding is accomplished in .program and .material files. Thankfully there’s a python-based script available for FX Composer that exports a basic .material file (40% of the work), but the rest requires a lengthy trial and error phase.
- mul(M,V) is preferred in OGRE vs. mul(V,M) in HLSL/FXComposer
- Y texture co-ordinate flipping
- Global variables in HLSL/Cg are horrible and should never have been allowed, but all shaders use them.
- .fx/.cgfx passes have to be manually re-coded.
- The shaders from FXComposer are unoptimized for OGRE - also, sample OGRE shaders work in local/tangent space whereas the FXComposer shaders operate in world space.
I don’t recommend writing your own BRDF shader. I’d take an existing one and modify it:
Being a producer, lead developer and lead technical artist is HARD
I thought once the prototype ramped up, my managerial roles would diminish, but in fact they have increased. While I’m assigning work to 3rd party contractors (I understand I can’t do everything), I’m spending just as much time checking the work and fixing it as I am on my own work. The rigging has proved most complicated, but that’s a topic for another post.
Other tasks that have proved difficult:
- Robot rigging (it’s not a simple character with a single rig)
- Threading
- Designing the city
- Building destruction
More next time…
Add comment August 3rd, 2008