Перейти к содержимому


Свернуть чат Чат Открыть чат во всплывающем окне

Гость : (2 дней назад) У кого-нибудь есть полный пак инструментария от lz?
Yakim (Watco... : (14 Июль 2018 - 00:06) :D
Yakim (Watco... : (14 Июль 2018 - 00:06) nope
Yandersen : (13 Июль 2018 - 22:07) Айаяй. Поди Якимко заспамил чат стикерами. :)
Yandersen : (13 Июль 2018 - 22:06) Да лан, тут каждый день кто-нить из админов заглядывает. Как пропустили?
Nextovoy : (13 Июль 2018 - 01:04) Я писал
Гость : (10 Июль 2018 - 22:42) Сорьки, что так у нас. Чего три года так и не попытался в чат писнуть? :)
Nextovoy : (06 Июль 2018 - 16:15) Спасибо
lz : (04 Июль 2018 - 19:44) Активировал.
Гость : (03 Июль 2018 - 16:30) Активируйте его.
Гость : (03 Июль 2018 - 16:30) Мой профиль - Nextovoy
Гость : (03 Июль 2018 - 16:25) Написать в чат. Профиль в ручную админы активируют.
Гость : (03 Июль 2018 - 15:47) Ох уж эта дурацкая привычка писать всё раздельно засоряя чат. Это всё классно, конечно, но ребята, одменестраторы, так называемые. Третий год пытаюсь зарегистрироваться (буквально, третий) на этом форуме, но ПИСЬМО С ПОДТВЕРЖДЕНИЕМ НА ПОЧТУ ТАК И НЕ ПРИХОДИТ. Что делать?
Гость : (03 Июль 2018 - 15:46) Перешёл я всё же по ссылке Redoctor'a...
Гость : (03 Июль 2018 - 15:41) Пора уже M4
Гость : (29 Июнь 2018 - 00:18) итак м3
lz : (28 Июнь 2018 - 16:01) Мы тебе и тут передадим.
Гость : (28 Июнь 2018 - 13:13) Зачем в телеграмме делать?!Я вот например не могу зайти,написать в чат,подписаться и не только у меня это.
Redoctor : (24 Июнь 2018 - 19:35) https://vk.com/away....0_23001&cc_key=
Redoctor : (24 Июнь 2018 - 19:34) Тогда в телеграмме в поисковике набери Механоиды 3
Гость : (24 Июнь 2018 - 19:05) Не открывается.
Redoctor : (24 Июнь 2018 - 18:00) https://t.me/mechanoids3 Для тех кто в танке.
Yakim (Watco... : (15 Июнь 2018 - 01:33) КРУЗИИИС!!!11

Изображение
lz : (15 Июнь 2018 - 00:09) КРУЗИС!
lz : (15 Июнь 2018 - 00:09) ЗИС
lz : (15 Июнь 2018 - 00:09) КРУ
Yakim (Watco... : (14 Июнь 2018 - 14:50) Крузис и Королева тоже не в моем вкусе, а проигрывать нечего =D
lz : (14 Июнь 2018 - 13:55) Конечно, полюбить - так королеву, проиграть - так миллион, сделать - так крузис.
smt005 : (14 Июнь 2018 - 00:22) И от третьего лица тоже можно сделать простенькую игру. Простая игра это лучше чем ничего.
smt005 : (14 Июнь 2018 - 00:21) А, ты хочеш что-бы хит был, с "Crysis" графоном и контентом на 100500 часов игры?
Yakim (Watco... : (14 Июнь 2018 - 00:18) Ни топдовншутеры, ни стратежки)
Yakim (Watco... : (14 Июнь 2018 - 00:15) Не, спасибо, не в моем вкусе=)
smt005 : (13 Июнь 2018 - 23:13) Помнится за пару недель от скуки сделал. Делал по вечерам.
smt005 : (13 Июнь 2018 - 23:13)
smt005 : (13 Июнь 2018 - 23:11) Или например такое, только с моделями из игры -> https://youtu.be/RFDdN5dcX8s
smt005 : (13 Июнь 2018 - 23:07) Yakim, да сами себя пните... :) Сделайте что-то, хотя бы уровня "Scrolling TopDown Shooter".
Yakim (Watco... : (12 Июнь 2018 - 22:17) так что, думаю завтра с утреца стартану марафон)
Yakim (Watco... : (12 Июнь 2018 - 22:15) хе-хе, не сомневайся, я в чате по уе уже поинтересовался, сказали обалденный сериал)))
Yandersen : (12 Июнь 2018 - 20:56) Оооооо, поди ща залипнет на пару дней, стопудофф. :)
Yakim (Watco... : (12 Июнь 2018 - 18:28) Окей гляну)
Yandersen : (12 Июнь 2018 - 16:23) Сериал Пространство посмотри. Не по части Мехов, просто шикарен, авось ману доставит.
Yakim (Watco... : (11 Июнь 2018 - 18:50) Дуст и ты уже закаленные и пустые, надож где-то ману доставать)))
Yakim (Watco... : (11 Июнь 2018 - 18:49) Думаю, кого быть пнуть, что-бы тот пнул в ответ да по сильнее.
Yakim (Watco... : (11 Июнь 2018 - 18:48) Давненько и не маленько хе-хе, делать нечего, прокрастинирую =)
Yandersen : (11 Июнь 2018 - 17:46) Якимка, ты там шо, упоролсо маленько? Чиво картинами опспамилсо?

Фотография
- - - - -

Механика глайдера


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 29

#1 OFFLINE   Yandersen

Yandersen

    Диванный теоретик

  • Админ
  • 454 сообщений
  • Откуда:Canada
  • Настоящее имя:Ян

Отправлено 14 Июль 2014 - 00:32

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

 

Начну с общей картины. Что такое антиграв, как он работает и как его симулировать.

 

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

Скрытый текст

 

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

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

 

Но пока сконцентрируемся на гравиках.

 

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

 

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

 

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



#2 OFFLINE   Yandersen

Yandersen

    Диванный теоретик

  • Админ
  • 454 сообщений
  • Откуда:Canada
  • Настоящее имя:Ян

Отправлено 14 Июль 2014 - 02:04

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

 

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

 

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

 

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

 

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

 

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

 

Ещё раз. Перед тем, как щёлкать выключатели на гравиках, мы делаем два прогноза по времени: за сколько времени глайд придёт в требуемое состояние, если от гравиков попросить создание сил, что приведут к эталону, и за сколько времени глайд погасит скорости (линейную и вращение) до нуля, если затребовать от гравиков создание сил для гашения текущих скоростей (для обоих вариантов все внешние силы, действующие на глайд в данный момент, суммируются). И чьё время оказывается больше, та задача по силам и назначается гравикам.

 

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



#3 OFFLINE   Темплатар

Темплатар
  • Механоид
  • 10 сообщений
  • Настоящее имя:Николай

Отправлено 14 Июль 2014 - 16:37

Я конечно понимаю, что меня убьют за такое кощунство...

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

Что если наш глайдер будет иметь возможность управлять этим грави-полем? пусть у игрока будет 9 кнопок его регуляции, позволяющие вертеть глайдер хоть на ХУ...Z *_*_* Для обычных игроков можно оставить и 4-е кнопки, а для продвинутых можно было бы использовать Num-клавиатуру.

Скрытый текст

 

Звучит довольно сложно, но достаточно просто в 8-и точках сделать приложение силы на глайдер, а дальше физика сама обо всем позаботится(кроме варианта "глайдер улетает в небеса")

Не дай бог Таугэшту прочтет  :unsure:


Если долго стоять в одном месте - можно увидеть, как меняется мир. Ты видел то странное существо в секторе Тундры?

#4 OFFLINE   Taugeshtu

Taugeshtu
  • Создатель
  • 36 сообщений

Отправлено 14 Июль 2014 - 22:28

Темплатар, запиши себе 6-тизначную комбинацию из циферок, скачай War Thunder, начни играть в аркадную битву и параллельно вводи на Numpad'е  эту комбинацию, раз за разом. Увидишь, почему эта идея - херня в чистом виде.


, наверное...


#5 OFFLINE   Yandersen

Yandersen

    Диванный теоретик

  • Админ
  • 454 сообщений
  • Откуда:Canada
  • Настоящее имя:Ян

Отправлено 15 Июль 2014 - 01:13

Вапще-то нечто отдалённо похожее уже штурмовало моё воображение. Это нечто было порождено конструктором глайдера...

 

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

 

Базовый девайс - это колобок в интерфейсном кожухе да с креплениями, главный процессор ("ГП"), такскать, моск глайдера в крепкой раме. Этот девайс обязательно должен присутствовать в каждом глайдере и считается главным объектом, а все остальные - его дочерними.

 

Это не всё, разумеется - ещё броня, придающая скелетоподобной модели законченный вид, но с ней отдельная история, ниже.

 

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

 

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

 

Ну и броня же, конечно. Как сделать возможность накладывать броню так, чтобы глайдер выглядел зализанно? А ведь тоже несложно, как ни странно! Для брони нужны крепления. Пусть это будут штырьки такие, которые крепятся к узлам, точно так же как и балки. Штырёк можно вертеть вокруг круглого узла, выбирая желаемое направление нормали к поверхности брони в данной точке. Кликнув три (или четыре) штырька в конструкторе глайдера мы получаем сегмент брони, изогнувшийся так, чтобы в каждой из трёх (или 4-х) точек крепления, на которые сегмент опирается, поверхность брони была перпендикулярна штырьку (сплайном модель сегмента брони рассчитывается). Количество треугов в ней зависит от изгиба (чем угол больше, тем больше треугов), толщина зависит от стандарта (лёгкая/средняя/тяжёлая), а текстура зависит от типа брони, который юзер поставил. Физическая моделька брони также рассчитывается, только с меньшей детализацией, чем графическая. Если оказывается, что лист брони пересекается с другими элементами глайда, конструктор не разрешает действие и советует разбить броню на сегменты поменьше, добавив ещё креплений.

 

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

 

Оу, я уже предвкушаю негодование тех, кто просёк кажущуюся проблему и готов воскликнуть: "Да ты чё, это ж получится, что в каждом глайде по сотне узлов да балок, на сцене десятки глайдов, и всё это рисовать - видюха скиснет!" А вот и нет. Наиболее многочисленные элементы - узлы и балки - рисуются не реальными 3D моделями, а своими шейдерами: чтобы нарисовать узел, являющийся шаром, нужно просто рендерить квадрат (два треуга), а в пиксельном шейдере поиграть с z-координатой, "вспучив" центральные пикселы, а крайние дискарднуть. И балки точно также рисуются двумя треугами и трюком в пиксельном шейдере. Так что вовсе не напряжно это никак будет.  :)



