ZloySkin

Без фотожабы скорее всего обойтись будет чрезвычайно сложно. А с фотожабой последовательность действий будет следующая: 1. Ищешь в интернете, (на диске, купленном у пиратов на рынке, у друзей и так далее) плугин к фотожабе, который так и называется DDSPhotoShopPlugin, затем файл dds.8bi пишешь в каталог PhotoShop\Plug-Ins, а msvcp71.dll и msvcr71.dll записываешь в корень фотожабы. Программа готова к сохранению в формате DXT. 2. Берёшь любую катринку, скалируешь её таким образом, чтобы каждая из её сторон была степенью двойки, для обычного экрана лучше всего использовать размер 1024х1024, после чего сохраняешь картинку, как dds, обычным SaveAs. Всё!

Отвечаю на вопрос Andrew Tikhonovsky. Surface чрезвычайно полезный и удобный инструмент моделинга. Делать им людей, животных, одежду, ткани и другие природные объекты чрезвычайно удобно. Скажу даже более того, я не встречал более удобного интрумента для высокополигонального моделинга природных объектов в максе. Ну постольку-поскольку, например, в ксюхе или люфтваффе есть ещё более простые и удобные, а, скажем майский SubDivisionSurface произвёл на меня впечатление весьма тяжёлой и не вполне логичной штуковины, как собственно и всё, что касается майки в целом. :-) Поэтому максовый Surface попрежнему остаётся зебест и намбаван. Но! Повторяю, что заточен он под часто-встречающиеся, но от этого отнюдь не менее специфические вещи. Чем, скажите мне, будет отличаться друг от друга инструментарий - тот же лофт, нурбсы, сюрфейсы, если установить уровень дискретизации 0? Да ничем... Зачем в таком случае усложнять себе жизнь, если на выходе нам необходимо получить меш, не легче ли и работать напрямую прямо с этим мешем непосредственно? Хотя в сущности это уже вопрос о том, кто к чему больше привык и кто с каким инструментом работает быстрее, то есть опять же вопрос заточенности ручёнок под конкретную лопату. Про культуру моделирования ты нигде и никогда не сможешь прочитать, она накапливается с годами и количеством тумаков и матов от тех людей, которым ты передаёшь свои модели на дальнейшую обработку. Если люди перестают со временем высказывать своё возмущение твоими моделями, то есть не тем каким способом они сделаны (способы у всвех бывают разными), а именно конечным результатом, то считай что начал "окультуриваться". Проблема может быть ещё и в том, что люди просто не захотят тебе об этом говорить, продпочтя банальную фразу "Модель хорошая, но, к сожалению, она нам не подходит." Помни только об одном: настоящая культура моделирования - это когда твоя модель подходит абсолютно всем без исключения, вне зависимости от каких-либо специфических требований конкретного движка.

