Комментарии 13
А что с производительностью у такого решения? Особенно когда в области видимости пара тысяч объектов, а в полной сцене — десятки или сотни тысяч?
А что с производительностью у такого решения?
Пока проблем с производительностью не испытывали. Хотя и сотни тысяч объектов в кадр не помещали.
а в полной сцене
В проекте ВТПС, который у нас реализован на OSG (вы, я помню, читали о нем), полная сцена никогда не отрисовывается, рисуется только так её часть, что попадает в пирамиду отсечения. Диспетчеризация отображения объектов выполняется движком из коробки, при применении механизма PagedLOD для загрузки объектов. К тому же имеется механизм LOD, так я склонен оценивать возможности по реализации больших пространств в OSG вполне оптимистично
Пока проблем с производительностью не испытывали. Хотя и сотни тысяч объектов в кадр не помещали.
Ну, про сотни тысяч я говорил не в кадре, а в сцене — понятно, что после отсечения отрисуется гораздо меньше. Просто это отсечение невидимых объектов тоже имеет ненулевую стоимость CPU. При этом описанные коллбэки и визиторы — это отличные ООП паттерны, но в классическом виде они очень плохо дружат с локальностью кэша, и на большом количестве объектов могут занимать ну очень существенное время. Поэтому и заинтересовался.
Кстати число фактических команд на отрисовку легко может вырасти в разы при появлении теней, локальных источников света (если только у вас не deferred shading) и отражающих поверхностей, типа зеркал.
Кстати число фактических команд на отрисовку легко может вырасти в разы при появлении теней, локальных источников света...
Естественно. Пока ничего из перечисленного мной не применялось, но когда будет возможность осветить этот вопрос, я это обязательно сделаю
Если Вам интересны параметры производительности в привязке к геометрии могу дать некоторую статистику
Да, интересная картина.
Хорошее — 500 объектов попадающих на отрисовку отправляются всего за 1 мс — не рекорд, но очень даже неплохо. State sorting в OSG все-таки работает, и возможно даже есть какой-то автоматический инстансинг.
Плохое — culling занимает 10 мс, иногда поднимается до 15. Это ОЧЕНЬ много, движок работает на грани, после которой начнутся тормоза, причем боттлнеком будет процессор, а не видеокарта. Вангую, что при необходимости усложнять сцену в лучшем случае вам придется либо пересматривать структуру своего scene graph, в худшем — смириться с архитектурными особенностями OSG, и отказаться от усложнения сцены.
Забавное — GPU тратит на кадр всего 2 мс. Это параллельно с CPU, который суммарно получается 12 мс и выше. Т.е. каждый кадр 10 мс видеокарта простаивает, и если даже вы увеличите площадь экрана или сложность шейдеров раз в 5 на итоговый FPS это не повлияет никак. В связи с этим очень рекомендую попробовать включить 8x MSAA — картнка должна стать намного более гладкой, без влияния на общую производительность. Более того, при этом можно попробовать перевести деревья на alpha to coverage и отключить для них сортировку по глубине — потенциально это может сэкономить прилично CPU, что в итоге скорее всего еще и поднимет FPS.
Хорошее — 500 объектов попадающих на отрисовку отправляются всего за 1 мс — не рекорд, но очень даже неплохо. State sorting в OSG все-таки работает, и возможно даже есть какой-то автоматический инстансинг.
Плохое — culling занимает 10 мс, иногда поднимается до 15. Это ОЧЕНЬ много, движок работает на грани, после которой начнутся тормоза, причем боттлнеком будет процессор, а не видеокарта. Вангую, что при необходимости усложнять сцену в лучшем случае вам придется либо пересматривать структуру своего scene graph, в худшем — смириться с архитектурными особенностями OSG, и отказаться от усложнения сцены.
Забавное — GPU тратит на кадр всего 2 мс. Это параллельно с CPU, который суммарно получается 12 мс и выше. Т.е. каждый кадр 10 мс видеокарта простаивает, и если даже вы увеличите площадь экрана или сложность шейдеров раз в 5 на итоговый FPS это не повлияет никак. В связи с этим очень рекомендую попробовать включить 8x MSAA — картнка должна стать намного более гладкой, без влияния на общую производительность. Более того, при этом можно попробовать перевести деревья на alpha to coverage и отключить для них сортировку по глубине — потенциально это может сэкономить прилично CPU, что в итоге скорее всего еще и поднимет FPS.
Хорошее — 500 объектов попадающих на отрисовку отправляются всего за 1 мс — не рекорд, но очень даже неплохо.
Вангую, что там неправильно считается эта одна миллисекунда. Ботлнек явно CPU (ибо gpu тратит всего 2мс на фрейм, и при таком «графоние» я верю, что там больше 2мс делать нечего). Так вот, куллинг 11мс + 1мс на дравколлы. При этом FPS в районе 50. А 50 кадров в секунду — это 20мс на кадр. Внимание вопрос: «Где еще 8 миллисекунд?»
Почему я грешу на измерение draw? Потому что GAPI асинхронный, и стоимость вызова draw может сместится в сторону SwapBuffers, т.к. на момент вызова draw мы только сабмитим данные. Реальный же draw произойдет позже.
upd. Хотя я посмотрел тут на график выше, и вряд ли draw был перенесен на SwapBuffers. Но вот 8 миллисекунд все таки потерялись:
Непосредственно перед Draw и после Draw. Примерно по 4мс с каждой стороны.
Да, потерявшиеся 8 мс меня тоже смутили, но подозреваю, что это может быть код, не связанный с графикой напрямую — видео вроде ведь не с графического движка в вакууме.
Плохое — culling занимает 10 мс, иногда поднимается до 15
Это связано с тем, что маршруты от ZDSimulator, используемые на ми на данный момент используют совершенно идиотский формат моделей движка DGLEngine. Эти модели (*.dmd) не содержат пути к текстуре, соотвественно при использовании механизма PagedLOD для фоновой загрузки моделей у плагина загрузки этих моделей нет информации о том, где брать текстуру. Приходится грузить её «на лету» в тот момент когда модель становится видима, для чего на каждой модели висит callback, срабатывающий на cull-проходе графа сцены.
В будущем мы плюнем на этот дурацкий формат и перейдем на родной *.osg
del
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
OpenSceneGraph: Основные приемы программирования