用户操作是怎样被构造成事件，并添加到事件队列中的？

citihome

如题，没有找到相关的代码，不知道从什么地方分析开始！

array

您是想了解源代码中的相关实现吗？那么可以参考GraphicsWindow及其派生类的实现代码

citihome

查看了GraphicsWindowsWin32中的代码，但没有找到相关的处理。另外，事件队列被存放在ViewerBase(还是View)中，也就是Viewer的父类，怎么要到GraphicsWindows中去进行分析呢？

array

GraphicsWindowsWin32保存了Windows系统中所有交互事件的处理，并将其传递到EventQueue中。请您再仔细阅读代码

citihome

仔细看了一下，是在GraphicsWindowWin32.cpp中包含了这部分代码，其构造和MFC的窗口类似。
但是其中还是有问题的：
1.由于osgViewer::Viewer是osgViewer::View的派生类，而View中定义有消息队列；GraphicsWindowWin32作为GraphicsWindow的派生类，GraphicsWindow中也包含了消息队列的定义。这两个队列分别实现什么功能(区别)？
2.GraphicsWindow作为GraphicsContext的派生类，这两个又有什么区别呢，难道GraphicsWindow是想实现对基于HWND（窗口句柄）的操作的封装；而GraphicsContext是想实现对基于HLGRC（渲染上下文）操作的封装？如果这样的话，从高层来看，仅会使用GraphicsContext，GraphicsContext实现了对输出目的地（其实也就是窗口）的抽象？
3.osgViewer到底是要实现什么功能，从其中的定义来看，包含了几乎所有的对象（或者基于指针），从而提供直接或者间接访问所有对象的入口？又或者仅仅是渲染环境配置、启动的入口？
4.Camera对象也不知道有什么用途，作为一个MatrixTransform，想不到有什么作用，难道是为了包含“场景数据”？（一个变换能实现什么功能呢）CullSettings除了包含筛选的控制参数外，也没有什么用途啊。
5.几个View（osgViewer：：Viewer，包括Viewer的父类，以及以View为后缀的“SceneView”）不知道是什么含义，在OpenGL世界中，与View（视图）有关的可能就是到照相机的参数（模型-视图变换矩阵）了。完全不明白，为什么这么设计，所谓的照相机的最大用处没有表现其作为“由世界坐标到视图（照相机）坐标进行投影的参数”用途，也不明白为什么要设计SceneView（场景视图）干什么？
6.不明白Renderer要实现什么功能，难道仅仅是要封装筛选台和渲染台么？不过似乎其没有直接包含到这两类对象的引用啊，其中还需要经过SceneView。

array

1、GraphicsWindowWin32的消息队列会复制到Viewer的消息队列
2、OSG是跨平台的，GraphicsWindowWin32实现了对于Windows系统中HWND和HLGRC的封装。GraphicsContext则是所有图形设备（窗口和离屏设备）的抽象类
3、osgViewer用于实现渲染后台的用户接口，以及场景树的承载者。
4、Camera总是对应一个图形设备GraphicsContext，即一个可以显示场景的窗口或离屏设备；CullSettings就是用来包含场景裁减参数的，这些参数可能被多种OSG功能类用到。
5、请参见《最长的一帧》，OSG中的“照相机”就是Camera类。SceneView则是整个渲染后台的承载者。
6、Renderer是相机（Camera）与渲染后台（SceneView）的接口

citihome

1.在Viewer::eventTraversal中找到了“复制逻辑”。有有了新问题：我们知道在eventTraversal中将处理GraphicsWindow消息队列中的消息，那么复制到View，_eventQueue中的信息将要实现什么功能呢？
保存OSG中接收到的所有信息，似乎没必要。
2.说道GraphicsContext可以具体化为离屏设备，究竟离屏设备有什么作用，不知道，没有映像。
4.5:我们是可以发现Camera与GraphicsContext的双向指针(N:1),但是和GraphicsContext到底是什么关系，还不是很明白，难道他们的分工为：在事件处理中，由于派生的GraphicsWindow中定义的_eventQueue中包含了用户输入信息，因此我们在事件处理中主要是基于GraphicsWindow进行处理;而Camera主要提供输出功能的入口（访问Renderer，然后调用Renderer引用的SceneView的cull（）和draw（））？

array

1、有很多可用的地方，比如用户也可以直接向Viewer的消息队列传递事件（例如摇杆和自定义事件等），然后这些事件也会通过takeEvents传递出去并且统一在EventHandler中进行处理

