Вопрос дискуссионный, как я это называю © :rolleyes: Это вот МОДный "Бисмарк", у которого "всего лишь" уменьшено значение координат по оси Z для мешей Hull* ...


Очевидно, что эффект тот же самый, который наблюдается и у камрада tvister'а после экспорта кораблика в формат ИЛа. Т. о., можно предположить, что "заново созданный аддон-экспортер" не вполне корректно преобразует координаты мешей в процессе экспорта :DONT_KNOW:
Ну, я про [_ROOT_] вспомнил потому только лишь, что он является "родительским" (Parent) для всех основных мешей модели. Вот и подумал, что, может, что-то не так с его координатами :ups: Однако - как оказалось - проблема действительно не в этом ...

Проверить корректность координат просто. Надо модельку загрузить в мою программку и всё сразу будет видно. :)

А теперь, откинув лирику, включим логику.

Итак, у нас есть кильватерный след, который должен появляться на поверхности воды. А кильватерный след, в общем случае, совпадает с осадкой судна. ;) Таким образом, с точки зрения различных оптимизаций, нам для корректного отображения нет нужды выдумывать лишние сущности. Одним хуком мы решаем сразу две проблемы - автоматически располагаем кильватерный след на поверхности и устанавливаем нужную осадку. В противном случае у нас появляются с ложности как на этапе создания модели, так и на этапе её программирования. Что противоречит общему правилу, "чем меньше сущностей, тем надёжнее".

А вообще это легко проверяется. Взять, и двинуть хуки вверх/вниз и посмотреть что получилось. :) У меня модов нет и сам это сделать не могу, но уверен в своей правоте.

Кстати, у кораблей может быть ещё один хук, _Tailer. Располагается на носу, рядом/на месте _Nose. Вероятно, что это один из вариантов буруна. Обычно присутствует у быстроходных малогабаритных моделей.

Вот, я картинку сделал, добавил у себя показ уровня воды, привязав его к хуку _Centre:

http://itmages.ru/image/view/3942525/df0072d7

Посмотрел, на всех модельках корабликов положение этого хука совпадает с глубиной осадки.

Интересно, что будет, если этот хук наклонить... :) :) :)

Тип Светлана
 

Спасибо всем откликнувшимся, подвигал центральную точку и все стало на место.

Еще б оно в приложении к ИЛу всегда срабатывало :rolleyes:
Беда в том, что в ИЛе - зачастую - работают не общие правила, а свои собственные :DONT_KNOW:
Да ничего, собственно, не получается :ups: Вот, все тот же МОДный "Бисмарк" с дефолтным - так скажем - расположением хуков ...

А это - с измененной координатой по оси Z ...

Что называется, найдите десять отличий ;)
Естественно. Но это ведь не означает, что его положение ее (осадку) и определяет :rolleyes:

Упс ... а у нас тут така-а-ая дискуссия развернулась :rolleyes: Что ж, хорошо есть, и хорошо весьма © :ok: Успехов в дальнейшем :good:

Вот тут должен сделать важное предупреждение! :)

В матрице трансформаций, коими и являются по факту хуки, нельзя просто так изменять координаты "по оси...". Почему? Потому, что это матрица трансформации.

Для понимания сути.

Разворот и перенос некоторой точки в пространстве - операция не коммутативная. От порядка выполнения операций зависит то, где точка в конечном итоге окажется.

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

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

По этому, когда мы говорим о "сдвиге по оси" обязательно требуется уточнение относительно каких координат мы сдвиг осуществляем. Ибо направление мировых и локальных осей запросто может не совпадать. И в этом случае, сдвигая, например по Z в локальных координатах, в глобальных мы можем двигаться вдоль другой оси, или вообще, под углом к осям.

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

Хуки надо двигать не в локальных координатах, а в модельных (мировых). Только тогда они сдвинутся правильно. Я на картинках, кстати, вижу глюк с положением хуков. Кильваторный след вылазит впереди носа и повёрнут относительно продольной оси модели на заметный угол. :) И похоже, что эти хуки тоже ставили наугад. :)

