Comments 37
Это слишком хорошо, чтобы быть правдой. Больше похоже на постановку.
Но если это правда, то эта технология может открыть множество возможностей, ИМХО
Но если это правда, то эта технология может открыть множество возможностей, ИМХО
Я подозреваю, что самая главная вещь, которую они не говорят заключается в том, что их алгоритмы могут работать только на статических, предварительно обработанных (упоминается) массивах данных. Это косвенно подтверждается как изначальными демками, так и выбранным направлением для применения технологии — ГИС, где по определению нет realtime обновлений. Так что, извините, никаких постреляшек и RPG не будет.
P.S.: Это всего лишь мои догадки.
P.S.: Это всего лишь мои догадки.
Как бы даже такое узкое применение — это все равно огого как много. Но как-то стремительно не верится, что их чудо-система умеет поверхностно читать с флешки огромные файлы без кэширования и загрузки в раму.
Ну я не спорю. Только чудес тут нет. Скорость чтения с флешки ограничена. Если они опираются на экранные пиксели как на основу, то их алгоритм должен оптимальным образом выбирать нужные воксели для заполнения экрана. С учетом того, что все крутится на центральном процессоре, можно заключить, что алгоритм не такой вычислительно сложный, и все упирается в правильный подбор данных для загрузки.
Если данные организованы таким образом, что координаты экранного пикселя являются достаточной информацией для отсечения ненужных данных, то такое можно представить. Что-то вроде сочетания хеширования с деревьями поиска. Хотя конечно, детали реализации представляют огромный интерес.
Интересно узнать, является ли модель универсальной или она строится под конкретный вьюпорт (1280х1024 например). Можно ли один и тот же файл крутить на устройствах с разными параметрами.
Если данные организованы таким образом, что координаты экранного пикселя являются достаточной информацией для отсечения ненужных данных, то такое можно представить. Что-то вроде сочетания хеширования с деревьями поиска. Хотя конечно, детали реализации представляют огромный интерес.
Интересно узнать, является ли модель универсальной или она строится под конкретный вьюпорт (1280х1024 например). Можно ли один и тот же файл крутить на устройствах с разными параметрами.
Я ни разу не программист, может вы мне подскажете: берем USB 2.0, пиковая практическая скорость чтения ~25mb\sec, отформатирована в NTFS(что тоже замедляет индексацию), на ней лежит файл 100Гб, который мы скидываем в окно вьюера. Что происходит дальше? Вьюер начинает читать файл последовательно и там с первых строк выдаются параметры видимых на старте приложения пикселей? А если сменить угол обзора — он куда поскачет в этом файле читать? Или там все так оптимизировано, что у тебя особо нет вариков — стартовая точка одна, связанные с ней точки перемещения известны, а резко перепрыгнуть в другой конец карты — нельзя?
Random read
Как я понимаю их алгоритм как раз и позволяет определить какой байт файла читать чтобы узнать цвет конкретного пиксела для любого ракурса в пределах сцены.
Фактически — нужно знать где в файле описан пиксел который пересечет произвольная прямая (проекция луча зрения).
Видимо для этого в начале файла размещают индекс, в котором задана в неком виде конфигурация сцены, эта информация держится в памяти, и позволяет рассчитать пересечения для каждой прямой в пределах сцены.
Думаю что используется иерархия объемных блоков. Заголовок файла описывает сцену состоящую из больших блоков, скажем размером с дом. По этой информации можно для любой прямой вычислить какие блоки она пересечет. Эти блоки имеют известные адреса смещений в базе, и в начале каждого блока — идет описание дочерних блоков (размером около метра), это описание позволяет найти пересечения с любой прямой проходящей через данный блок (а не через всю сцену). Внутри них точно также хранятся блоки размером в дециметр, сантиметр, миллиметр, и т.п.
Получается что для одного экранного пиксела нужно произвести не одно, а несколько чтений с диска. Но так как рядом стоящих лучей очень много (мы ведь просчитываем картинку, а не случайные прямые) — то и информацию одного луча можно использовать при просчете соседей.
А если каждый блок будет хранить еще и общий оттенок, то получается нечто вроде jpg сжатия картинки — каждый новый уровень хранит отклонение цвета от родителя и поэтому может хранить не 24 бита, а существенно меньше…
Ну и если у пользователя скорость ограничена — можно смотреть цепочку блоков не до конца, а меньше — качество картинки будет хуже, но и читать с диска придется меньше.
Фактически — нужно знать где в файле описан пиксел который пересечет произвольная прямая (проекция луча зрения).
Видимо для этого в начале файла размещают индекс, в котором задана в неком виде конфигурация сцены, эта информация держится в памяти, и позволяет рассчитать пересечения для каждой прямой в пределах сцены.
Думаю что используется иерархия объемных блоков. Заголовок файла описывает сцену состоящую из больших блоков, скажем размером с дом. По этой информации можно для любой прямой вычислить какие блоки она пересечет. Эти блоки имеют известные адреса смещений в базе, и в начале каждого блока — идет описание дочерних блоков (размером около метра), это описание позволяет найти пересечения с любой прямой проходящей через данный блок (а не через всю сцену). Внутри них точно также хранятся блоки размером в дециметр, сантиметр, миллиметр, и т.п.
Получается что для одного экранного пиксела нужно произвести не одно, а несколько чтений с диска. Но так как рядом стоящих лучей очень много (мы ведь просчитываем картинку, а не случайные прямые) — то и информацию одного луча можно использовать при просчете соседей.
А если каждый блок будет хранить еще и общий оттенок, то получается нечто вроде jpg сжатия картинки — каждый новый уровень хранит отклонение цвета от родителя и поэтому может хранить не 24 бита, а существенно меньше…
Ну и если у пользователя скорость ограничена — можно смотреть цепочку блоков не до конца, а меньше — качество картинки будет хуже, но и читать с диска придется меньше.
У них есть видео с мультиплеером (и бегающими анимированными человечками на точках), правда качество не очень (но точек в них дофига)
Ну а в чем проблема? Оно ищет по огромному массиву данных на HDD для ланшафта. Добавьте к этому кучу малых массивов — моделей игроков заранее оптимизированных под покадровую анимацию (каждый кадр представляет собой уже отдельную прощитанную модель с точками). Итого — после общего прохода, который вычислил точки для ланшафта, проходим по всем динамическим игровым объектам, отсекаем те, которых не видно, потом для каждого объекта получаем тот кадр анимации, в котором он сейчас находится, и повторяем поиск по этому массиву точек, чтоб перекрыть точки ландшафта. У таких моделей минус — прежде чем использовать их точки, придется дополнительно сориентировать их в простарнстве (матричное преобразование координатов каждой точки модели). Зато количество точек меньше на много порядков, они вполне влезут в RAM, да и преобразования такого рода просто созданы для GPU.
Кроме того, давайте прикинем. Они обещали что входные неподготовленные точки «сортируются со скоростью 3.5 миллиарда точек в час».
3500000000 / 60 (мин) / 60 (сек) / 60 (фреймов) = 16203 точки за время 1 фрейма при 60 фреймах в секунду. Пускай даже у нас не весь проц, а только 1 из 4 ядер — 4050 точек за 1 фрейм для неподготовленных объектов.
Из того что я слышал про технологию — в играх скорее возникнут проблемы со световыми эффектами.
Кроме того, давайте прикинем. Они обещали что входные неподготовленные точки «сортируются со скоростью 3.5 миллиарда точек в час».
3500000000 / 60 (мин) / 60 (сек) / 60 (фреймов) = 16203 точки за время 1 фрейма при 60 фреймах в секунду. Пускай даже у нас не весь проц, а только 1 из 4 ядер — 4050 точек за 1 фрейм для неподготовленных объектов.
Из того что я слышал про технологию — в играх скорее возникнут проблемы со световыми эффектами.
Даже если их штука не будет справляться с анимацией для игр, всегда можно воспользоваться гибридным решением. Фон — их метод. Персонажи и весь интерактив — старый ray casting. Совмещение с учётом наложений тоже должно быть решаемо.
ru.wikipedia.org/wiki/%D0%91%D0%B8%D0%BB%D0%BB%D0%B8%D0%BE%D0%BD
Что вы имели в виду?
Какое именно число? Разница в 3 порядка все-таки
Что вы имели в виду?
Какое именно число? Разница в 3 порядка все-таки
В видео об этом говорится на 7:35
У меня нет времени смотреть все видео, и тем более смотреть его со звуком на рабочем месте.
А вы, делая абстракт, если указываете какие-то числа, указывайте их, пожалуйста, однозначно, в общеупотребимых терминах, исключающих двойное трактование.
А вы, делая абстракт, если указываете какие-то числа, указывайте их, пожалуйста, однозначно, в общеупотребимых терминах, исключающих двойное трактование.
В видео говорится именно о миллиардах!
А кто-нить уже покопался в этом uds файле?
http://euclideon-apac-sydney.s3-ap-southeast-2.amazonaws.com/datasets/Kimoto_8cm.uds (607M)
Вы заметили, как отрисовка происходит… Очень напоминает octree и презентацию Jon Olick'а про воксели.
http://euclideon-apac-sydney.s3-ap-southeast-2.amazonaws.com/datasets/Kimoto_8cm.uds (607M)
Вы заметили, как отрисовка происходит… Очень напоминает octree и презентацию Jon Olick'а про воксели.
в данном файле присутствуют вот эти данные
В видео сказано (да и раньше они, помню, говорили), что алгоритм находит 1 нужную точку на каждый пиксель экрана. Интересно было бы увидеть его работу на MacBook с ретиной.
Все выглядит просто замечательно, но когда мы увидим конечный продукт для пользователя с использованием этой технологии?
бла бла бла… бла бла бла…
интересно, возможна ли нестатичная и интеракивная анимация?
может ли эта технология служить для создания игр?
может ли эта технология служить для создания игр?
Рисовать очень много воксельных данных мы научились сравнительно давно. Свежее. Другое дело, что освещение никакое (максимум phong shading), сцена статична и никаких анимаций. Все это интересно, но удручает что без деталей.
Нет там видео… другие ссылки есть?
видео удалено
Если они не жульничают, не умалчивают о проблемах и все действительно так красочно как они описывают, то чуваки заработали себе место в истории ИТ на ровне с БГ и Стивом.
Интересно, получил ли кто-нибудь демку по запросу?
Sign up to leave a comment.
Euclideon «вернулись» с новым видео