3. SWAP_EFFECTOR
Ну на словах тут все просто)
Выбираем пару клонов, и меняем их местами по позиции, размеру повороту.
Кол-во таких пар не ограниченно (наверное) :)
Добавил еще проектное превью, как это выглядит на рендере)
#MoPy
Ну на словах тут все просто)
Выбираем пару клонов, и меняем их местами по позиции, размеру повороту.
Кол-во таких пар не ограниченно (наверное) :)
Добавил еще проектное превью, как это выглядит на рендере)
#MoPy
🔥3
Media is too big
VIEW IN TELEGRAM
4. TRIGGER_EFFECTOR
Запускаем воспроизведение анимации только в момент триггера.
Появляется вопрос зачем, если подобное можно реализовать с помощью cloner(a) в режиме fixed
В режиме fixed скорость анимации зависит от степени влияния полей. Поэтому если поле двигается медленно или слишком быстро, то скорость анимации будет меняться соответственно, что иногда не подходит под задачу. Здесь же ничего не влияет на скорость анимации. Мы фиксируем момент с которого должна стартовать анимация и дальше она идет сама по себе.
Добавил 5 режимов
1 - Основная анимация остается до конца. Сброса не происходит
2 - Сброс сразу при выходе из зоны
3 - Клон доигрывает основную анимацию, затем сброс
4 - Клон доигрывает основную анимацию, затем реверс, затем сброс
5 - Реверс сразу при выходе из зоны
Сброс в данном случае отвечает за возможность перезаписать время триггера (полезно если клон попадает под воздействие триггера в сцене несколько раз)
#MoPy
Запускаем воспроизведение анимации только в момент триггера.
Появляется вопрос зачем, если подобное можно реализовать с помощью cloner(a) в режиме fixed
В режиме fixed скорость анимации зависит от степени влияния полей. Поэтому если поле двигается медленно или слишком быстро, то скорость анимации будет меняться соответственно, что иногда не подходит под задачу. Здесь же ничего не влияет на скорость анимации. Мы фиксируем момент с которого должна стартовать анимация и дальше она идет сама по себе.
Добавил 5 режимов
1 - Основная анимация остается до конца. Сброса не происходит
2 - Сброс сразу при выходе из зоны
3 - Клон доигрывает основную анимацию, затем сброс
4 - Клон доигрывает основную анимацию, затем реверс, затем сброс
5 - Реверс сразу при выходе из зоны
Сброс в данном случае отвечает за возможность перезаписать время триггера (полезно если клон попадает под воздействие триггера в сцене несколько раз)
#MoPy
🔥1
5. ROULETTE_EFFECTOR
Тут тоже на словах все просто. Пишем слово и вуаля!
Кол-во слов неограниченно)
#MoPy
Тут тоже на словах все просто. Пишем слово и вуаля!
Кол-во слов неограниченно)
#MoPy
❤1
Так же из каких-то простеньких эффекторов
1) Эффектор центрирования (раздвигает клоны от центра)
2) Эффектор вращения вокруг центра/ в данном случае мы получаем вращение из референсного объекта (надо доработать)
3) Random Weight - задает клонам рандомную последовательность выборки веса, длительность воздействия и промежутки выбора (по-хорошему надо доработать)
#MoPy
1) Эффектор центрирования (раздвигает клоны от центра)
2) Эффектор вращения вокруг центра/ в данном случае мы получаем вращение из референсного объекта (надо доработать)
3) Random Weight - задает клонам рандомную последовательность выборки веса, длительность воздействия и промежутки выбора (по-хорошему надо доработать)
#MoPy
❤1
Рома
2. PATH_EFFECTOR Сдвигает клоны по сегментам сплайна в зависимости от воздействия полей Для сдвига можно использовать как вес задаваемый отдельным эффектором, так и с помощью field list внутри эффектора. Можно использовать spline,mospline/spline mask и connect…
This media is not supported in your browser
VIEW IN TELEGRAM
Апдейт для PATH_EFFECTOR добавил возможность смещения по реальной дистанции
Рома
4. TRIGGER_EFFECTOR Запускаем воспроизведение анимации только в момент триггера. Появляется вопрос зачем, если подобное можно реализовать с помощью cloner(a) в режиме fixed В режиме fixed скорость анимации зависит от степени влияния полей. Поэтому если поле…
This media is not supported in your browser
VIEW IN TELEGRAM
Обновление для TRIGGER_EFFECTOR: добавил возможность работать с весами в режиме клонера fixed. Но веса сейчас также не влияют на длительность анимации, а просто триггерят её старт. Длительность также устанавливается в эффекторе. Из интересного можно получить вот такое слоумо)
#MoPy
#MoPy
Сейчас работаю над проектом и собрал две таких вариации по последовательному движению клонов. Обе завязаны на эффекторе PATH_OFFSET.
1ый просто использует режим distance (кол-во клонов = кол-ву сегментов сплайна)
2ой работает на триггере и передаче веса соседним (кол-во клонов = кол-ву сегментов сплайна) НО! Можно играться с visibility (возможно доработаю внутри кода)
Так же под эту задачу написал несколько python generator(ов):
1) Генерирует сплайн проходящий сквозь центр объекта (работает не превосходно, но для многих вариантов подходит)
2) Соединяет все сегменты сплайна. создавая полные пути от его начала и до конца (т.е условно 10 сегментов-10 сплайнов)
3) Если говорить простым языком, сортирует сегменты в зависимости от их удаленности от самого 1ого сегмента (вроде как работает, но конкретно для моей задачи это оказалось ненужным, поэтому пока на уровне сырого теста. Так же пока не могу додумать где и как это можно применить/использовать)
#PyGen #MoPy
1ый просто использует режим distance (кол-во клонов = кол-ву сегментов сплайна)
2ой работает на триггере и передаче веса соседним (кол-во клонов = кол-ву сегментов сплайна) НО! Можно играться с visibility (возможно доработаю внутри кода)
Так же под эту задачу написал несколько python generator(ов):
1) Генерирует сплайн проходящий сквозь центр объекта (работает не превосходно, но для многих вариантов подходит)
2) Соединяет все сегменты сплайна. создавая полные пути от его начала и до конца (т.е условно 10 сегментов-10 сплайнов)
3) Если говорить простым языком, сортирует сегменты в зависимости от их удаленности от самого 1ого сегмента (вроде как работает, но конкретно для моей задачи это оказалось ненужным, поэтому пока на уровне сырого теста. Так же пока не могу додумать где и как это можно применить/использовать)
#PyGen #MoPy
Media is too big
VIEW IN TELEGRAM
6. INHERITANCE_EFFECTOR
Перемещает матрицу одного mograph объекта к матрице другого в нужной нам последовательности
Сделал 2 версии:
1) Работает автономно
2) Работает через передачу веса сторонним эффектором
Хз как удобнее, по сути принцип один и тот же
Сейчас пока готов буквенный режим, в скором времени доработаю численный(сейчас он как бы тоже есть, но надо залазить в код, что не так удобно), и рандом. Заготовки уже есть, осталось скомпилировать
#MoPy
Перемещает матрицу одного mograph объекта к матрице другого в нужной нам последовательности
Сделал 2 версии:
1) Работает автономно
2) Работает через передачу веса сторонним эффектором
Хз как удобнее, по сути принцип один и тот же
Сейчас пока готов буквенный режим, в скором времени доработаю численный(сейчас он как бы тоже есть, но надо залазить в код, что не так удобно), и рандом. Заготовки уже есть, осталось скомпилировать
#MoPy
За отсутствием предложений решил поиграться с вычислением и группировкой сегментов "ветвистой" геометрии по уровням и подуровням. Очень удивился как нейронки на основе достаточно примитивных примеров могут строить очень сложные, а главное работающие структуры.
Попробовал 3 варианта:
1ый на основе интерсекции сегментов друг с другом (в основе синьковский bool)
2ой на основе расстояния между ближайшими точками сегментов
3ый на основе построения внутренних сплайнов
У всех 3ех есть как минусы, так и плюсы
1) На основе буля: достаточно долгий в обработке и при пересечении сегментов с "разных" веток, все условно попадает в одну сортировку,т.е уровни и подуровни могут вычисляться не всегда корректно. Из плюсов, пофиг на сетку
2) На основе точек: минусы +/- такие же, а из плюсов чуть быстрее, геометрия не обязательно должна проходить сквозь друг друга
3) На основе построения внутренних сплайнов: из минусов работает не с каждой сеткой, и хорошо работает с сегментами выходящими из одной точки (или почти), достаточно длинный код
Из плюсов: значительно быстрее остальных вариантов, т.к работает со сплайнами(т.е кол-во точек и различных проверок значительно меньше, более гибок, и как мне кажется наиболее точен
Пробовал еще метод, через создание bounding box, но этот способ работал наименее корректно
Попробовал 3 варианта:
1ый на основе интерсекции сегментов друг с другом (в основе синьковский bool)
2ой на основе расстояния между ближайшими точками сегментов
3ый на основе построения внутренних сплайнов
У всех 3ех есть как минусы, так и плюсы
1) На основе буля: достаточно долгий в обработке и при пересечении сегментов с "разных" веток, все условно попадает в одну сортировку,т.е уровни и подуровни могут вычисляться не всегда корректно. Из плюсов, пофиг на сетку
2) На основе точек: минусы +/- такие же, а из плюсов чуть быстрее, геометрия не обязательно должна проходить сквозь друг друга
3) На основе построения внутренних сплайнов: из минусов работает не с каждой сеткой, и хорошо работает с сегментами выходящими из одной точки (или почти), достаточно длинный код
Из плюсов: значительно быстрее остальных вариантов, т.к работает со сплайнами(т.е кол-во точек и различных проверок значительно меньше, более гибок, и как мне кажется наиболее точен
Пробовал еще метод, через создание bounding box, но этот способ работал наименее корректно
🔥1👀1
Скрипт 1: Волновое расширение по геометрической дистанции
Использует топологические соседства полигонов.
Для роста сегментов сравнивается расстояние между вершинами.
Прост в исполнении и быстро работает.
Эффективен для логических групп близких участков, но не учитывает реальную форму объектов.
Хорошо подходит для геометрических "кластеров".
✅ Скрипт 2: Расширение по Boolean-пересечениям
Строит PolygonObject'ы для каждого сегмента и проверяет пересечение через Oboole.
Очень точный, так как учитывает реальную форму.
Использует AABB оптимизацию и кэш пересечений для ускорения.
Главный минус — медленная работа при большом числе сегментов из-за Boolean-операций.
Подходит, если важна точность пересечений (например, для физически пересекающихся мешей).
✅ Скрипт 3:
Управление по углу, глубине, ветвям, и направлению.
Подходит для автоматической генерации путей/веток
Выдаёт сплайн как результат, а не просто выделение.
Самый сложный в логике, но и самый гибкий.
Это что говорят нейронки
Использует топологические соседства полигонов.
Для роста сегментов сравнивается расстояние между вершинами.
Прост в исполнении и быстро работает.
Эффективен для логических групп близких участков, но не учитывает реальную форму объектов.
Хорошо подходит для геометрических "кластеров".
✅ Скрипт 2: Расширение по Boolean-пересечениям
Строит PolygonObject'ы для каждого сегмента и проверяет пересечение через Oboole.
Очень точный, так как учитывает реальную форму.
Использует AABB оптимизацию и кэш пересечений для ускорения.
Главный минус — медленная работа при большом числе сегментов из-за Boolean-операций.
Подходит, если важна точность пересечений (например, для физически пересекающихся мешей).
✅ Скрипт 3:
Управление по углу, глубине, ветвям, и направлению.
Подходит для автоматической генерации путей/веток
Выдаёт сплайн как результат, а не просто выделение.
Самый сложный в логике, но и самый гибкий.
Это что говорят нейронки
👍2
Могу прикреплять/скидывать файлы для тестов или как-то иначе записывать, просто пока особо фидбека нет, поэтому выглядит больше как отчет)
🔥3
Если у кого-то возникают интересные идеи или хотелось бы добавить в синему какой-то инструмент, дайте знать. Организуем!)
🆒1
Media is too big
VIEW IN TELEGRAM
Дорабатываю свой вариант:
1)Добавил поддержку поиска подуровней с любой части уровня. (Раньше поиск был только с последней точки уровня😅)
2) Улучшил логику поиска подуровней, чтобы почти гарантировано избегать неточностей при пересечениях.
В коде, конечно, полная жопа) может когда-то подкорректирую, но пока остановлюсь, т.к в целом меня все устраивает, а смысл в дальнейших доработках вижу уже только под какие-то конкретные задачи
Вот основные шаги, которые использовались в ходе работы
1) Поиск связанных полигонов (сегментов)
2) Получение центр. точек сегментов и создание сплайнов на основе uv
3) Поиск связей и построение иерархии у сегментов
4) Сортировка сегментов сплайна по иерархии
5) Создание фин. сплайна и selection(а) из выборки
Код получился на 450 строк)
1)Добавил поддержку поиска подуровней с любой части уровня. (Раньше поиск был только с последней точки уровня😅)
2) Улучшил логику поиска подуровней, чтобы почти гарантировано избегать неточностей при пересечениях.
В коде, конечно, полная жопа) может когда-то подкорректирую, но пока остановлюсь, т.к в целом меня все устраивает, а смысл в дальнейших доработках вижу уже только под какие-то конкретные задачи
Вот основные шаги, которые использовались в ходе работы
1) Поиск связанных полигонов (сегментов)
2) Получение центр. точек сегментов и создание сплайнов на основе uv
3) Поиск связей и построение иерархии у сегментов
4) Сортировка сегментов сплайна по иерархии
5) Создание фин. сплайна и selection(а) из выборки
Код получился на 450 строк)
🔥5❤2👌1