#6 OFFLINE   Yandersen

Yandersen

    Диванный теоретик

  • Админ
  • 454 сообщений
  • Откуда:Canada
  • Настоящее имя:Ян

Отправлено 15 Июль 2014 - 01:15

Ах, ну так к чему ж я это всё, совсем забыл!  :)

Прикол в том, что каждым девайсом глайда юзер может управлять, войдя в менюшку, кликнув по девайсу, и назначив на определённую функцию девайса своего глайдера желаемую клавишу управления или подкрутив какие настройки, которые девайс имеет. Типа, желаемой высоты парения над рельефом для антиграва или скорострельности для пушки.



#7 OFFLINE   Темплатар

Темплатар
  • Механоид
  • 10 сообщений
  • Настоящее имя:Николай

Отправлено 15 Июль 2014 - 08:08

 

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

 

 

 

ты это так планируешь сделать? можно модель глайдера разбить на достаточно небольших кусков, что бы при каждом попадании выстрела по корпусу отваливался именно нужный(тот у которого произошло столкновение с патроном), но небольшой. правда я сложно себе представляю как это оформить еще и что бы влияло на остальной глайдер :/
 

 

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

 

 

 

Напоминаю - если будут спасатели, то игрок может просто подождать, пока вокруг никого не будет, и включить таймер самоуничтожения. Если не ошибаюсь, при "самоизъятии" механоиды не теряли рейтинг.


