пятница, 20 июля 2018 г.

dlib 0.14.0

На днях состоялся очередной релиз библиотеки dlib - 0.14.0. Из основных нововведений отмечу следующее:
  • SuperImage.pixelFormat теперь возвращает значение типа uint. Это было сделано для того, чтобы можно было расширять dlib.image новыми пиксельными форматами. Значения от 0 до 255 зарезервированы для dlib и используются в стандартных константах PixelFormat. Вместо PixelFormat.RGBA_FLOAT рекомендуется использовать FloatPixelFormat.RGBAF32 из dlib.image.hdri, поскольку в будущем будут добавлены новые float-форматы.
  • Реализовано сохранение изображений в формат Radiance HDR/RGBE (ранее была доступна только загрузка).
  • Добавлены новые фильтры: dlib.image.filters.histogram, dlib.image.filters.binarization.
  • Добавлен новый tonemapper - hdrTonemapACES.
  • Улучшен dlib.image.canvas. Растеризатор фигур Безье теперь поддерживает антиалиасинг (ранее антиалиасинг осуществлялся путем растеризации псевдоконтура алгоритмом Ву). Исправлен баг с рендерингом на неквадратных холстах.
  • В dlib.audio.synth добавлен объектно-ориентированный фреймворк для создания звуковых синтезаторов. Доступны три встроенных синтезатора: SineWaveSynth, SquareWaveSynth, FMSynth. Для рендеринга звука с произвольным синтезатором есть две функции - fillSynth и mixSynth.
  • Добавлен модуль dlib.math.smoothstep с реализациями сигмоид: hermiteSmoothstep, rationalSmoothstep.
  • Добавлена поддержка DMD 2.081.0 в dlib.core.stream.
Важно: начиная с 0.14.0, dlib не поддерживает macOS. О причинах этого бойкота я ранее высказывался в блоге. Скорее всего, функциональность, основанная на POSIX, продолжит работать нормально, но никаких гарантий на будущее нет, и проблемами совместимости с macOS, если они возникнут, я заниматься не буду. Непрерывная интеграция для macOS на Travis также была остановлена. В общем, рекомендую перейти на Linux, FreeBSD или Windows.

P.S. На сайте LightHouse Software за последние месяцы вышли две мои новые статьи:
Хочу также отметить статью aquaratixc Бинаризация методом Оцу в dlib, код из которой вошел в состав dlib 0.14.0.

P.P.S. К сожалению, пока не могу сказать, когда выйдет новая версия Dagon с отложенным рендером. Очень многое еще нужно дописать и реализовать. Но по завершении работы над Dagon 0.9 я планирую перевести на него Atrium, так что самое интересное только начинается.

четверг, 12 июля 2018 г.

Мысли о freeware

Будучи убежденным сторонником СПО, я часто задумываюсь, почему до сих пор существуют закрытые бесплатные программы (freeware)? В чем, как говорится, прикол? Их все еще очень много, и авторы даже не планируют их открывать. Я могу понять крупные компании, вложившие в свои коммерческие продукты миллионы долларов, но никогда не пойму энтузиастов, которые боятся выкладывать исходники своих персональных проектов.

Мне встречалось множество разных взглядов на этот вопрос, но все они сводятся к следующим основным пунктам:

1. Нежелание потерять контроль над проектом. Совершенно иррациональный страх - хотя бы потому что таких прецедентов попросту не было. Да, были случаи, когда форк становился популярнее оригинала, но еще ни разу никто не отбирал у изначального автора право развивать его детище так, как он хочет. Как он может "потерять контроль"? Эту мантру повторяют многие, но в ней нет и капли смысла. То, что под ней подразумевается - появление в одночасье сотен форков, несовместимых между собой - не более чем продукт чьей-то больной фантазии. В реальности же никто ничего не форкает без серьезной на то причины. Да, СПО - это анархия, где все делают, что хотят. Но это анархия разумных и опытных людей, и их суммарные усилия дают положительный результат, а не ноль. В противном случае движение СПО давно бы уже заглохло.

