Планирование
Начнем с того, что 64к-интру, лучше делать «с головы» а не «с хвоста». Существуют гении-приверженцы второго варианта, но это тема отдельного разговора.
Для начала нужно определиться, что за интра должна получиться в результате. Вариант «она будет мега-супер-оригинальной» - не прокатывает. Найдите аналоги. Возьмите 10-20 интр, и распишите, для начала, следующее (для каждой):
1. продолжительность
2. количество сцен
3. «динамика» интры, характер движения камеры, смены сцен
4. количество и характер синхро-связей
5. общее количество геометрии
6. «характер» геометрии
Выписав все это на обычный листочек в клетку, посмотрите покомпонентно, в чем ваша работа будет похожа на другие – т.е., ответьте на эти 6 вопросов (можете добавить еще, по вкусу) применительно к своей интре.
При этом, количественные характеристики помогут вам в определении «длины понтов» - скажем, если при заявленной длительности в 5 минут у вас сцен меньше, чем, скажем, в 195/95/256, который идет 3 минуты, то наверное ваша интра будет смотреться бедной на геометрию, и если ничего не предпринять – камерой, эффектами и т.д., то, вероятно, еще и скучной, затянутой.
Ну, а если вы, например, решили, что геометрии будет «в 2 раза больше», то задача уже формализуется достаточно четко: осталось придумать, как эти «2 раза» реализовать.
Постановка задачи
Когда задача в целом определена, можно приступать к разработке формата хранения данных. Чтобы не растекаться мыслью по древу, говорить будем только о хранении геометрии, благо с остальными частями все обстоит аналогичным образом.
Для начала, неплохо бы иметь уже готовый «минимальный» движок – чтобы знать, сколько примерно места остается на данные. Следующий шаг – распределение данных внутри свободного пространства. Сколько вы готовы отвести под музыку? А сколько реально потребуется для получения звука, который вас устроит? А сколько «съедят» текстуры? Ответив себе самому на все эти вопросы, в итоге вы должны получить одно 16-разрядное число: размер пространства, отведенного под решение конкретной задачи. В нашем случае, под геометрию.
Анализ
Помните вопрос №6 – про характер геометрии? Отвечать на него я вас уговаривал в п.1, а использовать ответ на него мы будем только сейчас. Жизнь не справедлива, однозначно…
 
Посмотрите внимательно на сцену (надеюсь у вас уже есть эскизы в карандаше или в 3д-максе, а не абстрактное «хочу»?) и попробуйте найти преобладающие геометрические формы. Что это? Кубы? Трубы (трубочки???)? Сферы? Полусферы с маленькой дыркой в правом боку? Насколько исходные «примитивы» поддаются генерации? Сколько раз повторяются похожие формы? Как расположены похожие объекты? Хаотично? Кружком? В линейку? Какие формы можно получить из других, и какими алгоритмами? Каков характер исходных форм – округлые, с жесткими углами, скругленные, шипастые? Не поленитесь, забейте получившиеся данные в табличку, откиньтесь на спинку стула и охватите ее целиком. Ищите повторения, повторения с модификацией – все, что можно описать простыми, элементарными действиями.
Пример анализа. Допустим, вы делаете сцену «завода». Там будет одна комната, две двери, шесть лестниц, и сотня ящиков. Двери нарисуем в текстуре – т.к. выяснилось, что открывать их мы не собираемся. Лестницы… на каждой по 4 пролета, по 50 ступеней на каждом. Умножаем на 6… маааать! 1200 объектов! Ок, моделим одну ступеньку в Максе, портируем в интру, затем «расставляем по сцене» - генерим клоны стуеней. Потом клонируем целые пролеты – для этого напишем код, который сможет перемещать/поворачивать пролет целиком. Затем клонируем получившуюся лестницу… и вуаля! Конечно еще нам понадобятся площадки, опоры и т.д., но это уже не так емко. А вот ящики простым клонированием не расставишь… но отличаются они только текстурами, положением и углом поворота по одной (!) оси…
Проектирование формата
С «форматом хранения лестниц» все должно быть ясно: более-менее оптимально утоптать информацию о клонах объекта за проблему можно не считать.
Разберемся с ящиками. Храним X, Y, Z, поворот по одной из осей, текстуру. 5 байт. Множим на 100, получаем 500 байт. Жирновато! Стоп, а Z зачем? Ящики в три ряда стоят? Хм, рисуем в 3 прохода, с разным Z, а храним 4 байта на ящик. Что еще? На сколько удалены ящики друг от друга? На разное «чуть-чуть»? Пересортируйте их так, чтобы это «чуть-чуть» было между смежными (по порядку следования описывающих объекты данных) объектами, и дополнительно – по росту удаленности. Сколько разрядов нужно для хранения смещений? В среднем, 4? На X и Y получается 8 бит – мы ужались до трех байт!
Сколько текстур задействовано на ящиках? 4? Какая дискретность будет достаточной для поворота? 64 фазы хватит? Тогда объединяем 2 бита информации о текстуре с 6 битами информации о повороте. Итого, 2 байта на ящик. Предел? Для этого этапа – возможно…
Компрессия
Код написали, массивчик заполнили, все это даже работает, но занимает по-прежнему много? Допустим, имеем описание сцены (x,y,rotation,texture). Данные, например, такие:
6,2,4,0
7,5,2,0,
5,1,4,1,
9,6,2,4,1,
9,2,4,2,1,
9,3,2,2,1
9,1,2,2,1,
7,4,2,2,5
AsPack и UPX не помогают, выкинуть из структуры уже нечего… Что делать? Возвращаться к пункту №3! Смотрите теперь уже на «голые» данные, ищите закономерности. С приведенными выше «данными», самое простое что можно сделать – поменять строки и столбцы местами. Получившиеся регулярные «дыры» из повторяющихся чисел компрессор воспримет гораздо благосклоннее. Вывод: всегда думайте, как будут паковаться ваши данные. Более того, изначально, с самых первых шагов, держите это в голове. Часто вроде бы избыточный, безо всяких «фокусов» с дельта-кодированием и усечением точности формат дает лучшие результаты, пототому что был изначально рассчитан на упаковку.
Черная магия
Посмотрите на рисунок, образуемый ящиками на виде сверху. Может, он что –то вам напоминает? Может, попробовать сгенерить текстуру, и использовать ее как карту расположения ящиков? А может, вам не так уж важно, как стоит каждый конкретный ящик, и их расстановку можно возложить на генератор (псевдо)случайных чисел? Пробуйте!
|
