Как стать автором
Обновить

Unlimited Detail — интересно, но есть у меня вполне конкретные сомнения…

Работа с 3D-графикой *
Несколько дней назад проскочило видео по Hacker News (и спасибо ayambit за напоминание о них на Хабре) про компанию Unlimited Detail, которая обещает сделать самые современные карточки NVidia и ATI бесполезными и рендерить сцены в миллиарды точек на обычном процессоре (CPU), без 3D ускорения(!) вообще. Превышая возможности современных видеокарт в сотни раз (тысячи, по заявлениям авторов, которые я ниже оспорю).

Если кто еще не видел:



Сначала на всякий случай о том чего это такое, а потом о том, что у меня, как у программера, сомнения вызывает, что на нетбуках без 3D карт, скоро будут в Crysis 3 играть…

(дальше очень много слов и технических деталей)


Unlimited Detail


Итак, увлекаясь всякими алгоритмами графики и компьютерного зрения и будучи достаточно знаком с OpenGL — меня это все действительно заинтересовало. О чем рассказывается в ролике? Что обычная графика, как она есть сейчас — состоит из полигонов — плоских поверхностей. Чем лучше Ваша карточка, тем больше полигонов она сможет отрисовать. Но реальные предметы часто округлые, в результате, будучи построенными из ограниченного набора полигонов — они кажутся угловатыми (примеры с горшками, люками, камнями и травой в видео) и хотя есть методы, позволяющие обойти в некотором смысле эти ограничения — в них есть свои проблемы.

По-старинке, методами OpenGL 3 / DirectX11 — parallax mapping, tesselation


Один из методов обхода ограничения плоскости полигонов — parallax mapping. О нем говорят разработчики в видео.


Проблема очевидна — край все равно остается прямой линией. Плюс это дает большую нагрузку (из-за расчетов шейдеров) на видеокарту, так что ими не поувлекаешься.

Второй вариант — tesselation. Это уже куда более продвинутый метод из области DirectX 11 (и OpenGL 3, у которого кстати сегодня принята аж 4 версия) — но тут видео стоит сотни слов:

Как видно — камни «честно» выступают на углу. Правда демка (если память не изменяет) под high-end карточку — GeForce 28x... под GF100 ( GeForce GTX 4x0 ) и ATI R800 ( Radeon 5xxx ) (спасибо infi за поправку)

В общем-то tesselation на современных платах позволяет обойти во многом ограничения полигонов практически настолько же, насколько Unlimited Detail (UD). Об этом правда не говорят авторы в видео.

Что сделала Unlimited Detail?


Ладно, возвращаемся к нашим UD. Итак, авторы заявляют, что разработали алгоритм поиска, который позволил им рендерить в реальном времени сцены с миллиардами(!) точек. Растеризуется (рендерится) именно точечное облако (point cloud), проще говоря — нет треугольников, есть только много-много-много мелких точек.

Для сравнения я как-то проводил тестирование относительно современной карточки (8600GTS) и она смогла рендерить на 24 fps только 10 миллионов точек. UD заявляет миллиарды(!), то есть 8600ых нужно 100 штук купить. При том, что рост производительности видеокарт составляет всего 22% в год (по данным UD в видео) — ждать аналогичного FPS от 3D ускорителей нам придется долго. (23 года вроде получается? 1.22**23 = 100)

За счет чего у UD скорость? За счет того, что у Вас на экране всего допустим 1024x768 = 786000 точек. Если мы будем знать какая конкретная 3D точка — какой на плоском мониторе соответствует — то нам надо всего-то 786000*25=20 миллионов операций в секунду. Современный процессор может до 3 миллиардов делать. Так что в приниципе — возможно и на процессоре. Но вот какая штука — до сих пор никто толком не нашел алгоритма, чтобы точно вычислять этот минимальный набор точек.

В современных играх используется так называемый occlusion culling.



Как можно заметить, когда включается сетка — часть домов просто пропадает (не рисуется). На более продвинутом уровне culling работает на уровне буквально полигонов — скрывая все те, что не будут видны (закрыты чем-то, позади, вне поля зрения, хотя последние два это немного другой и очень старый culling — frustum culling).

