coder

实验中，xquat是竖直的那个，yquat是与屏幕平行的那个，zquat是水平的那个。如果是vec2 = quatx。quatZ*vec1，则先转xquat,再转yquat,再转zquat,问题来了，如果多个步骤，该怎么办？顺序的不同，会导致结果的不同。//当前旋转的dir，也就是哪个dragger在起作用。在release时，把该四元数加入到数组中。//中心点初始坐标（可能没在原点上）使用时通过回调函数每帧更改。

五，漫游器的朝向，不是坐标系的XYZ轴，而是PItch,roll,yaw，所以，要涉及到一个球面坐标转向XYZ坐标系的过程，由于在初始化时， m_vRotation = osg::Vec3(osg::PI_2, 0, -osg::PI_2);这里用到了路径点，从X轴正向开始，所以再减去90度，使look方向的初始方向为X轴正向，便于计算。值得注意的是，朝向要绕X轴转90度，才能和默认漫游器一样，look方向指向Y轴正向，即。本来打算用现成的路径点漫游器，发现很不好用，限制也多，干脆自己写一个得了。

前面介绍了正交投影下的qedl，实际上，还有透视模式，根据摄像机位置的移动，远近切面也在不断变化，所以需要深度补偿。远近切面是从下式计算。只要摄像机位姿发生变动，就调用一次。同时更新shader的值。

回想一下hud文字，无非是把文字当作场景根，再加了一个正交投影的摄像机罢了。所以，只要把postRender改为prerender即可。从osg的例子上，可以看到，文字一般是写入hud的，那么，能不能写入fbo呢？

然而，实际项目中，会出现多种渲染方式.这时候就要用到。在qt中， 也要注意把图形上下文设置给采样摄像机。由于前面是简单的demo，所以不用管渲染次序。比如，采样摄像机设为2，处理摄像机设置为1。

如果将PerspectiveMode的设置为1，则会传递zNear和Zfar,在fixDepth()中，而将perspectiveMode = 0，则大大简化fixDepth()

