Clamp
Clamp'ова кухня

Clamp's Physics

Добавлен , опубликован
Небольшая наработка, реализующая достаточно высокоэффективную одновременную обработку множества снарядов, движущихся с соблюдением основных законов кинематики. В карте присутствует сама система и техдемо к ней, а также краткое описание. Для работы требуются установленные парсеры vJass и cJass.
Особенности:
  • Одновременная обработка до 400 активных снарядов без падения производительности
  • Возможность "на ходу" изменять частоту обработки снарядов и основные константы
  • Максимальная отвязанность системы от внутриигровых контроллеров движения
  • Хорошо написанный самодокументирующийся код с прозрачной архитектурой
Кроме того, в карте можно найти полную эмулированую библиотеку "math.h" из набора стандартных библиотек Си (в системе практически не используется, делал когда-то ради собственного удовольствия), полновесный набор функций для работы с векторами и классную модельку дамми-юнита со множеством анимаций разных углов наклона (к сожалению, автор модели мне неизвестен).
С радостью приму любой фидбек относительно системы, а также предложения по улучшению реализованного в ней функционала.
P.S.: версия системы указана как "0.9", однако при отсутствии каких-либо существенных замечаний по поводу её реализации она же будет являться финальной ("1.0").
P.P.S.: возможно, на днях запилю пару небольших статеек с более-менее подробным разбором системы и/или векторного подхода к движению (старая, кмк, не слишком информативна), о потребности пишите в комменты.
P.P.P.S.: если что, я не программист и никогда себя им не считал / не называл, так что в случае нахождения каких-нибудь заметных косяков прошу не пылать экспрессией на весь сайт. // Toadcop, привет маме! Мне понятны твои мотивы, но фильтры на базарах таки иногда надо включать.
, , ,
Скачать - 63 КБ 210
16 июл 2017
  • Размещен: 16.07.2017 10:26:19
  • Создан: 16.07.2017 10:26:19
  • Обновлен: 16.07.2017 10:26:19
