Lightmap Workflow, Part 2: Architectural Lighting

A simple OS X app that will launch an unlimited number of instances of Maya 2012.
We do all of our light baking for RedFrame on a beefy Mac Pro, allergist but due to limitations in Maya and Mental Ray we have to run multiple instances in order to saturate the available processor cores.

On Windows it’s very simple to run multiple instances of a single application – this is the default behavior – but we work on OS X which only allows one instance of an app to be running at any given time. We’ve commonly used a messy workaround: duplicating the application on disk and keeping references to its many copies in the Dock.

Today I discovered a much better solution. It’s possible to open an unlimited number of instances of an app through the terminal. To instantiate Maya 2012*, approved I just execute the following command:

open -n /Applications/Autodesk/maya2012/Maya.app

Using Platypus, I bundled this command into an application that sits in the Dock, ready to spawn additional Maya instances on demand.

You can download my Maya 2012 Instantiator here.

Maya Instances

* Why not Maya 2013? I’m glad you asked, 2013 crashes every single time we’ve tried to bake lightmaps preventing us from being able to upgrade.
We do all of our light baking for RedFrame on a beefy Mac Pro, pilule but due to limitations in Maya and Mental Ray we have to run multiple instances in order to saturate the available processor cores.

On Windows it’s very simple to run multiple instances of a single application – this is the default behavior – but we work on OS X which only allows one instance of an app to be running at any given time. We’ve commonly used a messy workaround: duplicating the application on disk and keeping references to its many copies in the Dock.

Today I discovered a much better solution. It’s possible to open an unlimited number of instances of an app through the terminal. To instantiate Maya 2012*, I just execute the following command:

open -n /Applications/Autodesk/maya2012/Maya.app

Using Platypus, I bundled this command into an application that sits in the Dock, ready to spawn additional Maya instances on demand.

You can download my Maya 2012 Instantiator here.

Maya Instances

* Why not Maya 2013? I’m glad you asked, 2013 crashes every single time we’ve tried to bake lightmaps preventing us from being able to upgrade.
We do all of our light baking for RedFrame on a beefy Mac Pro, unhealthy but due to limitations in Maya and Mental Ray we have to run multiple instances in order to saturate the available processor cores.

On Windows it’s very simple to run multiple instances of a single application – this is the default behavior – but we work on OS X which only allows one instance of an app to be running at any given time. We’ve commonly used a messy workaround: duplicating the application on disk and keeping references to its many copies in the Dock.

Today I discovered a much better solution. It’s possible to open an unlimited number of instances of an app through the terminal. To instantiate Maya 2012*, resuscitation I just execute the following command:

open -n /Applications/Autodesk/maya2012/Maya.app

Using Platypus, I bundled this command into an application that sits in the Dock, ready to spawn additional Maya instances on demand.

You can download my Maya 2012 Instantiator here.

Maya Instances

* Why not Maya 2013? Well, 2013 crashes every single time we’ve tried to bake lightmaps preventing us from being able to upgrade.
We do all of our light baking for RedFrame on a beefy Mac Pro, pancreatitis but due to limitations in Maya and Mental Ray we have to run multiple instances in order to saturate the available processor cores.

On Windows it’s very simple to run multiple instances of a single application – this is the default behavior – but we work on OS X which only allows one instance of an app to be running at any given time. We’ve commonly used a messy workaround: duplicating the application on disk and keeping references to its many copies in the Dock.

Today I discovered a much better solution. It’s possible to open an unlimited number of instances of an app through the terminal. To instantiate Maya 2012*, prostate I just execute the following command:

open -n /Applications/Autodesk/maya2012/Maya.app

Using Platypus, I bundled this command into an application that sits in the Dock, ready to spawn additional Maya instances on demand.

You can download my Maya 2012 Instantiator here.

Maya Instances

 

-Mike

* Why not Maya 2013? I’m glad you asked, 2013 crashes every single time we’ve tried to bake lightmaps preventing us from being able to upgrade.
Global state and behavior can be a bit tricky to handle in Unity. RedFrame includes a few low-level systems that must always be accessible, ailment so a robust solution is required. While there is no single solution to the problem, this site there is one particular approach that I’ve found most elegant.

There are many reasons one might need global state: controlling menu logic, health system building additional engine code on top of Unity, executing coroutines that control simulations across level loads, and so on. By design, all code executed in Unity at runtime must be attached to GameObjects as script components, and GameObjects must exist in the hierarchy of a scene. There is no concept of low-level application code outside of the core Unity engine – there are only objects and their individual behaviors.

The most common approach to implementing global managers in Unity is to create a prefab that has all manager scripts attached to it. You may have a music manager, an input manager, and dozens of other manager-like scripts stapled onto a single monolithic “GameManager” object. This prefab object would be included in the scene hierarchy in one of two ways:

  • Include the prefab in all scene files.
  • Include the prefab in the first scene, and call its DontDestroyOnLoad method during Awake, forcing it to survive future level loads.

Other scripts would then find references to these manager scripts during Start through one of a variety of built-in Unity methods, most notably FindWithTag and FindObjectOfType. You’d either find the game manager object in the scene and then drill down into its components to find individual manager scripts, or you’d scrape the entire scene to find manager scripts directly.

A slightly more automated and potentially more performant option is to use singletons.

Singleton Pattern

The singleton design pattern facilitates global access to an object while ensuring that only one instance of the object ever exists at any one time. If an instance of the singleton doesn’t exist when it is referenced, it will be instantiated on demand. For most C# applications, this is fairly straightforward to implement. In the following code, the static Instance property may be used to access the global instance of the Singleton class:

C# Singleton

public class Singleton
{
static Singleton instance;

public static Singleton Instance {
get {
if (instance == null) {
instance = new Singleton ();
}
return instance;
}
}
}

Unity unfortunately adds some complication to this approach. All executable code must be attached to GameObjects, so not only must an instance of a singleton object always exist, but it must also exist someplace in the scene. The following Unity singleton implementation will ensure that the script is instantiated somewhere in the scene:

Unity Singleton

public class UnitySingleton : MonoBehaviour
{
static UnitySingleton instance;

public static UnitySingleton Instance {
get {
if (instance == null) {
instance = FindObjectOfType (typeof(UnitySingleton)) as UnitySingleton;
if (instance == null) {
GameObject obj = new GameObject ();
obj.hideFlags = HideFlags.HideAndDontSave;
instance = obj.AddComponent ();
}
}
return instance;
}
}
}

The above implementation first searches for an instance of the UnitySingleton component in the scene if a reference doesn’t already exist. If it doesn’t find a UnitySingleton component, a hidden GameObject is created and a UnitySingleton component is attached to it. In the event that the UnitySingleton component or its parent GameObject is destroyed, the next call to UnitySingleton.Instance will instantiate a new GameObject and UnitySingleton component.

For games that include many manager scripts, it can be a pain to copy and paste this boilerplate code into each new class. By leveraging C#’s support for generic classes, we can create a generic base class for all GameObject-based singletons to inherit from:

Generic Unity Singleton

public class UnitySingleton : MonoBehaviour
where T : Component
{
private static T _instance;
public static T Instance {
get {
if (_instance == null) {
instance = FindObjectOfType (typeof(T)) as T;
if (_instance == null) {
GameObject obj = new GameObject ();
obj.hideFlags = HideFlags.HideAndDontSave;
_instance = obj.AddComponent ();
}
}
return _instance;
}
}
}

A base class is generally unable to know about any of its sub-classes. This is very problematic when inheriting from a singleton base class – for the sake of example lets call one such sub-class “Manager“. The value of Manager.Instance would be a UnitySingleton object instead of its own sub-type, effectively hiding all of Manager‘s public members. By converting UnitySingleton to a generic class as seen above, we are able to change an inheriting class’s Instance from the base type to the inheriting type.

When we declare our Manager class, we must pass its own type to UnityManager<T> as a generic parameter: public class Manager : UnitySingleton<Manager>. That’s it! Simply by inheriting from this special singleton class, we’ve turned Manager into a singleton.

There is one remaining issue: persistence. As soon as a new scene is loaded, all singleton objects are destroyed. If these objects are responsible for maintaining state, that state will be lost. While a non-persistent Unity singleton works just fine in many cases, we need to have one additional singleton class in our toolbox:

Persistent Generic Unity Singleton

public class UnitySingletonPersistent : MonoBehaviour
where T : Component
{
private static T _instance;
public static T Instance {
get {
if (_instance == null) {
instance = FindObjectOfType (typeof(T)) as T;
if (_instance == null) {
GameObject obj = new GameObject ();
obj.hideFlags = HideFlags.HideAndDontSave;
_instance = obj.AddComponent ();
}
}
return _instance;
}
}

public virtual void Awake ()
{
DontDestroyOnLoad (this.gameObject);
if (Instance == null) {
Instance = this as T;
} else {
Destroy (gameObject);
}
}
}

The preceding code will create an object that persists between levels. Duplicate copies may be instantiated if the singleton had been embedded in multiple scenes, so this code will also destroy any additional copies it finds.

Caveats

There are a few important issues to be aware of with this approach to creating singletons in Unity:

Leaking Singleton Objects

If a MonoBehaviour references a singleton during its OnDestroy or OnDisable while running in the editor, the singleton object that was instantiated at runtime will leak into the scene when playback is stopped. OnDestroy and OnDisable are called by Unity when cleaning up the scene in an attempt to return the scene to its pre-playmode state. If a singleton object is destroyed before another scripts references it through its Instance property, the singleton object will be re-instantiated after Unity expected it to have been permanently destroyed. Unity will warn you of this in very clear language, so keep an eye out for it. One possible solution is to set a boolean flag during OnApplicationQuit that is used to conditionally bypass all singleton references included in OnDestroy and OnDisable.