Но хоть какой-то (видимый) эффект от изменения координат хуков (пускай даже и некорректного) должен был бы быть?! Или не? :I'm_thinking:
Ндык :DONT_KNOW:

Должен, естественно. :) Но без самой модели предсказать, как оно будет, сложно. :) Это ведь сплошное умножение матрицы на матрицу. :)

Я скоро допилю у себя кручение/перемещение хуков, надеюсь с ними станет по проще. Времени бы ещё свободного где побольше найти. :)

Во-о-от ... а его ведь не видно! Ну, т. е. изменение координат хуков никак не сказалось на осадке корабля (ради чего, собственно, эксперимент и затевался) :DONT_KNOW:
Спасибо вам за ваши труды :thx:
Ндык ... время - деньги, как говорится, а деньги - они или начинают заканчиваться или заканчивают начинаться, и никак иначе :DONT_KNOW: Так и со временем :ups:

Хе-хе! :) Ну я же говорил, Мf = Mh * Mm0 * (Mm1) * ... * (Mmn) . ;) И как оно там двинется после этого умножения совсем не очевидно.

Давайте я ещё раз попробую объяснить этот момент. Он важен для правильной сборки моделей и понимание его позволит избежать ненужных ошибок и переделок. С рисунками было бы проще, но у меня с этим, увы, туго, не умею разными редакторами нормально пользоваться.

Итак. Допустим, что у нас есть первый меш, направление осей которого совпадает с направлением мировых осей. Теперь мы к нему присоединяем второй. Направление осей у второго тоже совпадает с мировыми. Пусть второй меш присоединён к первому со сдвигом, допустим - по Х на 10. Представили картинку? А теперь - фокус! :)

Мы поворачиваем первый меш на 90 градусов вокруг Y. Представили? Отлично! Что у нас случилось с направлениями осей? Локальные направления не изменились, но относительно мировых X и Y поменялись местами! И теперь, для того, чтобы в мировых сдвинуть второй меш по Х в локальных его надо двигать по Y. :)

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

Ещё один пример, хорошо это иллюстрирующий. Самолёт и, допустим, его руль направления. Когда РН стоит прямо вектор направления направлен вдоль оси самолёта. Мы отклоняем РН и вектор направления меняется на угол в сторону, противоположную отклонению РН. В мировых это происходит вокруг Z (ось направления Y), вдоль Х. А теперь мы прокручиваем модель вокруг Y (делаем бочку). Как меняется вектор направления при этом? Он у нас начинает описывать круг в случае неподвижности модели, либо спираль, если мы движемся. У нас направления осей для РН в мировых координатах изменяются, оставаясь локально неподвижными.

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

- мы имеем определённое соглашение по физическому назначению осей и строго его придерживаемся (уходим от XYZ, и, например используем yaw, pitch и roll чтоб не путаться в ситуациях смен направлений осей в мировых координатах)
- мы имеем определённое соглашение по тому, как соединяются отдельные части моделей и строго его придерживаемся

Ну и, естественно, матрицы перемножаем в правильном порядке.

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

Очень знакомое чувство. И вовсе не оффтоп, весьма познавательно и полезно.

Тип Светлана
 

