Клуб Народной карты

3D-модели от пользователей

akbars
19 октября 2015, 16:46

После того, как на Яндекс.Картах появились 3D-модели зданий, а на Народной карте стало возможно проставлять высоту у домов, к нам поступали вопросы от пользователей о возможности размещать на Картах 3D-модели других зданий, в том числе модели зданий от пользователей.

Эту инициативу мы приветствуем, поскольку 3D-модели - еще один способ сделать Яндекс.Карты более наглядными и удобными для ориентирования на местности.

Интерфейс размещения моделей не самый простой, потому пользователям, писавшим о своей готовности предоставить свои 3D-модели для размещения их на Яндекс.Картах (либо не писавшим, но просто желающим увидеть свои модели на Картах), нужно написать нам на почту ymaps-legal@yandex.ru, отправить файлы с 3D-моделями, при необходимости задать вопросы и обсудить детали. Мы привяжем модели к нужным зданиям и в ближайшем релизе они появятся на Яндекс.Картах.

Технические требования к моделям

  1. 3-D модель должна быть в файле формата KMZ, состоящего внутри из KML-файла с геопривязкой и модели объекта в формата COLLADA.
  2. В 3-D моделях зданий должны отсутствовать текстуры.
  3. 3-D модель не должна полагаться на какие-либо режимы сглаживания (gouraud/phong shading), т.е. хорошо выглядеть с flat shading (абсолютно плоские грани).
  4. 3-D модель не должна включать в себя участки рельефа.
  5. 3-D модель не должна содержать элементы, которые подвержены частым изменениям (рекламные вывески, баннеры и пр.).
  6. 3-D модель не должна содержать элементы (будки, заборы, деревья), не повышающие узнаваемость объекта.
  7. 3-D модель не должна содержать малые архитектурные формы.
  8. Детализация 3-D моделей должна быть достаточной, но не чрезмерной. Ориентировочные цифры - не более 5000 граней (faces) для зданий типа "прямоугольный дом с крышей", не более 25000 - для сложных храмов и исторических сооружений.

Поскольку в Пользовательском соглашении Народной карты отдельно вопрос 3D-моделей не оговорен, а параметры этих данных отличаются от добавляемых непосредственно на Народной карте, то для данного случая сделана отдельная оферта, которая регулирует юридические вопросы.

В случае, если тема окажется востребована, мы будем думать про более удобный интерфейс добавления 3D-моделей на Яндекс.Карты.

28 комментариев

хотелось бы видеть сборник примеров, чтобы оценить, на сколько полигонов рассчитывать

Разумный запрос, постараемся реализовать.

еще вопрос: какие критерии отбора - можно отпралять любой сарай или только значимые объекты типа стидионов, монастырей и т.д.?

У сарая, как кажется, нет сложной геометрии:)

Так что нижник критерием является невозможность адекватно отобразить объем объекта текущими средствами Народной карты - набором полигонов разной высоты. Наличие одного только ската крыши также не является в общем случае основанием для 3D-моделирования.

Так что речь, в первую очередь, про здания сложной архитектуры (стадионы и монастыри к таковым относятся почти всегда, но и "обычное" офисное или даже жилое здание может быть таковым)

Олег Чечулин
21 октября 2015, 04:18

Ангары в виде полукруглых крыш (без стен) не получается адекватно отрисовать текущими средствами, но и 3D-модель для них тоже делать не вижу смысла. Может, стоит продумать для таких случаев отдельный атрибут?

Атрибут какого рода?

Олег Чечулин
22 октября 2015, 02:19

Ну, например, назвать его "круглая крыша" или как-то так. Чтобы не параллелепипед рисовался, а полуцилиндр

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

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

 Список моделей с их id и изображением, для начала, не обязательно держать в редакторе, а в разделе справка, например.   Достаточно добавить масштабирование для 3D объектов.

akbars,
Есть готовые модели, принимайте

буду ждать интерфейс так как качать какие либо програмульки (а ля 2 недели на разбор в каждой кнопке) не сильно хочется

Интерфейса для создания моделей мы делать не будет в любом случае - на рынке их большое количество. Я писал про интерфейс загрузки моделей к нам.

Рыжов Фёдор
31 октября 2016, 21:14
akbars,
 А какую программу, на ваш взгляд, лучше использовать? Какая удобней?
Рыжов Фёдор,
SketchUp отличная программа, в основном она используется для рисования 3D моделей для Google карт но можно их делать и для Яндекса 
тов. Вальтер
19 октября 2015, 19:10

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

Для части пользователей, действительно, информация о пространственной форме объекта не очень актуальна, но для большинства она помогает при ориентировании по карте.

я бы уменьшил допустимое количество полигонов в 100 раз - ну куда сараю 5000 граней? хватит и 50

Это ж не допустимое, а максимальное. Никто не мешает сделать в 100 полигонов.

 Немного почитал по теме, стало чуть понятнее...

Но есть несколько вопросов.

1. Необходимо разобрать правилность заполнения файла .kml

Взят для примера гугловский.

 

http://earth.google.com/kml/2.1">

SketchUp Model of Macky Auditorium

University of Colorado, Boulder; model created by Noël Nemcik.

-105.2727379358738

40.01000594412381

0

127.2393107680517

65.74454495876547

-27.70337734057933

relativeToGround

-105.272774533734

40.009993372683

0

0

0

0

1

1

1

files/CU Macky.dae

 

Блок  как я понимаю нам не нужен?

Name id любой? Принципиально только название архива, которое будет задаваться администратором? 