2. Страх оказаться обокраденным. Вторая по популярности фобия - многие боятся, что кто-то украдет их исходники, скомпилирует и будет продавать за деньги. Это теоретически возможно, но дело в том, что в случае со свободным ПО понятие кражи кода лишается всякого смысла - все свободные лицензии разрешают коммерческое использование, иначе они не были бы свободными. Вообще я бы не бросался словом "украсть" применительно к нематериальным объектам. К апологетам этого слова у меня много риторических вопросов. Как можно украсть то, что доступно всем? Кто станет покупать то, что в другом месте раздается бесплатно? Если вы считаете, что вашу программу будут покупать под чужим брендом, почему вы сами ее не продаете? Если вы не ведете бизнес, то почему беспокоитесь о недополученной прибыли? И так далее, и тому подобное... И я уже молчу о том, что открытие исходников никоим образом не мешает продавать программу - если хотите извлекать прибыль, можете, например, продавать бинарники.

3. Страх потерять репутацию из-за действий злоумышленников. Кто-то может взять ваши исходники, встроить вирусы-шпионы-бэкдоры, выдать за оригинал и наживаться на несчастных, ничего не подозревающих пользователях, а обвинять будут вас. Звучит пугающе, но, опять-таки, начисто лишено рационального зерна. Вы всегда можете (и должны) дать понять пользователям, где именно находится официальный источник сборок, чтобы скачивали только оттуда (а из других источников - на свой страх и риск). И вы никоим образом не отвечаете за чужие деструктивные действия с вашим кодом - вы даже не отвечаете за корректную и безопасную работу оригинального кода, потому что любой свободный софт распространяется без каких бы то ни было гарантий.

4. Ну и, наконец, то, в чем не каждый признается - нежелание показывать публике свой быдлокод. Могу сказать честно - чужой код мало кто читает, каким бы классным он ни был. Обычно это нужно для исправления багов, во всех остальных случаях люди просто компилируют исходники или копипастят отдельные компоненты, не вникая в детали. Поэтому большая часть программ представляет собой уродливых нечитаемых монстров, и с этим все давно смирились. Конечно, бывает и такой код, который можно смело в рамочке на стенку вешать - читаемый, лаконичный, красивый - но такой встречается очень редко.
Тот, кто все-таки захочет разобраться в вашем коде, вряд ли будет вас публично высмеивать - если, конечно, вы сами не попросите критики. Творчество есть творчество - любой имеет на него право, и никто из нас не идеален. Если вы не публикуете код только из страха критики, то я вас уверяю - бояться абсолютно нечего. Напротив, открытие плохого кода может стать важным шагом на пути саморазвития.

Я, конечно, уважаю авторское право и не считаю, что мне кто-то что-то должен. Открывать или не открывать код - личное дело автора. Есть много закрытых программ с солидным сообществом, и может показаться, что в исходниках там никто особо и не нуждается, пока автор регулярно выпускает релизы и исправляет баги. Но я должен предупредить: стоит автору потерять интерес, как сказка закончится. Поскольку программа бесплатна, у автора нет перед вами никаких обязательств, и вы останетесь с носом. Я видел десятки таких примеров, и в том числе среди коммерческих продуктов.
Никогда не стоит забывать Столлмана: используя закрытые программы, вы становитесь зависимым и беспомощным. Поэтому я предостерегаю от использования freeware - лучше отдайте предпочтение СПО.

среда, 20 июня 2018 г.

Dagon - новое видео

Выложил новое видео Dagon с демонстрацией отложенного рендера и освещенных мягких частиц:



Также сделал сайт для движка:
https://gecko0307.github.io/dagon

понедельник, 18 июня 2018 г.

OpenGL на macOS. Продолжение