На полный трактат у меня может и не хватить ни времени, ни желания, ни физической возможности, поэтому буду постить маленькими тезисами, которые потом легко можно будет объединить при желании в один трактат. Итак, если следовать по порядку, то начать можно с азов моделирования. Самые распространённые и типичнейшие ошибки: 1. Я люблю нурбсы, сюрфейсы и лофты. Мне очень удобно с ними работать. Дорогие друзья, вы занимаетесь низкополигональным моделированием, поэтому, любая приблизительность в геометрии, как правило оборачиваеться лишним, ни чем не оправданным полигонажем, а все перечисленные мной выше способы моделирования, основаны на апроксимации поверхности алгоритмами, реализующими ряды Безье для кривых второго порядка. В случае низкополигонального моделирования кривые второго порядка оправданы лишь в при использовании сферических или цилиндрических поверхностей. Все остальные поверхности не только возможно, но и необходимо апроксимировать исключительно линейными функциями, которые не будут содержать ошибки дискретизации ряда Безье на кривой. Иными (русскими) словами, изломы поверхности будут находиться исключительно там, где это необходимо и там, где вы мануально установили их своими ловкими ручёнками, а не там где поставит их программа. Поэтому совет: Откажитесь от полуавтоматических способов моделинга, использующих параметрические функции тессиляции на сложных поверхностях. (Прим. второго порядка, поскольку никто не мешает задавать параметрически тессиляцию боксов, циллиндров и прочих примитивов.) Ошибка вторая, логически проистекающая из первой и не только. 2. Мне очень нравяться квадратные полигоны, с ними так прятно работать, всё хорошо видно что где, очень удобно и красиво. А ещё мне нравится регулярная сетка, точки так красиво стоят рядками, просто приятно работать. Дорогие друзья, я хвалю вас за любовь к красивым постореним и чувство гармонии, но низкополигональное моделирование, к сожалению не для вас. Вы наверняка найдёте себе значительно лучшее применение в персонажной анимации, там где количество треугльников имеет значение "постольку-поскольку". Дело в том, что в персонажной анимации есть такой термин MeshSmoothFriendlyObject. Это категория параметрических объектов типа Skin, которая позволяет производить автоматическую тессиляцию уже развешенного на кости скина. Представляете как это удобно при просчётах, когда, например, издалека на камеру бежит человек и по мере его приближения к камере? его детализация параметрически возрастает за счёт тессиляции? Представляете себе анимированный уже объект, который меняет свою геометрию, сбрасывая количество полигонов в разы? Это действительно круто, но как сказано в одном баяне: "Нахрена нам, папаша, весь этот тюнинг в Саратовском зоопарке?" Прошу уважаемую публику поверить наслово, что за 12 лет моей работы с компъютерной графикой, не только низкополигональной, а и высокополигональной тоже, это был единственный случай, когда регулярная сетка была действительно необходима и, мало того, только за её счёт достигалось дальнейшее нормальное функционирование модели. Во всех остальных случаях регулярная сетка и квадратные (прямоугольные) полигоны являлись совершенно ненужной и бестолковой ерундой, а в случае с низкополигональным моделированием олицетворяли собой Вселенское Зло. Почему? Объяснят следующие две ошибки, вытекающие из предыдущих двух. Но для начала наставление: Если вы всё-таки воспользовались параметрическими кративами, то постарайтесь всё же избавиться от регулярной сетки, даже если она вам не мешает. Приучайте себя к культуре моделирования, прежде всего потому, что в большой компании вашу модель будут использовать ещё несколько, а то и несколько десятков человек, и наверняка вам не захочеться, чтобы эти люди разговаривали с вами исключительно матом. Поэтому для начала поимейте представление о культуре моделирования, к которой относится и избавление от паразитной регулярной сетки. 3. Меня бесят видимые грани, жутко неудобно, мешают нормально воспринимать модель. Эта весёлая особенность вытекает из предыдущего пункта. На пару фраз окунусь в историю... Дело в том, что идеология любой программы, реализующей трёхмерную графику основываеться на создании изначально параметрических объектов. И действительно посмотрите можно ли, например, в максе, или в майке создать треугольник? Ответ однозначный - нет нельзя! Почему? Потому что треугольник не являеться параметрическим объектом, у него просто нет переменных, которые мы могли бы использовать в качестве параметров. А вот у четырёхугольника уже таковые найдуться, например, длина и ширина. Поэтому для создания треугольника вам необходимо будет создать какой-нибудь параметрический объект, плоскость или бокс, и только после нескольких преобразований вы сможете получить такой объект, как треугольник. Это не потому что программисты дураки или лентяи, просто такова идеология программирования, необходимо для начала найти величину, которую мы будем изменять, то есть переменную, а уже потом на её основе городить весь огород. Отсюда и все проблемы связанные с нашим случаем. Моделлер видит как строятся прямоугольники и почемуто абстрагируеться от того, что первоосновой всего являеться триангл, то есть треугольник, и продолжает пользоваться параметрическими категориями. На стадии нискополигонального моделирования моделлер просто должен дойти до самого низкого уровня, то есть до каждого треугольника, каждой грани, каждой точки. Поэтому мой совет: Во время работы всегда необходимо делать Edge Visible и визуально и мануально контролировать разворот граней. Есть ещё одна ошибка, которую допускают начинающие моделлеры, она объединяет и накапливает в себе следствия предыдущих ошибок и касается непосредственно уже конечной стадии моделирования, а самое главное самым отвратительным образом влияет на результат. Прежде всего это следствие ошибки 3. 4. Ну и что, что здесь чуточку накосячена геометрия, когда я назначу смусгруппы этого ничего видно не будет. Ошибка 4а. Меня всё время так парит назначать смусгруппы вручную я вообще не понимаю для чего это нужно. С самого начала совет: Прежде чем моделить, убейте к чёртовой матери все смусгруппы своей геометрии и всегда убивайте их, пока не доведёте модель до финального вида! Поймите одну простую вещь: когда вы моделите с установленными по умолчанию программой смусгруппами вы всегда видите на экране не то что у вас есть на самом деле, то есть вы совершенно не имеете никакого представления о том, какая же у вас истинная геометрия, поскольку программа сложила вектора нормалей к поверхностям только одним ей известным и доступным образом, вы в этом не участвовали. Для того чтобы было понятно приведу простейший пример возьмите треугольную пирамиду и назначьте всем её поверхностям одну смусгруппу. Вы можете определить что за геометрический объект получился у вас в итоге? Я сомневаюсь,что визуально это возможно. Только после точно установленной геометрии имеет смысл расставить смусгруппы. Здесь есть одна тонкость, и если не знать её, то ошибка 4б будет совершенно неизбежна. Ошибка 4б Я назначил смусгруппы только на те места где это необходимо, остальные места плоские и делать этого там не имеет смысла. Да конечно, этим самым можно сэкономить время, но только в том случае, когда вы имеете совершенно чёткое представление о том в каком виде будет представлена ваша модель, то есть вы досконально знаеете особенности вашего энжина и вид внутренней записи вашего объекта внутри энжина. Если вы не имеете представления об этом, то лучше не рисковать, это раз, и всегда помнить о культуре моделирования, это два. Не буду течь мыслью по древу, но вкратце существуют такие виды внутренней записи объектов при которых точки не участвующие в общем списке атрибутов смуса (а именно списка координат суммарных нормалей в точках), имеют отдельную запись с отдельной индексацией как дефолтные, а это в свою очередь ведёт в большим объёмам занимаемым геометрией в вертекс буфере, как следствие малой оптимизации объекта и иногда ведёт к переполнениям. А это значит, что если вы возмёте один ваш объект на рендер и он будет выглядеть нормально, два, три, десять, и всё будет хорошо, а на одинадцатом весь ваш энжин просто встанет или будет показывать весьма неожиданный результат или приведёт к ещё более непредсказуемым последствиям. А вам оно надо? Поэтому сделаю вам следующий совет: После того как вы убедились в том, что ни один из треугольников не имеет никаких смусгрупп назначьте всему объекту одну 1-ю, после чего, присваивайте поочерёдно ручками те смусгруппы, которые вам необходимы, последовательно отменяя 1-ю на необходимых треугольниках. Помните о культуре моделирования. На сегодня достаточно, продолжение в следующий раз.

