binary nightmare #6

Binary Nightmare #6

Visual Confabulation

We’re in the wild west - WebGL is slowly becoming civilized and the implementation within the Unity engine improves with each release. Unity has a concept of render paths, forward or deferred rendering essentially, and these are mostly concerned with the method in which the scene is lit. I’m not going to be covering these methods in depth here today - they’re not new, and they’ve been covered to death since the dawn of 3D accelerator cards.

Our intention was, and is still to used the deferred rendering path, but WebGL 1.0 just says no, as it only supports OpenGLES 2.0 shaders - at some point something changed somewhere in the Unity backend, and the rendering path automatically switches from deferred to forward under these conditions. This is because deferred rendering within Unity now requires 3.0 targets and above.

The shaders had not been developed properly for the forward rendering path - only Mimis makes use of this particular rendering path, and it was unknown to us at the time. So this month I took a couple of days to address some of the issues that had cropped up in Mimis and causing our results to look “bad”. We promised warts and all development - and well you’re starting to see a little of this, to be briefly tangential - this is exactly the kind of thing that happens in development. Something is developed and for some reason it doesn’t function in the way that is expected, along with the old adage of “Well it works on my machine”, (a poor excuse but it tends to be a cause for many ailments), it’s often that edge cases weren’t checked and tested, and this is usually caused by assumptive thinking. The assumption, we’re using the deferred renderer so why would we develop forward rendering shaders?

I previously covered the concept of bullshots back in Binary Nightmare #2, I’ll be showing some of these also in an effort to display how visual fidelity can be affected by manipulating the scene. This will help us to demonstrate the visual quality steps between “Bullshots”, “Native”, “Mimis”. I’ll be using the new “Skyjacker” that Dan has made to demonstrate these results. You can see it for yourself in his post <here> in Mimis.

Note: The post effects have not been balanced by an artist. And the lighting hasn’t been balanced for the scene. All the scene’s use the same “TwoTone” shader that we’ve developed.

The Bullshot

Firstly - this image uses the deferred rendering path, all the textures are at 4k, and there’s been a slight bit of photoshop manipulation, to improve the final quality. There’s also a bunch of post effects taking place to “enhance” the scene.

Native Deferred

This image is representing the deferred rendering path using 1k textures, and the post-effects that we expect to be using. This is subject to change naturally and shouldn’t be seen as a representation of the final product.

Forward Native

The forward rendering path uses the same post effects as we have in Mimis. The lighting also isn’t the same.

Mimis

Taken directly in Mimis, so the camera’s field of view is different, and the angle of the shot not identical. The lighting in Mimis is also different.

Conclusion

It’s strikingly obvious that there are differences in quality, and that is to be expected, there are also differences in terms of how the lighting, in fact, reacts with the surfaces - this is partially down to how the different rendering methods - and partially due to ShaderForges implementation of Deferred and Forward rendered PBR.

The purpose of all this is to show, the enhanced lie, and the difference between what we see, and what we’re showing your good selves within Mimis itself. Whilst the results are like for like, they’re also not terrible, and we feel it’s encouraging to allow for such close detailed inspections of the artwork.