Euclideon «вернулись» с новым видео

    http://www.youtube.com/watch?v=t8rsEJoh6mQ

    Вероятно, все помнят историю с Unlimited detail 2 года назад. После этого было еще одно официальное видео-интервью, и на этом наступила тишина.

    Теперь euclideon (сайт) загрузили новое видео, в котором рассказывают про свою программу — geoverse, которая использует тот самый магический алгоритм поиска вокселя. Данные, полученные с лазерных сканеров местности, сортируются со скоростью 3.5 миллиарда точек в час, сжимаются вплоть до 17% начального размера (в зависимости от желаемого качества), после чего их можно просматривать «прямо с винта» — не загружая полностью все в ram. Так же возможен просмотр данных с флешки, или через интернет — в режиме реального времени. Для медленного интернета предусмотрена особая опция, повышающая разрешение картинки по мере поступления новых данных.

    UPD: На сайте при регистрации можно запросить демо-версию.
    UPD: Обновил ссылку на видео.

    Similar posts

    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 37

      +3
      Это слишком хорошо, чтобы быть правдой. Больше похоже на постановку.

      Но если это правда, то эта технология может открыть множество возможностей, ИМХО
        +5
        Я подозреваю, что самая главная вещь, которую они не говорят заключается в том, что их алгоритмы могут работать только на статических, предварительно обработанных (упоминается) массивах данных. Это косвенно подтверждается как изначальными демками, так и выбранным направлением для применения технологии — ГИС, где по определению нет realtime обновлений. Так что, извините, никаких постреляшек и RPG не будет.

        P.S.: Это всего лишь мои догадки.
          +1
          Как бы даже такое узкое применение — это все равно огого как много. Но как-то стремительно не верится, что их чудо-система умеет поверхностно читать с флешки огромные файлы без кэширования и загрузки в раму.
            +3
            Ну я не спорю. Только чудес тут нет. Скорость чтения с флешки ограничена. Если они опираются на экранные пиксели как на основу, то их алгоритм должен оптимальным образом выбирать нужные воксели для заполнения экрана. С учетом того, что все крутится на центральном процессоре, можно заключить, что алгоритм не такой вычислительно сложный, и все упирается в правильный подбор данных для загрузки.

            Если данные организованы таким образом, что координаты экранного пикселя являются достаточной информацией для отсечения ненужных данных, то такое можно представить. Что-то вроде сочетания хеширования с деревьями поиска. Хотя конечно, детали реализации представляют огромный интерес.

            Интересно узнать, является ли модель универсальной или она строится под конкретный вьюпорт (1280х1024 например). Можно ли один и тот же файл крутить на устройствах с разными параметрами.
              0
              Я ни разу не программист, может вы мне подскажете: берем USB 2.0, пиковая практическая скорость чтения ~25mb\sec, отформатирована в NTFS(что тоже замедляет индексацию), на ней лежит файл 100Гб, который мы скидываем в окно вьюера. Что происходит дальше? Вьюер начинает читать файл последовательно и там с первых строк выдаются параметры видимых на старте приложения пикселей? А если сменить угол обзора — он куда поскачет в этом файле читать? Или там все так оптимизировано, что у тебя особо нет вариков — стартовая точка одна, связанные с ней точки перемещения известны, а резко перепрыгнуть в другой конец карты — нельзя?
                0
                Random read
                  +3
                  Как я понимаю их алгоритм как раз и позволяет определить какой байт файла читать чтобы узнать цвет конкретного пиксела для любого ракурса в пределах сцены.
                  Фактически — нужно знать где в файле описан пиксел который пересечет произвольная прямая (проекция луча зрения).

                  Видимо для этого в начале файла размещают индекс, в котором задана в неком виде конфигурация сцены, эта информация держится в памяти, и позволяет рассчитать пересечения для каждой прямой в пределах сцены.

                  Думаю что используется иерархия объемных блоков. Заголовок файла описывает сцену состоящую из больших блоков, скажем размером с дом. По этой информации можно для любой прямой вычислить какие блоки она пересечет. Эти блоки имеют известные адреса смещений в базе, и в начале каждого блока — идет описание дочерних блоков (размером около метра), это описание позволяет найти пересечения с любой прямой проходящей через данный блок (а не через всю сцену). Внутри них точно также хранятся блоки размером в дециметр, сантиметр, миллиметр, и т.п.
                  Получается что для одного экранного пиксела нужно произвести не одно, а несколько чтений с диска. Но так как рядом стоящих лучей очень много (мы ведь просчитываем картинку, а не случайные прямые) — то и информацию одного луча можно использовать при просчете соседей.
                  А если каждый блок будет хранить еще и общий оттенок, то получается нечто вроде jpg сжатия картинки — каждый новый уровень хранит отклонение цвета от родителя и поэтому может хранить не 24 бита, а существенно меньше…

                  Ну и если у пользователя скорость ограничена — можно смотреть цепочку блоков не до конца, а меньше — качество картинки будет хуже, но и читать с диска придется меньше.
              0
              У них есть видео с мультиплеером (и бегающими анимированными человечками на точках), правда качество не очень (но точек в них дофига)
              0
              Ну а в чем проблема? Оно ищет по огромному массиву данных на HDD для ланшафта. Добавьте к этому кучу малых массивов — моделей игроков заранее оптимизированных под покадровую анимацию (каждый кадр представляет собой уже отдельную прощитанную модель с точками). Итого — после общего прохода, который вычислил точки для ланшафта, проходим по всем динамическим игровым объектам, отсекаем те, которых не видно, потом для каждого объекта получаем тот кадр анимации, в котором он сейчас находится, и повторяем поиск по этому массиву точек, чтоб перекрыть точки ландшафта. У таких моделей минус — прежде чем использовать их точки, придется дополнительно сориентировать их в простарнстве (матричное преобразование координатов каждой точки модели). Зато количество точек меньше на много порядков, они вполне влезут в RAM, да и преобразования такого рода просто созданы для GPU.

              Кроме того, давайте прикинем. Они обещали что входные неподготовленные точки «сортируются со скоростью 3.5 миллиарда точек в час».

              3500000000 / 60 (мин) / 60 (сек) / 60 (фреймов) = 16203 точки за время 1 фрейма при 60 фреймах в секунду. Пускай даже у нас не весь проц, а только 1 из 4 ядер — 4050 точек за 1 фрейм для неподготовленных объектов.

              Из того что я слышал про технологию — в играх скорее возникнут проблемы со световыми эффектами.
                0
                Даже если их штука не будет справляться с анимацией для игр, всегда можно воспользоваться гибридным решением. Фон — их метод. Персонажи и весь интерактив — старый ray casting. Совмещение с учётом наложений тоже должно быть решаемо.
              0
              ru.wikipedia.org/wiki/%D0%91%D0%B8%D0%BB%D0%BB%D0%B8%D0%BE%D0%BD
              Что вы имели в виду?
              Какое именно число? Разница в 3 порядка все-таки
                0
                В видео об этом говорится на 7:35
                  +1
                  У меня нет времени смотреть все видео, и тем более смотреть его со звуком на рабочем месте.
                  А вы, делая абстракт, если указываете какие-то числа, указывайте их, пожалуйста, однозначно, в общеупотребимых терминах, исключающих двойное трактование.
                    +2
                    В видео говорится именно о миллиардах!
                  +5
                  А кто-нить уже покопался в этом uds файле?
                  http://euclideon-apac-sydney.s3-ap-southeast-2.amazonaws.com/datasets/Kimoto_8cm.uds (607M)

                  Вы заметили, как отрисовка происходит… Очень напоминает octree и презентацию Jon Olick'а про воксели.
                    0
                    в данном файле присутствуют вот эти данные
                    0
                    В видео сказано (да и раньше они, помню, говорили), что алгоритм находит 1 нужную точку на каждый пиксель экрана. Интересно было бы увидеть его работу на MacBook с ретиной.
                      0
                      увидеть его работу на MacBook с ретиной


                      Там рабочее разрешение даже до HD не тянет, а физическое этому движку ничего бы не дало, раз использовать нельзя.
                        0
                        ничего не мешает включить на ретине native разрешение
                      +4
                      Все выглядит просто замечательно, но когда мы увидим конечный продукт для пользователя с использованием этой технологии?
                        0
                        Как заметил belk, запросить демо-версию можно уже сейчас. Да и пример данных для просмотра есть
                        –8
                        бла бла бла… бла бла бла…
                          0
                          интересно, возможна ли нестатичная и интеракивная анимация?
                          может ли эта технология служить для создания игр?
                            0
                            В форме запроса демо-версии есть пункт «Interested in games», поэтому на это тоже был расчёт.
                              +3
                              Не факт, что в играх все будет полностью рендериться на их движке. Возможно что можно прорисовывать статику, фоны и «мебель». А потом уже поверх накладывать обычную геометрию
                                +2
                                Была такая игра, Outcast зовется, безумно красивая для своего времени.
                            +1
                            Рисовать очень много воксельных данных мы научились сравнительно давно. Свежее. Другое дело, что освещение никакое (максимум phong shading), сцена статична и никаких анимаций. Все это интересно, но удручает что без деталей.
                              0
                              Нет там видео… другие ссылки есть?
                                0
                                Есть, обновил.
                                +2
                                видео удалено
                                  0
                                  Забавно. Видео с самого начала было доступно только для тех, у кого есть ссылка — я о нем узнал через подписку. На всякий случай я сохранил копию видео, но сейчас залить не успею — будет часов через 8.
                                    0
                                    А, нет, видео просто «переехало». Обновил ссылку.
                                  0
                                  Если они не жульничают, не умалчивают о проблемах и все действительно так красочно как они описывают, то чуваки заработали себе место в истории ИТ на ровне с БГ и Стивом.
                                    0
                                    Интересно, получил ли кто-нибудь демку по запросу?
                                      0
                                      Лично я — пока нет.
                                        0
                                        Нет, тишина. С файловым форматом тоже все пошло достаточно туго. Header разрулил весь, а вот с данными без шелла работать сложно.

                                      Only users with full accounts can post comments. Log in, please.