И пишу без ложной скромности и почти в тезисной форме
Бросается в глаза то, что некоторые начинающие разработчики просто игнорируют информацию в наших ранних статейках и надеются на то, что получится все сразу быстро и красиво. Это влечет за собой косяки в разработке, затягивание ее, и дальнейший отход автора, столкнувшегося с преодолимыми трудностями, от дел. Для таких товарищей необходимо глубоко понять фразу «изучайте мат. часть». Тут нужно понимание, что дизайнер учится своему делу в среднем всю жизнь, и если первая разработка будет вестись долго, то вторая уже пойдет гораздо быстрее с возрастающим по гиперболе (горбом вверх) качеством. Но трудности ломают многих и в итоге, мы имеем вполне хороший выход по оружию, но больших моделей, которые приняты, или в стадии принятия на вооружение симулятора, всего – Т-72, Як-40, Мираж Ф-1, УАЗ-469, Предатор и, вроде, все.
Следующей проблемой, пересекающейся с предыдущей в несколько другой психоточке, является крушение надежд автора, который затратил на модель огромное количество времени и сил и в итоге получил неоднозначную оценку своего труда. Но, наши требования таковы, что просто великолепно смотрящаяся для зрителей модель не может быть оценена нами на оценку «отлично», только по причине того, что она лучше наших модельных динозавров и почти всех устраивает на форуме. У нас по традиции последних времен заявлено такое качество, которое не позволяет увидеть даже тускнеющих проблем в модели и при непосредственном сравнении с фотографиями. Отсюда видны горизонты личных допусков автора для «похожести» модели. Места фразе «и так сойдет» в разработке быть не должно. Очень хорошо, что некоторые члены форума принимают активное участие в обсуждении моделей и проводят в жизнь верное направление досконального изучения прототипа и перенесения всех его геометрических свойств на виртуальное отражение.
По частностям.
- нет большой необходимости браться сразу за сложную модель типа танка, есть много объектов, которые требуют разработки и на которых можно ознакомиться с тонкостями работы (например – опоры ЖД путей)
- нет необходимости браться за разработку при поверхностном ознакомлении с трехмерным редактором, но если очень хочется – см. предыдущий пункт
- обильное применение модификаторов не оправдано при плохом знании их свойств, в низкополигональном моделировании очень много работы проводится именно голыми руками. Автоматизация, в близком к чистому, виде приносит обильные скоростные плоды низкого качества, которые и приводят к затягиванию разработки и т.д.
Теперь непосредственно по моделированию:
- множество одинаковых мелких объектов должны иметь различные вариации в текстурировании. Как пример, можно назвать элементы активной брони танка, их много и при одном и том же текстурировании, бросается в глаза и идеальная «близнецовость», чего в реальности быть не может. Конечно, если следовать буквально написанному, то для этих элементов может уйти текстурного пространства больше, чем на все остальное изделие. Поэтому, можно создать несколько шаблонных вариантов (ну, шесть, например) и в разнобой их распределить в модели
- некоторые авторы замечены в некачественном текстурировании. Применяется плоское сквозное проецирование на объемном элементе, это ведет к тому, что на гранях объекта мы имеем не текстуру, а растянутые линии, что выглядит совсем уж вызывающе и непрофессионально
- имеет место сквозное проецирование двух симметричных сторон изделия, к примеру, какая-нибудь БМД-шка, в которой на два борта идет одно текстурное пространство. Но абсолютно симметричные загрязнения бортов не приносят модели лишней прелести
- видны проблемы в работе с фотографиями, есть прецеденты создания моделей чисто по чертежам. На этом вопросе уже останавливались неоднократно – это недопустимо, т.к. чертежей идеальных не бывает, они уже имеют свои накопленные ошибки и при работе по ним, автор к модели добавляет еще и свои. А вот грамотное распределение внимания по чертежам и по большому количеству фотографий только приветствуется
- касаемо предыдущего вопроса – есть проблемы с перенесением пропорций объекта на модель. Эта засада кроется в опыте моделирования, никто с наскока не сможет достаточно точно увидеть пропорциональные отношения, здесь нужна тренировка, и рисование чайника (упоминаемое в предыдущем труде) будет полезно именно начинающим моделлерам. Ну, и отсутствие попыток сделать крупный сложный объект с первого раза
- чем меньше применяется всяких модификаторов для создания объекта - тем меньше проблем мы испытаем с выгрузкой модели в ЛО
- нужно не забывать сваривать вершины меша после всяких непонятных операций, типа detach, explode и т.д.
- все элементы модели нужно конвертить в edit mesh перед отправкой нам
- модель и приложенная к ней текстура должны лежать в одной папке – распределять геометрию и текстуры по спец. папочкам не нужно
- нет необходимости устанавливать всякого рода источники света, располагать модель в наиболее выгодном ракурсе для просмотра. Все эти вещи убиваются нами перед оценкой модели, но помимо того, могут говорить о малом опыте работы автора.
Автор: дизайнер C. Колесников Drum27, Acgaen
2.3Приложение 3 Небольшое пособие по «запеканию» «оклюжена»
1. Берём объект. Назначаем ему какой-нибудь стандартный материал, лучше всего совершенно нейтрального цвета, что-то типа дифуза 128,128,128. Понятно, что вы обладаете некоторой культурой моделирования, то есть объекты "сращиваете", "вшиваете", "врезаете", "булините" не знаю какой ещё термин применить. (Это всё входит в понятие о культуре моделирования) А все грани делаете видимыми, для того, чтобы после "врезки" ручками убрать лишние точки и грани, которые остаются даже после повербулина, если объекты достаточно сложные. Мы ограничимся боксами, врежем их друг в друга, как показано на рисуночке и разложим, как опять же показано на рисуночке. Раскладку можно производить любыми известными вам способами, методами, кому как удобно и кому как нравится.
ПЕРЕД ЭТИМ ВСЕМ В ОБЯЗАТЕЛЬНОМ ПОРЯДКЕ ЧИТАТЬ ПУНКТ 9!!!
Необходимо только помнить о культуре моделирования. Про дублирование геометрии укажу чуточку ниже. Да ещё совсем забыл, перед просчётом оклюжена геометрия должна быть готова целиком и полностью, то есть все смус-группы выставлены в необходимом порядке.
2. Затем выставляем этот самый бесконечно большой источник света, светящий вовнутрь, в центре которого, находится наш объект. Лучше всего в топовой проекции. По сути, это небеса, skylight.
3. Затем необходимо проверить чтобы алгоритм LightTracer при использовании AdvancedLighting был активирован.
4. Далее, мы открываем диалоговое окно RenderToTexture и работаем исключительно в нём.
5. Проверяем, чтобы ключ Selected Objects был выставлен в положение enabled, и тогда для того, чтобы объект появился в вашем листе, его будет нужно просто выделить в сцене. Padding - очень полезный параметр, это величина полей рендера в пикселах, то есть того на сколько срендыренная текстурка будет перекрывать реальные размеры текстурных шелов по границам этих шелов. Очень полезная вещь. В первую очередь для того, чтобы фоновая заливка не интерполировалась билинейкой с реальным цветом уже запечёной текстуры на нижних уровнях мипмапа. По умолчанию параметр в 9 выставлен 2, то есть 2 пиксела. В 8 и 7 по умолчанию выставлен 0, поэтому проверять просто необходимо. Чем больше величина падинга, тем лучше, но дольше идёт просчёт. Я выставляю обычно 4, если размер текстуры, потом менять не собираюсь, вполне достаточно, меньше плохо. Иногда ставлю 8, но только тогда, когда это действительно требуется.
6. Дальше шаги будут зависеть от того, чего именно мы хотим добиться. Я опишу самый простой способ, остальное варьируйте на здоровье как вам заблагорассудится.
В следующем листе нажимаем кнопку Add, после чего выпадает меню выбора того, что мы в данный момент хотим посчитать. На картинке видно, что есть абсолютно всё, включая CompleteMap, но мы вибираем простой способ и тыкаем в LightingMap, затем на AddElement, после чего лайтмап оказывается у нас в листе рендера. Смотри следующую картинку.
7. На картинке видно, что обсчитываемая текстура появилась в рендерлисте. Затем давим на ... и выбираем место, в которое мы собираемся записать необходимую текстуру, выбираем разрешение, в моём случае 512х512, но вы можете выставлять какое угодно. Помните одно - в максе текстуры больше 4096х4096 считаются очень плохо, а иногда вообще не считаются. Я в таких случаях пользуюсь майкой.
Кроме того, есть ещё один подводный камень - это физический размер объекта в максе.
8. После того, как лайтмап будет просчитан, мы можем укладывать его в фотожабе отдельным слоем по алгоритму multiple и соответствующей регулировкой прозрачности слоя. То есть "запечь" лайтмап в дифуз карту.
В приличных движках лайтмап обычно кладётся на отдельный текстурный канал, имеет отличное от остальных текстур разрешение и блендится с основной текстурой в зависимости от изменений динамического освещения. В ЛО такого пока нет.
Кроме того, в меню LightTracer, приведённом в самом начале, можно выставить любые параметры источника света, включая количество взаимных переотражений, количество лучей, мощность свечения и дискретизацию. С этим тоже можно побаловаться, но по умолчанию стоят довольно сносные установки.
Как вы понимаете, что сосчитать таким образом можно всё, не только лайтмап. Я предпочитаю делать запекание руками, так этот процесс легче контролировать. Просто тупой обсчёт может дать неудовлетворительные результаты, от чего вас, видимо, и предостерегает Стас. Вот результат нашего урока, тексутру я не редактировал, она автоматически накладывается после просчёта на объект, надеюсь, что разница видна всем невооружённым глазом. Видно, насколько изменились глубина и восприятие объёма.
9. ВАРНИНГ!!! Помните о том, что перекрывание раскладки в данном случае категорически запрещено!!! Программа не знает, поверхность какого текстурного шела ей обсчитывать и начинает пороть чушь. Поэтому если у вас 10 одинаковых пушечек на кораблике возмите аккуратно одну, разложите и просчитайте, а только потом!!! копируйте посчитанную пушечку в разные места. Кроме того!!! Копировать советую 2 раза, сначала необсчитанную геометрию, а потом всю её прибить и копировать обсчитанную. Поскольку сама геометрия тоже участвует в обсчёте. Ну и перекрывания мапинг-координат разных текстурных шелов категорически запрещено!!! Только уникальные текстуры.
Одна поверхность - один набор текстурных координат!!!
И в догонку ещё. Лайтмап, применение которого описано мной достаточно подробно в отдельной ветке, имеет самые прямые физические корни.
Для тех, кто плохо понимает физическую суть порцесса постараюсь объяснить его на двух простейших примерах:
1. Представьте себе, что вы заходите в тёмную комнату, (для простоты совершенно тёмную, в которой нет даже окон) с электрическим фонариком. Что вы будете ведеть? Любая поверхность, кроме физической абстракции абсолютно чёрного тела имеет свойства к трём видам изменения движения световых лучей, а именно: поглощению, отражению и рассеиванию. Свойства поверхности как раз и характеризуются тремя коэффициентами поглощения, отражения и рассеивания. Таким образом мы видим помимо круглого пятна фокуса электрического фонарика и ещё что-то. Это что-то и есть результат многократных переотражений рассеяного света. Все могут провести этот несложный опыт, зайдя, например, ночью в ванную комнату с фонарём, чтобы убедиться в том, что этот принцип верен всегда.
2. Для того, чтобы убедиться в том, что верен также и обратный постулат, а именно о распространении рассеяного света на открытом пространстве, достаточно провести другой несложный опыт, а точнее даже натуралистическое наблюдение. Если в проживаете в городе, то заставьте себя выйти на улицу в очень пасмурный, а лучше даже дождливый день и пройдите по улице. Направленного света в подобной обстановке не сущестует, весь свет, который вы видите в данный момент является рассеяным. Достаточно посмотреть на движущийся автомобиль, чтобы увидеть, что под ним имеется довольно аморфная, размытая, но всё же падающая тень, несмотря на отсутствие направленного источника света. Спросите, как такое может быть? Отвечаю: вы видите самый простой пример затухания рассеяного света. Собственно, это и есть лайтмап, отрицать его наличие бессмысленно и антинаучно.
Думаю глаза человеку даны именно для того, чтобы видеть и замечать реализм.
Автор: дизайнер А.С. Суворов Zloy Skin
2.4Приложение 4 Информация для особо злостных моделлеров
Особо злостные моделлеры не любят:
- устанавливать в максе масштабирование, что делается так:
меню Customize
пункт меню Unit Setup точечка Generic Units
в нем System Unit Setup
В окне System Unit Setup устанавливается 1 unit = 1.0 Meters
Теперь 1 единица макса равна 1 метру, в соответствии с этим масштабируется модель
- устанавливать центр модели при виде сверху по цетру координатной сетки
- устанавливать модель при виде Front носом вправо
- ставить колеса, гусеницы, псевдоподии модели на горизонтальную ось координатной сетки
- называть материалы макса уникальными именами в соответствии с именем модели
Например: Terminator2_face, Terminator2_body - это правильно, а если все материалы будут называться Standard 1 и т.д. будет плохо.
- думать о том, зачем нужен альфа-канал
- читать тему на форуме "Статьи о моделировании"
- читать тему на форуме "Плагины ED"
- читать тему на форуме "Статья 3"
Особо злостные моделлеры любят:
- моделировать в поли-меше и считать количество полигонов количеством треугольников. В ограничениях дается именно количество треугольников, если вы сомневаетесь, совершите конвертирование в EditMesh и познаете истину
- пользоваться всякими примочками и модификаторами, не умея ими пользоваться. Как пример - применение Chamber к сложной модели пакетом ребер приводит к достаточно плачевным результатам
- применять для моделировани прозрачности материала обычные .bmp файлы
Автор: дизайнер С. Колесников Drum27, Acgaen
2.5Приложение 5 Модель повреждений
Ущерб , который наносится самолету огнем зенитной артиллерии , ракетами или при столкновении с какими-либо
другими объектами в воздухе и на земле , определяется на основе модели для расчета столкновений , представляющей из себя упрощенную 3D-модель самолета , разбитую на несколько десятков зон . Поражение каждой зоны приводит к накоплению для нее ущерба и выставлению логикой необходимых значений для соответствующих аргументов рисования * повреждении .
[* Анимация для каждого элемента 3D-модели имеет свой идентификатор (аргумент рисования) , определяющий , при каких условиях эта анимация будет воспроизводиться . Например , при накоплении критического ущерба для элемента AIR_BRAKE_L (воздушный тормоз левого крыла [таблица 1] ) модели расчета столкновений , логика
изменяет состояние аргумента рисования 187 . В визуальной 3D-модели с аргументом 187 связана анимация исчезновения воздушного тормоза левого крыла и вывод на отрисовку рваного края этого крыла при значении аргумента 187 равном единице (т.е. при критическом поражении) . В результате , в игре мы увидим поврежденный край левого крыла и отваливающийся от самолета тормозной щиток . ]
Критическое поражение зоны (т.е. фактически ее уничтожение) приводит к выбрасыванию ее и связанных с ней зон из дальнейшей проверки столкновений . Так уничтожение внутренней части крыла приведет и к выбрасыванию из проверки столкновений центральной и внешней зоны крыла , а также тормозного щитка , элеронов и закрылков.
Также при критическом поражении генерируются летящие отдельно от самолета обломки . Для Су-25T существует четыре файла с обломками : носовая часть + кабина , задняя часть фюзеляжа + хвостовое оперение , левое крыло и правое крыло . На основе этих четырех базовых файлов и создаются более мелкие поврежденные элементы (элероны закрылки , части киля , крыльев и т.д. ) . Например , если после взрыва ракеты рядом с самолетом , мы видим на экране разбитый самолет с оторванным , допустим , левым крылом и разлетающимися тремя обломками , например , внешней части крыла , тормозного щитка и закрылка , то на самом деле рядом с 3D-моделью поврежденного самолета три раза было сгенерированно левое крыло со включенными соответствующим образом для каждой копии аргументами рисования повреждений, что и дало отображение только вышеприведенных элементов .
Итак , в модель повреждений входят следующие компоненты :
1. “Обертки“** и разрушенные элементы самолета, находящиеся непосредственно в его 3D-модели и отображаемые вместо целого элемента при его поражении .
(номера аргументов , с которыми надо связывать операции видимости объектов , содержатся в таблице 1 )
2. Четыре файла , содержащих носовую и хвостовую часть , левое и правое крыло .(используются для генерации где-то двадцати с лишним элементов оторванных от самолета )
3. 3D-модель для расчета столкновений . ( все необходимые сведения по именованию зон поражения находятся в таблице 1)
[** Большая часть повреждений делается при помощи поверхностей (“оберток”) , повторяющих пораженную поверхность , но лежащих поверх нее и несущих на себе TGA-текстуру с изображением пробоин в обшивке , сколов краски , рваных краев , следов горения и т.д.. На вышеприведенном рисунке под номерами 3 и 1 обозначены обертки с изображением рваных краев внешней части левого крыла и киля . Под номером 2 обозначена обертка с изображением легких повреждений центральной области киля . На рисунке снизу показан киль с обертками , введенными в отрисовку вдоль всей его поверхности ( в соответствии с зонами поражения - три обертки на киль и по одной на руль направления и демпфер ) ]
Обертки легких повреждений отображаются каждая по своему аргументу рисования , но все (почти все***) в интервале значений ] 0 , 1 [ .
Предположим , что на верхнюю часть киля (в 3D-модели расчета столкновений это элемент FIN_R_TOP) пришелся некоторый незначительный ущерб. В зависимости от его величины логика выставляет аргументу 241 (таблица 1) соответствующее значение , например 0.2 . При этом в визуальной модели самолета сработает анимация видимости для обертки верхней части киля , связанной с аргументом 241 .В игре мы увидим , как этот элемент киля покрылся легкими повреждениями . Дальнейший ущерб , приходящий на этот элемент , будет складываться с предыдущим и , соответственно, будет увеличиваться значение аргумента 241 (*** при этом может срабатывать видимость и других оберток , т.е. можно сделать так , чтобы рисунок повреждения менялся в зависимости от величины ущерба ). При критическом значении ущерба , накопленного элементом , происходит выставление аргумента рисования 241 в единицу – -элемент оторван от самолета . В этом случае наша обертка снова пропадает из отрисовки , а вместе с ней и сама верхняя часть киля (т.к. ее видимость тоже связана с аргументом 241 , но лежит уже в интервале [0,1[ ) . Вместо этих элементов в отрисовку вводится обертка , изображающая рваный верхний край средней части киля ( элемент 1 на верхнем рисунке ) , и нервюра , находящаяся в стыке верхнего и среднего элементов киля (для них интервал видимости по аргументу 241 равен [1, +∞ [ ****) . Аналогичным образом срабатывают легкие повреждения и для всех остальных элементов .
Срыв обшивки на модели также делается почти вышеприведенным способом , единственное отличие заключается в том , что придется подменять целый элемент на поврежденный + обертка на область сорванной обшивки (имитация рваного края ) + силовой набор.
[**** В принципе , каждый элемент может реагировать одновременно на несколько аргументов видимости , тогда результирующая видимость определяется логическим перемножением значений видимостей этих аргументов. Так видимость элемента 1 задается не только аргументом 241 , но еще и 242 ( интервал видимости [0,1[ . Допустим , что через некоторое время после выставления аргумент 241 в единицу , самолет получает новое критическое попадание уже в среднюю часть киля (элемент FIN_R_CENTER) , логика выставляет аргумент 242 в единицу . Для элемента 1 произойдет перемножение видимостей аргументов 241 и 242 , результатом чего станет выбрасывание элемента 1 из отрисовки .]
Для того ,чтобы связать видимость элементов со значениями аргументов рисования, в 3D Max делается следующее:
1. В Track View для выбранного элемента добавляем трек видимости (кнопка Add Visibility Track) . Затем связываем этот трек с контроллером “ArgBased Visibility” .
2. Правой кнопкой мыши щелкаем на “Visibility” и в развернувшемся меню выбираем пункт “Property”. Появится новое окно , в котором можно добавить нужный аргумент (нажимается кнопка “Add” , в строке “Argument” вводим номер аргумента и нажимаем кнопку “Set Active”).
3. Осталось только поставить ключи в треках видимости (кнопка “Add Keys”) . Синим цветом будет обозначен интервал в котором данный элемент окажется виден . На нижнем рисунке изображены треки для аргументов 241 и 242 обертки 1.
Таблица 1.
Таблица соответствий между именем поврежденного элемента в модели для расчета и включением аргументов повреждений
| Киль | |
| FIN_R_TOP | Повреждение верхней части киля Аргумент 241 |
| FIN_R_CENTER | Повреждение центральной части киля Аргумент 242 |
| FIN_R_BOTTOM | Повреждение нижней части киля Аргумент 243 |
| RUDDER_R | Повреждение руля направления Аргумент 247 |
| RUDDER_L | Повреждение демпфера Аргумент 248 |
| Стабилизаторы | |
| ELEVATOR_L_OUT | Повреждение внешней части левого руля высоты Аргумент 239 |
| ELEVATOR_L_IN | Повреждение внутренней части левого руля высоты Аргумент 240 |
| STABILIZER_L_OUT | Повреждение внешней части левого стабилизатора Аргумент 235 |
| STABILIZER_L_IN | Повреждение внутренней части левого стабилизатора Аргумент 236 |
| ELEVATOR_R_OUT | Повреждение внешней части правого руля высоты Аргумент 237 |
| ELEVATOR_R_IN | Повреждение внутренней части правого руля высоты Аргумент 238 |
| STABILIZER_R_OUT | Повреждение внешней части правого стабилизатора Аргумент 233 |
| STABILIZER_R_IN | Повреждение внутренней части левого стабилизатора Аргумент 234 |
| Мотогондолы и двигатели | |
| MTG_L | Повреждение левой мотогондолы (центральная часть) Аргумент 168 |
| MTG_L_BOTTOM | Повреждение левой мотогондолы (нижняя часть) Аргумент 169 |
| ENGINE_L | Разрушение левого двигателя Аргумент 167 |
| MTG_R | Повреждение правой мотогондолы (центральная часть) Аргумент 162 |
| MTG_R_BOTTOM | Повреждение правой мотогондолы (нижняя часть) Аргумент 163 |
| ENGINE_R | Разрушение правого двигателя Аргумент 161 |
| Фюзеляж | |
| FUSELAGE_LEFT_SIDE | Повреждение левого борта центральной части фюзеляжа Аргумент 154 (дополнительно можно включать срыв люков с бортов аргументами 300 и 301 ) |
| FUSELAGE_RIGHT_SIDE | Повреждение правого борта центральной части фюзеляжа Аргумент 153 (дополнительно можно включать срыв люков с бортов аргументами 302 и 303) |
| TAIL | Повреждение задней части фюзеляжа Аргумент 81 |
| NOSE_LEFT_SIDE | Повреждение левого борта носовой части фюзеляжа Аргумент 296 (срыв первого люка) Аргумент 297 (срыв второго люка) Критическое повреждение (уничтожение всей носовой части) Аргумент 146 выставляется в 1 |
| NOSE_RIGHT_SIDE | Повреждение правого борта носовой части фюзеляжа Аргумент 298 (срыв первого люка) И / ИЛИ Аргумент 299 (срыв второго люка) Критическое повреждение (уничтожение всей носовой части) Аргумент 146 выставляется в 1 |
| NOSE_CENTER | Носовая часть фюзеляжа (центр) Критическое повреждение (уничтожение всей носовой части) Аргумент 146 выставляется в 1 |
| CABIN_LEFT_SIDE | Повреждение левого борта кабины Аргумент 150 Критическое повреждение (уничтожение всей передней части) Аргумент 147 выставляется в 1 |
| CABIN_RIGHT_SIDE | Повреждение правого борта кабины Аргумент 149 Критическое повреждение (уничтожение всей передней части) Аргумент 147 выставляется в 1 |
| COCKPIT | Попадание в пилота Аргумент 65 выставляется в 1 |
| GUN | Отказ пушки |
| Правое крыло | |
| AIR_BRAKE_R | Разрушение воздушного тормоза правого крыла Аргумент 183 |
| WING_R_OUT | Повреждение внешней части правого крыла Аргумент 213 |
| WING_R_CENTER | Повреждение центральной части правого крыла Аргумент 214 |
| WING_R_IN | Повреждение внутренней части правого крыла Аргумент 215 |
| ELERON_R | Повреждение элерона правого крыла Аргумент 216 |
| FLAP_R_OUT | Повреждение внешнего закрылка правого крыла Аргумент 217 |
| FLAP_R_IN | Повреждение внешнего закрылка правого крыла Аргумент 218 |
| WING_R_PART_OUT | Разрушение внешнего предкрылка правого крыла Аргумент 220 |
| WING_R_PART_CENTER | Разрушение центрального предкрылка правого крыла Аргумент 221 |
| WING_R_PART_IN | Разрушение внутреннего предкрылка правого крыла Аргумент 222 |
| Левое крыло | |
| AIR_BRAKE_L | Разрушение воздушного тормоза левого крыла Аргумент 187 |
| WING_L_OUT | Повреждение внешней части левого крыла Аргумент 223 |
| WING_L_CENTER | Повреждение центральной части правого крыла Аргумент 224 |
| WING_L_IN | Повреждение внутренней части левого крыла Аргумент 225 |
| ELERON_L | Повреждение элерона левого крыла Аргумент 226 |
| FLAP_L_OUT | Повреждение внешнего закрылка левого крыла Аргумент 227 |
| FLAP_L_IN | Повреждение внешнего закрылка левого крыла Аргумент 228 |
| WING_L_PART_OUT | Разрушение внешнего предкрылка левого крыла Аргумент 230 |
| WING_L_PART_CENTER | Разрушение центрального предкрылка левого крыла Аргумент 231 |
| WING_L_PART_IN | Разрушение внутреннего предкрылка левого крыла Аргумент 232 |
| Шасси | |
| FRONT_GEAR_BOX | Попадание в отсек переднего шасси Аргумент 265 выставляется в 1 |
| RIGHT_GEAR_BOX | Попадание в отсек правого шасси Аргумент 266 выставляется в 1 |
| LEFT_GEAR_BOX | Попадание в отсек левого шасси Аргумент 267 выставляется в 1 |
Автор: дизайнер Т. Цыганков Timur
2.6Приложение 6 Создание стационарных сооружений в Lock On
справочное руководство
Содержание
Брифинг
Настройка 3ds max для LOM Utils
Определения
Render Mesh
LOD dummy
Collision Model
Object Bounding Box
Освещенные ночью окна
Дым
Материал
Переменные перечней *.sht
Анимация
Анимация разрушения
CDDS Studio и текстуры в Lock On
Расположение в инсталляции Lock On
LOD-ы и clipping в Lock On
Общие ограничения
Общие рекомендации
Примечания