再次看osg《最长的一帧》,因为分页数据库适合于PagedLod和ProxyNode,一般调试还得准备数据,比较麻烦。
突然想起,和我以前封装的引擎类似。分页数据库就是几个生产者与消费者。
回过头来看这个图。
看似复杂,实际上并不复杂。
如果简化,只需要一个数据请求列表和等待合并列表就够了。请求什么数据,就合并什么数据即可。当然,合并前清空数据。
也就是说,在请求数据时,用生产者和消费者的方式;同样,在渲染合并列表时,也用生产者和消费者的模式。
如果,再考虑效率,就要加上等待编译列表,把stateset和drawable加上去。
如果再正规点,就把合并队列前的每帧清空数据独立出来,即弃用对象列表。
这些工作肯定不能每帧进行,而是开一个线程,就是DataBaseThread::run()。值得注意的是,这个线程只对pagedLod和proxyNode起作用,单纯加个cow.osg,是进不去的。
准确地说,是两个线程,一个应对本地数据,一个应对网络数据。应对网络数据的,就要写本地Cache。
对于上面的请求数据,还有个时限问题,即:超时不处理。当然,弃用对象列表中无用的数据该扔还得扔。
有效处理的数据,按kdtree组织。
每帧是如何更新数据的呢?1,发送无用数据列表到线程;2,从线程接收合并数据列表
合并列表和请求列表中的数据是一样的么?
不一样。有三种数据不会合并。1,请求列表中超时的;2,请求列表中没有父节点的;3,请求列表中需要编译的(即,等待编译列表)过期的
等待编译列表中的数据如何编译?
两种方式1,图形设备线程处理;2,立即编译
明白了这些,再看下边这张图,就没那么困惑了,一切都是很自然。