Смысл 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’ы широко используются не только в кино/видео производстве, но и в компьютерных играх.
Существуют несколько различных путей создания LOD’ов. Одними из наиболее продвинутых способов является моделирование с помощью нурбсов или патчей безье. С помощью них легко варьировать разрешение обьекта, но это пока удел кинопроизводства с очень сложными формами.
В game-индустрии основой производства трехмерных объектов является полигональное моделирование. И здесь возникает задача быстрого и эффективного создания полигональных LOD’ов с сохраниением общей формы и, что особенно важно, текстурных координат. Кому охота каждый раз перенатягивать текстуры на каждый новый LOD?
При создании игр рекомендуется, чтобы каждый последующий LOD имел в среднем в 1,5 – 2 раза меньшее количество полигонов.
Как их делать в MAX’е.
3DSMax – пожалуй самый широкоиспользуемый пакет для создания игровой графики. Для 3-й версии MAX’а существует неплохой плагин polychop. Это модификатор, который позволяет уменьшать детализацию без потери текстурных координат. Просто задайте уровень детализации в процентах. Также важным параметром является сохранение неизменного положения выделенных вершин(lockdown selected verts). Для этого нужно просто выделить нужные вершины до применения модификатора.
4-й MAX имеет встроенный модификатор Multires. Он схож по функциональности с Polychop’ом, но более продвинутый. В нем, кроме процентного отношения, уже можно задавать количество вершин.
Также Multires позволяет сваривать вершины(Vertex Merging), принадлежащие разным элементам обьекта, т.е. когда в сетке имеются разрывы. Polychop этого делать не умеет.
Неплохим средством в помощь гейм-моделеру является утилита Polygon Counter.
С ее помощью вы всегда будете знать сколько полигонов содержится в сцене или в выделенном обьекте.
Обычно для тестирования LOD’ы экспортируются в движок игры. Но для 3DSMAX’а существует полезный (слегка нами модифицированный) скрипт LOD_Tester (работает как в 3-й так и в 4-й версиях MAX’а). Он позволяет переключать LOD’ы непосредственно во вьюпорте. Это подходит для тех случаев, когда под рукой нет игрового движка.
Здесь все просто. Обьекты заносятся в список LOD List, для них указываются зоны видимости. Затем нужно создать и активизировать камеру. И все, теперь с помощью ползунка Cam Dist вы можете тестировать свое творение. В случае неудачи жмите кнопку Usage – это пошаговое руководство использования данного скрипта.
Очередь просмотра
Очередь
Хотите сохраните это видео?
Пожаловаться на видео?
Выполните вход, чтобы сообщить о неприемлемом контенте.
Понравилось?
Не понравилось?
Согласитесь, компьютерная графика сейчас наверное одна из самых быстро развивающихся сфер. Насколько далеко шагнул прогресс (в том же геймдеве) за последние 20 лет. От угловатых моделей как, например, в Ларе Крофт, до полноценного проработанного и живого мира.
Тогда, на первых этапах развития графики текстуры то накладывать было трудозатратно. От них по возможности отказывались, а пропуски закрашивали цветом. Сейчас же появилось множество фишек, которые снижают нагрузку на железо игрока, оптимизируют и значительно увеличивают качество графики.
Ребят, хочу поделится одной фичей, про которую мало кто знает. Я приведу пример по игре Hitman 6, но ниженаписанное можно сделать и с любой другой игрой!
Для NVIDIA: Показать полностью… 1) скачать программу Nvidia Inspector, установка не требуется. 2) Найти в списке игр Hitman Pro. 3) Выставить следующие настройки:
Чем выше значение LOD Bias (+3 макс) тем хуже текстуры. Вот наглядные скриншоты:
Для AMD И ATI: Я приведу пример на игре CS GO:
К слову, вы можете не ставить такое мыльцо, это уже в крайних случаях, вы можете поставить параметр 2 или 3, в них не так и замылена графика и не очень то и заметно ухудшение, но производительность все равно повышена.
Урок достаточно «углублённый», касается уже самых «глубоких» этапов графического мододелания, но я надеюсь, что кому-нибудь будет полезен.
Что такое, зачем нужно?
LOD (англ. Levels Of Detail — уровни детализации) — приём в программировании трёхмерной графики, заключающийся в создании нескольких вариантов одного объекта с различными степенями детализации, которые переключаются в зависимости от удаления объекта от виртуальной камеры. Другой метод заключается в использовании одной основной, «грубо приближенной», модели и нескольких внешних надстроек к ней. Каждая последующая надстройка к основной модели дополняется элементами детализации пропорционально номеру надстройки. То есть на самом большом расстоянии будет отображаться единственная главная модель объекта. С приближением же последнего к камере игрока к конвейеру отрисовки будут последовательно подключаться последующие надстройки деталей.
Смысл приёма заключается в том, что отображать высокодетализированные объекты, находящиеся на большом расстоянии от виртуальной камеры, нецелесообразно, затратно по вычислительным ресурсам. Использование LOD способно существенно снизить требования к ресурсам компьютера при выводе графики на экран, будь то рендеринг или вывод в реальном времени[1]. С использованием LOD, впрочем, связан широко распространённый баг, при котором на ближних планах отображается низкополигональная модель объекта.
Поэтому резонно искать автоматизированные средства генерации лодов.
Платные решения мы отбрасываем сразу. Поверьте, они того не стоят и я это докажу на примере.
Вердикт: не подходит для большинства моделей
Вердикт: то, что надо!
1) Выбираем нашу модель, переходим во вкладку «Utilities», намаем кнопку «More», в списке выбираем «Simplygon» и нажимаем «ОК»
2) В появившемся свитке снимаем галочку «Silent mode» и нажимаем на кнопку «Launch Simplygon»
3) Открывается окно подпрограммы «Simplygon» Для быстрого решения поставленной задачи переходим в правой колонке в закладку «Quick Start», выбираем пункт «LOD chain» («цепочка ЛОДов»), отмечаем необходимый уровень упрощения моделей (в нашем случае это 71, 50 и 36 процентов от исходного количества полигонов), далее нажимаем «Click me to Proceed»
4) В процессе работы вы увидите кнопку «Download» («Скачать»). Прелесть в том, что вычисления происходят в «облаках», то есть не зависят от вашего компьютера, отсюда такая скорость таких сложных вычислений. В любом случае, вы можете поставить галочку «Download automatically in future» (скачивать автоматически в будущем). Пока этот пункт не выбран, нажимаем «Скачать» вручную.
5) По окончании процесса нажимаем на кнопку «Import»
6) После, закрываем Simplygon. При этом программа спросит «импортировать ли сгенерированные ЛОДы в 3Ds Max», нажимаем «Yes»
7) Теперь у нас есть наша исходная модель + 3 её лода. Их необходимо переименовать. Правила именования моделей в серии TW: окончания должны иметь вид _lod1 (исходная модель), _lod2, _lod3 и _lod4.
8) Тут же, в списке элементов сцены вы сможете обнаружить три сторонних объекта с именами Object#. Это копии корня сцены, появившиеся в процессе создания лодов. Не будем вдаваться в подробности, их нужно просто удалить.
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 в разработке графических приложений. Но для этого следует накопить хороший материал и переработать массу англоязычных источников, а на это требуется время.
Но я не прощаюсь, благодарю за внимание и до новых встреч!
-В этой статье будет много технической информации, однако я постараюсь преподнести её максимально простым языком.
В начале лета многие передовые разработчики ААА игр заявили о том, что разработка игр дорожает а ценник на них не изменяется, поэтому давайте поднимем его.
1)Кто-то утверждал, что так индустрия сможет избавиться от надоедливых микротранзакций; 2)кто-то утверждал, что стандарты ААА проектов, как и аппетиты игроков растут, что требует больше человека-часов на разработку проектов, 3)кто-то ссылался на инфляцию. Что же, давайте разберёмся во всём по подробнее.
Транзакции
Давайте посмотрим на ближайшие релизы:
И мы видим повсеместные различные издания игр с заранее выпелиным контентом из цельного продукта. А о выпиливании лутбоксов из тех же спортивных симуляторов и различных игр-сервисов, никто и не думал. Я не хочу сказать что все игры пользуются такой стратегией монетизации, есть игры от студий калибром по меньше которые и не повышали цен на игры. Однако повышение цен никак не повлияло на наличие микротранзакций.
Про стандарты ААА проектов и технологии
Со временем, в гонке за потребителем ААА студии действительно пытаются сделать свой проект более масштабным и дорогим. Лучше графика, больше спец эффектов, больше срежиссированных синематиков, больше локации для игрового взаимодействия. И тут я бы не имел претензий если бы с развитием игр, никак не развивались бы и инструменты их разработки. Если раньше все делалось в ручную, и даже текстуры раньше ручками рисовали в фотошопе, то сегодня вы часто можете услышать такое слово как «процедурно-сгенерированный». Сейчас есть полно инструментов которые заметно упрощают работу художников, о которых я и хочу вам рассказать.
— Начнём с чего-нибудь по проще. Допустим нужно сделать игру в открытом мире, где полно всякой разнообразной растительности и на это потребуется очень много работы для проработки каждого деревца в каждом биоме, если бы не наше волшебное слово «процедурная генерация».
Сейчас на рынке есть такая великолепная утилита, как SpeedTree, которую уже используют многие студии. В ней можно создавать различную растительность в пару кликов, рандомизировать различные параметры, и выгружать уже готовые для игры модели деревьев, травы, лиан и прочей растительности. В которой учтена оптимизация, и поэтому в ней же можно создавать LODы для своих ассетов.
Как это работает? Вот бежим мы по локации и в упор подходим к нашему кролику что бы разглядеть его, и тогда движок нам выдаёт первого кролика на 69к треугольников. Отбегаем от него на небольшое расстояние, на котором мы уже не сможем различить мелкую детализацию, и вот уже движок выдаёт нам второго кролика на 2,5к треугольников и чем дальше мы отходим от нашего кролика, тем меньше на нём мы можем рассмотреть, а значит тем меньшую детализацию нам можно показывать и мы не заметим никакой разницы, а прирост FPS существенный.
-Но одних деревьев будет мало, нужен ещё и ландшафт. Что ж, и тут действует волшебство процедурной генерации. Есть множество инструментов в различных 3д пакетах и доступных движках, но давайте поговорим о специализированном софте. Перечислю только самые известные:
Если коротко, то эти программы позволяют генерировать фотореалистичные ландшафты. Да, у этих программ очень большой порог вхождения, но при должном умении, данные пакеты избавляют от очень большого количества ручной работы, что существенно ускоряет производство.
-Вот мы сделали наши биомы окружения и нам нужно наполнять локации уникальными для конкретного проекта архитектурными строениями и различными предметами. Казалось бы тут уже точно придётся всё делать самому с нуля. Но вот пришли Quixel megaskan и собрали огромнейшую библиотеку отсканированных материалов и ассетов.
Пожалуйста, вот тебе фотореалистичные материалы, которыми ты можешь красить своё окружение, и вот тебе достаточно большая библиотека фотореалистичных ассетов различных предметов окружения. Да для игровых проектов ещё нужно будет их оптимизировать, но всё это уже сильно упрощает работу художника.
-Вот мы нарисовали наше окружение, теперь нам нужны различные персонажи, за которых будем играть и с которыми будем взаимодействовать. Я сейчас не буду углубляться в дебри скульптинга персонаже, там хоть и появляются каждый год невероятные инструменты, они все ещё требуют ручную работу, но вот инструменты для облегчения работы, индустрия всё же представляет.
Представляю вашему вниманию утилиту Metahuman, в которой можно собирать персонажей, как в каком-нибудь редакторе персонажей из ММО, только гораздо более углубленном. С настроенным ригом, текстурами, и LODами, ок которых мы говорили выше. Может на каких-то проектах этого инструментария будет мало для главного персонажа, но вот собрать рядовых НПЦ, вполне возможно, причём с гораздо большим разнообразием чем в играх в которых всё делалось в ручную, где ты встречал одних и тех же прохожих из раза в раз.
Вот мы сделали персонажей, теперь нам их надо одеть. Можно в ручную рисовать одежду, что иногда даже легче чем как-то иначе, однако есть инструмент с названием Marvelous designer, который позволяет по выкройкам собрать нужный костюм, а при помощи инструментов симуляции физики реалистично помять его не обводя ручками каждую складочку.
Да, после Marvelous designer нужно ещё много работы, что бы добавить костюм в игру, однако он уже сэкономил тебе уйму времени, а симуляция физики хорошо работает не только с одеждой, но и с любыми тканями в принципе, будь то шторы, скатерти и прочие ассеты из ткани.
Также нельзя забывать о программах для анимации, например программа Cascadeur от отечественной студии Nekki.
Удивительная программа, с кучей инструментов, при помощи которых художник выставляет примерную анимаци, а Cascadeur додумывает её за художника, а художнику остаётся поправлять программу.
Нейросети в принципе сильно облегчают разработку, о чём уже подробно рассказал Алексей Макаренков в своём видео, очень интересно, советую посмотреть.
Тут можно и в 3D вьюпорте, и в 2D текстуре порисовать. И множество волшебных процедурных решений, значительно упрощающих жизнь и буквально рисующих за тебя.
А вот эта пугающая своим интерфейсом программа, хоть и сложна в освоении, предоставляет огромнейший инструментарий для создания процедурных тайловых текстур.
Можно ещё коротко затронуть фитчи, которые появятся в скором будущем. Наверное уже нет людей, интересующихся играми, которые не слышали про килер-фитчи Unreal engine 5. Я сейчас хочу рассказать о Nanite и Lumen.
-Nanite Потрясающая система, которая работает как система уже известных нам LODов, только делает она всё автоматически. Художнику не нужно рисовать отдельные уровни детализации, а просто загрузить объект в движок, а остальное программа сделает всё сама, и будет уменьшать или увеличивать детализацию объектов в зависимости от расстояния камеры от этих объектов. Что позволяет, как и обещали Epic games, на своих презентациях, строить сцены из запредельного количества полигонов.
Хочу предположить на сколько легче станет жить с данной технологией. Если ограничения по количеству полигонов в сцене сильно размывается, то можно оставлять честную геометрию, а не фэйкать её картами нормалей.
Для получения таких карт, мы честно прорисовываем все выпуклости, впадины, сколы и прочую мелкую детализацию, а потом грубо говоря фотографируем и переносим на плоскость такого же объекта только без детализации, что существенно позволяет сократить количество полигонов, не сильно теряя в качестве картинки. Но если с технологиями Nanite мы не сильно смотрим на количество полигонов, значит огромный пласт по рисованию карт нормалей можно просто игнорировать, а качество картинки станет только лучше.
Для тех кто не знаком с разработкой, объясню. В программе можно просчитать реалистичный свет, как в жизни с переотражением от объектов, что даёт нам мягкие тени и полутени, но если дать такую задачу программе, то 1 кадр будет просчитываться несколько часов, а чтобы играть в игры нам нужно как минимум 30 кадров в секунду. Поэтому для того чтобы и тени были красивыми и играть можно было, эти самые тени запекают в текстуры ( или если по проще, рисуют их на объектах), что вызывает ряд ограничений. Так если мы нарисуем красивую тень от объекта, то при перемещении этого объекта, тень останется на месте.
Поэтому у нас получаются 2 крайности, либо объект может двигаться, но тень у него максимально грубая, не имеющая полутонов, либо тень красивая, фотореалистичная, но объект всегда должен оставаться на месте. И данную проблему вызвался решить Ray tracing. Однако для него нужны специальные видеокарты, и он очень ресурсозатратный. И тут Unreal Engine 5 предоставляет Lumen, который делает почти всё тоже самое, но не так привередлив к железу, и кушает меньше FPS. А самое главное в нашей теме, что эта технология значительно сокращает количество работы для художников уровней.
Это ещё не все технологии значительно упрощающие разработку. Главное что они позволяют делать даже одному человеку больше, чем раньше делали целыми командами. Что доказывает проект, который в своё время навёл много шума.
Инфляция
Я не силён в экономике, однако было бы глупо отрицать существование инфляции. Валюта обесценивается и действительно условные 2000 рублей раньше стоили гораздо больше чем 2000 стоят сейчас. Но когда разработчики говорят о всех удорожаниях разработки, почему-то никто не говорит о том что сам рынок видео игр стал гораздо больше. Продавать информацию, не тоже самое что продавать материальные предметы. От увеличения количества проданных копий расходы на сырьё не увеличиваются. Если конечно не брать в расчёт физические носители. Но у тут никто из разработчиков не приводит статистику, о том на сколько часто покупали диски раньше и покупают сейчас. И не трубят о том как пытаются бороться со вторичным рынком, выпуская версии консолей без дисковода со значительно меньшим ценником в отличии от версии с дисководом.
Всё это очень сложная тема, и трудно говорить о подорожании разработки, не имея всех цифр на руках, однако очень удобно говорить о том что подорожало, не говоря о том что подешевело.