Ау, это я к тому, что может быть я с дуру напишу здесь такие вещи, которые на мой взгляд кажуться очевидными и безобидными, а на самом деле ЕД не очень бы хотелось делать из них паблисити... Я имею в виду именно некоторые технологические моменты... В этом и засор. Как говориться, держи язык за зубами, с зубами и останешься. :-)

Если бы никто не имел возражений, то по просшествии некоторого времени и собравши мысли в кулак, я, возможно, смог бы указать даже на те дизайнерские просчёты и ошибки, на которые не обращают внимание сами разработчики, думая, что так и надо... А, следовательно, и все остальные. :-) Взгляд изнутри, так-сказать, по прошествии времени... Разумееться не призыв к действию, а философские вопросы бытия. Очень уж часто мне приходилось слышать фразу "так исторически сложилось", причём от ЕД не первых и не последних. :-) Не в обиду будет сказано. Но Игорь (молодец) следует мадоксовской стратегии "у нас всё правильно" и, может быть, мои размышления на эту тему могут показаться лишними. Вобщем вкратце я устно уже всё изложил Андрею, не знаю насколько он понял меня и системно проанализировал, но могу и тезисно, решайте сами. :-) Просто иногда бывает забавно смотреть, как другие гуляют по граблям, которые ты смог обойти, но не в моём случае... Мне эти грабли рекошетят вот уже несколько месяцев, приходиться указывать на места их наибольшего скопления. (Элитный смайл означающий кряхтение и потирание поясницы)

