Update (4-29-2012)

Hey guys, sorry for the long silence. I've been working with my friend's group RUST ltd. on their brand new indie game project. Unfortunately, I can't show you anything right now, but we will be officially unveiling it very soon. On that note, I can tell you without any hesitation that it is probably the best looking thing you will find on the Unity3D platform. ;)

Other than that, I have been spending time on Kickstarter trying to help fund the Leisure Suit Larry remakes. We're currently shooting for $650K before the deadline on Wednesday so that they will add a bunch of new content. Any of my readers who wish to chip in, please do so now. :p

Take care. *waves*

Physical Glass/Gem Prototype

UPDATE:

I figured I should be nice and at least give you guys some details. This technique is SM3.0 compatible, and doesn't use alpha blending. :)

Original:

I just wanted to show off a test shot from my new physically-based material system that takes full advantage of Unity 3.5's features (ie. Linear HDR pipeline, Directional Lightmaps, Light Probes). 

The particular focus of this shot is my experimental physically-based glass/gem shader. In this scene, you can see two dynamic lights on all the objects, plus baked lighting to fill out the rest of the scene. Please forgive the programmer art, as this is still early and experimental. 

Hope you enjoy it! ;)

PS. I will give a proper breakdown of the technique in the future, after my team's game project has released.

Update (2-13-2012)

Hey everyone! *waves*

Sorry for the nearly 6 month drought of new content. Things have been kinda hectic on my end, with a slew of things going wrong all at once. Fortunately, I've managed to get most of them solved, and no longer have that as an impediment. More importantly, I now have a new game project in the works!

With the recent release of the Unity 3.5 beta, I now have several critical features I need in order to move forward with my experiments (Linear HDR lighting, RNMs, Light Probes, etc). Now I am in the process of integrating my Physically Based material and Radially Symmetric Reflection Maps (RSRM) systems into Unity 3.5. The initial results have been very promising, so I will follow up with the breakdown of my work and plenty of media very soon.

Keep your eyes peeled and your ears to the ground! ;)

Dice Poker Game (CANCELLED)

Unity3D Web Demo

Art and game behavior courtesy of Anton Hand.

Instructions:

Click ring to drop dice in box.

Click chips around box to chuck chips in center.

Click button in upper left to reset ring.

UPDATE:

This demo will only work for SM3.0 level GPUs. If you attempt to use it on an earlier generation GPU, you will just see black on all the geometry that is using the RSRM shader.

Situation:

If you were wondering why I haven't posted much lately then please allow me to fill you in on the details. Recently, I tried getting my Physically-Based Rendering (PBR) tech into Unity3D, with surprising success. Having gotten this working in a prototype, my artist friend set out to build a game using this new tech. Sadly, the project encountered some complications, and ultimately had to be cancelled.

Despite this, the prototype is in a state where the basic functionality is working. So I have decided to re-purpose it as a tech demo, which you can access via the above link. Please check it out and leave some feedback about the visuals in the comments section. ;)

Results:

The prototype shader used for this demo was single-pass forward rendered using two fake directional lights and a Radially Symmetric Reflection Map (RSRM). The scene itself also has SSAO, Bloom, and FXAA just to top it off.

The results are slightly incorrect due to my misunderstanding of the need to plug the BRDFs into the Punctual Light Equation and cancel some terms out. As a result, the specular ended up too bright, and fresnel for RSRM gives too much rim for rough surfaces. So while it is significantly better than the current standard of Phong & Blinn Phong lighting models, it still falls short of what I wanted to achieve.

Currently, I am working on an improved version that will correctly integrate with Unity3D's forward multipass lighting system. It will correctly accumulate the lighting in an FP16 target in linear space, then receive tonemapping before being passed to the rest of the pipeline. I will also being improving upon the built-in Bloom, SSAO, and Depth of Field effects to really sell the effect.

Keep your eyes peeled for future updates! ;)

Other Updates:

Other than this, I am currently working on a revised RSRM article, to centralize all I have learned in an easy to reference article. It will also detail the PBR BRDF I have chosen for my project, including strengths and weaknesses. Finally, this will provide a good opportunity for me to clear up some incomplete and flat out wrong information from my old articles.

