Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 19 Jun 2007
Offline Last Active Dec 29 2015 05:41 AM

Posts I've Made

In Topic: Variance Shadow Mapping With Expensive Terrain

22 October 2015 - 06:04 AM

Instead of using a shadowmap for shadows, you could bake the visibility between the terrain and the main light in an occlusion map. For each texel, cast a ray between the corresponding terrain sample towards the light, and store 0 or 1 depending on whether the ray hits the terrain or not. The intersection code can be optimized in several ways, for instance by precaching the terrain geometry instead of evaluating the fractal function on the fly.

An occlusion map has many advantages: it filters correctly, takes little memory (an 8 bit format is enough), gives you soft shadows for free and it's view independent. Of course you can tweak its resolution depending on your memory and runtime budget.

That's the approach I used more than 10 years ago for shadowing my terrains (on the CPU) and it worked very well. You should be able to prototype it on the GPU rather quickly.

Just an idea!

In Topic: directional light and dx11 shader

21 July 2015 - 04:26 AM

I'm going to upvote you because of your avatar happy.png Bud is a legend!

In Topic: Boat wakes on projected grid water

26 June 2015 - 10:59 AM

The projected grid method only relates to water rendering, not the physical simulation of waves. For that you'll need other techniques, like iWave, wave particles, procedural effects, artist-authored textures etc.
Most of these techniques use textures to store the wave state. They often operate in a coordinate space that lies parallel to the water surface. The coordinate space of the projected grid is, by definition, screen space (approximately). Therefore, you'll need a mechanism to move data from one coordinate space to the other, taking into account aliasing of course.
At this purpose, in my engine I use two render targets. The first has the size of the projected grid and stores the total displacement at each vertex of the grid. First, the 3D displacement of ambient (FFT) waves is written in this target. Then, other wave types are added to it (remember that water waves combine linearly). In my case all wave types are represented by textures. For antialiasing, I rely on the mipmapping capability of the GPU in conjunction with tex2Dgrad, to which I pass the analytical derivatives at each vertex.
The second render target has the size of the backbuffer and stores the horizontal components of the water normal. As above, it is initialized first with ambient waves. Then, other waves types are blended on it, again relying on mipmapping and, this time, hardware derivatives at each pixel.
You can blend procedural effects such as circular or Gerstner waves (trochoids) directly on these two render targets, without baking them into textures (which would be lossy in addition to unnecessary). Again, anti-alias these effects based on the frequency of the effects and the derivatives at the pipeline stage where they are drawn.

In Topic: Texture atlas generator

06 March 2015 - 06:12 AM

I am well aware of the technical limitations of texture atlases vs arrays vs slots. In the case of texture atlases, naturally I would manually unwrap the texture coordinates in the pixel shader and use tex2Dgrad (or equivalent function) for fetching the data. This approach has been used for more than a decade by tons of engines; I am simply looking for an existing bleeding-aware tool to pack textures.

Simple slots are not a solution in my case, as I want to support 64 textures and I want to dynamically fetch different textures per-pixel based on a material mask.

In Topic: Texture atlas generator

06 March 2015 - 05:00 AM

I should have been more specific. I am still targeting DirectX 9, so I cannot use texture arrays.
The tools recommended above are simple texture packers and ignore the issue of colour bleeding for wrapping, mip-mapped textures.
It is probably wise to write my own tool for texture processing, considering that I will need additional engine-specific features in the future.