Статья 3

[ZloySkin]

:) Тихоновский Я.

Блин, и умный же я (и скромный)! :)

Можно я опишу, как я делаю, если я где-то неправ - поправте.

В общем, я прикидываю насколько близко в сцене будет видна деталь, а потом подбираю так количество граней, чтобы она выглядела "достаточно гладенько". Вначале беру с избытком граней, а потом уменьшаю их количество, до тех пор пока углы в кривых ("гладких") не будут слишком явными, и возвращаюсь приблизительно на один шаг назад, но тут опять же все зависит от начальных условий на количество полигонов в модели. :) То есть если окружность на определенном расстоянии от камеры выглядит достаточно гладко (без явных углов) с 12 гранями, то нет смысла увеличивать количество граней до 13 (но я стараюсь выбирать количество граней в окружности кратное 4, чтобы раскладки текстур было легче делать). Кажется, так.

 

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

Продолжение следует...

[Aim]

я прочитал, вопросов не имею

[Andrew Tikhonovsky]

Почему обидно? Наоборт радоваться надо! Всем все понятно! Значит ты хороший учитель. :)

[ZloySkin]

Ладно, продолжим, далее, как и обещал. Недавний «Диалог о нормалях» имеет самое непосредственное отношение к тому, о чём пойдет речь ниже. Поэтому на всякий случай даю ссылку на эту ветку и, если что-то будет непонятно по ходу событий, прошу обращаться туда за разъяснениями. http://forums.eagle.ru/showthread.php?t=28217

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

Таким образом, я подведу некоторую черту под рисунком 7. Нас, как игровых моделлеров, такая степень детализации не интересует. Не имеет смысла строить всё, что я расписал абзацем выше, дабы добиться соответствия принципу рационального моделирования. Примем некую условность о том, что конкретно этот танк мы не сможем увидеть ближе, чем в полный размер во весь экран, всё остальное, это не наша область. Танк интересует нас только как элемент PROPS. (Жаргонное выражение, используемое гейм-девелоперами для обозначения всей «мебели». От английского театрального жаргонизма – props – «реквизит», сокращение от property, используется повсеместно даже не в англоязычных конторах.) То есть танк – это наша мебель, нас не интересует его анатомия, глубокое изучение, он необходим нам исключительно постольку поскольку, пролететь, пробежать, проехать или проползти мимо, не задерживая на нём взгляд. Всё остальное нас касаться не должно, поэтому в дальнейшее рассмотрение мы принимаем исключительно только оптимизированную модель танка, как вроде бы на первый взгляд удовлетворяющую принципу рационального моделирования. Надеюсь, такое долгое вступление до конца объясняет мой выбор? Главная мысль была: «Мы выбираем ту модель, которая на данный момент ближе всего подошла к тому, чтобы соответствовать принципу рационального моделирования». Все остальные выводы ложны.

[Coyote]

Ладно, продолжим, далее, как и обещал. Недавний «Диалог о нормалях» имеет самое непосредственное отношение к тому, о чём пойдет речь ниже. Поэтому на всякий случай даю ссылку на эту ветку и, если что-то будет непонятно по ходу событий, прошу обращаться туда за разъяснениями. http://forums.eagle.ru/showthread.php?t=28217

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

Таким образом, я подведу некоторую черту под рисунком 7. Нас, как игровых моделлеров, такая степень детализации не интересует. Не имеет смысла строить всё, что я расписал абзацем выше, дабы добиться соответствия принципу рационального моделирования. Примем некую условность о том, что конкретно этот танк мы не сможем увидеть ближе, чем в полный размер во весь экран, всё остальное, это не наша область. Танк интересует нас только как элемент PROPS. (Жаргонное выражение, используемое гейм-девелоперами для обозначения всей «мебели». От английского театрального жаргонизма – props – «реквизит», сокращение от property, используется повсеместно даже не в англоязычных конторах.) То есть танк – это наша мебель, нас не интересует его анатомия, глубокое изучение, он необходим нам исключительно постольку поскольку, пролететь, пробежать, проехать или проползти мимо, не задерживая на нём взгляд. Всё остальное нас касаться не должно, поэтому в дальнейшее рассмотрение мы принимаем исключительно только оптимизированную модель танка, как вроде бы на первый взгляд удовлетворяющую принципу рационального моделирования. Надеюсь, такое долгое вступление до конца объясняет мой выбор? Главная мысль была: «Мы выбираем ту модель, которая на данный момент ближе всего подошла к тому, чтобы соответствовать принципу рационального моделирования». Все остальные выводы ложны.

