Новые корабли. Сделай сам.

[deSAD]

Originally Posted by NB79

У нас есть следующие хуки на корабликах, определяющие осадку и эффекты на воде:

_Nose - бурун на носу
_Centre, _Left, _Right - место появления и угол расширения следа
_Prop - след от винтов

Судя по тому, что я вижу в моделях кораблей, _Centre, по мимо всего прочего, определяет и осадку. Возможно, что требуется обязательно выводить _Centre, _Left и _Right на один уровень.

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

Очевидно, что эффект тот же самый, который наблюдается и у камрада tvister'а после экспорта кораблика в формат ИЛа. Т. о., можно предположить, что "заново созданный аддон-экспортер" не вполне корректно преобразует координаты мешей в процессе экспорта

Originally Posted by NB79

А в [ROOT], как видно из названий, VisibilitySphere и CollisionObject определяют сферу видимости и объект коллизии для модели в целом.

Ну, я про [_ROOT_] вспомнил потому только лишь, что он является "родительским" (Parent) для всех основных мешей модели. Вот и подумал, что, может, что-то не так с его координатами Однако - как оказалось - проблема действительно не в этом ...

[NB79]

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

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

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

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

[NB79]

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

[NB79]

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

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

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

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

[tvister]

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

[deSAD]

Originally Posted by NB79

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

Еще б оно в приложении к ИЛу всегда срабатывало

Originally Posted by NB79

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

Беда в том, что в ИЛе - зачастую - работают не общие правила, а свои собственные

Originally Posted by NB79

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

Да ничего, собственно, не получается Вот, все тот же МОДный "Бисмарк" с дефолтным - так скажем - расположением хуков ...

[Hooks]
Vapor <BASE>
Vapor1 <BASE>
_Nose <BASE>
_Centre <BASE>
_Left <BASE>
_Right <BASE>
_Prop <BASE>

[HookLoc]
2.08362E-14 1.192E-07 1 1 -1.152E-07 2.98E-08 1.45E-07 1 -1.192E-07 -3.17663E-05 -5.55 17.17
2.08362E-14 1.192E-07 1 1 -1.152E-07 2.98E-08 1.45E-07 1 -1.192E-07 -3.17663E-05 21.21 17.17
-1.748E-07 -1 0 1 -1.748E-07 0 0 0 1 -5.74596E-05 -123.932 -2.38917
2.94E-07 1 0 -1 2.94E-07 0 0 0 1 -4.85879E-05 -98.3389 -2.38917
1 -3.4338E-07 0 3.4338E-07 1 0 0 0 1 4.73895 -98.3393 -2.38917
-1 4.2768E-07 0 -4.2768E-07 -1 0 0 0 1 -4.73905 -98.3393 -2.38917
2.94E-07 1 0 -1 2.94E-07 0 0 0 1 2.4107E-06 115.637 -2.38916

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

[Hooks]
Vapor <BASE>
Vapor1 <BASE>
_Nose <BASE>
_Centre <BASE>
_Left <BASE>
_Right <BASE>
_Prop <BASE>

[HookLoc]
2.08362E-14 1.192E-07 1 1 -1.152E-07 2.98E-08 1.45E-07 1 -1.192E-07 -3.17663E-05 -5.55 17.17
2.08362E-14 1.192E-07 1 1 -1.152E-07 2.98E-08 1.45E-07 1 -1.192E-07 -3.17663E-05 21.21 17.17
-1.748E-07 -1 0 1 -1.748E-07 0 0 0 1 -5.74596E-05 -123.932 -22.38917
2.94E-07 1 0 -1 2.94E-07 0 0 0 1 -4.85879E-05 -98.3389 -22.38917
1 -3.4338E-07 0 3.4338E-07 1 0 0 0 1 4.73895 -98.3393 -22.38917
-1 4.2768E-07 0 -4.2768E-07 -1 0 0 0 1 -4.73905 -98.3393 -22.38917
2.94E-07 1 0 -1 2.94E-07 0 0 0 1 2.4107E-06 115.637 -22.38916

Что называется, найдите десять отличий

Originally Posted by NB79

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

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

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

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

[deSAD]

Originally Posted by tvister

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

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

[NB79]

Originally Posted by deSAD

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

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

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

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

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

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

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

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

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

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

[deSAD]

Originally Posted by NB79

... Хуки надо двигать не в локальных координатах, а в модельных (мировых). Только тогда они сдвинутся правильно.

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

Originally Posted by NB79

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

Ндык

Originally Posted by asheshouse

_Centre, _left and ,_right entries interact to create the wake.
I have still not completely figured out how these work but still rely on some trial and error.

_Centre y coord sets spacing of left and right wake
_left _right x coord sets width and also affects centre wake.

[NB79]

Originally Posted by deSAD

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

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

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

[deSAD]

Originally Posted by NB79

Должен, естественно.

Во-о-от ... а его ведь не видно! Ну, т. е. изменение координат хуков никак не сказалось на осадке корабля (ради чего, собственно, эксперимент и затевался)

Originally Posted by NB79

Я скоро допилю у себя кручение/перемещение хуков, надеюсь с ними станет по проще.

Спасибо вам за ваши труды

Originally Posted by NB79

Времени бы ещё свободного где побольше найти.

Ндык ... время - деньги, как говорится, а деньги - они или начинают заканчиваться или заканчивают начинаться, и никак иначе Так и со временем

[NB79]

Originally Posted by deSAD

Во-о-от ... а его ведь не видно! Ну, т. е. изменение координат хуков никак не сказалось на осадке корабля (ради чего, собственно, эксперимент и затевался)

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

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

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

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

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

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

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

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

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

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

[tvister]

Originally Posted by NB79

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

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

[tvister]

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

[deSAD]

Originally Posted by tvister

... Поставил на нос "Крыма" спарку Минизини, стреляет куда угодно но только не в сторону противника.

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

[NB79]

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

Вообще, по тому, что видно в модельках, повороты заточены под локальную ось 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, только со знаком +. Как результат, может получится так, что оси при декомпозиции могут изменить знак! Ствол будет в ту же точку указывать, но начальные углы будут другие, не оригинальные! И потом, поворачивая объект, мы можем получить неожиданные эффекты. Это, помниццо, с американскими истребителями (забыл сейчас с какими) такой глюк случился при пересечении экватора, когда их к верх ногами опрокидывало, из-за такой баги в софте бортовом. Основная неприятность, связанная с декомпозицией, заключается в том, что чаще всего всё работает как надо, но при определённом стечении обстоятельств всё внезапно работать как надо перестаёт. Это стечение обстоятельств определяется совокупностью начальных углов.

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

[tvister]

Нда-а-а... Ничего, разберемся, другого пути у нас нет!

Originally Posted by deSAD

... В том переводе "ЧаВо" от western0221, который я в свое время делал, это обстоятельство отмечается особо

А что, тут? (требует какой то пароль).

[deSAD]

Originally Posted by NB79

Спасибо за доброе слово ...

Originally Posted by NB79

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

По одной из версий, это был F-15, по другой - F-16, причем если с последним это "случилось" только лишь в процессе отладки ПО, на симуляторе, то с "Орлом" - инрил ... если повар нам не врет ©

Originally Posted by tvister

... А что, тут? (требует какой то пароль).

Ох ... mea culpa, mea maxima culpa Check your PM, pls.

[NB79]

Originally Posted by deSAD

По одной из версий, это был F-15, по другой - F-16, причем если с последним это "случилось" только лишь в процессе отладки ПО, на симуляторе, то с "Орлом" - инрил ... если повар нам не врет ©

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

[Sita.]

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