Стараюсь... Как то странно в Иле рассчитываются углы обстрела. Поставил на нос "Крыма" спарку Минизини, стреляет куда угодно но только не в сторону противника. :(

Дискутировали ведь уже на эту тему ... и не раз :DONT_KNOW: Так что придется - по-видимому - использовать пресловутый метод научного (в)тыка :I'm_thinking: Ну или - быть может - камрад NB79 подскажет что-то дельное, исходя из своих знаний (немалых, надо заметить, и вполне себе "академических", я бы даже сказал) и опыта :ups:

Спасибо за доброе слово, но в этот вопрос я не вникал, не знаю, как эти углы в игре считаются.

Вообще, по тому, что видно в модельках, повороты заточены под локальную ось Y, если я чего не путаю. Это, конечно, нуждается в проверке, но возможно башни и стволы просто собраны не правильно. Т.е., делая башню нужно её строить так, чтоб она осью вращения имела Y. Аналогично и со стволами. И потом, когда аттачим детали в единую модель собираем их так, чтоб они ориентировались правильно. Тогда у нас всё должно крутиццо как надо. Но повторю ещё раз, тему корабликов не изучал и как правильно для них всё строить не знаю.

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

- ось X: -180 .. +180
- ось Y: -90 0 -90 .. +90 0 +90
- ось Z: -180 .. +180

Вот тут про ось Y стоит отдельно и сказать. Угол для Y через arccos получаем (на самом деле в алгоритмах немного по другому, но в матрице лежит cos угла в радианах). И он у нас для углов 0 - -180 меняется в диапазоне от -90 до -90, сначала возрастая до нуля, а потом уменьшаясь до -90. И аналогично для 0 - 180, только со знаком +. Как результат, может получится так, что оси при декомпозиции могут изменить знак! Ствол будет в ту же точку указывать, но начальные углы будут другие, не оригинальные! И потом, поворачивая объект, мы можем получить неожиданные эффекты. Это, помниццо, с американскими истребителями (забыл сейчас с какими) такой глюк случился при пересечении экватора, когда их к верх ногами опрокидывало, из-за такой баги в софте бортовом. :) Основная неприятность, связанная с декомпозицией, заключается в том, что чаще всего всё работает как надо, но при определённом стечении обстоятельств всё внезапно работать как надо перестаёт. Это стечение обстоятельств определяется совокупностью начальных углов.

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

Нда-а-а... Ничего, разберемся, другого пути у нас нет!
А что, тут? (требует какой то пароль).

:thx:
По одной из версий, это был F-15, по другой - F-16, причем если с последним это "случилось" только лишь в процессе отладки ПО, на симуляторе, то с "Орлом" - инрил ... если повар нам не врет © :rolleyes:
Ох ... mea culpa, mea maxima culpa :DONT_KNOW: Check your PM, pls. :ups:

Да, в принципе, с точки зрения проблемы разницы нет, симулятор это, или железка. :) Симулятор - та же кабина и весь бортовой вычислительный комплекс рядом в шкафу. :) Единственная существенная разница - на симуляторе штаны не испачкаешь когда с таким столкнёшься. :)

а как в блендере группы сглаживания расставляются? ...

Очень интересный вопрос, предмет многочисленных споров и рассуждений, если судить по интернету.
Если надо сгладить геометрию, то используем Smooth Vertex с Т-панели в Edit Mode, выделив необходимую группу вертексов.Если просто сгладить тени , использовать на той же панели Smooth. Модификатор Subdivision Surface работает на весь объект, но его действие на группу вертексов можно нейтрализовать при помощи Schift+E.

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

т.е. в максе это специальная панелька ... без влияния на сам меш или вертексы ...

Да есть такая проблема, пока не знаю как решить.

я знаю ... но тебе мой вариант не понравиться)))

Subdivision Surface для Ила только в хай поли мечтах)):D
Сам моделил в блендере, когда начинал. Со временем понял, что некоторые вещи блендер не даст сделать. Попробовал в максе. С тех пор блендер не открываю, хотя он мне больше понятен т.к. сделан для пользователей, а не для "инженеров"%). Если есть желание, можем связаться в скайпе, решить проблему сглаживания у вас в блендере.

:)

можем связаться в скайпе, решить проблему сглаживания у вас в блендере.

Спасибо за предложение, но для меня, пока что, скайп технически не возможен...

Как так? :eek:

Очень просто. Кочевой образ жизни, старенький слабый ноут, отсутствие камеры, очень медленный интернет, который "иногда бывает."

Камера не нужна. Только звук. Хотя, если инет такой, то да, толку нет. Как вариант можете скинуть мне, я поправлю сглаживание и вышлю вам обратно. Разумеется с видео пояснением. :law::)

Тип Светлана
 

