Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 210
Эх, к вашей действительно замечательной статье да эти бы комментарии: http://habrahabr.ru/blogs/games/87200/#comments
Комментарий относительно десятков гигабайт оперативной памяти на машине, на которой гонялась демка UD я думаю преувеличен. Если присмотреться, то все в демке сделано из примитивных повторяющихся кусков, хоть и очень детализированых. Т.е. реально храним в оперативной памяти не весь дом а один кирпич и из него складываем все стенки в редакторе. От этого неприятное ощущение повторяющихся шаблонов.
Согласен про сцену «слонов» («чудовищ»?). Они про два миллиарда точек говорили в сцене «джунглей». Вполне может там тоже повторяющегося конечно полно. Но реально эта сценка маааалюсенькая по сравнению с уровнями в современных играх. Так что проблема все равно имеется где это хранить. Они говорят о том, что детализация их дерева в сто (кажется) раз больше чем у Crysis…
Возможно скоро технологии так скакнут что 3D будут обрабатывать не на CPU и не GPU а в облаке. Через быстрое интернет соединение)
Вот только они стесняются показать рядом одновременно текстурированное дерево из Crysis в UltraHigh (если не ошибаюсь, то в конфиге есть параметры, отвечающие за количество граней и сегментов ствола дерева) и то же самое дерево в UD.
Или такой ролик где-то есть? Ну, что б одной половине кадра результат одного движка, в другой — другого (как обычно в примерах сравнений XBOX vs PC vs PS3)
Или такой ролик где-то есть? Ну, что б одной половине кадра результат одного движка, в другой — другого (как обычно в примерах сравнений XBOX vs PC vs PS3)
Сравнение вряд ли возможно. Дерево в Crysis имеет все равно полигоны + карты нормалей, там нет просто информации о точках. (Хотя исходно такие вещи моделируются в zBrush, где такая информация есть, но она не экспортируется).
Так что даже если бы у них была технология перевода полигональных моделей в их формат, для сравнения (а ее пока у них нет), то дерево бы выглядело точно так же, как в крайзисе high.
Тут все их видео на данный момент:
unlimiteddetailtechnology.com/videos.html
Так что даже если бы у них была технология перевода полигональных моделей в их формат, для сравнения (а ее пока у них нет), то дерево бы выглядело точно так же, как в крайзисе high.
Тут все их видео на данный момент:
unlimiteddetailtechnology.com/videos.html
«…Так что даже если бы у них была технология перевода полигональных моделей в их формат, для сравнения (а ее пока у них нет), то дерево бы выглядело точно так же, как в крайзисе high.…»
Ну так не надо переводить полигональную модель в их формат. Или это большая проблема — построить UD-модель, визуально похожую на то, что видим в Crysis?
Так мы сравнивать-то должны результат какой-то, т.е., по сути, некую визуальную часть, а не красивые и умные слова.
Смысл создания технологии всё-таки не в самой технологии, а в том, какой именно результат она позволяет получить.
Ибо сравниваем мы в конечном итоге то, какого качества картинку можно получить на единицу затраченных ресурсов.
Да, дерево в Crysis полигональное. Ну так вот и продемонстрируйте, что UD круче, т.е. позволяет получить более красивое такое дерево (с какого расстояния на него не посмотри), и при этом потребляет вот столько-то ресурсов.
Этого-то нету, вот в чём штука. А есть просто красивые слова о том, как это круто, и нелепые сравнения с гуглом.
Ну так не надо переводить полигональную модель в их формат. Или это большая проблема — построить UD-модель, визуально похожую на то, что видим в Crysis?
Так мы сравнивать-то должны результат какой-то, т.е., по сути, некую визуальную часть, а не красивые и умные слова.
Смысл создания технологии всё-таки не в самой технологии, а в том, какой именно результат она позволяет получить.
Ибо сравниваем мы в конечном итоге то, какого качества картинку можно получить на единицу затраченных ресурсов.
Да, дерево в Crysis полигональное. Ну так вот и продемонстрируйте, что UD круче, т.е. позволяет получить более красивое такое дерево (с какого расстояния на него не посмотри), и при этом потребляет вот столько-то ресурсов.
Этого-то нету, вот в чём штука. А есть просто красивые слова о том, как это круто, и нелепые сравнения с гуглом.
Да, но пишут они это про сцену с пирамидами животных, которая вполне возможно хранит только одно животное… Но подмечено верно.
> Как видно — камни «честно» выступают на углу. Правда демка (если память не изменяет) под high-end карточку — GeForce 28x…
под GF100 ( GeForce GTX 4x0 ) и ATI R800 ( Radeon 5xxx ).
под GF100 ( GeForce GTX 4x0 ) и ATI R800 ( Radeon 5xxx ).
Спасибо, сейчас поправлю.
5xxx — это не hi-end, 58xx — hi-end (про NVIDIA точно не знаю)
А мы эту хай-энд карточку на точках смоделируем на проце и заставим рендерить!
Если Вы имеете в виду 3D видео, которое не-Аватар и не-Шрек, которое не имеет 3D моделей, а снимается просто двумя камерами… то там надо использовать стерео-алгоритмы и алгоритмы фото(видео)грамметрии… а в них косяков пока что много. Тут больше скорее подойдер лазерное сканирование поверхностей. Но оно очень дорогое пока что развлечение.
Эээээхххх… прямо мою тему затронули… задача у меня та же — хотелось взять и отснять подмосковный городишко на 50000 жителей (всего-то 300 домов) и сделать 3D карту… казалось все так просто и должно быть уже в 2006 году было это решено быть ))
Если бы Вы знали сколько лет я уже изучаю для этого фотограмметрию и общаюсь с самыми большими умами (профессорами, докторами наук) в этой области, которые мне говорят: «нету готовых решений, все половинчатые… кое-как кое-чего можно, но далеко не все удается пока что»…
Вот это (восстанавливал сам с помощью нескольких разных технологий — это две лицевые стены дома и почти 300 фотографий из двигающейся машины):
было чуть ли не значительным достижением в 2007 году. Бело-зеленые полосочки — откуда снят кадр, сине-белые точки — всего лишь те точки, что удалось восстановить. Но и то этим нельзя пользоваться в коммерческих, например, целях — почти все алгоритмы в этой области используют патентованный алгоритм (SIFT) нахождения точек, который никто превзойти толком не может. Да и результат, в общем-то едва ли можно считать «настоящим 3d» :) так — куски стен, хоть и очень точно расположенные.
Но даже чтобы это сделать — мне пришлось четыре разных трека по 50 кадров склеивать.
Наиболее близкое к тому, что Вы хотите описывается в этом TechTalk от Google, полу-военная разработка с использованием лазеров и кучи студентов: www.youtube.com/watch?v=Y6fAszlImPM (только чего-то YouTube брыкается, не хочет показывать… заговор?)
Конечно сейчас и значительно более лучшие вещи делают. Но об этом может как-нибудь в другом топике.
Вообще по этой теме долго могу писать :)
Если бы Вы знали сколько лет я уже изучаю для этого фотограмметрию и общаюсь с самыми большими умами (профессорами, докторами наук) в этой области, которые мне говорят: «нету готовых решений, все половинчатые… кое-как кое-чего можно, но далеко не все удается пока что»…
Вот это (восстанавливал сам с помощью нескольких разных технологий — это две лицевые стены дома и почти 300 фотографий из двигающейся машины):
было чуть ли не значительным достижением в 2007 году. Бело-зеленые полосочки — откуда снят кадр, сине-белые точки — всего лишь те точки, что удалось восстановить. Но и то этим нельзя пользоваться в коммерческих, например, целях — почти все алгоритмы в этой области используют патентованный алгоритм (SIFT) нахождения точек, который никто превзойти толком не может. Да и результат, в общем-то едва ли можно считать «настоящим 3d» :) так — куски стен, хоть и очень точно расположенные.
Но даже чтобы это сделать — мне пришлось четыре разных трека по 50 кадров склеивать.
Наиболее близкое к тому, что Вы хотите описывается в этом TechTalk от Google, полу-военная разработка с использованием лазеров и кучи студентов: www.youtube.com/watch?v=Y6fAszlImPM (только чего-то YouTube брыкается, не хочет показывать… заговор?)
Конечно сейчас и значительно более лучшие вещи делают. Но об этом может как-нибудь в другом топике.
Вообще по этой теме долго могу писать :)
Для начала потому что чтобы было только достаточно данных — то нужно минимум 8 точек знать + фокальные расстояния обеих камер. Ну может и правда статью напишу — а то этот алгоритм как раз более-менее изученный, хоть и длинный, но информации по нему нифига не найдешь в рунете (сам мучился).
Там самые большие проблемы с тем, что часто: 1) не знаешь фокальные расстояния у фотографии… 2) не знаешь какая точка на одной фотке какой точке на другой соответствует, по крайней мере в автоматическом режиме… 3) если есть искажения объективов то число точек до 16 и больше может подняться… 4) не так уж просто, как кажется найти эти 8 точек… 5) ошибка в одной точке и провал всего алгоритма обеспечен :) есть методы борьбы, но и они не идеально спасают.
Там самые большие проблемы с тем, что часто: 1) не знаешь фокальные расстояния у фотографии… 2) не знаешь какая точка на одной фотке какой точке на другой соответствует, по крайней мере в автоматическом режиме… 3) если есть искажения объективов то число точек до 16 и больше может подняться… 4) не так уж просто, как кажется найти эти 8 точек… 5) ошибка в одной точке и провал всего алгоритма обеспечен :) есть методы борьбы, но и они не идеально спасают.
Вы в любом случае получаете объект с точность до масштаба. Вы же не знаете — кубик на фотографии — он 1см размером или 1метр. Для точных размеров Вам надо знать еще хоть одну длину на фотографии.
В случае же если у Вас фокальное расстояние одно и то же — проблема уменьшается по-моему до 7 точек (Вы просто убрали одну неизвестную в уравнениях), в некоторых случаях до 6, но тогда результатом будет несколько «правильных» вариантов, из которых только один настоящий — но его нельзя узнать программно. Но все проблемы остаются теми же… плюс там такая безумная математика полиномов начинается для решения, что я ее даже за эти годы не осилил :)
Я вот тоже блин думал, что там такого сложного — взял две-три точки — да все вычислил. Теперь чего-то уже жалею, что влез в это :)) особенно читая очередную формулу на полстраницы с объяснениями на следующих 20 страницах, использующие значки, даже названия которых я не знаю и объяснения в духе «это у нас нормально, что прямые пересекаются, так и должно быть, вообще-то все линии тут сходятся в две комплексные точки, какими бы Вы ни рисовали их в этом четырехмерном пространстве» :))
В случае же если у Вас фокальное расстояние одно и то же — проблема уменьшается по-моему до 7 точек (Вы просто убрали одну неизвестную в уравнениях), в некоторых случаях до 6, но тогда результатом будет несколько «правильных» вариантов, из которых только один настоящий — но его нельзя узнать программно. Но все проблемы остаются теми же… плюс там такая безумная математика полиномов начинается для решения, что я ее даже за эти годы не осилил :)
Я вот тоже блин думал, что там такого сложного — взял две-три точки — да все вычислил. Теперь чего-то уже жалею, что влез в это :)) особенно читая очередную формулу на полстраницы с объяснениями на следующих 20 страницах, использующие значки, даже названия которых я не знаю и объяснения в духе «это у нас нормально, что прямые пересекаются, так и должно быть, вообще-то все линии тут сходятся в две комплексные точки, какими бы Вы ни рисовали их в этом четырехмерном пространстве» :))
во-первых смотрим сюда:
www.cs.unc.edu/Research/urbanscape/
www.youtube.com/watch?v=3RF26nWzxhc
во-вторых, камеры калибрируются зараннее, а не в момент вычисления геометрии. В OpenCV есть работающий код по алгоритму Жанга.
в-третьих SIFT это дишь один из вариантов для нахождения feature-points, есть и другие, хотя возможно менее робастные. Да и вообще, придумайте свои если патенты мешают, добавьте какой нить параметр (но сначала статью:)
в-четвертых, давайте дружить :) я тоже занимаюсь подобными вещами.
www.cs.unc.edu/Research/urbanscape/
www.youtube.com/watch?v=3RF26nWzxhc
во-вторых, камеры калибрируются зараннее, а не в момент вычисления геометрии. В OpenCV есть работающий код по алгоритму Жанга.
в-третьих SIFT это дишь один из вариантов для нахождения feature-points, есть и другие, хотя возможно менее робастные. Да и вообще, придумайте свои если патенты мешают, добавьте какой нить параметр (но сначала статью:)
в-четвертых, давайте дружить :) я тоже занимаюсь подобными вещами.
UrbanScape то это давно я слюни пускаю, только вот товарищ Полифай не делится результатами-то и сорцами :) кроме видео.
А вообще ща и более впечатляющие уже видюшки есть:
www.youtube.com/watch?v=pcpVDGiNFZM
Даже заранее калибрированные камеры — это все равно минимум 8 точек пересечения надо. 6 на три кадра (но там я тоже математику не понимаю толком). Да и по сути на самом деле от камеры только фокальное расстояние так уж требуется — искажения можно тем же PTLens убрать легко. Но блин все равно 6-8 точек найти это не мало, особенно когда камера толком может заснять только часть плоского дома.
А если бы я мог придумать свой алгоритм для feature points — я бы не жаловался на патентованность SIFT :)
А вообще ща и более впечатляющие уже видюшки есть:
www.youtube.com/watch?v=pcpVDGiNFZM
Даже заранее калибрированные камеры — это все равно минимум 8 точек пересечения надо. 6 на три кадра (но там я тоже математику не понимаю толком). Да и по сути на самом деле от камеры только фокальное расстояние так уж требуется — искажения можно тем же PTLens убрать легко. Но блин все равно 6-8 точек найти это не мало, особенно когда камера толком может заснять только часть плоского дома.
А если бы я мог придумать свой алгоритм для feature points — я бы не жаловался на патентованность SIFT :)
ну так а кто вам код отдаст за просто так??
Диссер опубликован. Я не смотрел туда, но наверняка все описание там есть — берите да имплементируйте. (И это будет прекрасным примером повторяемости эксперимента!)
Для начала можно начать с этого
«Real-time Plane-sweeping Stereo with Multiple Sweeping Directions»
www.cs.unc.edu/Research/urbanscape/public/Gallup_RealtimePlanesweepingStereo07.pdf (сам хотел написать, да пока руки не дошли)
А по поводу калибрации я вас не понимаю… Зараннее закрепили камеры (жестко чтобы не крутились ни на миллиметр). Прокалибрировали: паттерн на принтере распечатали и подсунули туда.
Все параметры известны! Ставим камеры на машину (или еще куда). Можно начинать хоть dense estimation (с помощью ректификации) хоть feature-point matching.
Что вам еще нужно??
Диссер опубликован. Я не смотрел туда, но наверняка все описание там есть — берите да имплементируйте. (И это будет прекрасным примером повторяемости эксперимента!)
Для начала можно начать с этого
«Real-time Plane-sweeping Stereo with Multiple Sweeping Directions»
www.cs.unc.edu/Research/urbanscape/public/Gallup_RealtimePlanesweepingStereo07.pdf (сам хотел написать, да пока руки не дошли)
А по поводу калибрации я вас не понимаю… Зараннее закрепили камеры (жестко чтобы не крутились ни на миллиметр). Прокалибрировали: паттерн на принтере распечатали и подсунули туда.
Все параметры известны! Ставим камеры на машину (или еще куда). Можно начинать хоть dense estimation (с помощью ректификации) хоть feature-point matching.
Что вам еще нужно??
Да, это тот самый PMVS2 от Yasutaka Furukaw. Но почему они не сделали Fill Holes? И сколько ещё предстоит сделать моделлерам, чтобы получить законченную модель здания?
Вообще за этими технологиями громадное будущее, но по каким то причинам очень медленно происходит их развитие. 20 лет назад все думали, что фотограмметрия уже через 10 лет позволит восстанавливать 3D точно также, как за 10 лет развился рендеринг.
Лет через 10-15 риэлторы не будут показывать фотографии квартиры, а будут присылать ссылку на 3D модель (да, есть Photosynth, но пока нет полноценного 3D). Все магазины будут представлять товары в настоящем 3D, так как их можно будет создать автоматически по фотографиям.
Да, кстати, в одном из ранних релизов Photosynth, ещё до того как он стал Microsoft, была демка, где они полностью воссоздавали 3D модель с текстурами, а не просто point cloude.
Про калибрацию — да нахрена она нужна? Тот же syntheyes (match mover) вычисляет за секунды любой fov в любой момент времени, даже если был использован зум на видеокамере, а также устраняет дисторсию. То что эти «учёные» не знают таких очевидных вещей, и говорят «калибруйте камеры» — это чтобы им было проще.
Совершенно не понимаю, почему существующие photo 3d scanner и прочие программы требуют эти «коврики» для калибрации. Им сложно внедрить алгоритм расчёта всех параметров камеры, который есть в syntheyes и photosynth?
Вообще за этими технологиями громадное будущее, но по каким то причинам очень медленно происходит их развитие. 20 лет назад все думали, что фотограмметрия уже через 10 лет позволит восстанавливать 3D точно также, как за 10 лет развился рендеринг.
Лет через 10-15 риэлторы не будут показывать фотографии квартиры, а будут присылать ссылку на 3D модель (да, есть Photosynth, но пока нет полноценного 3D). Все магазины будут представлять товары в настоящем 3D, так как их можно будет создать автоматически по фотографиям.
Да, кстати, в одном из ранних релизов Photosynth, ещё до того как он стал Microsoft, была демка, где они полностью воссоздавали 3D модель с текстурами, а не просто point cloude.
Про калибрацию — да нахрена она нужна? Тот же syntheyes (match mover) вычисляет за секунды любой fov в любой момент времени, даже если был использован зум на видеокамере, а также устраняет дисторсию. То что эти «учёные» не знают таких очевидных вещей, и говорят «калибруйте камеры» — это чтобы им было проще.
Совершенно не понимаю, почему существующие photo 3d scanner и прочие программы требуют эти «коврики» для калибрации. Им сложно внедрить алгоритм расчёта всех параметров камеры, который есть в syntheyes и photosynth?
Такие разработки уже есть, например, программа 3DSOM. На вход она получает фотографию объекта с разных ракурсов на специальном коврике (который можно распечатать), а затем на основе этих фотографий строится трехмерное изображение (зачастую паршивое, но все-таки).
Некоторые примеры см. картинки
Некоторые примеры см. картинки
Тут понимаете проблема в масштабе — маленькие объекты легко восстановить с помощью подобных технологий. Даже отдельный дом довольно не сложно было бы, правда под него не запихнешь эту сетку реперных точек, но возможно.
Проблема начинается когда целый город хочешь сделать — то есть целую сеть зданий расположенных как-то относительно друг друга и не касающихся друг друга… отдельное-то здание и SketchUpом без проблем можно сделать, без всякой фотограмметрии.
Проблема начинается когда целый город хочешь сделать — то есть целую сеть зданий расположенных как-то относительно друг друга и не касающихся друг друга… отдельное-то здание и SketchUpом без проблем можно сделать, без всякой фотограмметрии.
так ведь восстановление города уже было где то проделано?? я видел демку, и в каком то фильме это даже использовалось!
Я не говорю, что это невозможно — возможно, но не доступно.
Это делается лазерным сканированием + специальным (закрытым) софтом ссылку я уже давал www.youtube.com/watch?v=Y6fAszlImPM. Пока что доступа простым смертным к таким технологиям нет. А лазерные сканеры ой как дофига стоят.
А в фильмах, в основном, восстанавливается небольшая часть только города (отдельная сцена в камере). Это возможно и сейчас. И то восстанавливается на самом деле больше движение камеры, чтобы ее совместить с 3D, сама сцена для фильмов не восстанавливается (за исключением отдельных точек).
Это делается лазерным сканированием + специальным (закрытым) софтом ссылку я уже давал www.youtube.com/watch?v=Y6fAszlImPM. Пока что доступа простым смертным к таким технологиям нет. А лазерные сканеры ой как дофига стоят.
А в фильмах, в основном, восстанавливается небольшая часть только города (отдельная сцена в камере). Это возможно и сейчас. И то восстанавливается на самом деле больше движение камеры, чтобы ее совместить с 3D, сама сцена для фильмов не восстанавливается (за исключением отдельных точек).
Помню, на хабре была тема про то, что восстановили в трехмере какой-то европейский город по снимкам с гугловской пикасы.
Отбирались фотки, в Exif полях которых была GPS информация. Как-то состыковывлось анализировалось на автомате.
В результате получилась 3D модель, в которой видны все главные улицы города, центральная площадь, на нем здание со шпилями.
Щас что-то не могу найти.
Отбирались фотки, в Exif полях которых была GPS информация. Как-то состыковывлось анализировалось на автомате.
В результате получилась 3D модель, в которой видны все главные улицы города, центральная площадь, на нем здание со шпилями.
Щас что-то не могу найти.
поиск одинаковых участков изображения ведь давно реализовано во всех mpeg-алгоритмах (для поиска смещения блоков между кадрами; а тут мы имеет просто два кадра в которых как будто изображение чуть повернулось)? не пробовали прикрутить?
Да, по сути это видеотрекинг — есть даже специальные программы. Но, к сожалению, сколько я с ними не бился — больше 3-4 домов и то на открытой улице (2-3 минуты езды) не удается смоделировать. Любой разрыв видео (камера показала только небо) и все, связать не удастся…
А если камеру частично в землю направить, например широкоугольным обьективом воспользовавшись, или еще както хитро извернувшись?
ну а как ты смоделируешь дом, протрекав видео в том же syntheyes? да и как текстуру автоматом наложить?
Да, все мы видели недавнюю демку www.youtube.com/watch?v=vEOmzjImsVc, которая даже текстуры в реальном времени через вебкамеру накладывает. Но открытой программы то до сих пор нет!
Да, все мы видели недавнюю демку www.youtube.com/watch?v=vEOmzjImsVc, которая даже текстуры в реальном времени через вебкамеру накладывает. Но открытой программы то до сих пор нет!
хех, занимаюсь той же самой задачей, только мы не используем сифт\асифт. профессора правильно говорят — общего решения пока нет.
Пробовал новый PMVS2? Там проблема, как и в старом PMVS из Meshlab — цветые точки — это ещё не всё, автоматического наложения текстур на получившуюся полигональную модель нет. Или уже знаешь как это побороть?
Ну и grail.cs.washington.edu/projects/interior/ если не останется закрытым научным документом, то тоже даёт новый уровень возможностей. Здесь хотя бы автоматические текстуры есть.
Твоя ссылка на Google — это те, кто в будущем стали называться CyberCity. Алгоритм закрытый, сотрудничают с Google для Google Earth 3D Cities. Выложили бы программу — через месяц бы вся Земля стала бы в 3D благодаря добровольцам с фотоаппаратом.
Ну и grail.cs.washington.edu/projects/interior/ если не останется закрытым научным документом, то тоже даёт новый уровень возможностей. Здесь хотя бы автоматические текстуры есть.
Твоя ссылка на Google — это те, кто в будущем стали называться CyberCity. Алгоритм закрытый, сотрудничают с Google для Google Earth 3D Cities. Выложили бы программу — через месяц бы вся Земля стала бы в 3D благодаря добровольцам с фотоаппаратом.
Вполне вероятно это требует много оперативки, но это разве сейчас проблема?
12гб, а тем более и 24 гб оперативы — не особо дешёвое развлечение, и уж тем более не думаю, что в ближайшие пару-тройку лет оно станет массовым.
Лично мне на все новые игры вполне хватает не новой nvidia 8800gts 512mb и 4 гб оперативы. Сейчас вот Ассасина второго прохожу — 30-35fps. То есть я к чему это написал — если не занимаешься 3d-моделлированием или крутым рисованием, то такое количество оперативки довольно среднему пользователю совершенно не сдалось.
Лично мне на все новые игры вполне хватает не новой nvidia 8800gts 512mb и 4 гб оперативы. Сейчас вот Ассасина второго прохожу — 30-35fps. То есть я к чему это написал — если не занимаешься 3d-моделлированием или крутым рисованием, то такое количество оперативки довольно среднему пользователю совершенно не сдалось.
5000 рублей на планку 4 гига, 30000 на 24 гига — как топовая видеокарта. Если обещают что видеокарта больше не понадобится… Плюс, по идее, такие задачи должны хорошо параллелиться, так что экстенсивный путь умножения ядер (обещают в ближайшее время шестиядерные десктопные процессоры) себя вполне оправдывает. К тому же игры всегда были двигателем прогресса, так что если технология себя оправдает то железо будет.
Да, но опять же повторюсь — сценка в джунглях (2млрд. точек) у них мааааалюсенькая по сравнению с тем, каких размеров один уровень в crysis… так что умножайте это возможно на 100 или на 1000. :)
Всего десять лет назад у меня было в 100 раз меньше памяти чем сейчас. При этом уже сейчас можно собрать систему, в которой будет ещё в 20 раз больше (про цену умолчим, но сам факт). Если вопрос будет актуален — за 2-3 года подтянут объемы.
Возможно, все возможно.
Только вот даже прочитать эти 30 гигов в память с винчестера на современной скорости — 16 минут :) а это всего-то одна полянка. А скорости винчестеров экспоненциально не растут.
Только вот даже прочитать эти 30 гигов в память с винчестера на современной скорости — 16 минут :) а это всего-то одна полянка. А скорости винчестеров экспоненциально не растут.
Ну, а если разрешение довести до любимых 1920 на 1080…
Может какую-нибудь узко специализированную нишу движок и займёт, ели не загнётся проект.
Может какую-нибудь узко специализированную нишу движок и займёт, ели не загнётся проект.
Тоже не понимаю, откуда столько восторгов по поводу воксельного движка. Эти движки выглядят сейчас как уг на фоне обычных полигональных.
Тем более детализация — это не первостепенная задача в современных играх, как мне кажется. Важнее эффекты. Еще не реализованы физические жидкости и дым.
И если бы они придумали движок, который сам создает проработанную игровую вселенную и интересный сценарий — вот это была бы революция.
Тем более детализация — это не первостепенная задача в современных играх, как мне кажется. Важнее эффекты. Еще не реализованы физические жидкости и дым.
И если бы они придумали движок, который сам создает проработанную игровую вселенную и интересный сценарий — вот это была бы революция.
Эффекты дописать наверно и на этом движке не проблема.
Он не совсем вокстельный.
Физические жидкости и дым… вот на основе вокстелей можно сделать, только весь их поисковой механизм помрёт вероятно.
Физические жидкости и дым… вот на основе вокстелей можно сделать, только весь их поисковой механизм помрёт вероятно.
Не думаю, по сути воксель — та же точка, только с радиусом. Другой вопрос что чтобы из массива вокселей сделать объемный объект, типа воды — вот тут уже мощности нужны. И тут уже фиг знает — сможет ли их движок хорошо отрисовывать пространство МЕЖДУ довольно далеко отдельно стоящими точками. Тут я даже предположить не могу.
Конечно не сможет, движок не отрисовывает пространство между, он умеет отрисовывать только точки.
Если исходить из того, что жидкости не сжимаемы… ну подумаешь пару триллионов точек на одинаковом расстоянии положить, их движок разберётся какие несколько тысяч отрисовать.
Но вот расчитать движение каждой их этих точек… не получится, интерполировать придётся сильно. Мне кажется у их движка вообще основная проблема — анимация, а для статики может и попрёт.
Если исходить из того, что жидкости не сжимаемы… ну подумаешь пару триллионов точек на одинаковом расстоянии положить, их движок разберётся какие несколько тысяч отрисовать.
Но вот расчитать движение каждой их этих точек… не получится, интерполировать придётся сильно. Мне кажется у их движка вообще основная проблема — анимация, а для статики может и попрёт.
не могу найти подходящую статью с красивыми картинками (сам помню был впечатлен когда встретил), но проблема рендеринга из point-cloud уже давным давно решена.
Можно здесь попробовать поискать:
www-cs.ccny.cuny.edu/~wolberg/publications.html#monograph
Идея «в кратце» состоит в том, что каждая точка представляет из себя не только цет и координаты, а еще и 3-х мерную гаусовскую сферу (точнее сказать распределение, но тогда это будет труднее представить).
В тех местах, где не хватает точек из облака, можно посмотреть из какой точки самая большая гауссовая компонента и подставить ее цвет (это будет трехмерный аналог nearest-neighbor re-sampling) или же цвет сделать взвешенной суммой из нескольких соседних точек (это будет аналог bi-linear).
Можно здесь попробовать поискать:
www-cs.ccny.cuny.edu/~wolberg/publications.html#monograph
Идея «в кратце» состоит в том, что каждая точка представляет из себя не только цет и координаты, а еще и 3-х мерную гаусовскую сферу (точнее сказать распределение, но тогда это будет труднее представить).
В тех местах, где не хватает точек из облака, можно посмотреть из какой точки самая большая гауссовая компонента и подставить ее цвет (это будет трехмерный аналог nearest-neighbor re-sampling) или же цвет сделать взвешенной суммой из нескольких соседних точек (это будет аналог bi-linear).
www-cs.ccny.cuny.edu/~wolberg/pub/tvcg97.pdf
Scattered Data Interpolation with Multilevel B-Splines
Не это ли?
Scattered Data Interpolation with Multilevel B-Splines
Не это ли?
ИИ только напишут — и придумают тот самый движок…
жидкость и дым значительно проще просчитать в точках — particles
Спасибо за обзор технологии, не знал про неё — впечатляет!
ИМХО оно реально, доводы про «современные винчестеры» и «гигабайты оперативки» неубедительны, т.к. настоящие современные винчестеры — SSD, у которых скорость доступа достаточна. И кто сказал, что не используются алгоритмы сжатия точек? Разве проблема их создать, если уж сделали гораздо более серьёзные алгоритмы их выборки?
Читаю дальше )
ИМХО оно реально, доводы про «современные винчестеры» и «гигабайты оперативки» неубедительны, т.к. настоящие современные винчестеры — SSD, у которых скорость доступа достаточна. И кто сказал, что не используются алгоритмы сжатия точек? Разве проблема их создать, если уж сделали гораздо более серьёзные алгоритмы их выборки?
Читаю дальше )
Спасибо за компетентный разбор, именно такого я и ждал.
Дайте ещё таких же демок!
Все эти point of cloud напоминают мне photosynth он там тоже рисует очень похоже как на видео примерах.
Верно :) Фотограмметрия (3d точки из фоток) это и есть та область, где я сталкивался с облаками точек и их редакторами. Только Photosynth на самом деле не совсем исходная технология — исходная для нее — это Phototourism и он же — любимый оперсорцовый Bundler.
точка это настолько гибкая геометрия что может из себя представлять и полигон
совсем маленький полигон при большом отдалении будет казаться точкой
совсем маленький полигон при большом отдалении будет казаться точкой
А возможно комбинировать полигоны и воксели? Т.е. использовать данную технологию, как наращиваемое «мясо» на полигоны (которые дают легкий контроль отсечения)?
А это по сути Вы tesselation и описываете (точнее — displacement maps, которые реализуются методом tesselation). Третье видео, которое такое черно-белое с сеточками. Есть полигон плоский и описание того насколько каждая точка из него выползает, вползает. Но полигоны тоже не так уж легки в отсечении (но по крайней мере для них уже много пускай сложных, но алгоритмов и технологий).
Как я понимаю из видео, тесселяция бьёт базовую сетку, добавляя опять же новые полигоны, учетверяя(?) за итерацию работу процессору. А я имел в виду возможность добавления именно облака точек, без треугольников. Т.е. по сути всё то, что декларируют UD, но контролируемое полигональным каркасом. Или tesselation не увеличивает кол-во треугольников?
Не, там суть в том, что разбиение осуществляет GPU, честно говоря технология очень новая — что является входными данными — не знаю, там для нее карточка-то нужна уровня GTX 480(!). Варианта два — либо это карта смещения, либо отдельные контрольные точки (судя по статье про hardware tesselation), в этом случае это и есть как раз облако точек, наложенное на треугольник (или квад), которые просто изгибают его в пространстве. Но по сути треугольник (или квад) передается один и тот же карточке + уточняющие данные.
А так по сути tesselation это и есть — уточнение полигональной модели.
А так по сути tesselation это и есть — уточнение полигональной модели.
tesselation в GPU предлагалось ATI ещё в 2007ом.
«…
GPU Tessellation Pipeline
Starting with the ATI Radeon HD 2000 series of graphics cards, PC developers can implement tessellation using
dedicated hardware and a programmable pipeline. We designed an extension API for a GPU tessellation pipeline
taking advantage of the hardware fixed-function tessellator unit available on recent consumer GPUs to access
this functionality in Direct3D 9 and Direct3D 10/10.1 APIs.
…»
А ихний же <a href=«ati.amd.com/products/pdf/truform.pdf>TruForm так вообще 2001-го года.
Это к вопросу об очень новой технологии…
«…
GPU Tessellation Pipeline
Starting with the ATI Radeon HD 2000 series of graphics cards, PC developers can implement tessellation using
dedicated hardware and a programmable pipeline. We designed an extension API for a GPU tessellation pipeline
taking advantage of the hardware fixed-function tessellator unit available on recent consumer GPUs to access
this functionality in Direct3D 9 and Direct3D 10/10.1 APIs.
…»
А ихний же <a href=«ati.amd.com/products/pdf/truform.pdf>TruForm так вообще 2001-го года.
Это к вопросу об очень новой технологии…
Вспомнился почему-то Delta Force с его воксельными холмами и трехмерными моделями на них. :)
производительность видео-карточек много большое современных процессоров за счет использования конвейеров параллельных вычислений. Вот кто бы толково додумался, как эту мощь использовать, чтобы не тупо шейдеры через нее гонять — вот тут да, технологический прорыв.
По сути все эти occlusion culling и направлены на то, чтобы не просто тупо шейдеры гонять, а очень только необходимые. Современные игры и движки (CryEngine, Unreal, Unigine, Unity3D) очень умны, чтобы предельно малое количество данных рендерилось, чтобы выжимать все что можно.
А если Вы не про 3D, а вообще чтобы мощность использовать — CUDA уже во всю развивается, да и OpenCL скоро будет.
А если Вы не про 3D, а вообще чтобы мощность использовать — CUDA уже во всю развивается, да и OpenCL скоро будет.
да, я просто про мощность. Такое ощущение, что эффективно используется только 1% заложенной мощности, нормального мат.аппарата не хватает
Ну из того, где я ковырялся — современные игрушки очень эффективно все используют. Там просто процессорики-то простенкие в видеоплате, хоть их и очень много. Они толком и заточены только чтобы матрицы и вектора перемножать.
так в том-т и дело, что перемножать можно меньше, сильно меньше. Просто все это через верхний уровень делается, вот издержек-то и накапливается.
Напоминает использование PHP для обработки веб-данных — все его используют, но С для тех же самых задач на 2-3 порядка (да-да, порядка, не раза) эффективнее.
Напоминает использование PHP для обработки веб-данных — все его используют, но С для тех же самых задач на 2-3 порядка (да-да, порядка, не раза) эффективнее.
Мелькают у них как минимум тени (они сами говорят, что параметры shadow mapping не успели оттюнинговать для демки), но иногда и правда кажется что куски геометрии мелькают. Про LOD они наоборот говорят, что это их преимущество, что не нужно использовать. Про инстансинг — да, у меня тоже такая крамольная мысль родилась на первой сцене :) но сцена в джунглях ее развеивает.
Подозреваю что насчет 30гигов через лет 5 будут говорить с усмешкой.
У меня компьютер с 8гигами и на них потрачены вполне вменяемые деньги
У меня компьютер с 8гигами и на них потрачены вполне вменяемые деньги
Кстати расстрою Вас, на ваших 8 гигах, потребуется не 30 гигов, а 60 гигов. :) Дело в том, что то, что я привел в статье — данные для 32 битных машин (да, сглупил, у 32-биток не может быть 32 гигов), для 64-битных — все данные в два раза возможно придется увеличивать — не знаю, честно говоря, не писал под 64-бита ничего. :)
Если они такие крутые почему я должен смотреть демки в убогом качестве 480p ?! ((
unlimiteddetailtechnology.com/videos.html
Наслаждайтесь — там HighRes видюхи есть.
Наслаждайтесь — там HighRes видюхи есть.
Круть конечно, но пока сам демку не запущу на своем компьютере не поверю
Не всегда 3 цвета на точку. Чаще, даже, 4 цвета по байту. 4-й «цвет» — альфа канал\прозрачность.
Технология с тенями, которую ты упомянул в примере с солнышком — это примитизированных shadow volume, дико непроизводительная, в чём многие убедились на примере DOOM 3 и Quake 4.
И, кстати, ИМХО стоило немного упомянуть хотя бы про воксели. Они тут больше в сравнение могут пойти, чем полигоны, ИМХО.
Технология с тенями, которую ты упомянул в примере с солнышком — это примитизированных shadow volume, дико непроизводительная, в чём многие убедились на примере DOOM 3 и Quake 4.
И, кстати, ИМХО стоило немного упомянуть хотя бы про воксели. Они тут больше в сравнение могут пойти, чем полигоны, ИМХО.
Ну да, можно и вообще 4мя double передавать :) glVertex4d(...) Просто я про минимальный случай говорил… Кстати прозрачность для них вообще проблемкой будет, я думаю… если они ищут только БЛИЖАЙШИЙ пиксел который будет виден — то найти какие позади этого ближайшего — может и проблемой быть, о которой я не подумал еще.
Про воксели — да, но как-то я даже и не знаю куда их было бы вписать. Как-то, как и у всей индустрии — мозги в контексте полигонов работают. :)
Про воксели — да, но как-то я даже и не знаю куда их было бы вписать. Как-то, как и у всей индустрии — мозги в контексте полигонов работают. :)
а если видеокарты пойдут не по направлению уменьшения полигонов, а по направлению работы с облаком, не будет ли это производительней в дальнейшем? допустим сделать видео которое будет только и делать что просчитывать то чем сейчас у них цпу занимается, тогда и проц расслабится, и видео можно будет подумать как ушучшать (блики, етк)
Все верно, конечно можно. Сделать их алгоритм в железе. Проблема в том, что хоть это и возможно — но это индустрии игр сейчас не нужно. У них уже есть инструменты, художники и рабочий процесс заточенный под полигоны. Переделывать это все — им нужен стимул. Просто факт того, что там будет куча деталей и им придется в разы больше работы делать + отказаться временно от эффектов — это вряд ли их простимулирует.
ну выше правильно сказали, сейчас они тупо ищут спонсоров, еси кто-то найдется, то появятся и эффекты примитивные (просто чтоб показать что можно, для начала) и еще ченить придумают :) в можно ведь создавать модели с мизерными полигонами и потом их просто переводить в облако для игр, тогда и редакторы текущие будут работать и художники
хм… немного смешно слышать про проблему нормалей, про 32 гб оперативки…
сплайны и нурбсы никто не отменял, а как вы знаете нормали к ним можно находить через производные, или же при задавать обход и брать из соседних )))
мне кажется все вполне реально
сплайны и нурбсы никто не отменял, а как вы знаете нормали к ним можно находить через производные, или же при задавать обход и брать из соседних )))
мне кажется все вполне реально
Я об этом и говорю, что если знать с какими другими точками связана эта точка — конечно можно :) А знать это можно только если есть треугольник или полигон. Я ж там и уточняю, что речь про честные поля точек, в которых просто разбросаны точки и нет между ними связи. А вот задача поиска соседней точки и вообще построения поверхности по облаку точек — тоже нетривиальна и не факт что в реальном времени ее можно решить.
понимаю, но все же врятли они эти точки честно загружают, это бессмысленно чтобы модель в точках занимала сотни мегабайт, при этом в играх это надо анимировать, связать
а описанная формулами поверхность по сути и занимает на диске мало, да ещё с ресурсами можно поработать для большей производительности.
а описанная формулами поверхность по сути и занимает на диске мало, да ещё с ресурсами можно поработать для большей производительности.
Да не, смысл UD в том-то и есть, что они именно Point Cloud загружают (о чем в видео неоднократно говорится), они даже уточняют, что можно взять полигоны и перевести их в их форма «три координаты + цвет»… Так что речь как раз совсем не о формулах.
Про анимацию, заметьте, они вообще молчат :) Неспроста…
Про анимацию, заметьте, они вообще молчат :) Неспроста…
Это, кстати, как раз именно то, чем воксели и занимаются — построение поверхности по близлежащим точкам, а они с гордостью 60fps на GeForece 280 GTX(!!) выжимают. www.youtube.com/watch?v=VpEpAFGplnI
В общем — верно, но:
1. хранить есть где (винчестер), нет возможности в реальном времени обратится к этому всему
2. верно, только тени как раз легко рисуются (объяснил в статье)
3. не в том дело — нет сотрудников, которые бы работали в облаках точек — не умеет этого почти никто, нанимать некого… а переучиваться, переделывать софт и т.п. — все это большие деньги и много времени — индустрии не надо. плюс это сильно увеличит количество работы, которую придется делать — игры будут еще дороже.
1. хранить есть где (винчестер), нет возможности в реальном времени обратится к этому всему
2. верно, только тени как раз легко рисуются (объяснил в статье)
3. не в том дело — нет сотрудников, которые бы работали в облаках точек — не умеет этого почти никто, нанимать некого… а переучиваться, переделывать софт и т.п. — все это большие деньги и много времени — индустрии не надо. плюс это сильно увеличит количество работы, которую придется делать — игры будут еще дороже.
Я вижу противоречие в третьем пункте. Т.к. при полигонах процесс такой — рисуем в ZBrush супер-детально, а потом трахаемся, пытаясь заставить это выглядеть прилично в low-poly. В новой технологии такой проблемы нету.
Никто уже давно не «трахается» с тем, чтобы лоуполи выглядело как хай. Технология нормалмэпинга и его производных отработана до предела — карты нормалей, карты высот снимаются быстро и эффективно в любом редакторе. Когда в широкое применение поступит тесселяция (DX11, GL4), там разницы от этих картинок (в плане геометрии) мы уже не заметим. И это, практически не меняя уже существующий конвейер по созданию арта.
»небольшая сцена, которая, как мы выяснили займет (только она!) 30 гигов места…
Мы ничего не выясняли. Это вы. И не выяснили, а предположили. Пока сути технологии же не названо? Не названо. Вот когда разрабы расскажут что да как, тогда и будет что обсуждать. А так получается, что вы сделали свой вывод (не факт, что верный), и от него пляшете.
Пока это, конечно, выглядит не лучше, чем трехмерная графика в рендерах начале 90-х. Но кто знает, может и впрямь сделали чего хорошего.
Мы ничего не выясняли. Это вы. И не выяснили, а предположили. Пока сути технологии же не названо? Не названо. Вот когда разрабы расскажут что да как, тогда и будет что обсуждать. А так получается, что вы сделали свой вывод (не факт, что верный), и от него пляшете.
Пока это, конечно, выглядит не лучше, чем трехмерная графика в рендерах начале 90-х. Но кто знает, может и впрямь сделали чего хорошего.
Дело в том, что алгоритм по их заявлениям ложится на плечи CPU. Если мы говорим об играх, то там есть чем занять CPU и без графики: физика, ИИ, игровая логика, добавь в это ещё и графику и мы вернёмся на уровень Quake 1 по всем остальным параметрам. Если пытаться перекладывать алгоритм на нынешние GPU (CUDA, OpenCL), то без аппаратной поддержки их фич, вряд-ли можно добиться хорошей эффективности. Никто в ближайшем будущем радикально менять принципы рендера не будет, потому как, всё рассчитано на нынешний процесс. Так что тут возможен только медленный поступательный процесс.
Ну, знаете. Тоже самое про то, что никто ничего менять не собирается и никому это не нужно говори про много революционных вещей.
И вот вы говорите, что не нужно. Если на мой старом компе можно будет в реальном времени вертеть такие трехмерки, то это как минимум будет удобно в работе, когда нужно быстро показать свободно вращаемую трехмерку, о чтобы она не выглядела серым уродством.
Короче я не был бы так строг к людям, которые только-только показали новую технологию, а их уже какашками закидывают.
И вот вы говорите, что не нужно. Если на мой старом компе можно будет в реальном времени вертеть такие трехмерки, то это как минимум будет удобно в работе, когда нужно быстро показать свободно вращаемую трехмерку, о чтобы она не выглядела серым уродством.
Короче я не был бы так строг к людям, которые только-только показали новую технологию, а их уже какашками закидывают.
При использовании тесселяции на DX11 такие же трёхмерки можно будет вращать в реалтайме. При этом сама демонстрация будет требовать меньше ресурсов оперативной памяти и видопамяти в разы.
Только вот 3Д Макс не работает на Директ Иксе. Вы говорите лишь про игры, а я — про практическое использование в работе, когда нужно показать суперкривого (по форме) детализованного дракона в реальном времени. Вот тут и будет уместна такая графика. Ну это лишь один из примеров.
Ну 3DMax то как раз имеет и OpenGL и DirectX рендер (по крайней мере в версии 7, новых я не ставил), кроме того, как я понял, должна уже появиться спецификация GL с тесселяцией, так что всё работает везде. Нет, я согласен, что какую-нибудь рабоче-промышленную нишу это может занять. Но только после того, как появятся какие-то спецификации этой технологии. Пока что лишь пару неудовлетворительных по качеству картинки видео и весьма расплывчатое описание.
Как не работает? Именно на нем (или OpenGL на выбор) и работает…
Явно очень много вещей можно будет делать процедурной геометрией, так-же как и Fabraush делали процедурные текстуры. Принцип тот-же. Так-же можно использовать фрактальные алгоритмы для повышения детализации. Больше матана, меньше данных на диске.
А зачем обязательно на каждую точку по 3 float на координату? Можно и тремя байтами обойтись, если координаты относительные.
А ещё, вроде, была такая игра Вангеры от KD-Labs. Они что-то похожее делали, кажется.
www.youtube.com/watch?v=l_ntIlfuvo8 — вот, можно посмотреть на gameplay. Игрушка сделана в 1998 году и спокойно игралась на pentium-mmx. Так что, технология вполне реальна, imho. Жаль, детали неизвестны, а самому обдумывать — времени нет. Хотя радует, что некие энтузиасты решили написать порт под UNIX. forum.vangers.org/viewtopic.php?f=33&t=2054
Помнится KD-Labs обещали всем подарить ускоритель для вокселей. (KDFX вроде как). Их дело живет и процветает?
Бред полный на мой взгляд, видимо в UD слегка ударились головой.
1. отражения
2. прозрачность
3. различные эффекты: например свечение и т.д.
тут на расчет каждой точки может уходить уж очень много ресурсов.
Да и к примеру у меня монитор 1920 на 1080, будет расти разрешение и дальше, чет не думаю, что процом все просчитать, а еще надо и игровой мир просчитывать, физику и т.д.
1. отражения
2. прозрачность
3. различные эффекты: например свечение и т.д.
тут на расчет каждой точки может уходить уж очень много ресурсов.
Да и к примеру у меня монитор 1920 на 1080, будет расти разрешение и дальше, чет не думаю, что процом все просчитать, а еще надо и игровой мир просчитывать, физику и т.д.
А такая ли проблема с отсутствием шейдеров в облаке точек? Вполне возможно расчитать цвет конкретной точки либо облака точек, либо написать алгоритм, по которому при накладывании теней группа точек будет объединена в логический массив(фактически став полигоном) и выполнена заливка и цветокоррекциЯ в соответствии с требованиями.
Тут дело в эффективном поиске. Подсказка: Гугл за миллисекунды выпёвывает вам выдачу из 10 сниппетов, прошерстив весь хранимый ими контент всего интернета. Правильно, индексы. Сколько дисковых сиков при этом делает гугл? Ну да, у гугла туева хуча серверов. Но когда-то он работал и на одном компе.
Просто ребята придумали какую-то пространствунную индексацию. (но это конечно не просто)
Просто ребята придумали какую-то пространствунную индексацию. (но это конечно не просто)
Во, именно это и хотел сказать.
Автор, неужели вы думаете, что они никак не оптимизировали алгоритм, а просто тупо будут перебирать все точки? Вы сами признаётесь, что над этим трудились серьёзные люди, думаю они как-раз и придумали крутой поиск (не тупой перебор, а алгоритм, повышающий производительность в разы).
Просто по вашей логике и гугл невозможен, а ответы на каждый поисковый запрос от него надо ждать по несколько лет — когда он ещё весь интернет-то обойдёт…
Автор, неужели вы думаете, что они никак не оптимизировали алгоритм, а просто тупо будут перебирать все точки? Вы сами признаётесь, что над этим трудились серьёзные люди, думаю они как-раз и придумали крутой поиск (не тупой перебор, а алгоритм, повышающий производительность в разы).
Просто по вашей логике и гугл невозможен, а ответы на каждый поисковый запрос от него надо ждать по несколько лет — когда он ещё весь интернет-то обойдёт…
Кошмар, люди!.. Хватит по поводу и без повода приводить Гугл в пример, когда не знаете о чем говорите.
У гугла время ответа на поиск КЛАСТЕРОМ машин с безумным объемом памяти и рейдовыми массивами с размером сектора в 64мегабайта (у Вас на домашнем компе — 512 байт) — вполне допустимое в пределах 100мс, 400мс и даже больше… Это 2-10 кадров в секунду! КЛАСТЕРОМ НАВОРОЧЕННЫХ МАШИН!!!
У гугла время ответа на поиск КЛАСТЕРОМ машин с безумным объемом памяти и рейдовыми массивами с размером сектора в 64мегабайта (у Вас на домашнем компе — 512 байт) — вполне допустимое в пределах 100мс, 400мс и даже больше… Это 2-10 кадров в секунду! КЛАСТЕРОМ НАВОРОЧЕННЫХ МАШИН!!!
Ну и поиск нужно проводить не по всему интернету, знаете ли.
И гугл не перебирает весь массив данных при каждом запросе. А по вашему примеру получается, что по другому не бывает.
И гугл не перебирает весь массив данных при каждом запросе. А по вашему примеру получается, что по другому не бывает.
Хм, сдается, мне что там далкео на «2-10 кадров в секунду», учитывая, количество поисковых запросов за ту же секунду…
Так и не одна сотня кластеров. По данным 2006 года у Гугла было около 450 000(!) серверов (а в 2005 всего 200 000), так что считайте сколько у них сейчас. Один кластер — это несколько тысяч серверов.
en.wikipedia.org/wiki/Google_platform
en.wikipedia.org/wiki/Google_platform
из 10 сниплетов, а на моем мониторе 1920x1080 = 2073600 точек.
Кстати делается при этом 1 сик на одно слово каждой машиной кластера (в параллель), дома у нас 1 компьютер, а не кластер. Там как раз данные хранятся по одному слову по порядку: спросил «фото», вот в индексе подряд и идут документы про фото: 318209092, 4928403092, 43898349, 4938493843 и т.п…
Проблема в том, что пространственные данные так особо не похранишь — луч взгляда может пройти по бесконечному количеству направлений. Каждое предположительное направление взгляда — размер индекса растет на изначальный размер объема данных.
Я не спорю, что что-то они придумали. Я спорю с тем, что объемы тут такие большие, что либо это что-то супергениальнейшее, что обходит миллионы подводных камней, в том числе и объемы данных, которые нужны для этого, либо все-таки какие-то хитрости при демонстрации тут. И второе с чем я спорю — что игровой индустрии эта технология не нужна, особенно при приближающемся tesselation.
Проблема в том, что пространственные данные так особо не похранишь — луч взгляда может пройти по бесконечному количеству направлений. Каждое предположительное направление взгляда — размер индекса растет на изначальный размер объема данных.
Я не спорю, что что-то они придумали. Я спорю с тем, что объемы тут такие большие, что либо это что-то супергениальнейшее, что обходит миллионы подводных камней, в том числе и объемы данных, которые нужны для этого, либо все-таки какие-то хитрости при демонстрации тут. И второе с чем я спорю — что игровой индустрии эта технология не нужна, особенно при приближающемся tesselation.
Проблема в том, что пространственные данные так особо не похранишь — луч взгляда может пройти по бесконечному количеству направлений. Каждое предположительное направление взгляда — размер индекса растет на изначальный размер объема данных.Это вам так кажется. Именно поэтому не вы придумали эту технологию. В революционных технологиях или алгоритмах вся прелесть в том, что никто до этого не считал это возможным. Но нашлись люди, проделавшие колоссальную работу, и заставившие невозможное свершиться.
Так что не надо тут про сканирование 30 гб информации, там явно не дураки работают.
Судя по описанию UD, их концепция будет непригодны для динамических сцен и динамического освещения.
Интересно, а возможно ли совместить эту UD технологию и ту, что есть сейчас? Скажем, сцена полигональная, но те объекты, которые требуют детализации отрисовываются UD. Раньше, например, использовался заранее отрисованый «задник»-картинка, по которому ползала 3Д-модель (Alone in the Dark, к примеру) Таким образом не нужно будет рассчитывать расположение каждого пиксела.
Не совсем понял про 1024х768 и отображение только 786000 точек.
В любом случае возникает ситуация когда в одну экранную точку должно проецироваться более чем одна реальная (например объект уходящий вдаль), их цвета придется смешивать. Если этого не сделать — будет каша как в старых играх на текстурах без билинейной/трилинейной/анизотропной фильтрации. И получается больше чем 1024х768 точек. В худшем случае (плоскость уходящая в бесконечность) придется считать все точки попавшие в камеру. Или я чего то не понимаю?
В любом случае возникает ситуация когда в одну экранную точку должно проецироваться более чем одна реальная (например объект уходящий вдаль), их цвета придется смешивать. Если этого не сделать — будет каша как в старых играх на текстурах без билинейной/трилинейной/анизотропной фильтрации. И получается больше чем 1024х768 точек. В худшем случае (плоскость уходящая в бесконечность) придется считать все точки попавшие в камеру. Или я чего то не понимаю?
Меня немного смутил тот факт, что в их сценах огромное количество одинаковых элементов. Возможно, 32GB оперативки и не нужно, если сделать одну модельку из миллиона этих «атомов», а потом клонировать ее бесчисленное множество раз.
А насчет «3D-аниматоры мыслят полигонами, нет алгоритмов сжатия облака точек, нет софта» — когда-то ведь и того, что сейчас есть, не было, а была только консоль и ascii-графика, но появились возможности, а вместе с ними и инструменты / специалисты.
А насчет «3D-аниматоры мыслят полигонами, нет алгоритмов сжатия облака точек, нет софта» — когда-то ведь и того, что сейчас есть, не было, а была только консоль и ascii-графика, но появились возможности, а вместе с ними и инструменты / специалисты.
Как я понял, суть посыла ребят в том, что разработчики софта и железа слишком увлеклись полигональным моделированием. Полигон — способ быстрой отрисовки однородной поверхности. Грабли были с самого начала, но грабли эти обходили хаками и затычками:
Кривую не нарисовать — хорошо, будем делить треугольник и мельчить сетку — железо не справляется — повысим частоту!
Однородные поверхности невыразительны — натянем на них текстуру. А если поверхность наклонить? Текстуру будем тоже крутить. А не понятно, что там за текстура — а мы повысим разрешение текстуры… Так пропадает же половина разрешения на текстуре — на тех точках, что дальше, а те, что ближе всё равно видны как многоугольники — а мы увеличим память под текстуры и повесим на текстуру фильтрацию.
А всё равно всё плоское — а мы сделаем «дисплейсмент» и добавим конвейеров в видеокарту, а всё равно углы плоские! — а мы опять «оттеселируем» по полной и добавим тактовой частоты.
А края полигонов с зазубринами получаются — хорошо, мы будем их размыливать… А у меня уже видюха греется — хорошо, мы поставим на неё жидкостное охлаждение.
А мы хотим тени — хорошо, на текстуру положим ещё одну текстуру и добавим ещё конвейеров и видеопамяти, а мы хотим динамические тени! — хорошо, положим сверху ещё полигончиков и т.д.
Т.е. в результате получаем очень много полигонов, на которые за много проходов рисуется избыточный (и это самое главное) массив точек. Если у ребят реально получилось убрать все грабли одним движением — напрямую рисовать точки, без привязки к треугольнику — то хорошо, если нет, то будем ждать следующих )
Кривую не нарисовать — хорошо, будем делить треугольник и мельчить сетку — железо не справляется — повысим частоту!
Однородные поверхности невыразительны — натянем на них текстуру. А если поверхность наклонить? Текстуру будем тоже крутить. А не понятно, что там за текстура — а мы повысим разрешение текстуры… Так пропадает же половина разрешения на текстуре — на тех точках, что дальше, а те, что ближе всё равно видны как многоугольники — а мы увеличим память под текстуры и повесим на текстуру фильтрацию.
А всё равно всё плоское — а мы сделаем «дисплейсмент» и добавим конвейеров в видеокарту, а всё равно углы плоские! — а мы опять «оттеселируем» по полной и добавим тактовой частоты.
А края полигонов с зазубринами получаются — хорошо, мы будем их размыливать… А у меня уже видюха греется — хорошо, мы поставим на неё жидкостное охлаждение.
А мы хотим тени — хорошо, на текстуру положим ещё одну текстуру и добавим ещё конвейеров и видеопамяти, а мы хотим динамические тени! — хорошо, положим сверху ещё полигончиков и т.д.
Т.е. в результате получаем очень много полигонов, на которые за много проходов рисуется избыточный (и это самое главное) массив точек. Если у ребят реально получилось убрать все грабли одним движением — напрямую рисовать точки, без привязки к треугольнику — то хорошо, если нет, то будем ждать следующих )
Один незахабренный человек очень просил передать в сии комменты свое мнение:
[11:01:12] Всем, привет. На хабре идёт бурное обсуждение Unlimited Detail. Я считаю что данная технология возможна.
[11:01:12] Этот движок — попытка реализовать SVO-voxel-raycasting. В документе Olick'а «Current and next generation parallelism in games» объясняется данная технология.
[11:01:12] А именно: 1. Voxel Oct-tree; 2. Compression (72bit per Node); 3. Automatic LOD;
[11:01:12] А гугл и тытуб помогут найти более хорошие реализации… (с DoF, AO, Soft Shadows)
[11:01:12] Всем, привет. На хабре идёт бурное обсуждение Unlimited Detail. Я считаю что данная технология возможна.
[11:01:12] Этот движок — попытка реализовать SVO-voxel-raycasting. В документе Olick'а «Current and next generation parallelism in games» объясняется данная технология.
[11:01:12] А именно: 1. Voxel Oct-tree; 2. Compression (72bit per Node); 3. Automatic LOD;
[11:01:12] А гугл и тытуб помогут найти более хорошие реализации… (с DoF, AO, Soft Shadows)
Nakilon, mikhanoid, большое cпасибо за инвайт.
По теме:
Текущий pseudo-подход к рендеру mesh-ей:
А что если, пойти обратным путём:
Это достигается путём:
Те. мы работаем не с Mesh'ем, а с его Octtree представлнием.
Дерево можно сильно сжать с помощью RLE-like преобразований.
Ссылки:
Сайт с документацией от сотрудника NVidia Research...
Инфа по движку GigaVoxels
Видео по GigaVoxels
Сайт VoxLOD'а
Видео по VoxLOD
Спасибо за внимание.
P.S. Первый коммент. Чувствую, что где-то сильно накосячил.
По теме:
Текущий pseudo-подход к рендеру mesh-ей:
- a) прикинуть LOD-ы моделей
- b) загрузить выбранные LODы (или просчитать их)
- c) с помощью occlusion culling алгоритмов отбросить ненужные полигоны
- d) оставшиеся полигоны (полигон — часть плоскости, с бесконечным количеством точек внутри себя) преобразовать в конечное число пикселей на экране (рендер)
- e)post-processing
А что если, пойти обратным путём:
- a) для каждой точки экрана сразу определим цвет, глубину, нормаль...
- b) просчитаем освещение и тени
- c) выведем данную точку на экран
Это достигается путём:
- a) деление mesh'а алгоритмом octtree на конечное количество кубов.
Количество кубов зависит от сложности модели и необходимой детализации. Для статичных моделей производится заранее и требует много места на диске.
Каждый куб содержит информацию о «детях» (1-byte), цвете(4), нормали(3) и specular power(1) - b) (Multi-Core)Определить куб для данного пикселя экрана путём Ray-Casting'а по Octtree дереву. Также получаем доп. параметр — глубина
- c) Расчитать освещённость и тени
- d) Post-processing
Те. мы работаем не с Mesh'ем, а с его Octtree представлнием.
Дерево можно сильно сжать с помощью RLE-like преобразований.
Ссылки:
Сайт с документацией от сотрудника NVidia Research...
Инфа по движку GigaVoxels
Видео по GigaVoxels
Сайт VoxLOD'а
Видео по VoxLOD
Спасибо за внимание.
P.S. Первый коммент. Чувствую, что где-то сильно накосячил.
P.P.S. Проект на Code.Google
Приветствуем на Хабре,
хотя конечно надо бы Вам подетальней объяснить что Вы имели в виду, даже я (автор статьи выше) некоторые моменты плохо понял.
В общем-то вот это видео по GigaVoxels частично подтверждает мои опасения насчет памяти:
www.youtube.com/watch?v=HScYuRhgEJw&NR=1
А там всего-то 2048 x 2048 x 2048…
хотя конечно надо бы Вам подетальней объяснить что Вы имели в виду, даже я (автор статьи выше) некоторые моменты плохо понял.
В общем-то вот это видео по GigaVoxels частично подтверждает мои опасения насчет памяти:
www.youtube.com/watch?v=HScYuRhgEJw&NR=1
А там всего-то 2048 x 2048 x 2048…
Вообще-то, ничего не мешает генерировать эти самые октодеревья в runtime из полиогональных моделей. www.tml.tkk.fi/~samuli/publications/laine2010i3d_video.avi вот видео с целым городом.
О! Выглядит впечатляюще… Но… опять же — 2.7ГБ данных на одну маленькую, в общем-то сценку (про церковь)… Такая сценка современными методами (полигоны, текстуры, normal maps) займет… не знаю точно, но то, что раз в 1000 меньше — это точно…
Про город они как-то умалчивают сколько он объема занимает. Хотя выглядит да, действительно хорошо.
Про город они как-то умалчивают сколько он объема занимает. Хотя выглядит да, действительно хорошо.
Зачем тратить циклы на runtime и оптимизацию, если можно заранее просчитать?!
+ драгоценные циклы пойдут на прорисовку динамических объектов
+ драгоценные циклы пойдут на прорисовку динамических объектов
И ещё непонятно, откуда вы взяли 2048^3? Просто они говорят, что это у них самый большой dataset — какой-нибудь томографический скан реального объекта.
Ну тут речь больше о том, что я близок относительно порядка цифр памяти, который требуется для подобных вещей.
Кстати, не то, чтобы придираюсь, но «octree» с одной «t» пишется.
А вообще на эту тему Вам бы лучше топик написать (статью), подробно и это — может прямо как ответ моей — в чем я ошибся и какие на самом деле бывают размеры памяти, откуда берутся нормали и т.п.
А вообще на эту тему Вам бы лучше топик написать (статью), подробно и это — может прямо как ответ моей — в чем я ошибся и какие на самом деле бывают размеры памяти, откуда берутся нормали и т.п.
Мне кажется, что пересказывать статью нет необходимости. А ключевые моменты уже и так отражены в наших комментах.
По поводу объемов:
Как я уже сказал, каждый воксел(куб) в дереве содержит 9 байт информации. (1-children + 4-color + 3-normal + 1-specuar)
Если мы имеем пространство 2048 x 2048 x 2048, то у нас максимум информации ~72Gb.
Допустим, после избавления от «пустых» данных, мы получим ~32Gb. Но ведь это не сжатые данные. и никто не говорит, что нам необходимо их все разом грузить в память.
В презентации Olick'а с SIGGRAPH2008 предложен следующий вариант сжатия:
а. Разделить все данные по слоям детализации.
б. Сжать информацию о детях в данном слое путём RLE-like преобразований.
в. Преобразовать информацию о цвете в дельту к родительскому слою (слайд 167/168 Olick'а) и сжать с помощью RLE
В результате имеем структуру, которую можно stream-ить по мере необходимости. Причём, оффсеты для данных и декомпрессия необходимых значений происходит на лету.
В документе ещё идёт речь о кешировании, но я не вдавался в детали.
Как я уже сказал, каждый воксел(куб) в дереве содержит 9 байт информации. (1-children + 4-color + 3-normal + 1-specuar)
Если мы имеем пространство 2048 x 2048 x 2048, то у нас максимум информации ~72Gb.
Допустим, после избавления от «пустых» данных, мы получим ~32Gb. Но ведь это не сжатые данные. и никто не говорит, что нам необходимо их все разом грузить в память.
В презентации Olick'а с SIGGRAPH2008 предложен следующий вариант сжатия:
а. Разделить все данные по слоям детализации.
б. Сжать информацию о детях в данном слое путём RLE-like преобразований.
в. Преобразовать информацию о цвете в дельту к родительскому слою (слайд 167/168 Olick'а) и сжать с помощью RLE
В результате имеем структуру, которую можно stream-ить по мере необходимости. Причём, оффсеты для данных и декомпрессия необходимых значений происходит на лету.
В документе ещё идёт речь о кешировании, но я не вдавался в детали.
Хмм! Интересно. Да и судя по всему NVidia тоже признает воксели как конкурентную вещь… Единственный вопрос — хоть бы кто показал реальное сравнение — сколько полигональная vs воксельная (сжатая) будет занимать, хотя бы в теории. Может есть где?
Вот теор инфа (olick слайд 170):
Data Storage Size
• 1.15 bits of positional data per voxel
•Cost savings improves as triangle size decreases.
•160 bits per triangle in traditional format
–x,z,y,s,tall 32-bits
-2.2:1 ratio
•80 bits per triangle in compressed format
–x,y,z,s,tall 16-bits
-1.1:1 ratio
•72 bits equivalent per triangle in oct-tree
–(for next generation)
Data Storage Size
• 1.15 bits of positional data per voxel
•Cost savings improves as triangle size decreases.
•160 bits per triangle in traditional format
–x,z,y,s,tall 32-bits
-2.2:1 ratio
•80 bits per triangle in compressed format
–x,y,z,s,tall 16-bits
-1.1:1 ratio
•72 bits equivalent per triangle in oct-tree
–(for next generation)
Еще правда пару вещей не понял про байты:
1-children — это что за байт?
3-normal — по-моему должно быть 3*4=12-normal (float'ы же)
А вообще интересно — я как-то и не задумывался что можно не отдельными точками хранить, а именно кубиками. Тогда и сглаживание куда проще получается.
Интересные мысли :) добавляю Вам кармы :)
1-children — это что за байт?
3-normal — по-моему должно быть 3*4=12-normal (float'ы же)
А вообще интересно — я как-то и не задумывался что можно не отдельными точками хранить, а именно кубиками. Тогда и сглаживание куда проще получается.
Интересные мысли :) добавляю Вам кармы :)
1-children: каждый куб имеет 8-детей, по биту на каждого
Как-то странно. Разве скорее не «указатель» на каждого должен быть?
Для хранения — в этом нет необходимости, а для runtime-а, они просчитаются.
И все же думаю статейку с пересказом Olickа надо бы :) Я бы сам с удовольствием почитал.
Я буду рад её почитать, если автором будете Вы. тк именно Ваша статья подтолкнула меня написать коммент. )
То о чем я писал — я хоть понимаю, Olicka сейчас читаю склонив голову набок :))
Попутно еще вот это читаю — там как раз кто-то из авторов этого paper участвует и про unlimited detail пошли. И поднимают интересные вопросы — например по поводу построения octree для анимаций…
ompf.org/forum/viewtopic.php?f=3&p=8319
Попутно еще вот это читаю — там как раз кто-то из авторов этого paper участвует и про unlimited detail пошли. И поднимают интересные вопросы — например по поводу построения octree для анимаций…
ompf.org/forum/viewtopic.php?f=3&p=8319
В этом документе идёт описание построение отражений с использованием тех-же Octree.
Вся прелесть всего этого SVO безобразия в скорости Ray Tracing'а
Вся прелесть всего этого SVO безобразия в скорости Ray Tracing'а
Всё проще. 1 означает, что дочерний кубик чем-то заполнен.
Это я понял — но где его искать-то, этот дочерний кубик. Но ладно, это уже формат хранения данных — тут вопрос чисто технический и уверен — решаемый одним или другим вариантом.
Этот кубик мы найдем только после декомпрессии очередного слоя детализации, в котором мы имеем по 9 байт на кубик… итого если у нас у родителя байт children = 01000100, то в дочернем слое мы имеем два кубика по 9 байт… а зная последовательность в байте children, я знаю, какая именно «девятка» мне нужна.
Normal map — текстура, в RGB — хранятся X,Y,Z => 3-байта для нормали
Судя по этой статье, 2048^3 можно хранить в 70Mb. (dataset=hash+offset=dataset)
А вот ещё один фокус (правда оффтопик): 3D в 2D в 3D(поиск оптимального «скальпеля» и выворачивание mesh в bmp)
Здесь инфа по Volume (voxel) Ray-Casting'у
А вот ещё один фокус (правда оффтопик): 3D в 2D в 3D(поиск оптимального «скальпеля» и выворачивание mesh в bmp)
Здесь инфа по Volume (voxel) Ray-Casting'у
Насчёт редакторов всё просто — можно преобразовывать другие форматы в облако точек — да те же тесселированные полигоны. Было бы желание.
Хммм… оказывается Unlimited Detail нашли свой способ еще 2 года назад…
Судя по гугло коду, ребята из NVidia принялись за работу в феврале этого года
Знаешь, у меня тут идейка появилась… мне кажется, что ребята из Unlimited Detail, для ускорения процесса сделали небольшой хак.
Что лучше всего использовать для рендера?!.. Правильно!!! СФЕРЫ.
ИМХО: Они используют Octree для поиска и сферы описаные вокруг куба для рендера. Отсюда и software-mode с ~10-30fps. Может и ошибаюсь.
Что лучше всего использовать для рендера?!.. Правильно!!! СФЕРЫ.
ИМХО: Они используют Octree для поиска и сферы описаные вокруг куба для рендера. Отсюда и software-mode с ~10-30fps. Может и ошибаюсь.
Честно — я даже предполагать не стану что там они сделали :)
Угадать будет трудно — вполне возможно что угодно. Мне больше интересно — сможет ли индустрия основанная на полигонах — повернутся на это, станет ли она это делать и лучше ли будут выглядеть игры.
Угадать будет трудно — вполне возможно что угодно. Мне больше интересно — сможет ли индустрия основанная на полигонах — повернутся на это, станет ли она это делать и лучше ли будут выглядеть игры.
Чтобы ответить на этот вопрос, надо прикинуть, а что сейчас мешает делать всё это в runtime?
Мне кажется, что данная технология позиционируется именно для static mesh, так как можно грузить данные, которые были просчитаны заранее.
Хммм… а что если для статик меша подсчитать не 15-20 уровней детализации, а первые 5-10 и в последние кубы вложить информацию о полигонах… и при необходимости, как раз в runtime, просчитывать локальный octree. Такой подход уменьшит кол-во мегабайт pre-computed octree…
Вроде данный подход имеет место быть…
Мне кажется, что данная технология позиционируется именно для static mesh, так как можно грузить данные, которые были просчитаны заранее.
Хммм… а что если для статик меша подсчитать не 15-20 уровней детализации, а первые 5-10 и в последние кубы вложить информацию о полигонах… и при необходимости, как раз в runtime, просчитывать локальный octree. Такой подход уменьшит кол-во мегабайт pre-computed octree…
Вроде данный подход имеет место быть…
> Нормали, конечно, могут быть, просто их откуда-то надо взять, а для этого должны быть треугольники или полигоны.
Или еще одна «координата» у точки. 4 байт будет достаточно для кодирования такой координаты. По сути, это радиус-вектор в сферической системе коодинат, ему хватит и 3 байт для неплохой точности (256 отсчетов по окружности в каждой плоскости).
Или еще одна «координата» у точки. 4 байт будет достаточно для кодирования такой координаты. По сути, это радиус-вектор в сферической системе коодинат, ему хватит и 3 байт для неплохой точности (256 отсчетов по окружности в каждой плоскости).
> Конечно, в видео мы видим отражение (а-ля Quake 1 :)) в озере. Но разрабы признаются, что они сжульничали и на самом деле сцена двойная — одна вверх, другая вниз. Правда такой примитивный эффект (отражение от плоскости) можно было бы и математически просто рассчитать. Другой вопрос — уже привычная «рябь»… тут ее уже так просто не рассчитать процессором — время нужно на трассировку луча
Ничего они не сжульничали. Они просто применили обратный райтрейсинг после вычленения нужных пространственных точек. В их случае обратный райтрейсинг для каждой точки экрана работает на 100% и без дополнительных расчетов по поиску пересечения луча с поверхностью. Это возможно, так как на первом этапе пространственные точки, через которые проходят лучи от пикселей монитора, уже известны. А в обратном райтрейсинге именно поиск пересечений лучей с поверхность занимает 99% вычислительного времени.
В обратном райтрейсинге тени получаются «бесплатными», а отражения делаются итеративным заворачиванием алгоритма. Учитывая, что пространственные точки известны, и их всего то 800 тыщ, и тени и отражения считаются влет.
Вообще в nvidia походу пока что плохо осознают, что достаточно появиться такому _алгоритму_, и при соответсвующей мощности процов видяхи с их полигонами станут ненужны. Я это жду уже 15 лет, походу, скоро время придет.
Похожая технология, кстати, уже работала в 2003 году. Вот демка под винду www.demoscene.ru/demo/dl_demo1.php3?208. Там райтрейсинг комбинирован с текстурами. И пашет на ура на даже на Cel 1.5GHz.
Ничего они не сжульничали. Они просто применили обратный райтрейсинг после вычленения нужных пространственных точек. В их случае обратный райтрейсинг для каждой точки экрана работает на 100% и без дополнительных расчетов по поиску пересечения луча с поверхностью. Это возможно, так как на первом этапе пространственные точки, через которые проходят лучи от пикселей монитора, уже известны. А в обратном райтрейсинге именно поиск пересечений лучей с поверхность занимает 99% вычислительного времени.
В обратном райтрейсинге тени получаются «бесплатными», а отражения делаются итеративным заворачиванием алгоритма. Учитывая, что пространственные точки известны, и их всего то 800 тыщ, и тени и отражения считаются влет.
Вообще в nvidia походу пока что плохо осознают, что достаточно появиться такому _алгоритму_, и при соответсвующей мощности процов видяхи с их полигонами станут ненужны. Я это жду уже 15 лет, походу, скоро время придет.
Похожая технология, кстати, уже работала в 2003 году. Вот демка под винду www.demoscene.ru/demo/dl_demo1.php3?208. Там райтрейсинг комбинирован с текстурами. И пашет на ура на даже на Cel 1.5GHz.
Вообще, NVidia думает об этом, см. публикации 2010
www.nvidia.com/object/nvidia_research_publications.html
А вот насчет того, что не нужны будут — это совсем не факт, я это в статье и объяснял — слишком большая ща инфраструктура вокруг полигонов — она так просто не сдастся — сейчас все заточено под полигоны и ничего под воксели.
www.nvidia.com/object/nvidia_research_publications.html
А вот насчет того, что не нужны будут — это совсем не факт, я это в статье и объяснял — слишком большая ща инфраструктура вокруг полигонов — она так просто не сдастся — сейчас все заточено под полигоны и ничего под воксели.
По поводу хранения таких объёмов данных, выше верно уже обсуждалось что можно сжимать.
Кармак в idTech5 тоже реализует, правда для текстур алгоритм сжатия сравнимый с объемами обычных текстур ~20Gb (MegaTexture) + всё это OpenGl
Так что вполне вероятно что Unlimited Detail возможна. всё что сейчас им нужно — качественная игра и формирование игрового комьюнити
Кармак в idTech5 тоже реализует, правда для текстур алгоритм сжатия сравнимый с объемами обычных текстур ~20Gb (MegaTexture) + всё это OpenGl
Так что вполне вероятно что Unlimited Detail возможна. всё что сейчас им нужно — качественная игра и формирование игрового комьюнити
Вообще-то около воксельные технологии давно обкатываются в различных приложениях в том числе и играх
id Software например разрабатывает — ID Tech 6 (информация на WIKI)
id Software например разрабатывает — ID Tech 6 (информация на WIKI)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Unlimited Detail — интересно, но есть у меня вполне конкретные сомнения…