Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Минимизация обрабатываемых полигонов в DirectX 01.11.08 08:59
Автор: Vedrus <Serokhvostov Anton> Статус: Member
|
Есть большая сцена с кучей дочерних объектов, например, земельный участок и дома на этом участке. Можно ли как-то игнорировать те объекты, которые находятся за пределами видимости и не нагружать видеокарту их прорисовкой?
Вообще интересуют вопросы создания оптимального 3D-движка. Те книги, которые нашёл, меня не удовлетворили, там оптимальности, в смысле быстродействия, уделяется далеко не первое значение.
Пролистал такие:
Грег Снук. 3D ландшафты в DirectX;
Франк Луна – Введение в программирование трёхмерных игр.
и др.
Английским, к сожалению, владею не достаточно хорошо, чтобы можно было читать книги на нём. Посоветуйте пожалуйста, книги, ссылки или свои мысли.
|
|
Всем спасибо, тема закрыта. 04.11.08 02:21
Автор: Vedrus <Serokhvostov Anton> Статус: Member
|
|
|
|
Сужаю вопрос. 03.11.08 03:02
Автор: Vedrus <Serokhvostov Anton> Статус: Member
Отредактировано 03.11.08 03:05 Количество правок: 1
|
Сужаю вопрос.
Я хочу сделать 3D-визуализатор, который будет осуществлять минимум избыточных действий, таких как обработка невидимых граней, обработка невидимых объектов и обработка частей объектов, закрытых другими объектами. Особо интересует следующий вопрос: можно ли до передачи сцены в видо карту исключить из обработки невидимые грани?
Есть ли какой-нибудь математический аппарат, позволяющий добиться этого? Пока я додумался до следующего. Разбить всю сцену на вложенные друг в друга кубические сектора и явно прописать какие из них видны из каждого сектора в заданном диапазоне углов просмотра.
Это существенно увеличит объём занимаемого дискового пространства, но, как мне кажется, увеличит скорость визуализации. Может кто-нибудь здесь увидит подводные камни, которые пока не вижу я?
|
| |
Индексация spatial-данных 03.11.08 07:44
Автор: amirul <Serge> Статус: The Elderman
|
http://en.wikipedia.org/wiki/Spatial_index
В частности http://en.wikipedia.org/wiki/R-tree
> Сужаю вопрос.
> Я хочу сделать 3D-визуализатор, который будет осуществлять
> минимум избыточных действий, таких как обработка невидимых
> граней, обработка невидимых объектов и обработка частей
> объектов, закрытых другими объектами. Особо интересует
Это лучше всего решается Z-Buffer-ом.
> следующий вопрос: можно ли до передачи сцены в видо карту
> исключить из обработки невидимые грани?
Зачем? Сколько там у современных видеокарт ядер? 256? Да еще заточенных с охрененной скоростью перелопачивать свои шейдерные команды? ВОТ И ПУСКАЙ КАЖДЫЙ ЗАНИМАЕТСЯ СВОЕЙ РАБОТОЙ. Если ты вынесешь существенную часть этой работы из GPU в CPU, это все будет безбожно тормозить.
> Есть ли какой-нибудь математический аппарат, позволяющий
> добиться этого? Пока я додумался до следующего. Разбить всю
Тут не математика скорее нужна, а структуры данных. Вот R-Tree самое то, чтобы провести первичную фильтрацию. Всем остальным должна заниматься видеокарта.
> сцену на вложенные друг в друга кубические сектора и явно
> прописать какие из них видны из каждого сектора в заданном
> диапазоне углов просмотра.
Никаких углов просмотра, ты чего.
> Это существенно увеличит объём занимаемого дискового
> пространства, но, как мне кажется, увеличит скорость
> визуализации. Может кто-нибудь здесь увидит подводные
> камни, которые пока не вижу я?
Я не знаю, какую задачу ты решаешь, но мне кажется ты идешь в неправильном направлении. Ты современные игры видел? Видеокарты - это такие СПЕЦИАЛИЗИРОВАННЫЕ устройства, разработанные, чтобы эффективно справляться с работой, которую ты сейчас пытаешься переложить на CPU.
|
| | |
Я обдумываю программу с 3D интерфейсом, которая могла бы... 03.11.08 08:30
Автор: Vedrus <Serokhvostov Anton> Статус: Member
Отредактировано 03.11.08 08:39 Количество правок: 3
|
Я обдумываю программу с 3D интерфейсом, которая могла бы работать на допотопных компьютерах.
Действительно, получается я перекладываю работу GPU на CPU. Может ли это дать положительный результат, если я установлю правильный балланс в загрузке GPL и CPU?
К примеру, если в компе стаит Riva TNT2 m64 32mb и Athlon 900Mhz, то будет ли эффективным в этом случае часть работы GPU переадресовать к CPU?
PS. Можешь в двух словах сказать, что такое spatial, а то я с английским не очень в ладах? А ещё лучше ссылку на русском...
PSS. Про R-деревья почитал, но так и не понял, чем они лучше обычных деревьев? Только тем, что задают ограничивающие области?
|
| | | |
А стоит ли? Это твое собственное пожелание или анализ рынка... 03.11.08 10:42
Автор: amirul <Serge> Статус: The Elderman
|
> Я обдумываю программу с 3D интерфейсом, которая могла бы
> работать на допотопных компьютерах.
А стоит ли? Это твое собственное пожелание или анализ рынка дал такое требование?
> Действительно, получается я перекладываю работу GPU на CPU.
> Может ли это дать положительный результат, если я установлю
> правильный балланс в загрузке GPL и CPU?
Естественно если ты установишь правильный баланс, то все будет зашибись, но вот по моему скромному мнению ты движешься в сторону, противоположную правильной.
> К примеру, если в компе стаит Riva TNT2 m64 32mb и Athlon
> 900Mhz, то будет ли эффективным в этом случае часть работы
> GPU переадресовать к CPU?
А ХЗ. На самом деле я не настоящий сварщик - геймдевом на занимался вообще, но общее ощущение неправильности подхода все равно не покидает.
> PS. Можешь в двух словах сказать, что такое spatial, а то я
> с английским не очень в ладах? А ещё лучше ссылку на
> русском...
http://www.abbyyonline.ru/Translate.aspx?words=spatial&Ln=1&B1=%D0%9F%D0%B5%D1%80%D0%B5%D0%B2%D0%BE%D0%B4
Spatial - пространственный.
Собственно spatial index - пространственный индекс. Структуры данных, предназначенные для быстрого поиска в двух-, трех- и более-мерных пространствах. По аналогии с индексами в базах данных (которые можно считать индексами в одномерном пространстве ключей), которые ускоряют определенные виды поиска (разные виды индексов ускоряют разные виды поиска), пространственные индексы помогают быстро искать объекты в пространстве (вон в том же гугльмапс search nearby можно ограничить насколько nearby надо искать - работа как раз таки двумерного пространственного индекса).
> PSS. Про R-деревья почитал, но так и не понял, чем они
> лучше обычных деревьев? Только тем, что задают
> ограничивающие области?
Обычные это какие? B-деревья поиска. Ну дык B-деревья ищут по одному ключу, то есть в одномерном пространстве, а R-деревья ищут в пространствах с количеством измерений больше 1. В общем с помощью этого дерева ты можешь сделать запрос типа "А подай сюда все объекты, с расстоянием не больше L от данной точки". Ну а потом с чистой совестью запихать это все в видеокарту - пускай разгребает
|
| | | | |
Как обычно, собственное пожелание )) 03.11.08 12:20
Автор: Vedrus <Serokhvostov Anton> Статус: Member
|
Как обычно, собственное пожелание ))
Спасибо за ответы. Т.е., твоя интуиция говорит, что лучше видюхе полностью сцену скармливать и не заморачиваться?
|
| | | | | |
Ага 03.11.08 20:41
Автор: amirul <Serge> Статус: The Elderman
|
> Как обычно, собственное пожелание ))
Ну ты тот же quake3, халву первую или nfs5 помнишь? Летало на машинах 10-летней давности. На еще более древних вообще не стоит обращать внимания (на 10-тилетние по большому счету тоже, но раз хочется :-) ). Если ты не ожидаешь, что твой интерфейс будет значительно сложнее, чем сцены в этих играх - просто используй best practices из геймдева и не морочь себе голову.
> Спасибо за ответы. Т.е., твоя интуиция говорит, что лучше
> видюхе полностью сцену скармливать и не заморачиваться?
Ну в общем да. Интуиция говорит, что не стоит изобретать велосипедов: как геймдевы делают, так и сделать.
|
| | | | | | |
я так понимаю, сейчас уже не стоит закладываться на что-то меньшее нетбуков 04.11.08 01:20
Автор: dl <Dmitry Leonov>
|
|
eeePC и иже с ними как раз соответствуют уровню пятилетней давности. Чего-то более древнего среди потенциальной аудитории в работоспособном состоянии, думается, уже просто не найти :)
|
|
Я слышал про эту теорию. А разве это все уже не реализовано... 01.11.08 16:26
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 01.11.08 16:27 Количество правок: 1
|
> Есть большая сцена с кучей дочерних объектов, например,
> земельный участок и дома на этом участке. Можно ли как-то
> игнорировать те объекты, которые находятся за пределами
> видимости и не нагружать видеокарту их прорисовкой?
Я слышал про эту теорию. А разве это все уже не реализовано в том же ДиректХ. Хотя там не та теория, которая имеется в виду. Я полагаю из-за ее неоправданности - вычисление тех областей объектов, которые не будут перекрыты/затенены другими объектами задача более трудоемкая, чем применение Z буфера. Здесь же все просто - прежде вывода точки - проверка ее глубины в z буфере. Ели она виднее, чем та, что уже есть, то нарисовали точку, занесли ее глубину в Z буфер. Если начать отрисовку с объектов, которые ближе всго, то последние объекты будут обрабатываться за минимальное время, так как вероятность того, что у них хоть какая то точка будет видна, очень мала.
> Вообще интересуют вопросы создания оптимального 3D-движка.
> Те книги, которые нашёл, меня не удовлетворили, там
> оптимальности, в смысле быстродействия, уделяется далеко не
> первое значение.
Это не выгодно. Разве за пол года можно соптимизировать движек, чтоб он стал быстрее в два раза. А через полгода начинается производство очередной видеоплаты, которая в два раза быстрее, чем та, что выпускалась пол года назад.
|
| |
С применением Z-буфера один и тот же пиксел может... 01.11.08 18:19
Автор: Vedrus <Serokhvostov Anton> Статус: Member
|
>Здесь же все просто - прежде вывода точки -
> проверка ее глубины в z буфере. Ели она виднее, чем та, что
> уже есть, то нарисовали точку, занесли ее глубину в Z
> буфер.
С применением Z-буфера один и тот же пиксел может прорисовываться раз 50. Понятно, что не на экране, но и этого хватит, чтобы тормаза появились. Конечно, видеокарты развиваются, но если оптимальное что-нибудь сделать, то можно будет большим числом полигонов оперировать. Вот и ищу.
> Это не выгодно. Разве за пол года можно соптимизировать
> движек, чтоб он стал быстрее в два раза. А через полгода
> начинается производство очередной видеоплаты, которая в два
> раза быстрее, чем та, что выпускалась пол года назад.
Ну, при грамотном подходе можно наверно добиться того, чтобы обновление под новую видюху заняло минимум времени.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
