转:Ogre的MaterialSystem分析

1. Mesh SubMeshSubEntityEntity

所有的Mesh对象是由SubMesh构成的,每个SubMesh代表了Mesh对象的一部分,该部分只能使用一种Meterial。如果一个Mesh只采用一种Material,那么它可能只包含一个SubMesh。

当基于Mesh创建出一个Entity时,该Entity由多个SubEntity构建而成, SubEntity与Mesh中的SubMesh一一对应。可以通过调用Entity::getSubEntity方法获得SubEntity。一旦得到SubEntity的指针,通过调用setMaterialName方法改变其Material。通过这种方法,可以改变所创建的Entity的默认Materials,从而使创建出来的Entity与众不同。

class SubMesh

{

RenderOperation::OperationType operationType;

VertexData *vertexData;

IndexData *indexData;

String mMaterialName;

};

通过代码可以看到SubMesh是保存顶点和顶点索引的类。

class Mesh: public Resource

{

typedef std::vector<SubMesh*> SubMeshList;

SubMeshList mSubMeshList;

}

通过代码可以看到Mesh是收集SubMesh的类。

class SubEntity: public Renderable

{

String mMaterialName;

MaterialPtr mpMaterial;

SubMesh* mSubMesh;

}

通过代码可以看到SubEntity与SubMesh和Material是一一对应的。

class Entity: public MovableObject, public Resource::Listener

{

MeshPtr mMesh;

typedef std::vector<SubEntity*> SubEntityList;

SubEntityList mSubEntityList;

}

通过代码可以看到Entity是收集SubEntity和Mesh的类。

Entity的可渲染属性:Entity是由SubEntity组成的,SubEntity是从Renderable继承而来,所以Entity是可渲染的。

Entity的可移动属性:Entity是从MovableObject继承而来,所以Entity是可移动的。

 

概括的来说,Entity和SubEntity是物体渲染特性的入口,而Mesh与SubMesh是物体结构特性(几何体数据)的入口。

2. TechniqueScheme PassTexture Unit

 

TechniqueScheme 

可以说技术和方案是Ogre引擎材质中最强大和活跃的两个特性。

在Ogre中,每个材质中都至少包含了一种“技术”实现,这种实现允许你对不同性能显示卡和硬件平台使用不同的材质属性组合。简而言之,技术就是“一种对物体的渲染方法”。通常来说对具体适用哪个渲染技术是由Ogre引擎自动甄选出来的(根据硬件性能、方案以及细节等级等信息),但是如果你希望的话也可以在代码中完全控制这个过程。

“方案”是Ogre使用的高级话题之一,事实上它是一个渲染技术集合的描述。举例来说,你可能有三个不同的技术方案:高质量,中等质量,低质量。在游戏运行的时候,允许用户通过选择这三个方案中的任意一个来确定在游戏中具体使用的渲染技术集合。

Ogre在渲染的时候,会有一个自动甄选所需渲染技术的固定流程:首先过滤掉那些不在当前方案中的所有技术(默认情况下当前方案是“Default”);然后选择适配当前细节等级(LoD)的那些;最后在剩下的当中挑选当前硬件环境中可以执行的最优技术(最好效果的)。当Ogre找不到任何一个可以使用的渲染技术时,就会把物体渲染成单调的白色表面。换句话说,如果你看到了一片雪白,就要检讨一下你对材质的配置了。另外在默认的情况下,材质中所有技术的细节等级(LoD)都被设置成为0,也就是最高的细节等级。换句话说,Ogre总是在尽可能的帮助你选择最优材质技术。

似乎技术和方案会带来很多复杂的处理细节。但在实际的执行过程中,你只要在材质脚本中提供了充足的内容,Ogre就会接替你来管理这些琐碎的细节。当然如果你喜欢,也可以用代码完成脚本所进行的工作。

Pass