А вы, уважаемый, когда-нибудь слышали о таком понятии, как филрэйт? Это почти то же самое, что и фрэймрэйт, но только более точно отражает реальную картину трёхмерного мира, поскольку считает не кадры, а количество пикселей, прорисованных в секунду. И если вы видите на экране объект с альфа-каналом, то на самом деле вы видите не то количество пикселей, которое получаеться простым умножением горизонтали вашего монитора на его вертикаль, а значительно большее. Такая вот несложная арифметика. Насчёт текстур с альфа-каналом я готов поспорить, поскольку есть несколько алгоритмов реализации этого самого альфа-канала. Если вы имели в виду алгоритм реализации альфа-тест, да ещё с нирест-фильтром, да ещё без сортировки треугольников внутри объекта, то, пожалуй, с таким утвержденим можно согласиться. Но! Как только вы начнёте сортировать фасетки, вы убъёте филрэйт в разы, особенно если объект будет отрисовываться на весь экран или на часть экрана. И ещё хуже того, если алгоритм реализации альфа-канала, будет сделан альфа-блендом. Тут уж вапче капут. В реальности надо проводить исследования каждого конкретного движка на предмет отрисовки альфа-канала. Я вот знаю, например, что в ЛО, альфа-канал, реализован по принципу альфа-бленда без сортировки треугольников. А кто его знает будет ли это быстрее, чем обычная геометрия, да ещё и не отягощённая какими-либо дополнительными шейдерами. Может скорость и будет быстрее, но не намного, а отвратность увиденного без внутренних сортировок задавит весь тот незначительный выигрышь в филрэйте. Поэтому не стоит так безапеляционно заявлять, тем более советовать ту или иную часть геометрии делать тем или иным способом, можно пролететь...

