Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 05 Nov 2005
Offline Last Active Yesterday, 11:45 AM

Topics I've Started

Query Timestamp inconsistency

07 February 2016 - 04:00 PM

Hey guys.


I've implemented some postprocess effect. Measured its performance with DX query using double buffering and I got 2ms.


Next, I thought about making my scene more complex so I loaded a bit more meshes and whole lot of textures (previously 1 draw call, now 400) and measured postprocess time. Should be the same, right? It's independent of the geometry rendering phase. But to my surprise the DX queries gave me 3.2ms.


I thought that maybe the problem was that I use too few queries; that reading queries from n-1 frame in n-th frame was not good enough. So I switched to quadruple buffering. And now I get 1.42ms timing.


Is there a way to get consistent timings from DX queries? I remember that when I was working on similar things at work where I had access to PS4 I only profiled there because PS4 *always* gave me consistent measurements. But now I'm stuck with DX11 and PC and want to get correct timings.



Also, depending on whether I run my app in Debug or Release mode, I get different timings. 2x worse in Debug. I'm not sure if they should differ that much since I measure GPU time.

DoF - near field bleeding

02 February 2016 - 12:23 PM

I decided to implement bokeh depth of field algorithm from here http://www.crytek.com/download/Sousa_Graphics_Gems_CryENGINE3.pdf

Actually, I did the far field part and it works really nice and fast. What I have big problems with though is doing the near field bleeding part (slide 43). To be honest, just reading these slides I don't see how the author could achieve this effect withour any sort of blurring of near field CoC. Or maybe he did that but didn't mention about it.

Have a look here (yeah, I know; I'm an art master):

Attached File  img.jpg   19.31KB   0 downloads

Say to the left we have out of focus region that is close to the camera and should bleed onto the background. Now, in slide 44 the author says that near field CoC should be used for blending. However, when processing pixels belonging to the background using this value will fill the entire background with the unblurred version of the color buffer, and any bleeding created in the DOF pass won't show up.

Any ideas on how to properly bleed the near field colors are very welcome.

Deriving L_o for directional light

15 December 2015 - 10:16 AM

I've been reading some ray-tracing book and stumbled upon something that really intrugued me. The author derives the simple dot(N, L) equation for an ideal directional light (assume white light (1,1,1)).

But let's start from the top. The direct illumination formula is this:



The final formula for L_o is:


(where l is light'd direction)


The author states that in order for the equation to end up like this, L_i must be:



I was curious enough to verify it and indeed:

A is cos(theta_l), B is phi_l. Note that I skipped BRDF f function.


Now my simple question is: why is L_i the way it is? How was it derived?

Deferred Lighting on Android

23 September 2015 - 10:08 AM


[ray-tracer] Banding problems

14 September 2015 - 01:51 PM

Have a look at the picture I attached.

Clearly, I can see there are bands of color on the sphere instead of smooth gradual variation. This problem gets more apparent as I move away from the sphere. I checked which component of my lighting equation causes the problem and it's the computed intersection point between a ray and the sphere. I've lookat at various ray-tracing tutorials but nobody mentions this. Have you ever expierenced this problem? How would you handle it? I'm really kind of surprised that I get almost "regular" rectangulars on the sphere (in screen-space).