вкратце, это техника разбиения треугольников, которые визуализируются видеокартой, на более мелкие. Причём обычно новые, более маленькие, треугольники используют для вычисления своих координат нормали исходного треугольника (т.е лежат не просто в плоскости исходного треугольника), тем самым, повышая гладкость поверхности визуализируемой 3-D модели. Помимо этого повышается реалистичности освещения (кто в курсе: фактически с ростом числа разбиений мы движемся от модели Гуро к затенению по Фонгу), так как увеличивается количество нормалей, для которых, собственно, и производятся вычисления освещённости.
Причём, при аппаратной поддержке акселератором, даже весьма солидные степени разбиения обычно не вызывают особого торможения. Почему? Дело в том, что фактически программа скармливает акселератору то же самое количество треугольников, что не перегружает шину обмена и не увеличивает требования к памяти. А современные акселераторы способны переварить просто немыслимое количество треугольников в секунду. Например, мой Rаdeon8500LE (не разогнанный, лень) практически не поперхнулся (FPS в Morrowind'е упал всего на 5-7%) при увеличении количества треугольников раза в три.
Степень сегментации (сглаживания, я употребляю этот термин, однако, для некоторых объектов (скал) возможно наоборот появление дополнительных деталей (бугорков, выступов, очень повышающих реализм) - всё зависит от расположения нормалей (для скал - видимо они торчат в разные стороны) оригинальной 3-D модели) задаётся отдельным состоянием (render state в Direct3D), что позволяет достаточно легко внедрить поддержку N-PATCH в любую программу (реализация N-PATCH в данной проге для Morrowind'а - яркий пример этому).
Теперь о грустном. К сожалению N-PATCH на данный момент реализован только в акселераторах от ATI (TRUFORM это название N-PATCH в акселераторах ATI). Причем не во всех: нужен Radeon8500LE (т.е R200) или Radeon с более высоким номером (кроме Radeon9000 - единственное исключение, на нём вообще при включении TRUFORM всё обычно виснет, что однако сильно зависит о версии Catalyst, так как TRUFORM на Radeon9000 программный). А в Radeon на основе ядра R300 введена более прогрессивная (в прямом смысле) версия TRUFORM 2.0, позволяющая плавно изменять степень сегментации (сглаживания). То есть не только между целыми числами - что уменьшает видимые переходы между целыми степенями сегментации TRUFORM 1.0 (впрочем, они и так не сильно-то и видны, исключая переход между степенью 1 (нет сглаживания, всё визуализируется как обычно) и 2 (минимально возможная степень сглаживания в TRUFORM 1.0)).
Однако по (неофициальной, форумы www.rage3d.com) информации на R300 почему-то имеет место гораздо более сильное падение производительности (по сравнению с Radeon8500) и всякие глюки при включении TRUFORM. Что наводит на нехорошие мысли о высокой CPU-зависимости. Однако это могут быть "просто" проблемы с драйверами.
К сожалению nVIDIA GeForce (любой, даже FX) не имеет аппаратной поддержки N-PATCH. Всё что могут эти карты, в этом отношении, сводится к программной эмуляции, которая сводит на нет все преимущества подхода позволяющего не пересылать дополнительные треугольники вместе с основными. Это даже если не принимать во внимание разбиение треугольника с помощью явно не приспособленного для таких дел CPU, для которого и так дел хватает - взять, к примеру, расчёт столкновений в Morrowind'е - кушает не меньше ресурсов (если не больше) чем визуализация. Про Matrox Parhelia и SIS Xabre (ни хочу никого обидеть, но ему бы с исходными треугольниками справиться) я уже не говорю.
Однако не всё так радужно и аппаратной поддержкой (да и вообще с техникой N-PATCH). Основная проблема заключается в том, что не все 3-D модели выглядят хорошо после применения такого типа сглаживания. Причина кроется в том, что акселератор имеет дело только с одним исходным треугольником, когда производит его разбиение. Его соседи не учитываются (что и понятно, т.к. иначе сложность реализации N-PATCH многократно бы возросла). Поэтому 3-D модели, имеющие прямые (указатели) или острые углы (ветки), выглядят как будто раздутыми после применения N-PATCH. Также нежелательно искривление некоторых поверхностей, которые должны быть плоскими (например, крыши домов северян). Но и это ещё не всё. На месте сочленения некоторых сложных объектов, состоящих из нескольких наборов треугольников, возможно появление ранее незаметных дыр (например, земля, пещеры, некоторые виды доспехов) из-за разной степени искривленности (вытекающей из нормалей) двух ранее вроде бы плотно примыкающих частей.
Однако не всё так плохо. Для большинства объектов возможно (и даже очень) применение N-PATCH. К тому же все геометрические артефакты, описанные в предыдущем параграфе, решаются (если всё же хочется иметь улучшенную модель освещения) путём применения специальной разновидности N-PATCH, а точнее когда все дополнительные треугольники располагаются строго в плоскости исходного. Такой подход к тому же гораздо дешевле в плане производительности. Хотя естественно он и не повышает гладкость объектов (хотя и какая гладкость может быть у прямоугольной стены?) - только улучшает модель освещения.
То есть для нормального использования N-PATCH мы должны уметь отделять "хорошие" объекты (без артефактов, вызванных кубической интерполяцией (по нормали) новых треугольников) от "плохих" (для которых ввиду артефактов желательна только линейная (в плоскости исходного треугольника без участия его нормалей) интерполяция). К счастью прога умеет это делать.
|
| | Как работает список N-Patch ключевых слов ? | | |
|
ем, кто хоть немного знаком c TES CS (редактор уровней Morrowind'а) должны знать, что каждый объект в игре имеет свой уникальный идентификатор (далее ID). Прога умеет определять ID для объекта, который сейчас будет нарисован. Поэтому, используя этот ID можно отделить (и активировать N-PATCH для них) объекты, которые будет неплохо выглядеть с N-PATCH от других.
Естественно, что специализировать идентификацию до уровня конкретных ID при таком подходе невозможно (по соображениям затрат как памяти так и процессорного времени). Поэтому объекты выделяются, как бы, классами. На каком основании? На основании вхождения / не вхождения (в качестве подстроки) ключевого слова списка в строку ID. Например, для ID "terrain_rock_ac_01" и "terrain_rock_ac_02" введение ключевого слова "rock" включает для них так и для любых ID содержащих rock (т.е. для "*rock*") N-PATCH. Так как все скалы (rock) обычно выглядят неплохо с N-PATCH (т.е. пример хороших объектов) то введение такого ключевого слова (rock) оправдано. Особенно приятно то, что такое ключевое слово будет работать и для ещё не созданных объектов (ID) этой группы (скал, камней), появление которых возможно (и даже очень) в будущих модах (mods) и дополнениях (expansions).
В общем, мы имеет ID и список ключевых слов (если перед любым ключевым словом не стоит птичка, то оно в дальнейшем не учитывается - его как бы вообще нет). Начинаем просматривать список сверху вниз и ищем первое ключевое слово (пока не берём в расчёт ключевые слова вида "корень!лист", т.е. те которые содержат '!' - восклицательный знак). Если ни одного совпадения не произошло, считается, что ID задаёт плохой объект (не применяется кубическая интерполяция геометрии, т.е. по простому - сглаживание).
Как только обнаруживаем первое совпадение (т.е. ключевое слово, обозначим его как "корень" - суть есть :) подстрока ID) начинаем просматривать все ключевые слова вида "корень!лист" (т.е. у которых слева от восклицательного знака, в точности :), стоит, только что найденный, "корень") на предмет обнаружения в нашем ID подстроки "лист". Если хоть один "лист" является подстрокой, то для текущего ID (а точнее для 3-D объекта с ним связанного) N-PATCH НЕ используется (т.е. это плохой объект, для которого максимум возможно применить линейную интерполяцию геометрии при включении "allow linear position interpolation").
Если ни один "лист" не является подстрокой ID, то в этом случае объект полагается хорошим и для него используется уровень сглаживания, основанный на "basic n-patch segmentation" (далее просто базовый уровень сегментации (сглаживания)).
Почему основанный? Потому что возможны различные модификаторы этого числа, задаваемые для ключевого слова "корень" в виде: <+-*/=><число> (для ключевых слов вида "корень!лист" модификатора не имеется, да он им и не нужен, так как фактически они применяются для отбрасывания плохих специальных подмножеств объектов из множества хороших объектов, задаваемое их общей левой частью).
Модификатор можно изменить при редактировании (выделите его мышкой и щелкните ещё раз) ключевого слова "корень", т.к. в режиме редактирования это ключевое слово имеет вид "корень"[<+-*/=><число>]. При окончании редактирования ключевое слово снова принимает вид "корень", а строка модификатора переходит в колонку modifier. Причём реальный (базовый, с учётом модификатора) уровень сглаживания появляется в колонке final.
Как же действует модификатор? В случае '+' или '-' к базовому уровню прибавляется (вычитается) целое число. При '*' или '/' базовый уровень соответственно умножается / делится на действительное число и берётся округленный до целого результат. При '=' базовый уровень вообще игнорируется и в качестве результата берётся целое число идущее далее.
С помощью последнего модификатора (и использовании того факта, что ключевые слова просматриваются сверху вниз, а также того, что "корень"=1 эффективно выключает N-PATCH для объектов, чей ID содержит в качестве подстроки "корень") можно реализовать исключение подмножества (плохих) объектов из множества хороших на подобие использования ключевых слов "корень" и "корень!лист". Например, "flora", "flora!tree" можно заменить на "tree=1", "flora" (порядок слева направо означает расположение этих ключевых слов сверху вниз в списке). Однако "flora", "flora!tree" всё-таки будет более эффективным т.к. "flora!*" будут просматриваться, только если ID уже содержит "flora".
Теперь о значении символов '[' и ']': они означают начало / конец ID. То есть "[p_" значит, например, "p_fortify_magicka_b" но никак не, например, "furn_imp_altar_01" (тоже содержит "p_" в середине). Однако '[' и ']' не являются нетерминалами, т.е. можно задать ключевое слово "[" (или "]"), которое будет "содержаться" в любом ID. То есть фактически все ID имеют форму "[ID]".
Чтобы быть совсем точным, некоторые объекты имеют ID в виде (только для ключевых слов из нашего списка) "[ID1][ID2]" (то есть можно задать ключевое слово "][" и оно будет найдено :). Такая форма ID используется для составных систем объектов. Например, [человек][голова], [человек][тело], [человек][рука] ... (ну вы сами понимаете, чем можно продолжить этот ассоциативный ряд :). Более конкретно в игре: [alvela saram][b_n_dark elf_f_head_04], [mudcrab][mesh01 0].
Причём обратите внимание, что в последнем случае, во-первых, используется какой-то внутренний ID (mesh01), а так же, на цифру через пробел (" 0"). Движок Morrowind'а часто добавляет такие цифры даже не к сгенерированным ID (которые можно найти в TES CS). Так что сильно не уповайте на ']', так как в большинстве случаев "чистого" "[ID]" не будет (а будет "[ID ]").
Да чуть не забыл есть ещё ключевые слова вида "!лист". Они нужны для откидывания объектов, для которых N-PATCH применяется прогой по умолчанию (да, есть и такое). Обычно к таким объектам относятся большинство живых (ну, по крайней мере, шевелящихся :) созданий, а также, кисти рук, туловища (включите "!chest", чтобы убрать N-PATCH для тел) и флаги. В общем, объекты со сложной анимацией (я подозреваю skinning, кто в этом разбирается), наличие которой можно очень быстро обнаружить не прибегая к списку ключевых слов (в данном случае он просматривается только на предмет "!лист" ключевых слов). Обычно это объекты органической природы (кроме флагов) и поэтому хорошо держат N-PATCH. Однако есть неприятные исключения: "!cliffracer", "!atronach" и, особенно, в некоторых случаях "!chest".
Какие примеры плохих ключевых слов? Основные проблемы возникают при применении чересчур общих ключевых слов. Например "in" - включает N-PATCH для многих объектов в помещениях (их ID имеют форму "[in_") (включая стены, что, уже одно, не очень хорошо). "[" вообще для всех объектов подряд. В общем, старайтесь избегать одно-двух буквенных ключевых слов, т.к. велика вероятность, что вы зацепите, что-либо ещё.
При нажатии правой кнопки мыши, в списке ключевых слов появляется меню. "Select All" - выделяет все ключевые слова списка, "Disable selected" - выключает (убирает, если, есть птичку перед ними) выделенные слова списка, "Enable selected" - включает (те, которые можно) ключевые слова списка, "Move Up selected" - сдвигает выделенные слова на одну позицию вверх, "Move Down selected" - вниз, "Delete selected" - удаляет (совсем) выделенные слова из списка, "Reset to Defaults" - сбрасывает список, на список с ключевыми словами по умолчанию.
"Load from file..." - загружает в конец текущего списка дополнительные ключевые слова из файла, который вы укажите.
"Save selected to file..." - сохраняет выделенные слова в указанном вами файле.
|
| | Комментарии по выбору N-Patch ключевых слов по умолчанию | | |
|
ля некого ускорения процесса прохода (который, однако, и так очень быстр - весьма оптимизированный ассемблер) списка ключевых слов, ключевые слова по умолчания распложены более или менее в порядке уменьшения частоты их появления в ID объектов. Обычно модификаторы "*2" имеют достаточно большие объекты (я отождествляю ключевое слово с тем подмножеством объектов, которое оно покрывает), которые имеет смысл сглаживать очень сильно.
- "[flora_!tree" активируйте (включите птичку перед ним) это ключевое слово, если не хотите, чтобы N-PATCH распространялся на деревья - иногда выглядят не очень правдоподобно, а точнее концы их веток. Но это на любителя.
- "[misc_" имеет так много исключений ("[misc_!*") потому, что такой подход эффективнее, если бы мы принялись перечислять все объекты из группы misc для которых N-PATCH подходит (просто неимоверное количество чашек, плошек, ваз, подушек - я лично сказал, хватит, после того, как увидел барабан из группы misc, смотрящийся с N-PATCH что надо). В основном все исключения связаны с либо длинными объектами (удочка - fishing_pole, метла - broom, ложка - spoon, вилка - fork, нож - knife) либо с всякими не глубокими сосудами, которые после применения N-PATCH так выгибаются, что становится видна поверхность, на которой они находятся, вместо их дна. Особый контингент составляют конкретные бутылки (bottle_01, bottle_09, bottle_13) - чего-то не то у них с горлышком. Для tankard (граненая кружка) просто сглаживаются грани, что на мой вкус не очень. Однако для остальных объектов (их ещё столько осталось!) "[misc_" работает неплохо, так как в эту группу в основном относятся маленькие, монолитные объекты ничего не теряющие после N-PATCH.
- "[a_" отвечает за доспехи, "[b_" - за части тела, "[c_" - за одежду (надетую, а "[common_" - лежащую на полках в виде свёртков), а "[p_" - за алхимические бутылки ("potion_" - просто за всякие другие бутылки).
- "[flora_*2", "root", "shrub", "plant" - всякая растительность.
- "rock*2", "boulder*2", "barnacle*2" (груда сложенных камней), "menhir*2" (здоровая скала, торчащая из моря (северный Morrowind)), "[terrain_*2", "cave_stal" (пещерные сталактиты) - всякие камушки (rock - ОЧЕНЬ распространен - имеется практически в каждой сцене наружи).
- "kollop" - морские раковины.
- "topshell*2" - шляпка здорового гриба - здания в Ald-ruhn (город такой). "[ex_redoran*2" - для зданий, "[ex_redwall_post" столбов - в том же городе.
- "[ex_vivec_water", "[ex_vivec_wspout", "[ex_vivec_g_" - всякие водопады и бассейны, "[ex_v_st" - статуи - только на крыше. Всё в Vivec'е.
- "[newcabin" - какой-то внутренний ID (в TES CS его нет) для носовой части кораблей.
- "[netch_betty" (летающая медуза), "[scrib]" (многоножка) для существ, для которых N-PATCH, по умолчанию, не срабатывает (наверное, есть какое-то отличия, но я не улавливаю).
- "!cliffracer", "!atronach?" - наоборот вырубает для некоторых существ (иначе в них появляются дыры). Причём вопрос означает, что данное ключевое слово отключено по умолчанию (т.е. N-PATCH для таких существ всё еще применятся, т.к. дыры в принципе не очень заметны (и если честно в данном случае не сильно-то и портят вид), если де делать стоп-кадров).
- "!banner" - вырубает N-PATCH для иначе включенных по умолчанию флагов, "
