Interview with Epic's Tim Sweeney

OOOGA OOOOGA WAJOOOOGA...

Ahem sorry my primal being came out there for a second...

Edge smoothing in UT3 with DX10 hardware. I don't have enough paper towels to clean up my drool.

Ouch, being more fillrate limited sounds like it's going to hurt R600.

No 64-bit native version. /sigh.

Thanks for the heads up.

Regards,
SB

 

Isn't edge-smoothing that same effect they used in GRAW (Deferred aswell) to make up for the lack of AA support? Or is this a case of 'same dog, different leg action'?

I wonder if MSAA would be possible under XP (DX9) with the Alky libraries?

 

Actually, DX10 SHOULD allow doing proper MSAA in a deffered environment. And I don`t think Sweeney would`ve harped about the advantages of DX10 over DX9 in this regard if they were doing some crappy per-edge blur-filter like GRAW, and Stalker do. So yes, this is very very very drool-worthy.

 

Yeah, when I read it, I assumed it was multisampling as well. But then I thought about it. How the heck do you multisample deferred shading? I used to think how are there games out there that can't be multisampled, but now I have no idea how this can.

 

If I show you how, will you give me a cookie?Just kidding, read this:http://static.tigerdirect.com/pdf/NVIDIA_Microsoft_DirectX-10_Technical_Brief.pdf, page 20, second paragraph, and this http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=961428&SiteID=1, specially the posts by Alexey Barkovoy.

 

Still haven't fully got my head around deferred shading. My understanding is that you're basically doing a geometry pass and storing all geometry attributes and lighting parameters specific to each object into a buffer. Then for each light in the scene you add that light's contribution into an accumulation buffer.

What I don't understand is why this accumulation buffer can't be the regular hardware supported MSAA buffer? Also, does DX10's support for accessing MSAA samples in an MRT mean that MSAA is hardware accelerated or is the final resolve still done in a shader?

 

I think it's to do with the stage that MSAA can happen in a DX9 rendering pipeline. So, MSAA happens near the end, and needs certain information that is lost in an earlier step if deferred rendering is used. I think the lost info is the geometry. I get the impression that with deferred rendering you end up with a screen full of pixels rather than a screen full of objects quite early in the process.

Looking forward to being told how way off base I am.

 

You are completely correct .
With Deferred Shading the accumulation buffer samples from textures (the "G-Buffers) representing the geometric properties of the scene (depth, normal, material, etc.). At this stage the actual polygons representing the scene are no longer available thus an MSAA'ed accumulation buffer wouldn't antialias anything since there are no polygons to antialias.
Multisampling with Deferred Shading is done by creating each G-Buffer as multisampled, and using DX10's shader-assisted resolves at the accumulation buffer stage to effectively apply shading to each sample and then resolving the results together. Ideally this should only be done for blocks of pixels containing different samples in order to save on performance (i.e. avoiding to apply supersampling on all pixels), however the process of determining if a pixel belongs to a *multisampled* edge can be quite involved.

 

Got it, thanks guys.

This stage of it was confusing me as well. In traditional AA the shader only sees a single fragment and the ROPs do all the sample generation, depth testing and blending magic. But if this G-Buffer now has multiple samples for the same final on-screen pixel how does the lighting pass decide which sub-samples to shade and which ones are "copied" from other colored subsamples in the same triangle? Or is it the case that all subsamples are lit independently if at least two triangles contribute to the pixel color?

Also, just to confirm. Is the depth-test for generating subsamples now front-loaded in the geometry pass? The sample data in the MSAA'd G-buffer would correspond to the final colored samples in the accumulation buffer so the lighting shader won't have to worry about the possiblity of triangles overlapping - right?

I think I need pictures

 

800x600 low detail....

 

and 20fps

 

Dunno of anyone showing an actual implementation in DX10 yet, so probably no pics are available. What SuperCow said sums it up nicely.

 

The latter. If more than one triangle contributes to a pixel then you will have to apply lighting to each individual subsample, then average the results together (and store it in the accumulation buffer). The trick is determining how many different subsamples exist for each given sample.

I'm not too sure what you're asking here. Once you have finished your geometry pass your MSAA'd G-Buffer will be a correct representation of the geometric data for your multisampled scene. The lighting shader certainly won't have to "worry" about overlapping triangles as long as it correctly access each multisample in the G-Buffer and apply lighting to them individually.

 

If I may ask something here:does anyone know where I can get the oldish PS3.0 PowerVR demos?The Cloth and whatever ones that were released some time ago and discussed extensively here. I can`t seem to find them on their site....they also had a Deferred rendering one.

 

Those three demos were published in the ShaderX2 book.

 

Thanks, now I only have to find where to get the book from

 

Thanks a lot, you answered both questions.

 

Here is "Cloth"
http://www.mitrax.de/data/files/dls/D3DCloth.zip

Dont know where to get "Voxel" or "Deferred Shading" sorry.

 

Cheers mate, thanks a lot...and sorry for mildly derailing the thread, but it`s a tad bit connected...a tad. And since I started already and everyone seems to be in a helpful mood:does anybody know why nVidia decided to anal retentive about their Cascades demo and limit its usage to G8x cards with a certain driver version?Anybody know of any circumvention attemps? I`ve toyed with 3DAnalyze, but I`m a VendorId and DeviceID short of all that I need for it, and there still would be the driver issue, but maybe I could engineer the inf for that.