4 271
`
ОЖИДАНИЕ РЕКЛАМЫ...

Показан только небольшой набор комментариев вокруг указанного. Перейти к актуальным.
0
21
7 лет назад
0
Doc, справедливости ради, объект, который весит больше, действительно в реальности быстрее падает из-за сопротивления воздуха. Да, переменную лучше назвать не mass, а как-нибудь наподобие resistance_factor, но фича с практической точки зрения полезная.
3
29
7 лет назад
Отредактирован Doc
3
То есть в этом случае чем больше сопротивление тем быстрее падает объект?)
Я бы ничего это не писал если бы не заявления в духе
[20:06:50] Clamp * Потому что всё от и до построено на матмодели, а не через костыли типа "юнит вошёл в область"
[20:06:16] Clamp * Доделал по инерции, смею утверждать, что у меня физика производительнее, чем в TcX
И прочий ненужный пафос.
0
30
7 лет назад
Отредактирован Clamp
0
ты просто сам попробуй не трогая основной код реализовать пару спеллов
Реализовал, потом мб залью мапу (если допилю).
Тут даже такие банальности как то, что гравитация это скаляр, а не вектор.
Исходно делал как раз через вектор, но не смог найти векторному выражению никаких применений, и перевёл в скаляр, хз.
Ты понимаешь вообще что там было основано на входе в ректангл только чтобы максимально перенести отсеивание колижнов в нативный код?
Тащемта, да, и это вроде где-то обсуждалось даже активно
зачем-то есть настраиваемый тикрейт
Глубоко в концепции это задумывалось как метод снизить нагрузку через снижение тикрейта при повышении количества объектов, но позже эмперически выяснил, что сам факт наличия такого числа юнитов оказывает на нагрузку несравнимо большее влияние, за сим оставил.
На самом деле, если бы не "ненужный пафос", то хрена-с-два я бы дождался здесь хоть какого-нибудь code review от практикующего специалиста, так что хз даже про его "нужность" или "ненужность". Хотя метод, конечно, не самый красивый, тут каюсь и приношу извинения.
При чем тут стек
Копипаста со статьи Скорпа, я знаю, что такое стак, но не увидел никакой проблемы в именовании, простите, если задел в нежных чувствах =)
с тем же успехом можно было слить все эти чайлд структуры в основную и ничего бы не изменилось.
стало бы нечитаемо, лол
На деле, это использую примерно так: есть набор пресозданых "визобжей" и дамагов, сам "физобж" варится по требованиям и на него вешаются копии нужных мне кусков конфигурации. Не помню, как это "правильно" называется, допустим, "factory" (надеюсь, не задел в нежных чувствах, если ошибся ;D)
Doc:
вот с этого просто в АХАХАХА
Ничего не могу сказать, действительно обосрался в полный рост \о/
Как-то получилось, что в игре выглядит нормально, "да и хер с ним, не буду трогать"
объект который весит меньше будет медленнее падать?
Там же проекция на ось z, то есть технически это ускорение падения, а не наоборот.
Снаряды тупо всегда уничтожают себя при колижне с юнитами.
А что им ещё делать, лол?
Если в сухом остатке, то действительно спасибо за то, что понатыкал в несколько куч, учту. Хотел бы попросить менее эмоционально и более предметно потыкать, по возможности, но само собой настаивать не могу.
0
29
7 лет назад
0
Фактически проблемы нет в наименовании никакой, работает - ок, но по факту если претендуешь на понятный код то естественно называть нужно своими именами.
Уничтожаться ниче офк не должно, какого фига физический объект должен за это отвечать? Но мое изначальное замечание было в сторону настраиваемости "движка".
0
30
7 лет назад
0
Doc:
если претендуешь на понятный код то естественно называть нужно своими именами.
Справедливо.
Уничтожаться ниче офк не должно, какого фига физический объект должен за это отвечать?
написал было возражение, но потом призадумался и передумал...
ЕМНИП, операции с базовыми типами (int, float, ...) напрямую обрабатываются, без дополнительных обёрток. Идея как раз заключалась в том, что всё, кроме визуала (юнит + эффект) хранится и обрабатывается в виде конструкций из этих базовых типов, даже запилил квадтри (только понятия не имел, что оно так называется) для упихивания "своих" декораций. Но, увы, там нашёлся баг, локализацию которого я счёл неоправданно трудоёмкой после ряда попыток и вовсе отказался от идеи юзать дудады.
единственное, что в нем хорошего это стиль
Вот это, должен признаться, нормально так огрело. Действительно, ничего больше?
2
29
7 лет назад
2
В коде нет совершенно ничего нового да и старое сделано на данный момент не везде лучшим образом, в этом и суть.
xgm.guru/forum/showthread.php?t=25570 пжлст, опана, гляди-ка
void HitGround(Body a) {
     real z0 = GetZ(a.x,a.y)
     real z2 = GetZ(a.x+CollPlosk,a.y)
     real z1 = GetZ(a.x,a.y+CollPlosk)
     real nx = (z0-z2)/SquareRoot((z0-z2)*(z0-z2) + (z0-z1)*(z0-z1) + CollPlosk*CollPlosk)
     real ny = (z0-z1)/SquareRoot((z0-z2)*(z0-z2) + (z0-z1)*(z0-z1) + CollPlosk*CollPlosk)
     real nz = CollPlosk/SquareRoot((z0-z2)*(z0-z2) + (z0-z1)*(z0-z1) + CollPlosk*CollPlosk)
Абсолютно то же самое, например. Да, код выглядит как нечитабельное говно. Да, тут тоже массивы называются стеком. Но тут и фичи и конфигурация.
0
12
7 лет назад
0 
gravity = 9.8/tickrate;
Я конечно понимаю, что "матмодели" это круто, и вообще код выглядит немного за пределами моего разумения как недопрограммиста, но постоянная гравитации ну никак не может зависеть от внутренней частоты работы физ. системы.
И еще, то, что в системе называется "impulse", это на самом деле должно называться "velocity", потому что импульс это масса*скорость, отсюда кстати и та вышеуказанная ошибка с умножением на массу.
0
30
7 лет назад
Отредактирован Clamp
0
Sergarr: 
gravity = 9.8/tickrate;
постоянная гравитации ну никак не может зависеть от внутренней частоты работы физ. системы
Каждые 1/tickrate секунды запускается обработка списка снарядов. Ускорение свободного падение (как и любое) измеряется в "метров в секунду за секунду", то есть в "изменении скорости за секунду". А за 1/tickrate секунды скорость изменится на 1/tickrate от полного значения.
И еще, то, что в системе называется "impulse", это на самом деле должно называться "velocity", потому что импульс это масса*скорость, отсюда кстати и та вышеуказанная ошибка с умножением на массу.
Вполне вероятно, что так и есть, исходную версию начинал писать через импульсы.
0
29
7 лет назад
0
И еще, то, что в системе называется "impulse", это на самом деле должно называться "velocity", потому что импульс это масса*скорость, отсюда кстати и та вышеуказанная ошибка с умножением на массу.
Я вот с этим кстати мега согласен и на самом деле просто забыл написать.
0
12
7 лет назад
Отредактирован Sergarr
0
Clamp:
Sergarr: 
gravity = 9.8/tickrate;
постоянная гравитации ну никак не может зависеть от внутренней частоты работы физ. системы
Каждые 1/tickrate секунды запускается обработка списка снарядов. Ускорение свободного падение (как и любое) измеряется в "метров в секунду за секунду", то есть в "изменении скорости за секунду". А за 1/tickrate секунды скорость изменится на 1/tickrate от полного значения.
А почему нельзя вот это деление на tickrate сделать непосредственно в физическом коде? Вот здесь, например:
this.impulse.z -= this.mass*gravity;
Вместо того, чтобы умножать на массу, делить на тикрейт. В бонусе - тебе не придется перерасчитывать величину gravity каждый раз, когда ты меняешь tickrate.
И еще:
                float nextX = this.location.x + this.impulse.x;
                float nextY = this.location.y + this.impulse.y;
Вообще, у тебя этот "импульс" (который на самом деле скорость), для того чтобы все было именно что по "матмодели", обязательно должен везде делится на tickrate - иначе получается, что ты к величине размерности расстояния добавляешь величину размерности скорости, что не есть хорошо.
Да, и еще: 9,8 - это для метров. В варике 1 единица расстояния это вовсе не метр, а гораздо меньшая величина. В варике 1 метр это где-то 100 единиц расстояния. Так что константа gravity у тебя должно быть не =9.8, а =9.8/100. И без всякого tickrate-а, разумеется.
0
30
7 лет назад
Отредактирован Clamp
0
Sergarr:
Да, и еще: 9,8 - это для метров. В варике 1 единица расстояния это вовсе не метр, а гораздо меньшая величина.
Это вполне очевидно. Выставил 9.8, визуально результат меня устроил, с чего бы менять?
В бонусе - тебе не придется перерасчитывать величину gravity каждый раз, когда ты меняешь tickrate.
Такой себе по ценности, одно дополнительное деление и одно дополнительное умножение раз в практически никогда процессор сможет выдержать.
обязательно должен везде делится на tickrate
Точно! Каждое деление вектора на число - это три операции деления, каждый объект описывается двумя векторами, то есть всего шесть операций деления. Достаточно согласиться с твоим предложением, и их количество вырастает до девяти, что не то, чтобы критично, но в 1.5 раза тяжелее без каких-либо профитов вообще.
Кроме того, в самом коде физического компонента объекта логика описывается пусть с уже обмусоленной ошибкой, но всё-таки универсально: при обновлении объекта он смещается в направлении суммирующей на её величину, а скейлинг этой величины под тикрейт - работа контроллера, который обрабатывает этот объект и устанавливает сам тикрейт.
Показан только небольшой набор комментариев вокруг указанного. Перейти к актуальным.
Чтобы оставить комментарий, пожалуйста, войдите на сайт.