Jump to content

  • Log In with Google      Sign In   
  • Create Account

ingramb

Member Since 16 Apr 2009
Offline Last Active Today, 11:12 AM

#5285069 When would you want to use Forward+ or Differed Rendering?

Posted by ingramb on 04 April 2016 - 01:14 PM

Most forward+ implementations will still require a z-prepass to prevent overdraw at the very least.  You can use this to compute SSAO (or whatever), and then read it in the forward lighting pass.

 

Depending on what you need, it's possible to write out a slim gbuffer (maybe include vertex normals) during the z prepass to allow more types of screen space effects.




#5282804 EVSM, 2 component vs 4 component

Posted by ingramb on 22 March 2016 - 11:43 PM

That's very helpful, thank you.

 

What kind of values did you end up needing for leak reduction?  Is that a value that you think makes sense to expose to artists per light, or did you get away with a hard-coded global value?




#5281725 Recommended reading for intermediate-advanced shader techniques

Posted by ingramb on 17 March 2016 - 01:20 PM

Good general overview of many rendering techniques:

http://www.amazon.com/Real-Time-Rendering-Third-Edition-Akenine-Moller/dp/1568814240

 

Lots of good presentations about more advanced techniques:

http://advances.realtimerendering.com/

 

Free online books with some interesting techniques:

http://http.developer.nvidia.com/GPUGems/gpugems_pref02.html

http://http.developer.nvidia.com/GPUGems2/gpugems2_frontmatter.html

https://developer.nvidia.com/gpugems/GPUGems3/gpugems3_pref01.html

 

Similar to above, but more recent and not free:

http://www.amazon.com/GPU-Pro-Advanced-Rendering-Techniques/dp/1568814720

(I think there are 5 or 6 GPU Pro books now, with more on the way)




#5281592 EVSM, 2 component vs 4 component

Posted by ingramb on 16 March 2016 - 11:41 PM

I'm looking for an explanation and/or example of why using 4 components vs 2 components is important for EVSM.  In my limited tests, using 2 component 32 bit gives much nicer results overall vs 4 component 16bit.  Dropping from 4 to 2 components does result in a bit more light-leaking, but it doesn't seem bad in the test scenes I'm looking at.  It's still hugely improved vs straight VSM.  Going down to 16bit however (even 4 components) causes pretty noticeable aliasing, and the required bias seems to result in peter-panning as well.

 

I remember specifically reading a presentation from Ready at Dawn, where they had to fall back to using 16bit for memory reasons on The Order.  Is there a good reason they chose this trade-off, vs dropping down to 2 components?




#4893741 D3DXUVAtlasPack wasted space

Posted by ingramb on 14 December 2011 - 12:37 AM

Upon further investigation, it seems that D3DXUVAtlasPack more or less ignores the requested atlas size, and generates the same uv space packing regardless. So what I've done is this:


1) Call D3DXUVAtlasPack with "default" square size
2) Scan the generated UVs, compute min/max
3) Scale and bias the generated UVs using the min/max, so they all map from 0-1
4) Adjust my atlas texture size, using an aspect ratio derived from the width/height of the UV space bounding rectangle
5) I can then pass this texture size and updated UVs to the texture gutter helper to actually generate my re-sampled texture


This seems to work pretty well, although I don't have a whole lot of control over the final aspect ratio. It seems that D3DXUVAtlasPack will generally create square atlases, unless there is a long thin rectangular chart somewhere. So my problem is mostly solved, although I would love to know if anyone else has any insight or information regarding UVAtlas.


PARTNERS