Simple PBR v2

Update 8/30

Simple PBR contains mistakes. You should build something based on this tutorial (by the excellent cynicatpro) instead:

I have an updated version of Simple PBR I can post if people are interested.


UPDATE 2, 10/30:

Updated version is here:


Now that I’ve gotten a chance to test things out in the Ruined Fountain scene, I can now pass out the much-improved version of Simple PBR:

Simple PBR is now even simpler! It now (properly) uses the albedo/rough/metal model used in many newer renderers and game engines.

It also comes with a cousin, Substance PBR. Substance PBR is just Simple PBR with the roughness squared, this is necessary to match the roughness curve used in Allegorithmic’s Substance tools. (bitmap2material, substance painter, etc). Substance PBR should more or less completely match the Substance pbr_metal_rough viewport shader, so you can just bake map channels, plug them in, and go. (I’ll have a more detail blog post in the coming days on how to work with Substance and Blender)

There is also a third group, Simple PBR Spec. This is like Simple PBR, but uses the spec/gloss model instead of metal/rough.

These groups do not have any tools for texture baking/creation, you still need to make those on your own. You may wish to check out Allegorithmic’s excellent guides on the subject:

Metroid Prime – Ruined Fountain

(minor note: dragon project is on hold until I decide if I want to bother fixing some design issues brought up in other WIP threads)

My never-ending love for the original Metroid Prime is back. I’ve done several renders before loosely based on its environments, but this time I wanted to do something a bit different. I wanted to re-create a room from the game outright, to try and see what it would look like in modern offline HD glory. I figured it would also be good practice working off someone else’s environment concepts. So I chose a standout and fairly small one, the ruined fountain in the Chozo ruins. This was somewhat inspired by this blog post. My goal isn’t necessarily for it to match down to individual details, but I’m trying to avoid major deviations as far as materials, locations of pipes and platforms, objects, etc.

So with no further ado (because I need to eat lunch pretty quick here…)

env_003 env_fountain_003b env_magma_003

Pluto and Charon



Had a little fun making a visualization of Pluto and Charon (was too lazy to do the smaller moons). The base color is built on the actual color data we have, thanks to a nice person named johnvanvliet over at the Celestia Mother Lode:


I took the color maps and layered a bunch of other crap on top of them, from surface maps other other planets and moons, to ice and concrete swatches. Kinda fun to sit down and design a planet surface.

Linking and Appending in Blender

Library linking is a very powerful function in Blender. In fact, it is pretty much essential once scene complexity goes past a certain point. Unfortunately, it’s not always very well explained. People are often left to learn how to work with it through reading reference manuals, and I guess osmosis and forum posts.

Well, this blog post is here to change that. In a nice written tutorial, I’m going to go over: 1) How this system works, and 2) how to use it to make your life easy. But first, a bit of background……

Blender’s Library and Datablock system

Blender stores all of your scene data in a particular arrangement known as a “library”. The library contains a bunch of pieces known in Blender parlance as “datablocks”. In more generic computing terms, these are often called “nodes” (indeed, that’s what their equivalent in Maya in known as), but that word has some special meaning for Blender. It refers to the stuff in the node editor, a “datablocklett”, if you will. Those aren’t too important right now, so we’ll just stick to calling them datablocks.

If you go to your scene outline, you can change the visibility to mode to “Blender file”.

This is a birds-eye view of the entire scene, broken up by data type. If you unroll a tab, like objects, for example, you’ll see a list of all datablocks by that type:


Object blocks are the individual objects in your scene. Object blocks have another block associated with them that supplies them with their data or geometry. A “mesh” block for meshes, a “camera” block for cameras, you get the idea.

The purpose of linking and appending is simple: Get a datablock from one .blend file into another. They go about it in different ways. To elaborate.


The append command is pretty simple, really. It just copies the selected datablocks from the source file into the current file. When you hit File > Append, you’ll select a .blend file, then you will be presented with some folders, one for each datablock type.


Select what you want (like any other file browser in Blender) and hit “Link/Append from Library”. You’ll now be taken back to your scene, and the data you copied will be available locally. If you selected objects, they’ll be in your scene now. If you selected something else, like mesh data or a material, they won’t appear (since they aren’t objects) but you can select them in the usual locations. Remember, when linking or appending an object, select the object itself in the “objects” folder, don’t select the mesh/curve/camera/whatever data. That’s just the data, it’s not an complete object.


Ok, got appending down? (give it a try if you haven’t already, because we’re about to build on that knowledge). Now, what happens when you choose “link” in the file menu instead of “append”? You get the same file browser and options – fun fact, internally, the link and append functions are the same command run with different options – but it works very differently. While appending COPIES the data, linking merely points to the original source file. It’s like the difference between copying a file and making a shortcut/symlink.

When you link individual objects, they show up with a teal-blue outline, and you can’t do much of anything with them.


You can’t move them, you can’t edit their materials, or their UVs, or whatever. Their properties are not in your current file, they are being read out of the file they came from. You need to go back to that file if you want to modify them. And you need to select objects individually when linking, which makes it easy to forget pieces of complicated models. So how do you actually make use of this? With linked groups!

Groups and Dupligroups

Blender allows you to add objects to lists known as “groups”. If an object is a member of a group, it will turn green to mark this. An object can be part of more than one group, if need be. Once you have a group created, they can do some really useful things. Like group instances, also known as dupligroups. We can add an instance of a group from the add menu:


