Спасибо! Про смену дня и ночи кстати есть старый видос на канале, как же давно я его снимал ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-5i-XCz_GQT4.html
Много условий для нахождения blockType, это, конечно, весело, но можно ведь айдишники блоков использовать и их порядок на большой текстуре, чтобы без условий, через остатки от деления (на кол-во блоков в одном ряду текстуры) прибавлять нужный uv в зависимости от id блока и его позиции на текстуре. Так мы обойдёмся одной простенькой функцией, и не нужно будет отдельно проверять каждый вид блока
а лучше гибридный вариант, чтобы простые блоки находились по id (умножение uv на id), а у сложных блоков чтобы была возможность брать по кастомным uv в коде этого блока
@@чибзик да, но в таком случае, скорее всего, придётся отделить простые текстуры от сложных, чтобы id не сбивался из-за разного количество текстур и самих блоков
Почему бы для типа блока из еnum использовать полноценный объект. Например Grass = {upUv: {x: 32, y: 16}, sideUv: {x: 16, y: 16}} Тогда создатель координат не будет думать о типе координат просто прочтёт из объекта который ему дали. В остальном спасибо что напомнил про щейдеры :) Когда то я тоже с ними игрался. Только вот аудитории это очень плохо заходит. Программирование шейдеров похоже на магию.
Привет. Хотелось бы добавить, что для определения позиций блоков лучше пользоваться не относительно разрешения текстуры и пикселей, а относительно сетки. Тогда можно будет легко изменять код, если разрешение текстуры меняется или сетка
У масштаба в таком виде проблема: боковая текстура травы относительно верхушки правильно рисуется только каждые 4 блока. В остальных случаях там рисуется та часть, которая больше похожа на землю. Возможно, могут возникнуть проблемы и с другими блоками, где разные стороны имеют разные текстуры
Ця гра нагадує мені таку гру, як Scrap Mechanic(За механікою маленьких блоків). Эта игра напоминает мне такую игру как Scrap Mechanic (За механикой маленьких блоков). Спасибо за интересные видео ^>^
Интересная задумка, но проще и красивее по стандарту использовать цельные текстуры для цельных блоков, но просто перерисовать их в соответствии с желаемым масштабом. Например, 4х4 текстура и блоки в 4 раза меньше в коде (хотя проще размер персонажа увеличить в 4 раза). Так и вычислений на видеокарту меньше ложится, и код везде понятнее, и боковая текстура травы адекватнее выглядит, и видеопамяти меньше занято. В идеале вообще наслайсить текстуры в Texture2DArray, чтобы не вычислять uv каждой текстуры, а просто передавать индекс текстуры через uv2. В шейдере благодаря встроенным функциям Unity это требует замены лишь нескольких строк кода, зато удобства привносит - хоть отбавляй.
Спасибо за видео. Можешь добавить USDT в TRC20 или в BEP20 кошелёк в описание, а то очень неприятно платить комиссию в 3.2 USDT. И немного по поводу блоков - не знаю будешь ли ты менять это потом или нет, но я бы убрал нафиг enum и добавил бы класс блока, в котором лежало бы его название и текстуры на все его стороны, а то сейчас нельзя добавить блок с уникальными сторонами ну и получается, что нам для каждого блока надо прописывать магические цифры отступа в коде (лучше их всё-таки в инспекторе прописывать) И часть 4, а не 3)
Спасибо, часть поправил, с кошельком разберусь и добавлю) В 6-й части почти так и сделаю, чтобы можно было добавлять разные типы блоков с разными сторонами. А после этого верну всё обратно к захардкоженым значениям, в частях где оптимизацией будем заниматься
@@sergio_nikol согласен, 6 эпизод будет про скриптаблы, как раз там эти координаты туда вынесем. Хожу тут по комментариям, разбрасываю спойлеры на следующие части)
@@EmeraldPowder хех :) Я бы кстати еще для оптимизации не делил бы на 256, а умножал на 0,0625 если таймпапа 16*16. Деление все-таки дорого стоит, а умножение проще. И координаты будет проще передавать: 0/15. 5/15 и т.д. :)
добавь шум на массив блоков травы, что бы блоки отличались оттенками, да и в данном случае я думаю лишним делать боковую текстуру для травы учитывая размер блоков, лучше оставь как сверху так и сбоку текстуру травы, а уже под этой травой блоки с цельной текстурой земли. можно добавить вкрапление блоков камня, земли на верхнем слое
Очень мощный и плотный урок по изучение шейдеров. Да еще и на реальном примере. Я как то смотрел как именно программируют шейдеры, но там было что то невероятно сложное и непонятное для моего уровня. Тем более когда в шкиле прогуливал геометрию и математику. Да и в институте тоже прогуливал, хотя почему то очень нравилось теория вероятностей. В общем не математического склада ума. После этого опыта шейдеры всегда обходил стороной. Но после этого материала понял, что все же стоит изучить эту тему, и научиться писать шейдеры. Весьма полезно и интересно. Плюс видимо есть много готовых решений для изучения. Еще раз благодарствую и низкий Одзиги.
Рад стараться) Меня тоже пугали когда-то шейдеры, потому что там все в статьях делали какие-то модели освещения, отражения, тени, и прочее. Но в какой-то момент я понял что это конечно всё хорошо, но шейдеры можно использовать чтобы просто делать всякие эффекты, вроде этого, или там плавную заливку, уход в невидимость, сгорание, и сразу стало понятнее зачем и что это
Привет, всё очень круто делаешь спасибо за туториалы. У меня есть одна просьба, не мог бы ты прикреплять весь код из туториала к видео(так было бы гораздо удобнее)?
@@tiny_tin либо ещё вариант сделать сразу большие блоки из который уже можно будет выдалбливать какие-то элементы, но мне первый вариант больше нравится
Мне кажется лучше было бы сделать как в моде chisels&bits для того же майнкрафта: руками ставится один большой блок, но с помощью инструмента можно его разбирать на более маленькие (там вроде они в 16 раз меньше стандартных блоков)
@@tatovka5209 наверное можно сохранить массив блоков чанка с помощью json (сначала создать Спомогательный класс который будет хранить значения массива, потом сохранять это значение класса в файл с помощью json utility)
Не рекламы ради, а примера для: Есть игрушка, "Vintage Story", довольно таки хардкорный майнкрафт, где есть это самое разделение блока на мелкие части. Когда ты с одного блока "выпиливаешь" себе вазу, или лейку по слоям из блока глины, чтоб потом ее запечь в костре. Или выпиливаешь из камня наконечник для копья или ножа, чтобы уже пользоваться готовым предметом как надо)) Довольно таки забавно...
Ну во первых - костыль с мнением, что могут быть только перпендикулярные стороны - медвежья услуга самому себе) Ну и во вторых - с боковинами травы поторопился) и в целом надо бы на шейдер куда больше времени потратить чтобы сделать скейлы более интелектуальными) Ну и в третьих - классное видео, лайк в копилку
С боковинами да, но их текстурой можно поправить, в каком-нибудь из следующих видео поправлю) А вот про стороны тут я точно уверен что у меня не перпендикулярных не будет, там если с ними бороться то надо ещё наверное такой же видос на пол часа записывать
Ну впринципе майнкрафт уже готов, осталось добавить сервак. Спавн пресетов из блоков в виде массива кубиков поверх верхних блоков. И поиграться с процедуркой типо пещер, все это еще снхронизировать через сервер. Крутая работа. Даешь волну майнкрафт проектов по всему русскому геймдеву)
Кстати тут не так уж и сложно было бы добавить онлайн, пока нет всяких печек, айтемов, и пвп. Но я всё же не буду, пока будет больше про процедурную генерацию и оптимизацию)
В самом майне такой мод есть, называется chunk animator. Он кстати даже несколько улучшает загрузку чанков, но тут уже хз за счёт самого ли эффекта, или там "бонусом" ещё патч на оптимизацию
не настолько) в том же майнкрафте заранее заготовленные деревья размещаются в рандомных местах. Другое дело сделать рандомную генерацию каждого дерева от корня к веткам, и еще чтобы росли во время игры. Вот это было бы интересно)
Это конечно хорошо, но это чудо надо оптимизировать. Генерация мэша заново занимает 300 мс времени, ещё больше если пробовать на мобильном устройстве. Даже нет идей как это оптимизировать, может можно повозиться с compute shaders?
Нужно сделать шаблоны, такими маленькими блоками что-то строит сложно. Например делаешь блок на 5 на 5 на 5 и сохраняешь в шаблоны и пользуешься и за один такой блок с инвентаря отнимается 125 маленьких блоков.
Потрясающий урок! Спасибо вам!) P.S. - У меня не получается довести дело из этого видео до финала, а именно трава в конце видео. При передаче в AddUvs типа блока Grass - все чанки генерируются так, будто передали неизвестный тип блока. (искал ошибку, пересматривал видео, но все-равно не могу понять почему не выходит как на видео.... помогите кто-нибудь разобраться, пожалуйста)
20:23 По сути текстура травы сломана так как верх боковой текстуры должен всегда касаться верхней текстуры что происходит не всегда. Ещё интересно как бы выглядела в такой системе текстур установка блоков по типу верстака, он бы тоже был сдвинут куда-то?
Ага, ниже уже писал, там по моему плану надо было боковую текстуру травы нарисовать в 4 строчки, чтобы каждые 4 пикселя по вертикали были как будто свисает трава сверху блока, тогда будет хорошо смотреться. Ну и конечно надо ещё логику как в Майне сделать чтобы только верхний блок был травой, а нижние становились землёй
Тут явно надо как то делать автовыбор тайла. Какой то конфиг для текстуры что ли (в случае с травой и боковушками так придется). Я так понимаю что всякие печки и верстаки это все таки будут отдельные блоки, а не часть меша? Или таки встраивать в меш, и вешать типа коллайдер для взаимодействия с игроков при нажатии
Записал заранее, да. Но там дальше будут видосы с оптимизацией, там toarray уберем, и глаза будут болеть только от того что наоборот слишком оптимизированно)
А можно обойтись юез кучи условий при определении того, какой блок генерить? Например посчитать в атласе текстуры только первый блок, а потом умножать его на нужный(если я правильно помню то, что енам возвращает число). Ну или как-то так
Можно и так, да, enum это число, так что если в текстуре просто по порядку расположить все блоки, и задать типам такие же id'шники, можно будет брать тайл по номеру. Но пока у меня тут всё в работе и ещё несколько раз переделается эта система, я текстуру хотел по миниму редактировать
Можно будет упростить код переделав его на switch case. Но сделать атлас это нафиг не надо. Не все текстуры могут быть использованы, в одном блоке может быть несколько текстур. Лучше для каждого типа делать все-таки свою проверку.
То чувство, когда взял оригинальную текстуру 4096 на 9472... и пытаешься высчитать пиксели в пейнте линеечкой, а потом тебя, таки, осеняет, что куб 256 на 256...
Согласен, там из-за того что текстура не рассчитана на такой подход не так красиво смотрится. Я бы её отредактировал, сделал бы не одну линию со свисающей травой сверху, а 4 разных. Возможно в какую-нибудь следующую часть добавлю такую модификацию
17:05 Тобто ти все одно викликаєш 4 рази одну і ту ж функцію :D Але стало гірше тому, що компілятор буде сам розширяти цикл у 4 строки... Так, це мізерно, але буде впливати на час компіляції, тим паче якщо проєкт великий, а такої практики багато.
Для C/C++ я бы согласился, но C# компилятор довольно быстро всё делает, не знаю если честно занимается ли он вообще разворачиванием циклов, но думаю тут влияние совсем небольшое будет. Так зато сложнее ошибку допустить, если потом в трёх строчках поменяешь координату, а в четвертой забудешь)
проблема еще выявилась, на отрицательных координатах в чанке по его локальным позициям x=1 и y=1 блоки не ставятся на самом чанке, а переносятся на какой то другой чанк и даже не на те координаты на которые ставил(Допустим чанк -1;-1 , ставлю блок на координаты 1;~;5 по локальным, и этот блок ставится на чанке -2;-1 на координатах 1;~+1;6, короч сложно всё, попробовал код этот на 2021.3.36f1 и на 2022.3.36f1, код переписывал с четкостью, не думаю что два раза смог бы ошибиться, вообщем вот, не знаю решится ли вообще эта проблема )
Пока очень интересный проект, хоть за юнити я не шарю смотреть очень интересно. У меня появился вопрос - Будут ли добавляться различные эффекты для атмосферы, я понимаю что рад этим думать ещё рано, но например в том же Teardown очень много различных видов эффектов на подобии дыма, тумана, огня и т.п.
очень интересный и познавательный видос, но боковые стогны у блока земли с травой выглядят топорно: верхнюю четверть текстуры занимает трава, а остальное земля если у нас блок = 1/4 текстуры, то получается что верхний слой сбоку полностью зеленый, а остальные полностью коричневые. в голову не приходит как это можно исправить.
Привет! Смотри, такой вопрос. Чанк это геймобджект на котором висит атлас текстур, тобишь кубы не являются геймобджектами в отдельности. Но что если я хочу задавать кубам текстуры не из этого атласа, а из отдельных изображений (отдельная картинка с текстурой для камня, земли и т.д).
Привет. Для этого нужно либо генерировать разные меши, один только с блоками земли, один с деревом, и т.д, и каждому задавать свой материал. Либо разные submeshes, чтобы в меш рендерер можно было задать несколько материалов массивом. Хотя в итоге работать это будет примерно одинаково, и соответственно чем больше мешей, тем тяжелее будет сцена, так что с атласами и одним материалом вариант мне больше нравится
@@EmeraldPowder Привет. Да я тоже так подумал, и остановился на атласе. Есть ещё один вопрос, выделение чёрного контура на блоке, на который смотрит персонаж. Я сделал геймобджект куб с аутлайном (сам куб невидимый), который подставляется под координаты блока, на который собственно и смотрит игрок. Такая реализация норм? Или можно как то попроще да поумнее
Да, этот шейдер очень на него похож. Точнее по сути это оно и есть, но у меня частный случай, где все полигоны параллельны осям координат, так что мне не надо было париться с интерполяцией, чтобы наклонные и изогнутые поверхности хорошо смотрелись. И текстура пиксельная, с ней особо не важно если она повернётся или отразится, так что поэтому там любые x/y/z можно друг на друга менять, всё равно смотреться хорошо будет
пытался добавить прозрачные блоки, вроде получилось, но бывает видно через текстуры кубов другие грани кубов, как наслоение на передний край, хотя объект дальше стоит. Подскажите, плз, как это решается
Если прозрачные добавлять, то по идее их нужно считать так же как воздух при проверке соседей. То есть если по соседству прозрачный блок - то всё равно генерировать грань
