news 2026/9/30 5:40:27

3D角色资源制作规范:从面数预算、UV贴图到MaxScript检查

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
3D角色资源制作规范:从面数预算、UV贴图到MaxScript检查

简介:《3D角色资源制作规范详解》是一份面向 3D 游戏与动画制作团队、角色建模师的实操性规范文档,用于统一角色资源在模型、UV、贴图和命名上的制作标准,降低后期返工与沟通成本。资源压缩包共 1 个文件,为 docx 格式文档,大小约 4.89MB,以《死神》角色为案例详细展开:模型阶段包括原画分析、三维重建和三角面数控制,人物与武器通常控制在 1500~2000 面,复杂角色可到 2500 面,大型 BOSS 为 3000~5000 面;UV 展开要求 PSD 图层做选区,贴图建议先画 1024×1024 再缩小为 512×512 的 tga,角色与武器共用同一贴图;文件命名规范则给出不同角色形态的拼音命名示例。资源还整理了后期检查要点,包括坐标轴与旋转轴归零、光滑组统一为 1、材质球命名、多余点焊接清理等,可直接作为团队内部规范模板或项目自查清单使用。目前已有 110 人学习下载,适合初入行的角色建模人员系统熟悉标准流程,也适合项目组长用来对齐上下游协作要求。

1. 一份能救命的 3D 角色资源制作规范:它把「看着差不多」变成「能直接进引擎」

接到《死神》这类量产角色项目的第一周,我就被返工单砸晕过:模型导入引擎歪着、贴图一放大就糊、武器和角色分开命名导致材质球多到爆、面数统计出来超预算一倍。逼着我干了一件事——把团队手里那份《3D角色资源制作规范.docx》从头到尾走了一遍。它不是讲大道理的美术标准,就是一张写满数字和命名规则的执行清单:三角面多少、tga 多大、焊接阈值多少、坐标轴归零没、光滑组是几。这份资源制作规范能解决的是量产环节最常见的五类返工:面数失控、UV 和贴图来回改、命名混乱、坐标轴歪、交付后没法维护。适合谁?刚进项目组被验收流程反复打回的 3D 角色建模师,或者小团队想给资产定一套大家都能守住的规矩的人。原文是一份 Word 文档,但里面每一条都能直接落地成你项目里的检查表。

2. 建模标准:面数预算、结构确认与关节布线

2.1 面数不是拍脑袋:1500/2500/5000 三档怎么对号入座

规范里最容易被当成「建议」实际是「硬指标」的,就是三角面数。先说清楚一个概念:游戏和引擎里统计的面数,指的是三角面(Triangles),不是 Max 里显示的四边形面。一个四边形拆成三边形成两个三角面,但你建模时看到的四边网格和引擎里的面数统计是两套口径。规范里所有数字说的都是三角面,这一条不先对齐,后面全乱。

再看具体数值:人物卍解和武器一起控制在 1500~2000 三角面左右,个别太复杂的可以到 2500 面,但其他简单的部件要权衡着拉回 1500 面;大型 BOSS 在 3000~5000 面。这里有个关键点,面数是「角色 + 武器合计」,不是角色算一份武器算一份。很多新人第一次提交,角色本身就 1800 面,武器又单独占了 600 面,合计直接破 2500,验收时被拒还不知道为什么。

我习惯把预算拆成三档表,建模前就定死:

资产类型面数预算典型场景
普通角色(含武器)1500~2000 三角面量产角色,可控范围内优先保视觉
复杂角色(含武器)放宽至 2500 三角面细节多的主视觉角色,但要用简单部件换回来
大型 BOSS3000~5000 三角面体型大、特效多,面数预算按体型翻倍

放在当时的项目背景看,Max 9 配合这个面数档位,说明目标平台是移动端或者低模量产级别。放到现在的 PC 高模流程,这套数字显然不够用,但它的核心思想完全不过时:面数是有限资源,必须先定总额度,再按视觉优先级分配。我一般会把武器单独列一行预算,比如角色 1600 面、武器 400 面,合计 2000 面封顶,这样后面不会互相挤占。另外「卍解」是《死神》里的解放形态概念,对应到制作上就是角色换形态时,模型和贴图都走同一套命名规则,这在第 4 章展开。

2.2 拿到原画先别动手:结构确认与三头身比例

规范原文第一条写得很朴素:「拿到原画提供的设计稿,先仔细分析,如果有不清楚的结构或者问题直接找负责改任务的原画沟通或者补充说明」。这句话看着像废话,实际上决定了后面返工成本的 80%。角色建模不像场景物件,一个腰带扣的结构没看懂、一个飘带的穿插关系没确认,你按自己的理解做出来,原画验收时一句「这不是我画的」,整个模型重来。