Будет ли возможность подвигать модельку, чтобы её правильно сориентировать средствами редактора после её добавления или придется все жестко забивать вручную, включая параметр  отвечающий за вращение в плоскости?

relativeToGround Не нашел в описании, это что такое?


2. Может все же начать с моделек попроще? Хотя бы с тех же сараев. С конвертом модели в формат .dae я никогда не сталкивался, но народ на форумах пишет, что "не все йогурты одинаково полезны..." То есть возможность конвертить есть во многих прогах, но файлики получаются разные и в некоторых случаях "битые". Дабы протестить, на предмет появления мелких косяков или еще чего...


3. А почему без текстур? Возни с ними конечно побольше будет, но без текстур здания выглядят довольно безликими... Этого функционала пока в принципе нет или нехотите перетежелять карту?  Можно было бы отключаемой эту функцию сделать. 

 Текстуры, кстати, можно было бы заменить раскраской граней. С учетом размера моделки на карте, это возможно  даже лучше бы выглядело.  Но пока неизвестно, поддерживает ли это формат Collada. И будут ли цвета граней отображаться при появлении на карте?  

 В спецификации COLLADA уже есть гео координаты, в таком же формате, как и .kml

Может быть можно было бы вообще обойтись без дополнительной упаковки модели в .kmz?

 Мда... Почитал тут нонче COLLADA спецификацию... Никогда раньше, не морочал себе голову в каком виде инфа в файликах храниться... Затея с унификацией данных 3D моделей, сцен, освещениея, анимации и пр. конечно интересная.

 

 

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

 

 Протестив несколько прог, заметил, что например Blender начинает прикручивать к файлу камеру, освещение и свои настройки к этому добру, это помимо mesh модели. 3D Max не ставил еще, но думаю, что будет примерно то же. GLC-Player, что-то вообще не захотел открыть мои .dae файлы. Пока что, наиболее достойный по содержанию .dae файл выдал MeshLab. Правда он не проставил метрику модели, но возможно её и небыло в моем исходном .stl Всю левую инфу, в идеале нужно как-то выпиливать, в идеале не в вручную.

 

 Конечно, COLLADA сохранит преобразования 3D редакторов и даже CAD систем, и где-то это будет не только отображаться, но и крутиться, мигать и прыгать. Но в этом случае API карт и навигатора должен все это (или частично) поддерживать. И неплохо бы знать, что именно он на текущий момент поддерживает.  Получается, он по сути своей должен приближаться к уровню игрового движка и простого 3D редактора с ограниченным интерфейсом для пользователя. Если все это направление в принципе интересно.

 

 Но не так страшен черт, як ёго малют;) Листая спецификацию, я обратил внимание, что масштабирование объекта (трансформация) выполнена с помощью матрицы, то есть модель (mesh) отдельно, преобразования отдельно. В этом, кстати, основное отличие некоторых CAD, от КОМПАС'а или  2D Corel Draw (насчет Solid Works незнаю). Где видимо вся система построена на матрице и иерархии матриц. Наглядным примером служит максовский модификатор 3х3х3 BOX. Я только сейчас понял принципиальную разницу между этими CAD. Компас остается в рамках классической геметрии, а далее строит и считает на основании пределов, логарифмов и прочего ужаса, который даже на бумаге, страшно представить, не говоря уже о формулах для построения каких либо объектов. Простым примером является построение двусекции произвольного угла (деление угла пополам) в AutoCad и КОМПАС'е c помощью двух окружностей. В AutoCad прямая, пересекая две окружности в первой точке, совпадает точно, а вот во второй, начинает уплывать при небольшом приблежении... В КОМПАСе все ровно. В случае CAD, это конечно может стать проблемой, если сопряжения элементов начинают уплывать уже в самой модели. Но преимуществом матриц является простота преобразования и моделирования объектов. Постоить API на основе матриц, еще туда суда, видимо... тут хотя бы простые арифметические расчеты, максимум, запятая плавает. А вот пределы... это точно для маньяков :) 

Но тема интересная :)

Добрый день, хочу узнать жива ли тема?
Рыжов Фёдор
16 ноября 2016, 14:48
Krestyaninov85,
Типа жива
Рыжов Фёдор,
Работаем дальше
Westb0und,
Меня примите, есть много моделей.
Какие типы примитивов Вы поддерживаете?
Пример: triangles или polylist + polygons
Это важный вопрос, т.к. при разбивании на треугольники количество граней может значительно возрастать - минимум в 2 раза. 
К примеру прямоугольник при экспорте полигонами  будет иметь 1 грань, треугольниками - 2 грани, кубик полигонами - 6 граней,  треугольниками - 12.
Ограничение в 5000 граней для какого случая у Вас прописано?
Хотелось бы еще определиться с форматом collada dae в kmz.
А конкретно:
1. Полигоны или треугольники (google earth не поддерживает полигоны, только треугольник)
2. Экспорт ребер и сторон граней (+2 обязательные пустые текстуры)
3. Использование компонентов или сплошниковая модель (компоненты значительно снизять размер файла при повторяющихся объектах)


Очевидно, что самый правильный вариант - полигоны, без ребер, без сторон граней, с компонентами.
Для проверки того, что у Вас поддерживается сделал тестовую модель в разных вариантах экспорта. Прошу Вас попробовать и проверить все из них. Визуально отличий быть не должно, однако самый оптимальный из этих вариантов - Cubic_poly_component.kmz
Файлы здесь: https://yadi.sk/d/6v1s9mSX3EXa9U



Отпишите что да как делать, какой из этих файлов подходит, от этого зависит как рисовать...
Обновлено 24 февраля, 22:32