Тут, Стас, есть одна загвоздка. В варианте 1, ты как руководитель, как правило, не на все 100 уверен в результате, а, самое главное, ты не сможешь после изготовления одной модели грамотно экстраполировать сроки изготовления другой. У меня была масса таких "клиентов". Был случай, когда человек, окончивший Серова, великолепно рисовал и, как ты говоришь, "чувствовал форму", и как-то моделил. Но всё по наитью. В реальности он не мог понять даже, что такое элементарная проекция, хотя я, совершенно честно пытался объяснить ему, глядя в глаза, на примере простого спичечного коробка. Бесполезно. Не даром, нас художников, когда учат, не стараються научить тому, как сделать, чтобы "было похоже", а напротив стараються втемяшить серую правду о построениях правильных геометрических конструкций. В итоге с человеком просто пришлось рассататься. Другие товарищи, более продвинутые в большинстве своём привыкнув "выминать", как ты сказал, одну конструкцию, напрочь срезаються на другой. Типичный пример: Ты наверняка знаешь, что все трёхмерщики, впервые поступив на работу, начинают с "домиков", ну или других кубообразных конструкций. Затем плавно переходят к технике, в вашем случае сначала простой, как ракеты, затем более сложной, такой, как броневики и в конце-концов выходят на свой высший уровень - вертолёты и самолёты. Так вот некоторые, "особо чуствующие форму", так и остаються моделить домики и ракеты. Не говоря уже о том, что на моделях людей срезаеться 90% трёхмерщиков. Так что не у всякого, у кого ручки заточены для того чтобы "мять Венеру за сиськи", получаеться потом сделать что-нибудь другое. Универсалов я встечаю чрезвычайно редко и, как правило, они имеют помимо художественного ещё и верхнее техническое... А таких "самородков", коих ты имел в виду, может и встречал, но ещё реже. Кроме того, у таких людей абсолютно всегда отсутствует инновационная мотивация... Они всё привыкли делать "на коленке", оттачивая своё мастерство, а потом очень долго приспосабливаються к внезапно изменившейся ситуации. Производительность труда в таких случаях явно не на высоте. Я уже не говорю о таком понятии, как "культура моделирования". Те же 90% причём весьма неплохих моделлеров обычно напрочь подвисают на регулярных сетках и на полном отсутствии мануального контроля за гранями. При этом все они, как один, никогда не слышали понятия "матрица" и "вектор", что характерно. А те самые "самородки", которых ты имел в виду, вообще не имеют никакого понятия о рациональной топологии. Кроме того, они считают, что моделят единственно правильными способами, потому, что "им так удобнее". В итоге, я расстаюсь с такими людьми, поскольку мне не нужны их модели, а им не понять почему именно. Так что, Кулибины от 3Д - это миф, распространяемый тобой в корыстных целях. :-)

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

Не советую заморачиваться с этим. Могут возникнуть серьёзные проблемы, связанные с пропаданием элементов активной брони. Вы можете предположить как будет происходить процесс? Я думаю нет... Вам нужно будет прописывать скрипт, подразумевающий ликвидацию каждого элемента. С предыдущим оратором категорически не согласен, элементы не могут повреждать друг друга - это бред, поскольку взрыв направленный, причём направленный в сторону от брони. Он не может сдетонировать соседние элементы, иначе представьте себе, что сдетонировала вся активная оболочка. Насчёт того, что одновременно могут сработать два активных элемента разом, вполне может быть, но вероятность такого чрезвычайно мала.

Там скорее звуковой эффект, нежели визуальный. Хлопок чрезвычайно громкий, а вот дыма практически не видно.:smartass: Лёгкий-лёгкий такой дымок...

Не знал в какой топик это засунуть, так что сорьки и не зачтите за злобный флуд. Мне очень понравилось. http://forums.airbase.ru/index.php/topic,36460.0.html

Эх народ, сказал бы я вам... Мне бы столько времени, сколько вы его делали... И на всё это время куда-нибудь на Кипр. Вот представьте теперь себе, что делаете вы этот танк за деньги и вам семью кормить надо... Выжила бы ваша семья или случись чего нидайбох... Или танк бы этот выглядел иначе? Отличная модель!!! Нещастье только в одном - это не серийный танк, не серийный в смысле геймдева... На текстурку бы ещё лайтмапчик наложить. У вас есть дублирующиеся элементы геометрии на текстурных координатах? Ну то есть у каждого кубика отдельный участок текстуры или они дублируються? Я бы мог посчитать вам лайтмапу, выглядело бы ещё более натурально.