我的做法是动手前先列三行确认清单:一是所有部件的正侧背三视图是否齐全,二是每个部件的材质区分(布料、金属、皮肤)是否明确,三是有没有隐藏结构——比如披风内侧的颜色、武器刃口有没有纹理。这些确认完,写个简短邮件或者群里留个文字记录,别口头确认完就开干。后面如果原画改了设计,这条记录就是你要求改模型工期的最硬依据。

这套规范针对的是三头身风格,头身比约 1:3,Q 版化造型。三头身有个特点:头和躯干的视觉占比大,四肢短小,武器反而会显得很大。所以低面数下要保的是头雕和上半身的主轮廓,腿脚因为大部分时间被阴影盖住,可以适当减面。肩关节和髋关节的布线要比正常头身比更密一圈,否则 Q 版角色做蹲起动作时,肩窝会穿模。

模型大小也要在最开始定死:以厘米为单位。Max 默认单位是英寸,新建场景第一件事就是把 System Unit Setup 改成 Centimeters,再确认 Display Unit 也切成厘米。这一步不做,模型导进引擎后要么巨大无比要么微缩到看不见,全靠手动 scale 是玄学。我和团队踩过这个坑:一个角色在 Max 里看着正常,导进 Unity 变成 0.5 米高的小人,整个骨骼比例全错,最后发现是单位没统一。

2.3 布线、焊接与无效点:关节处的取舍逻辑

面数定了、结构确认了,真正拉开水平差距的是布线。规范里原话是:「布线:关节位置要方便动作绑骨骼」,以及「点:不要有多余的点,选中所有的点,焊接 Weld,数值为 0.1,点击删除无效点」。

关节位置的布线逻辑其实一句话就能讲透:肘、膝、腕、指根这几个动得最狠的地方,必须有足够多的环线撑住形变。常见错误是关节处布了一个大三角面,绑定后动骨骼,刷权重时那一块怎么刷都像被折断,因为网格拓扑没有提供足够的边给权重过渡。建模时我会先在关节处切出一圈环形边,确保至少三圈线围绕关节,膝盖弯曲 90 度后外侧褶皱和内侧挤压才能在低面数下看起来不塌。

删除无效点的操作,规范给了明确数值:Weld 阈值 0.1。这个数值不是随便拍的——它是「保留有效拓扑」和「清除重复点」之间的平衡点。选中所有点,用 0.1 的阈值焊接,作用是合掉完全重合或极近的重复顶点,同时不会把距离稍远的正常顶点错误合并。焊接完再点一次 Remove Isolated Vertices(删除孤立点),那些不构成任何面的游离点就会被清掉。这两个操作做完,整个模型的顶点才算「干净」。

光滑组这里先不展开,但布线时有一个提前量要知道:如果最后光滑组统一设为 1,意味着整个模型被当成一个连续曲面处理,那么本应该有硬边的位置——比如剑刃、铠甲边缘——就全靠真实的几何转折去表现,不能指望光滑组的硬边功能帮你切一条棱。所以低面数下做硬表面,要么在需要硬边的位置多给两条边,要么接受它被平滑糊掉的代价。

3. UV 与贴图规范:从 PSD 选区的后路到 512 交付的锐化细节

3.1 UV 示范与 PSD 选区:把后期调整的成本压到最低

规范里单独放了一块「UV 示范」和「贴图精细度示范」,配图部分我没法在这里贴出来,但它文字里藏的要点比图更有价值:「PSD 图层要做选区,方便后期调整」。这句话翻译成执行标准就是:你交付的 PSD 贴图里,每个部件的图层必须独立,而且在画色彩之前先建好对应部件的选区。

为什么强调选区?因为量产项目的贴图不是画完就完,后面有大量微调:角色换配色、武器加特效光、某个部件要单独做 2 套材质变化。如果所有颜色都糊在一个图层上,调整等于重画;如果一开始就把每个部件的选区存在 PSD 里,三步就搞定了——载入选区、调色相、存 tga。做选区还有一个隐藏好处:保证 UV 分配层面每个部件互不重叠、互不越界。你在 PSD 里按选区检查 UV 分布,比在 Max 里对着 UVW Editor 看直观得多。

