RenderQueue

RenderQueue

  You can determine in which order your objects are drawn using the Queue tag. A Shader decides which render queue its objects belong to, this way any Transparent shaders make sure they are drawn after all opaque objects and so on.

  There are four pre-defined render queues, but there can be more queues in between the predefined ones. The predefined queues are:

  • Background - this render queue is rendered before any others. It is used for skyboxes and the like.
  • Geometry (default) - this is used for most objects. Opaque geometry uses this queue.
  • AlphaTest - alpha tested geometry uses this queue. It’s a separate queue from Geometry one since it’s more efficient to render alpha-tested objects after all solid ones are drawn.
  • Transparent - this render queue is rendered after Geometry and AlphaTest, in back-to-front order. Anything alpha-blended (i.e. shaders that don’t write to depth buffer) should go here (glass, particle effects).
  • Overlay - this render queue is meant for overlay effects. Anything rendered last should go here (e.g. lens flares).

  

  An example illustrating how to render something in the transparent queue

  Geometry render queue optimizes the drawing order of the objects for best performance. All other render queues sort objects by distance, starting rendering from the furthest ones and ending with the closest ones.

  For special uses in-between queues can be used. Internally each queue is represented by integer index; Background is 1000, Geometry is 2000, AlphaTest is 2450,Transparent is 3000 and Overlay is 4000. If a shader uses a queue like this:

  

  This will make the object be rendered after all opaque objects, but before transparent objects, as render queue index will be 2001 (geometry plus one). This is useful in situations where you want some objects be always drawn between other sets of objects. For example, in most cases transparent water should be drawn after opaque objects but before transparent objects.

时间: 2024-10-31 11:32:58

RenderQueue的相关文章

drawcall优化

Unity(或者说基本全部图形引擎)生成一帧画面的处理过程大致能够这样简化描写叙述:引擎首先经过简单的可见性測试,确定摄像机能够看到的物体,然后把这些物体的顶点(包含本地位置.法线.UV等),索引(顶点怎样组成三角形),变换(就是物体的位置.旋转.缩放.以及摄像机位置等).相关光源,纹理,渲染方式(由材质/Shader决定)等数据准备好.然后通知图形API--或者就简单地看作是通知GPU--開始绘制,GPU基于这些数据.经过一系列运算.在屏幕上画出成千上万的三角形.终于构成一幅图像. 在Unit

【Cocos2d-x 3.x】 3.0版本的全新绘制系

在Cocos2d-x 3.0的版本之前,Cocos2d-x的每个元素的绘制逻辑均分布于每个元素内部的draw()方法里,紧密依赖UI树的遍历:3.0开始,对绘制部分进行了重构,新的代码将绘制部分从UI树的遍历中分离出来,使得绘制系统设计更优雅.更灵活和易于扩展. UI树的遍历 这是渲染系统比较重要的一个职责,遍历UI树中每一个元素,遍历的有两个重要的目的,一是遍历的顺序基本决定了元素被绘制的顺序,二是在遍历过程中实现元素的模型视图变换矩阵的计算,计算结果供OpenGL ES渲染管线计算顶点位置.

Ogre 监听类与渲染流程

Ogre中有许多监听类,我们可以简单理解成C#中的事件,这些类作用都不小,说大点可能改变流程,说小点修改参数等,下面列举一些常用的监听类. FrameListener:由Ogre中的Root负责维护,主要针对所有RenderTarget监听 frameStarted:在一桢开始的时候,所有RenderTarget更新之前. frameRenderingQueued:所有RenderTarget更新之后,但是还没交换缓冲区.(意思屏幕上显示没变) frameEnded:所有RenderTarget

Ogre 渲染目标解析与多文本合并渲染

实现目标 因为需求,想找一个在Ogre中好用的文本显示,经过查找和一些比对.有三种方案 一利用Overlay的2D显示来达到效果. http://www.ogre3d.org/tikiwiki/tiki-index.php?page=MovableTextOverlay 二重写Renderable与MovableObject,利用对应字体查找到每个字符元素纹理坐标. http://www.ogre3d.org/tikiwiki/tiki-index.php?page=MovableText 三利

Unity+NGUI性能优化方法总结

一共9招. 1 资源分离打包与加载 游戏中会有很多地方使用同一份资源.比如,有些界面会共用同一份字体.同一张图集,有些场景会共用同一张贴图,有些会怪物使用同一个Animator,等等.可以在制作游戏安装包时将这些公用资源从其它资源中分离出来,单独打包.比如若资源A和B都引用了资源C,则将C分离出来单独打一个bundle.在游戏运行时,如果要加载A,则先加载C:之后如果要加载B,因为C的实例已经在内存,所以只要直接加载B,让B指向C即可.如果打包时不将C从A和B分离出来,那么A的包里会有一份C,B

cocos2D-X源码讲解之从cocos2D-X学习OpenGL(1)----cocos2D-X渲染结构

 个人原创,欢迎转载,转载请注明原文地址http://blog.csdn.net/bill_man 从本篇文章开始,将分析cocos2D-X 3.0源代码,第一部分是从cocos2D-X学习OpenGL,也就是分析cocos2D-X 3.0的渲染代码,本篇首先介绍cocos2D-X 3.0的渲染结构,使用的是3.0正式版. void DisplayLinkDirector::mainLoop() { if (_purgeDirectorInNextLoop) { //只有一种情况会调用到这里来,

使用Unity创造动态的2D水体效果

者:Alex Rose 在本篇教程中,我们将使用简单的物理机制模拟一个动态的2D水体.我们将使用一个线性渲染器.网格渲染器,触发器以及粒子的混合体来创造这一水体效果,最终得到可运用于你下款游戏的水纹和水花.这里包含了Unity样本源,但你应该能够使用任何游戏引擎以相同的原理执行类似的操作. 设置水体管理器 我们将使用Unity的一个线性渲染器来渲染我们的水体表面,并使用这些节点来展现持续的波纹. unity-water-linerenderer(from gamedevelopment) 我们将

Ogre2.1 Hlms与渲染流程

在我前面三篇说明Ogre2.x的文章里,第一篇大致说了下Hlms,第二篇说了下和OpenGL结合比较紧的渲染,本文用来说下Hlms如何影响渲染流程中,因为有些概念已经在前面二文里说过了,本文就不再提,最后这篇也算是对Ogre2.1一个渲染流程的详细讲解. PassScene简单流程 首先是所有场景更新,场景更新包含的内容如下. 场景动画 _applySceneAnimations 所有节点数据 UPDATE_ALL_TRANSFORMS 骨骼动画 UPDATE_ALL_ANIMATIONS 所有

Ogre2.1 结合OpenGL3+高效渲染

在DX10与OpenGL3+之前,二者都是固定管线与可编程管线的混合,其中对应Ogre1.x的版本,也是结合固定与可编程管线设计.转眼到了OpenGL3+与DX10后,固定管线都被移除了,相对应着色器的功能进一步完善与扩充,对应Ogre2.x包装DX11与OpenGL3+,完全抛弃固定管线的内容,专门针对可编程管线封装. Ogre1.x的渲染流程一直是大家吐槽的对象,除开用Ogre1.x本身的实例批次,才能把同材质同模型合并,但是用过的人都知道,这个局限性太大,另外就是每个Renderable结