Так вот — по сути авторы UD изобрели такой алгоритм, но только для точек. То есть он позволяет найти минимальное количество точек, которое нужно отрисовать и показывать только их. Тот же occlusion culling, но на уровне пикселей — какой каким закрыт будет.

Казалось бы — счастье есть! Трава перестанет быть плоской, будут все веточки видны, и даже шпалы станут выпуклыми.

Ну что ж, товарищи тунея… инженеры-программисты… давайте теперь включать мозги и разбираться что тут не так… (есть у меня сомнения)…

Что-то здесь не так...


Во-первых, как и говорится в видео — NVidia и ATI не очень-то жаждят эту технологию. Оно казалось бы и понятно — кому они нужны будут с карточками за 1000$ каждые 2 года, когда все будут на CPU играть. Но с другой стороны — почему бы не купить и не похоронить? Видимо не волнуются. А почему?

Так… попробуем подумать. 20 миллионов операций нам нужно для того, чтобы 1024x768 играть на 25 fps. Современный проц делает 3 миллиарда операций, значит на _поиск_ и отрисовку одной точки у нас должно уходить не более 150 команд низшего уровня. Ладно, допустим отрисовка — это по сути перемножение на матрицу 4x4 и еще там деление. Допускаем, что это возможно, но приходим к поиску.

Итак, 2 миллиарда пикселей, как они говорят, среди которых нужно искать…

1. Куда все это Вы запихали?


У нас нет каких-то популярных алгоритмов сжатия облаков точек (как для картинок — JPG, DDS и т.п.), значит все точки храним в памяти. Далее речь идет про сцену в джунглях, где мало повторяющихся элементов. 2 млрд точек * (4 байта(float) * 3 координаты + 3 цвета * 1 байт(uint8)) = 30 гигабайт оперативки… так, это у нас явно не влезет в домашний комп…

Ну уж для совсем полной паранойи: заметьте, что сценка в джунглях (2млрд точек, 30гигов в теории) — она мааааалюсенькая по сравнению с любым уровнем в том же Crysis, который раз в 100 может быть больше. Так что теоретические 30 гигов умножайте возможно на 100… или будем при каждом выходе с каждой поляны ждать подгрузки новых 30 гигов новой поляны (при скорости винчестера в 30МБ в секунду = 1000 секунд или 16минут на каждую полянку). :) Как в старые добрые времена самых первых игр — 10 шагов… «загрузка....»

Какие есть варианты? Винчестеры — они большие, 30 гигов не вопрос… Они строят какой-то индекс и хранят его в памяти, данные 30 гигов хранятся на винчестере, и к ним обращение идет по мере надобности… тут у меня возникают вопросы. Любое обращение к винчестеру (random seek) — это 9ms — то есть всего лишь сотня чтений в секунду. То есть не более 4 поисков на один кадра.

А если присмотреться к видео — то random seek (чтение не по порядку) будет требоваться по-любому, потому что одни «слоны» близко к камере, другие на фиг знает каком расстоянии. То есть любое движение чуть влево-чуть вправо и нам требуется опять прочитать пусть не очень большое количество (768 000 точек максимум), но разбросанных по 30гиговому файлу точек. Если бы эти точки все подряд были записаны — проблемы нет — современные домашние винчестеры десятки мегов в секунду читают по порядку, но вот случайное чтение — у них до сих пор беда… а у нас всего 4 поиска на целый кадр (760 тысяч точек в 4 запроса по сути надо прочитать).

Так что тут мы утыкаемся в два вопроса — где это все хранится и как воспроизводится… скорее всего девелоперы используют машины с деятками гигов оперативы и данные все в памяти. Но у нас с Вами десятков гигов нет.

Конечно, помнится Elite для Spectrum почти безграничную вселенную запихала в 64Кб, а theprodukkt Fabrausch целый город в 181 тысячу байт запихнули (очень хитрож..умным способом). Но что-то мне подсказывает, что метод процедурных текстур тут не особо спасет авторов.

2. Наработки, 3D художники, безработица, бунты...