Полностью согласен.:thumbup:

[ZloySkin]

Итак, приблизительного соответствия мы добились, что же дальше? Прежде всего, необходимо привести все элементы танка в соответствие с принципом рационального моделирования, в частности ступеньки лестницы. Ступеньки своим диаметром соответствуют опорам лестницы, а, следовательно, должны иметь столько же граней в поперечном сечении. Делаем, как показано на рисунке 8. Замечу, что после подобной оптимизации количество треугольников в сцене сократилось до 824. Аккуратно стыкуем концы ступенек с опорами, но не торопимся убивать торцевые фасетки.

Здесь я сделаю ещё одно важное отступление, без которого дальнейшее рассмотрение моих действий будет просто бессмысленным, а сами действия могут показаться абсурдными и даже вредными. Для начала скажу, что я собрался делать. Я «врежу» булином ступеньки в опоры. Для того чтобы начинающие и кое в чём поднаторевшие моделлеры не стали сразу плеваться (а опытные зубры сразу поймут с какой целью это делается) и не начали приводить основной довод в подобных ситуациях: А как же увеличение полигонажа? Я посчитаю количество треугольников с удалёнными торцевыми треугольниками ступенек, просто для того, чтобы знать от чего мы пляшем в сторону увеличения полигонажа. А именно после удаления торцевых фасеток ступенек осталось 760. Это потому, что ступеньки были сделаны цилиндрами, и в каждой торцевой части было не 2 треугольника, а 4 из-за центральной точки.

Итак, в сухом остатке имеется 760 треугольников.

После того, как я произвёл операцию сложения, сцена стала весить 856 треугольников, то есть на 96 фасеток больше, чем в исходной геометрии, или на 12,6% в относительных величинах. Прирост не такой уж и значительный, но возникает вполне резонный вопрос: что мы за счёт этого выиграли? Давайте посчитаем. В первоначальном варианте, когда было 760 треугольников, количество точек равнялось 456, после того, как геометрия «срослась» количество точек не изменилось!!! А это значит, что весьма важный фактор, как вертекс-буфер, существенно влияющий на скорость рендера, остался без изменений. Пока оставлю это замечание без комментариев, поскольку углубляться в то, что такое вертекс-буфер, его склонность к переполнению, а также что такое дро-колы, рано и вообще не имеет особого смысла. Просто прошу пока поверить мне на слово, в то, что сохранение количества точек есть хорошо. Кроме того, мы ещё имеем такое свойство объекта, как сглаживание (чувствуете, что мы медленно, но верно подходим к вопросу нормалей?). Так вот количество векторов нормалей к поверхности в каждой точке выросло не больше, не меньше, а ровно на такое же количество, насколько увеличилось количество треугольников. Тоже непреложный факт, поскольку нормаль к треугольнику мы берём из точки, а количество точек осталось прежним. Таким образом, наша запись увеличилась не так уж и существенно, а именно: количество треугольников и количество нормалей к ним в точках увеличилось на 12,6 %, а вот количество точек, а именно количество относительных координат (надеюсь, все знают, что координаты точек в объекте берутся в обжекспейсе, то есть относительно центра объекта) осталось без изменений. Тут я должен заметить, что особенности работы современных графических акселераторов таковы, что основную нагрузку на их производительность оказывает как раз не количество треугольников, а количество объектов (или подобъектов), имеющих в чём-то отличающиеся при рендере свойства. Ну, например, текстуры разные, или интенсивность блика другая, или ещё какое-то свойство материала не совпадает, ну или, в конце концов, это просто отдельный объект модели. Тогда этот подобъект загружается отдельным конвейером видеокарты, как совершенно самостоятельный объект, имеющий свои уникальные свойства. Соответственно, вызов на рендер занимает значительно большее время, нежели отрисовка самого подобъекта на экран. Этот вызов и имеет жаргонное название дро-кол (draw call). При этом количество треугольников (если оно разумно) внутри дро-кола значения не имеет. Скажу лишь, что один дро-кол из трёх треугольников будет выводиться на рендер такое же количество времени, что и дро-кол из 5000 треугольников, а вот 5000 дро-колов по одному треугольнику серьёзно притормозят карточку по отрисовке, не в 5000 раз, конечно, но в разы, а значит на сотни процентов. Не знаю, насколько то, что я написал, необходимо помнить каждому моделлеру и держать это в голове, хочу, только, чтобы все уяснили для себя: в случае вывода простой геометрии на рендер (до 5-10 тысяч треугольников) изменение полигонажа на 12% практически никак не скажется на производительности, увеличение же количества дро-колов снизит производительность приблизительно на тот же процент.

