Ох, если бы я знал. )
Очень много кода и материала, причем приходится постоянно проводить research и иногда переписывать нафиг куски кода. Тут, похоже, процесс важен не менее, чем результат.
Ну, тогда можно сделать каждую голову (уже с глазами) отдельным префабом, а в WormSkins хранить массив этих префабов. Идея в том, чтобы не хранить все головы в префабе, который будет создан на сцене.
И в отдельной ветке:
Про скины к червю и их реализации. Есть более красивое решение, которое, к тому-же, аккуратнее кастомизируется и не подразумевает создание кучи объектов:
Создаем новый класс WormSkins, наследуемый от ScriptableObject'а
В WormSkins делаем SerializeField массивы для голов, хвостов и тд:
[SerializeField] Sprite[] heads;
Делаем геттеры (точнее, функции-геттеры, т.к по индексу берем):
Sprite GetHead(int index)
Создаем в ассетах экземпляр этого класса (пункт 2)
Прописываем в нём все головы, хвосты и т.д.
Оставляем ссылку на этот экземпляр в префабе червя, в том классе, где у вас сейчас кастомизация происходит (или как-то более красиво, тут много вариантов)
Оставляем в черве только одну голову, один хвост и тд, без указанного спрайта
При запуске берем индекс из пользовательских настроек, получаем спрайт из WormSkins и засовываем его в нужный SpriteRenderer
По идее, лучше использовать не индексы, а уникальные id, которые самостоятельно прописываются для спрайта (не знаю, насколько хорошо делать его текстовым или привязываться к имени самого спрайта). В этом случае скин игрока не поедет при добавлении нового элемента в начало.
Спасибо за хорошую статью, их по unity3d не так уж много теперь.
Не думали использовать сплайны для создания тела червя? Ключевые точки все известны, можно построить Mesh используя их, а в unity3d есть удобный [AnimationCurve](https://docs.unity3d.com/ScriptReference/AnimationCurve.html, с помощью которого можно рассчитать сплайн.
Да, в Токи Поне всё очень контекстуально. Зато какой потрясающе формализуемый синтаксис! Меня, как программиста, он в своё время очень порадовал, но практического применения я не нашел: не превращать же её в ещё один эзотерический язык программирования.
Знаете, а я накосячил в статье. Изначально, действительно, работал только с верхней полусферой, но в какой-то момент оказалось, что свет получается не очень естественный. Причем, т.к непрямое освещение не использует raycast'инг, а берет направления из прямого освещения, пришлось работать со всей сферой целиком.
На самом деле, от своих знакомых я получал в том числе и такой фидбек:
"Красивые картинки, но ни черта не понятно";
"Картинок и текста много, а вот кода не хватает, было бы круто выложить код шейдеров и кое-каких классов";
"Очень не хватает uml диаграммы или чего-то подобного, чтобы понять в целом структуру проекта";
"Очень сухой стиль изложения и много ненужных подробностей, как в курсовой работе".
Так что есть над чем работать и именно для этого нужны прям конкретные (и, может быть, злые) замечания :)
Я примерно трижды прочел ваш комментарий, и, к своему стыду, так и не понял идею алгоритма. :(
Вы не могли бы как-нибудь визуализировать (да хоть на листке бумаги) его? Заранее спасибо большущее.
Нет, если бы я хотел себя нахваливать, мог бы и без статей обойтись. А сюда пришел поделится опытом и получить фидбек (потому что иногда возникает ощущение, что делаю какую то хрень :) ).
Но спасибо за комплимент.
Кстати, неплохая идея. Интересно только, как обеспечить всего 2 текстуры: по идее, для каждого динамического объекта придется считать отдельную текстуру, разве нет?
Да, читал вашу статью, когда начинал этот проект :)
Возможно, если сделать свет более дискретным (round(lightValue * 5) / 5), мне может подойти normalMapping. Но мне кажется, в динамике даже нескольких уровней будет достаточно глазу, чтобы заметить градиентное мыло.
Думал над таким вариантом: делать очень дискретную normal map, всего с несколькими уровнями. А результат normalMapping'а искусственно зашумлять.
Ох, если бы я знал. )
Очень много кода и материала, причем приходится постоянно проводить research и иногда переписывать нафиг куски кода. Тут, похоже, процесс важен не менее, чем результат.
Да, вот только всему этому придется игроку учится самому — слишком много взаимодействий. Но для уровней песочниц — идеально.
Да! Там действительно очень много забавных взаимодействий — и с кипением и с замерзанием. Из моих любимых идей:
И что самое приятное — каждый новый модуль добавляет (если это прорабатывать) не 1 взаимодействие, а N — 1 :)
Тогда возникает вопрос — если сделать это физичным — не потеряет ли в фановости? )
Но в любом случае, можно запилить и потом править коэффициенты.
Хм, можно подработать формулы так, чтобы передача теплоты вниз была медленнее, чем вверх.
Вы не могли бы переупорядочить изображения в результатах сегментации?
Сейчас для каждого метода в своём порядке, сложно ориентироваться :(
Ну, тогда можно сделать каждую голову (уже с глазами) отдельным префабом, а в WormSkins хранить массив этих префабов. Идея в том, чтобы не хранить все головы в префабе, который будет создан на сцене.
И в отдельной ветке:
Про скины к червю и их реализации. Есть более красивое решение, которое, к тому-же, аккуратнее кастомизируется и не подразумевает создание кучи объектов:
По идее, лучше использовать не индексы, а уникальные id, которые самостоятельно прописываются для спрайта (не знаю, насколько хорошо делать его текстовым или привязываться к имени самого спрайта). В этом случае скин игрока не поедет при добавлении нового элемента в начало.
Спасибо за хорошую статью, их по unity3d не так уж много теперь.
Не думали использовать сплайны для создания тела червя? Ключевые точки все известны, можно построить Mesh используя их, а в unity3d есть удобный [AnimationCurve](https://docs.unity3d.com/ScriptReference/AnimationCurve.html, с помощью которого можно рассчитать сплайн.
Ну, можно и так сказать. Но в AO ведь рассчитывается только прямая освещенность точки? В то время как тут учитываются переотражения.
Знаете, а я накосячил в статье. Изначально, действительно, работал только с верхней полусферой, но в какой-то момент оказалось, что свет получается не очень естественный. Причем, т.к непрямое освещение не использует raycast'инг, а берет направления из прямого освещения, пришлось работать со всей сферой целиком.
Вот так получается при сфере:
А вот так при полусфере:
Спасибо за комментарий, подправлю текст статьи :)
Пока нет, к сожалению. Сейчас доделываю воду, в следующей статье будет много видео. Постараюсь показать этот момент.
На самом деле, от своих знакомых я получал в том числе и такой фидбек:
"Красивые картинки, но ни черта не понятно";
"Картинок и текста много, а вот кода не хватает, было бы круто выложить код шейдеров и кое-каких классов";
"Очень не хватает uml диаграммы или чего-то подобного, чтобы понять в целом структуру проекта";
"Очень сухой стиль изложения и много ненужных подробностей, как в курсовой работе".
Так что есть над чем работать и именно для этого нужны прям конкретные (и, может быть, злые) замечания :)
Я примерно трижды прочел ваш комментарий, и, к своему стыду, так и не понял идею алгоритма. :(
Вы не могли бы как-нибудь визуализировать (да хоть на листке бумаги) его? Заранее спасибо большущее.
Нет, если бы я хотел себя нахваливать, мог бы и без статей обойтись. А сюда пришел поделится опытом и получить фидбек (потому что иногда возникает ощущение, что делаю какую то хрень :) ).
Но спасибо за комплимент.
Кстати, неплохая идея. Интересно только, как обеспечить всего 2 текстуры: по идее, для каждого динамического объекта придется считать отдельную текстуру, разве нет?
Пробовал пару лет назад что-то подобное :)
Да, читал вашу статью, когда начинал этот проект :)
Возможно, если сделать свет более дискретным (round(lightValue * 5) / 5), мне может подойти normalMapping. Но мне кажется, в динамике даже нескольких уровней будет достаточно глазу, чтобы заметить градиентное мыло.
Думал над таким вариантом: делать очень дискретную normal map, всего с несколькими уровнями. А результат normalMapping'а искусственно зашумлять.