Спасибо за предложение. :thx:Сейчас ситуация такова, модель "Красного Крыма" будет переделываться. Еще до установки вооружения я знал, что эта модель не совершенна. Не зная азов строительства создал модель, по оси Y,поворачивая модель по оси Z получаем проблемы с артой и хуками вообще. А как повернуть модель на нужный угол, чтобы Блендер этого не заметил?:I'm_thinking: Можно значительно уменьшить количество треугольников. Сейчас, строя Эльпидифор, все округлые площади закрываются квадратными "плашками", стараюсь максимально использовать альфу. Крыму требуется капитальная "пластическая" операция, которой я займусь после Эльпидифора. Проблему неправильного затенения полигонов в свое время изучал пользователь SAS Karla. Его"перу" принадлежит замечательная работа USS BON HOMME RICHARDhttp://www.sas1946.com/main/index.ph...c,46424.0.html В своих проектах он использовал старые, до 2.5 версии Блендера. Неправильное затенение, или проблемы с группами сглаживания это не проблемы Блендера, а баги экспортера http://www.sas1946.com/main/index.ph...c,44899.0.html
К сожалению я так и не понял, как они решили эту проблему. В общем планирую сначала отрихтовать 3д модель, потом буду править безобразия связанные с экспортом. Может быть и это не правильный путь, возможно что то нужно менять уже на этапе строительства? Не знаю, мало опыта. Работаю методом проб и ошибок, в темноте на ощупь, долго но точно. Всем мира, прорвемся...

Как вариант, применить ему вращение и скейл. В Максе это ресет икс форм. В блендере, в режиме object mode как показано на скриншоте.

Треугольников? Лучше не спешить... Можете сетку показать? Урезать всегда можно, но без видимой модели сказать что-то невозможно. Вообще экспорт из блендера затея так-себе. :)9 макс не кушает много ресурсов. И на этапе строительства и при экспорте проблем возникнуть не должно. ;)

Итак, первая часть "Битва за Полигоны" им. Красного Крыма. :D Посмотрев, что я там наговорил, хотелось удалить. Но, не решился. Есть и мои недочёты, исправлю. Буду стараться меньше воды и больше по делу говорить. Даже пытался не заснуть от своих "рассуждений".:( Будут ещё правки "кормы". Только после записи увидел недочёты, а уже спать пора. Ещё раз сори за тихий микрофон, громко говорить не могу. Будем считать, что это вводное видео. Продолжение следует... (если конечно нужно...:DONT_KNOW:)

с 18.55 минуты можно удалить ребро и больше вообще не трогать это место. Дальше нарезка была лишней. Чёт я сам напридумывал с сеткой. :eek::D

чувствую оскар не за горами))

за некоторые моменты по рукам меня надо. Вообще офигел. :law: Исправлю)

Тип Светлана
 

Посмотрел Ваш урок. Спасибо огромнейшее!:thx: "Красный Крым", это "первый блин" который полностью подтверждает известную поговорку.:) Практически все замечания справедливы, постараюсь их исправить. А вопросы к блендеру, появились еще на этапе экспорта. Тем не менее, блендер пока не бросаю, очень много ошибок на начальном этапе допустил просто по не знанию. Теперь потихоньку буду править.
ЕЩЁ КАК НУЖНО!!! Ещё раз спасибо:beer:,все советы и рекомендации для меня важны, с нетерпением жду продолжения...

хорошее видео

Мануалом я бы не назвал) Так, мысли вслух. :D Раз такая пьянка, буду делать дальше. :ok:

Всем мира. Немного не понял как создается (прописывается в .msh) модель столкновений. Что это за значения [CoNeiCnt_b0p0] [CoNei_b0p0] и за что они отвечают? Подскажите кто знает плз.

Точных подробностей не знаю, но это вроде "дерево", в "ветках" которого прописаны "соседи". Типа, есть полигон и находятся полигоны с которыми у него есть общая грань. Они для него соседями и являются. Это, типа, для быстрого нахождения точки столкновения/пересечения объектов.

Выглядит очень похоже на это, но это моё предположение, не разбирался с этим.