Тут разумные люди попытаются вспомнить о том, что я вёл речь о выгодах «сращивания» геометрии и посчитать выгоду, однако перевёл стрелки и начал «грузить откровенный левак», чтобы съехать с темы и запудрить людям мозги. Это не так, я пытался объяснить, что «сращивание» геометрии ведёт к такому увеличению полигонажа, которое вообще никак не скажется на суммарной производительности при отрисовке. Поэтому вернёмся к нашим баранам и начнём, наконец перечислять полученные выгоды, ведь помимо увеличения полигонажа, мы ещё имеем существенный геморрой.

[ZloySkin]

Не стану особо распинаться:

1. Я руками избавил Z-буфер (буфер, отвечающий за сортировку треугольников по мере удаления от точки зрения, то есть за порядок прорисовки треугольников) от необходимости сортировать перекрывающиеся части лестницы, ступеньки и опоры. На самом деле это ерунда, не сказывающаяся ни на чём. Реальный выигрыш заключается в том, что объект теперь не зависит от глубины Z-буфера, то есть того каким он будет на конкретной видеокарте 16, 24 или 32 битным. То есть прорисовка объекта не будет зависеть от того какая видеокарта занимается ею, и какие установлены драйвера. Мне будет на это глубоко плевать, а это существеннейший плюс к тому, что я называю культурой моделирования. К слову скажу ещё пару слов о культуре моделирования в этом пункте. Необходимо, чтобы все физические объекты в модели были «замкнуты», то есть не имели «надрывов». Кто гарантирует вас от того, что в самом ближайшем будущем вашу модель не захотят заанимировать? Что легче, достроить геометрию в тех местах, где появились щели и откровенные дыры в результате анимации или же по результатам убрать невидимые треугольники? Я думаю вопрос риторический… «Сращивание» геометрии методом булина практически гарантирует вас от «разомкнутости» объектов. Кстати, советую всем пользоваться 9 максом, поскольку в нём булиновские операторы работают несравненно корректнее, чем в более старых версиях, большинство «лишних» точек и граней оптимизируются. Это к слову. А по сути, использование замкнутых подобъектов также говорит о высокой культуре вашего моделинга. Если вы не уверены в том, замкнут объект или нет, просто завельдите точки и наложите оператор Cap Holes, он автоматически закроет плоскостями все имеющиеся у вас в объекте дыры. Полезный инструмент, те кто его придумал, знал толк в культуре моделирования.

2. В своей статье Небольшое пособие по "запеканию" "оклюжена" (см. http://forums.eagle.ru/showthread.php?t=27778), я упоминал о таком важном параметре, как padding. Надеюсь, никто не будет подвергать сомнению то, что я обязательно собираюсь применить этот великолепный инструмент при текстурировании своего танка. Ещё как собираюсь! Так вот без «сращивания» геометрии, падинг становится абсолютно бесполезной величиной, поскольку он будет влиять на края текстурных шеллов, которые скрыты у нас где-то под другими поверхностями. Грубо говоря, при просчёте лайтмапа перекрывающиеся части объекта, ступенек и опор будут просчитаны непредсказуемо, а результирующая текстура будет иметь в местах перекрытия чудовищного вида артефакты, которые могут навсегда оставить в вашем сердце неизгладимый след от неправильного применения «запекания» и совершенно несправедливо наложить на этот метод чёрный след «глючного» и опасного. То есть, надеюсь, все понимают, что если было принято решение при текстурировании использовать «запекание», то сращивание просто необходимо, иначе технология будет не выдержана.

3. Самый обширный пункт, которому необходимо посвятить отдельную главу, а именно: Вырожденная геометрия, борьба с ней и корректировка топологии. Почему это относится к списку выгод от «сращивания» геометрии будет понятно по ходу дальнейшего рассмотрения.

[ZloySkin]

Итак, что же такое вырожденная геометрия, каким образом она отрицательно сказывается на результатах моделирования и как с ней можно и нужно бороться?

Для начала дам определение вырожденной геометрии. Вырожденная геометрия – это такая геометрия, в которой присутствуют треугольники, в которых все три точки расположены приблизительно на одной прямой или очень близко к одной прямой. (Далее я введу более общее понятие вырожденной геометрии, поскольку этим определением она к сожалению не ограничивается.) Что это значит? Сейчас поясню. Одним из признаков вырождения геометрии могут служить, так называемые «длинные фасетки», то есть треугольники, у которых кратчайшая высота треугольника меньше самой длинной из сторон более чем на один порядок. Надеюсь, все помнят курс геометрии за 6 класс и не забыли что такое биссектриса, медиана и высота треугольника. Кто не помнит, может взглянуть на рисунок 9, иллюстрирующий «длинные фасетки», как один из признаков вырожденной геометрии.

Теперь напишу несколько слов о свойствах «длинных фасеток» и почему именно они являются основным признаком вырожденной геометрии. Из рисунка 6 видно, что все три точки треугольника расположены очень близко к прямой. Чем это чревато? Дело в том, что мы имеем конечное число разрядов при определении координат точек, то есть сами координаты всегда будут иметь ошибку дискретизации и округления до ближайшего значимого разряда. При ряде вычислений, как мы знаем, ошибка накапливается. Я уже писал в «Диалогах о нормалях» (http://forums.eagle.ru/showthread.php?t=28217), что нормали вещь в себе и зависят от формата записи объекта. Иногда нормали могут запросто не участвовать в записи, а просто вычисляться по правилу буравчика, оно же правило левой руки из координат точек треугольника. То есть треугольник записывается в виде 1.2.3, где 1, 2 и 3, это последовательность точек, а нормаль вычисляется через матрицу их координат. Почему по правилу буравчика? Да потому, что нормаль всегда смотрит в сторону, вычисляемую по правилу левой руки при нумерации точек по часовой стрелке. Например, в треугольнике 1.2.3 нормаль смотрит в сторону «от меня», а значит, я не вижу треугольника, а при нумерации 3.2.1 нормаль смотрит «на меня», а значит, фасетка является для меня видимой. Так вот, к чему это я? А к тому, что при вычислении нормали к «длинной фасетке» ошибка получается такой, что треугольник может смотреть куда угодно, только не туда, куда ему следовало бы смотреть. Думаю, что все моделлеры в той или иной степени сталкивались с этой проблемой. Мало того, если треугольник участвует в какой-то из смус-групп, то результирующие этой смс-группы будут также непредсказуемы. Надеюсь, что тоже понятно почему.

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

[ZloySkin]

Если мы взглянем на танк, под несколько иным углом зрения, как показано на рисунке 10, то обнаружится, что опора лестницы, а точнее её основная часть, без закруглений имеет самые что ни наесть первейшие признаки вырожденной геометрии. Мало того, эти признаки были у опор и до того, как я произвёл «сращивание» геометрии, то есть опоры состояли сплошь из «длинных фасеток», а значит, при участии в смус-группах начинали смотреться отвратительно.

Далее прошу обратить ваше особое внимание на тот парадокс, который порождает в себе вырожденная геометрия. Мы упрощаем круглую вроде бы опору в четырёхгранную и видим, что участие «длинных фасеток» в одной смус-группе не приводит к удовлетворительному результату, опора по прежнему смотрится довольно горбато и совсем не круглой. А теперь, внимание!!! Маленькое колдунство, то есть на самом деле не колдунство, а всего лишь ловкость рук и элементарная математика. Что будет делать начинающий моделлер? Да, он будет увеличивать количество граней в поперечном сечении. Так будет подсказывать ему элементарная человеческая логика. Но действовать надо, не подчиняясь инстинктам. Подчиняясь инстинктам, вы совершаете ошибку. Действовать надо согласно принципу рационального моделирования, а именно, надо тессилировать опору по длине. Парадоксально? Да нисколько, простая математика. Я ещё и не такое могу показать.

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

[Acgaen]

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

[Andrew Tikhonovsky]

Спасибо, за статьи.

Теперь у меня будет меньше "мук творчества". :)

[ZloySkin]

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

 

Я, честно говоря, не очень понимаю, как такое может происходить. Физические то координаты одни и те же, зачем их вызывать несколько раз? Сами точки хранятся в вертекс-буфере, вызываются только индексы точек, а они к вертекс-буферу отношения вообще никакого не имеют, будь то ЛО или вообще, что-либо ещё, процесс то происходит на апартном уровне, тут всё завязано на отрисовке, то есть на конкретном количестве фасеток.

По твоему получается, что в ЛО АБСОЛЮТНО ВСЕ треугольники одного меша вызываются по отдельности. Перечитай себя ещё раз и отнеси всё сказанное тобой, например к элементарному боксу. И лесенка и бокс это ОДИН МЕШ! Помоему ты бред какой-то написал. :) Пожалуй даже проиллюстрирую рисуночком почему.

Потвоему выходит, что точки 1,2,3,4,5 и 6 это РАЗНЫЕ точки двух боксов, маленького и большого, только потому, что результирующая фигура получена путём булевского вычитания? А если не булем делать а выстроить такую фигуру руками это будут одни и те же точки?

 

Возможно, Стас, ты путаешь одни точки с другими, а именно физические координаты точек геометрии, с кординатами точек текстурных шелов на раскладке. Тогда я тебя понимаю. Текстурных координат может быть действительно сколько угодно, то есть в теории до бесконечности. Но ведь и в случае с "несращиваемой" геометрией мы имеем те же проблемы. Поясни пожалуйста поподробнее, что конкретно ты имел в виду, КАК, ЗА СЧЁТ ЧЕГО может увеличиться физическое количество точек и по какой закономерности это происходит?

Ну и ко всему прочему, ты не до конца меня читаешь. Я призывал к "сращиванию геометрии" не потому, что количество физических точек остаётся прежним (это не должно подвергаться сомнению будь то ЛО или макс или ещё что-то), а по другим причинам. Перечитай меня ещё раз. Сохранение физического количества точек было только одним из аргументов того, что такое изменение не приводит к существенному снижению производительности. К слову, эмпирически этот показатель колеблется от 1 до максимум 5 процентов!!! 5 - это когда действительно чудовищно тяжёлая геометрия и количество треугольников вырастатет на 50-70% внутри одного меша.

При этом я всего лишь даю весьма показательный пример. Делай я эту лестницу для ЛО, я бы вообще трёхгранных палок налепил и оттекстурил их планаром. Дело то в сути вещей, а не в конкретном примере.

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

 

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

Лесенка - это тот же бокс, поскольку представляет собой однородный замкнутый меш.

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

То же самое произойдёт и с боксом, достаточно наложить на каждую из сторон бокса отдельную текстуру, как он из одного объекта превратится в 6 отдельных объектов и вместо 8 точек мы получим сответственно 24!!! Чуть ниже, когда я буду исследовать топологию, я ещё раз подробнейшим образом остановлюсь на этом моменте.

А на данном этапе, придётся поверить мне на слово - количество физических точек не изменилось. Поменяется оно только в том случае, если разным треугольникам одного меша будут назначены разные материалы. Существует даже такое понятие как MaterialMesh, которое практически эквивалентно понятию дро-кола.

Надеюсь, теперь всем становится понятно, насколько вредно увеличение количества дро-колов и насколько несравнимо больший вред это увеличение приносит по сравнению с увеличением количества треугольников.

[ZloySkin]

Поскольку выяснилось, что Стас, действительно случайно, что-то перепутал, а может быть имел в ввиду другое, то о чём пойдёт речь значительно ниже, когда я перейду к текстурным координатам точек, то продолжим по порядку. Как я уже отметил, для того, чтобы избавиться от вырожденной геометрии, необходимо произвести тессиляцию, то есть разбить внешние грани опор таким образом, чтобы избавиться от "длинных фасеток", как приблизительно показано на рисунке 11.