Other than that, I've also made a small update to my Partial Derivative Normal Map (PDN) article. Basically, I found an optimization to use a MADD to save an assignment, shaving off another instruction from the recovery equations.

Hope you will find them useful. :)

RSRM Enhancements

Let me preface this post by saying that I touched on some of these topics before. I decided to revisit them because I have learned a great deal since then, and felt I should make a little update on my progress. In particular, I wanted to correct some things that I got wrong in my prior post on the topic.

Fixes:

For the longest time, I was having trouble reconciling some of my results with those achieved in published Image-Based Lighting (IBL) papers. As it turns out, there were some problems in both my rendering code, and the console app that I wrote to convert an input gradient image into an Radially Symmetric Reflection Map (RSRM). The net result of my mistakes was that my RSRMs' lower specular powers were getting progressively darker when they shouldn't have been.

During this time, I had the incorrect notion that I needed specular power zero to represent my diffuse IBL. Naturally, this was incompatible with the non-linear mapping I have been touting so much. So I tried a remapping scheme to store specular power zero, but access it as if was specular power one. Unsurprisingly, this threw off the results for all my specular lighting, on top of producing incorrect diffuse lighting.

As a result, I was afraid I was going to have to use a different approach to generate and store my diffuse lighting (eg. Spherical Harmonics (SH)). Fortunately, when I fixed my RSRM generation app, I realized that specular power one can adequately represent diffuse IBL. This way, I can generate all my IBL data using one pipeline, and store all related lighting data in one RSRM texture.

In the process of fixing these problems, I took the opportunity to add some improvements to the system. All of which had the effect of greatly improving both the lighting quality, and reducing both storage and runtime costs for my RSRMs.

Non-Linear Mapping:

In my prior article, I demonstrated how a non-linear mapping of specular powers can reduce storage costs for IBL . It accomplishes this by accounting for the fact that the specular lighting has a non-linear rate of change for increasing specular powers. So we can store more samples for the rapidly changing lower powers, and less for the slowly changing higher powers. This allows us to reduce the number of discrete samples needed to recreate the full range of specular lighting. As it turns out, that was merely scratching the surface of how this technique can benefit the graphics pipeline.

Firstly, it allows artists to use a more intuitive "smoothness" parameter [0, 1] to handle the transition from rough to smooth materials. This allows them to use linear values to effect a perceptually linear change in the smoothness of the material. Compare that to using specular powers directly, which make it hard to tweak materials as their smoothness gets higher.

Secondly, this new parameter can be represented quite efficiently using only byte precision. As a result, it works great with g-buffers that use RGBA8 targets to reduce storage costs. Of course this also applies to storing the data in a smoothness map texture for materials. So it can be sampled directly from the texture into the g-buffer with no need for packing instructions.

Thirdly, this parameter is efficient to use at runtime, because it can be used to directly sample an RSRM. Plus it is cheap to recover the specular power for analytical lights, which only requires a pow(2048.0f, smoothness). This way, the two lighting systems gel together perfectly!

Finally, I decided to go with 256x32 for the map's resolution. This seems to be adequate for representing all the specular powers I want while being reasonably compact. Plus, it establishes a good habit for if I ever develop for the XBOX 360 (ie. 360 uncompressed textures have a lower size limit of 32x32, including the mipmaps).

Results:

Here are some videos and screenshots showing the new improvements in action. Please note that for all these tests, the only sources of illumination are an RSRM and a directional light.

Enjoy! ;)

RSRMs:

Figure 1. 1, Linear [1, 2048]; 2, Non-Linear [1, 2048]

Material Demos:

Figure 2. 1, Iron Sphere; 2, Plastic Sphere; 3, Plastic Statue; 4, Plastic-Metal composite (Model by Ben Mathis)

Final Thoughts:

After much testing, tweaking, and re-testing my RSRM implementation has developed to the point where I feel safe integrating it into my project. The next step will be to add RSRMs to my Light Pre-Pass renderer, and see how they will look with local lights using physically-based BRDFs. I'll keep everyone posted on my progress.

As always, questions and suggestions are welcome in the comments section. ;)