Войти
ПрограммированиеФорумГрафика

Рендер GUI (2 стр)

Страницы: 1 2 3 4 5 6 Следующая »
#15
13:42, 31 янв. 2019

Мизраэль
Интересная библиотека. Как я понял имеется возможность реализовать интерфейс GPUDriver для рендеринга геометрии. Только в репозитории какой-то бардак


#16
(Правка: 14:27) 14:24, 31 янв. 2019

zkolosok
> Все элементы засунуть в один буфер ясное дело не получится, поскольку есть
> иерархия, т.е.
> виджеты, которые содержатся в контейнерах, должны рисоваться после своих
> родителей.
Так это Вулкан надо использовать, он позволяет рисовать виджеты из одного буфера по порядку, а не как говно API

#17
14:34, 31 янв. 2019

NyakNyakProduction
А в OpenGL нет гарантии на то, что все треугольники отрисуются по порядку?

В принципе, если добавить z координату к виджетам, то можно и в один буфер все запихать. Но это так себе решение, конечно.

#18
17:14, 31 янв. 2019

Мизраэль
>Можете эту посмотреть: https://ultralig.ht/

Не понял, там web-браузер внутри? Chrome?

#19
18:34, 31 янв. 2019

После чтения форума на тему gui понял, что все элементы перед отрисовкой можно положить в vbo, а затем одним вызовом glDrawElements отправить на рендер. (используя при этом текстурный атлас)

Но! Непонятным остается следующее: каким образом при таком подходе организовать порядок отрисовки? (окно заслонило другое окно, надпись на кнопке, кнопка на окне)

Если ли способ такой сортировки при отключенном depth буфере и использовании одного vbo?

#20
18:42, 31 янв. 2019

zkolosok
glDrawElements() гарантирует порядок отрисовки же.
https://stackoverflow.com/a/22237165

#21
(Правка: 18:44) 18:43, 31 янв. 2019

zkolosok
Видяха рисует треугольники поочередно. Поэтому второй отрисует поверх первого. У меня используется именно такой подход (при этом текстуры максимально запихиваются в один атлас, или как вариант - заюзать массив текстур, позволяющий использовать множество текстур за один вызов).

С другой стороны интерфейс можно рисовать чисто аналитически в шейдере. Я с таким тоже повозился, было красиво на разных DPI, с учетом динамического масштаба и так далее, но переключение шейдеров и множество вызовов подсадило фпс.

Кстати посмотри на GWEN или его форк GWork:
https://github.com/billyquith/GWork
Вполне легкая для понимания либа, именно она меня натолкнула на мысль о том, что создание своего интерфейса не такое уж и сложное занятие.

#22
20:44, 31 янв. 2019

zkolosok
> Но! Непонятным остается следующее: каким образом при таком подходе организовать
> порядок отрисовки? (окно заслонило другое окно, надпись на кнопке, кнопка на
> окне)
>
> Если ли способ такой сортировки при отключенном depth буфере и использовании
> одного vbo?
Видеокарта обрабатывает каждый треугольник в отдельном потоке и растеризирует их так же, потому при наложении двух треугольников с одной глубиной могут вылезать проблемы.
Просто через координату Z передавай номер слоя, тогда все будет нормально сортироваться. При ортографической проекции никаких проблем такое решение не вызовет.

На счет остального - есть куча вариантов.
Если структура интерфейса фиксирована (не будут создаваться новые окна) то можно все через один glDrawElements все выводить, видимость отдельных виджетов можно контролировать через масштаб, просто умножаешь координаты элементов виджета на 0, получаешь вырожденные треугольники, которые автоматически не рисуются видеокартой. Тоесть при активных действиях просто обновляешь в буфере VBO параметр Scale для нужных вершин.
Второй способ - можно использовать SSBO для хранения информации о каждом виджете, включая номер слоя, в этом случае просто по ID виджета берешь всю необходимую информацию и рисуешь его.
Третий вариант - все элементы виджета это квады, тоесть можно сделать один квад, загнать в SSBO параметры всех элементов всех виджетов, а потом, через один вызов glDrawElementsInstanced отрисовать все эти элементы как отдельные инстансы.

С текстурами там тоже в принципе все просто, это или атлас, или массив текстур или "Bindless Texturing". В первом случае могут быть проблемы с фильтрацией при уменьшении размера элемента меньше его размера в текстуре, во втором случае будут проблемы с текстурами, так как они должны быть все одного размера, в третьем - нет никаких проблем. Ну и естественно все эти три способа можно комбинировать.

#23
21:54, 31 янв. 2019

Fantom09
> потому при наложении двух треугольников с одной глубиной могут вылезать проблемы.
Нет, при одинаковой глубине треугольники рисуются согласно своему номеру в буфере.
Z-fighting — он из за ошибок округления немного разной глубины.

> Просто через координату Z передавай номер слоя, тогда все будет нормально сортироваться.
Если интерфейс не квадратно-гнездовой, а модный полупрозрачный или, хотя бы, с антиалиасенными краями, то задание глубины никак не поможет.

