Jump to content

  • Log In with Google      Sign In   
  • Create Account


MJP

Member Since 29 Mar 2007
Offline Last Active Today, 01:58 AM

Posts I've Made

In Topic: Having trouble with energy conservation with IBL.

Today, 01:55 AM

Yeah, it definitely looks like you've got a bug somewhere. For comparison, here's some images from my ground-truth renderer, showing roughness values starting at 0.01 and ending with 1.0:

 

Attached File  StPeters_Small.png   299.17KB   0 downloads

 

Attached File  Uffizi_Small.png   364.26KB   0 downloads

 

FYI these are taken with an exposure of -2.5, which is a linear exposure of 0.176. It also has filmic tone mapping applied after exposure, followed by gamma correction.


In Topic: Distance to cone light / cone light culling

Yesterday, 12:22 AM

It is possible to test a cone for intersection with a plane, and the algorithm is described in the book Real Time Collision Detection. If you perform this test against the 6 planes of the view frustum, you can cull spotlight cones in the same way that you would typically cull a sphere. Just be aware that as the cone gets larger relative to the size of the frustum it becomes more likely to generate false positives (the same problem happens with spheres as well). As an alternative you can represent your spotlight with an oriented bounding box or a frustum, and test for intersection with a frustum using the separating axis test. SAT produces exact results, but is more complex than testing a sphere or cone against the frustum planes.

 

As for scaling down your shadow map resolution, you should consider that in the ideal case you'll want to scale your shadow resolution based on the projection of your occluders onto the receivers being lit by the spotlight. So if you're going to base it on a distance from the camera, then you'll probably want to pick a point inside the cone that represents the most likely place for a receiver to be. If everything is dynamic then you'll probably have to guess or estimate, unless you do some calculations at runtime. However if the light is static and there's static geometry involved, then you can possibly do a bit of offline analysis to make a better initial guess at which point to use.


In Topic: Compiling 64-bit Applications in Visual Studio Express 2013

30 August 2014 - 04:46 PM

VS 2012 and 2013 express includes the x86-x64 cross compiler, and not the full x64 compiler. Like SmkViper already explained, this essentially means that the compiler and linker are 32-bit executables, but ultimately they can produce a 64-bit executable. For the most part this isn't a big deal, unless you start working on a huge project that can cause the linker to exceed its 4GB virtual address space. I have no idea why they only include the cross-compiler and not the full x64 compiler, it doesn't seem to make much sense to me.


In Topic: MonoGame/HLSL Seperate Texture from sampler

29 August 2014 - 12:30 PM

You seem to be missing DX9-style (SM3.0) and DX11-style (SM4.0+) shader code here. I'm not really familiar with MonoGame...does that use DX11? XNA4 is definitely limited to DX9, so you will have to use the old DX9-style syntax for sampling textures (tex2D(), sampler, etc.).  You should consult the XNA samples for examples on how to set up the old-style shaders, and bind textures.

If are trying to use the same shaders for DX9 and DX11, let me warn you that it's rather difficult. You typically need to use a lot of macros to hide the different syntax.


In Topic: Why are their bumps in my shadow mapping?

28 August 2014 - 12:36 AM

Having a stair-step pattern is totally expected, since it's just aliasing due to rasterization. However in your picture the edges are rounded, which is strange. Are you using bilinear filtering when sampling the shadow map, or performing any other filtering/blurring on the shadow map before you sample it?


PARTNERS