3000个粒子就跑不动了 这正常吗？

feicheng99

新手问题：究竟一桢渲染多少个三角形算正常？

我的机器是迅驰1.5, 内存 512, 显卡ATI9200.
两个三角形构成一个粒子，也就是6000个三角形，关掉抗锯齿，打开backfaceculling,打开billinear filter, 分辨率800*600的窗口，粒子用AddColor AlphaBlend 做半透明效果，只有10几桢了。渲染函数用的是Draw***UP。
加上Terrain（LOD以后每桢3000个三角形左右）对性能几乎没有影响，因为把粒子调小一点的时候就算加上Terrain也可以跑到200桢。最起码是每桢只调用一次Draw***UP，如果是一个粒子调一次的话更慢的不可想象啦。可是网上有个文章的Instancing Demo测试，5种方法渲染15000个粒子，桢率那么高：
硬件Instancing是450桢，
Shander Constant 380，
Vertex Buffer是310,
UP是110，
就算是一个粒子DrawUp一次也有57桢，而且是15000个粒子。

大家给个标准吧，让我知道改进到什么程度算是性能不错了，就是一般要60桢/秒，在特定的渲染状态和分辨率等条件下，象我的机子最多可以绘制多少个多边形？

xpertsoft

不正在。

千里马肝

1. 更新一下最新driver
2. 尽量别用UP来画
3. DP调用次数太多，你6000个粒子相当于6000DP/frame，通常1G的CPU在保证30fps的情况下只能处理4000次DP，这也是为什么要用instancing来做的主要原因
4. alphablend引起的sort占用时间，以及填充率的问题
5. 粒子有做view frustum cull吗

一下子只想到这么多，供参考~

feicheng99

这些是优化，可是仍然不对，因为不需要这些优化也不应该这么慢的。
我想过优化数学库，少生成些临时对象，虽然有少许提升性能，但都不是很明显。
最后找到了最大的瓶颈，我是怎么都没想到的，竟然是太大的Vector遍历速度的问题。申请了32000个顶点空间，每个64字节，没想到用下标引用起来这么费劲，改成数组会快很多。更重要的，把指针一点一点往前推着一次遍历处理完数据，如果每次都用下标，每次都要去遍历如此长的数组，查找起来就会非常慢。现在4000个粒子，8000个三角形依然100桢以上了，还得继续优化。

bracelet

看看Debug和Release的差异

差异大是CPU负担太重

不大是GPU负担太重

月下临风

难道你不知道内存用的太多会严重影响性能么?
做粒子系统我一般用list.

千里马肝

>竟然是太大的Vector遍历速度的问题。申请了32000个顶点空间，每个64字节，没想到用下标引用起来这么费劲，改成数组会快很多

std::vector的实现必须保证在效率上与普通array一样，我倒想看看你是怎么在遍历操作
贴点代码出来看看~

另外，DUP是表示VB内存由app保存，那么实际在画的时候，driver会复制一份internal的copy，这导致了速度的降低
最好的方法就是申请一块static vb，这样有可能会放在local memory或是agp memory，大小等于4000 x sizeof(Particle)，然后用shader + const来做

list就更不对了

feicheng99

_vertices.resize(32000);
for(int i=0;i<_vertices.size();i++)
{
     _vertices  ..............
}

这样特别慢 我改成了数组 速度突然就上去了 我一直认为Vector完全可以代替数组 可是今天的程序竟然发现数组遍历快 我也想不通啊。

另外，如果改成数组以后,再这样写，不使用下标，就更快：
Vertex* p = _vertices;
int loop = 0;
while(loop < size)
{
   p->......
   p++;
   loop++;
}
如果用Vector 那使用Iterator 也会快一点，但是也没有数组快。
按理说使用下标引用，也只是计算一个指针的偏移量，只不过每次指针移动幅度比较大，可是运行结果却慢很多。

ricohcanon

xpertsoft: Re:3000个粒子就跑不动了 这正常吗？

不正在。

[em24]—啥意思？

月下临风

千里马肝: Re:3000个粒子就跑不动了 这正常吗？

>竟然是太大的Vector遍历速度的问题。申请了32000个顶点空间，每个64字节，没想到用下标引用起来这么费劲...

被马肝误解真是让人伤心啊

我怎么会蠢到用list去保存数据呢?用list是用来保存粒子的指针的.至于数据嘛你都已经说完了.我想真正懂数据结构的人都不会直接拿那些静态数组里的数据来处理逻辑的,更何况是量比较大的情况.
我很久以前测试过,一个是直接用数组的下标便历,一个是用指针便历,指针的速度要快好几倍,而且用下标从1->1m便历10变,比从1->100m便历一便要快很多,这说明什么问题?
所以我养成习惯了,尽量不开特大数组,即使开了,我也会尽量避免用下标便历.

最关键的是,粒子系统粒子的存储顺序一般来说是不重要的,甚至很多情况下不需要排序,也不需要定位查找,很多情况下,只是在渲染前根据他的生命周期更新一下而已,需要做的仅仅是便历每个一个粒子,用list便历,我不管数据量是多大,便历效率始终是O(n).
很多人不喜欢用list,认为是鸡肋,包括我现在的上级,但在我眼里,stl里每样都有他存在的理由.
从上所述,用list+dynamic VB是最正确的.