在Ogre中通路是最基本的渲染单位,同时也是可渲染对象(Renderable)用来标示自己渲染状态的基本单元。每个可渲染对象都会有自己的材质,Ogre在材质中甄选出最适合当前应用的技术实现。然后把当前技术中所有的“通路”依次放入图形硬件的渲染通路中。顾名思义,Ogre材质中的“通路”对应于图形硬件中“渲染通路”的概念。也就是说当前技术中如果包含了3个通路,那么在绘制是用这个材质的模型的时候,在每一帧就要进行3次渲染。

在实际的使用中,通路里面还有“纹理单元(texture unit)”的定义,你可以在一个通路中定义任意数量的纹理单元,当然一个不用也是没问题的。

Texture Unit

在Ogre对材质的定义中,纹理单元的概念对应于图形硬件中的纹理采样(texture sampler)。为了运行Ogre程序,至少需要一个硬件纹理采样支持。不过这并不是什么大问题,因为现代的图形硬件基本上都会有多个纹理采样,因此我们可以在一次渲染通路的执行中,同时处理多个纹理单元。

顾名思义,纹理单元里都会包含一张纹理。你可以直接用硬盘中的图片文件,也可以通过实时的渲染来得到,甚至可以通过一个视频流来动态生成纹理图案。在Ogre中并没有对通路中纹理单元的数量进行限制,这是因为Ogre能根据图形硬件能力动态拆分通路(这里假设没有使用硬件着色程序)。具体点说,如果你的图形硬件只能同时处理4个纹理采样,但是应用程序却使用了一个6纹理单元的通路。这时候Ogre会自动的把这个6纹理通路拆分成两个分别两次进行渲染,不过虽然最后的渲染结果和预期的一样,但是仍然是通过两次渲染通路来实现的,对效率的影响不言自明。

材质的组成

在下图中,展示了Ogre的材质之中各种组成成分之间的关系。一份完整的材质至少有一种技术实现,每种技术实现中至少要有一个渲染通路。从图示中看到材质中包含了N种的技术实现,而在真正的渲染时,只会有一种技术被激活并进入渲染过程(选择激活技术的工作一般交给Ogre自动完成)。

6-2:在Ogre中,材质,技术以及通路之间的关系

时间: 2024-08-08 22:10:10

转:Ogre的MaterialSystem分析的相关文章

转:Ogre源码分析之Root类、Facade模式

Ogre源码分析(一)Root类,Facade模式 Ogre中的Root对象是一个Ogre应用程序的主入口点.因为它是整个Ogre引擎的外观(Façade)类.通过Root对象来开启和停止Ogre是最简单的一种方式:当你构造构造一个Root实例的时候你就启动了整个Ogre,当析构的时候(让它停止活动或者执行delete删除它)Ogre也就关闭了. API手册中这样介绍到:Ogre::Root 类代表了客户应用程序的入口点.在这里,应用程序可以获得系统的重要的访问权,也就是获取渲染系统 ,管理配置

转:Ogre的SceneManager分析

SceneManager分析 场景管理主要工作包括以下几点: 1.可移动.不可移动和可渲染物体的创建删除. 2.场景查询. 3.渲染队列. 4.动态阴影. 一. 场景对象创建 场景中的所有对象,包括可移动与不可移动的:Camera.Light.SceneNode.Entity.ManualObject.BillboardChain.RibbonTrail.ParticleSystem.BillboardSet.Animation.AnimationState.StaticGeometry.Mov

Axiom3D写游戏:第一个窗口

Axiom主要的代码大致翻看了下,就想到了自己来模拟一下游戏开发. 这章主要包括创建窗口及3D渲染的一些基本元素,并添加一个第三人称的骨骼动画作主角,加上前文中修改过后的地形组件,能用鼠标和键盘进行漫游.如下图所示. 在Axiom上给出的例子中,可以选择是用OpenGL或是DirectX渲染,现在有问题的地方是如果用OpenGL渲染,而Axiom鼠标与键盘输入采用的是SharpInputSystem,这个在DirectX渲染下是没有问题的,但是在OpenGL渲染的窗口下得不到正确的鼠标位置.而D

