Emergent Technologies Interview: Part Two

[Rys]

<a href="http://www.beyond3d.com/interviews/emergent-two/"><img border="1" src="http://www.beyond3d.com/interviews/emergent-two/focus.png" align="right" width="75" height="75"></a>Since <a href="http://www.beyond3d.com/interviews/emergent-one/">our look at Emergent's Gamebryo business</a> back in November, we've been hard at work following up on Gamebryo itself, the game development technology used to create the likes of The Elder Scrolls IV: Oblivion on Xbox 360 and PC.

In this Beyond3D interview, <a href="http://www.beyond3d.com/interviews/emergent-two/">we check out Gamebryo in depth</a>, discussing renderer, tool and implementation technical details with Emergent's Dan Amerson and Randy Spong. We also recommend you check out our <a href="http://www.beyond3d.com/articles/gamebryoprimer/">Gamebryo primer</a> if you're unfamiliar with it or game engine technology in general, to take a look at the platform from a high level before diving in with the technical interview.

[AlStrong]

Great read. I dig. :)

[Arun]

Great read. I dig.Hehe. Well it probably isn't going to pick up at Digg, but hopefully a few sites will report it anyhow! :)


Uttar

[AlStrong]

If only more people understood what was being said; I didn't understand half of it, but the other half was great (*cough* PR *cough*). :razz: naw, I just appreciate these tech interviews. :)

[Andrew Lauritzen]

Awesome interview! Great question... I'm really happy that they were so forthcoming about their technology and willing to give detailed responses.

For example, the blooming used the HDR scene as rendered to texture and isolated the highest intensity pixels.
Ah, the hacked bloom ;) I guess we'll keep seeing this until people start to use truly HDR resources though.

We've designed the system with a number of techniques in mind, including variance shadow maps [...]
Woo! :)

I didn't understand half of it, but the other half was great [...]
I think I got most of it... did you have a specific question(s)?

[Arun]

Woo!Hehe, there certainly are going to be more and more games using VSM or VSM-like techniques in the coming days/months, I'm sure. It'll be very interesting to see how good they can look in real-world environments, and espesically so when combined with cascaded shadow maps and similar algorithms. I wonder how developers are going to handle the remaining robustness problems though, hmm... :)


Uttar

[dbamerso]

I just wanted to let everyone know that I've joined the forums here. I'll be happy to continue the conversation as time permits if there are additional questions prompted by the interview.

Dan Amerson

[Andrew Lauritzen]

I wonder how developers are going to handle the remaining robustness problems though, hmm... :)
I'll be posting a new demo today or tomorrow... I think I post it here first to get feedback, then maybe as an IOTD on GameDev. It solves (or provides better approximations) for most of the outstanding issues with VSM, including light bleeding, the need for high-precision hardware filtering support and the cost of blurring the shadow map. It also allows for variable filter width (i.e. softness) per pixel without branching (PCF requires branching to handle this, and filtering properly in general).

I think people will be pleased, and hopefully it'll help Emergent and other developers provide a more robust and flexible implementation.

[Arun]

Hey Dan! Great to have you here :)
Here's just a quickie from me I'm still curious about - it's one of the rare answers I didn't manage to conclude much from. Dark maps - what's actually, really different from light maps? Is the idea to basically modulate *down* what the per-pixel lighting equation is giving you based, or...?

AndyTX: Very interesting - looking forward to that. I know someone who was investigating those problems too and told me he found a very good solution, but considering he had "just enough" with FP32 filtering, I suspect it's also quite different! Hmm.


Uttar

[Geo]

I think people will be pleased, and hopefully it'll help Emergent and other developers provide a more robust and flexible implementation.

I love techie dweebs. When they say something like the above, you're never quite sure if they mean:

1). It'll be a little bit nicer.
2). "Oh, you say you want a Revolution. . . "

:lol:

[Andrew Lauritzen]

