查看: 1138|回复: 2

对《最长的一帧》的困惑

[复制链接]

该用户从未签到

发表于 2013-2-26 16:34:38 | 显示全部楼层 |阅读模式
    我在运用osg/osgearth的过程中遇到这样一个问题:众所周知,当osg加载影像的时候,影像是否建立了金字塔对加载效率影响很大。我感兴趣的是这种区别是在哪个地方产生的?不看代码,我猜测:对于没有建立金字塔的影像,当视距变化时,osg会根据视距计算当前需要抽取的像素点,抽完之后放入内存,等视距变化后这部分数据被析构掉。下次再到该范围时重新计算,导致一帧数据绘制很慢(估计是计算抽稀花费了大量时间)。而对于建立金字塔的影像,osg相当于根据一个索引去寻找已有的不同层的金字塔数据,速度就快很多。我的问题是如果大概是这样的逻辑,那osg是在什么地方实现这部分操作的呢?我猜测是在绘制的时候产生的差别。
    带着疑问我阅读了王锐老师撰写的《最长的一帧》这篇文章,尝试从中找到答案。但是当我读到16日的内容时,貌似还没有看到想看到的内容,剩下的内容只剩下render的了,我之前猜测应该在render之前会对数据进行预处理。当然在王老师的文章中我也看到一些线索,首先我的疑问是对于图像是否存在金字塔的判断是在数据库分页处理模块实现的吗?如果是的话,我有以下几点疑问:
1、osg在绘制之前会更新包含节点的多个“队列”,比如将新的节点放入“增加队列”或“合并队列”,而将通过视椎体裁切掉的节点或者多次绘制循环没有用到的节点放到“删除队列”然后析构掉。对于没有建立金子塔的影像数据,临时抽稀出的像素数据是否会作为一个新节点加入到“增加队列”或“合并队列”中?而当render range发生改变时,它们又被放入“删除队列”进行释放?
2、databasepager部分提到了预处理的功能,即等待编译列表(_dataToCompileList),这里的预编译功能对于提前计算待抽稀的金字塔数据是否有帮助?

如果对于图像是否存在金字塔的判断不是在数据库分页处理部分实现的,那对于建立和未建立金字塔的影像来说,osg在绘制之前是在哪里进行判断的,判断之后又做了哪些处理?

请王锐老师或者熟悉osg绘制的大师们给我一些启示,感激不尽!

该用户从未签到

发表于 2013-3-4 14:19:25 | 显示全部楼层
我感兴趣的是这种区别是在哪个地方产生的?

抽取数据先不说,建立一个16384x16384大小的纹理就已经爆掉大部分显卡了。如果是LOD的不同级别有不同精度的纹理去显示,那么压力相应的就小了很多。这并不是渲染队列做的事情,而是在预先构建场景结构的时候就考虑到的,正如vpb这样的工具做四叉树处理

该用户从未签到

 楼主| 发表于 2013-3-4 16:20:03 | 显示全部楼层
array 发表于 2013-3-4 14:19
抽取数据先不说,建立一个16384x16384大小的纹理就已经爆掉大部分显卡了。如果是LOD的不同级别有不同精度 ...

是的,对于osgearth中来说,是有gdal插件中的createImage接口来完成的,谢谢王老师
您需要登录后才可以回帖 登录 | 注册

本版积分规则

OSG中国官方论坛-有您OSG在中国才更好

网站简介:osgChina是国内首个三维相关技术开源社区,旨在为国内更多的技术开发人员提供最前沿的技术资讯,为更多的三维从业者提供一个学习、交流的技术平台。

联系我们

  • 工作时间:09:00--18:00
  • 反馈邮箱:1315785073@qq.com
快速回复 返回顶部 返回列表