Для открытых пространств, тоже можно PVS - дерево использовать.
А так у меня есть алгоритм Shadow clipping, который и будет убирать всю лишнюю перекрываемую геометрию. Т.е. площадь отрисовки всегда будет не больше размеров ViewPort’а. По сути таким образом обходя ограничение “flash fillRate’a”. В детали работы этого алгоритма вдаваться пока не буду, как включу его в интернет версию, так и расскажу.
На примере (грубый пример, но думаю результат работы будет ясен) это можно показать так:
1) представим что у нас размеры ViewPort’a 800х600;
2) допустим что мы рисуем в него 4 плоскости с размерами на весь ViewPort (800х600), т.е. площадь отрисовки равна 4*(800х600) = 1600х1200;
3) при работе этого алгоритма площадь отрисовки останется равной размерам ViewPort’a.
Да, не новый, есть еще вариант с тайлотовым Z буфером, но пока он скорость ниже показывает, чем Shadow clipping. Посмотрю на итоги полной доводки до ума этих алгоритмов и введу тот, который по тестам будет лучше.
А что тут новое придумаешь? Есть задача уменьшить площадь отрисовки путем полного удаления невидимой геометрии и перекрываемой. А делаться это будем как не крути путем обрезки полигонов (как при clipping’е и BSP - дереве). Без аппаратной поддержки и встроенных алгоритмах в ней, путей не много. Может в процессе и что-то придет в голову. Я открыт к предложениям, предположениям по поводу реализации этой задачи.
Интересно а можно посмотреть на “не интернет” версию?
“Не интернет” версия, имеет крайне трудное управление в ней проводятся эксперименты и тесты новых алгоритмов и т.д. А после доводки до ума, добавляются в “почти интернет” версию. “Почти интернет”, в ней уже отлаженные алгоритмы, материалы, загрузчики, полигональные объекты и т.д., я их ввожу постепенно в интернет версию. Просто если сразу все ввести, очень трудно будет отследить и исправлять баги, найденные разработчиками. А так в каждой версии добавляю несколько возможностей и если у разработчиков не возникает проблем, готовлю следующую версию.
Да сложная эта задача… Тут надо найти подобное решение как и в “комнатах”. Была у меня где то ссылка познавательная щаз поищу… http://cgm.computergraphics.ru/content/view/52
Там обзор интересных алгоритмов. Shadow Frusta называется там ))
Там правильно называется алгоритм, я назвал его немного по-другому, т.к. и работает он немного по-другому, да и просто более понятно из моего названия, что он делает (проводит обрезку).
Из списка алгоритмов, по этой ссылке, для flash подходят только Cells-and-Portals и Shadow Frusta, а Hierarchical Z-buffer никак нормально не пристроить, т.к. требует аппаратную поддержку (z-readback ).
Cells-and-Portals, подходят преимущественно для закрытых пространств.
>>Понятно… Это старый алгоритм Shadow clipping. Вот бы что то новое придумать. Интересно а можно посмотреть на “не интернет” версию?
Lol, Роман, вы эти комментарии сами пишете что-ли? За пять лет, что занимаюсь 3D графикой не слышал о таком алгоритме, может быть это одна из ваших ноу-хау?
отлично, за таким устрашающим названием как видим скрывается такая простая концепция )
вот вопрос: по какому именно параметру движок определяет какая комната является текущей? просто я подумал что если она определяет по полу (т.е. по z), то можно было бы делать более тонкую настройку, например в комнате 14 - с верхней части этой комнаты также видна и 11-я комната немножко, а с нижней - только 13-я, соответсвенно разделить пол 14-й на две части. Причем и 11-ю комнату можно было бы разрубить надвое, и 14-й дать видеть только верхнюю половину 11-й. Таким же образом можно было бы настроить и все остальное, ведь помимо самих голых комнат в них могут (и будут) находится некоторые статические (недвижимые) предметы, и этот мой подход сможет существенно сэкономить CPU, не так ли?
вот вопрос: по какому именно параметру движок определяет какая комната является текущей? просто я подумал что если она определяет по полу (т.е. по z)
Движок не использует какую любо ось для определения позиции. Он проверяет принадлежность ограничивающего эллипса камеры ограничивающиму параллелепипеду комнаты. В версиях до 1.3 включительно проверка принадлежности камеры (позиции камеры) была в проверки на столкновения. Но оказалось, что это не удобно, т.к. без проверок на столкновения нельзя использовать PVS дерево. В 1.4 проверка принадлежности камеры перенесена в рендер фильтры.
например в комнате 14 - с верхней части этой комнаты также видна и 11-я комната немножко, а с нижней - только 13-я, соответсвенно разделить пол 14-й на две части. Причем и 11-ю комнату можно было бы разрубить надвое, и 14-й дать видеть только верхнюю половину 11-й. Таким же образом можно было бы настроить и все остальное, ведь помимо самих голых комнат в них могут (и будут) находится некоторые статические (недвижимые) предметы, и этот мой подход сможет существенно сэкономить CPU, не так ли?
Да такой подход можно реализовать PVS - дерево позволяет делать более глубокое разбиение комнат для еще большей оптимизации скорости.
Кстати PVS не надо настраивать для всех объектов на сцене, достаточно настроить PVS для корневых объектов (в примере комнат).
Например:
1) у нас есть 3 комнаты и мы их добавляем на сцену;
2) настраиваем PVS для этих комнат;
3) теперь помещаем в эти комнаты другие объекты стулья, столы и т.д. (в роли детей):
4) когда движок обходит PVS - дерево он смотрит какая(ие) комнаты видны и выводит их и их детей.
Но можно заполнять PVS и всеми объектами, тогда мы добавляем другие объекты стулья, столы и т.д. не как детей комнат, а просто на сцену. Что позволить сделать более глубокое дерево с максимальной эффективностью использования, но такое дерево труднее построить (думаю это того стоит).
Да познавательный пример. А как на счет открытых пространств? Есть идеи?
Для открытых пространств, тоже можно PVS - дерево использовать.
А так у меня есть алгоритм Shadow clipping, который и будет убирать всю лишнюю перекрываемую геометрию. Т.е. площадь отрисовки всегда будет не больше размеров ViewPort’а. По сути таким образом обходя ограничение “flash fillRate’a”. В детали работы этого алгоритма вдаваться пока не буду, как включу его в интернет версию, так и расскажу.
На примере (грубый пример, но думаю результат работы будет ясен) это можно показать так:
1) представим что у нас размеры ViewPort’a 800х600;
2) допустим что мы рисуем в него 4 плоскости с размерами на весь ViewPort (800х600), т.е. площадь отрисовки равна 4*(800х600) = 1600х1200;
3) при работе этого алгоритма площадь отрисовки останется равной размерам ViewPort’a.
Понятно… Это старый алгоритм Shadow clipping. Вот бы что то новое придумать. Интересно а можно посмотреть на “не интернет” версию?
Да, не новый, есть еще вариант с тайлотовым Z буфером, но пока он скорость ниже показывает, чем Shadow clipping. Посмотрю на итоги полной доводки до ума этих алгоритмов и введу тот, который по тестам будет лучше.
А что тут новое придумаешь? Есть задача уменьшить площадь отрисовки путем полного удаления невидимой геометрии и перекрываемой. А делаться это будем как не крути путем обрезки полигонов (как при clipping’е и BSP - дереве). Без аппаратной поддержки и встроенных алгоритмах в ней, путей не много. Может в процессе и что-то придет в голову. Я открыт к предложениям, предположениям по поводу реализации этой задачи.
“Не интернет” версия, имеет крайне трудное управление в ней проводятся эксперименты и тесты новых алгоритмов и т.д. А после доводки до ума, добавляются в “почти интернет” версию. “Почти интернет”, в ней уже отлаженные алгоритмы, материалы, загрузчики, полигональные объекты и т.д., я их ввожу постепенно в интернет версию. Просто если сразу все ввести, очень трудно будет отследить и исправлять баги, найденные разработчиками. А так в каждой версии добавляю несколько возможностей и если у разработчиков не возникает проблем, готовлю следующую версию.
Да сложная эта задача… Тут надо найти подобное решение как и в “комнатах”. Была у меня где то ссылка познавательная щаз поищу…
http://cgm.computergraphics.ru/content/view/52
Там обзор интересных алгоритмов. Shadow Frusta называется там ))
Уже читал эту статью.
Там правильно называется алгоритм, я назвал его немного по-другому, т.к. и работает он немного по-другому, да и просто более понятно из моего названия, что он делает (проводит обрезку).
Из списка алгоритмов, по этой ссылке, для flash подходят только Cells-and-Portals и Shadow Frusta, а Hierarchical Z-buffer никак нормально не пристроить, т.к. требует аппаратную поддержку (z-readback ).
Cells-and-Portals, подходят преимущественно для закрытых пространств.
Да вы правы.
>>Понятно… Это старый алгоритм Shadow clipping. Вот бы что то новое придумать. Интересно а можно посмотреть на “не интернет” версию?
Lol, Роман, вы эти комментарии сами пишете что-ли? За пять лет, что занимаюсь 3D графикой не слышал о таком алгоритме, может быть это одна из ваших ноу-хау?
Яски, видимо 5 лет прошли впустую и бесцельно. Best кинул ссылку http://cgm.computergraphics.ru/content/view/52, также можете поискать в интернете, что это такое.
Вот пару ссылок для общего развития:
1) http://130.203.133.121:8080/viewdoc/summary?doi=10.1.1.45.1649
2) http://blog.csdn.net/c30gcrk/archive/2008/11/11/3276090.aspx
3) http://www.gamedev.net/reference/articles/article2330.asp
4) http://www.gamedev.net/columns/hardcore/shadowcast
отлично, за таким устрашающим названием как видим скрывается такая простая концепция )
вот вопрос: по какому именно параметру движок определяет какая комната является текущей? просто я подумал что если она определяет по полу (т.е. по z), то можно было бы делать более тонкую настройку, например в комнате 14 - с верхней части этой комнаты также видна и 11-я комната немножко, а с нижней - только 13-я, соответсвенно разделить пол 14-й на две части. Причем и 11-ю комнату можно было бы разрубить надвое, и 14-й дать видеть только верхнюю половину 11-й. Таким же образом можно было бы настроить и все остальное, ведь помимо самих голых комнат в них могут (и будут) находится некоторые статические (недвижимые) предметы, и этот мой подход сможет существенно сэкономить CPU, не так ли?
Движок не использует какую любо ось для определения позиции. Он проверяет принадлежность ограничивающего эллипса камеры ограничивающиму параллелепипеду комнаты. В версиях до 1.3 включительно проверка принадлежности камеры (позиции камеры) была в проверки на столкновения. Но оказалось, что это не удобно, т.к. без проверок на столкновения нельзя использовать PVS дерево. В 1.4 проверка принадлежности камеры перенесена в рендер фильтры.
Да такой подход можно реализовать PVS - дерево позволяет делать более глубокое разбиение комнат для еще большей оптимизации скорости.
Кстати PVS не надо настраивать для всех объектов на сцене, достаточно настроить PVS для корневых объектов (в примере комнат).
Например:
1) у нас есть 3 комнаты и мы их добавляем на сцену;
2) настраиваем PVS для этих комнат;
3) теперь помещаем в эти комнаты другие объекты стулья, столы и т.д. (в роли детей):
4) когда движок обходит PVS - дерево он смотрит какая(ие) комнаты видны и выводит их и их детей.
Но можно заполнять PVS и всеми объектами, тогда мы добавляем другие объекты стулья, столы и т.д. не как детей комнат, а просто на сцену. Что позволить сделать более глубокое дерево с максимальной эффективностью использования, но такое дерево труднее построить (думаю это того стоит).
Мне такое не попадается