Finally got around to posting these guys up :) Enjoy!



  1. Sam Martin says:

    Great! Thanks Steve.

  2. Jay says:

    Unfortunately GPU pro is not available yet. Amazon says we can pre-order though.

  3. Ste says:

    Hi Jay,

    Yeah, you’re quite right. I think it slipped a little bit. I think amazon are doing some reasonable pre-order deals, might be worth a look :)


  4. Mark Wayland says:

    Nice document, thanks for sharing!
    A question if I may?
    Exactly how did you end up handling per-pixel specular, as its evidently not written into the deferred buffer?

  5. Ste says:

    Hi Mark, thanks for your kind words. To answer you questions, we actually don’t have per-pixel specular for Blur, but if we were to have it there are a couple of avenues you could go with it, the most obvious solution would be to write specular power, etc. into a 2nd main memory render target using MRT, this could also allow us to improve the quality of the normals somewhat too. It’s more data to bring into the SPU program, but shouldn’t really add more cost as we’re not limited by data-access in our particular scenario and specular calculations would more than hide that latency even if we were.

  6. Mark Wayland says:

    Thanks, that’s pretty much what I figured. Sorry for all the questions, but I was wondering what you ended up doing for specular in Blur then? Did you do some RSX based specular, or just had it on the cars for a fwd render pass (or were all specularly lit objects fwd rendered)? Thanks again!

  7. Ste says:

    Hi Mark, happy to answer questions where I can, so no worries there :). Once again you seem to be on the money. The cars were rendered with forward shading due to their vertex heavy nature, we did some tricks with SH to make the dynamic lights affect them in a very low-frequency manner, still looked pretty good though :). Since they were forward rendered we can basically shade them how we like, so they have specular et al. We also did some nice tricks with the SPUs to generate cube maps to help save on some of the RSX cost.

  8. ForcefulFool says:

    Hey Ste, Can you explain more about how you determine what
    g_vScale is on slide 12 please?

  9. Ste says:

    Hi there,

    Firstly, I’m very sorry for the delay getting back to you. I didn’t have much access to a machine over Christmas. I had a word with Mr. McAuley to confirm what the g_vScale represents and the math is essentially the following:

    scale * (float2(2.0f, -2.0f) * vUV + float2(-1.0f, 1.0f))

    Where scale is 11 and 22 values in your inverse projection. I hope this helps.


Post Comment

Please notice: Comments are moderated by an Admin.

Theme © 2005 - 2009 FrederikM.de
BlueMod is a modification of the blueblog_DE Theme by Oliver Wunder