В целом есть много численных методов интегрирования лучше, чем метод прямоугольников, я не спорю, но ещё раз. Цель статьи показать, какие задачи в целом решаются математикой, а не показать наилучшее решение конкретной задачи.
В ней нет открытий, откровений и прочего. И была написала исключительно из-за того, что очень часто встречается абсолютное непонимание того, зачем в целом нужно знать математику, и какие прикольные задачи можно решать с помощью неё. Я искренне верю, что многим в вузе неинтересно изучать математику, так как непонятно, а зачем нужны эти матрицы, интегралы и прочие довольно абстрактные вещи. Можно придраться и к тому, что интеграл — это совсем не площадь под кривой. Так как площадь под кривой — это лишь его геометрическое представление. Кратные и поверхностные интегралы уже так просто не опишешь
Можно вспомнить много численных методов, из популярных метод Симпсона ещё лучше, но тем не менее это не цель статьи, научить математике. На это в вузах по 4 года тратят. Интеграл нужен для вот такой-то задачи. Какой метод интегрирования подставить в GetApproxSquareAnimCurve — дело третье.
Я хз, что это за формула, и что в ней такое кси, но вообще на сколько мне известно, абсолютная погрешность на определённом интеграле равна v * (b — a)^2/(2n). А теперь подставим значения из конкретно приведённого мной примера. Распределение скорости в целом лучше брать нормализованным, так как дистанция определяется позже, но в задаче у нас v = 1, a = 0, b = 1, n = 1000, то есть мы получаем 1/2000 — казалось бы, что это много. Но при вычислении интеграла мы 1000 раз складываем float значения < 1, что даёт ошибку 10^(-6)*1000 = 1/1000, что уже больше. Но помимо этого в следующей формуле для вычисления скорости ошибка ещё выше, так как там увеличивается степень вычислений.
Так что в данном конкретном примере проблема во float. Но вообще точность float почти всегда будет хуже, чем вычисление подобными методами на достаточно большом количестве операций
Просто не надо забывать, что float хранит всего 7 значащих символов, поэтому копейки которые потерялись при интегрировании — это мелочь, по сравнению с тем, как это суммирование может ломаться на нормальных числах в части расчёта скорости
Вообще на таком количестве итераций и по такой кривой — нет. Ошибка накапливается вот тут, которая имеет значение.
_Rigidbody.velocity = speedLaw.Evaluate(timer / time) * direction * speedK;
Та ошибка, которая накапливается в методе интегрирования в сравнении с этим не такая большая из-за количества знаков в числах и огромного числа итераций. Метод трапеций просто был бы оптимальнее.
Но вообще там есть ещё один нюанс, если брать контекст Unity и Rigidbody, помимо скорости у объекта есть иннерция + действует сила трения, по этой причине тут тоже есть пара нюансов. В конкретной реализации в репозитории просто накинут материал, у которого коэффициент трения равен нулю, но строго говоря на нормальных поверхностях формула посложнее. Ну либо работать не c _RidigBody (или навешивать физические компоненты юнити после смещения) Это уже зависит от конкретной задачи
Да, классная. И вот она именно по теории и из неё можно взять все формулы. Мне хотелось в статье показать конкретные применения (скрипт для камеры и скрипт для перемещения объекта в конкретную точку с неравномерной скоростью в общем случае), чтобы в особенности новичкам было понятно, «а зачем эту самую теорию изучать?», и где она может пригодиться
Ну да, просто это всё же интегрирование. Так то да, через суммирование последовательности.
Есть очень много задач, про которые можно рассказать. Про звук и преобразования фурье, про жидкостные симуляции и комплексные числа, про метод конечных элементов и пластические деформации. Тут скорее вопрос в том, что я написал пока пробную простенькую статью, чтобы посмотреть интересна ли кому-то тема. Учитывая реализацию всего и вся на юнити и открытых исходников (нельзя юзать ничего, что не под GPL, MIT, Apache и подобными лицензиями), могу сказать что это достаточно трудоёмкий процесс.
Поэтому если тематика будет интересна в общем, то может возьмусь за задачки посложнее. С аффинными и TRS матрицами согласен, хотя на самом деле это тоже базовые вещи про которые не все знают. Или тот же линал и шейдеры.
Нет, это интегрирование функции скорости по времени по сути численным методом. Определённый интегралл от 0 до 1 по времени функции скорости. Если взять определённый интеграл от той же функции скорости, то мы получим тоже самое значение с точностью до ошибки.
По векторам примеры базовые, по тому как переместить объект по физическому распределению скорости (можно подобрать подходящую аналитическую функцию), как показывает практика — нет
Собственно об этом написано до ката. Возможно стоило вписать пример с физикой, а не вынести его в репозиторий. А так, эта статья именно для новичков, чтобы они знали что существует такой инструмент и представляли, как им можно пользоваться.
Совершенно верно. Возможно я слишком плохо написал название. Его суть в том, что мне надоело видеть в большинстве решений Physics.Raycast на физические объекты для банального hover'а мышкой, поэтому я написал статью о том, что есть такая великолепная штука, как EventSystem
Вообще ссылку я скинул выше. Я терпеть не могу монобеховские синглтоны, так как они требуют слишком много обвязки вокруг. Но скажем если взять пример клиента из моей статьи про Unet то, вот не монобеховский синглтон github.com/Nox7atra/Simple-Unity-Client-Server/blob/master/Assets/Scripts/Networking/Client.cs
В случае с монобеховским в том же репозитории есть не совсем синглтон, но шаблонный (я просто немного упростил пример выше, так как многопоточностью в коде и не пахло, а пример выше учитывает и её) Он находится в каталоге Utils
Даже забьём на то, что по идее нужно разрушать компонент, а в этом случае уничтожается геймобжект. Последний зашёл, значит ты и прав? Реиницилизация в каждой сцене где присутствует? Зачем?
Я вообще против синглтонов монобехов. Но если уж юзать, то есть вот такая реализация (в самом низу), она даже лочит где надо. wiki.unity3d.com/index.php/Singleton
Но в целом синглтоны монобехи не нужны в большинстве случаев. Да и не удобны в целом.
В Unity он просто менее опасен, так как там нечасто кто-то работает в много потоков. У самого паттерна есть очевидные плюсы и минусы. Основной при неправильном использовании — это нереальная связность системы. В случае многопоточности с синглтонами очень неудобно работать. Если забыть про дедлоки и сделать нормальные блокировки и т.п., то всё равно сложно отследить порядок морфирования при дебаге. Сингтлон просто позволяет меньше думать над тем, как архитектурно красиво прокинуть некоторые сервисы, которые скорее всего будут в единичном экземпляре. Я использую синглтоны часто, но это не отменяет огромного количества недостатков. Просто, на мой взгляд, основное преимущество — это скорость разработки. За которую правда придётся платить в будущем.
Не имеет места быть ни ваш, ни пример из статьи. Это просто не синглтоны. Так как с таким описанием класса я могу спокойно создать много инстанстов. А реализация выше творить будет вообще полный треш с точки зрения мусора. У синглтона должен быть приватный конструктор, как минимум. В случае монобеха, там всё вообще сложнее. А описанные реализации — это очень опасные и даже вредные конструкции.
С описанным ФЗ всё так, когда подписывается РИД, когда задания где-то фиксируются и т.п. Так как в противном случае нужно ещё доказать то, что данная интеллектуальная собственность была создана в процессе исполнения служебных обязанностей. Я про этот документооборот.
В ней нет открытий, откровений и прочего. И была написала исключительно из-за того, что очень часто встречается абсолютное непонимание того, зачем в целом нужно знать математику, и какие прикольные задачи можно решать с помощью неё. Я искренне верю, что многим в вузе неинтересно изучать математику, так как непонятно, а зачем нужны эти матрицы, интегралы и прочие довольно абстрактные вещи. Можно придраться и к тому, что интеграл — это совсем не площадь под кривой. Так как площадь под кривой — это лишь его геометрическое представление. Кратные и поверхностные интегралы уже так просто не опишешь
Можно вспомнить много численных методов, из популярных метод Симпсона ещё лучше, но тем не менее это не цель статьи, научить математике. На это в вузах по 4 года тратят. Интеграл нужен для вот такой-то задачи. Какой метод интегрирования подставить в GetApproxSquareAnimCurve — дело третье.
Так что в данном конкретном примере проблема во float. Но вообще точность float почти всегда будет хуже, чем вычисление подобными методами на достаточно большом количестве операций
_Rigidbody.velocity = speedLaw.Evaluate(timer / time) * direction * speedK;
Та ошибка, которая накапливается в методе интегрирования в сравнении с этим не такая большая из-за количества знаков в числах и огромного числа итераций. Метод трапеций просто был бы оптимальнее.
Но вообще там есть ещё один нюанс, если брать контекст Unity и Rigidbody, помимо скорости у объекта есть иннерция + действует сила трения, по этой причине тут тоже есть пара нюансов. В конкретной реализации в репозитории просто накинут материал, у которого коэффициент трения равен нулю, но строго говоря на нормальных поверхностях формула посложнее. Ну либо работать не c _RidigBody (или навешивать физические компоненты юнити после смещения) Это уже зависит от конкретной задачи
Есть очень много задач, про которые можно рассказать. Про звук и преобразования фурье, про жидкостные симуляции и комплексные числа, про метод конечных элементов и пластические деформации. Тут скорее вопрос в том, что я написал пока пробную простенькую статью, чтобы посмотреть интересна ли кому-то тема. Учитывая реализацию всего и вся на юнити и открытых исходников (нельзя юзать ничего, что не под GPL, MIT, Apache и подобными лицензиями), могу сказать что это достаточно трудоёмкий процесс.
Поэтому если тематика будет интересна в общем, то может возьмусь за задачки посложнее. С аффинными и TRS матрицами согласен, хотя на самом деле это тоже базовые вещи про которые не все знают. Или тот же линал и шейдеры.
По векторам примеры базовые, по тому как переместить объект по физическому распределению скорости (можно подобрать подходящую аналитическую функцию), как показывает практика — нет
github.com/Nox7atra/Simple-Unity-Client-Server/blob/master/Assets/Scripts/Networking/Client.cs
В случае с монобеховским в том же репозитории есть не совсем синглтон, но шаблонный (я просто немного упростил пример выше, так как многопоточностью в коде и не пахло, а пример выше учитывает и её) Он находится в каталоге Utils
Я вообще против синглтонов монобехов. Но если уж юзать, то есть вот такая реализация (в самом низу), она даже лочит где надо. wiki.unity3d.com/index.php/Singleton
Но в целом синглтоны монобехи не нужны в большинстве случаев. Да и не удобны в целом.