Please Be Advised

I would love to provide an insightful response to all messages received, the reality is that it just isn't possible given time constraints and personal goals.  



123 Street Avenue, City Town, 99999

(123) 555-6789


You can set your address, phone number, email and site description in the settings tab.
Link to read me page with more information.

banner_blog_brig.png Blog

The official blog of, features in-depth tutorials and essential knowledge for artists and designers. The blog aims to go one step further than other sites by explaining the why just as often as the how in order to build our audience's fundamental foundations of art & design and prepare them for additive knowledge.

Let's Get Physical: Part 3 of 3

Jeremy R

Unity Asset Package & Resources

As a thank you to readers I have assembled a free Unity Asset Package which includes all 10 materials showcased in this guide, their supporting maps, and a demo scene for your perusal.  If you have a suggestion for this guide please don't hesitate to leave a comment or submit a message via the contact form.  Thanks for reading!

asset package contents

Note:  Asset package requires Unity 5.x or greater!

PBR RESources

PBR GUIDE   // Allegorithmic

PBR GUIDE // Allegorithmic

PBR IN PRACTICE // Marmoset Toolbag

PBR Guide [Allegorithmic]

The creators of the awesome Substance Designer and Substance Painter applications have compiled a very comprehensive guide to PBR theory.  Follow the link for Volume 1 and Volume 2 in downloadable PDF format.  Read More

Calibration Chart // Unity

Working with Physically-Based Shading: A Practical Approach

Unity's official write-up on working with their default PBR solution(s).  Article contains useful calibration charts for both Metalness and Specular pipelines.  Read More

PBR IN PRACTICE [Marmoset toolbag]

Another excellent PBR resource from the creators of Marmoset Toolbag 2.  Easy read for all knowledge levels, includes theory and practice tutorials, highly recommend for PBR beginners. Read More

Part 0 of 3

Want to know why Physically Based Rendering is becoming the new standard? Start here!

Part 1 of 3

Unfamiliar with PBR?  This introduction and summary of the technology  will get you up to speed on the basics of PBR.

Part 2 of 3

Familiar with PBR and ready to start authoring your own physically based materials in Unity 5?  Start Here!

Have a suggestion?  Leave a comment or use the contact form to send a message!

Let's Get Physical: Part 2 of 3

Jeremy R

Unity PBR Tutorial

The ability to differentiate [and isolate] specific surface details, and then correctly identify which surface map should contain those details, is the key to producing physically accurate results, consistently.

Let's Get Metal!

So, now that you've (hopefully) read the Introduction to Physically Based Rendering and have a Basic Understanding of the Metalness Approach to PBR, it's time to put it to practice!  We'll be breaking down the construction of a Chesterfield Sofa material.  This is a particularly good case-study for the Metalness approach to PBR as it has clearly defined transitions between metal (Brass Buttons) and non-metal (Tufted Leather) surfaces. 

It’s worth noting Unity’s Standard Shader didn’t always use the Metalness approach, in fact during the Unity 5 beta many artists were shocked to find the Specular approach was the default (and only) PBR model built-in to Unity 5. It wasn’t until artists banded together in the Unity community and brought the issue to the forefront that Unity not only included a Metalness option, but also defaulted to it.


Chesterfield Before Chesterfield After



In PBR, Normal Maps serve to provide directional lighting information for Macro surface details which (for one reason or another) don't merit the overhead of additional geometry.

Macro-Surface Details  

  • Folds / Wrinkles / Veins
  • Seams / Stitching / Weave
  • Bolts / Panels / Greebles
  • Deep Pitting, Deep Scratches
  • Protrusions / Extrusions / etc. 

Micro-Surface Details

  • Scuffs / Abrasions / Wear & Tear
  • Material Tension / Stretching
  • Perspiration / Water / Condensation
  • Glass / Frosted Glass
  • Smoothness / Roughness