UV 展开本身没有模型那么玄,但有几个判据我建议新人直接抄:整体 UV 使用率至少要占满 512 贴图有效区域的 85% 以上,剑这类细长物体尽量竖直摆放填充剩余空间,避免大块留白;对称部件(左右手、左右脚)要叠 UV 以省空间,这一点在角色和武器共用一个贴图时尤其关键。展开后 Uniform Shell 检查一遍,每个块的分辨率比例要和视觉占比成正比——头部的 UV 块密度要明显高于腿部,这个资源的视觉中心是头和武器。

3.2 1024 作画、512 交付:tga 缩小与锐化的完整流程

贴图规格原文写得很细:「tga 512*512(可以先画 1024*1024,最后存 tga 的时候缩小之后锐化一下就可以)」。这条流程背后的原因值得多说两句。先高分辨率作画,是因为 512 画布下画细节非常憋手,一个笔刷下去就是好几个像素,根本画不进去;而 1024 到 512 的缩小过程,会让边缘细节损失一大部分,最直接的补救就是缩小后加锐化。

实际操作路径我一般是这样:先按 1024 画完所有细节,确认视觉没问题;然后 PS 里 Image Size 缩到 512,采样方式用 Bicubic Sharper(双三次锐化);缩完以后加一次滤镜里的 USM 锐化,数量 60%~80%,半径 1.0 像素左右。存 tga 的时候有一个很多人忽略的选项:分辨率要选 32-bit,勾选 Alpha 通道为直通(Straight Alpha)。如果选错成 Premultiplied,角色进引擎后边缘会出现一圈黑边,那是因为半透明像素的 RGB 被预乘改变了。

另一个细节:角色和剑用同一张贴图。这个设计一是省显存预算,二是保证武器和角色在相同光照条件下的颜色统一——你单给武器画一张,光照调色再准也难免有色差。代价就是 UV 布局时武器要跟角色挤在同一个 512 空间里,这正好倒逼你提高 UV 利用率。规范里要求 PSD 和 tga 两种格式都要交付,这份文档虽然只是 Word 形式,但它描述的这套「双保险」思路值得直接抄:PSD 是源文件,用来改;tga 是交付文件,用来进引擎。源文件和交付文件分离,是贴图制作这条线上我能想到性价比最高的习惯。

顺带说一个贴图精细度的判断标准,规范里给了示范图但没法贴出来,我把它转成可自查的规则:512 贴图上,角色脸部至少能看清眼白和瞳孔的边界;衣服纹理用色块过渡,不要用 1px 的细线去画花纹,因为那些线缩小后必然糊掉。凡是缩小后只剩一团灰的细节,都属于无效精度,最开始就不该画上去。

4. 命名规范与后期检查:三个必须守住的细节和五条避坑记录

4.1 文件命名规范:yihu_b.max 背后的信息编码

规范里的命名规则值得单独拆一节来讲,它是对文件内容最精准的编码。看原文的两个例子:黑崎一护变身前模型 & 动作叫 yihu_b.max,冬狮郎变身后模型 & 动作叫 dongshilang_t.max;贴图对应 yihu_b.tga 和 dongshilang_t.tga。

命名拆解是三层:角色名称拼音(yihu / dongshilang)、形态代号(b=base 初始、t=transform 变身)、文件类型(max / tga)。这套规则解决三个实际问题:一是中文文件名在引擎工具链和 Git 等版本管理工具里容易乱码,拼音最保险;二是形态代号让「变身前」和「变身后」两套资产在文件列表里天然排在一起,不会混淆;三是模型和贴图用同一套主名,美术找贴图、程序找资源时,扫一眼文件名就知道对应关系。

目录结构也有要求:放在 BLEACH/model 下。这个看起来简单,但在成百上千个角色的项目里,目录根路径是资源管理的第一道闸。我做过的项目里最常见的翻车方式,是把模型放 D:\work\角色\黑崎一护\最终版_v3\,贴图放另一个临时文件夹,项目中途文件管理器一搜全是「最终版」「真的最终版」「改死不改了」。规范直接用固定目录 BLEACH/model + 拼音命名,从根源上杜绝这种事。

还有一个细节很多人第一次看会忽略:max 文件本身也要有内部命名。规范里冬狮郎的例子,max 文件里要包括 dongshilang_b 和 dongshilang_b_jian——也就是说,场景内的模型对象的名字,和文件名是同构的。对象层级里的根节点叫 dongshilang_b,武器节点叫 dongshilang_b_jian。这样绑定动画的人拿到文件,不用展开场景就知道哪个节点是身体、哪个节点是武器。

4.2 材质、坐标轴与光滑组:交付前的最后一道闸