Да в таком случае вообще вполне достаточно статических болванов, если их только в прицел разглядывать. Интересно конечно, но любая игра, чтобы продаться, должна иметь законченную концепцию и представлять из себя не просто запрограммированную кем-то "программу", а законченный коммерческий "программный продукт". Когда "планов громадьё", этот программный продукт в итоге вылезает чудовищно недоношенным, если вылезает. Просто посмотрите на эту часть с точки зрения здравого смысла... Вы много видели связанных групповых действий даже в тех играх, которые по своему жанру обязаны таковые предоставлять? Вы видели, как в каком-нибудь шутере, боты вдруг начинают подставлять друг другу плечи, дабы забраться, например, на верхний этаж дома через окно? Вы видели, как выглядят в шутерах смолёты и прочая техника, которая появляеться в пределах поля зрения плейера на несколько секунд и исчезает? Я просто рекомендую участникам дискуссии обратиться к здравому смыслу и всего лишь... Подумать над тем, сколько усилий будет затрачено на изготовление подобного расчёта и, главное, подумать будут ли эти усилия оправданы... Нужны ли подобные расчёты в случае, если мы видим их доли секунды с расстояния 300-500 м в размере несколько пикселей на экране, прежде, чем закидать НУРСиками? Я по долгу службы в данный момент связан со смежной ED отраслью, а именно делаю вертолётные симуляторы, не игровые, а именно самые что-нинаесть обычные симуляторы. Так вот у нас есть такая категория, которая носит название "микроландшафт". Это высокая трава, кусты, камни больших и средних размеров, в общем мелочь разрешением от нескольких сантиметров до нескольких десятков сантиметров. В этом есть жёсткая необходимость, поскольку микроланжшафт помогает выбирать будущему пилоту вертолёта правильную площадку для посадки. Ресурсов эта хрень жрёт до одури... Для того, чтобы её сделать было потрачено немало усилий, но она нужна и это оправдано. А вот танки и бронемашины, для стрельбы по ним в десятки раз проще и уродливее, чем в ЛО, потому как видим мы их на экране максимальными угловыми размерами в несколько сантиметров... И это тоже оправдано... Нет, есть конечно люди, которым интересно сделать из спичек Эйфелеву башню, но это НЕ КОММЕРЧЕСКИЙ ПРОЕКТ! :-)

Полностью согласен с Бубликом. Выбор позиции и размещение на ней - это ещё полдела, а как будем реализовывать методы противодействия инструментальной разведке противника, звуковой и оптической? Как будем вести собственную артиллерийскую разведку и так далее? Тут одним оживляжем дело не обойдёться...

Господа, вы маниаки!!! Вы представили себе работу аниматоров, вы представили себе какое количество времени это займёт, вы представили себе сколько это может стоить? А теперь представьте себе какую разветвлённую систему скриптования придёться написать, если анимацию повесить на один скелет... а теперь на два... а теперь на 10... А теперь представьте, что вы работаете не со скелетом а с буратиной, как в требуемом случае... Нет не вопрос, сделать можно всё, только найдёться ли та Золушка, которая решиться на это? Может дешевле ещё полдюжины самоходок забомбить покачественнее? Продолжу свою мыслю таким образом, чтобы было понятно... Вы кины смотрите? Типа там Троя, или Александр, или Гладиатор, или Храброе сердце? Вы в курсе как там массовки делались? Даже в Bravehart, где статистов было до одури их плодили монтажём и действительно грандиозные толпы были в кадре несколько десятых долей секунды, чтобы зритель не мог рассмотреть как их ловко откопипастили... Бюджетов этих фильмов никто не помнит? А сколько суммарно по времени занимает такой вот "оживляж"... Советую пересмотреть и на секундомере отщёлкать, а затем соотнести эти сцены с общей длительностью фильма и при этом постоянно держать в голове, что именно вот на эти 1,5-2 минуты кино и ушли 99% того самого бабла... Надеюсь доступно изложил свою мысль.

Я в геймдеве 12 лет отработал и сейчас в смежной области промышляю. Поверь, насмотрелся уже на такие игры и сам наделался по полной... Есть технологическое демо, а есть конечный продукт. Ты уверен, что именно это войдёт в релиз, если он действительно будет? А судя по датам скриншотов, эта игра имеет все шансы устареть ещё до выхода. Это совершенно обычные и оправданные сомнения, поскольку в моей практике выходила каждая 4-я игра в лучшем случае. И при этом, всё лёчшее, что в ней было, как правило оставалось пустой "наработкой на будущее", которая в итоге так никуда и не входила. И, поверь, подобное мнение не писимзм, а реальность.

