Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

133 Neutral

About EricPolman

  • Rank
  1. Coincidentally that is what I tried initially, using the technique proposed here: http://www.slideshare.net/hgruen/oit-and-indirect-illumination-using-dx11-linked-lists Might have done something wrong there though, since I could update my scene (or add more propagation steps) and it would take at least two seconds for those changes to reflect on the scene. Still a very interesting technique though!
  2. Yay the VS/GS/PS approach fixed it! And it is not significantly slower or anything.    Direct lighting (and small ambient term): http://scrnsht.me/u/yPb/raw Combined: http://scrnsht.me/u/wPb/raw Indirect lighting only (and small ambient term): http://scrnsht.me/u/xPb/raw   Still quite some self-illumination and incorrect bleeding, but for now, I am quite happy and satisfied.
  3. @Hodgman: interlocked was one of the things I considered, but interlockedadd for floats does not exist. I have tried casting to ints, storing, and converting back, but int4 doesn't work for InterlockedAdd, so I would need 12 UAVs (4 per colour channel) to store it. Seems like a hack when other people don't have to do it :P    @agleed: The last solution seems like the go-to solution when I look at other people's code (and now I know why they didn't just use a compute shader)   I will try the VS/GS/PS solution and report back! :) thanks for the help guys!
  4. result.positionWS /= numSamples;     result.normalWS /= numSamples;     result.normalWS = normalize(result.normalWS);     result.flux /= numSamples;          float surfelWeight = 6;     float4 coeffs = dirToCosineLobe(result.normalWS) / PI * surfelWeight;     float4 r4 = coeffs * result.flux.r;     float4 g4 = coeffs * result.flux.g;     float4 b4 = coeffs * result.flux.b;     uint3 gridPos = getGridPos(result.positionWS);     lpvR[gridPos] = (lpvR[gridPos] + r4) / 2;     lpvG[gridPos] = (lpvG[gridPos] + g4) / 2;     lpvB[gridPos] = (lpvB[gridPos] + b4) / 2; The compute shader takes a sample from the RSM (result) and converts that to the coefficients which I need to store. Before this shader I clear the lpvR, lpvG, lpvB volume textures and in this step I add the VPLs from the RSM to the LPV volume textures. Simply assigning or trying to do a "running average" both result in flickering. This flickering is worse when simply assigning/stomping. 
  5. Thanks for the reply!   Nope, not culling anything at the moment. And no movement in lighting and geometry. In one implementation (http://blog.blackhc.net/2010/07/light-propagation-volumes/ not mine) they use a VS/GS/PS combination and that seems stable. Do pixel shader blend operations guarantee thread safety?
  6. Hello, I am running into a situation that I haven't seen anyone else experience in implementing Light Propagation Volumes. I have an RSM of let's say 512x512. That's 262144 VPLs. If I would downsample this to 128x128, there's still 16384 left.   When trying to inject this in my volume texture (using Compute Shaders and UAVs) I, logically, get flickering lights due to race conditions. How can I avoid this problem?   I have seen approaches using Vertex Shader/Geom Shader/Pixel Shader combinations, but I don't understand how that would prevent it.     
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!