This creates an empty, and following it like ghosts, are copies of all the objects that are a part of that group. If you go to the empties object panel and look under duplication, you can see “group” is selected and it points towards the group we chose. You can edit this if you need to, of course.

The handy part is, we took all of those objects (there can be a ton of them) and made an empty that represents all of them. We can move this empty around, just by itself, and copy of the group stays with it, just as it was originally arranged. This copy is dynamic too; if we remove an object from the group, it will no longer appear in the dupligroup. Same goes if we add an object, it will now appear in all dupligroup instances of that group.

Group Linking

When you go into the link menu, you might notice there is a folder for “groups”. Rather than linking objects individually, what you’ll do most of the time is put everything into a group, and link that group. For example, not too long ago, I made a project with the pokemon Metagross. In the character file, I created a group (metagross_char_grp) with all the objects that make up the character, and I’ve linked it here.


Notice how Metagross is totally controlled from that one empty, and in fact, only exists in my scene outline as that one empty! If we switch over the the outline’s “blender file” view, we can see just what exactly happened:


Our “current file” hierarchy is joined by a second file, which contains the character. You can see a whole buttload of datablocks have been loaded in from that file, and they are all represented in the actual scene by that single empty! All of these blocks were either objects in “metagross_char_grp”, or were dependencies of something that was. (like materials, images, mesh data, armatures, etc)


Assembling the Scene with Linked Groups

Linking things in as dupligroups gives some big advantages:

  1. Complicated things live in a single, simple source file. 1 copy of the object, at the center of the scene, nothing else around
  2. Because of #1, if an object is used in more than one shot, you can keep them all sharing the same file. Need to make the vehicle more shiny? Easy, change the material in the source file, and the changes automatically propagates to all your shots.
  3. All the heavy data is not stored in your actual working file. So while you animate or set up lights, when you hit save, you only need to save the animation/light data. You don’t have to spend ages writing every mesh (that you didn’t touch) to disk. It’s just read when you need it.
  4. Everything in the final scene exists as just a few empties, which keeps everything neat and tidy.
  5. Since you work with pieces as a set, you don’t need to worry about breaking stuff. Like moving a lamp and forgetting to select one piece of the mesh
  6. If you need more that one of something, you can just add another group instance. Change the source, all the copies are updated. Bonus: it’s also instanced at render time, so engines like Cycles, Vray, Luxrender, etc, will only need to store the meshes in a particular group once, regardless of how many copies you actually make.

So to take advantage of this, you just build your scene in multiple separate files, add your objects to groups, and link them to your main shot file. How many files you want is up to you. For a simple scene, you might put the entire environment into one file, link that as one big dupligroup, add another for your character, add some lights, and call it a day. For a more complex shot, remember, you can nest dupligroups. If you add the group instance empty to a new group, then link that group, you get a dupligroup containing more dupligroups!

Here’s how this might work in practice. Let’s say you are making a tea room with a tiger in it. You have one .blend file where you have modeled most of the pieces of the tea room. The walls, floor mats, etc. You add all of these to your “tea_room_env” group. Maybe you want a couple of ornate lanterns hanging from the ceiling. This is a more complex thing made up of multiple meshes, and you will have several copies of it. You can build the lantern in its own .blend file, put it in a “lantern” group, and back in your environment file, you can link in this “lantern” group, make a few copies, place them how you like, then add these empties to the “tea_room_env” group as well. And maybe you also sculpted a statue of the Buddha you want in the room. No need to bother moving this, just add it to a “buddha” group in your sculpting file, and link that as well in your environment file. Add the empty to the “tea_room_env” group as well.

Now your tiger is complicated, and rigged and everything. For your own sanity, you want to work on that in it’s own .blend file as well. So add all the pieces to your “tiger” group. Now, make a new .blend that will be your final shot. Link in the “tiger” group and the “tea_room_env” group from their respective source files. Position tiger, add lights, render. Ez pz.

Wait a sec, what if you decide you want to add some flowers onto the lanterns? Well, if you had made everything as copies in one file, this would suck. You’d have to copy the flowers onto each lantern individually. But since we grouped and linked everything, it’s no big deal at all. Open up the lantern file, add the flowers, make sure they’re added to the “lantern” group, save it, and you’re good go. Open your main shot file back up, and all the lanterns have the flowers on them. They’re read from the environment file, which in turn reads each one from the same lantern file, and we just added the flowers in that file. So the change just shows up!

Here’s a flowchart of how we arranged the data:


Proxy objects

Oh yes, one more thing. You might be thinking, how exactly do we control the rigged character in this setup? There’s a special tool in Blender specifically for this. Proxy objects. Select your character dupligroup, and hit Object > Make Proxy. You will be prompted to choose and object in that group. Hopefully, you made a “control rig”, an armature object that can control all the functions of this character. Select that from the list. You will now get a special copy of it in the current scene, and any actions you do with it will affect all instances of that group.

Wait, “all instances”? Yeaaahhhhhhh. So it turns out Blender isn’t so great about handling things when you want more than one copy of the same character doing different things. Any and all instances of a particular group will always do the same thing. So Blender needs to be tricked into handling multiple characters. My favorite workaround for this (thanks to Sebastian Konig for suggesting it on BlenderArtists once) is to make multiple symlinked copies of the character file, and link the group from all of those. Blender will believe it is loading multiple different characters, when in reality it is loading the same one over and over.


Further Reading

Blender wiki on library linking:

Blender wiki on datablocks:

More Blender wiki on datablocks:

Blender wiki on groups:

Really good thread on asset management in Blender: