Статья 3

[Acgaen]

Статья 3. Проблемы.

 

Так как общественность интуитивно определила мою потребность в написании третьей статьи:

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

А Абрамс вы уже делаете? Посмотри интересную картинку:»

 

Пишу очередную нетленку.

 

К данному моменту накопился достаточный опыт работы нашей фирмы с соболезнующими нашему продукту разработчиками, что, однако, выявило и сопутствующие проблемы в этой области жизнедеятельности.

К коим относятся некоторые общие вещи, и проблемные, и позволяющие с оптимизмом смотреть в будущее совместной работы. Здесь остановимся на проблемных сторонах вопроса, которые частично были описаны в предыдущей статье.

 

Пишу без ложной скромности и почти в тезисной форме.

 

Бросается в глаза то, что некоторые начинающие разработчики просто игнорируют информацию в наших ранних статейках и надеются на то, что получится все сразу быстро и красиво. Это влечет за собой косяки в разработке, затягивание ее, и дальнейший отход автора, столкнувшегося с преодолимыми трудностями, от дел. Для таких товарищей необходимо глубоко понять фразу «изучайте мат. часть». Тут нужно понимание, что дизайнер учится своему делу в среднем всю жизнь, и если первая разработка будет вестись долго, то вторая уже пойдет гораздо быстрее с возрастающим по гиперболе (горбом вверх) качеством. Но трудности ломают многих и в итоге, мы имеем вполне хороший выход по оружию, но больших моделей, которые приняты, или в стадии принятия на вооружение симулятора, всего – Т-72, Як-40, Мираж Ф-1, УАЗ-469, Предатор и, вроде, все.

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

 

Теперь по частностям.

 

- нет большой необходимости браться сразу за сложную модель типа танка, есть много объектов, которые требуют разработки и на которых можно ознакомиться с тонкостями работы (например – опоры ЖД путей)

 

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

 

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

 

Теперь непосредственно по моделированию:

 

- множество одинаковых мелких объектов должны иметь различные вариации в текстурировании. Как пример, можно назвать элементы активной брони танка, их много и при одном и том же текстурировании, бросается в глаза и идеальная «близнецовость», чего в реальности быть не может. Конечно, если следовать буквально написанному, то для этих элементов может уйти текстурного пространства больше, чем на все остальное изделие. Поэтому, можно создать несколько шаблонных вариантов (ну, шесть, например) и в разнобой их распределить в модели

 

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

 

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

 

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

 

- касаемо предыдущего вопроса – есть проблемы с перенесением пропорций объекта на модель. Эта засада кроется в опыте моделирования, никто с наскока не сможет достаточно точно увидеть пропорциональные отношения, здесь нужна тренировка, и рисование чайника (упоминаемое в предыдущем труде) будет полезно именно начинающим моделлерам. Ну, и отсутствие попыток сделать крупный сложный объект с первого раза

 

- чем меньше применяется всяких модификаторов для создания объекта - тем меньше проблем мы испытаем с выгрузкой модели в ЛО

 

- нужно не забывать сваривать вершины меша после всяких непонятных операций, типа detach, explode и т.д.

 

- все элементы модели нужно конвертить в edit mesh перед отправкой нам

 

- модель и приложенная к ней текстура должны лежать в одной папке – распределять геометрию и текстуры по спец. папочкам не нужно

 

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

 

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