规范里「后期工作」这部分的每一句都值得抄成交付清单:删掉没用的材质、用第一个材质球、材质球和贴图名字用角色名、坐标轴和旋转轴归零、光滑组设为 1。先解释材质:max 文件里会有大量操作过程遗留的临时材质,直接交付会把材质球列表弄得巨长,接手的人根本不知道哪个是最终使用的。规范要求删到只剩一个材质球,且名称和角色名一致——角色和剑同一个材质球、同一张贴图。等价于告诉接手的人:你只需要看这一个材质球,其余删干净了。

坐标轴和旋转轴归零,这是导入引擎时最常出问题的位置。规范原话是「检查模型的自身坐标轴和旋转轴都为 0.0.0」。这里「自身坐标轴」指的是对象 Pivot(轴心点)在世界空间的位置归零,「旋转轴」其实指对象的旋转值归零。这两个值不归零,模型自身在 Max 里看着正常,但导出 FBX/OBJ 再导入引擎时,可能被引擎把偏移量当成动画初始姿态的一部分,导致角色进场景后是歪的,或者轴心点偏一万八千里,旋转动画整个绕错中心。

光滑组全为 1 的理解,要结合三头身和低面数背景来说。光滑组的作用是控制相邻面之间是平滑过渡还是硬边转折。如果光滑组出现杂乱分布——比如头部是 1 号光滑组、躯干是 2 号、手臂是 3 号——那相接位置会出现不自然的硬边接缝,看起来像破面。统一设成 1,整个模型被当作一个整体来平滑,是最稳妥的低模交付状态。代价是本来要硬边的地方也被平滑了,所以我在第 2 章说,建模时就该把硬边用真实几何转折做出来,而不是寄希望于光滑组。

规范里还有一条「模型大小:以厘米为单位」,前面第 2 章已经讲过,但要注意它出现在后期检查清单里,意味着这个检查要在模型做完之后、导出之前再做一次,而不是只在新建场景时设一次单位。我见过有人在新建时设了厘米,中途导入过一个英寸单位的参考模型,整个场景比例全乱,最后靠后期检查这条救回来。

4.3 五条高频坑:现象、原因与解决

以下五条是我按这份规范跑完整流程之后,在团队里反复遇到的真实问题,每条都是现象、原因、解决三段式,可以直接拿去给你的项目当验收问答:

  1. 现象:模型在 Max 里看着正常,导入引擎后整体偏移,旋转值带着莫名的 -90 度。 原因:导出前没有把对象旋转值和轴心点归零,max 默认的导入导出机制记录了这个偏移量。 解决:交付前全选对象,在 Hierarchy 面板把 Pivot 的位置、旋转全部清零;再选中对象用 Reset XForm 重置变换,把变换信息烘焙进基础几何,最后重新导出。

  2. 现象:512 的 tga 贴图在引擎里放大看全是模糊的色块,边缘还有白边。 原因:直接从 1024 缩到 512 没做锐化,且 tga 的 Alpha 通道选项用了 Premultiplied。 解决:按第 3 章的流程做——Bicubic Sharper 缩放、USM 锐化、存 32-bit tga 选直通 Alpha。锐化数量不够的话,边缘白边重新导一遍即可。

  3. 现象:执行「选中所有点 → Weld」之后,模型局部塌陷,出现一堆三角面拉丝。 原因:Weld 阈值被改大了。规范要求 0.1,很多人做模型的习惯是阈值 1 甚至 10,把所有靠近的点全焊到一起。 解决:严格按 0.1 执行。Weld 0.1 的作用只是合掉重合点和近似重合点,不是做整体减面。如果之前已经被大阈值焊坏,只能用历史记录撤销,所以执行前确认阈值输入框确实是 0.1。

  4. 现象:角色模型验收时面数统计爆表,但建模时每个部件看起来都不多。 原因:角色和武器分开了两套统计,或者武器圆柱用了过高的分段数。剑刃看起来简单,但一个 16 段的圆柱加剑柄、护手,轻松过 500 面。 解决:按「角色 + 武器合计」预算来分配。剑刃根数降到 8 段左右,剑身侧面用平面扩展加假厚度贴图补足,护手和剑柄尽量共用 UV 空间。

  5. 现象:过了一个月改版本,打开别人交的 max 文件,材质球列表五六十个,根本不知道哪个是最终材质。 原因:没有按命名规范交付,建模过程中的测试材质没清理。 解决:交付前删掉所有无用材质,保留唯一材质球并命名成角色拼音。接活的人在打开文件第一秒就能确认材质和贴图的状态,而不是花 20 分钟在材质编辑器里考古。

5. 把规范变成工具:MaxScript 自动检查与提交前自查

