- Barbar1an
- Постоялец
запустил ту демку на атлоне3000+ 7600GS выдало 15 фпс
у меня 25 fps стабильно
:-D у меня за сотню на HD4850, от 120 до 150 fps
А если залететь внутрь фракталла(вплотную) то может выдать аж от 200 до 300 фпсов ^_^
полагаю, как только афтар приступит к теням, вся его бодяга накроется тазом.
блин, после консольного флуда демка падает. абыдно :/ win7x64 gf250
neumond
Полагаю одной лопатой в твоём чулане стало больше... :)
кто-нить дайте линк на их демку, не могу найти.
судя по всему её нет..
neumond
> кто-нить дайте линк на их демку, не могу найти.
демки нет и в ближайшее время не предвидится. Возможно увидим новое видео с динамическим светом и анимацией в течение года. Многие уже догадались как они могут сделать правильные тени с адаптивным рендером из положения источника света в меньшее разрешение, и что z-buffer у них есть, если не поленятся может сделают какой-нибудь встроенный шейдер ssao на ассемблере. А демку EXE получим не ранее, чем через год.
Если хочется подумать над тем, как работает алгоритм, нужно внимательнее отнестись к _артефактам_ рендеринга UD:
1. обратите внимание на правый и нижний угол экрана при повороте камеры, в зависимости от угла поворота там есть зигзагообразный край с соответствующим наклоном.
2. присутствует z-fighting. Например, где есть камни и растения, растения на переднем плане иногда исчезают и виден только камень
3. "технический" рендер в зелёной валитре на первом видео - полоса на земле преломляется в середине при повороте камеры вниз
если видео были с более высоким качеством, возможно артефакты рендеринга дали больше идей.
Выскажу несколько предположений по поводу описания алгоритма UD:
1. В главном цикле отрисовки нет делений и умножений + не используется обычные 3D алгоритмы.
А что это значит? А значит то, что нужно забыть про матрицы проекций, умножения и т.п..
Как предположение: Берём в 3D массиве точку наблюдателя Берём в 3D массиве виртуальный экран 1024x768 точек (2D массив). Проводим вектора из точки наблюдения в каждую точку 2D массива, строим look-up таблицу единичных векторов для проецирования на 2D массив. Понятно, что имея такую look-up таблицу можно для каждой точки экрана строить луч, прибавляя в цикле к координатам виртуального экрана единичные вектора и проверяя пересечение с "вокселями". Это будет медленно и не решает всех проблем. Просто как факт - не обязательно каждый раз перемножать что-то на матрицу. А ведь look-up может быть и трёхмерным, тогда можно поворачивать камеру без пересчёта look-up таблицы
2. "But all of this is done by a new sort of method that we call MASS CONNECTED PROCESSING. Mass connected processing is where we have a way of processing masses of data at the same time and then applying the small changes to each part at the end."
Здесь завуалирована суть технологии. Какие-то преобразования вне главного цикла возможно используются по новой. Моё предположение по этому пункту: отрендеренные на экран точки при повороте камеры могут использоваться повторно, так как для каждой точки экрана хранятся x-y-z положение точки в пространстве. А особенно это "MASS CONNECTED". Возможно при относительно небольших поворотах/перемещениях камеры заново ищется только часть точек, а уже существующие на экране точки перетрансформируются и перезакрашиваются с учётом "MASS CONNECTED". Таким образом, перемещаясь по 3D пространству можно наблюдать за объёктом издалека, ввести некий коеффициент плотности облака "POINT CLOUD DATA", и если точек не хватает, проводить дополнительный поиск "вокселей".
3. Данные хранятся хитрым образом
Здесь можно много чего предположить:
- индексация. Возможно некая индексация. Их много, не факт что здесь это применено.
- особый вид LOD с опорными узлами. Опять же отсыл к "MASS CONNECTED", можно часть вокселей детализации хранить в локальных координатах "крупных" вокселей. Это позволит сэкономить на разрядности и виртуально даёт более 32,64,128 и т.д. бит точности в задании положения. Всю сцену можно хранить как некие центры масс объектов, относительно их задавать координаты более мелких центров и т.д.. Опять же всё на уровне предположений.
Предлагаю начать мозговой штурм технологии Unlimited Detail, а не размышлять на тему невозможности и т.п..
Начать с простого - рассмотрим 2D случай. Предположим что мы делаем Unlimited Detail, но не в 3D а в 2D! Экран у нас при этом станет не 1024x768 а одномерным - к примеру 768 пикселей. Теперь нужно задав вектор направления камеры найти способ быстро найти все точки, проецирующиеся на эти 768 пикселей. Если понять как это работает в 2D, то на 3D реализовать будет уже не так сложно. Операции умножения, деления и тригонометрию использовать только на подготовительном этапе, в главном цикле - только сложения и вычитания.
Для затравки новый скриншот в высоком разрешении:
http://www.igrodel.ru/tdg3d/udt.jpg
На видео видны LOD'ы, причём уровней несколько. Также предположительно, что у них "ето" тормозит, когда камера быстро двигается (задержки в видео) - это может косвенно подтверждать идею товарища tmtlib о поиске только части новых точек для рендеринга. Ну и ещё есть предположение, что сцена собрана из некоторого набора базовых объектов-кусков, так как она повсюду сама себя напоминает, как фрактал.
Alexander K
> Также предположительно, что у них "ето" тормозит, когда камера быстро
> двигается (задержки в видео) - это может косвенно подтверждать идею товарища
> tmtlib о поиске только части новых точек для рендеринга.
Это тогда получается что-то наподобие Parallax Occlusion Mapping-а в фуллскрине, только честного.. Может и так, а может и тормоза свопа Windows. По идее если программа жрёт много памяти, пусть даже меньше, чем установлено на их экспериментальном ноутбуке, винда может поработать диском. Либо чтение с диска.
Попробую развить идею:
Предположим, мы самым медленным ломовым способом найдём 1024x768 точек, которые выводятся на экран для данного положения камеры. У каждого пикселя помимо цвета rgb и глубины z будет некий идентификатор "mass connection", по которому можно узнать принадлежит точка (камню=1 или травинке=2, и т.д.).
Теперь при относительно малых перемещениях камеры мы можем сделать следующее:
1. провести обратное проецирование из экранных x,y + глубина координат в пространственные x,y,z
2. переместить камеру в новое положение
3. спроецировать из нового положения. Разумеется появятся точечные дырки в некоторых местах. Закрасим их на основе буфера принадлежности "mass connection"
Стоит отметить, что так как всё выполняется в софтваре, то не составит труда добавить помимо буфера глубины буфер _не_спроецированных координат. Тогда не нужно обратное проецирование:
1. Долго и упорно ищем точки для вывода на экран для начального положения камеры (1024x768=786432 точек)
2. В главном цикле идёт перемещение камеры
3. Берём x,y,z координаты 1024x768 точек, найденных на предыдущем этапе и проецируем их на экран для нового положения камеры
4. В местах, где образовались пиксельные дырки (ничего не спроецировалось) запускаем алгоритм "долгого и упорного поиска"
но уже не для 786432 точек, а для некоторого N. К примеру это может оказаться 10000 черных пикселей,
тогда мы ускорим процесс, не затрагивая найденных ранее 786432-10000=776432 пикселей, т.е. алгоритм поиска вокселей/атомов потребуется выполнить примерно для 1% от существующих пикселей. Будем приближенно считать скорость зависящей линейно от количества пикселей, тогда
Если полный поиск 786432 точек работает на скорости 0.3 fps,
то поиск 10000 точкек будет уже где-то 30fps
Возможно при таком подходе возникнут кое-какие артефакты....
Ну это всё предположение. Прошу заценить метод.
Идея офигенская, но возможно будут проблемы с фоном. Горизонт, объекты с дырками типа колёс например (дырки появляться не будут). Что-то пока в голову не приходит как это разрешить. И ещё - у них точки действительно маленькие, всё таки есть ещё какие-то хитрости в поиске точек, брутфорсно искать будет очень долго, даже не смотря на такие ухищрения.
Alexander K
> Горизонт, объекты с дырками типа колёс например (дырки появляться не будут).
Я не уловил что-то какие проблемы с фоном и колёсами. Возможно-возможно...
http://news.ycombinator.com/item?id=1179970
Здесь мы видим интересные детали:
The contacts page lists "Greg Douglas" as CTO - sounds like it might be this guy: http://www.doolwind.com/blog/game-developer-spotlight-greg-d...
Also, the same name appears against:
- A C++ R-Tree ( http://en.wikipedia.org/wiki/R-tree ) implementation: http://www.superliminal.com/sources/sources.htm (towards end)
- A contributor to the GameMonkey script engine.
и здесь:
Hi fuba, yes that is me (the same Greg). This interview took place before I was involved with Unlimited Detail. Unfortunately I won’t be able to answer questions about the UD technology or business for a while, but do look forward to doing so in future.
Alexander K
> И ещё - у них точки действительно маленькие, всё таки есть ещё какие-то
> хитрости в поиске точек, брутфорсно искать будет очень долго, даже не смотря на
> такие ухищрения
Понятное дело брутфорс это слишком сурово. Но, как мы видим, в проект влился некий Greg Douglas, который смыслит в деревьях R-Trees. Если на поиск всех точек идёт на скорости хотя бы 1 fps.
И ещё раз про пример:
Если полный поиск 786432 точек работает на скорости 0.3 fps, то поиск 10000 точкек будет уже где-то 30fps
Все дырки-то заново не нужно обрабатывать. Например, одиночные черные пиксели можно проинтерполировать с соседними на основе буфера цвета, глубины и принадлежности, для простоты вообще сложить 8 окружающих пикселей и поделить на 8, либо ещё проще - взять две соседних точки из сканлайна, сложить и поделить на 2. А для скопления незакрашенных пикселей уже производить поиск лучом через соответствующий пиксель экрана. И то - до тех пор, пока не появятся одиночные незакрашенные области - их-то уж как-нибудь можно проинтерполировать.
tmtlib
> Все дырки-то заново не нужно обрабатывать.
Ну это же не коллижн обрабатывать, тут всё равно будут ситуации когда надо абсолютно всё перереднерить, даже как не исключительные, а как рядовые. Сорри что я всё критикую и критикую, не нравится мне это самому, но день сегодня у меня _не_соображабельный_. Идеи хорошие, ты как сам чтобы попробовать наваять что-то?
усе равно, без реально кода... - соображения выглядят как слишком предположительно... тока кодирование выявляет реальные подводные камни...
Извиняюсь за оффтоп и, возможно, повторение высказанных кем-то мыслей, но:
1) Видео очень напоминает воксельную графику, ничего сверхнового в которой нет (поправьте).
2) Почти все сцены состоят из большого числа повторяющихся одинаковых объектов, и таких объектов обычно около десяти. http://unlimiteddetailtechnology.com/attachments/Image/u2008rwalk02.jpg
3) Всё статично и, вероятно, с этим будут проблемы.
Ну и главное:
4) Создание высокой детализации - это интересная техническая задача, но революции не будет. Низкая детализация вылезает на скриншотах, зато в динамической картинке, характерной для игр, она не особо видна. Зато тупящая физика или AI сразу обращают на себя внимание.
P.S. То есть будущее, скорее всего, не за убердетализацией, а за полной разрушаемостью, полной интерактивностью. Сложностью процессов, а не картинки, короче.
Тема в архиве.
