Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.141.244.201] |
|
Страницы: (4) [1] 2 3 ... Последняя » все ( Перейти к последнему сообщению ) |
Сообщ.
#1
,
|
|
|
Когда я делаю рендер в текстуру, где у меня окажется буффер глубины? Как его достать в массив и как достать кстати в массив текстуру?
|
Сообщ.
#2
,
|
|
|
Нужно создать depth-текстуру (glTexImage2D с параметрами GL_DEPTH_COMPONENT, GL_FLOAT) и прицепить её к FBO (glFrameBufferTexture2D с параметром GL_DEPTH_ATTACHMENT).
Получить содержимое - забиндить FBO, потом glReadPixels, GL_DEPTH_COMPONENT/GL_FLOAT для Z-буфера или GL_BGRA/GL_UNSIGNED_BYTE для цвета. Но это медленно, фактически имеет смысл только для отладки. |
Сообщ.
#3
,
|
|
|
Т.е. Zbuffer будет каждый раз скидываться в эту depth текстуру?
А насколько медленно? Я каждый кадр скидываю софтвейрно рендереный массив в текстуру, посредством glTexImage2D. Насколько утормозит процесс добавления чтения забора и текстуры в массивы? И вообще как посоветуете поступить? Я рисую свой софтвейр на плоскости, хочу сочетать его с хардвейром, который хочу отрендерить на текстуру, после чего вручную сопоставить софт и хард с буффером и перегнать полученный общий массив в тестуру и.т.д. |
Сообщ.
#4
,
|
|
|
Цитата Serg2016_1 @ Самый мегатормоз - это функция glReadPixels, а glTexImage2D неоднократно оптимизировалась (даже ввели glTexSubImage), так что за неё не беспокойтесь. Насколько утормозит процесс добавления чтения забора и текстуры в массивы? |
Сообщ.
#5
,
|
|
|
Цитата Т.е. Zbuffer будет каждый раз скидываться в эту depth текстуру? А насколько медленно? Скорее, текстура используется в качестве Z-буфера. Даже если что-то там копируется, внутри видеокарты это должно быть быстро. Цитата Насколько утормозит процесс добавления чтения забора и текстуры в массивы? Зависит от качества конкретного драйвера, у меня, например, максимум 1 Гб/с получалось на ReadPixels. Если пересчитать на кадр 1920*1080, это 126 кадров/c, или 8 мс. При 60 FPS у тебя 16 мс на кадр, т.е. половину времени рендера ты потратишь на банальную пересылку картинки. Даже если с драйвером повезёт и пересылка будет быстрее, добавляется ещё лишняя синхронизация CPU и GPU, это тоже не прибавляет скорости. Цитата И вообще как посоветуете поступить? Я рисую свой софтвейр на плоскости, хочу сочетать его с хардвейром, который хочу отрендерить на текстуру, после чего вручную сопоставить софт и хард с буффером и перегнать полученный общий массив в тестуру и.т.д. А что рисуется софтверно, неужели нельзя это аппаратно нарисовать? Сейчас в шейдерах чего только не делают - рей-трейсинг, воксели и т.п. |
Сообщ.
#6
,
|
|
|
Пишу натуральный софтвейрный мохеровый воксель, без туды, куды, сюды (из принципа)... https://yadi.sk/d/_-_3Zjl4qAvoB
|
Сообщ.
#7
,
|
|
|
А на каком процессоре получалось 1Гб? Это у меня при 512x512 на 2 шт. текстур будет пару мс....
|
Сообщ.
#8
,
|
|
|
Цитата Пишу натуральный софтвейрный мохеровый воксель Это ландшафт что ли? В шейдерах (на видеокарте) и более сложное делают: https://www.shadertoy.com/view/XsX3RB Обычный 2D-ландшафт (в котором не может быть произвольных пещер) тоже наверное можно сделать. Другое дело, что сейчас воксели для этого применять нет особого смысла, проще загнать миллион-другой треугольников в регулярную полигональную сетку - будет лучше выглядеть и тоже деформируется в направлении вверх-вниз. Цитата А на каком процессоре получалось 1Гб? Это у меня при 512x512 на 2 шт. текстур будет пару мс.... Не в процессоре суть, а в видеокарте, точнее в конкретном драйвере видеокарты (Radeon 7750). AMD не особенно любит OpenGL и плохо оптимизирует драйвера. Через OpenCL на той же карте я получал 5 Гб/c. Ну, понятно - OpenCL им нужен для продвижения APU, поэтому они его активно "вылизывают". Пару мс на 2 небольшие текстуры - верю, это те же 1 Гб/c, но в направлении "туда", это практически любая карта может. |
Сообщ.
#9
,
|
|
|
А пишу в софте, потому, что ТАМ целый нереализованный мир и все прямо перед глазами, только взять. Автомонтаж появляться не спешит, а "Вангеров", вспоминают в народных эпосных поэмах...
|
Сообщ.
#10
,
|
|
|
Мне кажется, пытаться копировать старую игру 1 в 1 скучно. Хоть что-то своё привнести, хотя бы рендер сделать по-другому. А если хочется давить на ностальгические чувства игроков корявыми "софтверными" пикселями, то это можно через GL_POINTS имитировать.
Прикреплённый файлSurfVoxGL.zip (83,8 Кбайт, скачиваний: 207) R - переключение псевдовоксели/полигоны, 1,2,3 - разное разрешение карты. |
Сообщ.
#11
,
|
|
|
Ну, насчет корявых я бы поспорил, но шерсть, конечно есть....
Нет, не копировать, даже наоборот, очень много вариантов: хочешь rts/tbs, гонки на кувыркающихся багги, rpg фаллаут тот же, я например хочу очень tbs... На Андроне по-моему, при определенном подходе должно все крышки снять, и воксели они, все таки мозг зацепляют... Пробовал GL_LINES, был послан в космическую пустоту скоростью отрисовки )) А в surfvox у меня чето фпс хромает, 30/12/5... |
Сообщ.
#12
,
|
|
|
Цитата А в surfvox у меня чето фпс хромает, 30/12/5... У меня не хромает, 2000 / 1400 / 600 в зависимости от разрешения карты. Может быть, это конкретно точки тормозят, переключи на полигоны. Или видеокарта совсем слабая. |
Сообщ.
#13
,
|
|
|
Карта встр., нот, 1.86x1 у меня это критерий ))) Рассчитываю на старые компьютеры, фпс приподнялся 70/20/8...
Добавлено А это кстати GL_POINTS? А как они отрисовываются, Они разного рамера что-ли? |
Сообщ.
#14
,
|
|
|
Цитата Карта встр., нот, 1.86x1 у меня это критерий ))) Рассчитываю на старые компьютеры, фпс приподнялся 70/20/8... Сомнительное это занятие, оптимизация под древнее железо. Тем более оптимизация игры - у основной массы игроков с мощностями всё в порядке. Разве что действительно на Андроид рассчитывать, но там всё относительно слабое, и видеокарта, и процессор. Надо тестировать, что быстрее - софтвер или OpenGL-точки. Цитата А это кстати GL_POINTS? А как они отрисовываются, Они разного рамера что-ли? GL_POINTS через VBO (хотя на встроенной карте VBO не поможет). Размер точек задаю через glPointSize в зависимости от размера окна и карты, чтобы не было дырок. |
Сообщ.
#15
,
|
|
|
Вот если-бы еще и GL_lines работало...
У меня с фпс все хорошо, на средних настройках 50 и еще запас по оптимизации, но единственное конечно трудновероятно сделать true perspective, приходится довольствоваться орто(чему я очень и рад), либо искаженной перспективой. Можно правда написать алгоритм диагональной штриховки, для заделки дыр, и причем вполне. С полигональной отрисовкой, по большому счету будет тот-же эффект, как от вокселей, если делать без белины(рушится параллакс, цветность выпадает, контрастность там..... Белиной надо рисовать тени, а чтобы nearest не топорщился надо использовать мипмап и малую контрастность(все равно цветом завалит по сравнению с фильтрованным)), но у воксов все равно своя прелесть ))(там обитают грифоны) |