В связи с возникающими вопросами по поводу работы Dagon под macOS, я считаю нужным еще раз, более развернуто объяснить суть своей позиции относительно Apple и недавней новости о прекращении поддержки OpenGL на macOS. Для англоязычных пользователей dlib я написал нечто вроде манифеста в формальном тоне, а тут выскажусь более свободно.

Лет пять назад я прочитал на MSDN утверждение Microsoft о том, что OpenGL - "устаревшая технология". Тогда я только посмеялся. Всем прекрасно известно, что задачу по поддержке OpenGL берут на себя производители видеокарт, а не операционных систем. Никому на самом деле не важно, насколько хороша нативная поддержка OpenGL в Windows - все равно все устанавливают драйвер от производителя видеокарты. Сейчас же ситуация несколько иная - под macOS вообще никогда не было другого OpenGL, кроме нативного. Это вынуждает разработчиков принимать политическое решение, и я свое принял.

В настоящее время полноценного аналога OpenGL для кроссплатформенной разработки не существует. Direct3D есть только под Windows, Metal - только под macOS, а Vulkan не является прямым аналогом OpenGL. Прекращение поддержки OpenGL в macOS влечет необходимость поддерживать в приложении несколько графических API. Это сложная задача, полноценно решать которую способны только коммерческие компании путем найма отдельных программистов на каждый бэкенд. Любителям, инди-разработчикам и мейнтейнерам СПО необходимость поддерживать несколько API сильно усложняет жизнь (очень сильно!), не давая взамен абсолютно никаких преимуществ. Самым очевидным выходом остается просто забить на macOS.

Да, возможно, немного обидно потерять часть своих пользователей - и только лишь! Если вы раздаете свою работу бесплатно, вас это не должно особо волновать. Я могу назвать десятки операционных систем, на которых ваш код не только не заработает, но даже не скомпилируется, на каком бы графическом стеке он ни был основан. Для реального мира поддержка этих ОС не имеет никакого значения. Если ОС не предоставляет стандартный API (а тем более такой важный в наше время, как графический), значит, она не стоит того, чтобы ее поддерживать. Технологии усложнились, на дворе уже не 90-е, чтобы каждый студент мог на коленке реализовать по бэкенду для кучи несовместимых платформ. Повторяю: забить, как в свое время забили на DOS, OS/2, IRIX, NeXT и еще много чего.

По этому поводу очень хорошо выразился Саймон Рот, автор игры Maia: "I won't port thousands of lines of my engine to a non standard proprietary API. Neither will many other developers either on principle or due to OSX's tiny install base. Here lies the end of games on Apple's desktop platform. Hundreds of thousands of older games will no longer run and there will be no economic incentive for the developers to rewrite their code. Even those using off-the-shelf engines would need to spend time and money to port to a newer release and retest. It's sad. Games are made of code that goes stale by design. That's bad, but by using open high level APIs and standards we can keep them alive and supported for much, much longer".

Дословный перевод: "Я не буду портировать тысячи строк кода моего движка на нестандартный проприетарный API. И этого не будут делать другие разработчики - из принципа или из-за небольшой пользовательской базы. Это конец игр на десктопной платформе Apple. Сотни тысяч старых игр больше не будут работать, и для их разработчиков не будет экономического стимула переписывать их код. Даже те, кто использует готовые движки, должны будут потратить время и деньги на портирование на новую версию и повторное тестирование. Это грустно. Код игр всегда устаревал со временем, и это плохо, но, благодаря использованию открытых высокоуровневых API и стандартов, мы можем сохранять их в живых и поддерживать еще очень долго".

среда, 6 июня 2018 г.

OpenGL на macOS

После многолетней эпопеи с кривыми драйверами Apple отказалась-таки от поддержки OpenGL в пользу своего проприетарного платформоспецифичного API Metal. В связи с этим я объявляю бойкот Apple и ее продуктам - мне стало понятно отношение этой компании к открытым стандартам (и я уж молчу про профессиональный сектор, VFX, анимацию и т.д). Отныне я не заинтересован в улучшении поддержки macOS в движке Dagon. Непрерывная интеграция Travis под macOS также будет остановлена для всех моих проектов. Призываю поступить схожим образом и прекратить выпускать игры под платформу, которая вынуждает вас привязывать свои программы к несвободным технологиям.

