!eVo!-X Ant UK
Banned
I found this interview, they say it all IN-ENGINE.
And a few comments on the hardware.
DEV DIARY
If you split the demo into 2 sections (interior and exterior), the
interior runs real-time quite happily at 1080p. The exterior struggles
a bit but more because we just kept adding more and more till it looked
right without going through various optimisation passes then anything
else (i.e. the flags are really expensive at the moment due to a quick
implementation).
Without saying anything regarding hardware etc. I will say everything
you see is still early and we expect it to run alot better in future...
avoid things, stay in formation etc., they try and jump out of the way
of the boozaka if you look carefully...) and use the normal animaton
system, they are even the same models, the LOD system handles it
transparently. They also turn into Havok ragdolls for a decent death.
Currently they are all on a single processor core, so the framerate
drops pretty sharply at high number of entities... but this should go
away once we have had a chance to work the machine properly...
Sony asked for 1080p for the trailer, so we provided it... Assuming all
things being equal I can't see why the final game wouldn't...
FPS I'll be really disappointed if we can't keep a steady 30 at worse
and would prefer 60 but given time scales 60 may not be possible (I'm
personally fussy about framerate so I'll try for a steady 60fps)
HDR is bread and butter for us, something like 2 years old tech.
Originally 16 bit integer (back in the ATI 9800 days) now FP16 based.
X360 has a nice 32 bit float mode (FP10) but I expect that will be
quite hard to use for proper HDR (never got a chance to use it so can't
really comment), considering we have actually hit precision issues with
FP16 framebuffers (64 bit). FP16 seems to be the best comprimise for a
framebuffer at the moment (its enough for most lighting, though we run
out of precision directly in front of the sun (noticeable on our cloud
renderer))
We haven't yet made the jump to a multi-thread game architeture yet. Almost everything sits on a single thread...
Actually the face is the only rendered thing in the demo, its uses our
high-end model (used for the surface extraction) rendering in Maya and
composited onto the in-game background. We were orignally intending to
do it in-engine as well, but there just wasn't time to implement all
the tech for a closeup (we don't have facial animation system at this
moment).
The other closeup of her face (after the aerial fight when she is falling down) is in-game.
Graphics and framerate are the low hanging fruit. Just threading up the
animation system and procedural graphics (hair, cloth, flags etc.) will
gives us a large amount of CPU time back for the game. The army need
this the most.
Longer term, Physics and AI services are obvious candidates.
As for what improves?, thats a good question. The priority is to move
the heavy weight stuff off the main game thread, hopefully doing this
will provide lots more time for the game code. That should improve the
gameplay in lots of ways.
Wether we will acheive all this and keep the code easy to develop with
is the big question. Lots of designers and coders (especially the more
junior members of the team) aren't used to dealing with threads, DMA
and C like code. Keeping a balance between the high level and the
harder stuff is the biggest challenge. I don't want a level designer
having to worry about threads but at the same time don't want him/her
coding in such a way that its totally serialised...
Its in-engine but I'd be lieing to say its very playable at the moment
BUT we have lots of work to do in this area. There is something like
2000 people on screen there, we have shown 500 people @ 30fps on our
old PC demo (GDC2004 time). Were not currently as efficient as we were
back when we did the last demo, a new more advanced shadow system and a
few other changes make each bloke a bit more expensive. To be honest
though, we knew we were about the change to the target platform when we
made those changes so optimising for a PC engine was a bit pointless.
Given the power and architecture of the target platform, it seems
achievable.
Actually Wil (one of the coders) has done some research work on
achieving that kind of depth of field and motion blur in-engine since
we finished the E3 demo. Its still being worked on but it looked pretty
good last time I saw it. He's calculating per-pixel velocity vectors so
you actually get smearing and blurring along the movement axis...
Currently we are about 30 odd, with the majority being coders but with
the rapid ramp up to full production we will grow alot (more than
double) with the art team becoming a much larger group percentage wise.
And a few comments on the hardware.
DEV DIARY
If you split the demo into 2 sections (interior and exterior), the
interior runs real-time quite happily at 1080p. The exterior struggles
a bit but more because we just kept adding more and more till it looked
right without going through various optimisation passes then anything
else (i.e. the flags are really expensive at the moment due to a quick
implementation).
Without saying anything regarding hardware etc. I will say everything
you see is still early and we expect it to run alot better in future...
avoid things, stay in formation etc., they try and jump out of the way
of the boozaka if you look carefully...) and use the normal animaton
system, they are even the same models, the LOD system handles it
transparently. They also turn into Havok ragdolls for a decent death.
Currently they are all on a single processor core, so the framerate
drops pretty sharply at high number of entities... but this should go
away once we have had a chance to work the machine properly...
Sony asked for 1080p for the trailer, so we provided it... Assuming all
things being equal I can't see why the final game wouldn't...
FPS I'll be really disappointed if we can't keep a steady 30 at worse
and would prefer 60 but given time scales 60 may not be possible (I'm
personally fussy about framerate so I'll try for a steady 60fps)
HDR is bread and butter for us, something like 2 years old tech.
Originally 16 bit integer (back in the ATI 9800 days) now FP16 based.
X360 has a nice 32 bit float mode (FP10) but I expect that will be
quite hard to use for proper HDR (never got a chance to use it so can't
really comment), considering we have actually hit precision issues with
FP16 framebuffers (64 bit). FP16 seems to be the best comprimise for a
framebuffer at the moment (its enough for most lighting, though we run
out of precision directly in front of the sun (noticeable on our cloud
renderer))
We haven't yet made the jump to a multi-thread game architeture yet. Almost everything sits on a single thread...
Actually the face is the only rendered thing in the demo, its uses our
high-end model (used for the surface extraction) rendering in Maya and
composited onto the in-game background. We were orignally intending to
do it in-engine as well, but there just wasn't time to implement all
the tech for a closeup (we don't have facial animation system at this
moment).
The other closeup of her face (after the aerial fight when she is falling down) is in-game.
Graphics and framerate are the low hanging fruit. Just threading up the
animation system and procedural graphics (hair, cloth, flags etc.) will
gives us a large amount of CPU time back for the game. The army need
this the most.
Longer term, Physics and AI services are obvious candidates.
As for what improves?, thats a good question. The priority is to move
the heavy weight stuff off the main game thread, hopefully doing this
will provide lots more time for the game code. That should improve the
gameplay in lots of ways.
Wether we will acheive all this and keep the code easy to develop with
is the big question. Lots of designers and coders (especially the more
junior members of the team) aren't used to dealing with threads, DMA
and C like code. Keeping a balance between the high level and the
harder stuff is the biggest challenge. I don't want a level designer
having to worry about threads but at the same time don't want him/her
coding in such a way that its totally serialised...
Its in-engine but I'd be lieing to say its very playable at the moment
BUT we have lots of work to do in this area. There is something like
2000 people on screen there, we have shown 500 people @ 30fps on our
old PC demo (GDC2004 time). Were not currently as efficient as we were
back when we did the last demo, a new more advanced shadow system and a
few other changes make each bloke a bit more expensive. To be honest
though, we knew we were about the change to the target platform when we
made those changes so optimising for a PC engine was a bit pointless.
Given the power and architecture of the target platform, it seems
achievable.
Actually Wil (one of the coders) has done some research work on
achieving that kind of depth of field and motion blur in-engine since
we finished the E3 demo. Its still being worked on but it looked pretty
good last time I saw it. He's calculating per-pixel velocity vectors so
you actually get smearing and blurring along the movement axis...
Currently we are about 30 odd, with the majority being coders but with
the rapid ramp up to full production we will grow alot (more than
double) with the art team becoming a much larger group percentage wise.
