Dx9

[Sneaks]

Доброго всем время суток,
потихоньку разбираюсь в дх9, при поддержки Майкла, конечно же.
Буду сюда писать все свои нубские вопросы.
Собственно говоря назрел очередной:
Вопрос про DrawIndexedPrimitive.
Я так понял при помощи него можно рисовать не только под ряд все вертексы, а и выборочно, согласно списка - индекс буфера.
На примерах я понял что он работает так: когда мы загоняем в вертекс буфер вертекс, мы сразу загоняем и в индекс буфер по аналогии с вертекс буфером, но почему то длинна его не такая как у вертекс буфера.
В общем если не сложно объясните тонкости.

[Mikle]

когда мы загоняем в вертекс буфер вертекс, мы сразу загоняем и в индекс буфер по аналогии с вертекс буфером,

Неверно. Тут рядом есть тема: viewtopic.php?f=6&t=34270, там в книге довольно подробно расписано про индексы, что они дают, что делают. Там про DX8, но работа индексного буфера осталась совершенно той же.

[Sneaks]

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

[Mikle]

на каждую текстуру иметь свой буфер.

Так обычно и делается, только формулируют это более общим образом - на каждый материал свой буфер. Материал не в смысле только D3DMATERIAL9, а и плюс шейдер (или набор строк SetTextureStageState), плюс текстуры.

[Sneaks]

Следующий вопрос
Делаю подобие частиц. Два полигона, на него текстуру с альфой все как в примере.
Сортирую по расстоянию, и рисую их в порядке от дальнего к ближнему в один буфер с учетом поворота на камеру.
Вот пример:
https://yadi.sk/d/OaUKAWe_3GtnrV
Управление - стрелочки и PgUp, PgDnw, P(русская З) - добавлять частицы, ограничение 200

Вопрос: можно ли так делать, не слишком это трудозатратное дело для CPU. И есть ли другие решения?
Забыл: решение по разным текстурам: все текстуры закунить в одну физическую, а в полигонах, согласно атласу, ставить tu tv согласно необходимой.
ЗЫ пример рабочий, верней даже черновик. Я на нем эксперементирую и учусь, так что за него сильно не бить, там все в свалке.
В примере есть к стати загрузчик .obj файлов, из минусов обж нашел только то что он много весит, т.к. ни чем не сжат, для обучения пойдет и скидывать с макса можно на прямую.

[Mikle]

Сортирую по расстоянию

При таком типе частиц этого можно избежать, они подразумевают аддитивный блендинг, в таком случае можно не упорядочивать.
Если частицы движутся средствами CPU каждый кадр, можно не использовать вертексный буфер, а рисовать прямо из массива с помощью DrawPrimitiveUp или DrawIndexedPrimitiveUp.

[Mikle]

Посмотри в теме моей игры BeQuits, там есть исходник, в нём модуль modCloud.bas - это весь дым, в модуле всего 5 Public процедур:
CloudInit - вызывается однократно в начале после инициализации D3D.
CloudTerminate - вызывается однократно в конце перед уничтожением D3D.
CloudAdd - добавить одну частицу дыма.
CloudTick - вызывается периодически (у меня 200 раз в секунду).
CloudDraw - вызывается из цикла рендера для рисования дыма.
Всё! Можно брать модуль и вставлять в другой проект, ничего лишнего. А твой проект читать очень тяжело, всё намешано, ещё и форматирование отсутствует.

[Sneaks]

Ну то что намешано я предупреждал, это эксперементальный, там все и сразу и в разных вариациях.
слямзил у тебя рендер стейты и все заработало.
Обидно что не понимаю что произошло.
Да и DrawPrimitiveUp не понятен. Начал искать в инете чем он отличается от обычного DrawPrimitive, толкового описания не нашел.

[Mikle]

DrawPrimitiveUp не понятен.

Это рендер геометрии без использования вертексного буфера, прямо из массива в памяти. Это медленнее, чем с использованием вертексного буфера, но, когда ты каждый кадр меняешь в вертексном буфере данные и засылаешь их туда (SetData или Lock, не важно), это получается то же самое, если не медленнее.

слямзил у тебя рендер стейты и все заработало.
Обидно что не понимаю что произошло.

Не начинай делать большой проект, пока не понял мелочи, погрязнешь. Делай маленькие тесты, примерно как примеры из книги, задавай вопросы, на примере таких маленьких проектов отвечать легче.

[Sneaks]

Переделал на примитивАП тесты показали:
200 частиц с АП: падение с 2600 до 1000 фпс
так же 200 частиц но с буфером: падение с 2600 до 1700 фпс.
Я так понял по производительности если я буду передвигать частицы в буфере каждый кадр то выходит одинаково. Но за счет того что я передвигаю частицы по таймеру и перерисовываю их в буфере, соответственно тогда же, т.е. реже чем каждый кадр то и фпс в итоге выше.
В общем пока не нашел применения дроПримитивАПам, думал можно через него рисовать скинед меши, но по логике этих же частиц, выгодней через буфер, т.к. менять его не обязательно каждый кадр, то выходит даже дешевле.