понедельник, 4 июня 2018 г.

GitHub и Microsoft

Узнал о покупке GitHub корпорацией Microsoft за $7,5 миллиардов. Очень надеюсь, что эта сделка не скажется на качестве сервиса, и мы не столкнемся с чем-то вроде MSVS Community Edition, для использования которого требуется привязка к аккаунту на серверах MS, или Skype с его вездесущей рекламой. А то и вовсе могут прикрыть, история знает случаи. В случае чего, конечно, можно переехать на BitBucket.

пятница, 1 июня 2018 г.

Patreon

Я решил запустить краудфандинг на Patreon: https://www.patreon.com/gecko0307. Упор, в основном, на три моих главных проекта - dlib, Dagon, dmech. Если я наберу ежемесячное финансирование в $100, то допишу документацию по dlib. Если $500, то буду заниматься разработкой dlib, Dagon и dmech в режиме полного дня, включая написание документации и новых уроков. Все, кто пожертвует $10 и выше, будут перечислены в списке спонсоров в репозиториях и на сайтах проектов.

среда, 30 мая 2018 г.

Освещение частиц

Работаю над освещением частиц:


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

Тени от частиц

Добавил поддержку теней от частиц:


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

вторник, 29 мая 2018 г.

Карты окружения в отложенном рендере

Несколько новых скриншотов отложенного рендера:


В ближайшее время планирую реализовать поддержку кубических карт с полноценным интегрированием Монте-Карло (сейчас используются равнопромежуточные карты с простым box-фильтром, формируемые стандартным mip-генератором OpenGL, что, конечно, дает достаточно далекий от физически корректного результат, хотя и визуально приемлемый). Также обдумываю вариант загрузки кубической карты из файла DDS, что позволяет строить мип-уровни в сторонних утилитах типа CubeMapGen.

понедельник, 28 мая 2018 г.

Dagon 0.8.0. Deferred Shading на подходе

На днях вышла новая версия Dagon - 0.8.0. Основные нововведения включают собственный формат движка для хранения моделей и сцен, который можно экспортировать из Blender, специализированный материал для частиц, исправленный рендеринг прозрачных объектов. Dagon теперь требует OpenGL 4.0 (из-за необходимости функции glBlendFunci). Полный список изменений см. на странице релиза.

Вскрылись проблемы с работой движка под macOS - поскольку у меня нет возможности тестировать его под этой ОС, поддержка Mac отныне не гарантирована. Но буду благодарен, если кто-то исследует эту проблему и предложит решение.

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


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

воскресенье, 27 мая 2018 г.

Интерполяция на основе сигмоиды

Для одного из шейдеров на GLSL мне потребовалась "умная" интерполяция цветов с возможностью изменять резкость перехода от одного значения к другому - от полностью плавного (линейного) до дискретного. В итоге получилась вот такая функция, которую я вывел на основе рациональной сигмоиды - может быть, кому-то пригодится:

float sigmoid(float x, float k)
{
    return (x + x * k - k * 0.5 - 0.5) / (abs(x * k * 4.0 - k * 2.0) - k + 1.0) + 0.5;
}

При k = 0 функция обращается в линейную, при k = 1 - разрывается в точке 0,5. Вы можете увидеть, как это работает, при помощи интерактивного графика на Desmos: https://www.desmos.com/calculator/s0cwcrtzvs.


Результат этой функции передается в привычный mix - то есть, вместо mix(c1, c2, t) пишем mix(c1, c2, sigmoid(t, k)). Получится, например, такое:


(градиенты гамма-скорректированы)

суббота, 19 мая 2018 г.

Экспорт в Dagon из Blender

