Eurogamer.net website has published some very interesting materials, related to upcoming Metro 2033 title. Firstly, they revealed full specifications of proprietary technology behing Metro 2033, known as 4A Engine, which is called even by its developers “one of the most advanced engines on the planet”.

You can read full specs here, and we’ll quote only part related to engine physics system:

Metro 2033 is coming out March 16 on PC and Xbox 360, PC version will include 3D Vision, DX 11 and GPU PhysX support.

Update:second part of interview with Oles Shishkovtsov was published on Eurogamer. Provides more in-depth details on PhysX SDK integration, and engine’s genesis in general.

Digital Foundry: The 4A engine integrates NVIDIA PhysX. What are the core advantages of the hardware acceleration, what sort of hardware do you require for the best experience?

Oles Shishkovstov: The core advantage is simply the performance. The CPUs just aren’t there to enable large-scale physical effects (although they are very competitive when processing traditional rigid-body things). However, when you offload costly PhysX processing to GPU, we’ve got less GPU time for rendering.

It’s a difficult question when choosing what hardware will provide the best experience. I’d say that dedicating another (maybe less powerful) GPU specifically for PhysX is the right thing to do!

Digital Foundry: Over and above the tech demo-style elements that make PhysX cool, can you explain to us how the physics add to the gameplay experience?

Oles Shishkovstov: We do not add PhysX effects if they aren’t integral to the gameplay experience. We don’t add an effect for the sake of an effect. Human eyes and brain are trained to see the inconsistencies. We are only trying to remove those inconsistencies in order to not distract from gameplay and not to lose that immersion we were heavily building brick by brick.

Digital Foundry: How did you integrate PhysX into your many-core engine assuming you don’t have hardware acceleration? Are the same principles in use in the Xbox 360 code?

Oles Shishkovstov: That’s easy. PhysX SDK has the similar notion of the “task” as we use. The SDK spawns them for every operation which can be safely parallelised, for example each rigid-body shape-shape collision detection, each cloth or fluid update, even the solver(s) is heavily sub-divided into the tasks.

We forward those tasks to our task-scheduler and they are processed in the same manner as everything else. The only “conceptual” difference is between their and our task-model – we “spawn-and-forget” tasks and PhysX uses a “spawn-and-wait” model.