Lighting in Unity 5: Polygon Lighting in KittenVR

Blog Posts ,Programming ,Tutorials ,Unity ,Virtual Reality
April 19, 2016

Today, while I was testing out the basics of a teleport method in KittenVR, I made several teleport pads and gave each of them a light. Cue a fantastic learning experience on my part about Lighting 101: How to not make weird patterns happen.

The Action:

Stick 10+ lights in a scene. Expect all of them to look happy and normal.

The Problem

Lighting is expensive, from a computational standpoint. Unity has an excellent overview on performance optimization with a whole section about optimizing and prioritizing different lights within a scene.

The above image shows the result of my overzealous fan of adding in teleportation lights for every pad. Several of them worked as expected. A couple of them only worked when I got close to them, or at a specific angle from the camera. One of them just looked like a polygon on the floor. I tried a few solutions, including an attempt to swap over to a baked lighting system (more on that in some future tale), deleting and re-adding the teleport pad prefab, and changing lighting settings, but the problem persisted.

I took to Twitter (a huge thanks to @LifeRemainsGood, @ablitter, @nvizstudio, and @reverendkjr for their suggestions!) and learned about Unity’s rendering pipeline implementation for lighting using the forward rendering path. Their manual contained a lot of really great information about how lighting gets prioritized within a scene, and I had a few options for fixing the problem within KittenVR.

The Solution:

This is one of the things that I love about software development (no sarcasm) – the ability to break down a problem and look at solutions across the software lifecycle stages. For me, I had rather quickly just made a snap decision to light up all of the teleportation pads, because it gave a cool effect to them, but I hadn’t stopped to consider the practical considerations. When I ran into this issue, I was faced with a few choices:

  • Change the forward rendering pipeline process by enabling a higher pixel light count within the Quality settings of the application
  • Modify the components of each of the individual lights to specify their importance and prioritize on a per-light basis
  • Create a proximity script to only enable lights on the teleport pads that were within a specific distance of the player
  • Re-design the teleportation pads to only have lights when they were active and selected

Within each individual software application, making decisions about design and engineering can be a challenging task given size and scope of project, as well as responsibilities.Since this is a project that I’m working on by myself, I get an extraordinary amount of freedom and flexibility to decide where in the pipeline to focus in on. Initially, to verify the actual issue, I went with the first option, and changed the pixel light count defaults in the QualitySettings inspector window so that a large number of pixel lights would render. While this fixed the issue, I immediately noticed a few considerations – namely, that this solution would probably come back to bite me in the ass when it came to optimization later on. Remember, this is a VR app – performance is key, and brute forcing rendering settings on lighting is a pretty irresponsible way to fix an aesthetic-only bug.

With that in mind, I decided to go with the most straightforward implementation: redesigning the teleportation pads to only have the light turn on when they were in focus. This would give the lighting more purpose, and solve performance and rendering problems without detracting from the rest of the experience. In the future, a better option would be to bake in lightmaps to represent the different static lighting effects, but I haven’t quite gotten the hang of that and my MBP was struggling to bake the lightmaps on my earlier attempts, so I’ve put a pin in that for now and will continue on with other aspects of development, coming back to the lighting a bit later.

Even after just four hours, Twitter is leaning heavily towards Vive support for KittenVR over Cardboard, so expect to see more on that in the future – especially around teleporting!

I have a lot of optimization left to do, but baking the lighting on the largest of my in-scene items removed a scene tris count from ~1.9M to ~441k. Definite improvement from realtime rendering for the whole thing!

Related Posts

Leave a Reply