Работаю над экспортером контента для Blender. Для хранения сцен я решил использовать свой контейнер Box, в который пакуются меши в формате OBJ, текстуры и файлы с описаниями объектов и материалов. Формат поддерживает граф сцены - то есть, объектам можно назначать родителей.


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

четверг, 17 мая 2018 г.

dlib 0.13.0 и Dagon 0.7.0

На днях состоялись новые релизы двух основных моих проектов - dlib 0.13.0 и Dagon 0.7.0.

Изменения в dlib:
  • Из основной ветки был удален пакет dlib.async. Решение об удалении было принято из соображений безопасности. К сожалению, у пакета в настоящее время нет активных мейнтейнеров, некому исправлять баги, поэтому я посчитал dlib.async недостаточно стабильным для существования в качестве официальной части dlib - хотелось бы, чтобы все компоненты dlib были в одинаковой степени актуальны и поддерживаемы. dlib.async продолжит существование в рамках ветки async, но пользователям рекомендую обратить внимание на более актуальные и законченные асинхронные движки - такие, как vibe-core
  • Добавлен модуль dlib.image.canvas с реализацией класса Canvas - векторного рендер-движка с интерфейсом, похожим на HTML5 canvas. В настоящее время он поддерживает отрисовку полигонов и фигур Безье с заливкой и контуром. Рендеринг осуществляется в заданное пользователем изображение SuperImage.
  • Улучшен декодер файлов Radiance HDR/RGBE - теперь он читает файлы, начинающиеся со строки "#?RGBE"
  • Добавлены функции tone mapping'а (hdrTonemapReinhard, hdrTonemapHable), новые алгоритмы выделения краев (edgeDetectLaplace, edgeDetectSobel), новые методы для структуры Color4f (toLinear, toGamma)
  • Добавлены новые функции для векторов (reflect, refract, faceforward)
  • Добавлены функции для вычисления касательного вектора кривых Безье (bezierTangentVector2, bezierTangentVector3).
Изменения в Dagon:
  • Полноценный HDR-рендеринг с автоматической экспозицией и tone mapping'ом
  • Поддержка HDR-карт окружения в формате Radiance HDR/RGBE
  • Улучшенные каскадные тени (более эффективное заполнение каскадами пирамиды видимости)
  • Переписан весь код, отвечающий за PBR. Теперь используется модель Кука-Торренса вместо Блинна-Фонга. Добавлена поддержка текстур шероховатости (roughness) и металличности (metallic)
  • Переписана система пост-обработки. Все фильтры теперь являются частью стандартной сцены (BaseScene3D), их остается только включить и настроить. Добавлены фильтры размытия при движении, свечения и цветокоррекции (LUT), улучшен фильтр хроматической аберрации
  • Улучшено встроенное процедурное небо - теперь движок сам генерирует геометрию небесного купола
  • Добавлены слои для сортировки объектов при рендеринге
  • Камера от первого лица облегчает рендеринг оружия в шутерах, предоставляя матрицу оружия
  • Улучшена поддержка джойстиков, добавлена поддержка рулей
  • Dagon теперь использует dlib 0.13.0.
Обновление демонстрационного приложения с использованием Dagon 0.7.0 планируется в ближайшие дни.

вторник, 15 мая 2018 г.

Улучшенные glow и lens distortion

Реализовал более качественный многопроходный эффект свечения и адаптировал шейдер хроматической аберрации из Wagner:


Пост-обработка в Dagon теперь стала намного проще - все встроенные фильтры легко включаются/выключаются и настраиваются при помощи специального API, являющегося частью класса BaseScene3D. Есть и возможность добавлять свои фильтры.

понедельник, 7 мая 2018 г.

Тени с учетом карты высот

Обычные теневые карты ничего не знают о рельефе поверхности и ведут себя так, будто она гладкая. Но если у нас есть parallax mapping и, соответственно, данные о высоте фрагмента, можно улучшить картинку путем смещения не только текстурных координат, но и теневых:

vec4 shadowCoord = shadowMatrix * vec4(eyePosition + eyeNormal * height * 0.3, 1.0);