Micro-Surface Details, as the name implies, are far subtler surface details which, until recently, were usually found in the Specular Map, or sometimes the Normal Map.  An example of this would be adding a noise filter to your Normal Map to simulate a "rough" surface.  As we'll see below, this is a no longer a good idea -- in fact it's a terrible idea unless you're literally authoring a 40-grit sandpaper material.

Tactile descriptors like smooth, wet, gritty, worn, and rough are all considered micro-surface details which don't merit additional normal information.  These micro-surface details are best realized in the Smoothness Map. (We'll go into detail about the Smoothness Map below.)

White Albedo // 50% Smoothness // Normal Map  //  CLICK FOR FULL SIZE

Authoring Normal Maps

You'll want to remove unnecessary noise as much as possible from your Normal Maps and focus your efforts on defining distinct shapes and forms.  This is especially important when transitioning to (or from) a metal/non-metal surface due to the (obvious) disparity in surface properties.  

Photo-Normal Conversion

Applications like Substance Designer, Crazy Bump, and Quixel's nDo still have a place in a PBR pipeline, make no mistake. Many artists (self-included) enjoy the efficiency of generating normal data from their preferred bitmap-to-normal converter.  One of the drawbacks of this process is the increased likelihood of finding artifacts and noise in the generated normals. To remedy this, try reducing the contrast of the photo reference, adjust output curves*, gamma and/or exposure as necessary in order to prepare the photo for a clean conversion.

* If you're using level adjustments rather than curve adjustments, the time is now to adopt a curves-based workflow.  Level adjustments have the propensity to break the histogram, especially when clamping down the global value range.


Metalness Map  //  CLICK FOR FULL SIZE

The Metalness Map serves to mask the areas of UV space which represent metallic surfaces (white) and everything else (black).

The Metalness Map, like the Smoothness Map and Ambient Occlusion Map, is stored in a single-channel (i.e. grayscale image).  Leveraging this information allows us to create a composite texture, also known as a Pack Map, which contains all three maps in a single file.  Efficiency!

In the case of Unity's Standard Shader, the Metalness values are stored in the Red Channel, while the Smoothness values are stored in the Alpha Channel, and Ambient Occlusion in the Green Channel.  Well what about the Blue Channel?  By default, Unity leaves the Blue Channel open for custom shader functions.

(We will take an in-depth look at the compositing process near the end of this article.)

White Albedo // 50% Smoothness // Normal Map // Metalness Map  //  CLICK FOR FULL SIZE should always author your Metalness Map with a value of 0 or 255 - nothing in between!

Authoring Metalness Maps

Since there are no known materials in the physical world which mimic the surface properties of both metals and non-metals, you should always author your metalness map with a value of 0 OR 255 - and nothing in between!   Note: Metal surfaces covered in a thin film of dust/dirt are the exception to the rule.

One could certainly argue the fact digital artists aren’t constrained by reality, and thus should author Metalness Maps at our own discretion, but [generally speaking] a grayscale laden Metalness Map just doesn’t retain fidelity under scrutiny, nor does it take advantage of the shader's inherent behavior.

With great power comes great responsibility.
— Uncle Ben [Parker]


Smoothness Map  //  CLICK FOR FULL SIZE

Upon adopting a PBR pipeline it is often the Smoothness Map which gives artists a difficult time.  But it is also the most enjoyable to author!   Why is that?

Well for starters, the Smoothness Map has the great responsibility of approximating all the subtle, nuanced characteristics which light energy exhibits upon interacting with a (micro)surface.  Whether it's as smooth as a cue ball or rough as chalk, it can be approximated with this single channel.

As mentioned in Let's Get Physical Part 1, there are "countless" possibilities between the roughest surface (0) and the smoothest surface (255).  Now obviously 256 degrees of interpolation is a far cry from being considered countless, but the spectrum of surface characteristics represented by each degree is substantial; so much so that even small deviations from physical reality can be realized at run time by the average pair of eyes.