Ogre GpuProgram分析

和前面讲解的Compositor一样,GpuProgram也对应一种资源文件,意思我们可以直接写一个文件来完成,不需要了解相关的类. 但是就和winform一样,直接拖控件能完成大部分工作,假如如果需要我们自己手工来定制相应控件,相应的类与属性还是需要了解的,不然我们看下Ogre里讲解延迟渲染的例子(DeferredShading),就会发现看不懂了. GpuProgram比较重要的是GpuProgramParameters对象,这个对象封装了着色器的参数设置. 从着色器语言来说,参数主要区分高

【Ogre编程入门与进阶】第三章 Ogre框架配置及概要分析 [转载]

分类: Orge模块2014-01-07 23:26 425人阅读 评论(0) 收藏 举报 3.1 Ogre支持的系统平台 笔者认为,Ogre几乎可以支持所有的系统平台.这并不是天方夜谭,Ogre的确拥有很强的跨平台性. Ogre是一个用C++语言开发的图形渲染引擎,Ogre最开始主要应用于Windows系统平台.不过随着Ogre的不断发展,Ogre的核心团队吸纳了精通Mac OS X和Linux系统的人才,来开发适用于这两种系统平台的Ogre,目前,Ogre开发团队中有专门的人员来维护Mac

[Ogre][地形]OgreTerrain的实现原理分析

转自:http://www.xuebuyuan.com/1482609.html 一.世界地图 将整个世界切分成多个Tile,每个Tile大小相同,用二维坐标形式索引起来,如图: 中心点(0,0)位置的Tile为世界地图的中心点,例如坐标可以定位为(0,0,0),由于Tile大小相等,世界坐标与Tile就可以进行转换,可以根据玩家所在的坐标快速的定位Tile.例如,当tile长度为12000时,玩家坐标为(13000,13000) 那么可以知道玩家在索引为(1,1)的Tile上. 二.Tile实

【转载】Ogre:Beginner Tutorial 1: SceneNode, Entity,和SceneManager 结构

原文:Beginner Tutorial 1: SceneNode, Entity,和SceneManager 结构 先决条件 这个教程假设你有C++编程的基础并且可以配置并编译OGRE应用程序 (如果你在配置环境方面有问题,请看OGRE + MinGW + Code::Blocks环境的搭建). 除了配置环境之外,你不需要有任何关于OGRE的知识. 介绍 在这个教程中,我会介绍给你OGRE中最基本的结构: SceneManager, SceneNode, 还有Entity 对象.我们不会涉及大

Ogre代码学习之1——Ogre中地形lod的基础:deltaHeight的计算

Ogre的地形系统中的重要概念:高度差,英文HeightDeltas,表示某个完整细节中的顶点,在某个它被隐去的lod中被插值之后的高度和原始高度(即高度图中的高度)之差. DeltaHeight = interp_h - actual_h 每个四叉树的每个lod中都会有一个最大的高度差,用来保存这个lod在这个四叉树块中相对于原始数据的最大差距,显而易见,这个高度差可以认为表示了该lod的失真程度,失真越大,就应该在越远的地方使用该lod.因此,这个值可以用来帮助确定当前状态使用哪一个lod.

Ogre 编辑器一(MyGUI+Ogre配置与主界面)

在查看Ogre例子时,想看材质要里的纹理,着色器代码都需要每个去查找,非常麻烦.也想看更新每个Ogre里的对象后有什么效果.然后看到Compositor组件与粒子组件时,想到能实时编辑着色器代码实时更新渲染. 开始想着C++做界面麻烦,用C#的winForm做,后面发现首先结合层比较麻烦,然后C#与C++一起调试也会比较麻烦,还有一些比较奇怪的异常也会麻烦.好吧,不如全用C++做,在学习能用在Ogre中的UI时,主要了解了包括Ogre自己的Overlay, CEGUI, MyGUI等等,最终选择