本文翻译自Don Burns和Robert Osfield(缺席)在Image 2003会议上的演讲幻灯片。 -------------------------------------------------------------------------------------- 1、什么是Open Scene Graph? 正是由于场景及其参数定义的特点,通过状态转化、绘图管道和自定制等操作,OSG还可以用于优化渲染性能。 可以运行OSG的平台,需要具备OpenGL的支持能力,以及C++的编译环境,支持OSG的系统包括Solaris,IRIX,Windows,Mac OSX,HP-UX,Sony Platystation等等,不过XBox除外。 和OpenGL类似,OSG的核心并没有提供窗口系统的功能。因此用户可以自由选择所需的图形开发接口,如GLUT,X11/Motif,Win32,MacOS X,Qt,wxWindows,Fox等。 OSG是一个开源系统。自Robert Osfield主持这个项目以来,OSG就作为一个开放源代码的图形开发工程开始在全球运作了。 OSG包括一系列的标准库。其核心是OSG本身。下图中的树状结构包括了场景管理的各个功能节点(node)。
OSGUtil提供了场景操作的工具。如场景的精简(cull)和绘制,优化渲染,提供快捷方式等。 OSGDB提供了文件管理和插件管理的功能。所有的文件和图片都使用插件进行读取,以下是目前支持的文件格式列表: 此外,OSG还提供了提供特殊功能和组件的一系列节点,如文本的字体和风格化显示,OSGSim用于模拟特定对象(天空,光,天候),以及粒子特效的显示。 用户可以自由地使用以上的库,也可以自定义新的库。 2、为什么开源? 考虑软件开发的流程:首先是一个概念性的想法或者一个用户需求,软件工程师随后提出设计和实现的方案,最后将方案转化为代码。 不幸的是,大部分商业软件将代码的部分作为“家传之宝”,深藏起来,生怕这些看起来汇集了智慧结晶的资料外泄。。 然而,软件真正的价值是在开发流程的第二步,而且这一步完全可以被重新演绎成别的代码。我们经常见到大型企业之间为了代码之争将对方告上法庭的例子,但是这显得毫无用处。 在软件的“食物链”当中,处于最底层的是系统开发者,他们针对硬件编写接口和驱动程序;其上一层是开发层软件的编写者,他们提供抽象层,并整合硬件接口(声音、图像、网络等),以方便应用软件的开发者使用。应用层软件的开发者比较特殊,他们不仅要理解开发平台的特性,还要十分理解应用程序的工作配置和上级用户的需求。 最上一层是应用软件的用户,和开发者不同,他们将计算机作为一种工具,他们不关心软件的技术细节,只要软件易用而且有用,他们就愿意为之付款。这些人包括办公室的白领,培训学员,老师,飞行员,等等。 在开发者的层级,事实上也有一条分界线存在。在这个层级中,最下面的两层(系统开发者和开发层软件开发者)是由硬件厂商支持的。而开发层软件开发者和应用软件开发者之间,却存在了明显的差别。 以上的场景存在了两条主要问题:一、应用程序开发者要依赖于开发层软件开发者和系统开发者,这决定了产品的质量;二、开发层软件开发者要开发出令人满意的产品,就必须与应用程序开发者分享设计的方案。而软件的真正价值也就在这里。 OSG开源后带来的益处主要有: 开源的产品并不等价于成功的产品。网络上存在着许多开源软件(可以浏览一下Source Forge),它们之间一直在进行着“适者生存”的战争。 一个优秀的软件,无论它开源与否,都必须物有所值,即,必须为最终用户提供唯一的解决方案;它必须稳定,没有哪个应用程序开发者愿意在有问题的软件基础上进行编程;它必须有良好的设计,必须提供一种适合用户的开发方法,而不是对开发者和用户加以限制。它必须有很好的交流渠道,经常性地为用户的问题提供回答,解决疑难,而且要做到谦恭有礼。 3、设计思想 大部分的交流都在OSG的邮件组中进行。我们每天都会抽出数个小时的时间回答问题,和OSG的用户进行各种交流。我们在OSG的主页上通过在线的参考指南向用户提供各种信息,其中也包括大量的示例。我们还负责维护一个主机,用于收集邮件组的问答资料,用户提供的的示例代码,以及一些软件的部分程序段。 4、多线程、多显示(Multi-threaded, Multi-display) 单线程低负荷的设计特性允许我们的程序“朴实无华”,即,我们不必关注不必要的损耗。可升级性也是呈线性的,系统负荷不会随着进程单元的增加而增加。 我们不需要在运行时实现数据保护,而是在编译时进行这项工作。我们使用C++常量来保证源代码中的数据只读,编译器会要求我们按照规定的方式写入数据,从而避免覆盖危险的数据。因此,在运行时,我们不需要再建立额外的进程来保护多进程共享的数据。 当然危险依然存在。在任何多进程程序运行时,都需要遵守一定的规则。其中最重要的是,程序只有在更新段(UpdatePhase)的时候才可以传递数据。如下所示:
现在,我们如果要描述每个相的处理时间,那么大致如下图所示。更新时间(Update)不到一毫秒,标准数据库的拣选时间(Cull)约2~3毫秒,绘图时间(Draw)则没有变化,除非我们有意在绘图时为程序添加更多的工作。 可以明显看出,CPU资源的使用少得可怜,更多的时间它处于空闲状态。 Producer是OSG的姊妹产品,它为OSG良好地实现了多线程、多显示的环境。其基本概念是运用抽象的“摄相机”(Camera)。Producer中的每一个摄相机都是一个对象,也是一个进程单元,可以自行、与其他摄相机异步地并行工作。 Producer/OSG的多显示运用,其原理如下图所示: 绘图(Draw)事实上是两个并行的进程。在现代的图形设备上,一般至少有两个处理器在进行工作。CPU并不负责图形的渲染,而是执行OpenGL的指令,也就是“分发”(Dispatch)。图形处理器(也就是GPU)负责执行CPU分发的OpenGL指令,并异步进行执行。 这样的硬件结构有几个特点:一、分发进程仅仅由CPU和GPU之间管道(FIFO)的传输速率决定;二、使用大容量的管道,可以使分发的时间远远少于和快于GPU绘图的时间。 基于以上的信息,Producer/OSG使用了称为“移相”(phase shifted)的技术: 在进行移相时,我们使用了两种周期进行计算。其中一种是由图形设备的帧扫描(vertical retrace)得来的,它用于图形硬件设备的绘图工作。 在CPU一端,我们使用的时间周期与图形设备帧同步(vertical sync)的周期相同,但是通过移相使得更新(update)、拣选(cull)和分发(dispatch)过程与绘图(draw)过程交迭。在理想情况下,我们可以在一次分发结束后立即开始下一次的更新。更新/拣选/分发的过程连续地运行,简化了多线程的模型,也提高了资源的使用效率。 -------------------------------------------------------------------------------------- 关于作者: Robert Osfield,自1999年开始担任项目负责人,并将其作为开源项目发布,自2000年开始全职承担OSG的开发工作。 关于Image: |