As rendering fidelity approaches physical-accuracy humans are increasingly sensitive to the (often small) disparities between what is and isn't consistent within a [virtual]  environment. As members of the human race we have the remarkable ability to perceive and immediately identify visual novelties, regardless of art style or fidelity goals.  (e.g. photo-realism vs. stylized)

Uniform 50% Smoothness Value Custom Smoothness Values
Our sensitivity to novelty is born from repeated exposure to what was [at one point or another] also novel. We can then assume immersion is a product of consistency.


Our sensitivity to novelty is born from repeated exposure to what was [at one point or another] also novel.  We can then assume immersion is a product of consistency. 

Similar in nature to Texel Density, Smoothness values rely upon calculated consistency from all contributing artists.  Whether you're an indie developer or a AAA studio, teams of all sizes would greatly benefit from a Smoothness Calibration Chart for the referencing of common project materials (e.g. plastic, wood, skin).  

Of course, you can choose to author a rubber tire with a smoothness value of 100% (which who knows, might be the perfect look for your kart-racing game) but you should plan on maintaining that smoothness value across all rubber surfaces, or your project may run the risk of contracting a case of appending disbelief.  

Unity 5 Calibration Scene

Unity 5 Calibration Scene

The Unity 5 Calibration Scene

When it comes to authoring the Smoothness Map, you'll want to make sure you have a "Calibration Scene" running in Unity to test your maps against varying lighting conditions.  Unity very generously released a "Calibration Scene" Asset Package for this very purpose, Available for Free Download on the Asset Store.  


Before you even begin authoring the Smoothness Map, stop and take a moment to think... Try to mentally simulate how that surface feels to touch in the physical world, and then try to replicate that visual-tactile sensation on the screen.  Trial and error is no doubt part of the PBR learning curve, but I find this visualization process to be helpful if (and when) uncertainties arise.



To fully appreciate the role of the Occlusion Map we'll be removing the (secondary) fill light to reveal the indirectly illuminated surface (on the right side of the cube).  We must do this because the Occlusion Map's behavior is only visible when the intensity of indirect illumination exceeds that of direct illumination. (i.e. The surface is in shadow, to some degree.)

(Note: Indirect lighting data comes from reflections and Global Illumination, baked or realtime.)

Absent AO Map Good AO Map

Authoring the Occlusion accurately isn't especially difficult, however, it is imperative to test your Occlusion maps against multiple lighting conditions.  Failing to do so may reveal some rather ugly results!

 Occlusion information is revealed as Direct Illumination falls off the curved surface.

ABOVE:  Spherical surface demonstrating the falloff of direct illumination and subsequent transition to indirect lighting information.  The spheres' material is as follows: Albedo value of 255,255,255 (white), 0% Metalness value (black), with a 0% Smoothness value (black).  The only supporting map is a binary checkerboard texture found in the Occlusion map slot.

It’s important to reserve the darkest of occlusion values for only the most obscured and finest of details.
Occlusion On Occlusion Off

ABOVE:  A 100% black Occlusion value tells Unity's lighting engine (Enlighten) that the surface is completely obscured from receiving indirect lighting information, rendering it completely unlit (pitch black, in most cases).  While the inverse Occlusion value (0%, white) tells Enlighten to render all available indirect lighting information.  It's important to reserve the darkest of occlusion values for only the most obscured and finest of details. 

There is little room for negotiation — if your project isn’t leveraging Pack Maps to the fullest extent possible — you’re leaving performance gains on the table.

The Pack Map


The term Pack Map describes a composite image which contains multiple single-sample (i.e. grayscale) texture maps, each of which is isolated to a unique color channel. (i.e. Red, Green, Blue or the Alpha channel.)

A physically-based material which neglects to leverage a Pack Map (opting for multiple image files, instead) will unnecessarily bloat the memory overhead of the material, as much as 400% in some cases, even more if additional maps are in-play (e.g. detail maps, alpha masks, emissive maps, etc.)

