Jump to content

Blender 3D: Noob to Pro/Blender Memory Management

From Wikibooks, open books for an open world
Note:

This section may be a bit bewildering on first reading. If you don’t understand it right away, don’t worry too much; but as you work more and more with Blender, making copies of objects, or sharing settings between objects, feel free to come back and re-read this and hopefully it will make some subtleties of Blender’s behaviour clearer.

Datablocks And Users

[edit | edit source]

It is helpful to understand how Blender manages memory. Just about everything in a Blender document—objects in scenes, scenes themselves, materials, textures, whatever—is stored in a datablock. Each datablock has a name, which must be unique among datablocks of the same type. Each datablock may be referenced from one or more places, mostly in other datablocks—in Blender parlance, it has one or more users. For example, several different objects might share the same material, so when you change the characteristics of the material, it automatically changes the appearance of all those objects.

If the number of users of a datablock drops to zero, it still stays around in memory, but it will not be saved when the document is saved. Thus, if you save and reload the document, all the datablocks with zero users will disappear. (In some cases you may need to save and reload a couple of times before all zero-user datablocks disappear.)

But up until that point, the datablock will continue to appear in the relevant popup menus, so you can reassign it to more users.

You can also assign a fake user to a datablock; this is what the “F” button is for in the popup menus that list datablocks of that type. This ensures that the user count never goes to zero, so the datablock always gets saved in the document even if it has no real users. This is useful for “library” documents, which can contain collections of useful materials and textures, say, that can be linked or imported into other documents, without also having to include dummy objects in the library just to ensure those materials and textures get saved.

For example, here is the widget that lets you choose the material for an object:

The main part shows the name of the current material, which is editable. The X button breaks the link to this material and decrements its number of users by one, while the F button assigns a fake user to this material. The + button lets you create a new material.

The material symbol on the left pops up a list of existing materials to choose from, plus a search box to search all existing materials:

Note the entry with the 0 symbol next to it; that currently has a user count of zero, and will disappear when the document is saved and reloaded, if it is not further used.

The widget also displays the current user count if it is greater than 1:

In this case the count was incremented because the F button was selected.

Note:

Clicking the number (if it’s greater than 1) makes a copy of the Material, attached only to this particular user. The copy has a user count of 1, while the original has its user count decremented by 1.

This is the basis of the (slightly confusing) distinction in Blender between object datablocks and object data datablocks. Object datablocks contain the information common to all the types of objects in the 3D scene, regardless of whether they’re mesh objects, lamp objects, camera objects or whatever; whereas the object data datablocks contain the information specific to that instance of the type of object, e.g. the vertex, edge and face definitions for this particular mesh you might be using, or the colour and energy of a lamp you've set up for your project, or the field of view of a camera you have.

That leads us to the difference between the two object duplication commands,  SHIFT + D  and  ALT + D : the former duplicates both the object datablocks and the object data datablocks (though this can be controlled in your User Preferences), while the latter only duplicates the object datablock. That means that in the first case the two objects are truly independent, but in the second case the new object continues to share the same object data datablock so a change in one will result in a change in both of them. So, for instance, if you use  ALT + D  on a mesh object and edit the vertices, edges or faces on one copy, the other copy will also be affected.