# Apply Object Texture Coordinates

Recently, I used Cell Fracture on a wall to split it into pieces. I then used an Empty and Object Texture Coordinates to map a Brick Texture over the wall. However, when I simulated the wall (Rigid Body Simulation), all of the textures changed (kind of like I expected).

What I was wondering is is there a way to "apply" Object Texture Coordinates, or otherwise, how can I fake it?

Here's my current result:

New .blend:

• You can run the texture coordinates through an emission shader, then bake it. (Remember, XYZ and RGB are identical.) – PGmath Jul 30 '16 at 13:21
• @PGmath I am not familiar with baking. Would you consider adding an answer and explaining it more in depth? – Shady Puck Jul 30 '16 at 14:13
• Does this answer your question? How do I bake a texture using Cycles bake – Jachym Michal Jan 23 at 14:45

final Blend file:

The workflow PGMath suggested works, there is a few traps however on the way to get that to work on the shards as well. I'll explain as I walk through the solution found. What's needed to get it done is the assistance of the TextureAtlas addon. Enable it in the Addon Section of Blender:

It's important to mention that without the initial idea by PGmath, I'd had no clue as of how to do it, so you might consider accepting his answer as the one which worked. The workflow is like this:

Create your scene as desired, with mapping set to object coordinates as requested. Next, create an image Texture, which will serve as the target of our baking:

For me, using 2048 x 2048 with 32 bit depth worked fine for your demo scene. Save this image as an OpenEXR to Disc. Now to the material setup. You want to bake the UV Map of this material here:

So you've used Object coordinates, and did some mapping inbetween as well. The part we need is only the part including the mapping node, so everything which affects the UVs. Feed that into an Emission Shader and connect it to the material output node (it is called Viewer in this screenshot, because, lazy as I am, I was using Node Wrangler to hook it up quickly, but it is nothing than a default Emission Shader):

If you render this now, you see something like this:

This is nothing else than the representation of our UVs as RGB channels. Now, add another image Texture Node, and select the Object_UVs Texture from there. At the moment it will be black or empty, but in a few seconds we have the UVs in there.

This material needs to be assigned to every shard of your simulation before you proceed. This has very likely been done by the cell fracture addon anyways, but just double check it. Now we need to create UVs for the shards. The tricky thing is, we want to bake a UV map that fits all shards at the same time, but we can only unwrap one at a time. So how to make sure UVs never overlap? TextureAtlas solves this by temporarily combining shards, unwrapping (lightmap pack), packing, and then separating them again.

Go to the TextureAtlas tab in the Rendering section, using the plus sign add an Atlas, and set these settings:

So the resolution should match your Texture, you add all shards to it by having them selected and clicking 'add selected', set the mode to Lightmap, and the margin to 0.05 (I got this value by testing). The margin will make sure there is some space inbetween shards, otherwise one shard's UVs overwrite anothers.

Now, make sure that this texture node is selected before starting the baking! Regarding performance, you can set the samples as low as 4, lower samples for me caused artifacts in the emit pass, resulting in distorsion. If clamping has an effect I did not test, but just set it to 0.0 for safety measures. Most important is the margin: set it to 1 pixel, as the 2K map will be really tight! Now use the Emit Pass as the result of your bake, and click 'bake':

If you have an image editor open at the same time, you can follow the progress. Once done, it should look something like this:

Save this image, so it won't be forgotten after you exit Blender. Regarding the File Format, since you need 32bit information ideally, choose OpenEXR with Float Full Color Depth, so 32bit per channel, as in this screenshot:

You can choose RGB instead of the default RGBA if you want to save some disk space, the Alpha won't be used. Now, you can create a node setup like this, while getting the exact same result as before:

The logic is: The RGB values in the Object_UVs texture represent the coordinates in the UV image editor, however the blue channel is unused. R represents U coordinates, G the V coordinates. Blender doesn't care if they come from a node, the uv editor or a texture, you can feed them in nonetheless!

• Standard SE etiquette is that if someone posts an idea in the comments, give them a little time to put in in an answer before copying it in your own answer, see this meta post. – PGmath Jul 30 '16 at 18:05
• no worries, I'll delete mine – aliasguru Jul 30 '16 at 18:13
• post updated after getting in touch with PGmath – aliasguru Aug 1 '16 at 16:34

You can do this by creating a special new material of the texture coordinates and baking it, then using the baked image for the texture coordinates of your split objects. Note thatt this should be done before cell fracturing your object.

First unwrap your object. It doesn't have to be a super clean unwrap, just something not too distorted.

Now create a new material and name it something like "MappingCoords" or whatever makes sense to you. For the material just plug the Object texture coordinates into an emission shader. Since color and vector datatypes are no different from each other the XYZ texture coordinates will now be represented by RGB values.

Now go to the UV/Image Editor and add a new blank image by clicking on the New button at the bottom. What resolution to use will depend on how big your model is and the resolution of the texture you will be using.

Next go back to the node editor and add an Image Texture node. Don't plug it into anything or modify your nodes, just select the blank image you just made and make sure the node is selected. Now go to the Render Properties tab and scroll all the way down to the Bake Rollout. Select Bake Type Emit and hit the Bake button.

The bake should look something like this:

Now go to the UV/Image Editor and save the baked image as an OpenEXR file (other file formats will undesirably clamp the <0 and >1 values to 0 and 1). You can then load the image and plug it into the Vector of the image texture for your material.

Now when you cell fracture the object each fractured piece should retain its UV unwrapped coordinates, which are being used to map the baked texture coordinates for the actual image texture.

Here is my .blend so you can take a closer look at what I did:

You will have to either re-bake the coords or download the above image (it's a PNG not EXR, but it will work in this case since I used generated coords which are in [0,1]) since the file was too big to fit on Blend Exchange.

• Perhaps I should have been a bit more clear. I have multiple objects that need to be uv unwrapped. I have achieved this by joining them, using Smart UV Project, Margin: 1, separating them with By Loose Parts, and realigning their origins with Origin to Geometry. I will say that after baking and following your steps to the best of my abilities, my results are still really weird. If you have the time, please consider problem solving with my .blend file, available in my question. – Shady Puck Jul 31 '16 at 1:46
• @ShadyPuck Sure, I'll take a look at it! I guess I didn't realize you have already cell fractured the object, it would make it easier if you bake the texture coords before cell fracturing it. Is that possible? – PGmath Jul 31 '16 at 2:49
• Probably. I'll try that in the morning. – Shady Puck Jul 31 '16 at 2:49
• Ok, I tried baking on the cube I used before cell fracturing, and I still get this weird result. I tried the openEXR thing, which I hadn't before, but it didn't change anything. Any more thoughts? I also uploaded a new .blend file that includes my newer exploits, minus the .exr because it was too big to go to Blend Exchange. – Shady Puck Jul 31 '16 at 12:40
• I've got a working solution now which keeps the mapping on the shards intact. It is based on your file, however this time I'll wait for PGmath to post his answer, don't want to offend the forum members any further. – aliasguru Aug 1 '16 at 7:48