|
Фреймворк voxplanet и игра Suber
|
|
| Adriana | Дата: Среда, 17.10.2012, 13:28 | Сообщение # 31 |
 Сержант
Группа: Пользователи
Сообщений: 21
Награды: 1
Репутация: 4
Статус: Offline
| RBC рушит программу, когда вызывается из асинхронного таска, а вызывать из основной нити программы слишком накладно, камера двигается рывками. Добавлено (17.10.2012, 13:28)
---------------------------------------------
Вообще, кстати, эта ошибка мне уже все нервы съела:
Code python: built/include/mutexPosixImpl.I:42: MutexPosixImpl::~MutexPosixImpl(): Проверочное утверждение «result == 0» не выполнено.
Аварийный останов (core dumped)
|
| |
| |
| ninth | Дата: Среда, 17.10.2012, 16:59 | Сообщение # 32 |
 Admin
Группа: Администраторы
Сообщений: 1582
Награды: 5
Репутация: 46
Статус: Offline
| 1. Попробуй сначала собирать RBC, а потом уже репарентить его в рендер.
2 .Так RBC, если не обращать внимания на время сборки, решает проблему или нет? Судя по скринам, деревья у тебя сгенеренные, может проще генератор допилить, чтобы он собирал не одно дерево, а сразу пачку в единую геометрию?
|
| |
| |
| Adriana | Дата: Понедельник, 22.10.2012, 13:26 | Сообщение # 33 |
|
Сержант
Группа: Пользователи
Сообщений: 21
Награды: 1
Репутация: 4
Статус: Offline
| В общем, я заменил деревья, полностью изменил методику их вставки и, кажется, проблему с деревьями решил.
Вкратце:
1. Деревья квадратные как в майнкрафте
2. Генерируются заранее 100 различных моделей
3. Эти модели используются для установки на сцену методом copyTo()
4. 10 деревьев инстанцируются в одну ноду, для которой делается flattenStrong(), с установленной задержкой 100мс, для того чтобы не было явных подергиваний при движении по миру (некоторое замедление движения все равно остается)
5. Все ноды с деревьями инстанцируются в большую ноду, для которой также делается flattenStrong()
6. Большая нода инстанцируется в ноду леса.
7. Используется временная нода, для того чтобы скрыть процесс перестройки деревьев.
Профит: генерируется один объект, который включает в себя все деревья, что делает фпс не ниже 100.
https://github.com/viatori....py#L142 код метода
|
| |
| |
| ninth | Дата: Вторник, 23.10.2012, 08:05 | Сообщение # 34 |
|
Admin
Группа: Администраторы
Сообщений: 1582
Награды: 5
Репутация: 46
Статус: Offline
| Другие виды флаттенов не пробовал? Иногда бывает, что результат по фпс не сильно отличается, зато скорость отработки на медиум и лайт - выше.
|
| |
| |
| Adriana | Дата: Пятница, 26.10.2012, 13:49 | Сообщение # 35 |
|
Сержант
Группа: Пользователи
Сообщений: 21
Награды: 1
Репутация: 4
Статус: Offline
| Коллизии резко снижают фпс. Использую луч из камеры.
Профиль таска, отвечающего за камеру
Code 20 function calls in 0.020 seconds
Ordered by: internal time
ncalls tottime percall cumtime percall filename:lineno(function)
1 0.020 0.020 0.020 0.020 {method 'traverse' of 'libpanda.CollisionTraverser' objects}
1 0.000 0.000 0.020 0.020 interactive.py:239(mouseUpdate)
1 0.000 0.000 0.000 0.000 {method 'sortEntries' of 'libpanda.CollisionHandlerQueue' objects}
1 0.000 0.000 0.000 0.000 {method 'setFromLens' of 'libpanda.CollisionRay' objects}
1 0.000 0.000 0.000 0.000 {method 'findNetTag' of 'libpanda.NodePath' objects}
1 0.000 0.000 0.000 0.000 {method 'getEntry' of 'libpanda.CollisionHandlerQueue' objects}
1 0.000 0.000 0.000 0.000 {method 'getNumEntries' of 'libpanda.CollisionHandlerQueue' objects}
1 0.000 0.000 0.000 0.000 {method 'getPointer' of 'libpanda.GraphicsWindow' objects}
1 0.000 0.000 0.000 0.000 {method 'getIntoNodePath' of 'libpanda.CollisionEntry' objects}
1 0.000 0.000 0.000 0.000 {method 'movePointer' of 'libpanda.GraphicsWindow' objects}
1 0.000 0.000 0.000 0.000 {method 'getX' of 'libpanda.MouseData' objects}
1 0.000 0.000 0.000 0.000 {method 'getXSize' of 'libpanda.GraphicsOutput' objects}
1 0.000 0.000 0.000 0.000 {method 'isEmpty' of 'libpanda.NodePath' objects}
1 0.000 0.000 0.000 0.000 {method 'getYSize' of 'libpanda.GraphicsOutput' objects}
1 0.000 0.000 0.000 0.000 {method 'getX' of 'libpanda.LVecBase2f' objects}
1 0.000 0.000 0.000 0.000 {method 'getMouse' of 'libpanda.MouseWatcher' objects}
1 0.000 0.000 0.000 0.000 {method 'hasMouse' of 'libpanda.MouseWatcher' objects}
1 0.000 0.000 0.000 0.000 {method 'disable' of '_lsprof.Profiler' objects}
1 0.000 0.000 0.000 0.000 {method 'getY' of 'libpanda.LVecBase2f' objects}
1 0.000 0.000 0.000 0.000 {method 'getY' of 'libpanda.MouseData' objects}
Сам по себе практически не отнимает время.
Тем не менее что-то сильно грузит программу, куда покопать?
Сообщение отредактировал Adriana - Пятница, 26.10.2012, 13:50 |
| |
| |
| ninth | Дата: Пятница, 26.10.2012, 14:52 | Сообщение # 36 |
|
Admin
Группа: Администраторы
Сообщений: 1582
Награды: 5
Репутация: 46
Статус: Offline
| Их тоже оптимизировать нужно ) Я так понимаю, ты лепил коллизии сразу на видимую геометрию? Вместо определения коллизии с "землёй", вероятно намного быстрее будет считать просто высоту по тому же принципу, по которому ты считал высоту для построения "земли". Так же посмотри в сторону "октрификации" http://www.panda3d.org/forums/viewtopic.php?t=12947
Вообще обычная практика при создании коллизий - делать под них отдельную геометрию достаточно сильно упрощённую. Если присмотришься - даже в самых современных играх с наикрутейшей физикой и т.п. применён данный подход.
|
| |
| |
| Adriana | Дата: Пятница, 26.10.2012, 23:27 | Сообщение # 37 |
|
Сержант
Группа: Пользователи
Сообщений: 21
Награды: 1
Репутация: 4
Статус: Offline
| С коллизиями я разобрался, у меня видимая геометрия итак упрощенная, земля из квадратов по два полигона. Собственно тормозит когда луч проходит через много полигонов, так что когда я тестировал этот самый луч, не учел этого. Когда луч смотрит строго вниз от модели, то ничего не тормозит.
В общем я подошел к другой проблеме, персонаж бегает рывками, даже с использованием globalClock.getDt(). Так как в фоне постоянно идут вычисления новых чанков, новых деревьев. Какой есть способ сделать так, чтобы персонаж всегда бежал с одинаковой скоростью, не обращая внимания на расчеты в фоне?Добавлено (26.10.2012, 23:27)
---------------------------------------------
Собственно кажется и эту проблему решил, хитрыми манипуляциями с потоками, приоретатми и задержками. Видео: http://youtu.be/dCsFaj7MXFI
|
| |
| |
| ninth | Дата: Суббота, 27.10.2012, 13:01 | Сообщение # 38 |
|
Admin
Группа: Администраторы
Сообщений: 1582
Награды: 5
Репутация: 46
Статус: Offline
| Гратс ) Успехи налицо )
Вот ещё идея для оптимизации - вместо большой дистанции видимости попробовать периодически делать рендер окружающего пространства, потом его скрывать, а получившееся накладывать на скайбокс. Но поскольку сам я так не пытался делать - то это только теоретическое предположение.
Ещё одно - возможно стоит поиграться с балансом (количество полигонов в кадре)/(количество перерасчётов), т.е. баланс GPU/CPU
По поводу упрощения - я имел ввиду установка вместо допустим десятка полигонов - одного аппроксимированного для коллизий.
з.ы. Может тему в WiP перенести?
|
| |
| |
| Adriana | Дата: Суббота, 27.10.2012, 16:03 | Сообщение # 39 |
|
Сержант
Группа: Пользователи
Сообщений: 21
Награды: 1
Репутация: 4
Статус: Offline
| Quote (ninth) Может тему в WiP перенести?
Вы тут администратор, вам виднее, я не против, если что.
Со скайбоксом идея интересная, возьму на заметку.
GPU практически никак не нагружен, а вот на CPU идет нагрузка не слабая, так что приходится в основном эту нагрузку и снижать. Приоритеты и задержки между микрооперациями помогают пока.
|
| |
| |
| ninth | Дата: Воскресенье, 28.10.2012, 19:41 | Сообщение # 40 |
|
Admin
Группа: Администраторы
Сообщений: 1582
Награды: 5
Репутация: 46
Статус: Offline
| Тему перенёс.
|
| |
| |
