|
Результаты поиска
| |
| puksus4 | Дата: Понедельник, 04 Мая 2020, 17:41 | Сообщение # 41 | Тема: Помогите с приоритетом отрисовки в SFML |
|
частый гость
Сейчас нет на сайте
| DivES, ну понятно. Но у вас в полноценном масштабе остаётся проблема обработать все объекты в рамках одного слоя) Ваш способ хорошо сработает при виде чисто сбоку, но при изометрии неудобен)
Цитата veeroteen (  ) puksus4, предлагаешь динамику на кадр сортировать?
Ещё раз, собрать массив содержащий все статические объекты в кадре, и все динамические. Один одномерный массив из всех объектов. У вас 200 статических камней и деревьев и 5 динамических персонажей - получите массив из 205 элементов.
Отсортировать его (В целях оптимизации статику можно сортировать заранее и сортировать тока динамику, затем отсортированную динамику сливать с отсортированной статикой так чтоб результат остался отсортирован).
Отрендерить.
Добавлено (04 Мая 2020, 17:42)
---------------------------------------------
Цитата veeroteen ( ) DivES, у тебя 3 координата общая на слой, а puksus4, предлагает делать эту координату на каждый обьект в слое
Неверно, я изначально оперирую объектами, а не слоями. Просто представляйте позицию объекта в его мировых координатах, а не в экранных. И порядок рендера определяйте из мировых. При рендере уже сдвигайте объекты куда вам надо чтоб они выглядели корректно.
Сообщение отредактировал puksus4 - Понедельник, 04 Мая 2020, 17:44 |
|
|
| |
| puksus4 | Дата: Понедельник, 04 Мая 2020, 17:30 | Сообщение # 42 | Тема: Помогите с приоритетом отрисовки в SFML |
|
частый гость
Сейчас нет на сайте
| Учитывая твой последний пост очевидно что ты не понял.
1) Массив одномерный в любом случае, внесение z координаты вообще никоим образом не влияет ни на размерность ни на количество объектов. Да и о какой n-мерности массива может идти речь, когда речь идёт об упорядоченном списке отдаваемых на рендер объектов.
2) Я и говорю про правильную отрисовку статики и динамики вместе.
Перечитай сообщения в теме.
Сообщение отредактировал puksus4 - Понедельник, 04 Мая 2020, 17:32 |
|
|
| |
| puksus4 | Дата: Понедельник, 04 Мая 2020, 17:18 | Сообщение # 43 | Тема: Помогите с приоритетом отрисовки в SFML |
|
частый гость
Сейчас нет на сайте
| Цитата DivES ( ) Это не совсем верная формулировка.
Рендер происходит именно послойно, то есть, если я захочу отрисовать объект перед другим, я изменю его слой (объекты одного слоя отрисовываются в порядке очереди, и ничто не может на неё повлиять).
В таком случае дайте определение понятию слоя в вашем случае, потому что я видимо не понял.Добавлено (04 Мая 2020, 17:19)
---------------------------------------------
Цитата veeroteen ( ) puksus4, при чем тут тормозить, речь о том что не имеет смысла делать такую схему, так как она ничего совершенно не меняет при всей своей громоздкости с 3-й координатой
Эта схема
1) значительно всё упрощает
2) полностью решает вашу проблему.
Что конкретно вам не нравится?
|
|
|
| |
| puksus4 | Дата: Понедельник, 04 Мая 2020, 17:08 | Сообщение # 44 | Тема: Помогите с приоритетом отрисовки в SFML |
|
частый гость
Сейчас нет на сайте
| veeroteen, ну да.
И в чём конкретно вы видите проблему? Засчёт чего конкретно, вы считаете, будет тормозить?Добавлено (04 Мая 2020, 17:11)
---------------------------------------------
Цитата veeroteen ( ) а вот это реально не понятно, у тебя в любом случае чем ниже координаты, тем ниже объект, никакие холмы ничего не изменят, у тебя в любом случае отрисовка идет от менших координат к большим
Неверно, подумайте.
|
|
|
| |
| puksus4 | Дата: Понедельник, 04 Мая 2020, 15:38 | Сообщение # 45 | Тема: Помогите с приоритетом отрисовки в SFML |
|
частый гость
Сейчас нет на сайте
| DivES, z координата хороша тем, что тупо расставляешь объекты, какие угодно, где угодно в мировом пространстве - и вообще не паришься о том, что перед чем должно рисоваться, сортировка всё сделает за вас.
У вас же относительное положение объектов друг от друга по сути захардкожено. А вдруг вы захотите в своей схеме один из объектов слоя 2 отрисовать перед объектом слоя 1, а второй - за? Получается, придётся проворачивать дополнительную магию со слоями, городить костыли.
Понятие слоя больше подойдёт для разделения принципиально разных вещей, которые с другом не связаны, либо гарантированно не перемешиваются. Например, в слое 1 отрисовать GUI, в слое 2 отрисовать главную сцену, в слое 3 отрисовать полупрозрачные объекты, в слое 4 - постэффекты. Или вот так: в слое 1 рисуете автомобильную дорогу, в слое 2 рисуете разметку полос на этой дороге. Также слои хорошо подойдут при виде сбоку для создания параллакса. Дальний фон в один слой, средний фон в другой, ближний в третий, а всё что на экране - в четвёртый.
+ собсно главная проблема как раз и заключается в том, как отрисовать объекты, когда их много. Вы привели вариант, когда у вас 2 объекта, а интересующий сценарий - когда объектов много. Что конкретно будете делать?
+ засчёт одной Y координаты вы не сможите разруливать объекты по физической высоте. Тойсть до тех пор пока у вас земля - одна большая плоскость и все объекты назодятся прямо на ней - всё будет гут. Как только научите персонажа прыгать или введёте "холмы" на карте - всё поедет лесом. Если конечно сейчас речь об изометрии.
Отдельно отвлекусь и скажу о производительности, вам на будущее.
Подобный подход - рисовать объекты по одному в лоб с сортировкой на цпу подойдёт только для простых игр или игр с относительно небольшим количеством объектов.
Будем считать, что вы ограничены сверху 5000 вызовами рендера, потому что при таком банальном подходе вы убиваете всю производительность на передаче рендер команд с цпу на гпу, грубо говоря и видюха и как минимум одно ядро вашего проца будут тупо простаивать впустую без дела в ожидании пока драйвер будет скармливать видюхе команды.
Выход из ситуации - всяческие ухищрения. Например, запечь всю карту в одну текстуру или юзать instancing для рисовки тайлов, для объектов в любом случае делать instancing.
Поэтому скажу, если у вас на экране карта из тайлов и вы рисуете в лоб каждый тайл отдельным вызовом рендера, то либо сделайте тайлы большого размера (чтоб на экране помещалось не более, чем, скажем, 40х40 тайлов), либо используйте более оптимальные (и сложные) методы рендеринга.
Количество объектов тоже старайтесь делать не слишком большим, если нету желания погружаться в низкоуровневые дебри рендеринга.
Сообщение отредактировал puksus4 - Понедельник, 04 Мая 2020, 16:53 |
|
|
| |
| puksus4 | Дата: Понедельник, 04 Мая 2020, 11:23 | Сообщение # 46 | Тема: Помогите с приоритетом отрисовки в SFML |
|
частый гость
Сейчас нет на сайте
| veeroteen, Не понял о чём вы.
Если о тайлах карты как таковой и о сложности её сортировки - представьте что это один объект (и оно так и есть. Это земля, её сортировать не надо, она всегда снизу, всегда рендерится первой. Представьте землю в коде одним объектом и рендерьте внутри как 100х100).
Либо отрисуйте сначала свои 100х100 тайлов земли как есть, а всё что сверху (персонаж, деревья, камни, ...) сортировкой.
Ну и понятно что под "всё что сверху" понимается ввиду то, что попало на экран, а не все объекты на сцене.
Если на карте есть холмы - то каждый уровень по высоте будет отдельным слоем + запихнуть "стены"
Даже если у вас 10000 объектов на экране (что вряд ли) кроме тайлов земли - сортировка вряд ли займёт очень много времени.
Есть виды сортировки которые гарантированно сортируют массив меньше чем за квадрат
В плюсах в стандартной библиотеке даже реализация такой есть std::stable_sort с O(nlog^2n). Если не хочется рисковать попаданием в худший O(n^2) случай обычного квиксорта который в среднем O(nlogn).
Ну а если прям ваще не хочется сортировать - можно получить автоматически правильный порядок отрисовки на уровне пикселей аппаратным ускорением засчёт кастомных шейдеров и включения буфера глубины при рендере. Кастомный шейдер понадобится для альфа теста, иначе в глубину отрендерятся даже прозрачные пиксели спрайтов.
Насколько я помню, в SFML можно писать кастомные шейдера, ибо сам писал 100 лет назад. А раз шейдера можно - значит и рендер стейты типа depthStencilState можно какимто образом настроить
Либо как альтернативный вариант - отсортируйте статику 1 РАЗ.
Затем КАЖДЫЙ КАДР сортируйте всех неписей.
Имея отсортированную заранее статику и отсортированные отдельно неписи, уверен, одно с другим можно быстро слить.
У вас 2 отсортированных массива, заводите 2 указателя и сливаете в отдельный общий массив, беря наименьший элемент из 2-х текущих массивов.
Сложность на кадр O(N + M + MlogM)
где N -статика, M - динамика
кстати, по сути это и есть то что вы сказали - разделить сцену на "до непися" и "после непися"
только обобщением на множество неписей, а не одного
Сообщение отредактировал puksus4 - Понедельник, 04 Мая 2020, 12:08 |
|
|
| |
| puksus4 | Дата: Понедельник, 04 Мая 2020, 03:46 | Сообщение # 47 | Тема: Помогите с приоритетом отрисовки в SFML |
|
частый гость
Сейчас нет на сайте
| Навскидку очевидное решение, обычная проблема приоритета рендера, с sfml не связана.
1) Определяешь для каждого спрайта точку, которой этот объект крепится к земле, у дерева будет низ ствола, посередине корней, вероятно почти у всех объектов это будет точка гдето внизу спрайта.
Для простоты можно взять тупо самую нижнюю точку спрайта по игрику и среднюю по иксу. Но возможно будут странности + будет хрень если в спрайте есть путсые области сбоков.
2) Расставляешь объекты в плоскости допустим xz, где x вправо, z от экрана. За позицию объекта считаешь позицию вышеупомянутой точки в мировом пространстве.
3) перед рендером собираешь пары позиция\реф объекта. Пихаешь сюда всё подряд без разбора, и статику и динамику.
4) сортируешь по убыванию z
5) рендеришь
Короче вводишь понятие глубины из 3д в 2д, где глубиной является позиция объекта по z, что интуитивно понятно.
Бонусный побочный эффект: Допустим у тебя есть холм, на нём дерево. Засчёт того что оно поднято относительно уровня земли, то и на экране его позиция будет выше по Y. Также есть второе дерево, оно не на холме, а сбоку на земле. Если не учитывать холм, будет казаться что дерево 2 перед деревом 1, но это не так. Если всё так же расставлять объекты по xz, сортировать, а при рендере поднимать y координату исходя из высоты объекта над землёй - получишь правильный порядок отрисовки с правильным перекрыванием объектами друг друга. То есть ствол дерева 1 перекроет листву дерева 2, как и должно быть.
Иллюстрация:
https://prnt.sc/saekf3
Сообщение отредактировал puksus4 - Понедельник, 04 Мая 2020, 04:12 |
|
|
| |
| puksus4 | Дата: Суббота, 25 Апреля 2020, 18:04 | Сообщение # 48 | Тема: Игра целиком на видеокарте |
|
частый гость
Сейчас нет на сайте
| Цитата drcrack ( ) зачем переносить на видюху вообще ВСЕ если можно перенести только то, что напрямую мешает перейти от 500 чуваков к 5000
Ну я и говорю - на гпу перетащить обработку отдельных юнитов (объектов), анимации и физику. Собсно в основном то что мешает.
Тойсть те вычисления которых много и которые должны параллиться + те вещи которые напрямую завязаны на объекты чтоб поменьше синхронизации было.
А поиск пути, глобальную логику геймплея, глобальный ИИ (управление отрядами, всякие глобальные события) спускать "сверху". И заставить юниты образовывать группы чтоб уменьшить нагрузку на то, что обрабатывается процессором.Добавлено (25 Апреля 2020, 18:44)
---------------------------------------------
Да, название темы наверн не совсем верное Правильно будет чонибудь типа "частичная обработка игровой логики на ГПУ" или чота типа такого
Сообщение отредактировал puksus4 - Суббота, 25 Апреля 2020, 18:21 |
|
|
| |
| puksus4 | Дата: Суббота, 25 Апреля 2020, 15:26 | Сообщение # 49 | Тема: Игра целиком на видеокарте |
|
частый гость
Сейчас нет на сайте
| В общем, есть вот этот проект, где автор взял и сделал игру целиком на видеокарте
Воть.
Ну и мне в общем-то понравилась идея, и с тех пор интересует, насколько возможно сделать игру типа mount and blade в режиме битвы или total war опять же чисто в режиме битвы, используя в основном видеокарту. Короче игру в которой есть дофига чуваков и они дерутся с применением тактики.
Ведь видюха неиллюзорно шустрее и если вместо ~500 чуваков на поле боя получить ~5000 - прям ваще огонь.
Собсно вот рассуждения на этот счёт, какие проблемы возникнут и как их решать.
1) Поиск пути
Не уверен как именно, но вот тут чуваки похоже умудрились запихнуть алгоритм А* на гпу. Но я уверен что грамотная реализация поиска пути не потребует GPU акселерации.
Ввести обязательное условие что на поле боя юниты ходят только группой, поиск пути для которых выполняется сразу для всех юнитов в группе. Групп может быть небольшое количество, при этом распределить поиск пути равномерно по кадрам. Столкновения же с другими юнитами, обход мелких препятствий и т.д. делать на самой видеокарте с помощью карты потенциальных полей, которую можно сгенерировать без проблем собственно на самой видеокарте. Хранить на ЦПУ карту мира в том или ином виде пригодную для поиска пути, будь то навигационные меши, сетка, чо угодно.
2) ИИ верхнего и среднего уровня
Алгоритмы ИИ анализирующие обстановку в игре с целью принятия тактических решений едва ли видятся возможным реализовать на ГПУ, но на счастье подобные вычисления вовсе не обязательно делать каждый кадр + данных для обсчёта не так много, можно превосходно делать этот обсчёт на ЦПУ, и слать на ГПУ буфера с указаниями что делать конкретным группам. Мораль солдат также обрабатываем тут. Смотрим сколько выживших в группе, сколько рядом союзников, сколько врагов, понижаем или повышаем мораль группы, и если она ниже плинтуса - делаем статус группе "бегство" и заставляем наш поисковик пути выдать путь подальше от поля боя. То есть индивидуальные юниты не бегут, бежит вся группа. Иначе пришлось бы для каждого бегущего солдата создавать отдельную группу, что крайне нежелательно с точки зрения производительности.
3) ИИ низкого уровня.
Если ИИ верхнего (тактика) и среднего уровня (решения группы юнитов) можно считать на цпу, то нижнего (ИИ отдельных болванчиков) уже нет смысла в рамках поставленной задачи т.к. в этом случае данных как раз много и некоторые решения нужно принимать быстро - нет возможности ждать. К тому же ИИ низкого уровня взаимодействует с другими элементами (анимации например), которые также обязаны хранить и обрабатывать на гпу. Допустим мы хотим чтоб юниты в игре вели себя по умному - умели атаковать, блокировать, как в mount and blade.
Во-первых юнит в группе не должен отходить слишком далеко от центра группы + должен подчиняться приказам сверху. Тойсть сначала смотрим какие обобщённые указания прилетели нам с ЦПУ, каков статус группы и учитываем это при обработке юнита.
Во-вторых, нам надо знать, какие вражеские солдаты находятся рядом. Это нужно для ближнего боя - определить цель атаки. Для этого можно юзать Спатиал Хеши (spatial hashes). Зарезервировать скажем, 10000 бакетов, хранение объектов в букетах можно организовать в виде списка, но без динамической памяти, просто на массивах. В самом букете храним первый объект, а в первом объекте идишник следующего. Если затруднительно обсчитать эту структуру прямо на гпу, объём данных не настолько большой (помним - 5000 юнитов на поле боя) чтоб это было критично для синхронизации и обработки на ЦПУ. К тому же это можно делать раз в 2-3 кадра или даже реже. Требуем чтоб объект не мог занимать более одного букета. Для этого вводим максимальный размер юнита и делаем чтоб ячейки нашей сетки перекрывали друг друга.
Таким образом имея эту структуру, для каждого юнита можно посмотреть ближайшие бакеты, выбрать набор из, скажем, 8 самых ближайших\приоритетных вражеских целей около юнита, смотрим что они делают. Если атакуют и мы в зоне поражения - блокируем. Иначе - пытаемся атаковать того кто к нам повёрнут спиной, или не блокирует и т.д. Также совершаем передвижения с целью занять выгодное положение относительно выбранных юнитов. А чтобы каждый кадр юнит не мотался как бешеный между разными целями - регулировать частоту смены решений, ввести пенальти на смену целей.
Для дальнего боя целевая группа противника будет обрабатываться на цпу в рамках ИИ среднего уровня. На гпу мы будем знать позицию группы, которую надо обстрелять. Соответственно смотрим букеты в некотором радиусе от центра группы (или берём рандомный в некотором радиусе в целях ускорения). По тому же принципу определяем конкретную цель обстрела - стреляем.
4) Анимации
Поскольку все объекты хранятся на гпу, и выбирают текущую анимацию на гпу, то и все анимации можно прекрасно хранить на гпу. Все матричные обсчёты костяных анимаций будут на гпу. Это значит, что скелеты болванчиков могут быть серьёзно детализированы. Можно отдельно обрабатывать каждый палец на руке каждого персонажа, просто каеф.
5) Звуки
Звуки на гпу мы воспроизводить не можем. Но мы можем завести буфер со звуковыми командами и аплодить его на цпу. Цпу просмотрит команды и начнёт воспроизведение нужных звуков.
6) Физика
Весь прикол в том, что физику обычно считают на цпу, поскольку результаты обсчёта физики обычно используются в игровой логике, а синхронизация ЦПУ с ГПУ может прибить всю производительность. ОДНАКО физику вполне можно считать на ГПУ. Яркий тому пример - nvidia PhysiX.
Также в репозитории Bullet Physics я видел код для гпу реализации физики. Так и не понял есчесно насколько он рабочий, в интернете инфы не нашёл. Но факт в том что физику можно делать на гпу. А что это значит? Правильно, в нашем случае это значит десятки тысяч объектов с физической симуляцией без просадки фпс.
7) Рендер
Ну, все объекты у нас уже на гпу, обрабатываем (ну там фрустум кулинг, разделение по материалам), собираем список, шлём на цпу, делаем индирект рендер.
8) Игрок
А чо тут делать-то? Считать ввод с клавиатуры, и синхронизировать объект игрока на цпу с объектом игрока на гпу. Нужно только идишник объекта на гпу знать.
9) Сеть
Если есть один игрок - то их может быть и тысяча. Вычисления всех игровых объектов, очевидно должно быть на сервере. Надо будет выдёргивать из гпу позиции объектов, воспроизводимые анимации и их прогресс, слать другим игрокам, принимать от них команды. Вероятно если какието геймплейные фичи влияют на рендер - их тоже надо выдёргивать. Рендер у клиентов локальный. Вообще конкретная реализация сети - отдельная тема и вряд ли сильно усложняется если игра на гпу.
Какие ещё могут возникнуть проблемы и как их можно решать?
Сообщение отредактировал puksus4 - Суббота, 25 Апреля 2020, 15:44 |
|
|
| |
| puksus4 | Дата: Воскресенье, 19 Апреля 2020, 19:06 | Сообщение # 50 | Тема: Bullet Physics: проблема с импульсами быстрых тел |
|
частый гость
Сейчас нет на сайте
| Делаю в общем игру в которой объекты должны попиксельно уничтожаться.
Примерно так как в гифке из этого сообщения
Собсно делаю римейк той игры котору делал на конкурс в 2016 году, только лучше во всех отношениях.
Для детектинга столкновений между объектами заюзал bullet physics.
Соответственно когда столкновение детектится, я повреждаю пиксельную оболочку тела в месте удара.
Соответственно тест - тела движутся навстречу друг другу и сталкиваются (белым обрисована упрощённая конвексная оболочка корабля собсно для столкновений)
screenshot 1
Для оценки масштаба разрушений беру импульс столкновения
screenshot 2
Когда тела движутся навстречу друг другу со скоростью 800 пикселей в секунду, всё нормально - тела повреждаются и отлетают.
Когда повышаю до 1600 - тела всё ещё разлетаются при столкновениях, но не повреждаются.
А не повреждаются потому что bulletPhysics почемуто выдаёт нулевые импульсы при столкновениях. Тойсть переменная impulse из скрина выше нулевая для всех контакт поинтов.
Это кажется странным, потому что по факту тела столкнулись и разлетелись. Но импульс столкновения почемуто нулевой.
Возможно это важно - единицей измерения в bullet считаю пиксель, соотв-но размер тела в длину около 100 пикселей, а относительная скорость движения тел между собой 1600 пикселей.
Bullet physics работает с частотой 60 кадров в секунду, соответственно с такими скоростями тела за кадр проникнут друг в друга максимум на четверть длины тела (1600 * (1.0 \ 60)) = 25. Тойсть Continious Collision Detection по иее в таком случае не нужен.
Добавлено (19 Апреля 2020, 19:19)
---------------------------------------------
Делать пули и снаряды собираюсь отдельно и находить пересечения между корабликами и пулями рей трейсингом, тойсть для пуль проблема неактуальна
+ Допускаю введение искусственного ограничения максимальной скорости движения\вращения корабликов
Но хотелось бы понимать, в каких случаях возникают подобные глюки. Как зависит от размеров, от формы коллизии, от фреймтайма, ... А то ограничу скорость одним значением - настрою геймплей под него, а потом бац - проблема снова проявилась.
Объекты в игре гарантированно будут размера больше определённого. Тойсть если от тела остался маленький ошмёток - он заменится на частицы, и в физической симуляции участвовать не будет. Тойсть очень маленьких тел в игре не будет.Добавлено (19 Апреля 2020, 23:02)
---------------------------------------------
А нет, вру, похожу что буллет детектит коллизию, но ничерта не разлетается, объекты просто пролетают сквозь друг друга.
Это заметно если заставить буллет физикс симулировать с частотой кадров 15 а не 60 и соответственно в 4 раза уменьшить скорость объектов. Они тупо пролетают, коллизии при эжтом детектятся. С меньшими скоростями опять же всё хорошо.
Сообщение отредактировал puksus4 - Воскресенье, 19 Апреля 2020, 19:22 |
|
|
| |
| puksus4 | Дата: Воскресенье, 05 Апреля 2020, 17:44 | Сообщение # 51 | Тема: Сортировка огромного количества частиц на гпу. |
|
частый гость
Сейчас нет на сайте
| drcrack, Спасибо, по поводу OIT годная мысля.
Нашёл тут на хабре статейку как сделать, вроде штука не особо сложная. А если будет слишком прожорливой - можно будет в настройки графики вынести выключалку.
Причём этим же методом по идее можно решить проблему что аддитивные частицы и полупрозрачные полюбасу будут рендерится разными батчами т.к. разный бленд стейт, а значит даже если отсортировать полупрозрачные - они будут глючить поверх аддитивных.
А в случае OIT мы блендим ручками, а значит можно аддитивные и полупрозрачные отрисовать за 1 батч и хранить в буфере фрагментов ещё и тип блендинга - и сблендить корректно.
Сообщение отредактировал puksus4 - Воскресенье, 05 Апреля 2020, 17:57 |
|
|
| |
| puksus4 | Дата: Воскресенье, 05 Апреля 2020, 05:37 | Сообщение # 52 | Тема: Сортировка огромного количества частиц на гпу. |
|
частый гость
Сейчас нет на сайте
| Пишу игру на с++ и DirectX 11, в которой хочу чтоб было много частиц. Набросал тут у себя систему частиц которая живёт полностью на ГПУ, обрабатывается кучей компут шейдеров и рендерится через индирект вызовы.
И тут встал (тойсть ещё не встал, но не может не встать в будущем) вопрос: Порядок отрисовки. В случае аддитивных частиц и частиц с альфа тестом вместо блендинга на порядок рисования глубочайше пофиг. Но проблема будет с полупрозрачными неаддитивными частицами.
Нашёл в интернетах частичное решение - Битоническая сортировка (Bitonic Sort). Суть в том шо берём группы по 2 элемента, сортируем, затем делаем обмен между соответствующими элементами соседних групп так чтобы в первую попал минимальный элемент, а во вторую максимальный. Затем увеличиваем размер группы до 4, делаем то же самое, затем до 8, ... И так за log(N) шагов и общей сложностью N log^2N делаем сортировку.
Сие хозяйство несложно распараллелить чтоб эффективно выполнялось на гпу. НО. Вот допустим у меня максимальное количество частиц - миллион. Я могу написать компут шейдер в котором будет не более 1024 потоков в группе (хардварное ограничение), то есть я смогу лишь частично отсортировать массив, имея в итоге отсортированные порции по 2048 частиц, но сам по себе массив не будет отсортирован.
Вот собсно вопрос, что в этой ситуации лучше сделать? Может быть забить и частично отсортированный массив будет работать достаточно хорошо? может быть можно на гпу отсортировать по другому?
Как бы вы решали эту проблему?
Вопрос не срочный, впадлу пока что вообще сортировку на гпу фигачить.
Пока что планирую рендерить полупрозрачные частицы вообще без сортировки и завести отдельный буфер для частиц с альфа тестом.
Таким образом когда частице достаточно альфа теста - она будет писать в буфер глубины и всё будет ок, возможно с какимто хитрым шейдингом чтоб резких краёв не было, а если частице нужна полупрозрачность - ввести ограничение что полупрозрачные частицы обязаны не иметь в текстуре слишком непрозрачных пикселей. Тогда (надеюсь) артефакты от неправильного порядка отрисовки будут не очень заметными. Тойсть использовать полупрозрачные частицы для действительно полупрозрачной фигни с однородной альфой, типа пыль, дым. Возможно возникнут проблемы когда в один момент времени сначала рендерится частица 1 а затем частица 2, а затем сначала частица 2 а затем частица 1. Тогда можможно дребезжание частиц между собой будет
Кароч тема скорее для обсуждения, чем конкретное ТЗ, возможно есть какието лёгкие обходные пути и костыли
Сообщение отредактировал puksus4 - Воскресенье, 05 Апреля 2020, 05:42 |
|
|
| |
| puksus4 | Дата: Четверг, 20 Февраля 2020, 17:36 | Сообщение # 53 | Тема: ищу напарника чтобы сделать игру |
|
частый гость
Сейчас нет на сайте
| Эргалон, это понятно, я сам на самом деле пишу не полноценный движок, т.к. использую чужие либы. Рендер графики полностью свой с нуля, для гуйни заюзал нуклеар, для звуков опенАЛ, для физики сейчас внедряю буллет физикс. Для скриптов луа с луа бриджом.
почему не юнити? медленный си шарп, почему не анрил? посидел на нем недельку, увидел что нет нормальной поддержки текстурных массивов и компут шейдеров, а значит он медленный на гпуДобавлено (20 Февраля 2020, 17:37)
---------------------------------------------
собсно щас мне буллет физикс не очень нравится т.к. дохрена аллокаций объектов на каждом пуке Добавлено (20 Февраля 2020, 18:03)
---------------------------------------------
Цитата drcrack ( ) все профессионалы закрыли тему прочитав про свой движок на С++
Скажу вам т.к. самому приходится лазить по коду рабочего проекта, я видел наши оптимизации - они очень узконаправленные. Этого невозможно добиться в "общих" движках. Если реализовать такую игру на анриле - производительность встанет колом. Крупные конторы не зря пилят свои движки. Готовые двиги - для мелких и средних игр.
В крупных конторах и спецы покрупнее сидят, которые как раз то и делают что свои двиги. Мой бывший начальник был прогером с опытом работы грёбаных лет 20.
Почему тогда я мелкую пишу на своём?
Просто так субъективно хочу. Я знаю что делаю неэффективно и согласен с этим. Это плохой план если хочешь по быстрому срубить бабла. Ну а ещё, как же достали эти игры от школьников на юнитях и гамаках, сраные 2д-ки, которые не тянет 1080ti. Не хочется быть таким.
|
|
|
| |
| puksus4 | Дата: Четверг, 20 Февраля 2020, 12:31 | Сообщение # 54 | Тема: Мультитекстурирование 3D ландшафта |
|
частый гость
Сейчас нет на сайте
| Цитата drcrack ( ) если ограничить это число 4, то тебе достаточно 2 управляющие текстуры: в первой хранятся 4 индекса (0-255) текстур с наибольшим весом, а во второй собственно их веса
Раз уж зарегался, скажу - текстуру с индексами семплить обычным образом нельзя. Т.к. индексы в отличии от весов не интерполируются корректно (например у пикселя 1 текстуры индекс 1 у пикселя 2 текстуры мндекс 3, в результате мипмапинга получишь усреднённый индекс 2)
Таким образом текстуру надо семплить только первого мип уровня , в результате чего будет кипение на стыках материалов, особенно на дальнем плане
Добавлено (20 Февраля 2020, 12:39)
---------------------------------------------
возможно есть вариант ручками посчитать мип уровни текстуры используя макс фильтр и семплить только целочисленные мипр уровни
Это гемор
Сообщение отредактировал puksus4 - Четверг, 20 Февраля 2020, 12:39 |
|
|
| |
| puksus4 | Дата: Четверг, 20 Февраля 2020, 11:44 | Сообщение # 55 | Тема: ищу напарника чтобы сделать игру |
|
частый гость
Сейчас нет на сайте
| Я тоже прогер, тоже пилю собственный 3д движок на плюсах и директХ 11, тоже принципиально не хочу юзать готовые движки. делал на своём двигле 3д игру, но не допилил, решил что будет слишком проблемно в одиночку пилить 3д контент + долго допиливать сам движок, и ушёл в 2д.
Работаю графическим программистом в конторе Eagle dynamics, моделить и текстурировать не умею, но заинтересован в том чтобы наполовину кодить двигло, наполовину учиться рисовать контент. Т.к. постоянно только кодить и только графику задолбало.
Можно пообщаться, возможно чото выйдет.
Пишите либо на почту pkbulba7@gmail.com либо в вк https://vk.com/beezoya
т.к. ответить сюда мне будет проблематично т.к. меня щас снова забанят.
|
|
|
| |
|
