Last month I mentioned a shading trick I was going to try on my old Phantom Organ Player model, and in this post I explain how that worked out. In addition, there are two obscure but cool tips I’ve learned in Unity, one of which may prompt me to return to a past game idea.
Long story short for the hair shading trick, it worked great! Here’s an explanation of how to improve hair/foliage lighting by manipulating the normals.
While that link discusses foliage, the same lighting problems (and thus same solution) applies to hair as well. It describes copying the normals from a base surface onto the foliage planes, rather than using standard normals on the planes. In Blender, this is done using the Data Transfer modifier.
While the normals for planes (like hair, or grass) would normally face perpendicular to the surface they sprout out of, resulting in jarring shading differences, the shading becomes smooth and pleasing if you copy normals from the base surface onto the perpendicular planes. Look at the before and after for my model’s hair:
So that worked well and was pretty easy, the best kind of modeling trick. I’ve pretty much scratched my 3D art itch by now, so I’m back to blogging mostly about programming and/or Unity.
Along those lines, I’ve recently learned of two new-ish things in Unity that are helpful to me. The first is a feature called On Demand Rendering. I actually saw mention of this while I was reading about an interesting framework called UIWidgets. I’m not sure if I’ll use UIWidgets (I’ve seen suggestion that this framework isn’t fully cooked) but their README mentioned On Demand Rendering for adjusting framerate and thus reducing battery usage.
Unity actually explained this new feature on their blog, and here’s a summary. You’ve probably noticed that mobile games drain your phone’s battery faster than other apps. That’s because most apps don’t redraw the screen unless things actually change, whereas games tend to re-render everything continuously. That makes perfect sense for active games where things on screen move constantly, but what about games where the screen is pretty much static for long periods of time?
For games like that (eg. games that just sit and wait until the player takes a turn) it is a wasteful drain on the battery to redraw the screen all the time. However you can’t simply turn down the framerate, because then the game will be less responsive to player input.
Unity has solved that problem by letting you decouple the rendering framerate from everything else. Now you can use on-demand rendering to render graphics at some slow rate, while continuing to receive input in a responsive way. You can even turn up the graphic framerate when input is received, so that the graphics still look smooth when stuff is happening. I haven’t played with it yet (I haven’t yet updated to the latest version of Unity) but the blog code looks easy enough.
One of the main reasons I was considering other development tools for (not sole, but this improvement may be enough for me) for the lightweight management sim was getting rid of battery waste. Well it looks like now I can do that while sticking with Unity, so I’m strongly considering returning to that project.
One last Unity tip I just learned of is Presets for importer settings. Basically, if you tweak a lot of settings (especially for importing assets) the same way, then you can turn those settings into a sortof template to apply. This is an even more obscure feature but I’ve already been putting it to good use at work.