这一节给你一个能直接用的东西。规范里所有检查项都是手工操作,但其中有四项可以自动化,我写了个 MaxScript,每次交付前把模型全选、跑一遍,结果直接输出在 Listener 窗口。脚本代码如下:

-- 提交前资产检查脚本 -- 用法:在 3ds Max 中打开待交付的 max 文件,全选所有要交付的模型后执行 sel = selection as array if sel.count == 0 then ( messageBox "请先选择要检查的模型!" title:"资产检查" ) else ( for o in sel do ( local fc = 0 if superClassOf o == GeometryClass then ( if classOf o == Editable_Mesh then ( fc = o.numFaces ) else if classOf o == Editable_Poly then ( fc = polyop.getNumFaces o ) ) local posOK = (length o.pos < 0.001) local rotOK = (o.rotation == (quat 0 0 0 1)) format "模型:% 面数:% 位置零点:% 旋转归零:%\n" o.name fc posOK rotOK ) format "\n检查完成,确认以上输出,材质和光滑组请按规范手动确认。\n" )

输出里每个模型都会带面数统计和坐标轴状态。脚本逻辑拆开说:先判断选择集是否为空,为空就弹窗提醒;然后逐个判断对象是 Editable Mesh 还是 Editable Poly,分别取三角面数量;最后比较对象位置是否在世界原点、旋转值是否为单位四元数(quat 0 0 0 1)。位置和旋转的允许偏差我放宽到了 0.001,不做严格等于判断,避免浮点数误差导致误报。光滑组这一项我没写进脚本,因为在 Max 里逐面检查光滑组的脚本逻辑复杂且容易误报,我习惯只做手动操作:全选所有面,点击 1 号光滑组按钮,一步完成,比脚本更可靠。

脚本检查完,把第 4 章的检查清单再逐项过一遍:文件命名符合拼音 + 形态代号;目录在 BLEACH/model 下;模型内对象节点带 _jian 后缀;材质球只剩角色名那一个;贴图是 PSD + tga 双份;tga 是 512、32-bit、直通 Alpha;坐标轴旋转归零;光滑组全部为 1。这张表我建议直接打印出来贴显示器边上,每提交一个角色资产就在上面打一个勾。

我最后想说的是,规范文档再细,它也只是把「验收标准」写清楚了,真正让你少返工的是把它变成肌肉记忆。在那之前,我每次提交角色资产都强制自己跑一遍脚本、过一遍清单,尤其是坐标轴归零和光滑组这两项——一个治歪模型,一个治破面,都看起来不起眼,却是我见过返工率最高的两个位置。把这份规范吃透,再配上你自己项目里的检查表,后续的验收流程能省下一大半来回沟通的时间。希望帮到你。

本文还有配套的精品资源,点击获取

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/9/30 5:40:02

.NET Framework TLS协议握手失败解决方案

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

作者头像 李华
网站建设 2026/9/30 5:39:30

12球称重题的本质:信息论视角下的最优决策

1. 这道题不是考数学&#xff0c;而是考信息论的底层直觉“12个乒乓球&#xff0c;其中1个是次品&#xff08;不知轻重&#xff09;&#xff0c;用天平称3次找出它”——这道题在Google、微软、亚马逊等科技公司面试中反复出现&#xff0c;但绝大多数人一上来就陷入“怎么分组”…

作者头像 李华
网站建设 2026/9/30 5:39:17

UFS 3.1协议最难啃的两章:UIC链路与安全机制实战拆解

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

作者头像 李华
网站建设 2026/9/30 5:39:12

计算机网络基础知识:OSI、TCP/IP、TCP、UDP 分层排查实战指南

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

作者头像 李华
网站建设 2026/9/30 5:38:10

MCP协议实战指南:从核心原理到智能体集成的避坑手册

MCP协议最近在AI智能体圈子里几乎成了热议标配。大家天天喊着“打破数据孤岛”“让智能体协作起来”&#xff0c;但真被问到“MCP协议到底做了什么、怎么接入、坑在哪”&#xff0c;能讲透的人其实不多。我平时做智能体开发和数据系统集成&#xff0c;从最早的HTTP接口手工拼接…

作者头像 李华
网站建设 2026/9/30 5:36:46

Jev类型安全AI封装:密钥申请、SDK接入与API避坑指南

最近后台和评论区被同一个词刷屏了——Jev。有人问它是不是又一个套壳的AI工具&#xff0c;有人拿着"jev密钥"到处找申请入口&#xff0c;还有人把它和TypeSafe AI、System One Model这些概念混在一起聊。我花了两周时间把Jev相关的资料、SDK接入流程、API调用链路完…

作者头像 李华