Revision 2012

Ну да. Просто не знаю, нужно ли писать Иллюминэйшн Модели, или достаточно вызвать соответствующую функцию с параметрами.

Это, конечно, круто, но немножко попахивает кидаловом. Т.к. в итоге, когда оно распаковывает все ресурсы, памяти жрет о-го-го же. А раньше как было? Есть у тебя 48 кб и все, выше головы не прыгнешь, некуда разжимать, хоть ты в миллион раз сожми данные. Можно сказать, что сейчас все эти конкурсы окончательно выродились в соревнования архиваторов. С программной точки зрения, конечно. Художники, музыканты и прочие режиссеры-постановщики напротив развернулись по-полной.

Эээ. А архивация это не программная генерация? Я просто не вижу принципиальной разницы допустим, между каким-нибудь классическим методом сжатия и вот таким-вот как в демках. Различие же только в узкости специализации применения. Ведь применительно к графике, тот же jpeg тоже с помощью математических формул создает изображение. И даже bmp, только алгоритм там совсем примитивный, в сравнении.

Лол. А я про сжатие эксешников, скорее говорил... вроде есть проги именно архиваторы.

Guyver > Не. Ничего общего. Процедурные текстуры генерируются с помощью формул. От начала до конца. То-есть не берём картинку и пытаемся превратить её в математическую формулу, а пишем формулу, чтобы получить картинку. Хорошая новость - бесконечная сложность текстур, плохая - нельзя запихнуть вот это лого именно в этот кусок. Только математику хорошо знать надо.
Используется оно очень часто в кино.
Архивация - метот сжатия с помощью определённых правил.

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

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

Просто не знаю как описать/показать это. В наши изнеженные времена, бывает очень сложно 3Д с математикой соединить. Особенно, если брать что-нибудь простое вроде Макса.

INHELLER, а вот эти действия "сжимаются по тем или иным правилам" (и разжимаются понятное дело), и "генерируются по заданному алгоритму" чем различаются? В любом случае же берутся некие исходные данные, какой-нибудь алгоритм и по нему уже "вычисляется цвет каждой точки". Т.е. что такое в твоем понимании "просто текстура"? Просто текстур не бывает же. Любые данные в компьютере это просто набор чисел, который по определенным алгоритмам обрабатывается и вот на выходе уже получаются "текстуры", "музыка" и прочие "тексты".

И ЗД это же тоже математика, что значит "с математикой соединить?"

Разница в том, что в первом варианте имеем изначально картинку - набор пикселей. По ней строим формулы и прочую хрень, по которым можно восстановить эту картинку.
Во втором случае имеем сразу формулы, которые нам должны теоретически дать (и дают) нужную картинку.