детализация объектов lod что это
Level Of Detail (LOD).
Смысл LOD, вытекает из его названия. Это не что иное, как несколько вариантов одного объекта с различными степенями детализации, которые переключаются в зависимости от расстояния объекта до виртуальной камеры. Нет смысла обсчитывать сложнейший объект, если он будет виден на экране размером в два пиксела. Их применяют для того, чтобы уменьшить загрузку ресурсов компьютера, будь то рендеринг или реалтайм вывод на экран. Поэтому LOD’ы широко используются не только в кино/видео производстве, но и в компьютерных играх.
Существуют несколько различных путей создания LOD’ов. Одними из наиболее продвинутых способов является моделирование с помощью нурбсов или патчей безье. С помощью них легко варьировать разрешение обьекта, но это пока удел кинопроизводства с очень сложными формами.
В game-индустрии основой производства трехмерных объектов является полигональное моделирование. И здесь возникает задача быстрого и эффективного создания полигональных LOD’ов с сохраниением общей формы и, что особенно важно, текстурных координат. Кому охота каждый раз перенатягивать текстуры на каждый новый LOD?
Как их делать в MAX’е.
4-й MAX имеет встроенный модификатор Multires. Он схож по функциональности с Polychop’ом, но более продвинутый. В нем, кроме процентного отношения, уже можно задавать количество вершин.
Также Multires позволяет сваривать вершины(Vertex Merging), принадлежащие разным элементам обьекта, т.е. когда в сетке имеются разрывы. Polychop этого делать не умеет.
Неплохим средством в помощь гейм-моделеру является утилита Polygon Counter.
С ее помощью вы всегда будете знать сколько полигонов содержится в сцене или в выделенном обьекте.
Обычно для тестирования LOD’ы экспортируются в движок игры. Но для 3DSMAX’а существует полезный (слегка нами модифицированный) скрипт LOD_Tester (работает как в 3-й так и в 4-й версиях MAX’а). Он позволяет переключать LOD’ы непосредственно во вьюпорте. Это подходит для тех случаев, когда под рукой нет игрового движка.
СОДЕРЖАНИЕ
Историческая справка
Такая же структура среды теперь предлагается как способ управления различными деталями, что позволяет избежать ненужных вычислений, но при этом обеспечивает адекватное визуальное качество:
Однако важным моментом является то, что в сложной среде объем информации, представленной о различных объектах в окружающей среде, варьируется в зависимости от доли поля зрения, занятой этими объектами.
Хорошо известные подходы
Хотя представленный выше алгоритм охватывает весь спектр методов управления уровнем детализации, в реальных приложениях обычно используются специальные методы, адаптированные к отображаемой информации. В зависимости от требований ситуации используются два основных метода:
В обоих случаях LOD выбираются на основе некоторой эвристики, которая используется для оценки того, сколько деталей теряется из-за уменьшения детализации, например, путем оценки геометрической ошибки LOD относительно модели с полной детализацией. Затем объекты отображаются с минимальным количеством деталей, требуемым для выполнения эвристики, которая предназначена для минимизации геометрических деталей в максимально возможной степени, чтобы максимизировать производительность при сохранении приемлемого уровня визуального качества.
Подробная информация о дискретном уровне детализации
Алгоритмы DLOD часто используются в ресурсоемких приложениях с небольшими наборами данных, которые легко помещаются в памяти. Хотя можно использовать алгоритмы, не связанные с ядром, степень детализации информации не очень подходит для такого рода приложений. Этот тип алгоритма обычно легче запустить, поскольку он обеспечивает более высокую производительность и меньшую загрузку ЦП из-за небольшого количества операций.
Дискретный пример LOD
| Изображение |  |  |  |  |  |
|---|---|---|---|---|---|
| Вершины | 140 | ||||
| Примечания | Максимальная детализация для крупных планов. | Минимум деталей, очень далекие объекты. |
OpenGL используется для рендеринга из-за его высокой эффективности при управлении небольшими партиями, хранении каждой модели в списке отображения, что позволяет избежать накладных расходов на связь. Дополнительная вершинная нагрузка создается за счет применения двух направленных источников света, идеально расположенных бесконечно далеко.
В следующей таблице сравнивается производительность рендеринга с учетом LOD и метода полной информации ( грубой силы ).
| Грубый | DLOD | Сравнение | |
|---|---|---|---|
| Визуализированные изображения |  |  |  |
| Время рендеринга | 27,27 мс | 1,29 мс | 21 × уменьшение |
| Вершины сцены | 2 328 480 | 109 440 | 21 × уменьшение |
Иерархический LOD
Поскольку оборудование ориентировано на большое количество деталей, рендеринг низкополигональных объектов может иметь неоптимальную производительность. HLOD позволяет избежать этой проблемы, группируя различные объекты вместе. Это позволяет повысить эффективность, а также воспользоваться соображениями близости.
Практическое применение
Видеоигры
В популярной игре о строительстве городов Cities: Skylines моды позволяют изменять уровень детализации.
В ГИС и 3D моделировании городов
LOD встречается в ГИС и 3D моделях городов как аналогичная концепция. Он показывает, насколько тщательно были нанесены на карту особенности реального мира и насколько модель соответствует своему аналогу из реального мира. Помимо геометрической сложности, в LOD модели могут учитываться другие показатели, такие как пространственно-семантическая когерентность, разрешение текстуры и атрибуты. Стандартный CityGML содержит одну из самых известных категорий LOD.
OpenSceneGraph: Уровни детализации (LOD) и фоновая загрузка объектов
Введение
Одной из интереснейших задач, решаемых посредством трехмерной графики является создание «больших миров» — протяженных сцен, содержащих большое число объектов с возможностью неограниченного перемещения по сцене. Решение этой задачи упирается в понятные ограничения, присущие аппаратному обеспечению компьютера.
Типичный пример: «большой мир» при визуализации железной дороги на движке OSG. Не хватает только лангольеров, пожирающих мир за поездом.
1. Использование уровней детализации (LOD)
Техника использования уровней детализации позволяет отображать один и тот же объект более или менее детально, в зависимости от расстояния от него до наблюдателя. Использование этой техники основано на том простом соображении, что мелкие детали трехмерной модели неразличимы на большом расстоянии, значит нет необходимости в их прорисовке. С одной стороны этот прием позволяет уменьшить общее количество геометрических примитивов, выводимых в буфер кадра, а с другой — не терять в дальности отображения объектов сцены, что очень полезно при создании больших открытых миров.
OSG предоставляет инструменты для реализации этого приема через класс osg::LOD, наследуемый от всё того же osg::Group. Этот класс позволяет представить один и тот же объект в нескольких уровнях детализации. Каждый уровень детализации характеризуется минимальной и максимальной дистанцией до наблюдателя, при соблюдении которой происходит переключение отображения объекта в этом уровне детализации.
osg::LOD позволяет задавать данный диапазон сразу при задании дочерней ноды, или позже, применением методы setRange()
Продолжаем мучать цессну и проиллюстрируем описанную технику примером
main.h
main.h
Для начала загружаем модель
Теперь необходимо генерировать несколько (ограничимся для примера двумя) моделек, с более низким уровнем детализации. Для этого скопируем загруженную ноду дважды, применяя методику так называемого «глубокого» копирования класса, для ноды реализуемого методом clone()
Теперь редуцируем геометрию этих моделей, используя класс osgUtil::Simplifer. Степень упрощение модели задается методом setSampleRatio() данного класса — чем меньше передаваемый параметр, тем менее детальной будет модель после применения процедуры редукции
Когда у нас есть модельки разного уровня детализации мы можем зарядить их в корневую ноду, созданную как умный указатель на osg::LOD. Для каждого уровня детализации задаем дистанцию отображения этого уровня
Под FLT_MAX понимается в некотором роде «бесконечно» большое расстояние до наблюдателя. После запуска вьювера получаем следующую картину
Уровень детализации 3
Уровень детализации 2
Уровень детализации 1
Видно, как при отдалении камеры от объекта снижается детальность отображаемой геометрии. Применяя этот прием можно добиться высокой реалистичности сцены при малом расходе ресурсов.
2. Техника фоновой загрузки узлов сцены
В движке OSG представлены классы osg::ProxyNode и osg::PagedLOD, предназначенный для баллансировки нагрузки при рендеринге сцены. Оба класса наследуются от osg::Group.
Узел типа osg::ProxyNode уменьшает время запуска приложения до начала рендеринга, если в сцене огромное количество загружаемых с диска и отображаемых моделей. Он работает как интерфейс к внешним файлам, позволяя выполнять отложенную загрузку моделей. Для добавления дочерних узлов используется метод setFileName() (вместо addChild) чтобы установить имя файла модели на диске и загрузить его динамически.
Узел osg::PagedNode наследует методы osg::LOD и загружает и выгружает уровни детализации таким образом, чтобы избежать перегрузки конвейера OpenGL и обеспечить плавную отрисовку сцены.
3. Динамическая (runtime) загрузка модели
Посмотрим, как происходит процесс загрузки модели с применением osg::ProxyNode.
main.h
main.cpp
Процесс загрузки здесь немного отличается
Вместо явной загрузки модели коровы мы указываем корневой ноде имя файла, где содержится модель и индекс дочерней ноды, куда следует поместить эту модель после её загрузки. При выполнении программы мы получи такой результат
Видно, что точка обзора выбрана не лучшим образом — камера упирается прямо в зеркальный бок коровы. Это произошло потому, что модель загрузилась уже после запуска рендера и инициализации камеры, когда нода 0 ещё не была видна. Вьювер просто не смог просчитать необходимые параметры камеры. Однако, модель загрузилась и мы может настроить режим её отображения путем манипуляций мышью
Что происходит в рассмотренном примере? osg::ProxyNode и osg::PagedLOD работают в данном случае как контейнеры. Внутренний менеджер данных OSG будет посылать запросы и загружать данные в граф сцены по мере того, как возникнет необходимость в файлах моделей и уровнях детализации.
Данный механизм работает в нескольких фоновых потоках и управляет загрузкой статических данных, расположенных в файлах на диске и динамических данных, генерируемых и добавляемых в процессе выполнения программы.
Движок автоматически обрабатывает узлы, не отображаемые в текущем вьюпорту и удаляет их из графа сцены когда рендер перегружен. Однако, такое поведение не затрагивает узлы osg::ProxyNode.
Как и прокси-узел, класса osg::PagedLOD также имеет метод setFileName() для задания пути к загружаемой модели, однако для его необходимо установить диапазон дистанции видимости, как для узла osg::LOD. При условии, что у нас имеется файл cessna.osg и низкополигональная модель уровня L1 мы можем организовать выгружаемую ноду следующим образом
Нужно понимать, что узел modelL1 не может быть выгружен из памяти, так как это обычный дочерний не прокси-узел.
При рендеринге внешне не видна разница между osg::LOD и osg::PagedLOD, если использовать только один уровень детализации модели. Интересной идеей будет организовать громадный кластер моделей Cessna, используя класс osg::MatrixTransform. Для этого можно использовать например такую функцию
Пример программы реализующей фоновую загрузку 10000 самолетов
main.h
main.cpp
Предполагается, что самолеты будут располагаться на плоскости с интервалом в 50 единиц координат. При загрузке мы увидим, что загружаются только те цессны, что попадаю в кадр. Те самолеты, что исчезают из кадра пропадают из дерева сцены.
Заключение
Этот урок в цикле об OpenSceneGraph будет последним, выполненным в формате «How To». В рамках двенадцати статей удалось уместить базовые принципы работы и использования OpenSceneGraph на практике. Очень надеюсь, что данный движок стал более понятен русскоязычному разработчику.
Это не означает, что я закрываю тему OpenSceneGraph на ресурсе, напротив, будущие статьи планируется посвятить более продвинутым техникам и приемам применения OSG в разработке графических приложений. Но для этого следует накопить хороший материал и переработать массу англоязычных источников, а на это требуется время.
Но я не прощаюсь, благодарю за внимание и до новых встреч!
Уровни детализации LOD
Уровни разработки/ уровни детализации/ LOD
Ниже приведен перевод статьи об уровнях детализации в BIM.
Если вы углубляетесь в мир BIM (Building Information Modeling), вы, скорее всего, столкнетесь с кучей сокращений, включая LOD. Что такое LOD, спросите вы?
Уровень разработки (LOD) решает несколько проблем, возникающих при использовании BIM в качестве инструмента связи или совместной работы, то есть когда кто-то, кроме дизайнера, извлекает из него информацию. В процессе проектирования строительные системы и компоненты переходят от неопределенной концептуальной идеи к точному описанию.
В прошлом не было простого способа указать, где находится элемент модели на этом пути. Дизайнер знает, а другие часто нет. Легко неверно истолковать точность, с которой моделируется элемент. Рукописные чертежи варьируются от штрихов на салфетке до жестких линий с выделенными размерами, и точность чертежа легко определить по его внешнему виду. Тем не менее, в модели общий компонент, размещенный приблизительно, может выглядеть точно так же, как и конкретный компонент, расположенный точно, поэтому нам нужно что-то кроме внешнего вида, чтобы увидеть разницу.
Кроме того, можно получить информацию из BIM, которая не предназначена для разработчика: неуказанные размеры можно измерить с точностью, информация о сборке часто существует до ее окончательной доработки и т. д. В прошлом эта проблема была обойдена всеобъемлющим отказом от ответственности, которые в основном говорят: «Поскольку некоторая информация в модели ненадежна, вы не можете полагаться ни на одну из них».
Инфраструктура LOD позволяет авторам модели четко заявлять о надежности данных элементов модели, поэтому концепция становится «Поскольку некоторая информация в модели ненадежна, вы можете полагаться на нее только в том случае, если я специально говорю, что вы можете». В среде, где люди, отличные от разработчика модели, зависят от информации из модели, чтобы продвинуть свою собственную работу, план работы по проектированию приобретает большое значение – пользователям модели необходимо знать, когда информация будет доступна для планировать свою работу. Структура LOD облегчает это.
Уровень разработки vs. Уровень детализации
LOD иногда упоминается или интерпретируется как уровень детализации, а не уровень разработки.
Есть важные различия. Уровень детализации является мерой количества предоставленной информации. Поскольку это только мера количества, основополагающее предположение состоит в том, что вся предоставленная информация имеет отношение к проекту и на нее можно с уверенностью полагаться.
Уровень разработки – это степень, до которой продумана геометрия элемента и приложенная информация, – степень, в которой члены проектной команды могут полагаться на информацию при использовании модели. По сути, уровень детализации может рассматриваться как вход для элемента, в то время как уровень развития является надежным выходом.
LOD 100: Элемент модели может быть графически представлен в модели с помощью символа или другого общего представления, но не удовлетворяет требованиям для LOD 200. Информация, относящаяся к элементу модели (то есть стоимость за квадратный фут, тоннаж ОВК и т. д.) могут быть получены из других элементов модели.
LOD 200: элемент модели графически представлен в модели как общая система, объект или сборка с приблизительными количествами, размером, формой, местоположением и ориентацией. Неграфическая информация также может быть прикреплена к элементу модели.
LOD 300: Элемент модели графически представлен в модели как конкретная система, объект или сборка с точки зрения количества, размера, формы, местоположения и ориентации. Неграфическая информация также может быть прикреплена к элементу модели.
LOD 350: Элемент модели графически представлен в модели как конкретная система, объект или сборка с точки зрения количества, размера, формы, ориентации и взаимодействия с другими системами здания. Неграфическая информация также может быть прикреплена к элементу модели.
LOD 400: Элемент модели графически представлен в модели в виде конкретной системы, объекта или сборки с точки зрения размера, формы, местоположения, количества и ориентации с подробной информацией, изготовлением, сборкой и информацией по установке. Неграфическая информация также может быть прикреплена к элементу модели.
LOD 500: Модельный элемент является проверенным на месте представлением (то есть, в собранном виде) с точки зрения размера, формы, местоположения, количества и ориентации. Неграфическая информация также может быть прикреплена к элементам модели.
Например – Структурная колонна / опорная плита (как показано выше)
Предостережения:
Нет строгого соответствия между LOD и фазами проектирования. Строительные системы разрабатываются с разной скоростью в процессе проектирования – например, проектирование структурной системы обычно намного опережает проектирование внутреннего строительства. Например, при завершении этапа проектирования схемы модель будет включать в себя множество элементов в LOD 200, но также будет включать много элементов в LOD 100, а также некоторые в LOD 300 и, возможно, даже в LOD 400.
Точно так же не существует такого понятия, как «модель LOD xxx». Как указывалось, ранее, модели проектов на любом этапе представления/выдачи будут неизменно содержать элементы и сборки на разных уровнях разработки. Например, не логично требовать «модель LOD 200» по завершении этапа проектирования схемы. Вместо этого «поставляемая модель схемы проектирования» может содержать смоделированные элементы на разных уровнях разработки.
LOD и LOI: что важно знать заказчику и исполнителю
С понятием LOD — уровень проработки, level of development — проектировщики обычно встречаются, когда получают требования к информационной модели или семействам. Чаще всего выглядят они как LOD300, LOD350, LOD400, но что кроется за этими обозначениями?
Для начала давайте посмотрим на определение и разберемся с нормативной базой. Источника у нас три:
Определения везде по сути идентичные.
LOD — набор требований, определяющий полноту проработки элемента цифровой информационной модели. Уровень проработки задает минимальный объем геометрических, пространственных, количественных, а также любых атрибутивных данных, необходимых для решения задач информационного моделирования на конкретной стадии жизненного цикла объекта.
Иногда LOD разбивают на две категории: LOD G и LOI (level of information). Первый отвечает за уровень геометрической проработки, второй — за информационное наполнение модели, это и есть атрибутивные данные. Например, диаметр подключения — это LOD G, а максимальное рабочее давление и наименование для спецификации — LOI. Чем выше уровни LOD G и LOI, тем больше работы нужно сделать проектировщику, чтобы сдать модель.
Заказчику тоже важно понимать, что это такое, так как от этого зависит качество модели. В результате LOD становится общим языком для разработчика и заказчика. Однако определение LOD довольно обтекаемое и не уточняет, что именно считать уровнем 100, 200, 300, 400 и 500. Эти цифры вообще не участвуют в определении.
Разобраться поможет СП 333. В пункте 6.3 рассказывается, что это за уровни и чем они отличаются друг от друга. Вот таблица из СП:
Также важно понимать, что определённый LOD описывает уровень проработки не для всей информационной модели здания, а только для отдельных её элементов. Когда вас просят выдать проект на уровне LOD 400 — это некорректное обозначение. Для каждой категории должно быть описание, насколько проработана геометрия, какие и как заполняются параметры.
Там же в СП 333, в приложении А, есть таблицы, где приводится пример того, как можно описывать категории для моделирования. Приведём пример такой таблицы для модели отопления.
В таблице нет ничего про LOD 500, потому что по сути это уточнённая модель по результатам монтажа. После завершения строительства проводят лазерное сканирование здания, получают облако точек. Модель и облако накладывают друг на друга, сравнивают, положения элементов корректируются до фактических. Такую BIM-модель можно выдавать в эксплуатацию, теперь в ней всё максимально близко к тому, что есть на самом деле.
В пособии от Autodesk по разработке семейств в приложениях есть примеры семейств и того, как они должны выглядеть на разных уровнях проработки. Это более наглядно и понятно.
Тем не менее системы чётких и конкретных указаний нет, каждый раз пожелания обговариваются между заказчиком и исполнителем. Кроме нормативных рекомендаций, а это именно рекомендации, а не требования, существует и практический опыт, который привязан к российским реалиям.
На иллюстрации выше пример модели на уровне LOD 400. При высокой детализации на шкафу видны все лампочки, переключатели и значки. Это красиво и радует глаз производителя оборудования, но по факту такая модель будет излишне нагруженной. Она не нужна ни проектировщику, ни строителю, ни экспертизе. Разве что дизайнеру интерьера, но обычно они работают в специализированном программном обеспечении, модели для Revit им не пригодятся.
Кроме того, чрезмерные «навороты» утяжеляют информационную модель, она начинает медленнее работать. Поэтому российское BIM-сообщество придерживается мнения, что LOD должен быть минимально достаточным, делать что-то ради красоты просто «чтобы было» бессмысленно и даже чревато неприятностями в работе. Нужно искать золотую середину: геометрия должна быть точной в габаритах и визуально походить на реальный объект, однако стремиться к фотографической точности нет необходимости. Необходимый минимум информация в модели — всё то, что требуется для спецификации по ГОСТ. Остальную информацию всегда можно приложить в виде ссылки на каталог.
Давайте подведём итоги.
Уровень проработки — важная составляющая для BIM-моделирования. Это общий язык между заказчиком и исполнителем, благодаря ему модель будет качественной.
Понятие LOD применимо не ко всей информационной модели, а к отдельным элементам. Например, сантехника может быть выполнена на низком уровне проработки, а технологическое оборудование — на высоком.
Уровни проработки:
LOD 100 — эскизы и наброски, может пригодиться архитекторам на ранних стадиях работы;
LOD 200 — стадия П без привязки к конкретному производителю, положения и размеры точные для основных конструкций;
LOD 300 — стадия П без привязки к конкретному производителю с точными положениями элементов;
LOD 400 — стадия Р, конкретные производители элементов, деталировочные узлы, точные положения и габариты
LOD 500 — актуализированная модель по исполнительной документации и/или облакам точек с уточнением положений возвездённых конструкций и сетей.
Для каждого случая нужно отдельно обговаривать LOD и обходиться минимальным возможным значением для экономии времени разработчиков и машинных ресурсов.