информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Портрет посетителяSpanning Tree Protocol: недокументированное применениеСетевые кракеры и правда о деле Левина
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
 Умер Никлаус Вирт 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / theory
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Индексация spatial-данных 03.11.08 07:44  Число просмотров: 1909
Автор: 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.
<theory>
Минимизация обрабатываемых полигонов в 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. Понятно, что не на экране, но и этого хватит, чтобы тормаза появились. Конечно, видеокарты развиваются, но если оптимальное что-нибудь сделать, то можно будет большим числом полигонов оперировать. Вот и ищу.

> Это не выгодно. Разве за пол года можно соптимизировать
> движек, чтоб он стал быстрее в два раза. А через полгода
> начинается производство очередной видеоплаты, которая в два
> раза быстрее, чем та, что выпускалась пол года назад.
Ну, при грамотном подходе можно наверно добиться того, чтобы обновление под новую видюху заняло минимум времени.
1




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach