XDECAL™ ****User-guide
Chapters
Decal Assets & Texture Library
Table of contents
Each decal serves as an instance of a particular template - a material or object that defines the decal's appearance. Decals themselves are merely containers, and templates can be swapped at any time.
All decals of the same template will share its looks, but it is also possible to have some material properties be different for each object (by using Attribute nodes in tandem with objects' custom properties). The addon provides some utilities for setting up such per-object attributes, but you should keep in mind that Blender only supports up to 8 instance attributes in a material (so you'd have to be judicious about which parameters you want to control on a per-object basis).
<aside> 🚧 By default, shadow rays (in Cycles) are disabled for material-based decals and enabled for object-based decals. This enabling/disabling happens upon decal instantiation and when you change its template type (e.g. switch from material to object, or vice versa). This is done to avoid potential shadowing artifacts when rendering with Cycles; since such artifacts do not seem to appear in Eevee, the material’s viewport display shadow mode is left as-is.
</aside>
A decal's main purpose is to be projected on one or more objects ("projection targets"), adhering to their surface like a sticker. Two main forms of projection are supported:
Copied geometry: this works by joining the copies of projection targets into a single mesh (and optionally removing the geometry outside of the projection volume), which is then displayed with the decal's material.
Shrinkwrap: unlike Blender's "Shrinkwrap" modifier, this will preserve vertex offsets along the template's Z axis for object-based decals, and remove the failed-to-project vertices for material-based decals. Note, however, that decal embedding will not work in this mode.
A decal can be dynamic or baked
In Dynamic mode, a decal automatically adapts to the changes in the geometry of its projection targets. Besides pure convenience, this can also be necessary for animations. However, if there are many dynamic decals on the same object or they use some expensive processing (like boolean intersections), it can slow things down during some operations.
If you check the decal palette page, you will also find that you can set a default (per file) for the dropped decals to be either baked or dynamic by default.
In Baked mode, decal's geometry is baked into a static mesh and the modifiers are turned off, which makes decals cost relatively very little performance. Baking is also required for a couple of additional features:
Not embedded decal (Stencil - Bevel material)
Embedded decal (Stencil - Bevel material)
Decal embedding. You can non-destructively "mix" / "merge" the decal's material with the materials of the underlying surfaces, which essentially provides an ability to locally override various BSDF properties (e.g. Normal) of the projection targets. The "merged" materials are automatically synchronized with the original materials via property drivers, but this only works for the changes in node socket values. Any other changes to the nodes and connections would need to be updated via re-baking.
<aside> 🚧 If the decal is projected on multiple objects which have multiple/different UV map names, you might not get correct results, unless their materials use explicitly specified UV maps or each mesh's active UV map has the same name.
</aside>
<aside> 🚧 A visible mismatch between the embedded decals and the underlying surface can also happen if the surface is using any sort of implicit object-local texture coordinates. Before embedding, make sure that the surface materials are using texture coordinates either coming from geometry (e.g. UV maps), calculated in global space, or calculated in a local space of an explicitly specified object.
</aside>
<aside> 🚧 Another reason for the visible mismatch can sometimes be the use / mixing of multiple shader outputs in the material of the underlying surface. It’s best to use a single Principled BSDF shader node, and avoid mixing multiple shaders.
</aside>
<aside> 🚧 For embedding/mixing to work, the BSDF/shader node(s) connected to the output need to be in the main material's node tree, and not inside a node group. If they are inside a node group, its contents would need to be ungrouped into the material itself (though keep in mind that ungrouping does not preserve the node group’s input values, so you’ll have to re-assign the corresponding values manually).
</aside>
Armature deformations with dynamic decals
Armature deformations with baked decals
Skeletal animations. The necessary setup steps are done automatically when you bake a decal projected on a mesh with an Armature modifier. This even works for deformed armatures (not in the rest pose), but the Armature modifier needs to be the last active modifier in the stack.
<aside> 🚧 Implementation note: switching from baked to dynamic will use the modifier's folded/unfolded state to restore their enabled/disabled state, so take care not to fold/unfold the modifiers when the decal is baked.
</aside>
© 2024 MOTH3R ® All Rights Reserved