Packing multiple texture maps in a single image file is not a new practice by any means, but it didn't become a crucial step-in-the-process of Unity-based art pipelines until physically based rendering became the standard.  This is in large part due to the additional maps required for PBR materials -- there is little room for negotiation on this matter -- if your project isn't leveraging Pack Maps to the fullest extent possible, you're leaving performance gains on the table.

So, now that you're (hopefully) sold on the idea of Pack Maps, you'd probably expect just about every art team to be on the Pack Map train, right?  Well, that hasn't been my experience, actually.  In fact, since the 2014 Unity 5 beta I've worked on half a dozen Unity 5 projects, half of which were well funded, and to my surprise only one of those projects was leveraging Pack Maps when I came on-board.  This is of course only my personal experience, but it was from those experiences, in fact, which inspired me to write this guide.

Standard Shader Channel Assignments

Channel Assignments for Unity 5 Standard Shader

Authoring pack maps in photoshop

Above all else, it is recommended that you author all supporting maps (i.e. Metalness, Smoothness, Occlusion) in a separate (PSD) master file!   In order to ensure a compatible export, you must export with:

  • No Layers / Flattened (Background layer w/ Lock icon)
  • TIFF or TGA (PNG's aren't compatible)
  • Alpha Channel (Must be included in export options)

Working directly within the Pack Map file (rather than from a separate master file) runs the risk of losing work and/or exporting the image in an incompatible format.  When you are ready to create your Pack Map, simply copy one of the maps from the PSD master file (CTRL+SHIFT+C to copy merged) then create a new file (CTRL+N).  

Pack Map Channels in Photoshop

By default, Photoshop will retain the dimensions of the clipboard data you just copied (e.g. 1024x1024).  Additionally your Background Contents should be set to White or Background Color, never Transparent.  (Attempting to compile a Pack Map from a file with a transparent background will add at least 2 additional steps.)

Click OK to create the new Pack Map file with the correct dimensions and opaque background contents. (top right)

Don't paste your map just yet!  First you must select the appropriate channel from the Channels window. (right) 

For example, you  would select the Red Channel if you're in the process of pasting the Metalness Map into your Pack Map.  Once you select the correct channel from the Channels Window and Paste (Ctrl+V) your map data from the clipboard, you're all set!  Rinse and repeat for the remaining map channels.

Albedo Map


Above: Saturation & Brightness physically-correct sweet-spot. Note: The values correlate to Dielectric/Insulator/Non-Metal surfaces.

Part 0 of 3

Want to know why Physically Based Rendering is becoming the new standard? Start here!

Part 1 of 3

Unfamiliar with PBR?  This introduction and summary of the technology  will get you up to speed on the basics of PBR.

Part 3 of 3 

Looking for examples? Additional resources and a downloadable asset package featuring 10 materials here.

Let's Get Physical: Part 1 of 3

Jeremy R

PBR in theory

The physical laws of the universe govern the appearance of everything in our third dimensional lives; PBR simply aims to reproduce nature by approximating the real world [physically-based] magnitude [intensity] and wavelength [color] of energy [light] present upon entering and exiting a given material’s surface properties. 

Simply put, the PBR tidal wave has been swelling for a long time, but the computational power necessary for physically-based rendering didn’t brush shoulders with real-time rendering capabilities, en masse, until recent years.

Why is the industry shifting towards PBR?

The visual fidelity of physically based rendering is second-to-none, and always has been.  In fact if you're familiar with VRay you're already acquainted with a physically based renderer.  As such, PBR is nothing to call home about, but until recently its applications were limited to 3D visuals of the pre-rendered variety (e.g. Pixar movies).  Simply put, the PBR tidal wave has been swelling for a long time, but the computational power necessary for physically-based rendering didn't brush shoulders with real-time rendering capabilities, en masse, until recent years.

What makes something physically-based?