[Mikle]

Тут не всё так просто. С "ап"ом буфер фактически обновляется столько раз в секунду, какой fps, поэтому при больших fps просадка больше. При реальных игровых fps, особенно при включенном vSync, влияние будет меньше.

[Sneaks]

Продолжаю изучение, рисую полигоны с разными текстурами и остальными стейжами, дело дошло до скининг меш. По что сам ручками выставляю координаты точек, и их закидываю в буфер, все вроде нормально, наткнулся что это может делать как то сама видеокарта. Вопрос: может ли? и если да, то в какую сторону копать?

[Mikle]

Вопрос: может ли? и если да, то в какую сторону копать?

В сторону создания анимированной модели в редакторе и экспорта её в .x.
Сам я этим не занимался, делаю анимацию своими велосипедами.

[Sneaks]

Я опять со своими нубскими вопросами
мне нужно объект из одного буфера вставить в другой буфер, но с изменением - угол поворота и масштаб. Есть ли какие нибудь средства для этого? или мне так же вытаскивать и самому ручками делать изменения и вставлять?

[Mikle]

Вручную. Проходим циклом по вертексам, умножаем на соответствующую матрицу, помещаем во второй буфер, ничего сложного.
Главное - нормали правильно трансформировать, для них не годится та матрица, что для позиций, для поворота и масштаба нормали можно умножать на транспонированную инверсную матрицу.

[Sneaks]

Не уж то взрослые дядьки в своих крутых проектах морфинг объектов, такие как шевеление деревьев от ветра, в ручную изменяют координаты точек? У меня на модель в 6к полигонов фпс просело очень сильно, с 3500 до 500. Я понимаю что 6к это приличная цыфра и в игре на дереве будет гораздо меньше полигонов. Меня беспокоит что я что то не через то делаю.

[Mikle]

Не уж то взрослые дядьки в своих крутых проектах морфинг объектов, такие как шевеление деревьев от ветра, в ручную изменяют координаты точек?

Конечно нет. Я когда-то писал статью как раз про "шевеление деревьев от ветра": http://www.uraldev.ru/articles/id/30
Можно обойтись и без шейдера, с помощью Vertex Blending.

[Sneaks]

блин, я до шейдеров еще не дошел. У меня по программе еще должно быть:
морфинг, скелетная анимация, разобрать с текстурированием (бамп, лайтмапы и т.д.) и только после этого собирался разбираться что такое шейдеры и как их использовать. Пока что для меня большая половина статьи написана на китайском
Похоже надо переформировывать порядок.
А где тогда можно ознакомиться с шейдерами на ВБ на языке для чайников? как твоя книга, очень понравилась, все разжовано и внятно.

[Mikle]

блин, я до шейдеров еще не дошел

Так я же написал:

Можно обойтись и без шейдера, с помощью Vertex Blending.

Это не так гибко, как шейдер, но кое-что сделать можно.

[Sneaks]

Глупые вопросы продолжаются:
Как можно получить координаты в проекции точки с использованием ДХ?
Т.е. мне нужны именно цифры где точка(вертекс) окажется уже на моем фрейме(Форме или картинке - не важно)?
Пояснения - хотел бы простым способом вытаскивать координаты объекта на экране. Как это сделать без участия ДХ вкурсе, формулы имеются. Просто не хотелось бы пересчитывать это все самому по второму разу еще и медленней.

[Mikle]

мне нужны именно цифры где точка(вертекс) окажется уже на моем фрейме(Форме или картинке - не важно)

Вычитаешь из позиции вертекса позицию камеры.
Нормализуешь полученный вектор.
Дотпродукт полученного вектора с нормализованным вектором вправо - это координата X а экране.
Дотпродукт полученного вектора с нормализованным вектором вверх - это координата Y а экране.
Координаты получаются от -1 до 1.

Как это сделать без участия ДХ вкурсе, формулы имеются. Просто не хотелось бы пересчитывать это все самому по второму разу еще и медленней.

Что имеется ввиду под участием DX? Если ты пишешь, к примеру, D3DXVec3Cross, это не значит, что расчёты будут на видеокарте, это считает проц. Такие простые расчёты на видеокарте считать и не выгодно - больше времени уйдёт на отправку и приём данных.

[Sneaks]

Ясненько, спасибо!

[Mikle]

Маленькое уточнение, вектор вправо нормализуем не к единице, а к величине Tan(FovX/2), вектор вверх к Tan(FovY/2). Это можно сделать однократно, если не меняется угол камеры.
И нормализация первого вектора тоже не совсем простая, мне сейчас тяжело сходу написать, компа с бейсиком нет под рукой, постараюсь позже вечером.

[Mikle]

Вот, проверил:

Код: Выделить всё

  Vec3Subtract v, ThingPos, CamPos
  Vec3Scale v, v, 1 / Vec3Dot(CamDir, v)
 
  TestX = (Width + Vec3Dot(CamRight, v) / Tan(FovY / 2) * Height) * 0.5
  TestY = (Height - Vec3Dot(CamUp, v) / Tan(FovY / 2) * Height) * 0.5


