• Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

101 Neutral

About subsym

  • Rank
  1. Hi, this is my first question on this board, so please bear with me if it's not in the right place [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img] It's about efficient iOS OpenGL ES programming. I have a quick question about rendering mirror effects. I know about the standard way (render scene and stencil for reflectors, render again with inverted transform), e.g. also discussed in this older thread [url="http://www.gamedev.net/topic/377187-mirror-reflection-effect/"]http://www.gamedev.net/topic/377187-mirror-reflection-effect/[/url] I was just wondering whether this is still state-of-the-art for planar reflectors, and whether people consider this a good fit for the specifics of the iPad GPU? You can obviously accelerate this by tighter frustum culling, but are there any other tricks you are aware of?
  2. [quote name='DementedCarrot' timestamp='1335247904' post='4934340'] If it was properly optimized couldn't it be faster? I just hate the idea of rasterizing an entire scene for every patch. I was hoping some kind of clever face->face visibility determination could eliminate huge numbers of patches that needed to be checked against others, and to set it up in such a way that you could pretty much just throw a list of patches that needed to be radiated at a compute shader. [/quote] The original radiosity algorithm just worked that way, looking at all pairs. There are many papers on how to accelerate it. One advantage you get from the hemicube is that you immediately get the correct form factor (without the costheta), whereas in patch-to-patch interaction you need some analytical expression for it. There are a number of them, some based on contour integrals, and some based on simpler approximations (disks etc). Otoh you get aliasing artifacts when doing hemicube, so there's a tradeoff.
  • Advertisement