Если долго стоять в одном месте - можно увидеть, как меняется мир. Ты видел то странное существо в секторе Тундры?

#8 OFFLINE   Taugeshtu

Taugeshtu
  • Создатель
  • 36 сообщений

Отправлено 15 Июль 2014 - 11:34


чтобы нарисовать узел, являющийся шаром, нужно просто рендерить квадрат (два треуга), а в пиксельном шейдере поиграть с z-координатой, "вспучив" центральные пикселы, а крайние дискарднуть

А тени? А бешеный филлрейт в данном случае? А текстурные координаты?

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

 


Кликнув три (или четыре) штырька в конструкторе глайдера мы получаем сегмент брони

Идея со сплайнами по опорным точкам неплоха. Я думал несколько иначе, на каждый модуль сгенерировать convex hull - выпуклый меш (не имеющий вогнутостей), "вырастить" его по нормалям, объединить все получившиеся меши, "вырастить" их - и получим две поверхности брони, внутреннюю и внешнюю. Но твоя идея, конечно, прикольнее. Тем, что позволяет управлять формой брони более точно, и даже делать несколько слоёв (на случай, если мы внезапно захотим ввести всякие кумулятивные снаряды)

 

Ну, и ещё, я не думаю, что мех должен быть главным блоком, да и узлы, в принципе, не нужны. Можно лепить модули как нравится (с процессом, похожим на сборку самолёта в Kerbal Space Program), а потом выбирать модули попарно и нажимать кнопочку "соединить" - и вуаля, получаем сгенерированный сегмент рамы. И система будет более гибкой, чем с узлами крепления.

 