In order for something to be considered "physically-based" it must approximate the laws of physics, and more specifically the behavior of light.  For example, all PBR shaders limit the amount of light leaving an object's surface to ensure it is never greater than the light which fell upon it originally. (This is known as the law of Energy Conservation.)  The physical laws of the universe govern the appearance of everything in our third dimensional lives; PBR simply aims to reproduce nature by approximating the real world [physically-based] magnitude [intensity] and wavelength [color] of energy [light] present upon entering and exiting a given material’s surface properties.  

If it sounds complicated, hang in there, it’s surprisingly simple in practice. 

— up close or from afar, realistic or stylized — without micro-surface details your scene will suffer from the aesthetic disorder known as Appending Disbelief! ...Sounds serious if you ask me.

What are Micro-Surface Details?

Micro-Surface Details (i.e. Smoothness/Roughness Maps) are one of the new additions to next-gen art pipelines.  Micro-surfaces are exactly what they sound like; the sheen of silk, the microscopic pitting of brick, the gloss of marble -- all micro-surfaces which can be mimicked by assigning a value between 0 (black) and 255 (white). The floor [0] and ceiling [255] describe whether a surface is as rough as physically-possible [0% Smoothness] or as smooth as physically possible [0% Roughness].*  

Smoothness Chart Unity 5 // Click for Full Size

These micro-surface details are rarely noticed by the average pair of eyes,  and most often it's the non-metal objects' surfaces we realize (e.g. wood, fabric, plastic).  This is because non-metals have a low index of reflectivity, which means light energy is much more prone to diffusion, rather than reflection.  Metals on the other hand have a high index of reflectivity, diffuse less light, and absorb certain wavelengths of light (i.e. Albedo) which make their surface details much more difficult to discern under "average" lighting conditions. 

Regardless of application these (micro)surface details are absolutely vital for creating the illusion of a world you can "reach out and touch" -- whether up close or from afar, realistic or stylized -- without micro-surface details your scene will suffer from the aesthetic disorder known as Appending Disbelief!  -gasp-  ...Sounds serious if you ask me.

*You'll find different values represent the floor [0] and ceiling [255] depending on what shader framework you're using. This is because shaders are written both ways -- some choose 255 to represent 100% roughness while others choose 255 to represent 100% smoothness. It's all a big mess really, and only adds to the difficulty of learning a new technology. In fact this is the prevailing reason there isn't a majority-ruled name for the roughness/smoothness map-slot found in PBR shaders.

A good rule of thumb -- the shader framework will use the maximum value to determine the map name. e.g. Unity's Standard Shader uses 255 for 100% smoothness, as such the Standard Shader has a Smoothness map-slot in the shader, rather than a Roughness map slot which many other frameworks use. Your mileage may vary.

I’m telling you this is the end for texture artists! PBR is going to turn us all into a bunch of monkeys punching predetermined values into one of these new fangled material generating machines. And watch, they’ll probably keep the machines in the basement.
— Anonymous Texture Artist

One shader to rule them all

Additionally, PBR reduces the number of special-case shaders necessary for a given scene.  In the past, realtime renderers relied upon a myriad of highly optimized [special case] shaders in order to emulate the physical world on a per-object basis:  An emissive shader for glowing objects, an additive shader for particles, a cutout shader for foliage, a refractive shader for glass, a refractive shader with displacement for water, a cubemap shader for.... you get the picture. 

How is this problematic?

Additional shaders == additional draw-calls!  Why are draw-calls important?  Well it is the number of draw-calls on the processor which is the single most delimiting factor [rendering bottleneck] of virtually all mobile devices; past, present and for the foreseeable future.  This limitation resulted in the sharing of shaders amongst assorted assets;  artists and tech artists alike had to be creative with their shader construction and implementation in order to get the most mileage out of each shader.  From an optimization perspective the sharing of shaders is great -- if we could have a single UBER shader to render every object in a scene, accurately, well that would be the mythical "absolute zero" of draw-call optimization. 

