помогите разобраться с индексами стрипов

Пишу парсер, который по сути сам расчитывает ТБН, и выплевывает индексированый буфер и список уникальных вершин. Решил его переделать для стрипов. Как расчитать стрип я вроде-как понял.
Ну для квада как-то так:
То что было : (0-1-2) и (2-3-0) - для три-лист - это мой текущий буфер индексов
А вот стрип : (0-1-2) и (1-3-2)  - для три-стрип - ВОПРОС! Это и есть индекс буфер для стрипов?

Трудность вся в понимании куда прикрутить индексы при стрипе? Делаю без индексов. всего 4 вершины просто в нужном порядке - и все рисуется стрипом... А как индексировать?

Смысл стрипов в том, что экономится место. Для первого треугольника задаешь три индекса(0-1-2), а для всех следующих только один индекс следующей(недостающей) точки. Например: (0,1,2; 3; 4) - индекс буфер с тремя треугольниками (0,1,2), (1,2,3), (2,3,4).

Mountaineer
Так то оно так, но я все равно не догоняю зачем для стрипов индексный буфер?

Пример:
вот 4 вершины

v3[0] = Vertex( 1.0f,  0.0f,  -10.0f);
v3[1] = Vertex( 1.0f,  5.0f,   -5.0f);
v3[2] = Vertex( 1.0f,  0.0f,    0.0f);
v3[3] = Vertex( 1.0f,  5.0f,    5.0f);

т.е. как-то так (с кривизны не гнать, вчера была днюха )))):

если в теле рендера написать нечто такое:

Device->DrawPrimitive(D3DPT_TRIANGLESTRIP, 0, 2); 

то вот что увидим:

Но, если я буду использовать индекс буфер:

i3[0]=0; 
i3[1]=1; 
i3[2]=2; 
i3[3]=3;

который по сути не меняет ни порядка вершин, ни чего....

а в рендере запишу так:
Device->SetIndices(IB3);
Device->DrawIndexedPrimitive(D3DPT_TRIANGLESTRIP, 0, 0, 4, 0, 2);
то картина не меняется !

Вопрос: каким макаром это вызовет оптимизацию, если буфер вершин придется делать большим чем при indexed TRI_LIST?
Придется все равно делать дегенеративные триугольники, которые простыми манипуляциями индексов не получится сделать. Треугольники вида А, А, В - А, В, С - В, В, С - В, С, Д..... Для таких придется дописывать в буфер вершин еще несколько значений.

Индексы вершин могут идти не последовательно. Поэтому в буфере индексов мы указываем этот самый порядок.

большинство вещей стрипом не сделаешь

Просто читал что если в программе массивные меши (более 100 К поликов) будут сделаны исключительно стрипами, то ФПС пондимется на 20-25%. Но это такой напряг, так что пока буду лепить индексированые листы, может через 2-3 года это не окажет сильного влияния на железо... Спасибы всем кто помогал ! :)

fzr125
Тут еще зависит, насколько они cache-friendly. Для этого есть специальные алгоритмы, которые перестраивают буфер индексов. Правда, не всегда можно получить положительный эффект.

ashujon
> большинство вещей стрипом не сделаешь
Каких например? У меня вроде все пока получалось.

JR-44
со стрипами ИМХО много гемора потом при прикручивании физики напр.
ещё могут быть неожиданности в вершинных и геом. шейдырах

При использовании индексов производительность будет выше, чем в случае стрипов - так говорит СуперКнига...

fzr125
Посмотри в DirectX SDK, там детально описано, какая выгода от стрипов и какая выгода от индексных буферов.

Mountaineer и Алмаз

Вы имели ввиду это?

However, decomposing meshes into strips and fans often results in a large number of separate pieces, implying a large number of DrawPrimitive calls. For this reason, the most efficient method is usually to use a single DrawIndexedPrimitive call with a triangle list.

fzr125
А мона по русски - а то я не шпилю english

JR-44
Можно:

Однако, разбиение объекта на стрипы и фаны часто приводят к увеличению отдельных частей, что означает большое кол-во вызовов DrawPrimitive. По этой причине наиболее эффективным методом, как правило, использовать единый вызов DrawIndexedPrimitive с triangle list.

Но там так и написано что не всегда, а - как правило.

JR-44
> Каких например? У меня вроде все пока получалось.
что именно получалось? я плохо себе представляю что можно было бы сделать одной сплошной полосой