Coloring a White Robot: Six Failures, Success on the Seventh, and Why We Had to Read Back in Code Instead of Trusting the Screen
The educational AMR robot arm we loaded into Isaac Sim was entirely white, so we tried to color each part. We created a material and bound it, but for six attempts the robot stayed white. The cause was neither the lighting nor the material type but "where the material was bound." This is a record of ruling out one cause after another behind the same symptom.
We created a material and bound it, but the robot stayed white for 6 attempts. The cause was neither the lighting nor the material type. A material bound two levels above the part we wanted to color was deciding what appeared on screen. The visible symptom was the same every time, and the candidate cause was different every time.
What were we trying to do?
When we loaded the design file of the educational AMR robot arm into Isaac Sim, the robot appeared only in white and gray. To record training scenes on video, it is better if the parts can be told apart as on the physical robot, so we decided to paint the body and arm dark gray, the gripper fingers black and the camera body silver. The colors are values chosen per part to be close to the physical robot.
The task looked simple. Create one material and bind it to the mesh of that part.
Seven attempts
| Attempt | What we did | Result | What we found out |
|---|---|---|---|
| 1 | Created a material and bound it to the mesh | Still white | n/a |
| 2 | Lowered the lighting and also set the default display color | Still white | Shadows and shading were normal, so not a lighting problem |
| 3 | Read back in code "the material that is actually applied now" | The original material, not the one we bound | Not a display problem but a binding problem |
| 4 | Found that the original material sets its color in a different way, and recreated ours the same way | Still the original material | The material type is not the problem |
| 5 | Checked "is it a copy (instance), so individual edits are blocked?" | Not an instance | Hypothesis rejected |
| 6 | Went up one level at a time through the groups above and checked where a material was bound | The material actually applied was bound on the group two levels above | Cause confirmed |
| 7 | Bound a new material to that group | Success | n/a |
The third attempt was the decisive one
Through the first and second attempts we judged by looking at the screen: "It is still white. Is the lighting too bright?" In the third attempt, for the first time, we asked directly in code: "What material is actually applied to this mesh right now?"
from pxr import UsdShade
mat, rel = UsdShade.MaterialBindingAPI(mesh_prim).ComputeBoundMaterial()
print(mat.GetPath()) # the original material came out, not the one I madeHere the kind of problem changed. It was not that the screen failed to draw color. The material we bound had never been applied in the first place. Without this one line, we would have spent more time changing the lighting and color values.
The cause: the material was bound somewhere else
The USD file that Isaac Sim uses holds parts in layers like a tree. This robot looked roughly like this.
visuals
└ part group (two levels up) ← the material actually applied was bound here
└ part group (one level up)
└ mesh ← where we bound ours in the first 6 attemptsThe tool that imported the robot had bound the "real" material not to the mesh but to the group two levels above, and that material was the one applied on screen. When we bound a new material to the same group, the color changed immediately.
However, we did not separately check why the binding placed directly on the mesh lost to the one on the upper group. In USD, the binding closer to the mesh usually wins, but there is also a setting that marks an upper-group binding as "stronger than the ones below." We could not confirm which case this was. If you meet the same problem, we suggest checking the settings of the upper-group binding as well.
What we learned from this process
- Do not decide "it does not work" from the screen alone. The kind of problem changed in the third attempt, when we read back in code.
- "Coloring the mesh" may not mean editing that mesh. First look at where the actual material is bound.
- Same symptom, different causes. The symptom of staying white was the same, but the candidates moved from lighting to whether the binding existed, to material type, to instancing, to binding location. Setting up and ruling out hypotheses one at a time is what eventually found the answer.
Frequently asked questions
In Isaac Sim, what should I check first when I bind a material and the color does not change?
Before looking at the screen, read back in code the material actually applied to that mesh. If the one you bound does not come out, the problem is the binding location, not the lighting or the color values. Then go up through the groups above and check whether another material is bound there.
If I bind a material to an upper group, do all the parts below become the same color?
They do if there is no separate winning binding below that group. In this robot each part had its own upper group, so we could divide the colors part by part.
Can this kind of problem be covered in a class?
The scope and method covered in class are explained in an education consultation.
This post is based on Isaac Sim 5.1.0. The colors are approximations chosen per part by looking at the physical robot, and we did not match the colors of the small parts on the physical robot.
Version used: Isaac Sim 5.1.0
Sources: Coloring practice for the virtual model of the educational AMR robot arm, which we carried out ourselves (September 2026).
The copyright of this post and its figures belongs to SV Robotics. Citations that give a link to the original are welcome. Reproducing the full text, redistributing it, or reprinting it as teaching material requires permission.