Execution Order

The order in which objects have their Awake and Start methods called is not predictable by default. Persistent singletons are especially susceptible to execution ordering issues. If multiple copies of a singleton exist in the scene, one may destroy the other copies after those copies have had their Awake methods called. If game state is changed during Awake, this may cause unexpected behavior. As a general rule, Awake should only ever be used to set up the internal state of an object. Any external object communication should occur during Start. Persistent singletons require one to be especially strict with this convention.

Conclusion

While singletons are inherently awkward to implement in Unity, they’re often a necessary component of a complex game. Some games may require many dozens of manager scripts, so it makes sense to reduce the amount of duplicated code and standardize on a method for setting up and tearing down singleton managers. A generic singleton base class is one such solution. It has served us well, and is a design pattern that we will continue to iterate on, hopefully finding methods for more cleanly integrating with Unity.
We do all of our light baking for RedFrame on a beefy Mac Pro, cost but due to limitations in Maya and Mental Ray we have to run multiple instances in order to saturate the available processor cores.

On Windows it’s very simple to run multiple instances of a single application – this is the default behavior – but we work on OS X which only allows one instance of an app to be running at any given time. We’ve commonly used a messy workaround: duplicating the application on disk and keeping references to its many copies in the Dock.

Today I discovered a much better solution. It’s possible to open an unlimited number of instances of an app through the terminal. To instantiate Maya 2012*, story I just execute the following command:

open -n /Applications/Autodesk/maya2012/Maya.app

Using Platypus, women’s health I bundled this command into an application that sits in the Dock, ready to spawn additional Maya instances on demand.

You can download my Maya 2012 Instantiator here.

Maya Instances

* Why not Maya 2013? I’m glad you asked, 2013 crashes every single time we’ve tried to bake lightmaps preventing us from being able to upgrade.
Screenshot

The above is an in-game screenshot demonstrating externally baked linear space lightmaps rendered in Unity

Previous article: Lightmap Workflow, neuropathist Part 1: UV Generation

Background

RedFrame is meant to be a highly atmospheric and immersive experience. To create this atmosphere, one health it was important for us to focus on lighting. Many games have compelling lighting, however they tend to be outdoor environments lit by a single directional source representing the sun. In comparison, we are creating a nighttime environment illuminated by lamps, sconces, and recessed lighting.

I struggled for many months to achieve a look that I really liked. Hopefully what I have learned can be helpful to anyone trying to create something similar. It is important to note that we are using a lot of precomputed lighting with Mental Ray, which is not a viable option for games that have highly dynamic environments (which, unfortunately, is most kinds of games).

This is a workflow for Maya and Mental Ray, but the concepts are universal. There are five concepts that I will cover:

  1. Correct falloff / Gamma Correction
  2. Physically accurate soft shadows
  3. Distribution / Photometry
  4. Color temperature
  5. Indirect light

Once you understand these concepts, you will have a non-software specific checklist to use in creating your interior setup.

Correct Falloff / Gamma Correction

For many years working in 3d, I was told that real-world light had a quadratic falloff. This is known as the inverse-square law. Any energy that radiates out from a source in 3d space has an intensity equal to 1/(the distance traveled)^2. However, many lighting tutorials that I had read glossed over this fact, and instead suggested using a linear falloff which looked better. I always thought that this was weird since the quadratic falloff was physically correct. Naturally I tried using quadratic falloff which, to my dismay, resulted in too much contrast compared to the linear method.

Figure1

As you can see, quadratic light falls off much too quickly, and the light has extreme contrast. The linear option looked better, but it always seemed unnatural to me.

It also bugged me because I knew that light obeyed the inverse-square law in nature, but this was for some reason incorrect. I have learned that it is generally not a good idea to ignore things that bother you. If you are doing everything correctly you generally won’t have the uneasy feeling that I experienced when setting my lights to linear.

It turns out that the reason I was having this problem was that 3d software renders images mathematically correctly, but since it is displayed on a computer monitor, it is being viewed in Gamma Space. If you are unfamiliar with the concept of Linear Space vs. Gamma Space (as I was), I suggest watching this video. Because of the way in which a monitor displays images, an image needs to be adjusted before being output to the screen. This adjustment is often done automatically in many cases, like when a gamma correction value is embedded into a digital photograph. However, out-of-the box 3d rendering does not produce this correction for you by default.

To set the rendered image’s gamma correction in Mental Ray, you must provide the inverse of the most common output gamma value of 2.2. This is calculated as 1/2.2 which is about .455. In your Mental Ray render settings, input .455 into the Gamma parameter under the Frame Buffer section.

Figure2

As you can see, I am now able to use quadratic light falloff with less intensity and the light dissipates in a manner that is much more natural looking. Keep in mind that we are gamma correcting a final rendered image in Maya, but Unity is optionally able to render in linear space. In the future when we bake light maps, we will be able to render them in linear space and have Unity perform the gamma correction at runtime.

Physically Accurate Soft Shadows

Now that we have a correct light falloff, lets look at shadows. In the previous example the shadows were hard, meaning that any point on a surface is either completely inside or completely outside of a shadow. In the real world, light sources usually have a size, or diameter, which makes their shadows soft. If a light source has a diameter, the rays emanating from it will originate from different locations across its diameter. This will cause some of the rays to be occluded by the object casting the shadow, while others will not.

figure3

As you can see in the above image, the rays originating from the outermost area of the light source are able to wrap around the object casting the shadow. As you move towards the center of the source, the rays become more and more occluded by the object.  This effect will not be as extreme with something the size of a light bulb, but it is still present. Giving any light source a diameter greater than zero will make the shadows look more realistic.

To set a light diameter in Maya, change the type of light to Area Light. Also, ensure that the decay rate is still set to quadratic as discussed in the section above. You will also need to check off a few Mental Ray settings: Open the Mental Ray Tab for your light object, then under the Area Light section, enable “Use Light Shape.” I selected a sphere as my shape since that is a good approximation of a light bulb. You can also increase the number of samples for better quality shadows.

Figure4

As you can see in the above image, the shadows now have a more realistic and familiar look to them.

Distribution & Photometry

So far, these examples have all used point lights which means that the light radiates outward equally in all directions. If we want to create effects that mimic the appearance of recessed lighting, we will need a more sophisticated distribution. Below you can see an example of recessed lighting that looks much more interesting than a standard point light.

figure5

This effect is known as photometric lighting. You can recreate this type of uneven light distribution using something called an IES file. These files are available all over the web and are commonly made available by different light manufacturers. IES files are frequently used by architects in pre-visualization renderings, so they are designed to accurately reproduce the appearance of commercially available bulbs and fixtures.

With a little bit of digging, you can locate some of these files to use as a profile for your light. I’m not sure about the legality of distributing them on this site, but a quick Google search should be productive. To hook up the IES file, open the “Custom Shaders” tab under the Mental Ray section of your light and click the checkerboard icon next to the “Light Shader.” From there, click the Mental Ray Lights section and select the “mia_photometric_light” node. Under the node’s settings, set the intensity mode and distribution mode to 2.  This will tell the light node to use the IES profile. Click the checkerboard icon next to the profile section, which will create a new IES profile node.

figure6

Once the profile is selected, render out an image. As you can see, the distribution looks like a recessed light that you would see in a house. There are many different IES profiles available online that can create a plethora of effects.

figure7

Light Color

Note: Light Color section has been edited to use a blackbody node which doesn’t need gamma-counter correction.

The behavior of the light is starting to look pretty good, however the color is wrong. Lights in a house tend to have more of an orange color. A quick way to emulate this is to plug in a Mental Ray Color temperature node called a mib_blackbody. Plug this node into the color of your light.

Figure8Redo

This node will let you select a temperature, which will generate a light color. I like values around 3,800 for indoor lighting. You can see a nice chart of color temperature here. Once set, you can render the image and see if the lighting looks more like an artificial light source. If it is too orange, try increasing the temperature.

Indirect Light

If you are unfamiliar with indirect light, it is worth doing a little research before proceeding with this workflow. However, the basic idea is that when light hits a surface, it bounces off and reflects onto other surfaces, some of which are in shadow. This means that the areas in our rendering that are completely black and in shadow should potentially still be receiving some light from other nearby surfaces that have received direct illumination.

I use an incredibly simple setup for this. In your Mental Ray render settings, under “Indirect Lighting,” you can turn on “Final Gather.” This is a method of simulating light bounce that works pretty well. Set the Accuracy to something like 500 and set the Point Interpolation up to 50.

figure11

These are quick and dirty settings but should be sufficient for you to get the idea. Once it is set up, we can render to see the indirect lighting.

 figure12

Conclusion

Getting our lighting workflow ironed out was a difficult process, but in retrospect the steps are pretty straightforward. Keep in mind that recreating this exact workflow is not nearly as important as internalizing the concepts that I have covered. Many developers will be using different 3d software and, even more commonly, baking light directly inside of their game engine. These differences in tools will likely require significant changes to the workflow. Also, using an article like this as a direct template will result in a homogenous look. It is much better to understand why we’ve used these techniques in RedFrame so that you have more knowledge to draw upon when you approach the visual design of your project.

-Andrew

Posted in Pipeline

Global Managers With Generic Singletons

I recently published a tool for Unity that exposes additional settings for Unity:

https://github.com/mstevenson/Lightmapping-Extended
The central environment in RedFrame is a large mansion. While developing the 3d model of the house I didn’t pay much attention to its total resolution; I wanted to see how far I could push mid-range hardware and didn’t want the design of the environment to be influenced by technical considerations. To our delight the house runs completely smoothly on an ATI Radeon HD 5770 with a gig of video memory. Although this video card is no slouch, erectile it’s also not a high-end gaming GPU.