Таким образом, мы создаем фейковую точку, расположенную выше реальной поверхности, и тень для нее будет рассчитываться как если бы поверхность была действительно рельефной. Эффект особенно заметен на краях тени, углах и скруглениях - там, где при обычном расчете теневых координат была бы сплошная тень, появляются освещенные участки:


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

Не знаю, использовалась ли такая техника раньше, и как она называется - может быть, что-то вроде height-corrected shadow mapping?

вторник, 1 мая 2018 г.

Улучшенный color grading

Мне удалось избавиться от эффекта бэндинга при цветокоррекции с использованием таблицы цветов - скоро все изменения будут доступны в репозитории.

четверг, 19 апреля 2018 г.

Уроки по Dagon

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

Также недавно я получил в свое распоряжение руль, и, соответственно, добавил поддержку рулей в Dagon (вернее сказать, улучшил уже существовавшую обертку над API ввода SDL2). Пример Dagon с машиной уже работает с рулями - надеюсь скоро выложить видео.

Планы на будущее следующие: в ближайшее время собираюсь довести до ума поддержку PBR-материалов, после чего выпустить Dagon 0.7 с новым HDR-рендером. Дальше, скорее всего, буду смотреть в сторону deferred rendering, поскольку на прямом рендере стало уже сложно получать современную картинку.

воскресенье, 18 марта 2018 г.

Почему не Go?

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

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

Go игнорирует весь опыт и успехи языкотворчества последних 30 лет.  Отсутствие шаблонов, нормального ООП, перегрузки функций и операторов, арифметики указателей - все это не имеет ничего общего с идеей простоты, о которой любят говорить евангелисты Go. Это реакционизм, желание закрыть глаза и не видеть современных задач, решение которых требует современных инструментов. Язык застрял в 70-х - технологии должны стремиться к простоте, но не к опрощению.

Go использует сборщик мусора. В D он тоже есть, но там можно написать свои собственные шаблонные New и Delete и писать в стиле C++, просто игнорируя сборщик мусора. Если вы попытаетесь сделать что-то подобное в Go, вам будут мешать все силы ада. Линус Торвальдс как-то сказал, что язык не может считаться системным, если он пытается скрыть от программиста механизм выделения памяти ("Any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel"). Он, правда, имел в виду C++, но тем не менее.

В Go неэффективная костыльная совместимость с C. Не знаю, как для других, но для меня C.int и C.char - это вырвиглазный ужас. Я уже не говорю о том, что вызов внешней функции в Go влечет переключение контекстов - учитывая, что ни один нормальный проект не обходится без библиотечных вызовов, тут уж просто без комментариев.

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

Подводя итог: хайп вокруг этого языка мне совершенно не понятен. Я не знаю, в каких именно областях хорош Go - какую ни возьми, везде найдется более подходящий язык. Для игр он точно не подходит. Go обычно позиционируется как современная замена C, но когда заходит речь о реальных задачах, которые решаются при помощи C, евангелисты Go кричат, что они не входят в область применения языка. Так чем же она ограничена, эта область? Консольными утилитами? Если выбирать между Go и C, то я уж лучше выберу C.

пятница, 26 января 2018 г.

HDR уже здесь

Все улучшения, которые я сделал в Dagon за последние месяцы, доступны в репозитории движка. Обновлено также и демонстрационное приложение. Изменения касаются, главным образом, рендера - Dagon теперь полностью основан на HDR. Используется автоматическая экспозиция (динамическая адаптация к освещению), поддерживаются операторы тональной компрессии Reinhard и Hable/Uncharted. Движок теперь понимает файлы Radiance HDR/RGBE, которые можно использовать в качестве карт окружения.


Также появилась поддержка motion blur (который делается все в том же широком диапазоне), а все доступные фильтры постобработки стали частью стандартной сцены (BaseScene3D). В будущем надеюсь сделать их более настраиваемыми, а также добавить новые фильтры.