However, while sharing shaders is good from an optimization perspective, it often leads to a loss in visual fidelity... But not with PBR.  In the case of Unity 5's "Uber" Standard Shader, the unused shader functions are "dropped off" at run-time automatically.  Pretty neat!  Additionally, the leading physically-based shader frameworks (i.e. Alloy Shader Framework for Unity 5 by the guys over at Rust LTD) offer an all-encompassing shader framework which is built modularly from the ground up; able to add, edit and control specific and extended PBR shader passes on a per-material basis. 

Of course Unity 5's Standard Shader also drops off the unused shader passes but it doesn't have the modularity which is often key for prototyping in PBR.  In fact, I would like to take this opportunity to shout-out to Rust LTD for making Alloy -- it's my go-to shader package whether I'm authoring a material found in everyday life or something more interesting.  Thanks Rust!

approximating reality

light interaction upon opaque surfaces can be summarized by two distinct behaviors:

Reflection [Specular] 

To Reflect 100% of all light, that is to say all light energy is bounced (reflected) from the surface without actually penetrating the surface, would give you a perfectly mirrored surface which exhibits equal intensity of the incident ray which fell upon it.  (See Right)

Diffusion [Albedo]

To diffuse 100% of all light would produce the flattest most vacuous of all matte finishes -- something akin to a rubber tire.  It doesn't sound very interesting, but I assure you there are countless awesome materials hiding between shiny mirror and dull rubber.  

The smoothness/roughness value of a physically-based material plays a major role in determining just how much light energy is reflected or diffused in a given lighting environment - but as we'll find out below, it's not the only parameter which plays a part in reflectivity.

to metal, or not to metal?

Whether or not a material is metallic in nature is the single most defining property of how it will appear visually, and for that reason the Metalness model of PBR was created [by Disney].


Most materials we see in our daily life fall into this category.  They reflect the full spectrum of light which hits* its surface -- although that reflection is usually so diffused upon exiting the surface that we don’t see a crisp reflection like those of metals.

*Keep in mind, light energy (or lack thereof) is emitted from virtually and literally every object in an environment, not just the light sources themselves.  This is why Reflection Probes are vital for PBR to have visual fidelity.


Metallic surfaces reflect most but not all of the spectrum of light that hits its surface, while absorbing the other visible wavelengths.  For this reason metals tend to reflect their own tinted version of reality, and the color it reflects is referred to as their Albedo.  

Metals also have a very high index of Reflectivity compared to non-metals.  A smooth gold surface will reflect the world around it with strong contrast, while a non-metal with the “same” smooth surface will only reflect a faint image.


Specular [Glossy] the alternative pipeline

The competing PBR model is called Specular [Glossy]. The Specular pipeline allows the artist to explicitly define the specular color of the material with the help of an additional RGB texture.  By contrast, the Metalness pipeline approximates the specular color of the material based on whether or not the surface is metallic in nature, and it's albedo value.  While the Specular approach is more akin to the traditional non physically-based way of authoring texture maps it also introduces an unnecessary variable for most artists to manage.  Additionally, the Specular model comes at the cost of greater memory overhead.

The general consensus is that the Metalness approach is considered more “artist friendly” due to its handling of the specular color, which reduces the possibility of producing “illogical” materials.  If you’re interested in the Specular approach you can select “Standard Shader (Specular)” from the shader menu or do a bit of Googling.

Part 0 of 3

Want to know why Physically Based Rendering is becoming the new standard? Start here!

Part 2 of 3

Familiar with PBR and ready to start authoring your own physically based materials in Unity 5? Start here!

Part 3 of 3

Looking for examples? Additional resources and a downloadable asset package featuring 10 materials.

Let's Get Physical: Intro to PBR

Jeremy R

What is PBR?

The information in this guide is essential for any artist authoring assets in a "next-gen" production setting -- which is to say virtually every end-user of a modern game engine. Whether you're a seasoned AAA veteran or a student in the classroom, this guide is determined to kickstart your understanding of Physically Based Rendering and demonstrate how to take advantage of the technology.  Efficiently.

Ready or not, PBR is the new standard.