Проблема, не решённая пока до конца ни в одной из игр. Вот по сию пору. Поэтому разработчики предпочитают отказываться от артиллерии с открытыми расчётами. Слишком много анимации, это ещё пол-беды. Беда в том, что подобную анимацию не зациклить в конечном временном интервале. Ну то есть сам момент стрельбы, всегда пожалуйста и есть даже игры, (сейчас навскидку не вспомню, в каких то аддонах Medal of Honor, помоему) где этот момент реализован. Но вот так, чтобы весь процесс, с установкой, наводкой и прочим...

Я скажу тебе даже больше... На современных карточках, вызов порядка 3000-5000 треугольников (а при том, что пиксельные шейдеры сейчас фаршируються с такой же скоростью, как и обычная диффузная геометрия), ни чем по времени не будет отличаться от вызова 1-го единственного треугольника. Здесь будет важен вопрос о количестве объектов с отличной геометрией и в первом приближении один объект размером 5000 треугольников будет отрисовываться в 5000 раз быстрее, чем 5000 объектов размером в 1 треугольник, но при этом совершенно разных (с неповторяемой геометрией или своими уникальными шейдерами). Понятно, что на практике всё несколько иначе, но в первом приближении это верно. Именно поэтому на отдельные сущности объектов, такие как танк или самолёт, разработчики пытаються навесить одну единственную текстуру и присвоить минимум шейдеров. Ты правильно понял мою мысль относительно изменяющейся геометрии... Я как раз и имел в виду случай вертексной анимации. Например, движение персонажа, реализованное скином, или в нашем случае, простейший вариант - изгиб лопастей винта вертолёта... Мы имеем сложный пересчёт матрицы объекта на каждом кадре и здесь даже мощная аппаратура будет гнуться, если не следить за полигонажем. Поэтому и понятно, что в 100 случаях из 100 мы имеем на анимированных персонажах нормалмапы, которые заменим геометрией ещё не скоро. to t116 Насчёт детализации вопрос в адрес ED Team. У меня есть сведения, что нелетабельные модели могут быть в районе 50000 и текстурами размером до 30 мб. Так что, у меня такое мнение, что такая детализация возможно даже ещё не достаточная. :-)

to Dronas Насчёт уверений в сторону "но не остаёться!" отправлю в адрес разработчиков ЛО. Спрашивайте у них... Мне кажеться, что "но не остаёться!" будет только тогда, когда ED Team и другие разработчики в области геймдева перестанут выдавать моделлерам требования по полигонажу, а вы во время моделинга перестанете каждые полчаса во время работы заглядывать в максовый Summary Info и выводить в майке Poly Count. Так что это, скорее всего, из области фантастики. А вот слово "даже" стоит там потому, что вы никогда не будете засовывать в реалтаймовские движки хайпольные модели, а будете всего лишь апроксимировать их на низкополигональные обрубки при помощи нормал- и прожект- мапов. Железо растёт в другую сторону, факт... А уважаемому t116 не надо так кипятиться, помоему, по поводу его знаний и умений, я не высказывался... Мой прежний пост был адресован Стасу, но так-сказать не в привате, а паблисити, так что не надо цепляться. Если бы вы знали, как это делаеться, то не задавали бы глупых вопросов, это раз. В моём посте есть два вполне конкретных пути решения вашей проблемы. А вежливые люди, помимо своего недовольства тем, что другие уделяют им своё внимание, иногда ещё и благодарят тех, кто тратит на них своё время, это два. to Dmut Нет, ты ошибаешься, моих там как раз мизер, они позжее будут, в основном, там, где ты указал мои "братья меньшие" вывешиваються. :-)

