что такое pom в шейдерах
Всем добрый день 🙂
Искал шейдер parallax occlusion mapping’a. Понравился пример в amd rendermonkey. После перевода к себе в приложение, увидел глюки. Проэкспортировал свою геометрию в 3ds и посмотрел, как она себя ведёт в rendermonkey. Оказалось, что и здесь глючит. Тот же самый глюк возникает и в directx sdk. Скрины прилагаются:
чет тбн наверно кривой, либо косяк где-то в расчете вектора смещения.
vip_open
> Проблему «неверного» (некорректного) тбн исключаю.
окей 😉
что тогда нужно сделать для rendermonkey, чтобы считался тбн в ней так как надо для моей модельки? 🙂
или есть какие то особенности моделинга под pom?
fzr125, вообщем, разглядываю tbn и вижу, что эти вектора не ортонормированны? это нормально?
vip_open
> это нормально?
нет.
кстати, рендерманки при выщитывании тбн учитывает эффект зеркала? а то вроде на скринах он присутсвует.
вроде это вся левая часть дома, отрисована без учета эффекта зеркала.
расчитывай тбн по сглаженным нормалям, в максе они для каждой вершины разные, такие нормали перпендикулярны не текушей низкополигональной геометрии, а как бы расчитаны для такой же модели, только высокополигональной, ну кароче не могу объяснить 🙂
Я сделал пару снимков tbn. Посмотрите, всё ли верно я посчитал?
normal_object_space 
tangent_object_space 
binormal_object_space 
binormal_object_space (restored) 
binormal_object_space (mirror off) 
normal_view_space 
tangent_view_space 
binormal_view_space 
binormal_view_space (restored) 
binormal_view_space2 
binormal_view_space2 (restored) 
Ну а самому проверить свой расчет трудно?
ну я делал так: 
fzr125 спасиб 🙂
я в принципе так и проверил! всё сходиться!
Вдруг заметите глюк какой-нить. всё равно ниодин пример не катит ( на этой модели дома
Learn OpenGL. Урок 6.1. PBR или Физически-корректный рендеринг. Теория
Комментарии 13
Как-то слишком долго и сложно, но не сказано главного. PBR — это промышленный стандарт подхода к материалам. Технически представляет собой от 3 до 5 текстур на материал: основной цвет, нормали, шероховатость, опционально displacement, опционально AO, опционально металличность. Не то чтобы это имело ахти какое отношение к физике — просто это действительно удобная модель описания материалов. Про физические свойства поверхностей любой желающий может почитать со всеми мат. выкладками и разными моделями освещения в любой более-менее глубокой статье про трассировку лучей. Это действительно важно если вы собираетесь сделать свой PBR-шейдер или трассировщик лучей, поддерживающий PBR-материалы.
Так вот, эти текстуры накладываются в соответствии с общей UV-раскройкой, но семантическое значение у них разное. Создавать их удобно, например, в Substance Designer (дорисовывая отдельные непаттернящиеся артефакты в Substance Painter). Всё вместе при известных положениях источников света довольно прямолинейно рисуется в шейдере.
Самое сложное тут — displacement, который для действительно вкусного результата должен иметь в распоряжении модель из сумасшедшего числа полигонов. В 3D-редакторах это исполняется одноимённым модификатором + комбинацией subdivide-ов (есть попытки перенести в рендер, например в Radeon Render, Cycles Render — пока что это экспериментальная фича). В играх же для отрисовки дисплейсмента применяется хитрый дым и зеркала под названием Parallax Occlusion.
Шейдеры в Unity — это не сложно. Часть 1 — Вступление
Будем разбираться в шейдерах
Вступление
То есть, для отображения любого 3D объекта необходимо иметь шейдер. При просчёте шейдера учитывается огромное количество информации, необходимой для корректного отображения: вершины, текстуры, освещённость, и так далее.
Есть множество типов шейдеров, вот некоторые из них:
Вершинные шейдера (vertex shaders)
Фрагментные (пиксельные) шейдера (fragment shaders)
Меш шейдера (mesh shaders)
Вычислительные шейдера (compute shaders)
Практика
Итак, предлагаю перейти к практике и написать простой шейдер. Будем писать unlit-шейдер. Unlit-шейдер это шейдер, который при просчёте объекта не учитывает освещение.
Полный код шейдера
к примеру, переменная текстуры будет выглядеть следующим образом:
_MainTex («Texture», 2D) = «white» <>
а переменная для цвета вот так:
_SpecColor («Specular color», color) = (1., 1., 1., 1.)
Доступные типы данных
Range(min,max) = number float в промежутке от min до max
Vector = (numer,number,number,number) x,y,z,w
Color = (numer,number,number,number) r,g,b,a
2D = «defaulttexture» <> 2D текстура
Cube = «defaulttexture» <> Кубическая текстура
После блока с переменными, обязательно должен быть блок SubShader. Их может быть несколько. В этом блоке шейдера определяется логика работы шейдера, в том числе логика на языке GLSL. Шейдер может содержать несколько сабшейдеров с различной логикой для различных видеокарт. Начинается сабшейдер с указания тегов.
В данном случае мы указываем что объект следует отрисовывать как непрозрачный. Далее по коду следует блок Pass, или проход шейдера. Внутри данного блока будут писаться вертексные и фрагментные части шейдера. Ключевые слова CGPROGRAM и ENDCG указывают блок шейдера на языке GLSL. Следовательно CGPROGRAM открывает блок кода, а ENDCG, соответственно, закрывает его. Далее идут две директивы:
Вот этой строчкой #include «UnityCG.cginc» мы подключаем библиотеку со вспомогательными и наиболее полезными функциями. Подробнее про это библиотеку можно прочитать вот тут.
Далее мы указываем данные, которые нам будут необходимы для нашего шейдера.
Эти переменные будут использоваться внутри программы на языке GLSL. Для корректного маппинга переменных из блока Properties в переменные GLSL необходимо соблюдать нейминг. Названия переменных должны совпадать.
Итак, разобрав множество нюансов, мы наконец-то подошли к реализации логики шейдера. Рассмотри вершинную часть шейдера:
Теперь рассмотрим фрагментный шейдер:
На этом пока что всё. Пишу первый раз, поэтому буду рад конструктивной критике. В дальнейшем планируется ещё несколько частей. Разберём амбиентные шейдеры, шейдеры воды, ткани, вычислительные шейдеры и много чего другого интересного.
Шейдеры в Unity — это не сложно. Часть 2 — диффузный шейдинг
Будем разбираться в шейдерах
Всем привет! Благодарен всем за замечания и комментарии к предыдущей статье. Благодаря всем нам мы наполняем интернет доступными знаниями и это действительно круто.
Сегодня продолжаем разбираться с шейдерами, а именно с работой с освещением. Рассмотрим тип освещения Ламберта, познакомимся с диффузным шейдингом, и, как обычно, напишем и разберём AD шейдер (Ambient Diffuse).
Теория
Итак, начнём наше знакомство с типом освещения Ламберта (Lambertian reflectance).
Поглощение и отражение света
Перенося это всё на Unity, данный физический процесс можно разбить на следующие составляющие:
Источник света излучает свет
Свет падает на объект, отражаясь и рассеиваясь.
Отражённый свет попадает в камеру и мы получаем картинку.
В Unity источник света описывается точкой в пространстве, а мощность (или количественная величина света) описывается параметром освещённости (Intensity). Поскольку в модели освещения Ламберта угол обзора не имеет значения, мы будем видеть один и тот же цвет со всех сторон.
Возвращяясь к реальности, рассмотрим пример освещения участка с криволинейной поверхностью. Когда луч света падает на поверхность гладкого объекта, свет отражается. Так как лучи света парралельны, то в случае с гладким объектом отражённые лучи будут также параллельны. Это регулярное отражение называется однонаправленным отражением или зеркальным отражением света. Но гладкость объектов относительна, и, как правило, представляет собой шероховатую и неровную поверхность. В таком случае падающие лучи являются параллельными, а отраженные лучи будут рассеиваться во всех направлениях. Это явление является диффузным отражением света.
Отражение света на криволинейной поверхности
Как можно заметить, в участках с солнечными лучами, падающими под прямым углом, интенсивность света будет выше, в то время как на участках, где свет падает не прямолинейно, освещённость будет ниже. Тот же сценарий должен повториться и для диффузного шейдера.
Характеристики диффузного освещения:
Интенсивность освещённости пикселя не зависит от угла обзора.
Интенсивность освещённости зависит от угла падения света на поверхность.
Итак, нам нужно понять, что нужно для вычисления цвета каждого пикселя в каждой точке. В модели Ламберта поверхность объекта описывается как поверхность с идеальным отражением( возникает только диффузное отражение). Рассмотрим формулу для расчёта окружающего освещения:
Формула для расчёта направленного света:
Формула вычисления направленного света несколько отличается от вычисления окружающего света. При вычислении отражения окружающего света не имеет значение его направление, так как окружающий свет не имеет направления (точнее направлен на все стороны). Поэтому окружающий свет одинаков для каждой вершины. В случае вычисления направленного света его направление имеет значение. Рассеивание направленого света зависит от расстояния до нормали. Чем ближе к нормали, тем сильнее рассеивание. Интенсивность диффузного отражения направленного света соответствует закону косинуса Ламберта. Таким образом имеем формулу:
У меня нет цели нагружать статью огромным количеством теории. На мой взгляд, все базовые моменты были рассмотрены, поэтому предлагаю закончить с теорией и перейти к практике.
Практика
Итак, немного разобравшись в том, как работает свет в Unity, и в том, как нам его применять в шейдере, перейдём к написанию шейдера. Напомню, мы будем писать шейдер AD (Ambient diffuse)
Полный код шейдера
Далее при помощи ключевого слова CGPROGRAM мы объявляем раздел шейдера на языке GLSL. Мы будем использовать такие же наименования, как и в предыдущей главе, а это значит, что #pragma vertex vert объявляет в качестве вершинного шейдера функцию с именем vert, а #pragma fragment frag в качестве фрагментного шейдера функцию с именем frag. Строчкой #include «UnityCG.cginc» мы подключаем библиотеку со вспомогательными и наиболее полезными функциями. Кто хочут узнать больше про эту библиотеку, можно прочесть про неё вот тут.
Движемся по коду дальше и определяем скруктуру данных для фрагментного шейдера:
Более подробно расписано в документации. Далее следует объявить блок переменных, которые будут использоваться в шейдере. В нашем случае это:
Для вычисления нам необходимо будет вычислить следующие данные:
единичный вектор направление освещения;
нормаль в мировых координатах;
позицию в мировых координатах;
Получаем соответствующие вычисления:
Итак, все необходимые для вычисления данные получены, приступаем к рассчёту освещения. В первую очередь рассчитаем окружающее освещение:
Здесь для рассчёта окружающего света мы перемножаем интенсивность освещения и цвет. Далее рассчитываем диффузное освещение:
Здесь мы рассчитываем диффузное освещение по формулам которые были описаны выше в теории. Далее нам осталось сложить окрущающий и диффузный цвет:
Есть. Рассчёт освещения окончен. Для окончательного формирования выходной структуры данных нам осталось лишь передать uv координаты.
Есть. Шейдер написан. Осталось проверить его в Unity.
Походу что-то сломалось, не могу вставить гиф, посмотреть можно тут
Как можно видеть, шейдер отрабатывает корректно, интенсивность и цвет можно менять через переменные шейдера.
Также проверим работу шейдера с освещением:
Походу что-то сломалось, не могу вставить гиф, посмотреть можно тут
Как можно видеть, всё работает корректно, освещённость объекта меняется в зависимости от изменения параметров источника освещения.
На этом пока что всё. Спасибо за внимание. Знаю, статьи выходят не часто, но постараюсь исправиться и писать больше. Читаю все ваши комментарии, рад объективной критике и замечаниям.
Вторая жизнь вместе с Maven
Думаю, для большинства хабражителей не будет откровением, что среди крупных софтварных разработок нередко встречаются технологии и языки значительно отстающие от передовых. К сожалению, это неизбежность, т. к. невозможно в какой-то момент взять и переписать несколько миллионов строк кода на другой язык или с применением более современного фреймворка.
Но в какой то момент отставание становится настолько существенным, что продукт перестает быть конкурентоспособен и постепенно исчезает с рынка. Именно такую ситуацию постепенного затухания мне и довелось наблюдать.
Здесь я хочу рассказать о том, как в конкретном случае я постарался оттянуть неизбежное и оживить разработку применив для этого сборщик проектов Maven.
Главным достоинством разработанной мною системы, пожалуй, можно назвать то, что небольшим количеством трудозатрат, можно при помощи Maven научить проект, реализованный на любом языке, собираться из отдельных Пакетов, соблюдающих свою версионность и автоматически обновляющихся при сборке проекта. Все что для этого нужно, это утилита командной строки, которая может скомпилировать исходник, а в случае скриптовых языков была бы полезна утилита валидации.
Итак дано:
— Система, «ядро» которой состоит из набора dll и отдается прикладным разработчикам без исходников.
— Прикладной язык программирования, который подобен Паскалю, но кроме стандартных возможностей Паскаля(из которых доступно далеко не все) позволяет использовать объекты, реализованные в dll «ядра». Данный прикладной язык компилируется в подобие байт кода и исполняется отдельной dll «ядра».
Таким образом, основная разработка ведется на описанном выше волшебном прикладном языке, все прелести которого, пожалуй, могли бы ужаснуть уважаемое сообщество, а «ядро» периодически(новая версия раз в пару месяцев) поставляется из головного офиса и не подлежит модификации.
Очень вероятно, что разработка и поддержание собственного языка программирования похожего на Паскаль и сделанного на базе Delphi возможно была плохой идеей, но 15-17 лет назад, когда все это начиналось, об этом никто не думал. Преследовались другие цели, которые в общем-то с успехом были достигнуты.
Сама система представляет из себя продаваемый заказчику продукт с сервером, клиентом и тонким клиентом. Естественно, большинство клиентов не удовлетворяются стандартным функционалом системы, поэтому существует несколько отделов прикладной разработки, “допиливающих”систему под их нужды. Каждым проектом занимается обособленная группа программистов. Взаимодействие и обмен опытом между группами катастрофически малы. Таким образом, каждая группа получает свой шанс переизобрести велосипед и наступить по десятому разу на одни и те же грабли.
Проведя анализ, стало понятно, что такое отсутствие взаимодействия отделов объясняется прежде всего нехваткой механизмов использования общего кода. Иными словами, если все-таки, происходил обмен опытом и исходниками между группами, то библиотека(исходник) просто копировалась в другой проект(продукт для друго клиента) и начинала жить самостоятельной жизнью, сохранив в себе все глюки и недоработки, которые присутствовали на момент копирования.
Для исправления ситуации было принято решение организовать репозиторий (хранилише) и систему сбора проекта с использованием набора библиотек общего кода(Пакетов).
В качестве инструмента для этого был выбран Maven, т. к. он по умолчанию выполняет схожие функции, имеет гибкий жизненный цикл и огромную гибкость плагинной системы.
Но обо всем по порядку
Главной проблемой, о которой я и не подозревал в начале своих изысканий, оказалось то, что Пакеты должны содержать в себе не скомпилированные в байт код файлы, а именно исходники, т.к. компиляция должна происходить именно под той версией «ядра», для которой они будут использоваться. Для простоты назовем наши прикладные исходники bpas. Это немного противоречит стандартному ЖЦ в Maven.
Немного о том как работает Maven
Жизненный цикл Maven достаточно полный, и набор фаз(phases) учитывает практически все этапы сборки проекта, которые могут потребоваться.
Причем пытаясь запустить какую-то фазу ЖЦ, например «mvn compile», я на самом деле запускаю всю цепочку фаз от validate (валидация проекта) до compile, не пропуская ни одной. Для каких-то фаз существуют так называемые плагины по умолчанию, которые будут вызваны несмотря на то, что в pom.xml(основной файл Maven проекта) существует только заголовок и ни одного указания на запуск плагинов.
Здесь стоит отдельно отметить тот факт, что Maven — это полностью плагинная система. Иными словами, он не умеет практически ничего, кроме запуска плагинов, а вот они уже умеют делать потрясающе много. Получается, что когда мы хотим научить Maven каким- то особенностям сборки проекта, мы должны добавить в pom.xml указание на запуск нужного плагина в нужную фазу и с нужными параметрами.
Вот такой абсолютно валидный пустой pom.xml, несмотря на свою пустоту, при получении команды mvn deploy запустит Плагин инициализации, компиляции, упаковки и деплоя Java исходников из папки src/main.
Основной политикой использования в Maven является то, что для любого действия есть свои параметры по умолчанию и дополнительные настройки требуются только в том случае, когда этих умолчаний не хватает или они грубо нарушаются. В моем случае пришлось отказаться от очень многих умолчаний, поэтому pom.xml уже не выглядит так скромно.
Построение нового ЖЦ в pom.xml
Для реализации пакетов был подобран следующий жизненный цикл.
initialize (инциализация) – Читаем настройки из конфиг(property или key = value) файла и добавляем их в тег properties. О теге properties поговорим чуть позже.
generate-sources (генерация исходного кода) – Загружаем и распаковываем из zip все Пакеты, которые являются зависимостями данного пакета/проекта, в отдельную директорию для последующей компиляции вместе с исходниками текущего пакета/проекта.
compile (компиляция) – Запускаем свой плагин компиляции для наших bpas, который определяет правильный порядок компиляции и запускает компилятор командной строки для нашего языка. Кратко я расскажу о собственном плагине ниже, но гайд по его написанию предлагаю вынести за пределы данной статьи.
assembly (сборка) – запаковываем пакет, состоящий из исходников bpas в zip с сохранением структуры подкаталогов исходных файлов.
deploy (в нашем случае выгрузка в репозиторий) – Собранный на фазе assembly zip отправляется в локальный репозиторий Maven с добавлением к нему pom.xml и другой информации по пакету. Данная процедура почти идентична нормальному deploy jar файла, но с особыми параметрами.
clean (очистка) – Данная фаза не входит в общий ЖЦ фаз сборки, а стоит несколько особняком, но поскольку она также была модернизирована, ее тоже стоит упомянуть. Кроме стандартного удаления директории, в которой лежат скомпилированные файлы. (targetDirectory), потребовалось удалять тот мусор, который образуется в процессе скачивания и распаковки пакетов-зависимостей.
Общая структура pom.xml
Я условно делю pom.xml на две части: заголовок и сборка.
Заголовок представляет из себя идентификацию пакета (groupId, artifactId, version), свойства (properties, которые выполняют роль внутренних констант), указание локального репозитория (distributionManagement), указание локального репозитория плагинов (pluginRepositories), указание локального репозитория пакетов (repositories) и указание зависимостей этого пакета (dependencies). При этом все три репозитория могут указывать на одно и то же хранилище, но принципиально это три разные сущности, каждую из которых нужно указывать отдельно. Так например, мы можем решить хранить плагины отдельно от остального кода, а для доступа к пакетам в хранилише использовать http доступ, тогда как «деплоить» туда мы будет как в файловое хранилище.
Сборка (тег build) — это вторая часть pom.xml, в которой настраиваются особенности обработки той или иной фазы жизненного цикла различными плагинами с недефолтными настройками. Кроме этого там настраиваются директории и параметры, которые будут участвовать в сборке проекта:
sourceDirectory – директория, в которой находятся исходники для компиляции.
finalName – конечное имя файла после запаковки в архив.
directory – рабочая директория, в которую будут положены скомпилированные файлы.
Кроме этого еще раз хочу напомнить, что для всех этих параметров, существуют значения по умолчанию, и их отдельное указание в нашем случае требуется только потому, что они должны отличаться от этих самых умолчаний.
Реализация ЖЦ в теге build
Теперь вернемся к определенному нами ЖЦ и посмотрим, как каждая из фаз жизненного цикла реализована при помощи вызова нужного плагина с той конфигурацией, которая нам нужна.
initialize
Тут опять давайте немного отвлечемся и отдельно упомянем тег properties. Объясним, зачем он нужен и как используется.
Если говорить очень грубо, то этот тег похож на объявление констант, которые в дальнейшем будут использоваться в нашей программе (pom.xml). Но попадать туда значения могут тремя разными способами. И у каждого способа есть приоритет, определяющий, какое в итоге значение будет в тот момент, когда оно реально потребуется.
Низший приоритет у прямой записи свойств в тег properties, например так:
Более высокий приоритет у прямого задания параметров при запуске Maven, примерно так «mvn –DhelloText=Hi initialize»
При запуске Maven с таким параметром исходное значение тега helloText будет заменено на переданное в строке запуска для текущего сеанса, т.е. в xml оно не сохранится. Если такой константы вообще не существовало, то на этот сеанс она будет существовать и может быть использована. Значения всех несуществующих констант — пустая строка.
Наивысшим приоритетом обладает добавление значений в тег proprties плагинами в текущей сессии. Они так же не сохраняться в pom.xml. Именно этот механизм и будет использован нами для вынесения отдельных настроек сборки в properties файл, содержащий “имя=значение”
Для этого используется плагин properties-maven-plugin
generate-sources
На стадии генерации исходников мы рекурсивно загружаем из репозитория и распаковываем все необходимые нам Пакеты, которые указаны в зависимостях. Опять же самим практически ничего делать не нужно. Все за нас сделает плагин после указания ему правильных настроек.
Конструкция $ означает, что нужно взять значение из тега “/project/properties/packagesPath”.
Отдельно хочу отметить, что использования плагина maven-assembly-plugin для распаковки считается deprecated и не рекомендуется к использованию в Maven 3. Вместо него используется maven-dependency-plugin с настройками аналогичными указанным выше. Я же использую более старую версию плагина, чтобы еще раз наглядно показать, как один и тот же плагин настраивается на выполнение нескольких задач из его ассортимента.
compile
Со стадией компиляции пришлось изрядно повозиться, но основные трудности возникли с написанием собственного плагина компиляции. Пошаговая инструкция по написанию собственного плагина для Maven — это тема для отдельной статьи, поэтому сейчас мы не будем заострять на этом внимание. В конце-концов изложенный здесь материал может быть использован и для скриптовых языков, компиляция которым вообще не требуется.
Одно можно сказать наверняка, как бы вы не старались, не удастся отключить запуск родного плагина maven-compile-plugin, призвание которого компилировать исходники на Java( Не рассматривая возможности редактирования superPom.xml). Итак настройки моего плагина компиляции выглядят следующим образом:
используемые параметры:
protectionServer — сервер защиты, без которого невозможен запуск компилятора командной строки.
protectionAlias — секция используемой лицензии сервера защиты.
bpasccPath — полный или относительный путь к компилятору командной строки.
binaryVersion — Версия, которая будет «вмонтирована» в скомпилированную библиотеку.
Это далеко не все настройки моего плагина, но как я и говорил, это тема для отдельной большой статьи. В принципе секцию configuration можно было вообще не указывать и тогда все параметры, которые необходимы плагину, были бы проинициализированы плагином значениями по умолчанию, что соотвествует основной концепции Maven.
assembly
При прохождении фазы assembly у Maven по умолчанию настроен запуск maven-assembly-plugin, явно указав его запуск в фазе assembly в теге build, мы можем переопределить его настройки и заставить работать на нас. Этот же плагин мы использовали для распаковки пакетов перед компиляцией, поэтому теперь я приведу полную версию настроек этого плагина, включающую и запаковку и распаковку.
packagesDirName — это константа из /project/properties файла pom.xml
Отдельно хочу отметить, что такое вынесение настроек запаковки в отдельный файл, позволило мне создать один конфиг запаковки на все Пакеты, что крайне удобно.
deploy
Фаза deploy так же запускается Maven’ом независимо от того, указали ли мы настройки этого плагина или нет. Переопределив их, мы и этот плагин заставили работать на себя.
С такими ручными настройками maven-deploy-plugin позволяет любой файл(или даже группу файлов) выложить в репозиторий Maven как валидную библиотеку(Пакет). Теперь разберем настройки по порядку.
file — файл, который будет отправлен в репозиторий Maven как Пакет.
url — путь к репозиторию Maven
repositoryId — идентификатор репозитория, в который будет производиться депллой.
groupId, artifactId, version — стандартная идентификация пакета в репозитории Maven. Именно по этим трем параметрам можно однозначно идентифицировать библиотеку. packaging – функционал деплой так же включает в себя запаковку файлов, которые будут отправлены в репозиторий, поэтому необходимо снова указать ему zip, чтобы он ничего не делал с пакетом, иначе распакует и запакует как jar :-).
pomFile – если данный параметр указан, то в комплект к Пакету будет добавлен тот файл, который мы укажем как pom.xml, при этом его изначальное имя может быть другим. Сохранять оригинальный pom.xml выгодно по многим причинам, поэтому мы не будем брезговать данной возможностью.
clean
Фаза clean, как я уже говорил, не входит в стандартный ЖЦ. Изначальная ее задача состоит в том, чтобы после выполнения команды mvn clean в проекте не осталось никаких следов жизнедеятельности. В нашем случае кроме стандартной папки targetSource(указана в теге build) требуется так же удалить все Пакеты, которые были «слиты» как зависимости для успешной компиляции пакета/проекта.
directory — собственно указание директории, которую необходимо удалить. Надо отметить, что тут создатели плагина отошли от общепринятой концепции, и явное указание настроек плагина не отменяет его действий по умолчанию. Но в данном случае, это очень хорошо, т. к. избавляет нас от лишний настроек.
Памятуя о том, как поначалу тяжело разбираться с отдельными ветками настроек, ниже приведу полный текст pom.xml одного из пакетов.
Итоги
Несмотря на то, что я сам остался чертовски доволен своей работой, я готов признать, что в данном виде система пакетной сборки проекта еще далека от совершенства, однако, приведенное описание достаточно иллюстрирует реализацию полного жиненного цикла пакета/проекта. Фактически это работоспособный каркас, поверх которого можно почти неограниченно расширять возможности.