OpenGlobus - новая JavaScript WebGL библиотека для 3D карт.

Нет, к сожалению такого примера нет, но вся библиотека(это два файла js и css) весит не больше 600 Кб, тайлы и рельеф загружаются онлайн. АПИ позволяет использовать настроить источники оффлайн, например натайлить тот же ОСМ и натайлить рельеф, из своего источника или глобусный. Идея хорошая, как для примера, но ее надо подготовить.

Простите не понял, увеличить рельеф по высоте вроде как масштабировать(как в гугл земле)? Или увеличить детализацию рельефа?

А что можете увеличить детализацию STRM :slight_smile: Конечно он хотел увеличить наглядность разницы высот.

А какой там формат? Есть какой-то тул для генерации из голого ПБФ?

Есть смысл ждать?

Рельеф:
Я предлагаю(предполагал, когда делал механизм загрузки рельефа), что каждый тайл рельефа глобуса(карты), представляет собой регулярную сетку(меркаторовская), в каждой ячейке которой записана высота. Например тайл рельефа тех высот которые по умолчанию работают в глобусе имеет размерность 33x33 высот(ячеек) т.е. клеток в ячейке 2^5, (в цезиуме, если я не ошибаюсь 2^6, в гугл земле 2^5). Например для глобуса я натайлил кеш из dem файлов и храню его на сервере, ничто мне не мешает натайлить кеш локально. Правда весит много, весь рельеф около 70 Гб(http://viewfinderpanoramas.org/), а кеш под терабайт(чуть меньше).
Пример тайла с рельефом: http://earth3.openglobus.org/12/1344/3846.ddm

Если вы хотите использовать свой формат(например серые тайлы с геосервера), не зависимо от источника(расположения), в АПИ необходимо добавить свой класс TerrainProvider, которому вы указываете размер сетки, адрес источника(если есть), и “виртуальный”(javascipt) метод, в котором вы свой формат переделываете в регулярную сетку тайла и отдаете в глобус. Таким образом вы можете подключить любой источник с рельефом, можно даже програмный какойнибудь шум Перлинга сделать(эти вещи я планирую сделать в примерах, их там уже около 30, но такого еще не делал, не думал что это будет интереснее чем скажем отображение видео, нерасчитал.)

Растр:
Тоже самое, как в лифлете или опенлеерсе: растровые тайлы, указываются источники, или используются АПИ как в случае с Яндексом или Гуглом. т.е. скачали в папку тайлы и указали ее как источник. Например вот здесь: http://176.194.189.20/earth/

Конечно будет пример. Меня например тоже интересует рельеф, но сейчас есть только один источник, есть в планах пример с источником из Цезиума(открытый источник), или со своего геосервера. Про оффлайн не думал, буду иметь ввиду.

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

Пожалуйста, добавил пример: http://openglobus.org/examples/HeightFactor/heightFactor.html

Ну вот, любо дорого смотреть.

Ещё бы поддержку координат в ссылке.

Глобус задумывался как открытый проект, для того чтобы каждый мог подстроить его под свои нужды. Для этого существует система контролов(плагинов). Контрол - это объект, класс которого наследует базовый контрол, у которого есть метод доступ к интерфейсу всего движка: сценам, камерам, шейдерам, слоям, событиям, window/document, webgl, и т.д. Пример контрола, который добавляет кнопку, при нажатии камера “летит домой”: http://openglobus.org/examples/CustomControl/customControl.html

Практически любой специализированный механизм удобно делать в виде контрола, например контрол отвечающий за навигацию мышкой, или на тачпаде; контрол, который устанавливает Солнце в позицию относительно даты и времени; контрол отображения Частоты кадров в секунду; контрол который рисует координатную сетку, как в ГуглЗемле(который тоже ждет своей очереди) и т.д.
https://github.com/OpenGlobus/OpenGlobus/tree/master/src/og/control

Разработанный вами контрол, может остаться в вашем проекте, а может быть добавлен в список контролов для глобуса, как в любой стандартной схеме опенсорс проектов.

Хочу загрузку 3D моделей с текстурами.

Это можно реализовать через полную поддержку gltf

Это как раз та задача, к которой я приступаю, сразу после публикации Глобуса в свет:)

Да уж, про фактор 5 я явно погорячился, а вот фактор 3 уклоны, которые пешеходами воспринимаются как значительные, как раз делает визуально заметными и при просмотре в вашей библиотеке. Так что вы эту фичу не выбрасывайте, пригодится.

А что за формат карты рельефа ddm? Откуда данные, чем конвертированы? Я смотрю, там нет лишнего шума, применялась какая-то фильтрация/сглаживание? Можно ли скачать всю планету? Давно хочу нарезать тайлы с рельефом, как с затенением (hill shading), так и с раскрашенной картой высот и изолиниями.

