The Daily DIP Count

Since “making of sotc” remains as the most important search phrase leading people here, I will attempt to whore some more hits by linking another interesting article, this time about Capcom’s new engine, used for Dead Rising and Lost Planet now, and for Devil May Cry 4 and Resident Evil 5 in the future. The Japanese original is here, and a semi-translated version is here. (For some reason Google Translate doesn’t translate all of the text - possibly on purpose.)

Several highlights, translated by kind people on various forums:

1. This MT engine work started in Sept. 2004 and they had something up and running by January 2005. It’s based on the Onimusha 3 engine. The project started with just one engineer, then ramped up to 3, and now they have 5 people maintaining and upgrading the code. They added 4 people now just for the PS3 port which started in Oct. 2005. The MT engine is currently used for Dead Rising and Lost Planet, but future cross-platform next-gen games will also use it.
2. They evaluated UE3, and they see they appreciate the strengths of that engine. But they were worried about some of the performance limitations at the time, and the lack of support personnel in Japan. They have high hopes for UE3 in the future. But they decided this time to go at building their own tech.
3. They started with Xbox 360 since it is so close to the PC platform and mostly compatible.
4. There have been requests from developers to license their engine due to the success of Lost Planet and Dead Rising. But Capcom feels that it would take too much effort to hire the appropriate support staff. They would rather put more effort into developing even better games for their users.
5. They talk a bit about the multithreading techniques they are using to get the power out of the asynchronously multicore CPUs in the 360 and PS3.
6. They give a detailed description of the technique and provide screenshots to show they are using to do motion blur on the Xbox 360. The algorithms are based on a talk given by Simon Green at NVIDIA at GDC back in 2003. (This is the one aspect of Lost Planet that looks truly next-gen, and makes the game really stand out and look unbelievably beautiful.)
7. More info on Xenon performance, 1 3.2Ghz core = 2/3 power of P4 3.2Ghz, but if use all 6 threads, you can get 4X performance.so Xenon 3.2Ghz 3 cores 6 SMT = P4EE 3.2Ghz 2 cores 4 SMT. And the memory access latency, yes the latency is bad, but like current gen GPU, more threads means you can hide the memory access problem better. so that is not a big problem.
8. Each character has 10k to 20k ploy, VS has 30k to 40k poly, background 500k. Normally there are around 160mb texture on the memory, 60mb - 80mb is background.
9. Dynamic MSAA adjust, base on the scene FPS. i.e. < 30fps, 4AA -> 2AA.
10. MT stands for Multi-Target, Multi-Threaded, Meta Tools engine.
11. Dead Rising scenes render about 4M polys, and Lost Planet scenes max out at about 3M. This is because of the demanding number of particles needed for Lost Planet. They said that drawing bleeding zombies is technologically much easier than creating a rich organic world filled with smoke, fire, and snow.
12. They are very proud of the techniques they been able to employ to get a tremendous amount of good looking particle effects on screen without causing slowdown. They said that utilizing the Xbox 360 EDRAM for certain screen effects gives them great speed without hurting frame rate. They said that this EDRAM, along with learning to properly use the multithreaded processors, are the two “tricks to making Xbox 360 games run well”.
13. They also mention that although their MT engine is being launched with Dead Rising and Lost Planet on Xbox 360, next it will be used for the PS3 title Devil May Cry 4, and then they plan a Xbox 360/PS3 multiplatform game next, Resident Evil 5.

Edit: Here’s a more complete translation.

You’ve played too much modern shooters when you launch Unreal Tournament (the original, not some newfangled drive-fest) and:

* you constantly try to reload

* when you get hit, you instinctively try to hide to regenerate

* … and you keep wondering is it _really_ worth it to walk over the weird boxes with crosses on them

* somebody gets close, you try to melee him… where’s the melee button?

And, seriously, dude, where’s my textures? You call this high-resolution textures? Is that the Wii version or something?

Once again I set out to prove people smarter than me are wrong by trying various things for tangent-space normal map compression, and once again I found myself wrong.

Lesson one: you can’t stuff normals in DXT1, no matter how much voodoo you do on the reconstruction side. The blocks show through, painting little 4×4 bricks on top of the bricks of my test texture.

Lesson two: if you resort to 8 bits per pixel, try the so-called DXT5_NM format. It’sВ X component in alpha, Y component replicated in the color components, Z = sqrt(1 - X*X - Y*Y). It looks OK, and has no visible blocking artifacts.

The problem with reconstructing Z from X and Y is that it’s a non-linear operation, andВ breaks down under bilinear filtering - just think of what Z component you’d reconstruct when fetching right in the middle between two pixels, one with (1,0) and the other with (0,1) XY components. The error is greatest near the equator (small Z values), but it is always there. Thankfully, real-world normal maps rarely have sharp normal boundaries, and most of the normals point straight up, so the general appearance of bumpiness is preserved. And it sure beats the blocks you get if you keep the Z values somewhere in the DXT5 block, or dropping the resolution of the normal mapВ in halfВ if you go to two bytes per texel.