(设定数组有64个浮点值,默认为1.0）对于osg::vec2的数组，传递到shader。一，对float类型的数组。

其实，很简单，对于同一个颜色缓冲区，设置三个采样摄像机就可以了。只是把纹理设置为1，0.5，0.25倍，采样摄像机的视口也要设置为1，0.5，0.25倍，sampleCamera0->attach(osg::Camera::COLOR_BUFFER0, texColor0);在qedl中，也考虑到不同分辨率纹理，1，0.5，0.25倍。

/摄像机视口投影到纹理大小。

类似于颜色缓冲区采样纹理，深度缓冲区也可以通过采样摄像机进行。三，将深度图纹理传递到pass1Camera。二，将深度图纹理关联到深度缓冲区。

/摄像机视口投影到纹理大小。pass3和pass2类似，只是再熟悉下，这个Pass设定为最后一步，可以不再输出纹理，3，pass3Root按顺序加上以前的所有摄像机，查看Pass3Root。//绑定采样摄像机1。

4，pass2Root按顺序加上以前的所有摄像机，查看Pass2Root。二，pass2是比较完整的，同时有输入纹理和输出纹理。1,pass2摄像机输入tex1,输出tex2。与pass1类似，这里只列出不同的地方。3，shader中，将红色背景改为绿色。

一般情况，一个采样摄像机和1个显示摄像机就足够了，但是，并非完全如此。最近将qedl移植到osg时，就出现了N个步骤。当然，可以把所有的步骤都糅合在最后一个显示摄像机处理，但是那样就会成了大杂烩，代码不优雅,且容易出错。即将采样后的摄像机，通过pass1,tex0->tex1,再通过pass2摄像机tex1->tex2…这里先用颜色占位，有助于看看每个passRoot是否正确。这是个比较有趣的事情，因为可以无限扩展下去。所以，这时候要考虑多pass，一，采样摄像机背景设置为黑色。

一般情况，一个采样摄像机和1个显示摄像机就足够了，但是，并非完全如此。当然，可以把所有的步骤都糅合在最后一个显示摄像机处理，但是那样就会成了大杂烩，代码不优雅。在此之前，先修改下osgfbo(五）中纹理坐标的表示方法，不是说osgfbo(五）中的做法不对，而是我更愿意明确的把纹理坐标数组赋值到（0，1）之间。2，将纹理坐标按照以前传递shader数组的方式，传递到shader(注意，序号不能为0，这里设置为1）4，在shader中，顶点shader改为。所以，这时候要考虑多pass，5，传递给片元着色器。

什么是pass,这个问题，看似简单，也让我头疼。看了osgdefered，pass定义为osg::Camera。杨石兴的osg视频教程定义为osg::Group。摄像机之间如何传递，众说纷纭。osg自带例子上只有采样摄像机和最后呈现的摄像机，并没有中间摄像机，忽略了这步。osg视频教程上通过。我认为一个pass可以定义为一个Group，包含三部分：到目前pass为止的所有摄像机，geode，texture。摄像机分为采样摄像机，中间处理摄像机，以及最后呈现的摄像机。

点云

osg

osg

osg

osg

osg

osg

osg

osg

OSG

终于快结束了，再接再厉。GOGOGO！对于剩下的两个线程模型，一，默认的线程模式是DrawThreadPerContext其实，前面有些已经跟踪过了，再一边抄一边调试，熟悉下，一遍肯定记不住。如果ViewerBase类的成员函数suggestBestThreadingModel(),没有找到适合当前计算机系统的线程模式的话，将自动采用这一模式来完成渲染的工作。DrawThreadPerContext模式没有设置渲染启动栅栏和结束栅栏。因此，这一渲染模式下将不会在.

GraphicsContext::createGraphicsThread()创建线程时，得到一个osg::GraphicsThread线程对象而使用Camera::createCamera创建线程时，得到的是osg::OperationThread对象，它是GraphicsThread的父类。可见osg::OperationThread是osg::GraphicsThread的父类。这...

电子书对同步三兄弟的初始化做了介绍，再看看它们三个在哪里初始化的呢？动态绘制阻塞器_endDynamicDrawBlock的作用就是避免DYNAMIC对象的运行时更改影响后台渲染的工具。在初始化时，我们需要设置它的最大计数值，当completed函数的执行次数达到这一数值时，将释放被阻塞的线程，也就是主进程。这一最大计数值正是场景中摄像机渲染器Renderer的个数。这里State::_dynamicObjectC...

对于几个多线程渲染中的成员变量

在第25天，这个例子可能会有误导，因为用的是pagedlod的方式触发的，实际上，任何一个可绘制节点都可以，因为最终在渲染叶中，再改到最简单，依然触发这里没有设置，所以直接返回false...

目前已经到了单线程渲染的尾声了，先看看总体框架，看看还是否忘记了。昨天，看到的第24天内容结尾，有点懵逼，下面这个图以前看的也有点懵，直到这两者都看了后，突然有点明白了，从渲染元和状态节点起始，由osg状态机为中转核心。在看电子书之前，先在源码把这张图上的这些找到，观其大略。再对照下电子书，看看自己的思路有什么问题。可见，moveStateGraph在状态节点中与状态机之间搭建了桥梁。渲染元与渲染叶之间，RenderLeaft::render()是在RenderBi...

电子书开始主要介绍了要解决的问题。抄一抄。首先，我们要解决的问题是RenderStage::runCameraSetUp和RenderStage::copyTexture这两个函数的工作内容。事实上也是对“什么是渲染目标实现方式”进行讨论。渲染到纹理。RTT技术意味着我们可以将后台实时绘制得到的场景图像直接作为另一个场景中对象的纹理，从而实现更加丰富的场景表达效果。在viewer::eventTraversal函数中调用camera::getRenderTargetImplementation()进

看看总体进度第22天通过CUllvisitor创建了渲染树和状态树，并进行必要的剔除。接下来进行排序和优化RenderStage::sort函数时按照前序渲染台，当前渲染台和后续渲染台的顺序进行，其中前序渲染台和后续渲染台通过Camera::setRenderOrder实现，保存了指定摄像机及其场景子树和渲染树结构。渲染树及其各个分支中数据的排序工作实际上时通过RenderBin::sortImplementation函数实现的，如果希望能实现自定义的渲染树排序动作，通过Re

先看看全流程先抄一抄节点访问器NodeVisitor的工作原理.当我们执行节点的accept(NodeVisitor* nv)函数时，当前节点自动调哟个NodeVisitor::apply方法，将自身的信息传递给节点访问器nv,由它负责执行相应的处理工作；然后节点将自动执行Node::traverse函数，调用所有子节点的accept函数，从而实现了节点数的遍历。在遍历的过程中，每个节点都会调用NodeVisitor::apply，将自身的指针传递给访问器，因此，NodeVisito..

看看全流程，主要讲sceneview::cull（），跟过去重点在cullstage()下一步深入展开osgUtil::CullVisitor::pushStateSet() ...

电子书上给了个例子，抄一抄，加深下印象，也验证下以前的想法对不对对于场景实例其中"ss"加上数字代号来标识这些Stateset对象，后面括号中的两个参数分别表示setRenderBinDetails的两个设置项("-"表示空字串，"R"表示"RenderBin","D"表示"DepthSortedBin"即ss03->setRenderBinDetails(0,""); //缺省设置ss11->setRenderBinDetails(0,"");ss13->..

这个主要是理论了。抄一抄。最常用到场景管理方式时场景节点树结构，场景树顶点的叶节点osg::Geode包含了各种需要渲染的几何体的顶点和渲染状态信息；而组节点osg::Group及其派生出的各种特殊功能节点则作为场景树的各个枝节节点 ，它们也可以拥有不同的渲染状态；有且只有一个节点可以直接作为整个场景的根节点，使用setSceneData将其设置为场景的视景器系统，即等同于将整个场景树传递给OSG的渲染和显示系统。而保存节点和几何体的各种渲染属性（osg::StateAttribute,例如纹理、雾

发现一个错别字，改过来，哈哈，先看看总体流程直奔renderer::draw()为了查询gpu，在main（）函数先设置，要不没法往下调试重点落在sceneView::draw()以后深入...

先看看流程电子书上介绍了渲染器osgViewer::Renderer类，osgViewer::Renderer为摄像机渲染场景的工作提供了一个公共接口，当我们向视景器viewer添加了一个新的摄像机camera时，一个与摄像机相关联的渲染器Renderer也会被自动创建。当准备渲染场景时，与特定图形设备GraphicsContext相关联的摄像机也会自动调用其渲染器的响应函数，执行场景筛选与绘制等工作。渲染器负责调用场景视图获取摄像机附带渲染器的代码：关于场景视图在.

终于到达绘制了，先看总体流程阶段然而，从并行堆栈上看，已经有渲染线程开启了跟着电子书走，先是介绍，抄一抄，加深印象。osg的场景渲染过程可以简单地分为三个阶段：用户APP阶段，更新用户数据、负责场景对象的运动和管理等；筛选cull阶段，负责对场景中的对象进行筛选裁剪，略过那些不会被用户所见（因而不必渲染）的物体，并根据渲染状态的相似性对即将进入渲染管线的对象排序（从而避免OpenGL状态量的频繁切换）；绘制（DRAW）阶段，执行各种OpenGL操作，将数据送入OpenGL渲染管线及.