Вообще-то в каждом конкретном случае тессиляцию необходимо производить по отдельному, выбранному для данного конкретного случая алгоритму. В данном случае я выбрал простейший путь, то есть привёл решётку опоры к регулярному виду. Это исключительно для того, чтобы была понятна суть борьбы с вырожденной геометрией. Вообщето я мог разбить грань и не на 8 частей, а например, на 4 или иное количество, и при этом также избавиться от вырожденной геометрии. Какой алгоритм применять решать необходимо на каждом конкретном примере, согласно принципу рационального моделирования и первому определению вырожденной геометрии. То есть следить за тем, чтобы кратчайшая высота треугольника всегда менее чем на один порядок отличалась по длинне от самой длинной стороны треугольника.

На рисунке справа изображён конечный результат после назначения смус-групп. Всего смус-групп две: 1 назаначена на боковые поверхности опор и 2 назначена на ступеньки и торцы опор.

Замечу, что после тессиляции количество треугольников увеличится на 64 штуки и их суммарное число составит 888. Соотнесём это число с нашим сухим остатком из 760 треугольников и получим 16типроцентный прирост геометрии. Не существенно для регулярной сетки. Такой процент, как 16 легко можно вычленить из другого места модели, так что легко можно списать!

[ZloySkin]

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

Математика этого явления элементарна, все нормали к треугольникам конуса в этой точке суммируются в одну, которая совпадает с осью кручения конуса, как показано на рисунке.

Видно, что нормаль имеет чрезвычайно тупой угол с поверхностями треугольников, это и даёт настолько неудовлетварительный результат на выходе.

В связи с этим, я имею намерение вывести второй признак вырожденной геометрии, а именно: на участке сглаживания, то есть в точке, где нормали к поверхности суммируются геометрия вырождается при стремлении угла суммарной нормали к поверхности к 180 или к 0 градусов хотя бы в одном из направлений суммирования. Иными словами, чем больше угол нормали к поверхности отличается от прямого, тем большую вырожденность геометрии вы получите.

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

Как бороться с этим явлением?

[ZloySkin]

Для примера возмём модель носового обтекателя, как показано на рисунке 12.

Хорактерно прявляется обычное явление вырожденности геометрии в концевой точке обтекателя. Что делать? Попробуем решить задачу в лоб, то есть произвести тессиляцию на самом конце. Я пропущу промежуточный вариант, и так понятно, что если добавить ещё одно сочленение практически в самой законцовке, то достичь своей цели, то есть избавиться от вырожденной геометрии мы не сможем. Почему? Да потому, что между последним и предпоследним сочленениями возникнут "длинные фасетки", а результат и в этом случае будет неудовлетворительным. Что делать? Придётся тессилировать последнее и предпоследнее колено, так, чтобы законцовка пришла к виду аккуратного скругления, как показано на рисунке 12 справа. Охренеть! - скажете вы, и будете правы, - а как же экономия полигонов, ведь вместо 216 треугольников, существовавших в исходном варианте, мы получили 360 или на 67% больше!!! фактически ничего не добавив, а всего лишь избавившись от паскудского артефакта, вызванного вырождением геометрии. Не слишком ли жирно?

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

[ZloySkin]

Я вернусь к началу своей статьи и вспомню, как бесжалостно я кастрировал маленькую сферу. Точно также, я возьму законцовку и сделаю её просто треугольной пирамидкой, ведь это не противоречит, а очень даже соответствует принципу рационального моделирования. Следующее сочленение я сделаю всего лишь шестигранником в сечении. А что мне мешает двигаться дальше, сделав следующее сочленение восмигранником, два последующих двенадцатигранниками, предпоследнее перед основным радиусом шестнадцатигранником и только основной радиус оставить таким, каким он и был, то есть 24 грани, так как показано на рисунке 13 слева?

А справа виден результат упрощения, который состоит из 186 треугольников. Так что получилось в итоге? Я избавился от вырожденной геометрии, моя модель стала выглядеть лучше первоначальной, да ко всему прочему я ещё и на треугольниках сэкономил! 30 штук, те самые 16% мимо кассы!!! Всё это, благодаря золотому принципу рационального моделирования.