Хе-хе... Проблема более масштабна, чем кажеться изначально. Я бы особо выделил несколько несколько аспектов: - Согласитесь, что начиная изучать математику, вы для начала сталкиваетесь с азами и пока не заучиваете наизусть таблицу умножения, не прикасаетесь не то что к дифференциальным, а даже и обычным уравнениям линейной алгебры. Я понятно излагаю? Так какого, спрашиваеться, органа, любые книги по моделингу, в том числе и весьма уважаемого мною Миши Марова, начинаются с описания моделинга всякими разнообразными нурбсами, сюрфасами и прочими лофтами с той лишь только целью, чтобы сбить с толку честных LowPoly модельеров? - Я объясню почему это происходит... Дело в том, что некие вумные программисты не сумели реализовать доступных методов быстрого моделинга примитивов и создали лишь те методы, которые наиболее просто описывались известными математическими алгоритмами. Ну здесь всё понятно - непрерывные ряды Фурье и Безье реализовывать значительно проще, чем простейшие линейные последовательности. А затем этим программистам осталось только втюхать всем остальным, насколько всё это круто и как быстро всё это делаеться, и как всё это позарез необходимо господам моделлерам. - Реальность же заключаеться в том, что: 1. Алгоритмов оптимизации нормальных до сих пор не создано, поскольку до сих пор нет интеллектуальных систем обработки даже простейших линейных последовательностей. 2. Высокополигональный моделинг оказался необходим только в одной сверхспециализированной области - персонажной анимации. А в том, что касаеться игровых технологий, то, как всегда, был и остаётся большим злом, даже после появления таких категорий, как карты нормалей. 3. Количество моделлеров, способных узреть корень низкополигонального моделирования, в итоге стремится к 0. - Не поймёт человек сущностей сурфейсов, сабдивижнсурфейсов, нурбсов, сабсурфейслайтскатерингов, нормалмапов, прожектмапов и прочей галиматьи, пока не научиться строить треугольников. Господа, совет начинающим - не пользуйтесь модификаторами, если вы не в состоянии с вероятностью близкой к 1 в своей голове предсказать результат. Начните с того, чтобы попробовать отстроить какой-нибудь примитив из обычного бокса вручную, пользуясь только внутренними функциями модификаторов EditableMesh и EditablePoly. И тогда вы с большим удовольствием будете использовать все безграничные возможности вашего программного обеспечения. Заверяю, поскольку в других программах, позволяющих творить трёхмерку, таких, как майка, ксюха, люфтваффа, нет и сотой доли тех модификаторов, которые присутствуют в максе, но тем не менее люди, работающие там, как-то без них могут обходиться...

Проблемы с булем, как правило, возникают не от самого буля, а от кривых ручёнок булиньщиков. Надо просто понять его идеалогию. А что вы собственно хотели? Вы занимаетесь LowPoly моделингом и не в состоянии мануально контролировать каждый треугольник? В качестве практического совета могу порекомендовать пользоваться 8-кой, ну или найти к 7-ке плуг под названием PowerBoolean...

Гы-ы-ы-ы... :megalol: Как говаривал один из моих преподов в институте: "А вот это уже вопрос непосредственно к программисту." Ну или ещё есть крылатая фраза, употреблявшаяся в ВУЗах повсеместно: "Учите матчасть." Как же вы мужчина расчитывали реализовать алгоритм, не зная инструментарий? :lol: Ручками надо, ручками, забудте слова лоХФтенГ, еХтРуДенГ и тем более буЛИнеНГ, не ругайтесь в приличном обчестве. А точки двигать придёться полюбому, иначе не получиться ничего, и ещё много чего придёться монстрячить.

Люди, добрыЕ, сами мы не месТныЕ... Поможите кто чем может. Нужна кинематическая схема механизма вывода Р-33 на МиГ-31, да и фоток бы неплохо подкинуть по-детальнее, типа "вид снизу" с ракетами и без. Владельцы фотографий 57-го борта могут не беспокоиться. Был бы также очень признателен за изображение внешнего вида ГШ-6-23/М в БОЕВОМ незачехлённом положении. Идеальным было бы изображение в момент стрельбы. Всем заранее признателен за сСылки в интернете, присланные по почте ДВД, кассеты, книги, фотоальбомы. :horseback ======================== Уважаемый, следите за речью!