В данных есть пробелы. Качество уже не вспомню какое, источник предоставляю ниже по тексту. Тайл с расширением ddm - это простой массив чисел - высот в метрах, тип float(простите кажется integer но также 4 байта), представляющий сетку размером 33х33. Тайл веб меркаторовской сетки. Кеш тайлов сделан из данных скачанных по этой ссылке http://www.viewfinderpanoramas.org/Coverage%20map%20viewfinderpanoramas_org3.htm точность srtm30 примерно 90 метров между высотами. Исходные данные хранятся в *.hgt файлах wgs84 размером 1х1 градус, это видно скачав клетку с приведенного сайта. Тайлил при помощи утилиты https://github.com/OpenGlobus/OpenGlobus/tree/master/Tools/HeightsAdapter/HeightsAdaptater но на нее нет документации, т.к. я планировал чтобы глобус имел возможность подключать любые подходящие источники с высотами например свой источник тайлов на геосервере, или открытые данные Cesium AGI, но заодно сделал свой формат, для простоты и эксперимента. Если нужно подробнее - поясню в картинках. Скажите.

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

Нечаянно запостил это сообщение(точнее предыдущее) если можно удалите его.

Понятно. Я тоже оттуда брал.

Во, вот про это я и спрашивал.

Я точно такую же утилиту писал сам, только для 129х129 (а если быть точнее, то 131х131 с захватом ряда пикселей с каждого края, чтобы сделать бесшовную карту нормалей). Мне показалось, что у вас смещений меньше, поэтому и написал сюда с вопросом. Но сейчас присмотрелся - они просто менее заметны из-за сглаживания. Хотя допускаю, что я в своей утилите что-то напутал с координатами. Я до сих пор не знаю, пиксель показывает высоту “средней точки” квадрата, состоящего из граней этого пикселя, или он показывает высоту левой-верхней вершины. Делал на глаз по известной местности. Позже буду перепроверять.

Кстати, а зачем сохранять в массив 4-битных чисел, когда изначально числа 16-битные? Я, правда, работал через TIFF с задействованием утилиты gdalwarp, возможно в HGT битность выше, но точности-то уже все равно нет.

По поводу источников данных: когда я еще в прошлом году набрёл на viewfinderpanoramas, я не нашел внятной информации о копирайтах. Связался с автором. С его слов понял примерно следующее: карта главным образом основана на SRTM и на ASTER GDEM, плюс есть какие-то данные из других источников, являющихся общественным достоянием. Это так, для информации.

Еще вопрос… а где и как вы хостите такое количество тайлов? Объем-то небольшой, а количество большое.

Я выбирал размер грида тайла маленьким(33х33) из соображений, что тайлы постоянно загружаются, удаляются из памяти, снова загружаются, поэтому они должны быть маленькими как можно меньше, кстати винт на котором лежит тайловый кеш отформатирован с таким расчетом, что один тайл занимает один кластер :sunglasses:

В hgt вроде бы действительно 16 битные данные. hgt хранит высоты распределенные как бы по градусной сетке wgs84, при конвертации в меркаторовскую сетку(так чтобы высоты были распределены по меркаторовской сетке), я решил вычислять высоты меркаторовской сетки ориентируясь по высотам сетки hgt, которая wgs84. И так получалось, что в меркаторовской сетке кругом координаты - узлы, которые не совпадали с координатами из hgt, я предположил, что буду пересчитывать высоты(меркаторовской сетки) по треугольникам, которые образуются по исходным данным. Для большей точности расчеты происходят в double, а сохраняются в float, т.е. 4 байта.
пример:
hi hi+1
-----------------
| |
| * |
| mk |
| |
-----------------
hj hj+1

где, h - это высоты из файла hgt которые соответсвуют координатам srtm30, mk - координата меркаторовской сетки, в которой надо найти высоту(она не совпадает с высотой h).

Свой север. Но для глобуса, он не столь важен, только как источник данных для ландшафта. Можно использовать любой другой источник. Даже свой, тот-же геосервер.

Понятно. Я работу по преобразованию в меркатора поручил gdalwarp.

Там ведь порядка 20 миллионов файлов, да?

Кеш тайлов очень большой, конечно, если принять точность srtm 3 секунды, тогда максимальный индекс глубины равен 15, для меркатора 2^15 = 32768, итого тайлов 32768^2 = 1073741824. Плюс тайлы на зумах от 1 до 14 :open_mouth:

Это полный кеш тайлов.

Без кеша: 26129 файлов(данные по одном градусу). Это занимает 70 гигабайт.

П.С.
Моим алгоритмом кеш делался примерно 4-5 дней, на довольно стареньком ноутбуке, что я полагаю неплохой результат.

Исправлено! Благодаря вашему замечанию, алгоритм рисования рельефа был значительно улучшен!

-Увеличена на порядок скорость шейдинга рельефа
-Улучшено качество шейдинга рельефа
-При строгом просмотре в надир, сохраняется детелизация рельефа