а вообще в числе физических объектов ирлихта!

спешу «обрадовать», смертельные удары по быстродействию наносит не только большое число нод, но и в равной степени большое число мешбуферов в одной ноде… вот так, т.е. приемлимое быстродействие «храниться» в пределах сотни нод(мешбуферов) иначе имейте под рукой инструмент который сможет пихать в ОДИН мешбуфер и удалять из него вершины и индексы произвольно.

вот так, одну проблему решил – вылазит еще одно и похлеще превой, так ведь и забить на это дело не долго… :( уродсво какое-то


Отзывов: 4 на “IrrLicht: проблема быстродействия не только в числе нод”

  1. Digan ()

    Загрузив большой меш с кучей текстур у меня получилось у одного нода 968 мешбуферов. FPS 50-79. Мне кажется это нормально) Причем я не использовал всякого рода оптимизации. Просто загрузил и отобразил.

  2. Эльмиго ()

    на момент написания статьи я сгенерил поле 128на128 клеток и залил их «дубами»(десяток вершин) – поместил каждую модель в отдельный мешбуфер, поолучилось 9216 заполненных на 0.01% буферов, прицепил их к одной ноде и как думаешь какой был FPS? Правильно! Никакой!

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

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

  3. Digan ()

    Я так понимаю новый мешбуфер создается у нода если предыдущий уже заполнен?

    Вообще на оф. форуме иррлихта находил пример реализации метода Occluson culling, то есть отсечение полигонов которые перекрываются другими. Выигрывалось достаточно много FPS. Жаль ссылка на исходники битая была…

  4. Эльмиго ()

    понимаешь правильно, мешбуферы формируются на этапе загрузки модели и новые добавляются по мере заполнения вершинами последнего добавленного под «пробку», но только буфера создаются не у нода, а у меша


Оставьте свой отзыв

Вы должны войти, чтобы оставлять комментарии.