Наработки. Все технологии до сих пор были рассчитаны на полигоны. Все 3D редакторы (за исключением специфических, с которыми я хоть и работал, но их даже названия никому ничего не скажут) рассчитаны на полигоны. Все 3d-художники думают полигонами (конечно zBrush меняет немного сцену игры, но все равно изначально работа идет с низкополигональной моделью). Все текстурщики привыкли работать с полигональными моделями… все алгоритмы оптимизации моделей рассчитаны на полигоны… все алгоритмы сжатия рассчитаны на плоские текстуры (JPG, DDS).

Просто нет достаточно ни средств обработки облаков точек, ни людей умеющих в них рисовать, ни алгоритмов сжатия. Там показывается в видео небольшая сцена, которая, как мы выяснили я предполагаю выше займет (только она!) 30 гигов места… а алгоритмов сжатия такого рода данных особо и нет!

Конечно разработчики говорят о том, что можно брать обычные модели и переводить их (с текстурами) в point cloud, но признаются, что пока этого не сделали. Это может решит проблему отсутствия художников, но не решит проблему сжатия и объема.

3. Нам не нужны никакие блики и отражения, будем играть в Дум!


Разработчики и говорят, что «не обращайте внимания на мерцающие тени — это мы недоотладили shadow map» (в принципе, речь идет о параметрах shadow mapping — тут понятно, их нужно тюнинговать под конкретные сцены), но проблема все же имеется. В частности — почти все что Вас впечатляет в современных играх — это шейдеры. Любой блик — результат работы шейдера. А у шейдеров одной из основных входных вещей для него является нормаль точки на поверхности. (рисунок) Вот эта стрелочка (только в каждой точке треугольника) и является определяющая насколько «блик» в ней сильный. Именно от нее пляшет тот же displacement mapping, отражения(особенно!) и преломления света.

Теперь проблема. У точки в точечном облаке НЕТ НОРМАЛИ… некуда у нее стрелку провести — она просто точка. Для нормали ей нужно знать хотя бы две другие точки, с которыми она будет образовывать поверхность (ну или направление нормали). Поэтому она не может отражать, преломлять, отсвечивать и т.п. Проще говоря настоящее точечное облако не может даже представить собой глянцевый пластик (или даже не идеально матовый пластик) — блики исключены — их просто не рассчитать. Поэтому все что Вы видите на видео — в общем-то матовое — никаких бликов.

На самом деле тут я немного вру — и конечно если использовать старые методы полигонального моделирование — нормали у точек могут быть. Но в честном облаке точек нормалей нет. Нормали, конечно, могут быть, просто их откуда-то надо взять, а для этого должны быть треугольники или полигоны.


Это пример того, что такое вообще облако точек, которое и рендерят Unlimited Detail. Кстати, следует заметить, что это объясняет, что детализация там не «бесконечная». Она конечная, авторы имели в виду, что они могут почти не ограниченный по размерам уровень искать (что, в общем-то, сомнительно).

Отступление почему тени-то работают: С тенями тут все проще делается — сцена рендерится еще раз с точки зрения солнца (невидимо) и сравнивается какие из этих точек («видимые» солнцу) видны и наблюдателю в камеру — те, что видны — светлые (на солнце), те, что не видны — в тени.

Конечно, в видео мы видим отражение (а-ля Quake 1 :)) в озере. Но разрабы признаются, что они сжульничали и на самом деле сцена двойная — одна вверх, другая вниз. Правда такой примитивный эффект (отражение от плоскости) можно было бы и математически просто рассчитать. Другой вопрос — уже привычная «рябь»… тут ее уже так просто не рассчитать процессором — время нужно на трассировку луча…

Поэтому от всех классных эффектов типа бликов, отражений — временно придется отказаться (пока не придумают как в реальном времени в облаке точек вычислять нормали точки или между точками) и делать все игры в пасмурной погоде (а-ля Дум, хотя в нем кажется и то уже были отражения...)

Проще говоря смотрим сюда — вот только первые два варианта без нормалей и возможны:


