Просто не надо забывать, что 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 он просто менее опасен, так как там нечасто кто-то работает в много потоков. У самого паттерна есть очевидные плюсы и минусы. Основной при неправильном использовании — это нереальная связность системы. В случае многопоточности с синглтонами очень неудобно работать. Если забыть про дедлоки и сделать нормальные блокировки и т.п., то всё равно сложно отследить порядок морфирования при дебаге. Сингтлон просто позволяет меньше думать над тем, как архитектурно красиво прокинуть некоторые сервисы, которые скорее всего будут в единичном экземпляре. Я использую синглтоны часто, но это не отменяет огромного количества недостатков. Просто, на мой взгляд, основное преимущество — это скорость разработки. За которую правда придётся платить в будущем.
Не имеет места быть ни ваш, ни пример из статьи. Это просто не синглтоны. Так как с таким описанием класса я могу спокойно создать много инстанстов. А реализация выше творить будет вообще полный треш с точки зрения мусора. У синглтона должен быть приватный конструктор, как минимум. В случае монобеха, там всё вообще сложнее. А описанные реализации — это очень опасные и даже вредные конструкции.
С описанным ФЗ всё так, когда подписывается РИД, когда задания где-то фиксируются и т.п. Так как в противном случае нужно ещё доказать то, что данная интеллектуальная собственность была создана в процессе исполнения служебных обязанностей. Я про этот документооборот.
Устная договоренность часто ничего не значит, то что в бумаге за подписью стоит — это важно. Но и тут нюанс, под роспись ознакамливаешься с документом, а по факту расписался за «другую» редакцию.
Конечно же она ничего не значит, я просто сужу по множеству моих мест работы, где всё было на устных договорённостях и всё было нормально. Конечно лучше, когда всё правильно, так как всё просто и всем всё понятно.
Интеллектуальной собственностью(ИС) работника обладает работодатель, если это было служебным заданием(срок 3 года, потом эксклюзивные права возвращаются автору). Есть ещё авторское вознаграждение, за использование ИС, это отдельной статьей. Никаких проблем получить ИС сотрудника не вижу.
Вообще не совсем, так как этого недостаточно. Должен быть подписан набор документов, в том числе отчуждения всякие. Часто неправильно составлено NDA. Причём смотря о каких правах говорить. Авторские права передать нельзя, а вот для права на использование, там да. Но тут ещё вопрос того, что если не подписать отчуждение в пользу юр. лица (или если оно не прописано нигде), то тогда в целом автор может этот код использовать где угодно.
А проблема в том, что если работа не проектная, в нормальный режим работы компании не везде на подпись приносят документы связанные с этим. Так как «служебное задание» и т.п. — это же не в устной форме данное указание. И для стартапа скажем это всё слишком геморно, да и не нужно в большинстве случаев.
Если речь обо мне, то у меня узкая специализация, в моём городе горстка компаний подобной в топике с «эффективными менеджерами».
Это да, тут я не прав, прошу прощения. Просто удалёнки или вариантов релокации много, но не всем нравится удалёнка и хочется куда-то переезжать.
_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
Но в целом синглтоны монобехи не нужны в большинстве случаев. Да и не удобны в целом.
Разве project Oxford, который сейчас Microsoft Cognitive Services не тоже самое делает? Ну хотя может вопрос в точности.
Конечно же она ничего не значит, я просто сужу по множеству моих мест работы, где всё было на устных договорённостях и всё было нормально. Конечно лучше, когда всё правильно, так как всё просто и всем всё понятно.
Вообще не совсем, так как этого недостаточно. Должен быть подписан набор документов, в том числе отчуждения всякие. Часто неправильно составлено NDA. Причём смотря о каких правах говорить. Авторские права передать нельзя, а вот для права на использование, там да. Но тут ещё вопрос того, что если не подписать отчуждение в пользу юр. лица (или если оно не прописано нигде), то тогда в целом автор может этот код использовать где угодно.
А проблема в том, что если работа не проектная, в нормальный режим работы компании не везде на подпись приносят документы связанные с этим. Так как «служебное задание» и т.п. — это же не в устной форме данное указание. И для стартапа скажем это всё слишком геморно, да и не нужно в большинстве случаев.
Это да, тут я не прав, прошу прощения. Просто удалёнки или вариантов релокации много, но не всем нравится удалёнка и хочется куда-то переезжать.