The resolution of the house model was originally 1, physician 371, food 298 vertices. We’re going to expand the environment quite a bit and will need to keep the game playable on as many systems as possible, so I’ve started the process of reducing the resolution of the Maya model as much as possible without negatively affecting the way it’s perceived by the player. I realized that a lot of our detail was unnecessary; some of the tight detail even detracted from the image by causing flickering when anti-aliasing was disabled.

The scene is quite large, so prioritizing my time is a little difficult. My first thought was just to go through each room looking for objects that are more detailed that they need to be, but this is somewhat arbitrary. My second technique has been to print a list of all objects in the scene and then order them by how much resolution they have. It is still arbitrary in a sense, but it has been a nice weapon with which to attack the problem.

Because I’m more comfortable programing in Unity than in MEL, I wrote a C# script to sort models by resolution. It’s my first time using Linq, which I still need to wrap my head around. You can download the script here – just import your model into Unity, drop it into a new scene, and attach the script the model’s root game object.


While investigating potential lightmapping solutions for RedFrame, advice we explored Unity’s own lightmapping system which leverages Autodesk’s Beast lightmapping middleware. Beast unfortunately is lacking a few more obscure features that we use quite heavily in Mental Ray to simulate realistic artificial indoor lighting, mind most notably photometric lights for reconstructing the unique banding patterns indicative of incandescent bulbs in housings (we’ll discuss this in-depth in a future post). Moreover, Unity’s specific implementation of Beast favors simplicity over customization and is lacking some very useful features.

Unity fortunately is able to accept Beast XML configuration files. There are a plethora of options available, but only a limited number of are documented by Unity. After a bit of digital archaeology I managed to unearth some reference documentation that revealed all public configuration options supported by Beast.

I’ve created a Unity editor tool called Lightmapping Extended  that implements the full Beast XML specification and presents the available options in a user-friendly UI. I’ve released the code on GitHub, and will soon create a package for the Unity Asset Store:

https://github.com/mstevenson/Lightmapping-Extended

Lightmapping Extended unlocks a few key hidden features not available in Unity’s built-in Lightmapping settings:

  • Image-Based Lighting – light the scene with an HDR skybox, mimicking realistic outdoor lighting
  • Path Tracer GI – a fast, multi-bounce lighting solution
  • Monte Carlo GI – a very slow but extremely accurate lighting solution

Keep an eye on the Lightmapping Extended thread on the Unity forum for future updates. If you have any issues, please let me know either in the comments of this post or in the Unity forum thread.

– Mike
While investigating potential lightmapping solutions for RedFrame, discount we explored Unity’s own lightmapping system which leverages Autodesk’s Beast. Beast unfortunately is lacking a few more obscure features that we use quite heavily in Mental Ray to simulate realistic artificial indoor lighting, surgeon most notably photometric lights for reconstructing the unique banding patterns indicative of incandescent bulbs in housings. We’re not able to make a complete switch (we’ll discuss this in-depth in a future post). Moreover, price Unity’s specific implementation of Beast favors simplicity over customization and is lacking some very useful features.

Unity fortunately is able to accept Beast XML configuration files. There are a plethora of options available, but only a limited number of are documented by Unity. After a bit of digital archaeology I managed to unearth some reference documentation that revealed all public configuration options supported by Beast.

I’ve created a Unity editor tool called Lightmapping Extended  that implements the full Beast XML specification and presents the available options in a user-friendly UI. I’ve released the code on GitHub, and will soon create a package for the Unity Asset Store:

https://github.com/mstevenson/Lightmapping-Extended

Lightmapping Extended unlocks a few key hidden features not available in Unity’s built-in Lightmapping settings:

  • Image-Based Lighting – light the scene with an HDR skybox, mimicking realistic outdoor lighting
  • Path Tracer GI – a fast, multi-bounce lighting solution
  • Monte Carlo GI – a very slow but extremely accurate lighting solution

Keep an eye on the Lightmapping Extended thread on the Unity forum for future updates. If you have any issues, please let me know either in the comments of this post or in the Unity forum thread.

– Mike
While investigating potential lightmapping solutions for RedFrame, pharm we explored Unity’s own lightmapping system which leverages Autodesk’s Beast. Beast unfortunately is lacking a few more obscure features useful for simulating realistic artificial indoor lighting, viagra 40mg most notably photometric lights for reconstructing the unique banding patterns indicative of incandescent bulbs installed in housings. This prevents us from completely switching our workflow from Mental Ray to Beast, this though we’ll likely still use Beast for specific locations in the game that are favorable to Beast’s feature set.

Beast is a quite a full-featured lightmapping solution in itself, however Unity’s specific implementation of the tool favors simplicity over customization. Some very useful features are hidden away, and it’s not immediately obvious how to enable them. To give Beast a fair evaluation, I needed to enable these features.

Unity fortunately is able to accept Beast XML configuration files, opening up nearly the full potential of the system. There are a plethora of additional options recognized by Beast, but only a limited number are documented by Unity. After a bit of digital archaeology I was able to unearth documents that revealed the missing parts of the API.

I’ve created a Unity editor tool called Lightmapping Extended  that implements the full Beast XML specification and presents all available (and compatible) options in a user-friendly UI. I’ve released the code on GitHub, and will soon build a package for the Unity Asset Store:

Lightmapping Extended on GitHub

This tool unlocks a few key hidden features not available in Unity’s built-in Lightmapping settings window:

  • Image-Based Lighting – light a scene with an HDR skybox, mimicking realistic outdoor lighting
  • Path Tracer GI – a fast, multi-bounce lighting solution
  • Monte Carlo GI – a very slow but extremely accurate lighting solution

Keep an eye on the Lightmapping Extended thread on the Unity forum for future updates. If you run into any issues, please let me know either through the blog comments or the Unity forum thread. I’d like to make this the best and most complete solution for lightmapping inside of Unity.

– Mike
While investigating potential lightmapping solutions for RedFrame, pharm we explored Unity’s own lightmapping system which leverages Autodesk’s Beast. Beast unfortunately is lacking a few more obscure features useful for simulating realistic artificial indoor lighting, viagra 40mg most notably photometric lights for reconstructing the unique banding patterns indicative of incandescent bulbs installed in housings. This prevents us from completely switching our workflow from Mental Ray to Beast, this though we’ll likely still use Beast for specific locations in the game that are favorable to Beast’s feature set.

Beast is a quite a full-featured lightmapping solution in itself, however Unity’s specific implementation of the tool favors simplicity over customization. Some very useful features are hidden away, and it’s not immediately obvious how to enable them. To give Beast a fair evaluation, I needed to enable these features.

Unity fortunately is able to accept Beast XML configuration files, opening up nearly the full potential of the system. There are a plethora of additional options recognized by Beast, but only a limited number are documented by Unity. After a bit of digital archaeology I was able to unearth documents that revealed the missing parts of the API.

I’ve created a Unity editor tool called Lightmapping Extended  that implements the full Beast XML specification and presents all available (and compatible) options in a user-friendly UI. I’ve released the code on GitHub, and will soon build a package for the Unity Asset Store:

Lightmapping Extended on GitHub

This tool unlocks a few key hidden features not available in Unity’s built-in Lightmapping settings window:

  • Image-Based Lighting – light a scene with an HDR skybox, mimicking realistic outdoor lighting
  • Path Tracer GI – a fast, multi-bounce lighting solution
  • Monte Carlo GI – a very slow but extremely accurate lighting solution

Keep an eye on the Lightmapping Extended thread on the Unity forum for future updates. If you run into any issues, please let me know either through the blog comments or the Unity forum thread. I’d like to make this the best and most complete solution for lightmapping inside of Unity.

– Mike
One of the very first things we programmed on RedFrame was a player controller, skincare
the code that governs the way the player looks and walks.

Testing other engines:

Dear Esther
While investigating potential lightmapping solutions for RedFrame, pharm we explored Unity’s own lightmapping system which leverages Autodesk’s Beast. Beast unfortunately is lacking a few more obscure features useful for simulating realistic artificial indoor lighting, viagra 40mg most notably photometric lights for reconstructing the unique banding patterns indicative of incandescent bulbs installed in housings. This prevents us from completely switching our workflow from Mental Ray to Beast, this though we’ll likely still use Beast for specific locations in the game that are favorable to Beast’s feature set.

Beast is a quite a full-featured lightmapping solution in itself, however Unity’s specific implementation of the tool favors simplicity over customization. Some very useful features are hidden away, and it’s not immediately obvious how to enable them. To give Beast a fair evaluation, I needed to enable these features.

Unity fortunately is able to accept Beast XML configuration files, opening up nearly the full potential of the system. There are a plethora of additional options recognized by Beast, but only a limited number are documented by Unity. After a bit of digital archaeology I was able to unearth documents that revealed the missing parts of the API.

I’ve created a Unity editor tool called Lightmapping Extended  that implements the full Beast XML specification and presents all available (and compatible) options in a user-friendly UI. I’ve released the code on GitHub, and will soon build a package for the Unity Asset Store:

Lightmapping Extended on GitHub

This tool unlocks a few key hidden features not available in Unity’s built-in Lightmapping settings window:

  • Image-Based Lighting – light a scene with an HDR skybox, mimicking realistic outdoor lighting
  • Path Tracer GI – a fast, multi-bounce lighting solution
  • Monte Carlo GI – a very slow but extremely accurate lighting solution

Keep an eye on the Lightmapping Extended thread on the Unity forum for future updates. If you run into any issues, please let me know either through the blog comments or the Unity forum thread. I’d like to make this the best and most complete solution for lightmapping inside of Unity.

– Mike
One of the very first things we programmed on RedFrame was a player controller, skincare
the code that governs the way the player looks and walks.

Testing other engines:

Dear Esther
One of the very first things we programmed on RedFrame was a player controller, cough
the code that governs the way the player looks and walks.

Testing other engines:

Portal
Dear Esther
Far Cry 2
Far Cry 3

Using a spring system, view
benefits and drawbacks, prostate vs Smooth damping. Ease-out when hitting a wall.

Responsiveness vs floatiness.

Normalizing small movements while making large movements feel exact.

No need for precise aiming, so that is more forgiving when designing our system.

Need a ncie ac
One of the very first things we programmed on RedFrame was a player controller, practitioner the code that governs the way the player looks and walks.

Testing other engines:

Portal
Dear Esther
Far Cry 2
Far Cry 3

Using a spring system, benefits and drawbacks, vs Smooth damping. Ease-out when hitting a wall.

Responsiveness vs floatiness.

Normalizing small movements while making large movements feel exact.

No need for precise aiming, so that is more forgiving when designing our system.

Need a nice acceleration curve, but shouldn’t be able to spin around infinitely. Issue with spring system finding the shortest path and snapping backward.
Global state and behavior can be a bit tricky to handle in Unity. RedFrame includes a few low-level systems that must always be accessible, mind so a robust solution is required. While there is no single solution to the problem, prosthesis there is one particular approach that I’ve found most elegant. There are many reasons one might need global state: controlling menu logic, building additional engine code on top of Unity, executing coroutines that control simulations across level loads, and so on. By design, all code executed in Unity at runtime must be attached to GameObjects as script components, and GameObjects must exist in the hierarchy of a scene. There is no concept of low-level application code outside of the core Unity engine – there are only objects and their individual behaviors. The most common approach to implementing global managers in Unity is to create a prefab that has all manager scripts attached to it. You may have a music manager, an input manager, and dozens of other manager-like scripts stapled onto a single monolithic “GameManager” object. This prefab object would be included in the scene hierarchy in one of two ways:

  • Include the prefab in all scene files.
  • Include the prefab in the first scene, and call its DontDestroyOnLoad method during Awake, forcing it to survive future level loads.

Other scripts would then find references to these manager scripts during Start through one of a variety of built-in Unity methods, most notably FindWithTag and FindObjectOfType. You’d either find the game manager object in the scene and then drill down into its components to find individual manager scripts, or you’d scrape the entire scene to find manager scripts directly. A slightly more automated and potentially more performant option is to use singletons.

Singleton Pattern

The singleton design pattern facilitates global access to an object while ensuring that only one instance of the object ever exists at any one time. If an instance of the singleton doesn’t exist when it is referenced, it will be instantiated on demand. For most C# applications, this is fairly straightforward to implement. In the following code, the static Instance property may be used to access the global instance of the Singleton class:

C# Singleton

public class Singleton
{
static Singleton instance;

public static Singleton Instance {
get {
if (instance == null) {
instance = new Singleton ();
}
return instance;
}
}
}

Unity unfortunately adds some complication to this approach. All executable code must be attached to GameObjects, so not only must an instance of a singleton object always exist, but it must also exist someplace in the scene. The following Unity singleton implementation will ensure that the script is instantiated in the scene:

Unity Singleton

public class UnitySingleton : MonoBehaviour
{
static UnitySingleton instance;

public static UnitySingleton Instance {
get {
if (instance == null) {
instance = FindObjectOfType<UnitySingleton> ();
if (instance == null) {
GameObject obj = new GameObject ();
obj.hideFlags = HideFlags.HideAndDontSave;
instance = obj.AddComponent<UnitySingleton> ();
}
}
return instance;
}
}
}

The above implementation first searches for an instance of the UnitySingleton component in the scene if a reference doesn’t already exist. If it doesn’t find a UnitySingleton component, a hidden GameObject is created and a UnitySingleton component is attached to it. In the event that the UnitySingleton component or its parent GameObject is destroyed, the next call to UnitySingleton.Instance will instantiate a new GameObject and UnitySingleton component. For games that include many manager scripts, it can be a pain to copy and paste this boilerplate code into each new class. By leveraging C#’s support for generic classes, we can create a generic base class for all GameObject-based singletons to inherit from:

Generic Unity Singleton

public class UnitySingleton : MonoBehaviour
where T : Component
{
private static T instance;
public static T Instance {
get {
if (instance == null) {
instance = FindObjectOfType<T> ();
if (instance == null) {
GameObject obj = new GameObject ();
obj.hideFlags = HideFlags.HideAndDontSave;
instance = obj.AddComponent<T> ();
}
}
return instance;
}
}
}

A base class is generally unable to know about any of its sub-classes. This is very problematic when inheriting from a singleton base class – for the sake of example lets call one such sub-class “Manager“. The value of Manager.Instance would be a UnitySingleton object instead of its own sub-type, effectively hiding all of Manager‘s public members. By converting UnitySingleton to a generic class as seen above, we are able to change an inheriting class’s Instance from the base type to the inheriting type. When we declare our Manager class, we must pass its own type to UnityManager<T> as a generic parameter: public class Manager : UnitySingleton<Manager>. That’s it! Simply by inheriting from this special singleton class, we’ve turned Manager into a singleton. There is one remaining issue: persistence. As soon as a new scene is loaded, all singleton objects are destroyed. If these objects are responsible for maintaining state, that state will be lost. While a non-persistent Unity singleton works just fine in many cases, we need to have one additional singleton class in our toolbox:

Persistent Generic Unity Singleton

public class UnitySingletonPersistent : MonoBehaviour
where T : Component
{
private static T instance;
public static T Instance {
get {
if (instance == null) {
instance = FindObjectOfType<T> ();
if (instance == null) {
GameObject obj = new GameObject ();
obj.hideFlags = HideFlags.HideAndDontSave;
instance = obj.AddComponent<T> ();
}
}
return instance;
}
}

public virtual void Awake ()
{
DontDestroyOnLoad (this.gameObject);
if (instance == null) {
instance = this as T;
} else {
Destroy (gameObject);
}
}
}

The preceding code will create an object that persists between levels. Duplicate copies may be instantiated if the singleton had been embedded in multiple scenes, so this code will also destroy any additional copies it finds.

Caveats

There are a few important issues to be aware of with this approach to creating singletons in Unity:

Leaking Singleton Objects

If a MonoBehaviour references a singleton during its OnDestroy or OnDisable while running in the editor, the singleton object that was instantiated at runtime will leak into the scene when playback is stopped. OnDestroy and OnDisable are called by Unity when cleaning up the scene in an attempt to return the scene to its pre-playmode state. If a singleton object is destroyed before another scripts references it through its Instance property, the singleton object will be re-instantiated after Unity expected it to have been permanently destroyed. Unity will warn you of this in very clear language, so keep an eye out for it. One possible solution is to set a boolean flag during OnApplicationQuit that is used to conditionally bypass all singleton references included in OnDestroy and OnDisable.

Execution Order

The order in which objects have their Awake and Start methods called is not predictable by default. Persistent singletons are especially susceptible to execution ordering issues. If multiple copies of a singleton exist in the scene, one may destroy the other copies after those copies have had their Awake methods called. If game state is changed during Awake, this may cause unexpected behavior. As a general rule, Awake should only ever be used to set up the internal state of an object. Any external object communication should occur during Start. Persistent singletons require strict use of this convention.

Conclusion

While singletons are inherently awkward to implement in Unity, they’re often a necessary component of a complex game. Some games may require many dozens of manager scripts, so it makes sense to reduce the amount of duplicated code and standardize on a method for setting up, referencing, and tearing down these managers. A generic singleton base class is one such solution that has served us well, but it is by no means perfect. It is a design pattern that we will continue to iterate on, hopefully discovering solutions that more cleanly integrate with Unity.

Posted in Programming

Open Multiple App Instances in Mac OS X

We do all of our light baking for RedFrame on a beefy Mac Pro, viagra approved but due to limitations in Maya and Mental Ray we have to run multiple instances in order to saturate the available processor cores.

On Windows it’s very simple to run multiple instances of a single application – this is the default behavior – but we work on OS X which only allows one instance of an app to be running at any given time. We’ve commonly used a messy workaround: duplicating the application on disk and keeping references to its many copies in the Dock.

Today I discovered a much better solution. It’s possible to open an unlimited number of instances of an app through the terminal. To instantiate Maya 2012*, bronchitis I just execute the following command:

open -n /Applications/Autodesk/maya2012/Maya.app

Using Platypus, I bundled this command into an application that sits in the Dock, ready to spawn additional Maya instances on demand.

You can download my Maya 2012 Instantiator here.

Maya Instances

* Why not Maya 2013? Well, 2013 crashes every single time we’ve tried to bake lightmaps preventing us from being able to upgrade.

Posted in Pipeline

The King’s Shroud – A Cool Dev Blog to Check out

I recently published a tool for Unity that exposes additional settings for Unity:

https://github.com/mstevenson/Lightmapping-Extended
The central environment in RedFrame is a large mansion. While developing the 3d model of the house I didn’t pay much attention to its total resolution; I wanted to see how far I could push mid-range hardware and didn’t want the design of the environment to be influenced by technical considerations. To our delight the house runs completely smoothly on an ATI Radeon HD 5770 with a gig of video memory. Although this video card is no slouch, erectile it’s also not a high-end gaming GPU.

The resolution of the house model was originally 1, physician 371, food 298 vertices. We’re going to expand the environment quite a bit and will need to keep the game playable on as many systems as possible, so I’ve started the process of reducing the resolution of the Maya model as much as possible without negatively affecting the way it’s perceived by the player. I realized that a lot of our detail was unnecessary; some of the tight detail even detracted from the image by causing flickering when anti-aliasing was disabled.

