'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)

Prototype: Orientation-Adapative Grid

"Orientation adaptive Grid" is a concept I drew up earlier this week and I finally turned it into a working prototype yesterday. There really isn't a lot to talk about - It reacts to the orientation of the camera and shows/hides the three available grids. The video below demonstrates this in a few seconds...



(watch is high-quality to see the lines)

I'm not quite sure if I will be using this in the later stages of my editor - so far it goes look kinda cool and doesn't seem too distracting - it will require some more tuning (of the alpha values) and once the ViewCube (seen in the top-right corner) is complete I will revisit this concept as they play pretty well together.

Editor Tool: ViewCube (Camera Orientation helper)

Got to work on a new tool today and to users of 3D Studio Max or Maya it may look very familiar. It's called the ViewCube and it helps you orientate your camera in the scene. The video below demonstrates the basic system, Right now it's still only a prototype I made earlier this evening and I will finish it at a later time. The final tool will interpolate to the new position/orientation and the tool itself will be available in the top-right corner of the screen (and will have greatly improved visuals of course ;)).

Since I only have one viewport available in my editor, this can theoratically be a replacement for the standard dedicated Top/Side/Front-viewports. I might add an easy toggle for perspective-to-orthographic so you would not longer need/have 4 viewports on your screen at the same time...

Engine Restructuring

So I have actually had the time to work on the engine again and been experimenting with some design patterns. Since the deadline of our latest project (Project Sunburn) has passed a while ago I have been doing some experimental stuff, mostly to try and fix issues and concerns that were bugging me for a while. Since there are currently no new projects/games scheduled to use the engine I am basically free to experiment and try out new things.

A pretty major annoyance is 'one-frame-lag', it's fairly common and can easily happen when you don't own full control over the optimal update-order of your components. This type of lag most commonly occurs when object-A affects object-B, but B has already updated himself that frame. It will then take another frame for the full-effect to be applied. The same thing can happen when different objects query information from a object that itself gets affected several times during a frame, this ends up being messy and will have unexpected results and one-frame-lag.

However, I believe to have found a pretty solid solution, since it a bit experimental I will first test it against more complex components. More on that later...

The latest version of Core Engine was also lacking a proper Game-State management framework, which wasn't a problem for a long time since we generally didn't use 2D menus for our prototypes, but I am currently figuring out a good way to re-integrate this into the engine (from scratch) The 'standard' frameworks really don't work for me as they easily make your framework very complex and put a lot of extra strain on iteration speed, it should be a lot simpler and that's exactly what I'll be trying to accomplish.

A small note on the Gizmo for those of you who may be using it - I might release an update soon fixing some of the integration issues people might experience when they don't have a similar framework set-up. I will try to completely decouple the component which makes it a lot easier to integrate  into your own editor. (If you experienced any other issues, let me know and I will see if I can fix is along with the rest)

With all the other stuff going on I did not spend a single minute on V-script (Except for a presentation I did, I might talk about it some other time) So there is not much news on that I'm afraid.