#24
(Правка: 1:26) 1:09, 1 фев. 2019

}:+()___ [Smile]
> Нет, при одинаковой глубине треугольники рисуются согласно своему номеру в
> буфере.
Вообще нигде, ничем и никак не гарантируется (если есть пруф, доказывающий обратное - с удовольствием ознакомлюсь).

Каждый треугольник обрабатывается независимо, от трансформации вершин до растеризации. Никакой синхронизации между ними нет и быть не может.
Да, они попадают в очередь последовательно, а вот дальше уже может быть что угодно, где-то сработает T&L кеш и один из треугольников "выстрелит" раньше, где-то появится задержка из-за неоптимального расположения индексов/вертексов или из-за произвольного чтения из буферов, или даже банально производительность отдельных ядер может отличаться.

Отдельно можно поговорить о растеризации, один из классических примеров порядка растеризации:
https://www.geeks3d.com/20131031/opengl-4-2-atomic-counters-raste… indows-linux/

Там отлично видно что не смотря на то, что в целом пиксели треугольников растеризируются в порядке следования треугольников, но отдельные блоки могут растеризироваться когда угодно.

Где-то еще даже демка от NVidia была, там эту проблему (наложение квадов с декалями) решают через NV_fragment_shader_interlock и барьеры. Проблема там немного другая, квады декалей не в одном буфере а в разных, но суть та же:
http://gameworksdocs.nvidia.com/GraphicsSamples/NormalBlendedDecalSample.htm
GPU doesn't guarantee the order of the fragment's shader invocations. Thus, it may result in flickering or undefined artifacts when multiple decals are overlapped.

}:+()___ [Smile]
> Если интерфейс не квадратно-гнездовой, а модный полупрозрачный или, хотя бы, с
> антиалиасенными краями, то задание глубины никак не поможет.
Да, это как раз проблема описанная выше (да и вообще проблема прозрачности, не имеющая простого решения), мы никак не можем контролировать порядок вывода, потому с многослойным полу-прозрачным интерфейсом будут проблемы. Тут уже нужно или каждый слой отдельно выводить,  сортируя по глубине, или использовать одну из техник OIT.

Я щас смотрю в сторону такой вот техники:
http://jcgt.org/published/0002/02/09/paper.pdf
Так как сейчас у меня количество дроуколов в движке стремится к 1, то это единственный нормальный способ решить проблему с OIT, причем техника подходит как для прозрачности так и для аддитивного смешивания.

#25
4:44, 1 фев. 2019

Fantom09
> Вообще нигде, ничем и никак не гарантируется (если есть пруф, доказывающий
> обратное - с удовольствием ознакомлюсь).
Вообще то как раз гарантируется. Гарантируется на уровне API:
https://www.khronos.org/opengl/wiki/Rendering_Pipeline_Overview#Rasterization

Primitives that reach this stage are then rasterized in the order in which they were given.

И AMD запилила даже дополнительную педаль, которая позволяет отключить эту гарантию:
https://gpuopen.com/unlock-the-rasterizer-with-out-of-order-rasterization/
чтобы еще поиметь немного профита.
#26
8:04, 1 фев. 2019

Всем спасибо за развернутые ответы, очень много нового узнал.

Пока все-таки склоняюсь к разделению геометрии на несколько буферов.
Теоретически (пока я так вижу), весь мой интерфейс будет соответствовать примерно такому дереву:

-> Игровой экран:
->->Виджет окна:
->->->Виджет (кнопка, чек бокс и т.д.):
->->->BoxContainer
->->->->Виджет:
->->->->BoxContainer
->->->->-> ...

т.е. вроде как виджеты друг друга не перекрывают, кроме возможного перекрытия одного окна другим.
Таким образом можно выделить 3 буфера на одно окно.

1. Геометрия окна;
2. Геометрия виджетов (получим например обходом дерева контейнеров);
3. Геометрия текста на виджетах.

Покритикуйте, пожалуйста, такой подход.

Еще вопрос, если можно:

В предыдущей, очень кривой попытке реализации системы gui, я думал на тем, как поступать с буквами надписи
на кнопках, если размер надписи больше размера кнопки. Я написал алгоритм отсечения лишней геометрии и уменьшения размера букв, которые попали на кнопку наполовину.
Как с этим обстоит дело в других играх?

#27
9:10, 1 фев. 2019

MrShoor
> И AMD запилила даже дополнительную педаль, которая позволяет отключить эту
> гарантию:
Блин, таки да, согласен, пруф железный, я был неправ.
Вот только я ловил глюки при выводе нескольких полигонов с одной глубиной.
Нужно будет как-то потестить, спасибо за ссылку!

#28
(Правка: 9:38) 9:28, 1 фев. 2019

zkolosok
> Как с этим обстоит дело в других играх?
  У меня текст это отдельный элемент GUI, размер кнопки
и размер текста выставляются вручную.
  Прорисовка следующая: Window->Button->Text

#29
12:33, 1 фев. 2019

zkolosok
> Я написал алгоритм отсечения лишней геометрии и уменьшения размера букв,
> которые попали на кнопку наполовину.
> Как с этим обстоит дело в других играх?

Прошу прощения за тупой вопрос. Можно же использовать scissor test

Страницы: 1 2 3 4 5 6 Следующая »
ПрограммированиеФорумГрафика