TestX и TestY - координаты точки на экране от верхнего левого угла (в пикселях).
Width и Height - размер бэкбуфера в пикселях.
CamPos - позиция камеры.
CamDir, CamRight и CamUp - нормализованные направления вперёд, вправо и вверх.
То есть мы нормализуем не само направление на объект, а по его проекции на направление вперёд.

[Sneaks]

Спасибо, я только завтра смогу проверить

[Sneaks]

Начал топорным методом пересчета направления камеры через синусы косинусы.
Пока копался в инете как это делают другие меня осенило
MatrixLookAtLH Mtrx, Vec3(cam(0), cam(1), cam(2)), Vec3(cam(3), cam(4), cam(5)), Vec3(0, 10, 0)
В этой матрице, если я не заблуждаюсь, должны быть как раз те цыферки направления камеры.
Посмотрел что в этой матрице и увидел что Matrx.m3х схоже с моими показаниями направления вперед.
Могу ли я тупо тягать таким образом направления и не ошибаюсь ли я в этом?

[Sneaks]

Вот что у меня вышло с последней редакцией:

Код: Выделить всё

Dim v As D3DVECTOR, CamPos As D3DVECTOR, ThingPos As D3DVECTOR, CamDir As D3DVECTOR
Dim CamUp As D3DVECTOR, CamRight As D3DVECTOR
Dim Width As Single, Height As Single

  MatrixLookAtLH Mtrx, Vec3(cam(0), cam(1), cam(2)), Vec3(cam(3), cam(4), cam(5)), Vec3(0, 10, 0)

CamPos.x = cam(0)
CamPos.y = cam(1)
CamPos.z = cam(2)

CamDir.x = Mtrx.m31
CamDir.y = Mtrx.m32
CamDir.z = Mtrx.m33

CamUp.x = Mtrx.m21
CamUp.y = Mtrx.m22
CamUp.z = Mtrx.m23

CamRight.x = Mtrx.m11
CamRight.y = Mtrx.m12
CamRight.z = Mtrx.m13

Height = IndBuff.ScaleHeight
Width = IndBuff.ScaleWidth

FovY = 90

ThingPos.x = 10
ThingPos.y = 30
ThingPos.z = 50

  Vec3Subtract v, ThingPos, CamPos
  Vec3Scale v, v, 1 / Vec3Dot(CamDir, v)
 
  TestX = (Width + Vec3Dot(CamRight, v) / Tan(FovY / 2) * Height) * 0.5
  TestY = (Height - Vec3Dot(CamUp, v) / Tan(FovY / 2) * Height) * 0.5
 
  Line (TestX, TestY)-(TestX + 20, TestY + 20), 200, BF



Точка на экране есть но двигается по своим закоконом. Пробовал с фов играться - не в этом дело.

[Mikle]

Могу ли я тупо тягать таким образом направления и не ошибаюсь ли я в этом?

Такие базовые вещи, как позиция и направление камеры, не нужно ниоткуда "тягать", наоборот, это должны быть базовые переменные (либо свойства объекта "камера"), исходя из них уже вычисляется матрица VIEW (например, с помощью MatrixLookAtLH).
Только следует помнить, что третий вектор в параметрах MatrixLookAtLH - это не строго направление вверх относительно камеры, а всего лишь вектор, задающий вертикальную плоскость, проходящую через вектор Dir, а второй вектор - это не направление вперёд (Dir), а позиция точки, находящейся впереди камеры, на которую мы смотрим, чтобы получить её, нужно прибавить к позиции камеры вектор Dir.
Ещё, у тебя там есть строка FovY = 90, это ошибка, все формулы работают с радианами, а не градусами.

[Sneaks]

не пояснил, мой косяк, согласен.
cam(0) - координата позиции камеры по Х
cam(1) - координата позиции камеры по У
cam(2) - координата позиции камеры по Z
cam(3) - координата позиции цели взора по Х
cam(4) - координата позиции цели взора по Y
cam(5) - координата позиции цели взора по Z

Наверное косяк в фов сейчас переделаю и посмотрю.

[Mikle]

cam(0) - координата позиции камеры по Х
cam(1) - координата позиции камеры по У
cam(2) - координата позиции камеры по Z
cam(3) - координата позиции цели взора по Х
cam(4) - координата позиции цели взора по Y
cam(5) - координата позиции цели взора по Z

Это я и так понял, хотя всё это как-то странно, но основная мысль была другая:
Такие базовые вещи, как позиция и направление камеры, не нужно ниоткуда "тягать"

Вперёд и вправо получается так:

Код: Выделить всё

Vec3Subtract CamDir, vAt, CamPos 'vAt - тот вектор, который задаётся в MatrixLookAtLH
Vec3Normalize CamDir, CamDir
Vec3Cross CamRight, vUp, CamDir 'vUp - тот вектор, который задаётся в MatrixLookAtLH
Vec3Normalize CamRight, CamRight
Vec3Cross CamUp, CamDir, CamRight 'CamUp - направление вверх камеры