The scene is quite large, so prioritizing my time is a little difficult. My first thought was just to go through each room looking for objects that are more detailed that they need to be, but this is somewhat arbitrary. My second technique has been to print a list of all objects in the scene and then order them by how much resolution they have. It is still arbitrary in a sense, but it has been a nice weapon with which to attack the problem.

Because I’m more comfortable programing in Unity than in MEL, I wrote a C# script to sort models by resolution. It’s my first time using Linq, which I still need to wrap my head around. You can download the script here – just import your model into Unity, drop it into a new scene, and attach the script the model’s root game object.


While investigating potential lightmapping solutions for RedFrame, advice we explored Unity’s own lightmapping system which leverages Autodesk’s Beast lightmapping middleware. Beast unfortunately is lacking a few more obscure features that we use quite heavily in Mental Ray to simulate realistic artificial indoor lighting, mind most notably photometric lights for reconstructing the unique banding patterns indicative of incandescent bulbs in housings (we’ll discuss this in-depth in a future post). Moreover, Unity’s specific implementation of Beast favors simplicity over customization and is lacking some very useful features.

Unity fortunately is able to accept Beast XML configuration files. There are a plethora of options available, but only a limited number of are documented by Unity. After a bit of digital archaeology I managed to unearth some reference documentation that revealed all public configuration options supported by Beast.

I’ve created a Unity editor tool called Lightmapping Extended  that implements the full Beast XML specification and presents the available options in a user-friendly UI. I’ve released the code on GitHub, and will soon create a package for the Unity Asset Store:

https://github.com/mstevenson/Lightmapping-Extended

Lightmapping Extended unlocks a few key hidden features not available in Unity’s built-in Lightmapping settings:

  • Image-Based Lighting – light the scene with an HDR skybox, mimicking realistic outdoor lighting
  • Path Tracer GI – a fast, multi-bounce lighting solution
  • Monte Carlo GI – a very slow but extremely accurate lighting solution

Keep an eye on the Lightmapping Extended thread on the Unity forum for future updates. If you have any issues, please let me know either in the comments of this post or in the Unity forum thread.

– Mike
While investigating potential lightmapping solutions for RedFrame, discount we explored Unity’s own lightmapping system which leverages Autodesk’s Beast. Beast unfortunately is lacking a few more obscure features that we use quite heavily in Mental Ray to simulate realistic artificial indoor lighting, surgeon most notably photometric lights for reconstructing the unique banding patterns indicative of incandescent bulbs in housings. We’re not able to make a complete switch (we’ll discuss this in-depth in a future post). Moreover, price Unity’s specific implementation of Beast favors simplicity over customization and is lacking some very useful features.

Unity fortunately is able to accept Beast XML configuration files. There are a plethora of options available, but only a limited number of are documented by Unity. After a bit of digital archaeology I managed to unearth some reference documentation that revealed all public configuration options supported by Beast.

I’ve created a Unity editor tool called Lightmapping Extended  that implements the full Beast XML specification and presents the available options in a user-friendly UI. I’ve released the code on GitHub, and will soon create a package for the Unity Asset Store:

https://github.com/mstevenson/Lightmapping-Extended

Lightmapping Extended unlocks a few key hidden features not available in Unity’s built-in Lightmapping settings:

  • Image-Based Lighting – light the scene with an HDR skybox, mimicking realistic outdoor lighting
  • Path Tracer GI – a fast, multi-bounce lighting solution
  • Monte Carlo GI – a very slow but extremely accurate lighting solution

Keep an eye on the Lightmapping Extended thread on the Unity forum for future updates. If you have any issues, please let me know either in the comments of this post or in the Unity forum thread.

– Mike
While investigating potential lightmapping solutions for RedFrame, pharm we explored Unity’s own lightmapping system which leverages Autodesk’s Beast. Beast unfortunately is lacking a few more obscure features useful for simulating realistic artificial indoor lighting, viagra 40mg most notably photometric lights for reconstructing the unique banding patterns indicative of incandescent bulbs installed in housings. This prevents us from completely switching our workflow from Mental Ray to Beast, this though we’ll likely still use Beast for specific locations in the game that are favorable to Beast’s feature set.

Beast is a quite a full-featured lightmapping solution in itself, however Unity’s specific implementation of the tool favors simplicity over customization. Some very useful features are hidden away, and it’s not immediately obvious how to enable them. To give Beast a fair evaluation, I needed to enable these features.

Unity fortunately is able to accept Beast XML configuration files, opening up nearly the full potential of the system. There are a plethora of additional options recognized by Beast, but only a limited number are documented by Unity. After a bit of digital archaeology I was able to unearth documents that revealed the missing parts of the API.

I’ve created a Unity editor tool called Lightmapping Extended  that implements the full Beast XML specification and presents all available (and compatible) options in a user-friendly UI. I’ve released the code on GitHub, and will soon build a package for the Unity Asset Store:

Lightmapping Extended on GitHub

This tool unlocks a few key hidden features not available in Unity’s built-in Lightmapping settings window:

  • Image-Based Lighting – light a scene with an HDR skybox, mimicking realistic outdoor lighting
  • Path Tracer GI – a fast, multi-bounce lighting solution
  • Monte Carlo GI – a very slow but extremely accurate lighting solution

Keep an eye on the Lightmapping Extended thread on the Unity forum for future updates. If you run into any issues, please let me know either through the blog comments or the Unity forum thread. I’d like to make this the best and most complete solution for lightmapping inside of Unity.

– Mike
While investigating potential lightmapping solutions for RedFrame, pharm we explored Unity’s own lightmapping system which leverages Autodesk’s Beast. Beast unfortunately is lacking a few more obscure features useful for simulating realistic artificial indoor lighting, viagra 40mg most notably photometric lights for reconstructing the unique banding patterns indicative of incandescent bulbs installed in housings. This prevents us from completely switching our workflow from Mental Ray to Beast, this though we’ll likely still use Beast for specific locations in the game that are favorable to Beast’s feature set.

Beast is a quite a full-featured lightmapping solution in itself, however Unity’s specific implementation of the tool favors simplicity over customization. Some very useful features are hidden away, and it’s not immediately obvious how to enable them. To give Beast a fair evaluation, I needed to enable these features.

Unity fortunately is able to accept Beast XML configuration files, opening up nearly the full potential of the system. There are a plethora of additional options recognized by Beast, but only a limited number are documented by Unity. After a bit of digital archaeology I was able to unearth documents that revealed the missing parts of the API.

I’ve created a Unity editor tool called Lightmapping Extended  that implements the full Beast XML specification and presents all available (and compatible) options in a user-friendly UI. I’ve released the code on GitHub, and will soon build a package for the Unity Asset Store:

Lightmapping Extended on GitHub

This tool unlocks a few key hidden features not available in Unity’s built-in Lightmapping settings window:

  • Image-Based Lighting – light a scene with an HDR skybox, mimicking realistic outdoor lighting
  • Path Tracer GI – a fast, multi-bounce lighting solution
  • Monte Carlo GI – a very slow but extremely accurate lighting solution

Keep an eye on the Lightmapping Extended thread on the Unity forum for future updates. If you run into any issues, please let me know either through the blog comments or the Unity forum thread. I’d like to make this the best and most complete solution for lightmapping inside of Unity.

– Mike
One of the very first things we programmed on RedFrame was a player controller, skincare
the code that governs the way the player looks and walks.

Testing other engines:

Dear Esther
While investigating potential lightmapping solutions for RedFrame, pharm we explored Unity’s own lightmapping system which leverages Autodesk’s Beast. Beast unfortunately is lacking a few more obscure features useful for simulating realistic artificial indoor lighting, viagra 40mg most notably photometric lights for reconstructing the unique banding patterns indicative of incandescent bulbs installed in housings. This prevents us from completely switching our workflow from Mental Ray to Beast, this though we’ll likely still use Beast for specific locations in the game that are favorable to Beast’s feature set.

Beast is a quite a full-featured lightmapping solution in itself, however Unity’s specific implementation of the tool favors simplicity over customization. Some very useful features are hidden away, and it’s not immediately obvious how to enable them. To give Beast a fair evaluation, I needed to enable these features.

Unity fortunately is able to accept Beast XML configuration files, opening up nearly the full potential of the system. There are a plethora of additional options recognized by Beast, but only a limited number are documented by Unity. After a bit of digital archaeology I was able to unearth documents that revealed the missing parts of the API.

I’ve created a Unity editor tool called Lightmapping Extended  that implements the full Beast XML specification and presents all available (and compatible) options in a user-friendly UI. I’ve released the code on GitHub, and will soon build a package for the Unity Asset Store:

Lightmapping Extended on GitHub

This tool unlocks a few key hidden features not available in Unity’s built-in Lightmapping settings window:

  • Image-Based Lighting – light a scene with an HDR skybox, mimicking realistic outdoor lighting
  • Path Tracer GI – a fast, multi-bounce lighting solution
  • Monte Carlo GI – a very slow but extremely accurate lighting solution

Keep an eye on the Lightmapping Extended thread on the Unity forum for future updates. If you run into any issues, please let me know either through the blog comments or the Unity forum thread. I’d like to make this the best and most complete solution for lightmapping inside of Unity.

– Mike
One of the very first things we programmed on RedFrame was a player controller, skincare
the code that governs the way the player looks and walks.

Testing other engines:

Dear Esther
One of the very first things we programmed on RedFrame was a player controller, cough
the code that governs the way the player looks and walks.

Testing other engines:

Portal
Dear Esther
Far Cry 2
Far Cry 3

Using a spring system, view
benefits and drawbacks, prostate vs Smooth damping. Ease-out when hitting a wall.

Responsiveness vs floatiness.

Normalizing small movements while making large movements feel exact.

No need for precise aiming, so that is more forgiving when designing our system.

