newbspguy
newbspguy copied to clipboard
UnrealKaraulov
Load map from info_player_start POV, if it exists
Предложение - добавить опцию для загрузки карты в редакторе с точки info_player_start. А то есть такие карты, на которых не сразу сориентируешься, где что находится, если загружаешься непойми где. Либо, допустим, даже так, сделать опцию, какую энтить искать для точки загрузки. info_player_deathmatch или, к примеру, trigger_changelevel. Это на случай, когда на карте нет info_player_start. Если таких энтить несколько, то выбирать первую по списку (чтоб всегда с одной точки обзор был вначале). Ну и учитывать angles в настройках энтити для выбора направления обзора.
По поводу реализации данной фичи, можно так сделать: список энтить в настройках, с приоритетом. Первая энтить будет той, которую будет искать редактор в первую очередь, например info_player_start. Если не найдена, то ищет первую info_player_deathmatch по списку. Если не найдены обе, то смотрим следующую, или грузим карту, как обычно.
Что-то не пойму как "angles" в CameraAngles записать, то работает то не работает, как-то совсем странно. На одних картах получилось работает на других в обратное направление смотрит и т.п)
На счет trigger_camera, тоже думал добавить, но чет геометрию совсем подзабыл :D Думаю как получить vec3 angles из двух vec3 точек :)... )))) как найду, сделаю :)
Я вижу, опция работает. Однако энтить в списке она выбирает НЕ первую. Например, на c1a0 выбирается вторая энтить info_player_start (удивительно, но там их две), которая находится почти в конце списка. Аналогично, на карте bounce выбирается вторая энтить, а не первая.
Ну и поворачивает взгляд не туда. Было бы, кстати, неплохо помещать камеру за спиной модели игрока, т. е. на некотором оптимальном отдалении, а не внутри неё.
Я бы предложил поднять камеру на 50 юнитов выше и отодвинуть на 50 юнитов назад. Тогда спавнишься за плечами модели и немного над ней. Ну или на 64 юнита, чуть подальше.
Питч можно не учитывать, достаточно делать проверку Yaw, т. е. куда модель смотрит по сторонам света.
Пример того, как выглядит спавн с отдалением на 64 юнита.
А это 32.
Кстати, на данный момент, камера выбирает направление +90 градусов к дефолтному расположению энтити (без учёта значения Yaw, как если бы оно было = 0+90). Поэтому направление взгляда совпадает с расположением модели в тех случаях, когда Yaw = 90 (как на скринах выше).
Хотя бы отдаление не помешает пока, а то стрёмно спавниться внутри модели.
Хотя бы отдаление не помешает пока, а то стрёмно спавниться внутри модели.
Сделаю уже завтра если не забуду. Казалась бы камеру должно быть очень легко повернуть но у меня какие-то трудности с этим возникают :)
Ещё одна проблемка, на примере скинутой карты de_dust2x со вставленной моделью камня. Почему-то если есть такая модель на карте, и прога её загружает, то она уже не стартует с видом от info_player_start / info_player_deathmatch, а запускает карту с видом от нулевой точки. Т. е. как будто не находит нужную энтить. Возможно, ищет её в подгруженной модели.
Да и посмотрю что можно сделать с отображением текстуры, возможно нужно их во встроенные загрузить что бы нормально отображались в хл.
Да, можно опцию сделать по сохранению с использованными вшитыми текстурами. И надо бы, кстати, доработать функцию экспорта wad в карту. Тоже не весь wad импортировать, это ведь ни к чему, а только использованные на карте текстуры.
Логичный вопрос - вот в программе есть виджет Go To, в котором имеется 1) переход в указанную точку по указанным координатам, 2) поворот взгляда в заданном направлении. Так вот вопрос - если Go To делает то, что требуется, так почему какие-то сложности с перемещением игрока в нужную точку и указанием направления его взгляда при этом? Функция абсолютно одна и та же. Следственный эксперимент:
Сразу всплывает ряд ошибок. Во-первых, оси перепутаны. Coordinates и Angles - это не X Y Z, как указано в GoTo. Координаты - это Y X Z. Т. е. -621 - это глобальное "вперёд и назад", -1000 - это "влево и вправо", -166 - это "вверх и вниз". Я уже ранее писал, что Y и X поменяны местами в очереди. Во-вторых, камера, как выясняется, работает через задницу. А именно, то, что в графе Angles указано, как X Y Z на деле вообще является Y Z X (не Pitch, Yaw, Roll, а Pitch, Roll, Yaw). Т. е. первая цифра даёт наклон взгляда вниз-вверх (это Pitch, или Y по установленным правилам). Вторая при Go To не делает ничего, но по логике она должна давать крен обзора влево-вправо (это Roll, или Z). Третья цифра даёт поворот обзора вокруг вертикальной оси (это Yaw, или X). Но и это не всё. Третий косяк - отсчёт направления взгляда камеры соответствует углу 90 градусов. Т. е., чтобы нам камерой смотреть туда, куда будет смотреть игрок, развёрнутый с углом Yaw = 0, нужно в Go To прописать не X, а Z, и не 0, а 90. Но дальше самое смешное. Камера BSPGuy крутит обзор в противоположную сторону. Т. е. если info_player_start повёрнут на 90 градусов по angle, то нам в нужно не прибавить 90, а вычесть 90 из исходного направления 90 градусов. Т. е. мы будем смотреть в нужном направлении, если указать 0 в графе Z. Если энтить повёрнута на 180 градусов, то камере нужно задать значение -90 или 270. В общем, полный бред. Энтити вращаются против часовой стрелки, а камера - по часовой.
Что-то с этим надо делать...
@Qwertyus3D ахах вот почему я не мог никак сделать что бы работало, у меня тоже сказачная хрень происходила когда пытался установить углы )) Ну посмотрю что с этим можно сделать
Там ещё я хотел, чтобы обзор камерой отдалялся назад на 50 юнитов, но чтобы это работало, для начала придётся наладить управление камерой, т. к. само по себе "назад" определяется тем, как развёрнута энтить. Т. е. для начала нужно определить, где у неё, собственно, зад. И уже согласно этому отдалять камеру, относительно выбранного направления.
Кстати, в меню Go To есть проблемка - размер окна фиксированный, его нельзя увеличить так, чтобы все опции были видны сразу, приходится использовать прокрутку вниз. И состояние данного виджета тоже не восстанавливается после перезапуска программы.
Нашел как угол правильно устанавливать https://github.com/rein4ce/hlbsp/blob/1546eaff4e350a2329bc2b67378f042b09f0a0b7/js/hlbsp.js#L266 :) я то думаю какого черта он кривой какой-то все время получался)))
@Qwertyus3D сделал как там, теперь углы правильно устанавливаются, и камера отодвигается выше
Работает правильно, камера не то, чтобы выше, просто примерно на уровне глаз. НО пропущено то, на что я указывал - неправильное именование осей для Coordinates и Angles. Это базовая проблема редактора, оси поименованы не так, как их считает движок игры, и как они прописаны в любом FGD и редакторе карт.
В общем, всё заново (выше немного неправильно объяснил, сам запутался), то, что у нас в окне Go to в графе Coordinates подписано, как оси X Y Z, на деле должно быть подписано, как Y X Z. Это вопрос №1. Первая координатная ось - это ось Y (фиолетовая), а не X (синяя).
Вопрос №2. Оси графы Angles (которые указывают, как разворачивать объект) - это X Z Y. Смотрим сюда: http://samselectronicsprojects.blogspot.com/2014/07/getting-roll-pitch-and-yaw-from-mpu-6050.html В FGD порядок осей объектов указан, как PItch Yaw Roll (т. е. X Z Y). Первая ось (Pitch) - это синяя ось X при выделении объекта в редакторе, вращение объекта вокруг которой вызывает наклоны-запрокидывания объекта вниз (+) / вверх (-). Вторая ось (Yaw) - это зелёная ось Z при выделении объекта в редакторе, вращение объекта вокруг которой вызывает повороты объекта влево (+) / вправо (-) Третья ось (Roll) - это фиолетовая ось Y при выделении объекта в редакторе, вращение объекта вокруг которой вызывает крен в правую (+) или левую (-) сторону.
Т. е. в обоих случаях последовательность осей не X Y Z, как могло бы показаться логичным. Тем не менее, такой порядок принят, и следует просто подписать оси в соответствии с принятым порядком. Обращаю внимание, что координатные оси ещё прописаны и в виджете Трансформации, в графах Move и Scale. И там тоже должен быть указан порядок Y X Z. Надеюсь, теперь с этим всё понятно.
Вопрос №3. Когда в виджете Go to в разделе Angles мы указываем, куда развернуть камеру, то тут сразу несколько проблем.
-
Вторая графа Angles (то, что сейчас указано, как Y, а на деле является Z) не даёт задать значение угла поворота. Т. е. ты просто вписываешь любое число, а оно тут же сбрасывается на 0.
-
Если мы оставляем значение Angles 0 0 0, то после перемещения камера на деле разворачивается в положение 0 90 0. Т. е. добавляет 90 градусов поворота по второй графе (если бы она работала).
-
Если мы что-то вписываем в третью графу, допустим, 90 градусов, то это вместо наклона камеры (который должен задаваться данной осью) приводит к повороту камеры по Yaw (вторая графа), причём с инвертированным значением. Т. е. камеру крутит по другой оси и в обратном направлении.
В итоге, наклон камеры (Roll) с помощью Angles не работает вообще, а поворот камеры (Yaw) просто поломан аж в трёх местах. Единственное согласованное значение - это Pitch из первой графы.
Вот теперь всё очень чётко объяснил, надеюсь.
Ещё дополнение, неплохо бы, чтобы можно было сразу три значения граф вставлять из буфера обмена. Ну т. е., чтобы щёлкнув по первой графе, можно было туда скопипастить значение типа 100 200 -300 И сразу заполнялись все 3 графы, а не вручную каждую править.
@Qwertyus3D ну я поменял текст стало лучше или я не так понимаю, мне чето с этими углами и координатами плохо доходит)))))
Ну я же всё расписал. Как я ещё должен объяснить? Ладно: Вопрос №1 и Вопрос №2 - это просто текст изменить.
Вопрос №3 - ну тут надо перечитать и врубиться, потому что там баг из трёх пунктов, каждый из которых следует исправить. Я максимально чёткое описание дал, на мой взгляд.
Я сейчас дам картинку, в чём проблема, а ты уж постарайся понять, вроде не на иностранном языке пишу.
Итак. это скрин с карты c1a0b. Пример взят по энтите info_player_start. Данная энтитя спавнит игрока с расположением строго по оси координат 0 0 0, т. е. вот как эта моделька расположена, так и должен смотреть взгляд камеры при перемещении Go To, если мы не меняем угол (Angles).
А фактически - БАГ №1 - если мы оставим угол 0 0 0 в Angles, камера разворачивает взгляд на 90. Т. е. мы будем смотреть вот так:
Внимание! Я на модельке показываю, как разворачивает камеру при значении 0 0 0. Т. е. моделька тут для понимания, в чём проблема камеры, а с самой моделькой всё нормально, поэтому на ней и показываю, что не так с камерой.
Как видно из примера, камеру разворачивает на 90 градусов по среднему значению, т. е. 0 90 0. Это у нас ось Z, а порядок осей Angles - X Z Y.
Для X, соответственно, получается так:
А для Y так:
Ещё раз, это три примера, как ДОЛЖНА БЫЛА БЫ работать камера, если бы она работала правильно. Если бы мы вбивали в Go To Angles значения 90 градусов по каждой из осей и камера после этого правильно бы поворачивала нашу точку обзора.
Т. е. в виджете Angles порядок осей должен быть X Z Y. Это то, что было ранее обозначено, как Вопрос №2.
X управляет наклоном камеры вниз, в сторону пола при плюсовых значениях, в сторону потолка при отрицательных. Сейчас это так и работает, только ось в виджете не на своём месте по порядку.
Y управляет вращением камеры вбок, плюсовые значения (если мы считаем их с видом от первого лица) должны наклонять обзор по часовой стрелке, минусовые - против часовой. На данный момент с этой осью БАГ №2 - она вращает камеру по оси Z и в противоположном направлении. Т. е. вообще не за свою ось отвечает.
Z управляет вращением камеры вокруг вертикальной оси, и плюсовые значения - это ДОЛЖНЫ БЫТЬ повороты влево (считая вид от первого лица), а минусовые - повороты вправо. На данный момент эта ось вообще не управляема - это БАГ №3. Сначала вводимые значения сбрасывались, а теперь ты вообще отрубил возможность вводить туда значения.
Обращаю внимание, что в меню дебага текущее отображение углов Angles тоже выводится в порядке X Y Z, там тоже нужно поменять последовательность на X Z Y, чтобы везде всё совпадало.
Ещё раз, что требуется:
- поменять порядок осей Angles в виджетах Go To и Debug на X Z Y
- убрать дополнительный поворот камеры по оси Z на +90 градусов, когда мы вбиваем значения Angles в Go To.
- исправить то, что значения, вбиваемые в графу Y, крутят камеру по оси Z, и в противоположном направлении.
- исправить то, что ось камеры Z сейчас не управляется вообще, а только посредством неправильного вращения по Y.
Надеюсь, теперь всё ясно, потому что я уже не один час потратил на описание проблемы, и как бы уже запарился объяснять -_-