A new (Deferred) Renderer [Part 1]

For a long time I have used SunBurn as my primary rendering solution. This helped a great deal while developing Needle Juice, Over Night and more recently: Project Sunburn. With no new game projects lined up with Core Engine, I have decided to experiment with my own rendering solution, based on Catalin’s Deferred Rendering sample along with information from many other sources including a Killzone 2 presentation from 2007.

The above images shows the most recent unit-test of filling the hardware DepthBuffer with the Gbuffer-depth to draw post-deferred geometry (i.e. using forward rendering for transparent surfaces) and other visuals such as vertex-lines. This is done during the final combining pass of the geometry data and lighting using the ‘DEPTH’ semantic. This fills the depth-buffer as all depth is lost after switching RenderTargets (something that can be prevented on the PC using PreserverContents, but does not work on the Xbox - this solves the problem entirely)

Some other experiments include texture projection as seen below.

Texture projection has several great uses, including Deferred Decals, light shapes and video projection on the scene's geometry (as seen in Splinter Cell: Conviction) Back while developing Over Night we used shadow-mapping in places where texture projection could have been much cheaper. A good example of this is the blue light coming from outside through the shaded window, covering most of the room as seen below. The second image uses a texture to simulate a similar effect, without having to re-draw the entire shadowmap every frame, instead simply sampling from the texture and projecting it into screen-space.

Looking back at Needle Juice, where we used a directional light with shadows to draw light coming through the windows, another place where texture projection would have been a cheaper and more elegant solution to our problem (also preventing light-leaking, which is very common with directional lighting)

Needle Juice: directional-light coming through the window, required shadow-mapping.

I will continue working on the renderer for the time to come, with such a wealth of presentations, papers and samples on deferred rendering (and graphics programming in general) it will keep me busy for a while…Until next time! :)

'Depth Dependent Halos' for Wireframe rendering [Part 3]

It took a while to upload (on 56k wireless connection) but the video is finally available on YouTube. If you haven't seen the previous posts about this topic, the effect is based on UDK's implementation of 'Depth Dependent Halos' to increase readability of wireframes in complex scenes.



After I managed to get the desired effect I could simplify it significantly. Moving from two render-passes to one and from 18 texture look-ups to 'just' 9. This was possible by removing the normal 'diffuse' pass which is nothing more than the regular colored wireframe you can see in the video (when the halos are toggled-off), and instead using the information available inside the depth-buffer to construct the wireframe. This is pretty easy if you take into account that if (depth == 1) there is no geometry, where if (depth < 1) there is in fact a line that was drawn when constructing the depth-buffer. From this you create a colored wireframe and the halo inside the post-processor. The same data can be used to determine intersecting lines...removing the need for 9 texture lookups that sampled data from the original wireframe in the first prototype and instead re-using the sampled depth.

The result can be seen above...

'Depth Dependent Halos' for Wireframe rendering [Part 2]

I have been working on getting the depth buffer to generate properly and using it to post-process the wires (i.e. creating the outline around the wireframe) and so far I'm quite satisfied...it's still a work in progress, but progress is going well...

This is the result so far, with the depth buffer drawn in the top-left corner and the final image in the middle. 

A zoomed-in version of the first image, the effect is visible around the characters head where you see a clear outline being formed, disconnecting it from the other character underneath it. 

For comparison I used a color similar to UDK (see first image of previous post)

4 more texture-lookups will be added which adds improved support for diagonal lines - that would bring the total lookups to 14...which is quite a lot for a single effect, but since the geometry will never been drawn with fancy shaders while in this 'mode' (nor any other post-process effect) I don't expect it to be a problem. This effect provides the most benefit when moving around with the camera, I hope to upload a short video of this after I finalized the effect.

'Depth Dependent Halos' for Wireframe rendering

'Depth Dependent Halos' is something I read on the UDK site a while ago, it's for their 'new' (by now pretty old...) wireframe rendering that increases readability of the lines for complex scenes. I was kind of wondering how they accomplished this and wanted to try this out myself (I was working on a wireframe-mode anyway, so it was the right time to experiment)

This is the effect I am trying to replicate. Black halos are drawn around the wireframe lines to provide a better understanding of depth differences between these lines.

I went through a few different approaches and ended up with a small post-processing shader that applies the halo around the wireframe lines. It took a few iterations to get the desired results, but I did end up with something that is pretty close to what I am looking for...

The first step was to create my regular wireframe and letting the post-processor create a small single pixel halo around these lines using a different color. The second step (still have to start on this one) will require a depth-buffer and use the depth information to determine if the outline/halo should be drawn with halos being drawn on top of lines underneath them, creating discontinuities between lines that intersect and are underneath others.

Some of the iterations I went through:

Trying to find out the correct pixel offset and coloring by finding edges and applying a different color to each direction (up/down/left/right in screen-space)

This is the current state of the code, and resembles the desired effect (of step 1) quite closely.

I have also been working on some additional scene navigation features. These are best shown in a video, but since I currently get my connection through a painfully slow USB stick - that will have to wait...

bonus image...(this result was less then expected, but looks pretty cool)

Due Update

It's been a while since my last update. After a tiring 26 and a half hours of continuous work to make the deadline, I needed some time off from XNA. I got started again earlier this week though and I have a few teaser screenshots to show you guys.

The placeholder shells colliding with the environment.

The new shell models. (By Bo our 3D Artist)

Transparency/cube-map test for scope on Assault Rifle. (using Arbitrary model)

Dummies, a much easier way to align muzzle flashes and shell positions with the weapons.

The new (WIP) Gizmo. The current release on Codeplex is pretty outdated feature-wise. An updated release should be up soon (no ETA available yet)

Other upcoming tasks include, motion-blur on the shells, depth of field on the weapons and a proper muzzle flash among other cool stuff...

Post-Process: Motion-Blur Effect

A simple Motion-Blur post-process based on the GPU Gems 3 article.

Engine Update: Shaders & Editor Additions

It has been a while since my last update. The image below shows some of the things I've worked on these past few days...

So what's new? First off, the shaders might have caught your attention, the lava is flowing and the arrows are flashing which you can't see in the still image unfortunately, I'll make sure to include them in the next video. They were really just experiments to get some practice with shaders and was hoping to use it for a material editor I was working on (had to put it on hold for now) Still, I think they look pretty cool (especially when you see them in motion)

The next thing you can see on the image is the ContextMenu (pop-up menu that appears when you right-click) Its part of the Editor and is rendered inside of the XNA Game window. XNA is still running as it is used to, winforms is added to the XNA window not the other way around.

As you can see there are several useful options inside this pop-up window. You can quickly add new Entities, add selected entities to your current script and continue playing or restart the level using the changes you made in edit-mode.

Hopefully I'm able create another video soon, showcasing some other additions that were added over the past couple of weeks. In the meanwhile I'm working on a game prototype, this directly aids in build the engine as well...

Post-Processing Volumes

This time I'll keep the words to a minimum and let the images speak for themselves...(more info below)

Base Image

Increased black-point

Cold tint

Warm tint

If you've ever tried Post-Process Volumes inside of UDK/UE3 then you'll be familiar with the concept. I've tried to replicate a lot of its features. You can affect highlights, midtones and shadows (as seen in the images above) as well as bloomscale, blur, noise etc. They all react to the position of the player (inside or outside of the volume) and will transistion between the values when you enter/leave the associated volume. I'll upload a video of that later on...On a sidenote, I've made a lot of progress with the animation editor, more info on that will be available later on just like the video :)