Hey Dan! Great to have you here :)
AndyTX: Very interesting - looking forward to that. I know someone who was investigating those problems too and told me he found a very good solution, but considering he had "just enough" with FP32 filtering, I suspect it's also quite different! Hmm.
Mintmaster by any chance? We chatted briefly about VSMs after the initial paper and he seemed quite keen, and also had lots of good ideas. I've been anxiously awaiting results from him but I haven't heard anything back yet :( As far as I'm concerned, the more people using and improving the technique, the better! That's partially why the original paper was so short; we were expecting people to take the idea and run with it.

I love techie dweebs. When they say something like the above, you're never quite sure if they mean
I'll leave that to you to decide :) IMHO the VSM idea is the real "revolution" (revelation?) for which credit goes to William Donnelly. The rest of the work has just been figuring out cool stuff that we can do with it.

In any case, I want to thank Dan directly for being so forthcoming. Us "techie dweebs" and researchers love to hear the gory details :) It certainly gives me new ideas and insight, and good direction for future work.

[dbamerso]

Hey Dan! Great to have you here :)
Here's just a quickie from me I'm still curious about - it's one of the rare answers I didn't manage to conclude much from. Dark maps - what's actually, really different from light maps? Is the idea to basically modulate *down* what the per-pixel lighting equation is giving you based, or...?

Uttar

There's definitely some confusion of terminology with dark maps. I think our dark maps are equivalent to light maps, but it's probably best for me to just show a snippet of the lighting equation for our standard material and let you see mathematically what I mean. Here's a severly reduced equation for our standard material's pixel operations.

Color = DarkMap * BaseMap * DynamicLighting

We named the texture a dark map because it generally doesn't brighten the surface. It modulates the color down since you are usually multiplying by a number in the range [0,1]. That limitation of range was definitely the case when we introduced dark maps as a multitexturing option upwards of 6 years ago. With current hardware and texture formats, you could very easily have a dark map with a more expressive range than [0,1] that does brighten the surface when used with our standard material.

dba

[Andrew Lauritzen]

Color = DarkMap * BaseMap * DynamicLighting
That's interesting... seems kind of like an ambient occlusion term, except for dynamic lights. Is your "dark map" parameterized by direction at all (a la. HL2 ambient cube), or constant?

[dbamerso]

That's interesting... seems kind of like an ambient occlusion term, except for dynamic lights. Is your "dark map" parameterized by direction at all (a la. HL2 ambient cube), or constant?

Dark maps are constant. That is largely a legacy consideration. As I noted, we introduced them as an option for our clients before pixel shaders existed in consumer hardware which precluded the more advanced ambient occlusion maps in use today.

Moving forward, we hope to add more advanced ambient occlusion technologies to our engine and tools. It's certainly something we are discussing and investigating. However, I can't really say anything definite about future features or management might get testy. :wink:

dba

[iwod]

Lots of mentioning on Direct X, PC and Console.
What about Mac and Wii?

[Arun]

What about Mac and Wii?The Mac doesn't support DirectX, so that's a no-go for Gamebryo, but also most other engines out there obviously.
As for the Wii, its performance characteristics are similar to that of last-generation consoles, and there are a bunch of questions which relate directly or indirectly to that... :)

[dbamerso]

Lots of mentioning on Direct X, PC and Console.
What about Mac and Wii?

The Mac doesn't support DirectX, so that's a no-go for Gamebryo, but also most other engines out there obviously.
As for the Wii, its performance characteristics are similar to that of last-generation consoles, and there are a bunch of questions which relate directly or indirectly to that... :)

We do not currently have a Gamebryo product for sale on either of these platforms, Wii or Mac. While the underlying graphics API for those platforms does differ from DirectX, that is a difference that we can address with appropriate engineering resources.

Support of a platform is typically a business decision, and we continually evaluate all platforms. If there is a business opportunity for us in the future on Wii, Mac, or any other platform, we'll consider producing a version of Gamebryo for that platform.

dba