Добавлю, что этот метод, называется методом деградации геометрии (геометрия как-бы деградирует в соответствии с принципом двух сфер :)) и применяется он не только на объектах вращения.

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

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

Ну и в качестве дополнения, хочу ответить на вопрос Андрея Тихоновского по выбору количества граней у объектов вращения. Как следует из вышеописанного примера лучше всего для объектов вращения выбирать наиболее кратное количество граней, то есть кратным максимальному количеству простых чисел. Например 12, 24 и 36 великолепные числа, поскольку свободно делятся на 2, 3, 4, 6, а вот 10, 16 и 18 и 32 не лучший выбор, поскольку в ряду будет отсутствовать либо тройка, либо четвёрка.

Объекты вращения с 12, 24 и 36 гранями наиболее пригодны для деградации и экономия полигонов после деградации будет значительно более ощутимой, если вы, скажем, предпочтёте им числа из казалось бы заведомо более "экономичного" ряда 10, 16, 18 и 32.

Однако бывают исключения. Например, представьте себе циллиндрический счётчик на индикаторе какого-нибудь прибора. Понятно, что будет лучше, если он будет состоять из циллиндра с количеством граней кратным 10, поскольку на нём будут расположены цифры от 0 до 9. Но это частный случай, привожу только в качестве исключения.

[grisha]

Количество вершин в кубе

 

Итак, по просьбе Стаса я бы хотел прояснить вопрос и закрыть непомерно разросшееся обсуждение этой темы.

 

Итак, современные видеокарты работают только с фиксированным форматом вертекса. В случае сетки с нормалями и одним набором текстурных координат он выглядит так:

vec3 position;

vec3 normal;

vec2 texcoords;

Размер такого вертекса фиксирован, и равен 32 байтам.

 

При выгрузке из 3D Max происходит анализ геометрии. Если у точки есть два или более значения для одного из полей (position, normal, texcoords) - создается необходимое количество дубликатов этой точки. Таким образом после выгрузки у каждой точки есть ровно одна позиция, одна нормаль и одни текстурные координаты.

 

Поясню на примере:

Пусть есть куб, у которого каждая сторона имеет свою группу сглаживания. Это означает что в каждой вершине есть три варианта нормалей, таким образом при выгрузке создастся буфер на 8*3 = 24 вершины.

 

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

 

Если мы теперь уберем текстурирование, оставив только закрашенный куб с одной группой сглаживания, уникальных вертексов станет 8.

 

Надеюсь это объяснение прояснит ситуацию.

 

С уважением,

Ведущий программист по графике фирмы Eagle Dynamics,

Гриша.

[ZloySkin]

Итак, по просьбе Стаса я бы хотел прояснить вопрос и закрыть непомерно разросшееся обсуждение этой темы.

 

Итак, современные видеокарты работают только с фиксированным форматом вертекса. В случае сетки с нормалями и одним набором текстурных координат он выглядит так:

vec3 position;

vec3 normal;

vec2 texcoords;

 

Размер такого вертекса фиксирован, и равен 32 байтам.

 

При выгрузке из 3D Max происходит анализ геометрии. Если у точки есть два или более значения для одного из полей (position, normal, texcoords) - создается необходимое количество дубликатов этой точки. Таким образом после выгрузки у каждой точки есть ровно одна позиция, одна нормаль и одни текстурные координаты.

 

Поясню на примере:

Пусть есть куб, у которого каждая сторона имеет свою группу сглаживания. Это означает что в каждой вершине есть три варианта нормалей, таким образом при выгрузке создастся буфер на 8*3 = 24 вершины.

 

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

 

Если мы теперь уберем текстурирование, оставив только закрашенный куб с одной группой сглаживания, уникальных вертексов станет 8.

 

Надеюсь это объяснение прояснит ситуацию.

 

С уважением,

Ведущий программист по графике фирмы Eagle Dynamics,

Гриша.

 

Как формальное объяснение принимается, ты правда, забыл уточнить, что есть ещё поля записи vertexcolour1, vertexcolour2 по RGB компонентам, и что под текстурные координаты выделяется 16 регистров всегда, а position и normal - это float. ;) Предлагаю тему закрыть, поскольку речь шла не об этом.