Т.е. в моём видении конструктор глайдеров будет иметь 3 режима работы - расстановка модулей, генерация рамы, генерация брони.


, наверное...


#9 OFFLINE   Yandersen

Yandersen

    Диванный теоретик

  • Админ
  • 454 сообщений
  • Откуда:Canada
  • Настоящее имя:Ян

Отправлено 15 Июль 2014 - 12:56


А тени? А бешеный филлрейт в данном случае? А текстурные координаты? Вообще, зря ты переживаешь.

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

Оба элемента рендерятся своими шейдерами, разумеется.

 

 

"вырастить" ... по нормалям, ..., ... и получим две поверхности брони, внутреннюю и внешнюю.

Именно так - сплайном генерим меш внутренней поверхности, затем по нормалям генерим внешнюю поверхность и боковые закрывающие сегменты..  :)

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

 

 

 


Ну, и ещё, я не думаю, что мех должен быть главным блоком

О как? Ну и каким куском игрок будет управлять, если глайдер разорвало на части, всё ещё способные к функционированию?

 

 


Можно лепить модули как нравится (с процессом, похожим на сборку самолёта в Kerbal Space Program), а потом выбирать модули попарно и нажимать кнопочку "соединить" - и вуаля, получаем сгенерированный сегмент рамы.

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



#10 OFFLINE   Yandersen

Yandersen

    Диванный теоретик

  • Админ
  • 454 сообщений
  • Откуда:Canada
  • Настоящее имя:Ян

Отправлено 16 Июль 2014 - 05:14

От антиграва до искусственного интеллекта

 

Поразмышляв над антигравом, я задался вопросом: если от контроллера гравиков требуется держать глайд на определённой высоте, то как эта высота определяется? Ранее я постулировал, что это есть высота от центра масс и вертикально вниз до ландшафта. Но это же бессмысленно! Что если глайд решил припарковаться на открытом канализационном люке? Получится, что высота до дна огромная, значит можно расслабить гравики и позволить машине падать. Но тогда нос и попа глайда просто стукнуться о края люка и глайд сыграет роль затычки. Неверно же! Другой вариант - влёт на трамплин. Нос стукнется, пока центр масс достигнет возвышения.

 

Посему просто задавать антиграву держать высоту - не решение вообще.

 

Введём же новый тип девайсов - сенсоры (proximity sensors). Они жёстко крепятся на корпусе в разных точках, как гравики, и мониторят лазерным лучом, скажем, расстояние до поверхности. Т.е. данные сенсора - это его положение, направление и замерянное расстояние (ну или квадрат его - не суть). Если какой-то сенсор обнаруживает, что расстояние ниже порога срабатывания, он требует от антиграва создать силу, приложенную в точке его крепеления и направленную противоположно направлению его взгляда - ну, типа, "спасай антиграв, поверхность слишком близко, тяни меня отсюдава!".

Для плавности можно ввести два порога для сенсора - начальный и критический: выходной сигнал сенсора равен нулю, если расстояние больше начального порога и 100% если расстояние выше критического порога. Между ними весомость возрастает обратно пропорционально функции от расстояния (линейно, квадратично - не суть, главное чтоб плавно зависела).

 

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

 

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

Скрытый текст



#11 OFFLINE   Taugeshtu

Taugeshtu
  • Создатель
  • 36 сообщений

Отправлено 16 Июль 2014 - 11:34


Жёстко прописывая явное влияние сенсора на эффектор мы по сути создаём безусловный рефлекс в мозге нашего механоида.

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

 

Сами сенсоры - здравая идея, но инфу с них не стоит кидать сразу на конкретные эффекторы.


, наверное...


#12 OFFLINE   Arсhangel

Arсhangel

    Главный админ

  • Админ
  • 44 сообщений
  • Откуда:Украина
  • Настоящее имя:Влад

Отправлено 16 Июль 2014 - 12:18


не стоит кидать сразу на конкретные эффекторы.

Почему бы тогда не кидать инфу системе стабилизации, а она уже распределяла нагрузку на сами эффекторы.



#13 OFFLINE   Yandersen

Yandersen

    Диванный теоретик

  • Админ
  • 454 сообщений
  • Откуда:Canada
  • Настоящее имя:Ян

Отправлено 16 Июль 2014 - 13:33

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

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

"Весомость" для каждого конкретного гравика определяется так:

if (GravikState==DEAD) Weight = 0;

else Weight = dot( cross(SensorDir, (SensorPos-MassCenterPos) ), cross(GravikDir, (GravikPos-MassCenterPos]) );

 

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