With the release of Unity 5 and UE4 so came the wide-spread adoption of Physically Based Rendering (PBR)*.  It's an exciting time to be a game artist, realtime physically-based rendering is offering every artist out there the chance to author assets which compete with the most visually compelling experiences to date.  This is, of course, to be expected with most advancements in realtime rendering once they hit the mainstream, but physically based rendering introduces something special -- consistency

...only to find out that their Chesterfield sofa which looks plush and inviting in one scene then devolves to a steel-reinforced slab of concrete in another.

That's right, consistency.  PBR, when utilized as intended, allows artists to author assets which retain their visual fidelity under virtually any lighting environment -- not an easy feat to accomplish as any lead artist can tell you.  But not all is well in this time of transition... Time and again I have seen physically based materials authored inefficiently, incorrectly, and ultimately failing to take advantage of the inherent behavior and power of PBR.  Often this presents itself as an artist attempting to ad-hoc (eyeball) the property values of their material(s) to the tune of a very specific lighting environment -- only to find out that their Chesterfield sofa which looks plush and inviting in one scene then devolves to a steel-reinforced slab of concrete in another.  (Speaking from painful experience here.) 

* Unity has overwhelmingly adopted the term Physically-Based Shading, or PBS; the two are interchangeable but PBR is more common in physically-based literature.

isn't pBR too expensive for mobile? 

Well, that's for you and your team to decide.

Modern mobile devices, especially the ever-popular flagship devices (e.g. iPhone, Galaxy, Nexus, etc.) have rendering capabilities far beyond what the average consumer, and many a developer, realize.  In fact it's still common place for game developers to look to their on-screen vertex count as the compass needle for optimization -- that's simply not the case with a properly optimized scene.  Would you believe it if I told you it is possible to render a 13,000 square foot, 3-story open-air environment weighing in at more than 1 million verts on an iPhone 4? 

It's true:

These are of course in-editor captures, but you don't have to take my word for it; dig up your old iPhone 4 and download Republique: Metamorphosis on the Apple App Store.  It runs 1 million vertices at a solid 30 FPS even with the added complexity of multiple skinned characters, running water, flowing fabric, and a bounty of post FX.  

How was this accomplished?  

  • Combining proximal meshes which share the same shader

  • Combining those meshes as close to the maximum addressable number of verts-per-mesh possible (i.e. 65,536 verts for Unity which uses a 16-bit buffer)

  • Re-sizing and clamping texture resolutions on a per-scene basis

  • Combining all textures into an atlas on a per-scene/per-shader basis

  • Using the appropriate texture compression to strip out unused channels

  • Reducing overdraw of meshes, especially those with blending properties

  • Batching (Static & Dynamic)

  • Occlusion volumes based on FOV of the fix-position cameras

(Note: Mobile optimization guide is on the horizon.)

Depending on the complexity of your scene, implementing these optimizations can be the difference of a 1,000% in terms of latency.  During the development of Republique's most ambitious scenes I routinely saw latency improvements in the range of 100ms [10 FPS] to 10ms [60 FPS] while employing the above techniques.  In fact, the optimization gains became so formulaic and predictable that we were able to create increasingly grandiose environments as the series progressed. 

So, are you using Unity 5 to compose an immersive experience?  Does your scene have at least one dynamic light?  Well chances are you're paying the overhead for a physically-based lighting engine, possibly PBR shaders as well, while missing out on some (or all) of the perks that come with the shiny new territory of PBR.

The Library of Republique: Metamorphosis isn't physically based, in fact it's almost entirely diffuse-only with static light-mapping, but it demonstrates what can be accomplished when you profile your platform and develop to your device's strengths.  


Continue to Let's Get Physical: Part 1 of 3



Unfamiliar with PBR?  This introduction and summary of the technology  will get you up to speed on the basics of PBR.


Familiar with PBR and ready to start authoring your own physically based materials in Unity 5?  Start Here!


Looking for examples? Additional resources and a downloadable asset package featuring 10 materials here.