Need a ncie ac
One of the very first things we programmed on RedFrame was a player controller, practitioner the code that governs the way the player looks and walks.

Testing other engines:

Portal
Dear Esther
Far Cry 2
Far Cry 3

Using a spring system, benefits and drawbacks, vs Smooth damping. Ease-out when hitting a wall.

Responsiveness vs floatiness.

Normalizing small movements while making large movements feel exact.

No need for precise aiming, so that is more forgiving when designing our system.

Need a nice acceleration curve, but shouldn’t be able to spin around infinitely. Issue with spring system finding the shortest path and snapping backward.
Global state and behavior can be a bit tricky to handle in Unity. RedFrame includes a few low-level systems that must always be accessible, mind so a robust solution is required. While there is no single solution to the problem, prosthesis there is one particular approach that I’ve found most elegant. There are many reasons one might need global state: controlling menu logic, building additional engine code on top of Unity, executing coroutines that control simulations across level loads, and so on. By design, all code executed in Unity at runtime must be attached to GameObjects as script components, and GameObjects must exist in the hierarchy of a scene. There is no concept of low-level application code outside of the core Unity engine – there are only objects and their individual behaviors. The most common approach to implementing global managers in Unity is to create a prefab that has all manager scripts attached to it. You may have a music manager, an input manager, and dozens of other manager-like scripts stapled onto a single monolithic “GameManager” object. This prefab object would be included in the scene hierarchy in one of two ways:

  • Include the prefab in all scene files.
  • Include the prefab in the first scene, and call its DontDestroyOnLoad method during Awake, forcing it to survive future level loads.

Other scripts would then find references to these manager scripts during Start through one of a variety of built-in Unity methods, most notably FindWithTag and FindObjectOfType. You’d either find the game manager object in the scene and then drill down into its components to find individual manager scripts, or you’d scrape the entire scene to find manager scripts directly. A slightly more automated and potentially more performant option is to use singletons.

Singleton Pattern

The singleton design pattern facilitates global access to an object while ensuring that only one instance of the object ever exists at any one time. If an instance of the singleton doesn’t exist when it is referenced, it will be instantiated on demand. For most C# applications, this is fairly straightforward to implement. In the following code, the static Instance property may be used to access the global instance of the Singleton class:

C# Singleton

public class Singleton
{
static Singleton instance;

public static Singleton Instance {
get {
if (instance == null) {
instance = new Singleton ();
}
return instance;
}
}
}

Unity unfortunately adds some complication to this approach. All executable code must be attached to GameObjects, so not only must an instance of a singleton object always exist, but it must also exist someplace in the scene. The following Unity singleton implementation will ensure that the script is instantiated in the scene:

Unity Singleton

public class UnitySingleton : MonoBehaviour
{
static UnitySingleton instance;

public static UnitySingleton Instance {
get {
if (instance == null) {
instance = FindObjectOfType&lt;UnitySingleton&gt; ();
if (instance == null) {
GameObject obj = new GameObject ();
obj.hideFlags = HideFlags.HideAndDontSave;
instance = obj.AddComponent&lt;UnitySingleton&gt; ();
}
}
return instance;
}
}
}

The above implementation first searches for an instance of the UnitySingleton component in the scene if a reference doesn’t already exist. If it doesn’t find a UnitySingleton component, a hidden GameObject is created and a UnitySingleton component is attached to it. In the event that the UnitySingleton component or its parent GameObject is destroyed, the next call to UnitySingleton.Instance will instantiate a new GameObject and UnitySingleton component. For games that include many manager scripts, it can be a pain to copy and paste this boilerplate code into each new class. By leveraging C#’s support for generic classes, we can create a generic base class for all GameObject-based singletons to inherit from:

Generic Unity Singleton

public class UnitySingleton : MonoBehaviour
where T : Component
{
private static T instance;
public static T Instance {
get {
if (instance == null) {
instance = FindObjectOfType&lt;T&gt; ();
if (instance == null) {
GameObject obj = new GameObject ();
obj.hideFlags = HideFlags.HideAndDontSave;
instance = obj.AddComponent&lt;T&gt; ();
}
}
return instance;
}
}
}

A base class is generally unable to know about any of its sub-classes. This is very problematic when inheriting from a singleton base class – for the sake of example lets call one such sub-class “Manager“. The value of Manager.Instance would be a UnitySingleton object instead of its own sub-type, effectively hiding all of Manager‘s public members. By converting UnitySingleton to a generic class as seen above, we are able to change an inheriting class’s Instance from the base type to the inheriting type. When we declare our Manager class, we must pass its own type to UnityManager<T> as a generic parameter: public class Manager : UnitySingleton<Manager>. That’s it! Simply by inheriting from this special singleton class, we’ve turned Manager into a singleton. There is one remaining issue: persistence. As soon as a new scene is loaded, all singleton objects are destroyed. If these objects are responsible for maintaining state, that state will be lost. While a non-persistent Unity singleton works just fine in many cases, we need to have one additional singleton class in our toolbox:

Persistent Generic Unity Singleton

public class UnitySingletonPersistent : MonoBehaviour
where T : Component
{
private static T instance;
public static T Instance {
get {
if (instance == null) {
instance = FindObjectOfType&lt;T&gt; ();
if (instance == null) {
GameObject obj = new GameObject ();
obj.hideFlags = HideFlags.HideAndDontSave;
instance = obj.AddComponent&lt;T&gt; ();
}
}
return instance;
}
}

public virtual void Awake ()
{
DontDestroyOnLoad (this.gameObject);
if (instance == null) {
instance = this as T;
} else {
Destroy (gameObject);
}
}
}

The preceding code will create an object that persists between levels. Duplicate copies may be instantiated if the singleton had been embedded in multiple scenes, so this code will also destroy any additional copies it finds.

Caveats

There are a few important issues to be aware of with this approach to creating singletons in Unity:

Leaking Singleton Objects

If a MonoBehaviour references a singleton during its OnDestroy or OnDisable while running in the editor, the singleton object that was instantiated at runtime will leak into the scene when playback is stopped. OnDestroy and OnDisable are called by Unity when cleaning up the scene in an attempt to return the scene to its pre-playmode state. If a singleton object is destroyed before another scripts references it through its Instance property, the singleton object will be re-instantiated after Unity expected it to have been permanently destroyed. Unity will warn you of this in very clear language, so keep an eye out for it. One possible solution is to set a boolean flag during OnApplicationQuit that is used to conditionally bypass all singleton references included in OnDestroy and OnDisable.

Execution Order

The order in which objects have their Awake and Start methods called is not predictable by default. Persistent singletons are especially susceptible to execution ordering issues. If multiple copies of a singleton exist in the scene, one may destroy the other copies after those copies have had their Awake methods called. If game state is changed during Awake, this may cause unexpected behavior. As a general rule, Awake should only ever be used to set up the internal state of an object. Any external object communication should occur during Start. Persistent singletons require strict use of this convention.

Conclusion

While singletons are inherently awkward to implement in Unity, they’re often a necessary component of a complex game. Some games may require many dozens of manager scripts, so it makes sense to reduce the amount of duplicated code and standardize on a method for setting up, referencing, and tearing down these managers. A generic singleton base class is one such solution that has served us well, but it is by no means perfect. It is a design pattern that we will continue to iterate on, hopefully discovering solutions that more cleanly integrate with Unity.
Global state and behavior can be a bit tricky to handle in Unity. RedFrame includes a few low-level systems that must always be accessible, mind so a robust solution is required. While there is no single solution to the problem, prosthesis there is one particular approach that I’ve found most elegant. There are many reasons one might need global state: controlling menu logic, building additional engine code on top of Unity, executing coroutines that control simulations across level loads, and so on. By design, all code executed in Unity at runtime must be attached to GameObjects as script components, and GameObjects must exist in the hierarchy of a scene. There is no concept of low-level application code outside of the core Unity engine – there are only objects and their individual behaviors. The most common approach to implementing global managers in Unity is to create a prefab that has all manager scripts attached to it. You may have a music manager, an input manager, and dozens of other manager-like scripts stapled onto a single monolithic “GameManager” object. This prefab object would be included in the scene hierarchy in one of two ways:

  • Include the prefab in all scene files.
  • Include the prefab in the first scene, and call its DontDestroyOnLoad method during Awake, forcing it to survive future level loads.

Other scripts would then find references to these manager scripts during Start through one of a variety of built-in Unity methods, most notably FindWithTag and FindObjectOfType. You’d either find the game manager object in the scene and then drill down into its components to find individual manager scripts, or you’d scrape the entire scene to find manager scripts directly. A slightly more automated and potentially more performant option is to use singletons.

Singleton Pattern

The singleton design pattern facilitates global access to an object while ensuring that only one instance of the object ever exists at any one time. If an instance of the singleton doesn’t exist when it is referenced, it will be instantiated on demand. For most C# applications, this is fairly straightforward to implement. In the following code, the static Instance property may be used to access the global instance of the Singleton class:

C# Singleton

public class Singleton
{
static Singleton instance;

public static Singleton Instance {
get {
if (instance == null) {
instance = new Singleton ();
}
return instance;
}
}
}

Unity unfortunately adds some complication to this approach. All executable code must be attached to GameObjects, so not only must an instance of a singleton object always exist, but it must also exist someplace in the scene. The following Unity singleton implementation will ensure that the script is instantiated in the scene:

Unity Singleton

public class UnitySingleton : MonoBehaviour
{
static UnitySingleton instance;

public static UnitySingleton Instance {
get {
if (instance == null) {
instance = FindObjectOfType&lt;UnitySingleton&gt; ();
if (instance == null) {
GameObject obj = new GameObject ();
obj.hideFlags = HideFlags.HideAndDontSave;
instance = obj.AddComponent&lt;UnitySingleton&gt; ();
}
}
return instance;
}
}
}

