OBJ模型文件的结构、导入与渲染Ⅰ
2016-06-21 18:28
381 查看
在[3DS文件结构的初步认识]中提及了3DS格式模型文件。固然3DS格式很常用,但OBJ格式的模型也是很常见的,于是咔嚓了一下心,熟悉了一下格式,并写了一个导入OBJ格式模型的类,顺便有此文。——ZwqXin.com
先总体说一下两种格式的不同处。比起二进制文件为主、连每个块的用途也得试探来试探去的3DS,文本文件为主的OBJ对我们更友好。与3DS文件的树状[块结构]不同,OBJ文件只是很单纯的字典状结构,没有块ID来表征名字而是简单地用易懂的表意字符来表示。总之看上去是赏心悦目的样子,而苦处也就只有实际写导入代码的时候才知道了-
-。OBJ文件优化了存储但劣化了读写,接下来慢解^^……
本文来源于 ZwqXin (http://www.zwqxin.com/), 转载请注明
原文地址:http://www.zwqxin.com/archives/opengl/obj-model-format-import-and-render-1.html
1. OBJ,从格式到读入
背景介绍一下吧,它的创始公司是Wavefront Technologies,最早的母体软件是Advanced Visualizer(8认识~),目前版本好像3.0,不含动画。由于有良好的移植性能,3dsMax、Maya一连串建模软件都可以随便导入和导出(印象记得自己唯一系统学过的建模软件ProE也有类似的选项?不过不太确定了)。反正通用性好网上提供的直接资源多,招人欢喜,不像.max那种深闺女,不像.x那种自宠儿……(我没有别的意思.obj您别误会。)换句话说,只要写好一个导入obj文件的工具类,就不用像之前那样到3dsMax里转成3ds再导入OpenGL了。
作为一种文本文件,什么文本查看器都能看,不像3DS那种乱麻麻的乱码。格式说明网上也有很详细的,这里随便找一篇写得挺好的:【ZT】3D中的OBJ文件格式详解(擦~这链接里的转帖不附原文链接实在是卑鄙无耻的行为!)。
#...(#是注释符)
mtllib pCube.mtl
g default
v -0.500000 -0.500000 0.500000
v 0.500000 -0.500000 0.500000
v 0.500000 -0.500000 -0.500000
....
vt 0.000000 0.000000
vt -1.000000 1.000000
.....
vn 0.000000 0.000000 1.000000
vn 0.000000 0.000000 -1.000000
.....
g pCube1
s off
usemtl initialShadingGroup
f 1/1/1 2/2/2 4/4/3
f 3/3/5 4/4/6 6/6/7
f 5/5/9 6/6/10 8/8/11 7/7/12
f 7/7/13 8/8/14 1/9/16
g pCube2
usemtl DefferShadingGroup
.....
a.可能包含顶点法线信息而不需自行计算。
当然了如果文件中没有法线信息那还是同样要计算的,不然在OpenGL里渲染起来会悲剧,至于这项数据存在的理由你自己列举吧,但是起码是不再需要相邻面法线取平均这种粗糙的手段,嘛不过储存量大了些;文件的第二部分是后半部的"面数据",与3DS类似的是每个面(f)利用索引指示的顶点属性来表示,但是——
b.索引指向整个数据区,且连同纹理坐标和法线,一个顶点的属性可能需要3个索引。
c.一个面至少要3组顶点属性,但3组以上组成一个面(多边形而非三角形)也是可能的。
前者引入导入时的一堆麻烦事,后面讲解。后者表示如果我们要用3D渲染系统渲染(目前主流是三角面片化,连四角面片也要慢慢不太溶于显卡了),就要在导入时切割面片人为三角面化。其实除了面还可能有点线曲线曲面之类的,此时只能无视之。另外这里还有几个标识符,组(g)标识一个独立物件(也就是3DS文件里的Object概念),每个组有其自己的材质(usemtl指定),如果几个组想共用一种材质的话,只需要改改顺序好了,因为usemtl也类似状态机会一直作用于后面的组直到下一句usemtl。标识s绝对可以选择性无视因为随便找个OBJ文件看上去就知道是个光滑组的概念了,我们没必要理会;第三部分是上面没显示的,它不属于obj后缀的文件但是OBJ文件的一部分——mtl材质库文件。在前面指定材质usemtl后也就简单的一个名字,它代表的东西可以在obj文件附带的mtl文件中找到。这个mtl文件在obj文件中mtllib指定,上面一段,就是pCube.mtl了,注意要在使用材质前指定。相对来说,mtl文件的格式更加复杂:
newmtl InitialShadingGroup
illum 4
Kd 0.50 0.50 0.00
Ka 0.10 0.10 0.10
Tf 1.00 1.00 1.00
map_Kd -s 1 1 1 -o 0 0 0 -mm 0 1 desertHouse_details_color.tga
bump -bm desertHouse_details_normal.tga
Ni 1.00
Ks 0.00 0.00 0.00
map_Ks desertHouse_details_specular.tga
Ns 18.00
newmtl DefferShadingGroup
....
d.Obj模型中各对象都可能包含多种纹理贴图类型
好了,格式解释好,就要开始解析(parsing)了。
首先是要定下导入数据的数据结构。以CLoad3DS类[一个读取3DS文件的类CLoad3DS浅析Ⅰ]中3DS的数据格式为基础,在实际导入代码编写过程中增减数据成员,是比较稳妥的。按照模型对象数据(obj文件)+ 材质数据(mtl)的分法,将模型确定为:
//模型信息结构体
typedef struct tag3DModel
{
bool bIsTextured; //是否使用纹理
std::vector<tMaterialInfo> tMatInfoVec; // 材质信息
std::vector<t3DObject> t3DObjVec; // 模型中对象信息
}t3DModel;
其中材质数据体直接按照所需的材质属性据在mtl材质库中找到对应项,并以名称为标识。绝大多数情况下obj文件里要引用所有的材质(当然是不一定但是为了导入方便就这么假定好了),我的策略是当读obj文件读到mtllib标识的时候就马上打开对应的mtl文件把所有材质读入里面tMatInfoVec,再返回obj文件。当后面读到usemtl的时候再按名称查找tMatInfoVec。遇到纹理文件的时候,直接生成纹理ID并保存,另外每种纹理会有一个对应的nTexObjX*数据变量指示该纹理在使用过程中所在的纹理对象(毕竟同一材质的这些纹理基本是要多重贴图[MultiTexture]的),在读入的时候只给DiffuseTex默认GL_TEXTURE0,其他置0,这些值一般是需要的时候再由应用层去设置的,我们的导入类单纯生成所有纹理但只会在渲染的时候使用DiffuseTex(我对是否该在应用层指定的时候才生成其他对应的纹理,留个问号,毕竟实际场合下如果材质中有,我们多半是要用的,而延后生成纹理就很被动了。空间与效率的争夺啊。):
// 材质信息结构体
typedef struct tagMaterialInfo
{
char strName[MAX_NAME]; // 纹理名称
GLfloat crAmbient[4];
GLfloat crDiffuse[4];
GLfloat crSpecular[4];
GLfloat fShiness;
GLuint nDiffuseMap;
GLuint nSpecularMap;
GLuint nBumpMap;
GLuint TexObjDiffuseMap;
GLuint TexObjSpecularMap;
GLuint TexObjBumpMap;
}tMaterialInfo;
// 对象信息结构体
typedef struct tag3DObject
{
int nMaterialID; // 纹理ID
bool bHasTexture; // 是否具有纹理映射
bool bHasNormal; // 是否具有法线
std::vector<Vector3> PosVerts; // 对象的顶点
std::vector<Vector3> Normals; // 对象的法向量
std::vector<TexCoord> Texcoords; // 纹理UV坐标
std::vector<unsigned short> Indexes; // 对象的顶点索引
unsigned int nNumIndexes; // 索引数目
GLuint nPosVBO;
GLuint nNormVBO;
GLuint nTexcoordVBO;
GLuint nIndexVBO;
}t3DObject;
先总体说一下两种格式的不同处。比起二进制文件为主、连每个块的用途也得试探来试探去的3DS,文本文件为主的OBJ对我们更友好。与3DS文件的树状[块结构]不同,OBJ文件只是很单纯的字典状结构,没有块ID来表征名字而是简单地用易懂的表意字符来表示。总之看上去是赏心悦目的样子,而苦处也就只有实际写导入代码的时候才知道了-
-。OBJ文件优化了存储但劣化了读写,接下来慢解^^……
本文来源于 ZwqXin (http://www.zwqxin.com/), 转载请注明
原文地址:http://www.zwqxin.com/archives/opengl/obj-model-format-import-and-render-1.html
1. OBJ,从格式到读入
背景介绍一下吧,它的创始公司是Wavefront Technologies,最早的母体软件是Advanced Visualizer(8认识~),目前版本好像3.0,不含动画。由于有良好的移植性能,3dsMax、Maya一连串建模软件都可以随便导入和导出(印象记得自己唯一系统学过的建模软件ProE也有类似的选项?不过不太确定了)。反正通用性好网上提供的直接资源多,招人欢喜,不像.max那种深闺女,不像.x那种自宠儿……(我没有别的意思.obj您别误会。)换句话说,只要写好一个导入obj文件的工具类,就不用像之前那样到3dsMax里转成3ds再导入OpenGL了。
作为一种文本文件,什么文本查看器都能看,不像3DS那种乱麻麻的乱码。格式说明网上也有很详细的,这里随便找一篇写得挺好的:【ZT】3D中的OBJ文件格式详解(擦~这链接里的转帖不附原文链接实在是卑鄙无耻的行为!)。
#...(#是注释符)
mtllib pCube.mtl
g default
v -0.500000 -0.500000 0.500000
v 0.500000 -0.500000 0.500000
v 0.500000 -0.500000 -0.500000
....
vt 0.000000 0.000000
vt -1.000000 1.000000
.....
vn 0.000000 0.000000 1.000000
vn 0.000000 0.000000 -1.000000
.....
g pCube1
s off
usemtl initialShadingGroup
f 1/1/1 2/2/2 4/4/3
f 3/3/5 4/4/6 6/6/7
f 5/5/9 6/6/10 8/8/11 7/7/12
f 7/7/13 8/8/14 1/9/16
g pCube2
usemtl DefferShadingGroup
.....
整个OBJ文件可以分成三个部分:第一部分是文件前半部的“顶点数据”部分——指定了模型所用到的全部顶点(v)、顶点纹理坐标(vt)、顶点法线(vn)。(括号里是数据的行头标识)其中顶点(位置)数据是必须的,纹理坐标只在对应的物件处有纹理时才必须,法线也是非必须的但是要注意的,也许你还记得在[一个读取3DS文件的类CLoad3DS浅析Ⅰ/一个读取3DS文件的类CLoad3DS浅析Ⅱ]两篇文章中提及3DS是不包含法线信息需要我们自己去计算,这就是OBJ文件相对3DS第一个大特点——
a.可能包含顶点法线信息而不需自行计算。
当然了如果文件中没有法线信息那还是同样要计算的,不然在OpenGL里渲染起来会悲剧,至于这项数据存在的理由你自己列举吧,但是起码是不再需要相邻面法线取平均这种粗糙的手段,嘛不过储存量大了些;文件的第二部分是后半部的"面数据",与3DS类似的是每个面(f)利用索引指示的顶点属性来表示,但是——
b.索引指向整个数据区,且连同纹理坐标和法线,一个顶点的属性可能需要3个索引。
c.一个面至少要3组顶点属性,但3组以上组成一个面(多边形而非三角形)也是可能的。
前者引入导入时的一堆麻烦事,后面讲解。后者表示如果我们要用3D渲染系统渲染(目前主流是三角面片化,连四角面片也要慢慢不太溶于显卡了),就要在导入时切割面片人为三角面化。其实除了面还可能有点线曲线曲面之类的,此时只能无视之。另外这里还有几个标识符,组(g)标识一个独立物件(也就是3DS文件里的Object概念),每个组有其自己的材质(usemtl指定),如果几个组想共用一种材质的话,只需要改改顺序好了,因为usemtl也类似状态机会一直作用于后面的组直到下一句usemtl。标识s绝对可以选择性无视因为随便找个OBJ文件看上去就知道是个光滑组的概念了,我们没必要理会;第三部分是上面没显示的,它不属于obj后缀的文件但是OBJ文件的一部分——mtl材质库文件。在前面指定材质usemtl后也就简单的一个名字,它代表的东西可以在obj文件附带的mtl文件中找到。这个mtl文件在obj文件中mtllib指定,上面一段,就是pCube.mtl了,注意要在使用材质前指定。相对来说,mtl文件的格式更加复杂:
newmtl InitialShadingGroup
illum 4
Kd 0.50 0.50 0.00
Ka 0.10 0.10 0.10
Tf 1.00 1.00 1.00
map_Kd -s 1 1 1 -o 0 0 0 -mm 0 1 desertHouse_details_color.tga
bump -bm desertHouse_details_normal.tga
Ni 1.00
Ks 0.00 0.00 0.00
map_Ks desertHouse_details_specular.tga
Ns 18.00
newmtl DefferShadingGroup
....
通常mtl文件和纹理文件要和联系的obj文件放在一起。看上面,这里newmtl指定新材质的名称,以供obj文件中对应查询,后面一列会是材质属性,全部属性实在太多了,详情请看这篇文章,很详细:Alias/WaveFront Material (.mtl) File Format。这里挑几个重点的,也是我后面的导入程序主要关心的部分:环境光反射材质(Ka)、漫反射光材质(Kd)、镜面反射材质(Ks)、镜面反射的Exponent(Ns,即常说的Shinness),OpenGL同学们记得吗,以上可以用glMaterialf(v)可指定,只是其中Ns要做个转换从[0,1000]到OpenGL一般光照模型的[0,128]。d/Tr是指透明度(alpha通道),map_Kd是我们最关心的纹理,map_Ks是镜面纹理(SpecularMap)、bump是法线纹理(Bump Map/Normal Map,见【shader复习与深入:Normal Map(法线贴图)Ⅰ/shader复习与深入:Normal Map(法线贴图)Ⅱ】)。(另外提一下资料中提及的map_Ka是环境光纹理,map_Ns是Shinness纹理,map_d是透度纹理,decal是贴花纹理,disp不清楚[说是指示表面粗糙度],这些都相对在3d程序中少用,如果实在需要再重载我的导入类好了。)
d.Obj模型中各对象都可能包含多种纹理贴图类型
好了,格式解释好,就要开始解析(parsing)了。
首先是要定下导入数据的数据结构。以CLoad3DS类[一个读取3DS文件的类CLoad3DS浅析Ⅰ]中3DS的数据格式为基础,在实际导入代码编写过程中增减数据成员,是比较稳妥的。按照模型对象数据(obj文件)+ 材质数据(mtl)的分法,将模型确定为:
//模型信息结构体
typedef struct tag3DModel
{
bool bIsTextured; //是否使用纹理
std::vector<tMaterialInfo> tMatInfoVec; // 材质信息
std::vector<t3DObject> t3DObjVec; // 模型中对象信息
}t3DModel;
其中材质数据体直接按照所需的材质属性据在mtl材质库中找到对应项,并以名称为标识。绝大多数情况下obj文件里要引用所有的材质(当然是不一定但是为了导入方便就这么假定好了),我的策略是当读obj文件读到mtllib标识的时候就马上打开对应的mtl文件把所有材质读入里面tMatInfoVec,再返回obj文件。当后面读到usemtl的时候再按名称查找tMatInfoVec。遇到纹理文件的时候,直接生成纹理ID并保存,另外每种纹理会有一个对应的nTexObjX*数据变量指示该纹理在使用过程中所在的纹理对象(毕竟同一材质的这些纹理基本是要多重贴图[MultiTexture]的),在读入的时候只给DiffuseTex默认GL_TEXTURE0,其他置0,这些值一般是需要的时候再由应用层去设置的,我们的导入类单纯生成所有纹理但只会在渲染的时候使用DiffuseTex(我对是否该在应用层指定的时候才生成其他对应的纹理,留个问号,毕竟实际场合下如果材质中有,我们多半是要用的,而延后生成纹理就很被动了。空间与效率的争夺啊。):
// 材质信息结构体
typedef struct tagMaterialInfo
{
char strName[MAX_NAME]; // 纹理名称
GLfloat crAmbient[4];
GLfloat crDiffuse[4];
GLfloat crSpecular[4];
GLfloat fShiness;
GLuint nDiffuseMap;
GLuint nSpecularMap;
GLuint nBumpMap;
GLuint TexObjDiffuseMap;
GLuint TexObjSpecularMap;
GLuint TexObjBumpMap;
}tMaterialInfo;
然后就是对象数据了——或者我应该在下篇中再详细结合导入过程讲,先给出数据结构一览:
// 对象信息结构体
typedef struct tag3DObject
{
int nMaterialID; // 纹理ID
bool bHasTexture; // 是否具有纹理映射
bool bHasNormal; // 是否具有法线
std::vector<Vector3> PosVerts; // 对象的顶点
std::vector<Vector3> Normals; // 对象的法向量
std::vector<TexCoord> Texcoords; // 纹理UV坐标
std::vector<unsigned short> Indexes; // 对象的顶点索引
unsigned int nNumIndexes; // 索引数目
GLuint nPosVBO;
GLuint nNormVBO;
GLuint nTexcoordVBO;
GLuint nIndexVBO;
}t3DObject;
纹理ID是用来指涉tMatInfoVec的,对象名字就免去了,减少储存。值得注意的是,我这里没有使用任何跟“面”有关的数据,但是导入过程是读“面”无误,这里头有个转化关系。不然什么是”OBJ文件优化了存储但劣化了读写“呢?——很明显我要动用VBO(顶点缓存对象,见【学一学,VBO】),而且还是Indexed VBO!
相关文章推荐
- 自定义抛出异常
- AWK的NR和FNR详解
- KahaDB简介
- 个人博客地址,http://devopslinux.com/
- PyQt5 第二篇 #应用程序图标
- ado显示,删除后刷新重新显示
- 9-9-B+树-查找-第9章-《数据结构》课本源码-严蔚敏吴伟民版
- 几个Java分隔后组装sql查询示例
- okhttp连接池复用机制
- 字符串拼接技术
- 编程之美2.10寻找数组中的最大值和最小值扩展问题Java版
- 认识nginx
- ado删除
- NYOJ 63 小猴子下落 (二叉树优化)
- MQTT基础——Part 2. 发布/订阅模式
- Hadoop源码分析之二(RPC机制之Call处理)
- canvas 裁切路径 Clipping paths
- 中华人民共和国计算机信息系统安全保护条例
- Socket粘包,分包解决方法和算法
- 流程预览 ?