Еще одна проблема — прозрачность. Если UD ищет только БЛИЖАЙШИЙ к камере пиксел который будет виден — то найти какие позади этого ближайшего — может и проблемой быть, не предусмотренной алгоритмом поиска. А именно так прозрачность и работает — 50% переднего пиксела и смешиваем с цветами тех, которые позади.

4. Будет ли Россиянин Американец платить 500$ за торре игру?


Одна из основных проблем сейчас в игровой индустрии, что приходится делать слишком детализированные объекты (я против этого — дайте мне лучше веселую заводную игру с умеренной графикой, чем еще более похожую на реальную жизнь игру… если бы я хотел реальности — я бы пошел на улицу, а не за игрой) Именно из-за этого уже на игры десятки миллионов долларов тратятся… GTA4 — 100 млн. долларов!

Так вот, сейчас углы еще срезаются… хотя нет, наоборот, как раз за счет того, что в играх пока еще есть углы в 3D моделях — цена еще умеренная на разработку объектов. А что если каждый предмет игры придется разрабатывать в zBrush… по точкам… до миллиметриков детализацию доводя… цены на игры еще выше скакнут… конечно, Россию это мало волнует, но тем не менее — это еще один повод, чтобы игровая индустрия сопротивлялась введению таких технологий как Unlimited Detail.

5. AI? Физика? Bones?


Совсем забыл про это сказать тоже… сейчас видеокарты выручают разработчиков тем, что оставляют проц почти свободным для расчета AI и физики (хотя последнее тоже уже на видеокарты перекладывается). В случае же если проц будет заниматься только расчетом графики — AI и физику считать будет уже некому. Так же как так называемый скиннинг — изгиб модели персонажа во время анимации с помощью костей. Этим тоже сейчас либо CPU, либо GPU занимается. А придется все на CPU, который и так уже будет занят.

Так что может за "бесконечную детализацию" без видеоплаты придется платить отупевшим AI и проходящими сквозь землю закостеневшими игроками из-за отсутствия процессорного времени…

Может конечно многопроцессорность выручит, но пока в нынешних реалиях — еще один маленький гвоздик в ногу Unlimited Detail.

В общем...


В общем, видео впечатляет. И я не сомневаюсь, что авторы сделали то, что они показывают. Возможно где-то срезали углы (типа 32gb оперативы), но все же это существует. Тем более, что хакеры из Hacker News раскопали, что авторы UD возможно являются одними из ведущих разработчиков в мире в области алгоритмов (Greg Douglas, возможно тот же, что и имеющий отношение к разработке алгоритма «R-Tree») и имеют опубликованные работы… но вот что-то все-таки (по вышесказанному) я сомневаюсь, что это будет допущено в игровой мейнстрим… (по крайней мере не в ближайшие 16 месяцев, как обещают разрабы Unlimited Detail).

Но, как и в любой хорошей предпринимательской деятельности — чем больше людей говорят, что то, что Вы делаете — невозможно, тем лучший путь (возможно) Вы нашли. Так что может господа из UD нашли как обойти все эти проблемы и эта технология действительно может работать на ноутбуках... Но пока что даже в теории я отмести ни одну из них не могу (… возможно, только про нормали...) и IT-опыт подсказывает что обычно чудес не существует.

И что еще важнее — нету у игровой индустрии такого уж стимула, чтобы принимать эту технологию и переделывать все свои инструменты под нее, переучивать людей и разрабатывать новый алгоритмы сжатия и хранения таких данных, когда с приближающимся уровнем видеокарт детализация на глаз уже неотличима от того, что предлагает UD. А уж визуально демки UD проигрывают почти любой современной игре лет так на 7.

Предсказывать ход истории — дело неблагодарное, никогда не угадаешь куда повернет. Я лишь озвучил теоретические проблемы, которые вижу.

Ну, время покажет…


Йои Хаджи,
вид с Хабра

P.S. Оказывается Unlimited Detail нашли свой способ еще 2 года назад
Теги: unlimited detailграфика3ddirectx 11opengl 3
Хабы: Работа с 3D-графикой
Всего голосов 157: ↑146 и ↓11 +135
Комментарии 210
Комментарии Комментарии 210

Похожие публикации

Лучшие публикации за сутки