The above implementation first searches for an instance of the UnitySingleton component in the scene if a reference doesn’t already exist. If it doesn’t find a UnitySingleton component, a hidden GameObject is created and a UnitySingleton component is attached to it. In the event that the UnitySingleton component or its parent GameObject is destroyed, the next call to UnitySingleton.Instance will instantiate a new GameObject and UnitySingleton component. For games that include many manager scripts, it can be a pain to copy and paste this boilerplate code into each new class. By leveraging C#’s support for generic classes, we can create a generic base class for all GameObject-based singletons to inherit from:

Generic Unity Singleton

public class UnitySingleton : MonoBehaviour
where T : Component
{
private static T instance;
public static T Instance {
get {
if (instance == null) {
instance = FindObjectOfType&lt;T&gt; ();
if (instance == null) {
GameObject obj = new GameObject ();
obj.hideFlags = HideFlags.HideAndDontSave;
instance = obj.AddComponent&lt;T&gt; ();
}
}
return instance;
}
}
}

A base class is generally unable to know about any of its sub-classes. This is very problematic when inheriting from a singleton base class – for the sake of example lets call one such sub-class “Manager“. The value of Manager.Instance would be a UnitySingleton object instead of its own sub-type, effectively hiding all of Manager‘s public members. By converting UnitySingleton to a generic class as seen above, we are able to change an inheriting class’s Instance from the base type to the inheriting type. When we declare our Manager class, we must pass its own type to UnityManager<T> as a generic parameter: public class Manager : UnitySingleton<Manager>. That’s it! Simply by inheriting from this special singleton class, we’ve turned Manager into a singleton. There is one remaining issue: persistence. As soon as a new scene is loaded, all singleton objects are destroyed. If these objects are responsible for maintaining state, that state will be lost. While a non-persistent Unity singleton works just fine in many cases, we need to have one additional singleton class in our toolbox:

Persistent Generic Unity Singleton

public class UnitySingletonPersistent : MonoBehaviour
where T : Component
{
private static T instance;
public static T Instance {
get {
if (instance == null) {
instance = FindObjectOfType&lt;T&gt; ();
if (instance == null) {
GameObject obj = new GameObject ();
obj.hideFlags = HideFlags.HideAndDontSave;
instance = obj.AddComponent&lt;T&gt; ();
}
}
return instance;
}
}

public virtual void Awake ()
{
DontDestroyOnLoad (this.gameObject);
if (instance == null) {
instance = this as T;
} else {
Destroy (gameObject);
}
}
}

The preceding code will create an object that persists between levels. Duplicate copies may be instantiated if the singleton had been embedded in multiple scenes, so this code will also destroy any additional copies it finds.

Caveats

There are a few important issues to be aware of with this approach to creating singletons in Unity:

Leaking Singleton Objects

If a MonoBehaviour references a singleton during its OnDestroy or OnDisable while running in the editor, the singleton object that was instantiated at runtime will leak into the scene when playback is stopped. OnDestroy and OnDisable are called by Unity when cleaning up the scene in an attempt to return the scene to its pre-playmode state. If a singleton object is destroyed before another scripts references it through its Instance property, the singleton object will be re-instantiated after Unity expected it to have been permanently destroyed. Unity will warn you of this in very clear language, so keep an eye out for it. One possible solution is to set a boolean flag during OnApplicationQuit that is used to conditionally bypass all singleton references included in OnDestroy and OnDisable.

Execution Order

The order in which objects have their Awake and Start methods called is not predictable by default. Persistent singletons are especially susceptible to execution ordering issues. If multiple copies of a singleton exist in the scene, one may destroy the other copies after those copies have had their Awake methods called. If game state is changed during Awake, this may cause unexpected behavior. As a general rule, Awake should only ever be used to set up the internal state of an object. Any external object communication should occur during Start. Persistent singletons require strict use of this convention.

Conclusion

While singletons are inherently awkward to implement in Unity, they’re often a necessary component of a complex game. Some games may require many dozens of manager scripts, so it makes sense to reduce the amount of duplicated code and standardize on a method for setting up, referencing, and tearing down these managers. A generic singleton base class is one such solution that has served us well, but it is by no means perfect. It is a design pattern that we will continue to iterate on, hopefully discovering solutions that more cleanly integrate with Unity.
Global state can be a bit tricky to handle in Unity. All executing code must be attached to GameObjects as components, apoplectic
and GameObjects must exist in the hierarchy of a scene. There is no concept of low-level application code – there are only objects and their behaviors.

The most common method for implementing global managers in Unity is to create a prefab object that contains all manager components attached to it. This prefab is either included in each scene file, viagra 40mg
or if state must be persisted between levels, food
it is added to an initial bootloader scene that loads the prefab and calls its DontDestroyOnLoad method forcing it to survive future level loads. Other scripts grab references to these managers through one of a variety of built-in methods, such as FindWithTag, FindObjectOfType.
Global state can be a bit tricky to handle in Unity. All executing code must be attached to GameObjects as components, medic and GameObjects must exist in the hierarchy of a scene. There is no concept of low-level application code – there are only objects and their behaviors.

The most common method for implementing global managers in Unity is to create a prefab object that contains all manager components attached to it. This prefab is either included in each scene file, troche or if state must be persisted between levels, symptoms it is added to an initial bootloader scene that loads the prefab and calls its DontDestroyOnLoad method forcing it to survive future level loads. Other scripts grab references to these managers through one of a variety of built-in methods, such as FindWithTag and FindObjectOfType.

A slightly more automated and possibly more performant option is to use singletons.

Singleton Implementation

The singleton design pattern allows global access to an object, while ensuring that only one instance of it’s type is ever allowed to exist at any one time. If a singleton object exists, all references will point to this one object. If an object doesn’t exist, it will first be created. For most C# applications, this is fairly straightforward to implement:

[CODE]

In the above code, a static _______ [explain what it’s doing]

Unity unfortunately adds quite a bit of complication to this approach. All executable code must be attached to GameObjects, so not only must an instance of a singleton object always exist, but it must also exist someplace in the scene.

[singleton implementation that works with Unity]

[making things easier by creating a generic class that breaks polymorphism]

OnDisable

Leaking objects.
Global state and behavior can be a bit tricky to handle in Unity. There are many reasons for needing this: controlling menu logic, sick _____ execute coroutines separate from objects in the scene _____. All executing code must be attached to GameObjects as components, and GameObjects must exist in the hierarchy of a scene. There is no concept of low-level application code – there are only objects and their behaviors.

The most common method for implementing global managers in Unity is to create a prefab object that contains all manager components attached to it. This prefab is either included in each scene file, or if state must be persisted between levels, it is added to an initial bootloader scene that loads the prefab and calls its DontDestroyOnLoad method forcing it to survive future level loads. Other scripts grab references to these managers through one of a variety of built-in methods, such as FindWithTag and FindObjectOfType.

A slightly more automated and possibly more performant option is to use singletons.

Singleton Implementation

The singleton design pattern allows global access to an object, while ensuring that only one instance of it’s type is ever allowed to exist at any one time. If a singleton object exists, all references will point to this one object. If an object doesn’t exist, it will first be created. For most C# applications, this is fairly straightforward to implement:

[CODE]

In the above code, a static _______ [explain what it’s doing]

Unity unfortunately adds quite a bit of complication to this approach. All executable code must be attached to GameObjects, so not only must an instance of a singleton object always exist, but it must also exist someplace in the scene.

[singleton implementation that works with Unity]

[making things easier by creating a generic class that breaks polymorphism]

Enabling the base class to know something about its sub-classes.

 

OnDisable

Leaking objects.
poolFor anyone who doesn’t know, dosage we’re building RedFrame using the Unity game engine. Unity is a wonderful tool with many features that make it appealing for indie development, viagra including the ability to deploy to multiple operating systems as well as an amazingly simple asset pipeline.

The folks at Unity were kind enough to feature our game on their site, and we recommend checking it out if you want to get a little more background on the project. We have been a bit tight-lipped so far and hopefully this is a good introduction to who we are and what we would like to accomplish with RedFrame. Check out the article!
For the last few months, bronchitis a friend of mine from work, viagra sale Oliver Barraza, angina has been working on his game, The King’s Shroud for OUYA. Like our project, it is being developed in Unity. He describes the game as follows:

“The King’s Shroud is a story based Tactical Action Role-Playing Game designed to give more freedom without sacrificing the elements of strategy and control which players have come to expect from the TRPG genre. Featuring a limb-based damage system and our unique Targeting Arc, players engage in combat with complete control over the weapon’s swing arcs, carefully evaluating situations and positioning strikes for the most damage. King’s Shroud brings a new level of strategy to the already fantastic TRPG genre.”

His blog is updated very regularly, which gives a nice window into his learning process as well as the evolution of the project.  Recently he’s switched form Javascript to C# and his post about the transition illustrates the language differences in a very clear way. The concept of the game is also really unique yet at the same time has a scope that is realistic for a small indie effort. I enjoy talking to Oliver about game design/programing at work and we’ve learned a lot from each other. I’ve seen his ideas evolve very quickly in a short time period and I recommend checking out his blog!

-Andrew

SalomeSketches ScreenShot01 ScreenShot02

 

Posted in Uncategorized

Advanced lightmapping in Unity

