Название файла, в котором находятся классы можно увидеть справа от кода (вертикально). Но их можно располагать как душе угодно, кроме конечно MonoBehaviour и ScriptableObject (они должны быть в файлах с таким же названием). Кроме того, весь проект можно скачать на Boosty или Patreon без подписки (см. описание к видео)
Нет, он поддерживает и прямой вызов методов (под капотом там используется FunctionPointer). Там же в документации: docs.unity3d.com/Packages/com.unity.burst@1.8/manual/csharp-calling-burst-code.html
Где это использовать? Например, я хочу свою генерацию мира как в майнкрафте переписать под такое, чтобы чанки не создавались отдельными объектами. Подойдет ли этот способ для такого?
Использовать можно в любой ситуации, включая и чанки мира. Просто следует помнить, что в этом случае затрудняется отладка, так как созданные объекты не отображаются в окне иерархии.
@@arturberkgames У Вас опыта видно больше, чем у меня. Это имеет смысл вообще? Просто мне кажется, что юнити немного тяжело каждый раз взаимодействовать с тысячами объектов. Просто хранить в отдельном классе позицию чанка, его модель и список с блоками, вместо отдельного объекта с отдельным скриптом для этого. И отрисовывать эти чанки из массива, как в видео
@@AlexanderGusev-p6x GameObject-ы предоставляют удобный функционал: иерархии, компоненты, функции жизненного цикла, редактирование в редакторе, сериализация. Если этот функционал не нужен и объектов реально тысячи, то можно задуматься. Иногда отказаться от GO вообще не получиться, например, если нужна встроенная физика, коллайдер не создашь без GO.
Вроде все правильно написал, но выдает ошибку в foreach (var heightmapModifier in heightmapModifiers), говорит, что Оператор foreach не работает с переменными типа “lHeightmapModifier", так как “lHeightmapModifier" не содержит открытое определение экземпляра или расширения для “GetEnumerator", еще аргумент 2: не удается преобразовать из “lHeightmapModifier" в “lHeightmapModifier[]", и еще Оператор foreach не работает с переменными типа “lHeightmapModifier", так как “lHeightmapModifier" не содержит открытое определение экземпляра или расширения для “GetEnumerator". Эти три ошибки идут подряд начиная с первого foreach и заканчивая на втором, все три heightmapModifiers подсвечены красным.
Скорее всего вместо GetComponentsInChildren используете метод GetComponentInChildren, который возвращает не массив, а только первый модификатор. Если что, все проекты к видео есть на Boosty (к этому видео: boosty.to/arturberk/posts/6cce2f5d-d596-4e6a-a8a5-7b8597fd75bc)
А юнити получается тоже самое делает под капотом ? И уже сам шейдер проводит отсечение мешей которые не видно камере. Увеличится ли производительность если я таким способом буду отрисовывать большой уровень платформера буквально заменив своим скриптом кучу gameobjects ? По идее должно, если только меш рендерер как то сам не определяет рисовать ему или нет
При вызове Graphics.DrawMesh (но не DrawMeshNow) отрисовка "встраивается" в нормальный механизм отрисовки мешей, т.е. полностью соответствует тому, как рисует меши MeshRenderer (согласно документации). Таким образом можно избавиться от использования GameObject, что конечно положительно скажется на использовании памяти и времени старта сцены. Сама скорость отрисовки мешей если и изменится, то незначительно, особенно если объекты не двигаются и не требуется пересчитывать матрицы трансформации. Видео немного устарело, сейчас лучше пользоваться методами Graphics.Render... (Graphics.RenderMesh в нашем случае)
Збст. Захотел поправить существующие шейдеры в юнити, понял что без какого либо понимания базовых вещей не обойтись, сижу впитываю, конечно посматривая ещё и в офф доку ) Спс за труд !
Пока писать под URP и HDRP шейдеры с освещением и другими функциями кодом сложно, все заточено под Shader Graph. Shader Graph в принципе удовлетворяет основные запросы по созданию шейдеров. Например, в URP нет удобного способа создать шейдер с освещением, как Surface Shader в BIRP. Также для написания шейдеров на URP используется язык HLSL вместо CG. Это не значит, что CG шейдеры не поддерживаются (компилируются то они в одно и тоже). Но используется другая библиотека базовых функций (трансформация, сэмплинг текстур и т.д.).
В этом примере есть 1 существенный недостаток. Который к сожалению я еще не выяснил как пофиксить. Если вы создадите 10 обьектов на сцене, и инициализируете систему. То как только вы удалите 3-4 элемента не по порядку, а например 10, 8, 5, 3. Вы получите Missing Reference Exception на строку updatables[i].Updatable();. И порядок выполнения так же потеряется. Если кто-то знает как починить подскажите
Привет, подскажи, пожалуйста! Хочу сделать невидимый объект, но на который падали бы тени, принцип понимаю, но никак реализовать не могу ни стандартными инструментами Unity, ни через шейдеры - ничего не получается. Хочу сделать механику как в disco elysium, где основная локация - одна большая текстура, но рилтайм тени падают на лоупольные объекты окружения.
Вот что-то подобное для BIRP: gist.github.com/ArturBerk/ba241b129d5e7c66604b34a74907a0e7 Но скорее всего в этом случае лучше реализовать экранные тени. Рисовать тени постэффектом на основе буфера глубины.
@@arturberkgames спасибо! на BIRP работает, на URP пытался переписать, но ругается на "Redefinition of _Time", поиски показали, что это связано с #include "Packages/com.unity.render-pipelines.lightweight/ShaderLibrary/Lighting.hlsl"
Привет! У меня появились мысли, которые подошли бы для нового видео. Сделай видос о SDF и всё что с этим связано. Там куча тем и было бы круто узнать от тебя о их имплементации
This is the best procedural animation controller i ever seen , so smooth and flexible, but there are some issues, when walking on inclined surface , the movement directions changes , i could fix that , but i wanted to be able to walk on slope and climb walls , i could not align the MovementTarget rotation to the ray hit normal, can you help me please ?
Более корректно получается осуществлять вращения не через Rigidbody , а через ConfigurableJoint , так же вычисляем вращения целевых объектов анимационной модели , за которой Active Ragdoll повторяет вращения :ConfigurableJoint joint ; var lookRotation = Quaternion.inverse(Target.rotation); joint.targetRotation = Quaternion.LookRotation(lookRotation); А можно все мышцы - Configurablejoint сделать массивом и так же массив из целевых объектов вращения и при помощи итератора for из одного класса управлять поведением Active ragdoll
Вместо увеличения Drag нужно считать силы через пид контроллер. При использовании драга модель будет плавать как в воде при отключении следования. Для перемещения частей где нет RB можно использовать простой transform.
Совершенно согласен. Просто drag + сила - это и есть простейший ПИД контроллер без интегрирующей составляющей. Но в реальном проекте конечно лучше использовать более гибкое решение.
Привет, крутецкое видео, как и всегда. Не поможешь с больной для меня темой, а именно перевода векторов в трансформе с float на double? На данный момент просто сделал отдельный тип Vector3D и в нем implicit и explicit конвертацию в обычный Vector3, но душа просит большего. -)
Наткнулся недавно на такой проект: github.com/Unity-Technologies/com.unity.gis.high-precision-framework. Позволяет вместо обычного компонента Transform использовать HPTransform, который построен на 64-битных числах с плав. запятой. Сам не пробовал, но вдруг чем-то поможет.
Есть такой ассет - Odin Inspector. Ассет популярный, позволяет облегчить и улучшить написание редакторов. И здесь я просто попробовал показать один из способов того, как можно повторить его функционал на простейшем примере с кнопкой. Заодно показал использование Reflection и кодогенерации на конкретном примере.
@@dmitriypermyakov5402, а вот и зря, Odin Inspector очень полезный инструмент и сильно экономит время, если нужно делать кастомные окна и инспекторы в Unity Editor
Я делал для кнопок PropertyDrawer для bool переменных. [Button("Name", "MethodName")] [SerializableField] bool testButton; Минус в том приходится переменную создавать которая будет сериализоваться зря. Но не нужно генерировать код, не нужно эдитор создавать для компонента т.к. это может конфликтовать с другими эдиторами, если другие аттрибуты будут, то и для них не придётся дописывать код в генератор, и будет работать всегда.
Хороший подход для решения этой задачи. Я же, например, просто купил Odin Inspector и получил это и многое другое за разумную плату. И сразу возникла идея оценить, как можно повторить его функционал. А заодно рассмотреть использование Reflection, кодогенерации на конкретном примере.
Динамическая компиляция что то новое для меня ))) Обычно мои полномочия заканчивались на сборе атрибутов рефлексией, а тут оказывается можно на лету дорисовывать логику .. круто, это наталкивает на размышления, СПС))
Да конечно, [ContextMenu] подходит для вызова метода. Но цель была посмотреть, как сделать что-то подобное OdinInspector-у. Просто была выбрана именно кнопка для метода для примера. Но можно и другой функционал повторить на базе этого небольшого примера. Например условие на C# появления кнопки.
Попадалось в топиках Юнити форума сравнение GetComponent и TryGetComponent, с выводами, что второй предпочтительнее и быстрее ? Что думаешь по этому поводу?