#14 OFFLINE   Темплатар

Темплатар
  • Механоид
  • 10 сообщений
  • Настоящее имя:Николай

Отправлено 16 Июль 2014 - 17:02

Еще вариант - потеря какого-нибудь эффектора всего лишь потеря скольких-то там процентов от мощности антиграва (остальное на себя берет система стабилизации)


Если долго стоять в одном месте - можно увидеть, как меняется мир. Ты видел то странное существо в секторе Тундры?

#15 OFFLINE   SHW

SHW

    Разработчик

  • Создатель
  • 32 сообщений
  • Откуда:Самара
  • Настоящее имя:Слава

Отправлено 22 Июль 2014 - 18:42

Мне не очень нравится идея использовать гравики для всех способов перемещения. Думаю, маршевые реактивные двигатели всё-таки стоит оставить. Иначе, глайдер рискует быть весьма вялым. Вы же не сможете обеспечить большие ускорения только с помощью антигравов. Хотя, если они будут вращаемыми, то можно попробовать.
Your mind is software. Program it.
Your body is a shell. Change it.
Death is a disease. Cure it.

#16 OFFLINE   Yandersen

Yandersen

    Диванный теоретик

  • Админ
  • 454 сообщений
  • Откуда:Canada
  • Настоящее имя:Ян

Отправлено 22 Июль 2014 - 22:01

Если гравик способен противостоять гравитации и даже джампать, значит придать глайду ускорение больше 9.8м/с^2 для него не проблема - а раз так, то сила похлеще маршевого движка с гравиков выходит. Другое дело, что угол с поверхностью играет роль, да... Но идея была в том, чтобы растопырить пачку гравиков во все стороны, чтоб всегда было каким уцепиться. Тут испытывать надо, не так уж и очевидно, что на самом деле получится.



#17 OFFLINE   Taugeshtu

Taugeshtu
  • Создатель
  • 36 сообщений

Отправлено 23 Июль 2014 - 01:46


а раз так, то сила похлеще маршевого движка с гравиков выходит

Ну-ну... Астронавты во время взлёта ракеты испытывают 3-4g перегрузок, а гравик у тебя даёт, ну, допустим, 2g. Вертолёт получится. Впрочем, садись и пиши)


, наверное...


#18 OFFLINE   Yandersen

Yandersen

    Диванный теоретик

  • Админ
  • 454 сообщений
  • Откуда:Canada
  • Настоящее имя:Ян

Отправлено 23 Июль 2014 - 03:00

2g? Тогда глайды в мехах не подпрыгивали бы так живенько.  :)



#19 OFFLINE   SHW

SHW

    Разработчик

  • Создатель
  • 32 сообщений
  • Откуда:Самара
  • Настоящее имя:Слава

Отправлено 23 Июль 2014 - 14:19

Не забывайте, что вам ещё надо, чтобы он не переворачивался при ускорении. А значит выгоднее всего занижать глайдер и тыкать сильно вдоль поверхности, чтобы получить ускорение больше 1g. Да ещё и накачивать этот гравик придётся очень сильно, так как расстояние от точки отталкивания сильно увеличится, а эффективность его падает как квадрат расстояния, то есть очень быстро. А если вы взбираетесь на склон, или со склона, то этот близкий к горизонтали гравик вообще будет тыкать в пустоту. С другой стороны, если реактивный двигатель даёт ускорение больше 1g, то достаточно поставить глайдер на попу, чтобы превратить его в ракету.
Your mind is software. Program it.
Your body is a shell. Change it.
Death is a disease. Cure it.

#20 OFFLINE   PA3UJIb

PA3UJIb

    Серый

  • Создатель
  • 171 сообщений

Отправлено 24 Июль 2014 - 19:04

Proximity sensors это конечно занятно придумано.

Рассмотрим ситуацию в пределе - у нас до хренища много сенсоров. Тогда получаем вместо нескольких лучей поверхность, которой глайдер отталкивается от земли. Если учитывать, что сила антигравитационного привода снижается на краях этой поверхности, то - ВУАЛЯ! - мы снова возвращаемся к сферическому boundbox'у, как в М1-М2. Мера расстояния от точек грунта до "сферы взаимодействия" определяет силу антиграва в конкретной геометрической точке глайда. И именно от нее рассчитывается взаимодействие с землёй и остальными объектами, на ней расположенными. Так что, возвращаясь к ситуации глайдера над люком, глайд просто зафиксируется над дыркой, будет в так называемом равновесном состоянии, и чтобы сдвинуть его понадобится приложить усилие более значительное, чем при движении по ровной как стол поверхности.


 





Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных