我接到的第一个 AR 涂涂乐项目是给一家线下亲子机构做互动屏。第一版逻辑很简单孩子在平板上选颜色模型就换成对应颜色。Demo 出来当天产品经理就拍板要改孩子画的东西能不能直接穿到模型身上 这句话听起来就像给模型换层皮我当时也以为不过是换一张贴图结果真做起来从选图权限、图片解码、纹理方向到材质替换每一步都有能坑到怀疑人生的细节。这篇文章把我最终跑通的完整链路写下来用户上传一张图片Unity 解码成 Texture2D动态生成 Material 贴到 AR 场景里的 3D 模型上秒变新皮肤。附带可直接拿去用的 C# 代码以及我在真机上踩过的坑和对应的排查思路。1. 上传图片换肤的产品逻辑与应用边界1.1 传统涂涂乐的天花板在哪市面上大多数涂涂乐的核心交互是从预设素材库中选一个颜色或贴图赋给模型。这种模式的开发难度低、可控性强但它有两个天然的短板素材有限、结果同质化。用户玩五分钟就能把所有内容翻完而且每个用户得到的都是同一套颜色缺少这是我的作品这种最原始的成就感驱动。尤其在儿童教育场景里孩子画完一幅画期待的是我创作的图案被看见、被使用而不是点击一个按钮换色。这种参与感上的缺失直接决定了产品的留存上限。用户上传图片变皮肤恰好同时解决这两个问题。内容来源从开发者提供变成用户自创理论上无限扩展结果因人而异每个模型穿的都是用户自己的画或照片天然自带分享冲动。我当时的版本在加了上传功能后用户平均使用时长比旧版本涨了将近一倍分享次数更是明显提升。虽然这个统计不算严谨但方向是明确的让用户参与创作而不是让用户做选择题。1.2 适合这个功能的场景和模型选择从实际落地来看这个功能最适合三类项目。第一类是亲子互动孩子画完涂色卡、拍一张照片让虚拟宠物或卡通形象穿上自己的画作。第二类是文创和营销互动比如博物馆、展会里的吉祥物换装用户上传品牌元素或自己的设计图案在 AR 镜头里即时看到效果。第三类是角色自定义类游戏或社交应用里允许用户用本地图片装饰角色的外观。但这里有个容易被忽略的前提不是任何模型都适合做换肤。模型必须拥有一套完整、合理的 UV 展开。很多从公开渠道下载的免费低模UV 可能是重叠的或比例极度失衡贴上去必然扭曲变形。所以在选择美术资产阶段建议先用棋盘格纹理测试一遍——如果棋盘格在模型表面分布均匀、没有明显拉伸或接缝再拿来做换肤功能。这一步省不了硬做的结果就是后期反复调 UV 浪费时间。2. 吃掉换肤原理UV、贴图坐标与 Material 的关系2.1 UV 展开是皮肤地图3D 模型的表面之所以能显示图片靠的是 UV 展开。建模师在做模型时会把模型表面摊平成一张二维平面每个顶点记录自己对应贴图的哪个位置这套坐标就是 UV。渲染时GPU 读取模型表面每个位置对应的 UV再从贴图上取出对应像素的颜色最终呈现到屏幕上。说人话就是模型像一张白纸折成的纸盒子UV 展开等于把盒子拆开平铺在桌上贴图则是你要粘到每个纸面上的照片。谁都会贴照片但如果你拿一张比例不对、方向歪斜的照片去贴最后盒子展开区域的图案一定会变形。所以用户上传图片变模型皮肤这件事本质是替换模型的贴图Texture和材质Material而不是修改模型本身的网格Mesh。这一点想清楚后面所有代码都会顺理成章。2.2 为什么走换材质而不是改模型有人会问能不能直接改模型的顶点颜色顶点色的确能给模型上色但它有几个硬伤第一顶点色跟顶点数量绑定分辨率低细腻的图案做不了第二顶点色需要美术预先把哪个区域允许上色烘焙好动态加载一张外部图片没有直接通道。所以正确做法永远是走材质管线图片 → Texture2D → 赋给材质纹理属性 → 替换或覆盖 Renderer 的材质。在 Unity 里替换材质有两种思路。第一种是直接给renderer.material赋一个新材质实例优点是简单直观适合开发和 Demo 阶段缺点是一次换肤就多一个新材质实例多个模型共用基础材质时会浪费内存。第二种是用MaterialPropertyBlock它只修改属性而不创建实例适合正式版里一批模型共用基础材质的场景。我的习惯是原型期用第一种把功能跑通版本稳定后换成第二种再做一次完整的内存梳理。3. 核心代码实现从图库选图到模型换肤的完整链路3.1 环境准备与模型规范先确认项目环境。我使用的是 Unity 2021.3 LTS 和 2022.3 LTSAR 部分用 AR Foundation 4.2 及以上配合 ARCoreAndroid和 ARKitiOS对应的 XR Plugin。图库选择用 NativeGallery 插件它把 Android 和 iOS 的原生相册 API 封装成了统一的 C# 接口比自己写AndroidJavaObject调 Intent 省心太多。这里有个新版本的坑Android 13 及以上把相册读取权限从READ_EXTERNAL_STORAGE拆成了READ_MEDIA_IMAGES需要在 Player Settings 里声明好否则可能出现选图失败。模型格式方面FBX 是 Unity 原生支持最好的格式日常开发首选。如果模型要从服务器动态加载GLB/GLTF 格式更有优势Unity 里可以配合 glTFast 插件运行时加载。无论哪种格式前提都一样UV 展开正确、模型中心合理。特别是中心点很多低模的锚点要么在脚底要么在几何中心不统一后面 AR 摆放时需要针对包围盒做偏移处理。3.2 用户上传图片移动端相册选图移动端最稳妥的交互是调用系统相册。NativeGallery 的核心接口使用起来很简单private void PickImageFromGallery() { NativeGallery.Permission permission NativeGallery.GetImageFromGallery((path) { if (string.IsNullOrEmpty(path)) { Debug.Log(用户取消选图); return; } StartCoroutine(ApplySkinFromPath(path)); }, 选择一张图片作为新皮肤, image/*); }在 Windows/Mac 编辑器环境调试时这个接口会弹出一个文件选择对话框也可以用EditorUtility.OpenFilePanel直接选本地文件但要注意编辑器下的路径和手机沙盒路径格式不同代码里最好单独封装一层获取路径的逻辑。还有一个容易被忽略的细节相册返回的 path 在不同平台上格式不一样。Android 上可能是content://开头的 Uri也可能是/storage/emulated/0/...真实路径。NativeGallery 内部处理了大部分转换但如果哪天要自己对接原生File.ReadAllBytes打不开content://路径需要先转成真实路径或用NativeGallery.LoadImageAtPath读取。3.3 图片解码从文件到 Texture2D拿到路径后核心解码代码其实很少private IEnumerator ApplySkinFromPath(string path) { // 不在这里直接解码先让当前帧结束避免选图回调时卡住主线程 yield return null; Texture2D texture LoadTextureFromPath(path); if (texture null) { yield break; } texture LimitTextureSize(texture, 2048); ApplySkinToModel(texture); } private Texture2D LoadTextureFromPath(string path) { byte[] bytes File.ReadAllBytes(path); Texture2D tex new Texture2D(2, 2, TextureFormat.RGBA32, false); if (!tex.LoadImage(bytes)) { Destroy(tex); return null; } return tex; }new Texture2D(2, 2, TextureFormat.RGBA32, false)里的 2x2 只是占位LoadImage会从字节数据里解析真实宽高并覆盖内容。最后一个参数mipChain我建议设为 false因为动态皮肤场景里模型通常不会离镜头特别远省掉 mipmap 可以降低接近一半显存占用。如果以后发现模型在远处有纹理闪烁再开启也不迟。3.4 大图降采样别让手机相册照片撑爆内存移动端相册里的照片动不动就是 4000x3000直接加载进内存意味着巨大的分配。以 RGBA32 格式算4000x3000 的贴图需要 4000 × 3000 × 4 ≈ 48MB。如果在加载的同时还在跑 AR 相机和渲染低端 Android 非常容易闪退哪怕不闪退解码瞬间的卡顿也会让用户觉得 App 崩了。private Texture2D LimitTextureSize(Texture2D source, int maxSize) { if (source.width maxSize source.height maxSize) { return source; } float ratio Mathf.Min((float)maxSize / source.width, (float)maxSize / source.height); int newWidth Mathf.Max(1, Mathf.RoundToInt(source.width * ratio)); int newHeight Mathf.Max(1, Mathf.RoundToInt(source.height * ratio)); RenderTexture rt RenderTexture.GetTemporary(newWidth, newHeight, 0, RenderTextureFormat.ARGB32); rt.filterMode FilterMode.Bilinear; RenderTexture.active rt; Graphics.Blit(source, rt); Texture2D result new Texture2D(newWidth, newHeight, TextureFormat.RGBA32, false); result.ReadPixels(new Rect(0, 0, newWidth, newHeight), 0, 0); result.Apply(); RenderTexture.active null; RenderTexture.ReleaseTemporary(rt); if (source ! null) { Destroy(source); } return result; }这段代码有几个容易出错的位置。第一ReadPixels之前必须确保RenderTexture.active指向当前 RT否则读出来会是黑图。第二Graphics.Blit默认复制 RGBA能正确保留透明通道不要多此一举改成别的混合模式。第三RenderTexture.GetTemporary拿到的 RT 用完必须ReleaseTemporary否则长时间运行的设备上内存会持续增加。3.5 动态生成 Material 并应用到模型贴图到手后要把它挂到材质上并应用给模型。基础版本public void ApplySkin(Texture2D texture, Renderer targetRenderer) { if (texture null || targetRenderer null) return; Material baseMat skinBaseMaterial; // Inspector 里指定的预设材质 Material mat new Material(baseMat); mat.mainTexture texture; mat.SetFloat(_Glossiness, 0.2f); targetRenderer.material mat; }这里不推荐用Shader.Find(Standard)直接创建材质原因有两条。第一项目切到 URP 后Shader.Find(Standard)可能返回空或不是预期 Shader。第二运行时 Shader.Find 有字符串查找开销Shader 如果没有提前进入构建列表还有可能被裁剪导致模型变紫粉色。最稳的做法是在 Inspector 上拖一个基础材质skinBaseMaterial运行时用new Material(baseMat)克隆再改纹理属性。多模型共用材质时建议改成MaterialPropertyBlockprivate static readonly int BaseMapID Shader.PropertyToID(_BaseMap); // URP 主纹理 public void ApplySkinWithBlock(Texture2D texture, Renderer targetRenderer) { MaterialPropertyBlock block new MaterialPropertyBlock(); targetRenderer.GetPropertyBlock(block); block.SetTexture(BaseMapID, texture); targetRenderer.SetPropertyBlock(block); }需要确认渲染管线Standard Shader 的主纹理属性名是_MainTexURP Lit 是_BaseMap用Shader.PropertyToID缓存 ID 可以避免重复字符串查找性能更好。3.6 AR 场景整合让模型出现在真实世界模型在普通场景换肤成功后放到 AR 场景里还需要让它稳定出现在摄像头识别的位置。假设用 AR Foundation 的ARTrackedImageManager识别一张涂色卡或参考图流程是识别成功 → 生成模型根节点 → 等用户选图换肤 → 根据包围盒调整位置和缩放把模型立在卡片上。private void PlaceModelOnTrackedImage(GameObject modelRoot, ARTrackedImage trackedImage) { Bounds bounds new Bounds(modelRoot.transform.position, Vector3.zero); foreach (Renderer r in modelRoot.GetComponentsInChildrenRenderer()) { bounds.Encapsulate(r.bounds); } float halfHeight bounds.extents.y; modelRoot.transform.SetParent(trackedImage.transform, false); modelRoot.transform.localPosition new Vector3(0f, halfHeight, 0f); modelRoot.transform.localEulerAngles new Vector3(0f, 180f, 0f); }这块代码解决的是模型的姿态问题。很多美术做模型时中心点默认在脚底或几何中心直接在识别图像上摆必然出现陷一半或者飘起来。所以我用所有子 Renderer 的包围盒重新计算高度偏移以几何中心为锚点。这个办法对大部分角色模型都适用如果模型本身朝向有问题再单独微调欧拉角即可。4. 实战踩坑图片方向、比例拉伸、内存与光照4.1 EXIF 方向导致皮肤躺倒在测试一台 Android 时用户从相册选了一张竖着拍的宠物照片换到模型上之后贴图却是横着的。排查很久发现是 JPEG 的 EXIF 信息在作怪。很多手机相机在拍照时会往 JPEG 文件头写入 Orientation 字段告诉图片查看器应该旋转多少度显示。Texture2D.LoadImage不会自动解析这个字段只会按文件原始像素排列加载。结果就是相册预览时系统按 EXIF 自动旋转了Unity 加载时却和文件原始像素一致两边方向不一致。解决办法是加载后读取 EXIF Orientation 并手动旋转贴图public static Texture2D RotateTexture(Texture2D source, int orientation) { switch (orientation) { case 3: return Rotate180(source); case 6: return Rotate90CW(source); case 8: return Rotate90CCW(source); default: return source; } }完整的 EXIF 解析代码比较长通常是解析 JPEG APP1 段里的 IFD0 标签 0x0112。社区里有现成实现直接搜C# EXIF orientation Unity就能找到。建议把那套代码做成一个静态工具类以后所有涉及相册图片的项目都能复用。注意一点有些开源库解析不到 Orientation 时返回 0 或 1这两种情况按不旋转处理不要误伤。4.2 图片比例和 UV 比例不一致导致拉伸第二个高概率问题模型的某个部位 UV 展开区域可能是 1:1 的方块也可能是整块 2:1 的长条。用户上传的图片比例如果和 UV 区域比例相差很大贴上去图案会立刻变形。方案有三种我最推荐第三种。第一种是代码居中裁剪按目标比例从图片中心截取一块再应用简单但会丢画面内容。第二种是调整 Tiling通过_MainTex_ST的缩放让图片不变形地覆盖表面缺点是部分 UV 区域可能覆盖不到或纹理重复。第三种是在 UI 层让用户先裁剪比如用 UGUI 的 RawImage 加固定长宽比遮罩用户自己调整构图后再提交结果最可控体验也最好。这里给一个居中裁剪的参考实现注意要在降采样之后再执行public static Texture2D CropToAspect(Texture2D source, float aspect) { float sourceAspect (float)source.width / source.height; if (Mathf.Approximately(sourceAspect, aspect)) return source; int cropW source.width; int cropH Mathf.RoundToInt(cropW / aspect); if (cropH source.height) { cropH source.height; cropW Mathf.RoundToInt(cropH * aspect); } int startX (source.width - cropW) / 2; int startY (source.height - cropH) / 2; Color[] pixels source.GetPixels(startX, startY, cropW, cropH); Texture2D result new Texture2D(cropW, cropH, TextureFormat.RGBA32, false); result.SetPixels(pixels); result.Apply(); return result; }4.3 Android 大图内存与 OOM我的测试机是一台中端 Android8GB 内存加载 4000x3000 原图时会有明显卡顿再大一点的图甚至直接闪退。除了降采样还有几个配套习惯要养成解码完成后立刻把byte[]引用置空让 GC 能尽快回收原始文件数据。LoadImage出来的临时纹理在降采样或替换到材质后如果没有其他引用要记得Destroy。很多内存泄漏其实就出在这种临时贴图忘记释放。同一时间反复换肤时先把旧贴图Destroy再加载新的避免峰值内存叠加。可以先让材质退回基础贴图再加载新图。4.4 AR 场景下的光照与阴影问题换肤完成后还有一个观感问题材质如果保留默认高光参数在 AR 真实环境下会显得非常塑料像一块发光体压在桌面上。AR 场景的光照来源是真实环境光所以模型材质要迎合环境光。Unity AR Foundation 在移动端提供环境光估计可以获取环境光的颜色和强度并设置到场景的 Directional Light 上。如果是 URP建议打开 Environment Probe或者至少把 Directional Light 的强度绑定到环境光估计值。模型_Glossiness控制在 0.1~0.3 之间不要出现大面积镜面高光。阴影方面移动端 AR 的模型阴影本身是个难题。地面识别质量好可以用平面阴影或简单透明阴影面片地面识别不稳定不如直接关闭实时阴影用模型底部的柔和径向渐变模拟接触阴影。这个细节在互动屏场景里很重要因为用户第一眼看的就是模型是否贴合真实世界。5. 进阶玩法多部位换肤、截图分享与性能优化5.1 多部位换肤的映射思路很多模型不止一个 MeshRenderer比如角色分为头、上装、下装、鞋。做多部位换肤之前先在模型上给每个 Renderer 取好名字如slot_head、slot_body生成名称到 Renderer 的映射表然后在 UI 里让用户选择部位、上传图片分别赋给对应材质。Dictionarystring, Renderer slotMap new Dictionarystring, Renderer(); foreach (Renderer r in model.GetComponentsInChildrenRenderer()) { slotMap.Add(r.gameObject.name, r); }批量替换时循环赋值即可。每个部位的 UV 区域比例不同建议给每个部位独立配置目标宽高比或者统一使用自由裁剪模式让用户自己调整情况会简单很多。5.2 把作品保存成图片分享AR 涂涂乐完成后用户大概率想把成果截图发出去。直接ScreenCapture.CaptureScreenshot会把整屏 UI 和背景一起截进去观感不好。更可控的方法是单独渲染模型到 RenderTexture再保存 PNGRenderTexture rt RenderTexture.GetTemporary(1024, 1024, 16, RenderTextureFormat.ARGB32); Camera cam GetComponentCamera(); cam.targetTexture rt; cam.Render(); RenderTexture.active rt; Texture2D snap new Texture2D(1024, 1024, TextureFormat.RGBA32, false); snap.ReadPixels(new Rect(0, 0, 1024, 1024), 0, 0); snap.Apply(); RenderTexture.active null; cam.targetTexture null; RenderTexture.ReleaseTemporary(rt); byte[] pngBytes snap.EncodeToPNG(); NativeGallery.SaveImageToGallery(pngBytes, MyApp, skin_ System.DateTime.Now.Ticks .png);透明背景需要把 Camera 的 clear flags 设为固定颜色并把 alpha 设为 0同时确保渲染背景用的材质支持透明。这个方法很适合做作品墙和每日最佳作品这类社区功能。5.3 性能与内存优化清单换肤功能在移动端跑稳关键是控制内存、显存和解码卡顿。整理一份实际可用的优先级清单优先级优化项说明高限制贴图最大尺寸为 2048大部分模型足够内存可降到原图 1/4高延迟/异步加载图片避免选图回调解码造成几百毫秒卡顿高替换用 MaterialPropertyBlock避免创建大量材质实例中纹理格式使用 ASTCAndroid显存带宽更好中频繁换肤时先销毁旧贴图控制内存峰值低关键 Shader 加入 Always Included防止小游戏/动态加载时被裁剪5.4 微信小游戏与 Web 端打包的差异如果项目最终要发成微信小游戏有两件事必须提前处理。第一File.ReadAllBytes不能直接用于小游戏的沙盒文件更稳妥的做法是先用UnityWebRequestTexture加载本地临时文件或者通过微信 API 拿到图片本地临时路径后再读取字节。第二小游戏环境对 Shader 裁剪很激进运行时Shader.Find一个不在预加载列表里的 Shader 很可能返回空模型直接变紫粉色。解决方法是在 Player Settings 的 Graphics 的 Always Included Shaders 里把用到的 Shader 都加进去或者全部改成预设材质 clone 的方式。WebGL 还要注意压缩格式兼容性ASTC 在部分 WebGL 环境可能不支持建议 Web 端统一用 RGBA32 或 DXT 纹理测试覆盖 Chrome 和 Safari 两种内核。我自己的开发习惯是每次拿到一个新模型第一件事就是先做棋盘格 UV 测试再把基础材质拖到 Inspector。这两个动作加起来不到两分钟但能同时避开UV 不对导致贴图扭曲和Shader 被裁剪导致模型变紫这两个最常见的坑。如果你的项目正在做类似功能建议按这个顺序推进先用一张测试图跑通相册 → 解码 → 换肤 → 显示再做多部位和分享。核心链路稳了后面都是锦上添花。