[ZloySkin]

Думаю, что я ещё дам некоторые разъяснения по поводу того, что написал выше Гриша, поскольку по ходу рассмотрения, всё-равно придётся неоднократно к этому возвращаться.

 

Сейчас несколько занят по работе, продолжу в ближайшее время, жду вопросов.

В бытность мою студентом, лет 15 назад преподавал нам на 3-4 курсах такую дисциплину, как радио-технические цепи и сигналы некий профессор Соколов, весьма эпотажная личность, умница и любимец всей кафедры. В своё время он окончил Сорбонну и слушал курс небезвестного профессора Дирака, выведшего функцию Дирака и предложившего гипотезу монополей Дирака. К чему это я? У профессора Соколова была по его словам привычка Дирака говорить после лекции одну и ту же фразу: еcли нет вопросов, значит никто ничего не понял, видимо я плохо объяснял.

Так что жду вопросов.

[Crusader]

Не знаю насчёт Дирака, а в школе моя учительница по математике 40 лет назад говорила так: "У кого есть вопросы? Нет? Значит либо всем всё ясно, либо никто ничего не понял." Я думаю, эта мудрость ещё от древних греков тянется. :-)

[Acgaen]

Красная кнопка

 

Научно-методическое пособие по изготовлению кнопки

 

Бесполезное пособие, могущее помочь кому-то где-то как-то убить ненужные треугольники.

 

Стоит задача сделать кнопку подбную вот такой:

 

 

Т.е. - это квадратная кнопка размером 18х18 мм, видимая на экране в виртуальных величинах с расстрояния около 30 см. Это не просто квадратная кнопка, а кнопка со скругленными краями, с торчащим торцом вокруг стеклышка, имеющим полукруглый край. Современность позволяет нам распоряжаться треугольниками менее экономно, чем в 20-м веке, поэтому делается модель с четырехгранными закруглениями краев и получается вот такая штука, состоящая из 142 треугольников.

 

 

Ее каркас будет выглядеть так:

 

 

Теперь, так как тяжелое прошлое заставляет нас полусознательно экономить треугольники в моделях, пытаемся придумать как уменьшить количество треугольников в этих условиях. Получается, что кнопка будет торчать из металлической панели примерно на 8 мм, под которую нет никакой возможности заглянуть. Значит, можно ее удлиннить вниз на такое расстояние, которое позволит нам, не меняя визуального восприятия, сварить по четыре вершины в каждом углу кнопки. Вот новый вариант кнопки:

 

 

А вот и ее каркасный вид:

 

[Acgaen]

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

 

 

Но экономия 24-х треугольников не может затушить энтузиазм разработчика, поэтому он кощунственно варит вершины стеклышка и получает на нем не 14, а два треугольника, снимая с плеч модели еще 12 треугольников:

 

 

 

Вот и итоговая кнопка, которая ничем не отличается для воспринимающего ее глаза от первоначального варианта. Сэкономлено 36 треугольников. На фига это надо, возникает в мозге мысль. А другая мысль ей отвечает, что, вроде, не особо и надо, но умножая количество кнопок хотя бы на 20 мы получим экономию 720 треугольников, а это кое-где поможет появиться еще одному кадру в секунду на мониторе пилота и пальнуть не мимо цели, а поразить ее своим баллистическим лазерганом.

[Coyote]

А если с верхнего торца кнопки убрать среднюю грань и сделать скриншоты с 30 см, будет видно разницу?:music_whistling:

[Dronas]

А если с верхнего торца кнопки убрать среднюю грань и сделать скриншоты с 30 см, будет видно разницу?:music_whistling:

 

Вот-вот.

 

А ещё уж слишком много раз встречал упоминания о том, что геометрия не должна пересекаться, что это тоже не очень хорошо сказывается на скорости... А в ЛО почему-то это советуется делать везде...

[Acgaen]

А если с верхнего торца кнопки убрать среднюю грань и сделать скриншоты с 30 см, будет видно разницу?:music_whistling:

 

Будет. При изменении угла визирования кнопки, мы увидим в таком случае не частичный затухающий рефлекс, а тотальную засветку этого торца.