Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 27 Jan 2014
Offline Last Active Jul 26 2014 01:56 AM

Posts I've Made

In Topic: Getting around non-connected vertex gaps in hardware tessellation displacemen...

27 June 2014 - 03:34 AM

Thanks MJP.

I don't suppose there's any video / audio recording of the presentation using those slides available somewhere, possibly for a nominal fee?


On a more off-topic note, I recognize that avatar of yours but have been unable to remember the name of the show (or was it possibly a book?) it featured in, care to enlighten me? 

In Topic: about "AlphaToCoverage"

26 June 2014 - 11:07 AM

Off the top of my head, that tends to happen when your leaves (or whatever else you have that uses a transparent texture) are rendered out of order, meaning that the edges of the leaves will blend with the background colour of the wrong object (for example your skybox instead of what is immediately behind them).

To solve this you'll have to either ensure all your transparent objects are drawn back-to-front and that your non-transparent objects are drawn in a previous pass, separate from the transparent ones (or you can sort them all but that generally wastes some more time). Another approach is to skip alpha blending and instead just clip pixels whose alpha value is below some threshold from your pixel shader. That looks blockier up close, but since you have no alpha blending and just overwrite pixels with the ones closer to the camera, you don't need to sort all your foliage, which can be a lot of overhead if you have plenty of it.

In Topic: DX11 on a DX10-class GPU -- How far can you go?

26 June 2014 - 10:50 AM

DX11 is just a superset of DX10 so yes, there should be no problems :)

If you choose to switch to DX11 further on all you need to do is switch a single flag; all your old "DX10 feature level" code will run without any need to change it.

In Topic: Per-instance data in (non-vertex) shaders

24 June 2014 - 11:54 AM

Ah, that's clever, didn't know there were separate buffer resources in addition to having to rebuild and sample a texture.


In Topic: Standard approach to shadow mapping multiple light sources?

15 June 2014 - 09:23 AM

Use a cube map

Admittedly I'm not all too familiar with cube maps but won't they essentially render as 6 separate maps anyway?



@MJP: Thanks for the insight.

My planned game probably won't "require" that many lights, I'm basically just planning ahead and trying to come up with the most flexible solution to start with so as to not have to rewrite too large portions should it turn out I need an extra light or four somewhere along the way. Frustum culling the lights makes sense and I've heard of faking point light shadows by actually generating shadows for an imaginary spot light pointing at the most lit area of said point light (such as straight down on the ground).

As for pre-generating static lighting on static meshes, won't that by definition fail and you'll have to regenerate the whole thing the minute any dynamic objects enter the shadowed zone however? I suppose it would still work for distant / unreachable areas though (although I'm planning a mostly outdoors game that would require dynamic directional sun / moon lighting anyway so I guess this isn't too applicable at my particular situation unfortunately. Good to know for later endeavours though.).

Also thanks for the links, will read through them during the upcoming rainy vacation days! That dual paraboloid shadow mapping seems like it could be quite useable at a first glance smile.png


Edit: forgot to mention it but I was under the impression that you could at most have up to 16 textures bound to the graphics pipeline for any single draw call. It would however seem I was dead wrong as MSDN suggests the number to be 128 for shader model 4 (however no such number is given for SM5). That at least gives some more headroom to work with, even though it will of course be limited by other factors instead in the end then.