2、Offscreen Rendering，一个在现代图形学中极其重要的概念，其价值不言而喻。我不想过多介绍

4/5、GraphicsContext就是承载OpenGL环境的图形设备，Camera负责对场景观察、投影、映射到视口，再通过Renderer输出指令给图形设备。至于具体的叙述，不知可否麻烦您先读过《最长的一帧》中的相关文字和结构图呢？我个人不太想拼命地解释已经写过的问题

citihome

谢谢，《最长一帧》有读过（知道就是你老的大作），也研究了一下相关代码的框架。但是准确地说，其中的思路线索不是很明显，个人认为至少在下面几个问题上可以再深入挖掘一下：
1.从指令流的角度来看，怎样以OpenGL方式进行输出。CullStage中的CullVisitor的功能相当于将场景树中的信息进行封装（以RenderBin的方式，其中的主要结构数据为RenderLeaf），最后传递给RenderStage，RenderStage调用RenderLeaf封装的Drawable对象的drawImplementation，在这个函数中实现OpenGL语言的调用（从这个角度来看，drawImplementation就相当于翻译器）。这部分内容（结构、流程）缺失，个人认为这个才是整个OSG的主线。
2.《最长一帧》需要描述“将模型数据以OpenGL格式的接口调用输出”这个情景，同时也断断续续描述了主要的类，但是缺少相关的汇总：放在一起时，各个对象实现功能的异同、协作，都不了解。
3.这个是题外话，可以跳出《最长一帧》这个圈子，实际上，我们对一个图形系统（特别是GUI的开发平台）的了解，除了对输出的处理，还应该包括输入的处理吧。（特别是OSG对于输入的处理同其他的处理系统不一样，窗口例程和OSG的事件处理(回调)程序是基于数据（事件队列）进行交换的（相当于读写者两个角色），而不是像MFC消息路由那样基于调用实现（大部分人不是JAVA、C#程序员）。
个人看法

array

《最长的一帧》是本人业余时间在网络上发表的零散文字，从写作的一开始就没有主线，而是记录下阅读源代码的过程而已。感谢您的意见和建议，不过我个人暂时没有打算将这些文字再次整理和深入的打算。

您所说的OSG->OpenGL的指令流过程，以及相关的主要类，在《最长的一帧》中其实都已经零散地阐述了，并且在我的新书中（清华大学出版社正在运作，并已经接近尾声），尽量详尽地汇总和讲解了这些内容。可惜个人的水平有限，依然无法将它们彻底地剖析清楚；有些概念在我自己的脑子中十分明确，但是表达到纸面上却依然含混。我尚不是专业的文字工作者，成本的写作经验也只有区区百万余字而已，这些方面很难做到完善，请多见谅。

如果楼主愿意参与完善OSG的教程和文档，或者对于OSG培训（事实上我们也正在着手这一工作）的资料准备等事情感兴趣的话，也许我们可以深入地讨论一下。

citihome

本人由于学位原因，还不能在这上面花大力气。期待着你的大作

shengrendan2

唉，我看了你们的这番综述，不禁感慨万千啊
city的想法知道opengl就用上了这件事情，我认为不是osg最重要的；
封装嘛，osg::下面全是opengl的封装，状态，变量等；还有各种效果，如灯光，雾效
了解opengl是咋么工作得，这osg怎么就变成了opengl指令流还是很容易理解的；
opengl怎么玩滴？
1.配置好上下文
2.作画
3.释放上下文


所以我的意思呢，就是应该把osg的上面逻辑搞清楚了，下面的无非就是opengl普通的做法；

至于《最长一帧》吧，还是比较主线明显的——就是一个frame是怎么就运行的意思嘛；

但是，我不习惯的地方是：杂草丛生的感觉

我一直希望能把这个frame改成，层次结构，先提纲挈领，然后逐层分解，（现在的the longest frame也做到部分了），也会有frame是最上一层，其次的andvance，realize，各种traversal。也是那么回事

还需要精辟，图示，流程图要多，遇到某种软件现象，要总结，（我记得总结了一个visitor模式，也有图）
当然那个各种平台的，也对代码有分析，但没有提升一下；

另外，最长一帧的图示，我不太清楚啊，应该是不是标准图示？
因为有些地方，是array自己发明的吗

shengrendan2

to city
其实因为学位的问题，很苦恼；
呵呵
osg的文档少得可怜；
同情一下