продолжение

Открываем файл dat.любого судна мода MFM. Я взял наугад М31Х.

Открываем превью модели.(стрелка) Далее жмем кнопку обозначенную,цифрой 1. Тем самым вызываем zon.файл.  Открывается окно с этим файлом,тут же его сворачиваем,а в первом окне(dat.) жмем кнопку под цифрой 2. Оба файла «сливаются» в один.

Видим у судна в центре всего 2 сферы. Это нормально. Это подразумевает поиск остальных сфер у моделей разломов этого судна. Чтобы увидеть модели этих разломов и конструкцию зон,присущую им,делаем следующее:

Пресс «+» под цифрой 1,далее- любой из указанных стрелками Node(это и есть модели разломов- F-forward-перед-нос,В-back-зад-корма) и жмем обе кнопки под цифрой 2. Та кнопка что левее,делает модель видимой* Та кнопка,что правее,делает невидимыми  все другие модели. Все эти операции видимости-невидимости не производят никаких изменений и созданы просто для удобства работы в программе. В результате видим следующее:

*-в конструкции dat. судов c разломами так задумано: пока судно составляет единое целое,"играет" модель главного node,модели разломов же появляются на "арене" в момент,собственно,разлома судна,на замену тут же исчезающей из игры модели "целиковой",это сделано для избежания "пустой"нагрузки на  систему и игру без надобности одними и теми же полигонами.До момента разлома модели разломов невидимы и игра их "не работает" Сделать модель видимой-невидимой в игре-вкладка Node Positioning.(это чуть выше Model Preview  и Linked 3D model Галочка-снять поставить-напротив Visible.

продолжение следует

продолжение

На скрине ниже  показан пример примерно правильного «покрытия» объекта сферами.

Суть концепции такова: приблизительно точно покрыть сферами габариты судна по всем координатам. Но при этом необходимо учесть:под килем сфера должна выступать намеренно наружу на игровое расстояние примерно 2 метра+-0,5метра. Для имитации «магнитов» торпед. Во всех остальных местах корпуса судна допуск выступа(либо,наоборот,нехватки) за пределы габаритов примерно 1 метр. В особых случаях(например,покрытие надстройки) доля выступа может быть до 2 метров. Участки корпуса,которые трудно покрыть одной сферой разом,покрываются двумя сферами меньших размеров(тремя,четырьмя,сколько понадобится)и наоборот. Чересчур педантичная точность ни к чему,но и далеко «отходить от курса» чревато.
Из всего этого следует,что…багованное судно M31X(как и очень многие другие моддерные суда) требует «ремонта».
О «ремонте» позже.

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

продолжение

Боксы

В отличие от сфер  боксы отличаются друг от друга цветом в зависимости от их типа и назначения. Выделенный свиток бокса также,как и в случае со сферами свой "родной" бокс выделяет ярко желтым цветом. В целом,здесь примерно та же кухня,что и в сферах,т.е.интуитивно уже понятно,что с ними надо делать. Остановлюсь лишь на некоторых моментах. У любого бокса,в отличие от сфер по выставлению его координат имеется  не 1,а 2 параметра-минимальный и максимальный.(min. max.) Для чего? Для того,чтобы вы при создании и расположении бокса не теряли ориентир,верх-низ,зад-перед,лево-право. Это важно. Минимальные настройки должны отвечать за грани низ-зад-лево***(читайте сноску),максимальные-верх-перед-право. Например,если вы перепутаете мин-макс бокса,скажем огня,то он будет гореть у вас в трюме,и вы его не увидите,либо наоборот,пылать в воздухе над палубой.На скрине,я как мог,постарался всё это отобразить.

***В случае парных боксов(где каждому боксу свой борт) минимальные настройки -низ-зад-ЦЕНТР ПРОДОЛЬНОЙ ОСИ СУДНА. Максимальные-верх-перед-ВНЕШНЯЯ СТОРОНА БОРТА. В случае централизованного бокса-как уже писалось выше.
Тип…здесь прописывается номер типа бокса. При выделении  этого параметра с номером,ниже,в дескрипшн должно отобразиться определение этого типа,присвоенное этому номеру. Если дескрипшн не распознает и пишет unknown zone type,то по номеру типа вы можете определить сам тип в файле Zones.cfg
ArmorLevel и LinkTo аналогично настройкам сфер.
В заключении хочу озвучить одно негласное правило,которое ни разу меня не подводило,и я всегда им с успехом пользовался до тех пор,пока  не научился сносно понимать эту чудесную программу и работать в ней уже почти без проблем:
Производя ремонт zon.какого-нибудь нерадиво сделанного моддерного судна,либо создавая zon. «с нуля» я всегда держал в раскрытом виде два судна,примерно схожих по габаритам,а главное,по типу:с одной стороны-ремонтируемое(создаваемое),с другой- стоковый добротный вариант. Вникая в принцип и логику размещенных в сток-судне сфер и боксов,настройки их параметров,учитывая примерную разницу соотношений габаритов судна к компонентам zon.,всё это я переносил-производил уже на "стапельном" судне,разумеется,заранее прикидывая уже разницу соотношений габаритов между судами,и внутренними соотношениями размеров  и расположения боксов.
Вот,собственно, пока и всё. Удачи в новых начинаниях.

Конец

Wise

Node, принцип их работы, id, Parent id

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

Каждый юнит,будь то,судно или самолёт, в своём dat-файле имеет только 1(!) главный  Node (замечу,что схема работы Node библиотечных файлов орудий и других общих установок,к которым обращаются файлы юнитов, схожа,но всё же,имеет свои отличительные особенности,и это уже другая история.  О ней позже,по возможности и при наличии свободного времени). Все остальные Node конструкции любого  юнита «не имеют права» находиться сами по себе вне главного  Node,даже если по идентификационным номерам они имеют зависимость от него. Это прямая дорога к вылетам. Игра встречает более одного,равноценного по иерархии, Node и не знает,какой из них работать.
Каждый Node(chunk) в своих настройках имеет свой уникальный идентификационный номер(id),а также  идентификационный номер «родителя»(Parent id),от которого зависит какой-либо конкретный Node. Каждый собственный id,имеющийся у всех чанков,которым предписано его иметь,должен быть уникальным. Повторение его у разных чанков в одной игре-вылет 100%. Рассмотрим  на скрине:

Главный Node-свиток(выделен синим),как и любой другой «дочерний» Node имеет свой собственный уникальный id. Но,в отличие от «дочерних» и в связи с тем,что он главный(«отец»)-он не имеет Parent id.(0х00000000000000) Все «дочерние»(зависимые от главного) Node-свитки,кроме своих уникальных ид.номеров,в графе «Parent id» имеют ид.номер «отца»,кроме того,они «обязаны» находиться внутри этого «родительского» Node-свитка. Всё это показано на скрине. Node-свитки,обозначенные знаком вопроса расположены неправильно. Они «обязаны»находиться уже внутри главных «дочерних» Node,указанных зелёными стрелками. Но в данном случае «вопросные» Node находятся в таком расположении временно,как визуальный образец при создании мода(впоследствии,удаляемый,либо перемещаемый на своё законное место)а также,как наглядное пособие по уроку упрощённого перемещения  Node в ту иерархию,которая необходима на взгляд моддера.
Суть всей этой канители-понять принцип строгого соблюдения абсолютно любым Node  «субординации».. «Знай сверчок свой шесток».

Итак,если в каком-либо из юнитов в dat.файле вы видите непорядок конструкции иерархии Node,первым делом,глядя на сам юнит, вы должны определить,в каком именно Node-свитке должен находиться «заблудившийся» Node. Снова рассмотрим на скрине:

Видим,что неправильно расположенный Node - <New_label>8,это дымоход(красная стрелка). В «родителях» он имеет главный  Node-M04B(чёрные стрелки) а по иерархии и своему расположению на судне,должен принадлежать Node-свитку кормового разлома судна,т.е. Node- M04B_B(зелёная стрелка).Значит,если это законченный юнит,то совершенно необходимо исправить эту ошибку и вернуть этому <New_label>8 своего «законного родителя». Сделать это легко:
1 Определяем «законного родителя», и копируем его идентификационный номер в буфер обмена,как на скрине:

2.Возвращаемся к «заблудившемуся» Node,наводим курсор мыши на его Parent id и делаем левый клик вместе с Ctrl. Откроется возможность переименования этого Parent id,что мы благополучно и используем,вставив из буфера обмена ид.номер «законного папаши».(на скрине):

При этом весь «заблудившийся» Node вместе со всем своим содержимым автоматически «ныряет» в свиток своего «нового родителя». Разумеется,после операции не забываем сейвить весь файл.
Примечание: «заблудившиеся»  Node,уже имеющие при этом в Parent id номер своего «законного родителя» так просто не хотят перемещаться в его свиток. Для решения этой проблемы достаточно сначала вставить в Parent id «заблудившегося» Node ид.номер,например, главного  Node , «блудный сын» нырнёт туда,а уже оттуда,тем же макаром отправляете его туда,где ему и место. Вот пока всё.

Wise

Совершенно верно. Именно этим методом «крепятся» также и библиотечные установки к судам и самолетам. Но в данном уроке я рассказывал только о судах и самолетах(исключая лодки,имеющие в своей конструкции более сложные схемы построения,указанные тобой ). Их мы не можем ни к чему прикрепить ,это полностью завершенные самостоятельные объекты,потому их главный  Node и не имеет  Parent ID ,вернее,оно имеет значение- 0х00000000000000.

Смотри скрин. Выделяешь  любой заблудившийся Node,его zon-точка выделится красным цветом. В случае,если заблудившийся Node-это модель,то такой метод определения местоположения на судне,а значит и определения «истинного родителя» не всегда может помочь,т.к. непутевый моддер может внедрить в файл модель какой либо детали со сбитым центром координат,что может в свою очередь ввести в заблуждение. В этом случае поможет «игра» кнопками видимости-невидимости Node.о которых я уже рассказывал выше. В любом  случае,тем или иным методом,но «законный родитель» «загулявшего» Node определяется.

Wise

Алексею(Лукнеру)
3d-моделинг применяется везде. Отдельные области применения оправданно требуют максимально качественного моделирования,и вопрос лимита полигонов там не стоит. 3d-моделинг для компьютерных игр- это отдельная и самая востребованная область применения. Сложность 3d-моделинга в ней заключается в том,что помимо создания качественных моделей необходимо еще стараться соблюдать т.н. лимит. Потому,что в  отличие от других областей применения(видео-кинематограф и т.д.),где модель воспринимается,как один целый предмет,в компьютерных играх система вынуждена «рисовать» каждую «клетку»(полигон) этой модели.Короче,весь вопрос упирается в ресурсы компа и двигателя игры. И если мы хотим,чтобы игра была без тормозов,нам требуются модели,созданные по принципу-«дёшево и сердито». Лимит-предел,превышение которого недопустимо. В моделировании для комп.игр это понятие относительно. В нём нет чёткого предела,есть примерные величины,переступать которые можно,но не рекомендуется(+-). Надо переступить-делай это,но сильно с ума не сходи. Средние числа никто не знает,но на примерах можно сделать приблизительный вывод. Для этого самого примера я взял всё ту же самую известную лодку товарисча Тестпилота. Вот первый скрин. Это его гайка:

На скрине видно,сколько полигонов на одну эту гайку потратил ТР. Теперь второй скрин,где гайку создал уже я для сравнения с гайкой ТР:

Теперь скрин 3:

Где мы видим,сколько всего потрачено полигонов ТР на одни только ср..ные гайки одной только детали. А этих гаек у ТР там еще навалом в других деталях(не говоря уже о деталях самих).Ну и остается посчитать,сколько полигонов было бы достаточно для этих самых гаек: 16х24=384. Разница составляет 7104 дармоедных полигона. Для сравнения:этой суммы полигонов хватает двум стоковым(сх3) судам. 24 гайки ТР сожрали средний стоковый лимит двух судов. Суть в том,что текстуре,которая будет покрывать эти гайки,абсолютно плевать,сколько в ровной плоскости полигонов. Она идентично покроет собою,как 1 полигон,так и 1000 и 1000000. При этом,выигрыша от миллиона полигонов ровно ноль. А проигрыш колоссальный. Это как,нанять на работу для охраны какой-нибудь клумбы не одного сторожа с з\п 3000р.,а дивизию сторожей,с оплатой 3000р.каждому. Маразм очевиден. Смысл этого примера: не делай 100 полигонов там,где нужен всего 1.
След.скрины: та же самая деталь.




Я выделяю один из компонентов этой детали,делаю его невидимым,и что я вижу: под этим компонентом внутри скрываются ещё компоненты. Я может запамятовал,а что в хантере предусмотрен реальный ремонт лодки и разбор её агрегатов на части? Для кого ТР впихнул туда куски,которые в игре никогда никто не увидит? Зато,их увидят игра  и система. И будут их работать. Они ж понятия не имеют,что  думать для ТР,это не про него..Вот сюда же ещё немного скринов:

Нижняя деталь-это палуба рубки cх5 от   ubi. 89 полигонов-всё по уму,осталось дело за хорошо рисованной текстурой. Смотрим далее:

Тестпилоту палубы юбиков показалось мало,и он добавил сверху кучу переплетенных прутьев,т.н.решетку, тянущую в общ.сложности на 6,5 тысяч полигонов. Кто мне объяснит,для чего ТР это сделал? Лично я не нашел ни одного вразумительного объяснения,кроме одного: приступ. Ну и вот ещё:

Обод горловины люка в его исполнении. 4000 полигонов. Всё бы ничего,но сверху на этот обод он накладывает люк(зеленые стрелки),который скрывает собой этот обод от посторонних глаз навсегда. Уже без комментариев. Мораль: не создавай(и не оставляй) полигоны там,где их никогда не будет видно. Итог мода ТР: 90000 прямых излишков+165000 косвенных. Пусть даже без косвенных.  90000. Здоровенный сток-конвой сожран неграмотностью ТР. 
Последние 2 скрина:


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