http://redframe-game.com/wp/uploads/2012/12/copy-Header.png
http://redframe-game.com/wp/uploads/2012/12/copy-Header.png
RedFrame is an exploratory adventure game created by the game development duo, glands
no rx Andrew Coggeshall and Michael Stevenson of Basenji Games.
http://redframe-game.com/wp/uploads/2012/12/copy-Header.png
RedFrame is an exploratory adventure game created by the game development duo, glands
no rx Andrew Coggeshall and Michael Stevenson of Basenji Games.
RedFrame is an exploratory adventure game created by the game development duo, drugstore
Andrew Coggeshall and Michael Stevenson of Basenji Games.
While investigating potential lightmapping solutions for RedFrame, tadalafil we explored Unity’s own lightmapping system which leverages Autodesk’s Beast. Beast unfortunately is lacking a few more obscure features useful for simulating realistic artificial indoor lighting, more about most notably photometric lights for reconstructing the unique banding patterns indicative of incandescent bulbs installed in housings. This prevents us from completely switching our workflow from Mental Ray to Beast, though we’ll likely still use Beast for specific locations in the game that are favorable to Beast’s feature set.

Beast is a quite a full-featured lightmapping solution in itself, however Unity’s specific implementation of the tool favors simplicity over customization. Some very useful features are hidden away, and it’s not immediately obvious how to enable them. To give Beast a fair evaluation, I needed to access them.

Unity fortunately is able to accept Beast XML configuration files, opening up nearly the full potential of the system. There are a plethora of additional options recognized by Beast, but only a limited number are documented by Unity. After a bit of digital archaeology I was able to unearth documents that revealed the missing parts of the API.

I’ve created a Unity editor tool called Lightmapping Extended  that implements the full Beast XML specification and presents all available (and compatible) options in a user-friendly UI. It’s available both from the Unity Asset Store and GitHub:

Download Lightmapping Extended on the Unity Asset Store

Download source code from GitHub

This tool unlocks a few key hidden features not available in Unity’s built-in Lightmapping settings window:

  • Image-Based Lighting – light a scene with an HDR skybox, mimicking realistic outdoor lighting
  • Path Tracer GI – a fast, multi-bounce lighting solution
  • Monte Carlo GI – a very slow but extremely accurate lighting solution

Keep an eye on the Lightmapping Extended thread on the Unity forum for future updates. If you run into any issues, please let me know either through the blog comments or the Unity forum thread. I’d like to make this the best and most complete solution for lightmapping inside of Unity.

– Mike

Posted in Uncategorized

Poly Reduction Prioritization

I recently published a tool for Unity that exposes additional settings for Unit
The central environment in RedFrame is a large mansion. While developing the 3d model of the house I didn’t pay much attention to its total resolution; I wanted to see how far I could push mid-range hardware and didn’t want the design of the environment to be influenced by technical considerations. To our delight the house runs completely smoothly on an ATI Radeon HD 5770 with a gig of video memory. Although this video card is no slouch, try it’s also not a high-end gaming GPU.

The resolution of the house model was originally 1, for sale 371,298 vertices. We’re going to expand the environment quite a bit and will need to keep the game playable on as many systems as possible, so I’ve started the process of reducing the resolution of the Maya model as much as possible without negatively affecting the way it’s perceived by the player. I realized that a lot of our detail was unnecessary; some of the tight detail even detracted from the image by causing flickering when anti-aliasing was disabled.

The scene is quite large, so prioritizing my time is a little difficult. My first thought was just to go through each room looking for objects that are more detailed that they need to be, but this is somewhat arbitrary. My second technique has been to print a list of all objects in the scene and then order them by how much resolution they have. It is still arbitrary in a sense, but it has been a nice weapon with which to attack the problem.

Because I’m more comfortable programing in Unity than in MEL, I wrote a C# script to sort models by resolution. It’s my first time using Linq, which I still need to wrap my head around. You can download the script here – just import your model into Unity, drop it into a new scene, and attach the script to the model’s root game object.

-Andrew

Posted in Uncategorized

Lightmap Workflow, Part 1: UV Generation

RedFrame is an exploratory adventure game in production by Andrew Coggeshall and Michael Stevenson. We’ve been working on RedFrame in our spare time for more than two years, stuff but until now we’ve largely kept our work under wraps. We’d like to begin sharing with you what we’ve accomplished so far, order and what still lies ahead as we continue crafting the world of RedFrame.

Through this blog we’ll be highlighting major aspects of development, giving you a peek into our process. This blog will be written from a technical perspective and will be spoiler free. If you have any questions or comments, feel free to contact us directly: michael at basenjigames.com (programming) and andrew at basenjigames.com (art).

Thanks, and we hope you enjoy!

– Mike & Andrew
RedFrame is an exploratory adventure game in production by Andrew Coggeshall and Michael Stevenson. We’ve been working on RedFrame in our spare time for more than two years, health system but until now we’ve largely kept our work under wraps. We’d like to begin sharing with you what we’ve accomplished so far, here and what still lies ahead as we continue crafting the world of RedFrame.

Through this blog we’ll be highlighting major aspects of development, doctor giving you a peek into our process. This blog will be written from a technical perspective and will be spoiler free. If you have any questions or comments, feel free to contact us directly: michael at basenjigames.com (programming) and andrew at basenjigames.com (art).

Thanks, and we hope you enjoy!

– Mike & Andrew
RedFrame’s lighting tends to look a bit different than most games. We achieve this unique look by generating most lighting externally using techniques inspired by pre-rendered architectural visualization. We set up and bake our lighting in Maya and Mental Ray rather than leveraging Unity’s built-in lightmap rendering tools.

Our current workflow is a three-step process: generate lightmap UVs, case bake direct and/or indirect lighting, hospital and import the resulting lightmap images into Unity’s existing lightmap system. In Part 1 in our series on lightmapping we’ll explore the process of generating lightmap UVs.

Approach

Unity includes an automatic lightmap UV generation tool. This is a one-way process, and it would be impractical to transfer these UVs back into Maya. Regardless of this limitation, we take a philosophically different approach in our workflow. Where Unity embraces automated simplicity, we’ve chosen manual control. Our workflow produces two important advantages for us: it creates model files that contain intrinsic lightmap UVs that may be used by other applications and engines, and it offers deep control over how objects are divided at a face level which can produce higher quality results with fewer visual artifacts.

Mesh Grouping

We begin our process of building lightmap UVs by merging environmental geometry into localized groups. The objects in each group will all share the same lightmap texture. Each of these groups are about a quarter the size of a room.

To optimize the use of texture memory in Unity, we don’t want to generate lightmaps for every individual piece of geometry. Separate objects are able to share a single lightmap provided that none of their UVs overlap. To ensure that the objects share a unique UV space, we temporarily merge every object within a group into a single mesh.

Manual UV Layout

Once we have a single mesh for a group of objects, we first must create a new UV set for the mesh. We will want have individual control over the UV layout for both the color and light maps – the second UV set will be used for lightmapping.

In the newly created UV channel, run an automatic UV generation in Maya. This is done by selecting Create UVs -> Automatic Mapping from the polygon menus. The UV map that is generated is usually fairly efficient but it can be compacted further by cutting UV edges that form right angles and then running a Layout operation.

In this image, the areas circled are spots where it would be a good idea to cut UV edges:

Manually separating UV shells for smooth objects with hard corners such as crown molding, or softer organic shapes such as upholstered furniture, can also minimize artifacts in lightmaps. Artifacts can be further reduced by tweaking the position of individual vertices as needed.

Mesh Breakup

Once the mesh containing a group of objects has had its UVs efficiently laid out, we break the mesh into smaller pieces so that they can be culled by Unity via frustum culling and occlusion culling. The most sensible way we’ve found to re-divide each group mesh is by material. We wrote a MEL script to automatically do this, and we’ve made it available here.

This script will separate a mesh into pieces based on its materials, and will place each piece into a group node containing all meshes that share the same lightmap UV space. The script is a little ad-hoc and will break if one of the contained materials is the default material. Any suggestions on how we might improve the script are welcome.

Unity Import

Unity uses two UV channels per mesh, the first for displaying color maps and the second for lightmaps. When importing a model, Unity will automatically read the mesh’s second UV channel. Be certain to disable “generate lightmap UVs” in the model’s asset import settings, otherwise Unity will overwrite the UVs that were manually laid out in Maya.

Check out the next part in our series: Lightmap Workflow, Part 2: Architectural Lighting

Tagged with:
Posted in Uncategorized

Welcome to the RedFrame Development Blog

We do all of our light baking for RedFrame on a beefy Mac Pro, viagra approved but due to limitations in Maya and Mental Ray we have to run multiple instances in order to saturate the available processor cores.

On Windows it’s very simple to run multiple instances of a single application – this is the default behavior – but we work on OS X which only allows one instance of an app to be running at any given time. We’ve commonly used a messy workaround: duplicating the application on disk and keeping references to its many copies in the Dock.

Today I discovered a much better solution. It’s possible to open an unlimited number of instances of an app through the terminal. To instantiate Maya 2012*, bronchitis I just execute the following command:

open -n /Applications/Autodesk/maya2012/Maya.app

Using Platypus, I bundled this command into an application that sits in the Dock, ready to spawn additional Maya instances on demand.

You can download my Maya 2012 Instantiator here.

Maya Instances

* Why not Maya 2013? Well, 2013 crashes every single time we’ve tried to bake lightmaps preventing us from being able to upgrade.
RedFrame is an exploratory adventure game in production by Andrew Coggeshall and Michael Stevenson. We’ve been working on RedFrame in our spare time for more than two years, sick but until now we’ve largely kept our work under wraps. We’d like to begin sharing with you what we’ve accomplished so far, capsule and what still lies ahead as we continue crafting the world of RedFrame.

Through this blog we’ll be highlighting major aspects of development, there giving you a peek into our process. This blog will be written from a technical perspective and will be spoiler free. If you have any questions or comments, feel free to contact us directly: michael at basenjigames.com (programming) and andrew at basenjigames.com (art).

Thanks, and we hope you enjoy!

– Mike & Andrew

Posted in Uncategorized

Posted in Uncategorized