|
|
|
Канал Игры Мечты: «FAQ по OpenGL» |
|
|
Kamizeka
370 EGP
  Рейтинг канала: 3(27) Репутация: 136 Сообщения: 1037 Откуда: Калуга - родина космонавтики Зарегистрирован: 14.06.2005
 |
|
Zachesa : |
а хороший ИИ на последнем месте
|
Это происходит совершенно не из-за недостатка ресурсов.
_________________ Something's rotten in the state of Denmark. |
|
|
Shirson
1605 EGP
           Рейтинг канала: 7(626) Репутация: 219 Сообщения: 16511 Откуда: 79°W 44°N Зарегистрирован: 29.01.2002
 |
|
Можно прояснить связь между визуальностью средств разработки и невозможностях алгоритмов ИИ, а так же бока, с которого тут графические красоты?
_________________ У меня бисера не доxеpа. |
|
|
Jurec
348 EGP
   Рейтинг канала: 4(76) Репутация: 102 Сообщения: 1441 Заблокирован Откуда: Seattle Зарегистрирован: 25.02.2006
 |
|
Присоединяюсь к вопросу Shirson`а
_________________ MOV topka, C++ |
|
|
Diff
708 EGP
      Рейтинг канала: 2(11) Репутация: 44 Сообщения: 4179 Откуда: Сферическая Земля в вакууме. Зарегистрирован: 04.07.2003
 |
|
Jurec : |
Кстати, физику сейчас модно переносить на GPU
|
Не. Последний писк моды - это физические ускорители. Типа такого: http://www.overclockers.ru/lab/22639.shtml. Не исключено, что через пару-тройку лет такого рода девайс будет таким же обязательным аттрибутом игрового компьютера, как и GPU.
Zachesa : |
Скажем для выполнения алгоритмов ИИ, где многие задачи можно распараллелить, вдруг удастся задействовать ресурсы GPU. Единственно в ближайшие годы врядли увидим возможность использовать эти возможности в визуальных средах разработки (Visio, Delphi) народ помешался на графических красотах, а хороший ИИ на последнем месте.
|
Расчет ИИ средствами GPU для Delphi. Пишите еще...
_________________ Конец света в конце тоннеля |
|
|
Shirson
1605 EGP
           Рейтинг канала: 7(626) Репутация: 219 Сообщения: 16511 Откуда: 79°W 44°N Зарегистрирован: 29.01.2002
 |
|
Diff : |
Не. Последний писк моды - это физические ускорители.
|
Подтверждаю. Сам являюсь обладателем PhysX, который по умолчанию идёт с делловскими XPS.
Вполне закономерно, есть надобность - сделают железку. Физике - физиково, ГПУ - ГПёво
_________________ У меня бисера не доxеpа. |
|
|
Kamizeka
370 EGP
  Рейтинг канала: 3(27) Репутация: 136 Сообщения: 1037 Откуда: Калуга - родина космонавтики Зарегистрирован: 14.06.2005
 |
|
Честно говоря, мне будущее физикса и ко представляется сомнительным (из-за боттлнеков и неуниверсальности, в отличие от GPU, которые плавно расширяют возможности), однако эти детали скорее для флеймваров на iXBT. А эта тема всё же называется FAQ по OpenGL
_________________ Something's rotten in the state of Denmark.
Последний раз редактировалось: Kamizeka (22:33 12-06-2008), всего редактировалось 2 раз(а) |
|
|
Shirson
1605 EGP
           Рейтинг канала: 7(626) Репутация: 219 Сообщения: 16511 Откуда: 79°W 44°N Зарегистрирован: 29.01.2002
 |
|
Согласен, завязываем тут с оффтопом
_________________ У меня бисера не доxеpа. |
|
|
Duh
101 EGP
 Репутация: 20 Сообщения: 269 Откуда: Ярославль Зарегистрирован: 18.07.2004
 |
|
Собственно еще вопрос: у меня появилась потребность использовать прозрачность (для отрисовки выхлопов движков), и для корректной отрисовки требуется синхронизация буфера глубины и буфера, в котором смешиваются цвета. Как вариант советуется сортировка по глубине с последующим рендерингом. В принципе мне это не в лом, только тормозить должно дико, в связи с чем резонный вопрос - кто-нибудь знает, как делать это аппаратно?
|
|
|
Jurec
348 EGP
   Рейтинг канала: 4(76) Репутация: 102 Сообщения: 1441 Заблокирован Откуда: Seattle Зарегистрирован: 25.02.2006
 |
|
Duh : |
только тормозить должно дико
|
кто сказал?
Сортировка делается везьде. Исключения составляют можели прозрачности основанные на сложении. Тогда не важно как рисуешь (от перестановки слагаемых сумма не меняется).
Сортируй.
_________________ MOV topka, C++ |
|
|
Duh
101 EGP
 Репутация: 20 Сообщения: 269 Откуда: Ярославль Зарегистрирован: 18.07.2004
 |
|
Дык участок кода критический. Посуди сам - каждый раз перед отрисовкой компу надо будет устроить сортировку по оси x в с.к. камеры для всех двигателей всех кораблей. А для этого перед сортировкой для каждого двигла надо будет переходить в с.к. камеры, т.е. за счет CPU считать обратную матрицу модели, из которой этот движек торчит. В противном случае, при перекрытии изображений выхлопов от движков разных шипов начнут вылезать пакости, разные и неприятные. А движков в шипе будет до 6 сзади + до 4 спереди, шипов на сцене штук 70....
Sh.Tac. : |
могу только догадываться зачем Duh'у понадобился Р-буфер... но задник можно например выводить в него
|
Задник им и рисую .
Sh.Tac. : |
хотя гораздо проще для задников отключиить Z-буфер, отсортировать их самостоятельно и нарисовать, потом включить обратно и нарисовать уже ближнюю сцену с нужной степенью детальности
|
В пределах звездной системы так и рисую. P-buffer мне нужен, чтоб с галактикой веселиться - при залете в зв.систему сделал рендер один раз, а потом рисовать надо только кубик.
Последний раз редактировалось: Duh (09:56 19-06-2008), всего редактировалось 3 раз(а) |
|
|
Jurec
348 EGP
   Рейтинг канала: 4(76) Репутация: 102 Сообщения: 1441 Заблокирован Откуда: Seattle Зарегистрирован: 25.02.2006
 |
|
Duh : |
по оси x в с.к. камеры
|
по оси z
Duh : |
за счет CPU считать обратную матрицу модели
|
1) даже если пришлось бы - не критично
2) просто умножать на матрицу камеры
Duh : |
В противном случае, при перекрытии изображений выхлопов от движков разных шипов начнут вылезать пакости, разные и неприятные
|
Начнут. Бери все партиклы в 1 буфер и сортируй.
Duh : |
шипов на сцене штук 70
|
Сразу? Это много.
А вообще я смотрю ты сильно преуменьшаешь возможность CPU..
добавлено спустя 3 минуты:
Ты думаешь я не писал системы частиц?
_________________ MOV topka, C++
Последний раз редактировалось: Jurec (10:47 19-06-2008), всего редактировалось 2 раз(а) |
|
|
Jerry Rezet
581 EGP
  Рейтинг канала: 5(113) Репутация: 86 Сообщения: 3365 Откуда: Санкт-Петербург. Зарегистрирован: 01.04.2005
 |
|
Jurec, Тут вопрос возник..
А такие функции, как glVertexPointer(3, GL_FLOAT, 0, @Vertex[0]); например - они, как я видел в первом посте темы, не обрамляются операторными скобками glBegin() и glEnd? Но ведь всё, что должно рисоваться обычно помещается внутри этих операторных скобок? Можешь растолковать ламеру, что и как с применением ГЛ-ных функций рисования с использованием массивов?
_________________ - Вы не представляете, как вам повезло, что я здесь. Вы об этом еще пожалеете. [c]
Последний раз редактировалось: Jerry Rezet (04:32 01-04-2009), всего редактировалось 1 раз |
|
|
Digited
271 EGP
   Рейтинг канала: 4(99) Репутация: 49 Сообщения: 932
Зарегистрирован: 24.08.2004
 |
|
Jerry Rezet : |
А такие функции, как glVertexPointer(3, GL_FLOAT, 0, @Vertex[0]); например - они, как я видел в первом посте темы, не обрамляются операторными скобками glBegin() и glEnd? Но ведь всё, что должно рисоваться обычно помещается внутри этих операторных скобок?
|
Видеодрайвер принимает на отрисовку массив вершин, а для этого массива - опционально вспомогательные массивы: цвета, нормалей, текстурных координат, индексов.
glBegin/glEnd и gl***Pointer/glDrawArrays/Elements - это два способа отправки таких данных на отрисовку. Первый - старый и максимально медленный, второй - быстрый. В директе первого вообще нет, есть только аналог второго - DrawIndexedPrimitives. Когда перетирают за графику, часто проскакивает термин DIP - как раз имеется ввиду вызов DrawIndexedPrimitives в директе, то есть единичная команда отправки блока вершинных данных в видеодрайвер. (glDrawArrays - аналогично). Чем больше DIPов за кадр, тем больше нагружается драйвер (CPU) и больше накладных расходов на организацию переправки геометрии в видеокарту по шине, поэтому в играх (в рендерерах) нужно стремиться свести количество DIPов к минимуму или хотя бы не злоупотреблять ими, то есть группировать геометрию по-всякому и отсылать максимально большими порциями. При использовании glBegin/glEnd количество DIPов - неимоверное. Драйвер кеширует их, но все же из-за этого нагрузка на проц засчет работы драйвера прилично выше, чем при переправке массивов вершин/цветов/текс координат и пр.
p.s. максимальная скорость отрисовки - когда эти массивы данных уже находятся в озу видеокарты - google vertex buffer object
p.p.s. Юра уточнил, что glBegin + glEnd = 1 DIP и что стоимость дипа в гл ниже, чем в директе.
Последний раз редактировалось: Digited (13:49 05-05-2009), всего редактировалось 2 раз(а) |
|
|
Jerry Rezet
581 EGP
  Рейтинг канала: 5(113) Репутация: 86 Сообщения: 3365 Откуда: Санкт-Петербург. Зарегистрирован: 01.04.2005
 |
|
Директ меня не интересует - я в нём "нивзубкопытом". То есть, грубо говоря, из какого бы места (попадающего в "главный поток", типа ф-ции main) не вызывалась функция gl***Pointer/glDrawArrays/Elements - она отрисуется, и её незачем пихать в операторные скобки? Меня только это интересует.
_________________ - Вы не представляете, как вам повезло, что я здесь. Вы об этом еще пожалеете. [c] |
|
|
Варсик
545 EGP
    Рейтинг канала: 4(81) Репутация: 117 Сообщения: 4041 Откуда: Москва Зарегистрирован: 22.12.2002
 |
|
Обычно делают так: Есть основной "графический" цикл и основной "игровой" цикл. Вот Графический начинается с glBegin и заканчивается glEnd. То есть фактически вся отрисовка = 1 DIP'у
_________________ WARNING: By reading this post you accept that this post is genius. |
|
|
Jerry Rezet
581 EGP
  Рейтинг канала: 5(113) Репутация: 86 Сообщения: 3365 Откуда: Санкт-Петербург. Зарегистрирован: 01.04.2005
 |
|
Warstone : |
Обычно делают так: Есть основной "графический" цикл и основной "игровой" цикл. Вот Графический начинается с glBegin и заканчивается glEnd. То есть фактически вся отрисовка = 1 DIP'у
|
Это и ЕЖу понятно.. Но меня всё же интересует.. эмм.. как бы это выразится..
Jerry Rezet : |
То есть, грубо говоря, из какого бы места (попадающего в "главный поток", типа ф-ции main) не вызывалась функция gl***Pointer/glDrawArrays/Elements - она отрисуется, и её незачем пихать в операторные скобки? Меня только это интересует.
|
_________________ - Вы не представляете, как вам повезло, что я здесь. Вы об этом еще пожалеете. [c]
Последний раз редактировалось: Jerry Rezet (05:57 06-05-2009), всего редактировалось 1 раз |
|
|
Digited
271 EGP
   Рейтинг канала: 4(99) Репутация: 49 Сообщения: 932
Зарегистрирован: 24.08.2004
 |
|
Нет, незачем.
Есть еще один момент: видеокарта при подготовке кадра использует свой процессор и озу видеокарты, программа - центральный процессор и системное озу, то есть аппаратно ускоренная компьютерная графика создается в двух компьютерах, работающих параллельно. Для получения наибольшего фпс важно это использовать.
Если цикл работы приложения такой:
//------- кадр n -----------------------------
1. получение сообщений оси (системный цикл)
2. обработка объектов сцены
3. физика
4. сеть
5. подготовка данных для отрисовки
6. отправка данных для отрисовки в драйвер
7. переключение видеобуферов
//---------------------------------------
то производительность системы будет складываться из времени работы центрального процесора на 1-5 + времени работы видеоподсистемы 6-7. По сути, вместо параллельной работы получаем последовательную.
Параллельная работа достигается таким порядком:
//------- кадр n -----------------------------
1. получение сообщений оси (системный цикл)
2. обработка объектов сцены
3. физика
-. сеть в отдельном потоке
4. подготовка данных для отрисовки
5. переключение видеобуферов для вывода кадра n-1
6. отправка данных для отрисовки в драйвер (и вообще вся работа с ним)
//---------------------------------------
|
|
|
Варсик
545 EGP
    Рейтинг канала: 4(81) Репутация: 117 Сообщения: 4041 Откуда: Москва Зарегистрирован: 22.12.2002
 |
|
Гм... Откройте для себя VBO и расширения OpenGL. Тогда будет так:
1. Загрузка ресурсов в видео карту
2. "Заполнение" "макроса" который ворочает мешами
3. Передача его видео карте. (Реальные данные сетки, ктестур и т.д. уже там)
_________________ WARNING: By reading this post you accept that this post is genius. |
|
|
Jerry Rezet
581 EGP
  Рейтинг канала: 5(113) Репутация: 86 Сообщения: 3365 Откуда: Санкт-Петербург. Зарегистрирован: 01.04.2005
 |
|
Warstone : |
Гм... Откройте для себя VBO и расширения OpenGL. Тогда будет так:
|
Эмм.. Тутбэ, типа, ОпанькиГЛ как-нибудь освоить.. А потом и ВБОхиваться во всякие расширения и расфигачивания..
Вобщем понятно. Огромедное спасибищще и респегт.
_________________ - Вы не представляете, как вам повезло, что я здесь. Вы об этом еще пожалеете. [c] |
|
|
Варсик
545 EGP
    Рейтинг канала: 4(81) Репутация: 117 Сообщения: 4041 Откуда: Москва Зарегистрирован: 22.12.2002
 |
|
Ну... Все-таки откройте. Код поменяется не сильно, а скорость возрастет в 100 а то и больше раз.
_________________ WARNING: By reading this post you accept that this post is genius. |
|
|
|
|
|
Канал Игры Мечты: «FAQ по OpenGL» |
|