Gamedev

Ответить в тред Ответить в тред
Check this out!
овг Аноним # OP 05/04/20 Вск 01:37:40 6531941
image.png 2250Кб, 1920x1080
1920x1080
image.png 1943Кб, 1920x1080
1920x1080
image.png 3226Кб, 1920x1080
1920x1080
Очередной выживач говна. Делаю на unity. На данный момент в работе чуть больше трех месяцев

Понял, что не помешает вести что-то вроде дневника. Пусть он будет здесь
Аноним 05/04/20 Вск 01:49:31 6531962
ovgg.mp4 25297Кб, 848x480, 00:01:13
848x480
Вот небольшой видос, на котором видно текущий прогресс

Мир, очевидно, бесконечный, процедурный и все такое. Есть несколько (три) тулзы для модификации террейна - сферическая тулза, кубическая (которая работает супер хуево, наверное я ее поменяю) и flatter тулза, которая делает ровную поверхность (спиздил идею из Astroneer)

Ни противников, ни чего-либо похожего, сейчас нет
Аноним 05/04/20 Вск 05:12:21 6532043
>>653194 (OP)
Бля, круто, хочу игру с вот такой вот пустынней и такими вот туннелями. Типа субнаутики, только в пустыне с туннелями.
Аноним 05/04/20 Вск 08:53:28 6532114
>>653204
Space engineers, только играть в неё скучно и оч непонятно
Аноним 05/04/20 Вск 11:28:41 6532245
>>653196
Видос не запускается. Делай webm
Аноним 05/04/20 Вск 14:52:38 6532426
shitfuck.webm 4411Кб, 1280x720, 0-2562047788:00:0-54
1280x720
Надеюсь, что не слишком шакально вышло
Аноним 05/04/20 Вск 15:02:02 6532437
>>653242
Чет пиздец какой-то, нет, так не пойдет. Не думал, что самой сложной задачей за три месяца окажется нормальная конвертация в webm
Аноним 05/04/20 Вск 23:35:37 6533358
image.png 1586Кб, 1534x691
1534x691
image.png 1351Кб, 1534x689
1534x689
Сегодня было не очень много времени на работу, к сожалению

Немного обновил систему настроек - теперь при обновлении настройки "цвет тумана" будет одновременно обновлен backgroundColor у камеры (да, сейчас у меня не используется скайбокс) и fogColor у RenderSettings

Ну и большую часть времени пытался разобраться с шейдером для террейна

Тут стоит сказать, что я вчера написал генератор этого самого шейдера, который создает все требуемые мне файлы. Смысл этого действия состоит в том, что для поддержки различных террейн материалов (dirt и stone на данный момент, но в перспективе их будет больше) требуется много копипасты в коде шейдера. Поэтому я решил заранее избавить себя от этих проблем. За основу взял темплейт URP-шейдера, найденный на гитхабе

И вроде этот генератор работает, создает файлы, все такое, но normal map и прочие map нормально не сэмплируются (насколько я вижу), а diffuse map сэмплируется корректно. И вот я не знаю, с чем связана данная проблема

На первом скрине можно видеть тестовый шейдер, который я правил вручную, и у которого только один набор карт используется. С ним все работает корректно (normal map сэмплируется). А на втором скрине (и на всех скринах в этом треде) можно видеть сгенерированный шейдер. Я специально сейчас выкрутил все параметры, чтобы было максимально заметно некорректное поведение
Аноним 05/04/20 Вск 23:38:41 6533369
aaaaaaaaaaaaaaa[...].webm 29367Кб, 1920x1080, 01:13:15
1920x1080
Плюс попытка номер два залить видос
Аноним 06/04/20 Пнд 14:24:17 65341010
Пробуй через эту программу Movavi Screen Recorder 11 делать видео с экрана.

А здесь https://convert-video-online.com/ru/ конвертируй в меньший размер.
Аноним 06/04/20 Пнд 21:52:06 65351711
Записывай через OBS и будет тебе счастье
Аноним 06/04/20 Пнд 23:27:18 65353312
image.png 1768Кб, 1535x694
1535x694
Короче, сегодня после работы пытался разобраться с шейдером. На данный момент я только понял, что скорее всего превысил максимальное количество texture sampler'ов. Больше у меня особо идей нет. Но оно в целом выглядит реалистично, т.к. в своем генераторе я втупую скопировал структуру template-шейдера, а там для каждой из карт материала используется отдельный шейдер. В моем случае же получается, что количество этих карт умножается на количество материалов * 2, что даже при двух только материалах дает просто огромное количество этих самых sampler'ов.

Посему я решил избрать другой подход - я убрал из шейдера всё, кроме diffuse map. Все остальные значения либо вовсе выпилил, либо заменил на константы. А теперь, когда он работает в таком минимальном состоянии, буду добавлять всякие плюшки, если посчитаю это нужным. Ну и еще там видимо нужно будет как-то вместо одного shader pass использовать несколько, если все-же количество sampler'ов будет слишком большим (по крайней мере я прочитал, что так советую решать эту проблему). Буду смотреть, в общем.

И сделал небольшую таску - добавил фонарик для игрока. Мелочь, а приятно.

Думаю, что дальше так и буду стараться делать - часть большой таски + небольшие задачи, на которые не должно уходить много времени.

>>653410
>>653517
Спасибо большое за советы. Попробую эти варианты, как будет время
Аноним 06/04/20 Пнд 23:32:48 65353713
>>653533
Только сейчас понял, что возникла путаница в использовании слова "материал". Чтобы было более понятно опишу лучше так : на каждый "игровой материал" (или "террейн материал", как удобней) требуется два "материала" (в стандартном смысле слова, который используется в контексте компьютерной графики). Надеюсь, что так понятней стало, хз
Аноним 08/04/20 Срд 14:24:28 65399614
Оп, это marching cubes?
Планируешь физику к висящим блокам прикручивать?
Как хранишь данные?
Аноним 08/04/20 Срд 17:47:01 65407115
>>653996
Да, они самые

Если получится в достаточной степени это все дело оптимизировать, то попробую. А так физика этих блоков это не самый критичный момент, на мой взгляд

Сейчас это наверное сделано несколько ебануто, но на данный момент это лучший вариант из тех, что я пробовал (а попробовал я относительно много). Выглядит это примерно следующим образом

На хай левеле у меня есть TerrainController, в котором хранится пул чанков

Каждый чанк имеет массив float + int значений, который хранится на GPU, т.к. все эти модификации происходят через compute shader'ы. Это те самые значения, по которым и прогоняется marching cubes. Еще имеет выделенную на GPU память под вершины меша. Так же он имеет заранее выделенную память для вертексов, индексов вершин и индексов материала на заднной вершине (dirt, stone и т.п.). Это значения уже хранятся в оперативной памяти и нужны для построения самого unity-меша. Количество выделяемой памяти, понятное дело, прямо пропорционально размеру чанка

Но каждый чанк хранится внутри так называемого ChunkColumn, т.к. они сами по себе кубические, то я объединяю из в "колонны", чтобы террейн имел настраиваемую высоту. По-сути это просто набор указателей на несколько чанков, которые расположенны на одинаковых X и Z координатах. Это облегчает их динамическую подгрузку и вообще все операции, которые требуется производить над чанками, которые находятся в одной "колонне"


В целом, если кратко, то получается как-то так. Но я тут много деталей упустил. Если будет интересно, могу и про них написать

Этот вариант конечно очень много места в памяти занимает (и в видео-памяти и в оперативной тоже), но у меня есть некоторые идеи, как это можно будет зафиксить. В to-do листе задача есть, так что в скором времени, надеюсь, руки до этого дойдут
Аноним 08/04/20 Срд 17:52:38 65407216
>>654071
Кстати, хочу отметить, что Unity не особо помогал с этим всем делом, а скорее даже мешал. Наверное под такое дело лучше другой движок юзать. Atroneer тот же, вроде бы, сначала на Unity пилили, а потом на Анрил перебрались
Аноним 08/04/20 Срд 18:48:47 65409717
>>654072
>Анрил перебрались
Может тебе тоже на анрил перебраться, пока разработка далеко не ушла.
Аноним 09/04/20 Чтв 01:04:40 65424218
bandicam 2020-0[...].webm 3645Кб, 1480x532, 00:00:28
1480x532
Сегодня сделал небольшую задачу - основу системы цветовых пресетов. Сейчас объясню, нафиг она вообще нужна

У меня в проекте уже есть несколько мест, в которых требуется настраивать цвет, как, например, туман и сам террейн. И вот выставлять где-то в рандомных местах проекта эти цвета не очень здорово, как мне кажется. Ведь когда таких объектов, требующих окраски, будет становиться больше, их тяжело будет менеджить. Поэтому я решил сделать централизованную систему, в которой у меня существует заданная цветовая палитра, а в остальных местах проекта выставляется не конкретное значение цвета, а цвет, заданный в палитре. Таким образом мне не надо будет беспокоиться о том, что я где-то могу забыть поменять цвет какой-нибудь срани или еще что-то в таком духе. И вообще так проще будет добиться художественно привлекательной картинки, наверное

Да и к тому же, это может оказаться полезным, если я буду добавлять различные биомы в игру, т.к. каждому из них я смогу задать свой пресет

Так же есть функционал смены пересетов, где можно задать новый пресет и время, за которое должна произойти смена. На видосе, вот, пример есть. На нем происходит смена с Dbg Another Preset на Preset

>>654097
Я хочу попробовать до конца доделать проект на Unity. Просто ради интереса. А там уже посмотрю, может потом на Анриле попробую что-нибудь сделать

Аноним 10/04/20 Птн 00:07:21 65476119
Пиздец. Сегодня начал делать LOD систему для террейна. И какая же это боль, конечно. По-сути, надо перелопатить всю логику подгрузки чанков, а она написана, эм, хуево и запутанно, так сказать. У меня прям жопа сгорела, если честно. Но зато это хотя бы возможность ее переписать. Ну и если я сделаю, как задумано, то, по-идее, террейн будет занимать меньше места в памяти и рисоваться на бОльшие дистанции.

Лучше, конечно, такие вещи решать заранее.
Аноним 11/04/20 Суб 23:39:21 65569820
image.png 1014Кб, 1536x689
1536x689
Получилось неплохо оптимизировать всю эту террейн систему. В результате радиус видимости удалось увеличить в разы, при том, что памяти теперь все это дело стало занимать гораздо меньше. Я прям удивился тому, насколько сильной вышла разница. Конечно, еще есть определенные проблемы со всем этим, но уже этот подход выглядит более перспективно, чем тот, что я до этого использовал.

На картинке, вот, пример террейна, запущенного на моем, далеко не самом мощном, ноуте из unity редактора, с таким радиусом видимости, какой раньше тянулся только на мощных компах (и то они начинали дико пердеть).

А все, что я сделал, по-сути - это отделил представление (условно) от данных. Теперь каждый чанк хранит в себе только game object с мешем и прочей сранью (т.е. просто отображение скалярного поля данных, по которому прогоняется marching cubes), а нужные GPU и RAM буферы гетает через специальный ChunkDataController, который "распределяет" данные между чанками. И теперь нам не требуется для каждого чанка отдельный набор буферов, что и дало такое сильно уменьшение затрачиваемой памяти.

Теперь еще видно, насколько плоский и "трипофобный" террейн сейчас генерируется.
Аноним 12/04/20 Вск 19:46:26 65611721
>>655698
> плоский и "трипофобный" террейн сейчас генерируется
А мне ЗБС. Я сразу же представил, как люди живут там, строят дома по краям карстовых пещер. Сотни лестниц ведут из полости в полость. Откуда-то тянется костра дымок. Где-то фырчит двухтактный движок. Жизнь кипит.
Аноним 12/04/20 Вск 21:17:51 65619422
image.png 534Кб, 1280x692
1280x692
image.png 538Кб, 890x455
890x455
Сегодня в спокойном темпе начал переделывать генерацию террейна. Ну и еще немного фиксил систему подгрузки чанков. В эту систему надо добавить еще одну фичу (ну или пару), чтобы все это дело стало работать норм.

На первом пике можно видеть результат сегодняшней работы. На втором пике рофло-вариант с совмещением предыдущего и нового варианта генерации. Мне кажется, что вышла неплохая основа для дальнейшей работы. Хотелось бы добавить пещеры еще и все такое. Ну и надо будет причесать шейдер, который все это дело генерирует, ибо сейчас он не особо хорошо оформлен.

>>656117
Хм, ну тут такое дело, что это все не вписывается в лор игры (который я пока умышленно не раскрываю). Ну и еще мне несколько неприятно смотреть на подобный террейн. И, думаю, такое может быть у достаточно многих людей.
Аноним 12/04/20 Вск 23:12:18 65627423
>>656194
> лор игры (который я пока умышленно не раскрываю)
Ммм... Интрига! Неужто лор будет круче вселенной наоборот с толщеходами? Будем посмотреть!
Аноним 13/04/20 Пнд 03:40:46 65634124
Почему выбрал юнити?
Не срачер, просто интересно почему выбор был сделан в пользу юнити, а не уе или годо
Аноним 13/04/20 Пнд 09:14:52 65636925
Аноним 14/04/20 Втр 00:58:15 65669826
Spacey14.04 Scr[...].png 2215Кб, 1920x1080
1920x1080
Spacey14.04 Scr[...].png 2560Кб, 1920x1080
1920x1080
Spacey14.04 Scr[...].png 3759Кб, 1920x1080
1920x1080
Spacey14.04 Scr[...].png 2602Кб, 1920x1080
1920x1080
Сегодня продолжал работать над системой подгрузки. Надеюсь, что завтра уже доведу ее до нормального вида. А пока, вот, скриншоты дома, который я сегодня сделал ради интереса. Уже не только пенисы в игре получается строить. Ну и плюс тут можно посмотреть на бОльшую дистанцию отрисовки.

>>656341
Если кратко, то можно сказать, что "просто так" выбрал. Но можно это интерпретировать так, как другой анон тебе ответил, наверное. Как удобней будет.
Аноним 14/04/20 Втр 01:39:55 65670727
>>656698
Ничего более депрессового чем этот дом в пустыне я не видел в играх.
Даже напомнило Sothc.
Внезапно возникло желание пожелать тебе удачи. Желаю.
Аноним 16/04/20 Чтв 01:55:06 65750128
a2e0f64c628b5a5[...].jpg 87Кб, 537x671
537x671
>>653194 (OP)
Визуально игра выглядит очень меланхолично, не просри стиль! Это выглядит как пустыня на какой-то далёкой плнете, пещеры напомнили первый фильм про Риддика, а дом посреди этой пустоты это что-то!
Если эта выживалка будет иметь хорор составляющую то цены ей не будет. Надеюсь у тебя всё выйдет.
Вот видос случайно попался может тебе поможет https://youtu.be/-VgtSL5ZpYc
И пик монстра, может пригодится
Аноним 16/04/20 Чтв 15:35:03 65774729
>>653194 (OP)
Слушай, я особо тред не читал, но имею пару вопросов:
На каком движке делаешь игру и имел ли ты какие-то навыки, например в программировании, до того, как приступил к разработке?
Аноним 16/04/20 Чтв 17:12:07 65782630
>>657747
Первый вопрос отпадает.
Аноним 16/04/20 Чтв 23:37:02 65806131
image.png 729Кб, 1539x694
1539x694
Вчера довел до удовлетворительного состояния систему подгрузки. На всякий случай снабдил ее код комментариями сверху донизу, чтобы через месяц не вспоминать, как она вообще работает. В общем, более или менее норм вышло, я думаю.

Так же начал работать над инвентарной системой. Пока не могу придти к архитектуре, которая меня удовлетворяет, хотя движение в этом направлении и идет, вроде бы. Хочется не только добиться достаточной гибкости использования но и удобства.

Параллельно заложил небольшую основу для систему локализации. Решил сделать это сейчас, чтобы потом не ходить по всему проекту для того, чтобы "string" заменить на условный "LocalizibleString". В целом система должна быть не очень сложной, если, конечно, я не вижу сейчас каких-то "подводных камней".

Новых интересных скриншотов у меня нет, так что прикреплю к посту небольшую фракталоподобную штуку, которую некоторое время назад сделал. Чтобы пост выглядел поинтереснее. Вообще это sort of процедурная генерация на основании заданного меша. Для этой конкретной картинки просто я подобрал удачный ракурс и базовую геометрию.

>>656707
>>657501
Благодарю. Рад, что вам понравилось. И, кстати, судя по вашим комментариям, я попадаю в то настроение, которое хочу получить в итоге.

За видос спасибо. В релейтеде мне все вылезал, но что-то не доходили руки его посмотреть. Позже попробую решить проблему слишком заметного тайлинга текстур.

>>657747
Ну, я в шараге отучился на программиста и по специальности около года сейчас работаю. А вот всех остальных навыков у меня толком нет, я думаю. Не полный ноль, но и ничего хорошего тоже.
Аноним 17/04/20 Птн 16:41:35 65832732
>>658061
> начал работать над инвентарной системой. Пока не могу придти к архитектуре, которая меня удовлетворяет
Рекомендую методику "от результата".
Если речь о коде, то пишешь строчки, типа:
> Kak.ya.hochu(Zdelat.interfeis);
> Inventar.peredat(otKogo, Inventar.elementy(index), komu);
> SladkiRulet.peremestit(Igrok.inventar);
> Inventar.elementy(index).vykinut(nahui);
Затем последовательно реализуешь необходимые сущности, чтобы твой код не вызывал ошибок.
Если речь о графике, сначала накидываешь на форму каркас из элементов, добиваешься, чтобы всё нравилось, затем привязываешь к каркасу функционал из кода выше.
Аноним 18/04/20 Суб 01:45:27 65864833
ovg (convert-vi[...].webm 38090Кб, 1274x720, 00:01:02
1274x720
Сегодня продолжал работу над инвентарной системой. В целом получилось может слишком сложно, но вроде более или менее гибко. Разделить все это можно на следующие "компоненты" (к ecs никакого отношения не имеет, если что) :

1. Есть базовый класс Inventory, который является обычной оберткой над массивом заданного размера, в каждой ячейке которого хранится InventoryItem (надо будет заренеймить в InventorySlot, наверное). В свою очередь InventoryItem хранит два поля - id и количество предметов. Id для самого айтема не имеет никакого значения - интерпретировать и сетапить его должны другие системы, которые используют инвентарь. Таким образом, получается, что класс Inventory является супер базовой штукой, которая может быть использована во множестве разных контекстов. Ну, я надеюсь на это, по крайней мере

2. У инвентаря есть интерфейс. Тут идея в том, что, например, в случае инвентаря игрока нам нужно уметь постепенно свитчится между элементами, последовательно переходя от одного к другому, но в случае какого-нибудь условного ящика нам такой функционал не нужен, там другая логика взаимодействия. Посему я отделил интерфейс инвентаря в отдельный класс. На этом уровне все Id предметов - тоже просто абстрактные числа, не имеющие никакого смысла.

3. Есть PlayerInventory класс, который в себе хранит инвентарь игрока и интерфейс для него. Так же имеет возможность задавать изначальный сетап инвентаря в инспекторе Unity. Тут уже появляются впервые Item'ы, а не простые рандомные int'ы.

4. Собственно Item. Точнее сказать, ItemDescription. Каждый предмет, который игрок может взять в руки, использовать, выбросить, описывается с помощью специального ScriptableObject, в котором хранится набор некоторый набор полей, который описывает все необходимые свойства предмета - uid (в виде строки), название (в виде локализуемой строки), внешний вид в руках (префаб), внешний вид на земле (тоже префаб), максимальное количество в одном слоте инвентаря. Но это для базовых предметов, у которых нет какой-либо логики использования - их можно только подобрать и выбросить. Для предметов с логикой использования есть специальный ScriptableObject - ItemWithLogicDescription, который хранит в себе все те-же поля, но дополнительно имеет место для еще одного ScriptableObject'а, в котором описывается логика. У объекта логики есть методы Activate и Deactivate, которые, очевидно, включают и выключают эту логику. Логика, в прнципе, может делать все, что захочет.

4.5. Таким образом все необходимые свойства объектов описываются в одном месте и не зависят от других систем. Связанность образуется только в объектах, которые описывают логику, т.к. они могут тесно взаимодействовать с другими системами.

5. Есть специальный синглтон, через который по uid ItemDescription'а можно получить интовый id (и наоборот). Это используется как раз для того, чтобы предметы с заданным ItemDescription'ом можно было положить в инвентарь. Что важно - на данный момент в разные игровые сессии эти id могут оказываться разными для одного и того же Item'а. Это немного странно, но более удобно, чем вручную int проставлять во всех дескрипшенах (это выглядит очень багоопасным).

6. Ну и теперь все готово, чтобы на основе этого строить остальную игровую логику. На данный момент есть возможность сменять заселекченый предмет в инвентаре (через класс интерфеса, см. пункт 2). Заселекченый предмет отображается "в руке" с помощью получения ItemPreview префаба из ItemDescription'a. Заселекченный предмет можно выбросить. После того, как он выброшен, будет заспавнен GameObject на основании префаба, который, опять же, описан в ItemDescription. Так же можно эти объекты подбирать. Они будут возвращены в инвентарь, а GameObject будет удален.

И, кстати, таким образом, чтобы добавить новый, полностью рабочий Item достаточно создать корректный ItemDescription. И его можно брать в ручки будет, кидать и подбирать. Никаких мерзких enum'ов говна и прочих списков нигде не надо делать. Наверное это никого не удивит, да. Но я очень боялся, что какое-то такое говно всплывет.

Если кто-то дочитает эту простыню, то буду рад услышать ваши предложения и замечания. Я накидал это все дело за пару дней, вышло немного сумбурно, и наверняка я что-то упустил. Видос с примером прилагаю. Там без UI нифига не понятно, конечно, но по-сути я просто выкидываю и подбираю различные предметы.

>>658327
Согласен, это хороший подход, я примерно такой способ и выбрал изначально. Только еще помимо кода старался представить желаемый пайплайн добавления новых объектов. Ну и пайплайн удаления объектов тоже.
Аноним 20/04/20 Пнд 00:14:03 65939734
image.png 955Кб, 1080x654
1080x654
Короче, недавно я решил, что весь этот террейн работает слишком медленно, и надо что-то с этим делать. Я попытался исправить это добавлением новых структур данных, которые хранят дополнительную информацию о чанках, чтобы уменьшить количество "перегенерируемых" чанков, да и в целом постарался оптимизировать C# код. Это помогло. Но все-равно результат оказался слишком плохим, из-за чего у меня сгорела ass.

Посему я решил сделать одну из двух вещей - либо сделать систему генерации в виде NativePlugin'а для Unity, либо перейти на Unreal. Основная идея состоит в том, чтобы получить возможность писать эту логику на языке, в котором можно будет более четко менеджить память, а также который будет работать без виртуальной машины и GC. C#, хоть и хороший язык, но для моих целей он не совсем подходит, да и работать мне с ним не очень комфортно.

Так что эти выходные я посвятил изучению этих двух вариантов. NativePlugin'ы мне показались не очень удобными, т.к. мне придется весь интерфейс для связи моей системы с C# реализовывать в виде функций (поправьте, если я не прав, пожалуйста). Я имею ввиду что-то в духе функций TerrainController CreateTerrainController() . А затем, чтобы вызывать какие-то методы у этого объекта, надо будет делать дополнительную функцию, которая принимает указатель в качестве аргумента : void TerrainContoller_Update(TerrainController obj) { obj -> Update(); }. Это выглядит супер-неудобным, если честно.

Т.к. вариант с нативными плагины мне не зашел, я решил попробовать второй вариант. Большую часть времени потратил на чтение документации к Анрилу. В целом за эти полтора дня вышло сделать черновую генерацию из говна и палок, совершенно не оптимизированную. Скрин прилагаю. Пока буду дальше смотреть в этом направлении, т.к. оно мне кажется наиболее предпочтительным
Аноним 20/04/20 Пнд 01:31:29 65941635
>>659397
Странно, вроде бы я ставил звездочки у указателей. Но, надеюсь, идея понятна.
Test Test * Test
Аноним 21/04/20 Втр 08:09:03 65992636
>>659397
>за эти полтора дня
блять ты чо сука какой-то вундеркинд что ли

хули у меня всё так медленно
Аноним 21/04/20 Втр 11:02:49 65995337
>>659397
>GC
Ним можно управлять вроде как.
Алсо, яннп, разве террейн не генерится однократно при создании?
тред не читал
Аноним 21/04/20 Втр 22:20:59 66020238
>>659926
Это магия сиплюсплюс. Не тот язык мы учили в школах, анон.
Аноним 22/04/20 Срд 12:01:23 66072139
Текстура твоя?
Аноним 01/05/20 Птн 23:37:25 66515740
image.png 690Кб, 1211x648
1211x648
Бамп. Я не умер.

Пытаюсь потихоньку сделать террейн опять, который мне бы нравился. Попробовал несколько вариантов, и, может, нашел неплохой.

Не охуевайте сильно от моего 999icq, но я только сейчас додумался использовать qtree для чанков, чтобы реализовать lod'ы и вообще более эффективно использовать память.

В текущем варианте разные инстансы qtree представляют из себя некое подобие "супер-чанков", которые имеют очень большие размеры. Ну а строятся эти деревья на основании позиции плеера. Максимальная глубина дерева это количество lod'ов, которые предусмотрены системой. Каждому листу дерева соответствует chunk column.

На прикриле я цветом визуализировал lod'ы террейна. Чем светлее цвет, тем более детализированный там террейн.

Так же немного изменил подход к настройкам террейна. Теперь они более гибкие (вроде бы).

Не для срача, а просто на заметку : для данной задачи Анрил действительно подходит гораздо лучше, чем Unity. Например, генерация одного чанка 32x32x32 самым тупым способом на Unity занимает просто дохуищу времени (точных замеров нет, сорян), но аналогичная генерация на Анриле происходит практически моментально. Он настолько быстро справляется с этой задачей, что всякие compute shader'ы даже не понадобятся, наверное. Я даже смог каждый кадр заново генерировать несколько чанков 64x64x64 с небольшим оффсетом, чтобы получить эффект движения, и, даже на моем не самом сильном ноуте, фреймрейт был в районе 30 кадров (повторюсь - это самый тупой и неоптимизированный вариант реализции).

>>659926
Да забей, я просто с# на плюсы переписал код, который и так уже раз десять писал. Ничего такого не сделал, поэтому и вышло быстро.

>>659953
Вот насчет возможности управлять им я не знал, если честно. Но все-равно это все выглядит скорее как борьба с языком и попытка писать на шарпе так, будто это плюсы. Наверное это не очень хорошо.

А насчет террейна - он должен быть условно бесконечным и подгружаться вместе с передвижением игрока. Майнкрафт, наверное, самый близкий пример.

>>660721
Все текстуры качал с textures.com

Аноним 02/05/20 Суб 11:06:25 66522641
>>665157
> А насчет террейна - он должен быть условно бесконечным и подгружаться вместе с передвижением игрока. Майнкрафт, наверное, самый близкий пример.
В майнкампфе на сколько я знаю ограниченный мир (n х n блоков) генерится при ините и просто подгружается при передвижении игрока (и его настроек).

Алсо, задам наверное тупой вопрос, я конечно с дивана и не совсем понимаю как ты собрался реализовать эту бесконечность. Вот допустим я сделал какое-то действие с миром (выкопал яму/построил дом) в точке 0/0/0 (ну или где там будет спаун)(понятно что действие будет от и до какой-то точки) и решил попиздовать в далекое путешествие на 0+n/0/0+m условных координат попутно ставя какие-то метки чтобы вернуться домой. Получается все эти изменения мира нужно будет держать в памяти и через t времени подобного путешествия она рано или поздно закончится.
У тебя по идее мир должен будет прогружаться в оперативку на n/n/n координат вокруг игрока, а весь уже сгенеренный мир должен сохраняться уже на жесткий диск, я правильно понимаю?
Аноним 06/05/20 Срд 09:35:51 66628342
>>665226
>генерится при ините
Это неверно. Он бы просто не поместился на диск тогда. Он генерится на лету.

>нужно будет держать в памяти
В том же MC так и сделано (изменённые, но далёкие чанки сбрасываются на диск и выгружаются из ОЗУ до очередного посещения). И, да, память заканчивается, если ты решишь миллионы квадратных километров пометить.
Аноним 06/05/20 Срд 10:56:59 66629243
>>666283
Я немного проебался - нужно по сути "сохранять" весь мир где уже просто был игрок, а не изменения.
Аноним 11/05/20 Пнд 06:16:38 66830544
>>653196
Не ясно что за хуйню ты удумал и что это вообще будет из себя представлять новый майнкрафт?, но с чем я могу поздравить тебя точно, так это с тем, что манипуляции с ландшафтом у тебя сделаны лучше, чем в No Man's Sky ебаном и это нихуя не комплимент на самом деле, просто примечание
Аноним 11/05/20 Пнд 07:53:46 66830945
>>653194 (OP)
>Делаю на unity.
Используешь ecs?
Аноним 16/05/20 Суб 17:17:48 67006446
image.png 397Кб, 1280x577
1280x577
image.png 694Кб, 1280x576
1280x576
image.png 945Кб, 1280x577
1280x577
image.png 633Кб, 1280x576
1280x576
Небольшой апдейт. Все еще продолжаю свои попытки блять сука нахуй найти нормальную архитектуру для террейна. На данный момент сделано следующее. Как писал выше, есть quad tree, которое строится на основании позиции игрока. Потом я на основании этого дерева строю террейн. Чем глубже находится нода дерева, тем более детальный террейн там будет, таким образом получается некоторое подобие lod'ов.

Я отделил непосредственно генерацию чанков в отдельный тред. Из мейн-треда я могу просто "заказать" у него генерацию значений для какого-то чанка, передав указатель на объект и коллбек, который будет вызван по завершении генерации.

Так же теперь загрузка происходит постепенно. Т.е. сначала полностью грузится самый низкополигональный террейн, затем более детальный и так далее, пока загружать останется нечего.

Зачем я это делаю вообще, почему мне не подошло то, что было до этого? Потому что оно лагает, когда за один кадр необходимо сгенерировать много чанков. Или просто сделать их видимыми (что необходимо делать из мейн-треда), или, наоборот, невидимыми. То, что я сделал сейчас, помогает частично избавиться от этой проблемы, но я уверен, что можно сделать лучше. Не должно все так лагать, иначе это просто хуевая игра будет с технической точки зрения.

У меня есть идеи, как это можно исправить. Постараюсь на выходных сделать.

Короче, из-за смены движка, я откинулся в прогрессе практически в самое начало. Но оно к лучшему, наверное.

Т.к. мне нечего показать сейчас, то скину еще скринов с другими "экспериментами" с процедурной генерацией. Только теперь я пытался сворачивать плоскую геометрию в шары. Делал я это с помощью преобразования обычных координат в полярные. Вышло очень просто и забавно. Может потом использую где-нибудь, хз.

>>665226
Там в принципе другой анон верно ответил. Добавлю только что изначально, если не ошибаюсь, ограничений на размер карты там не было, но из-за багов ("далекие земли") они были введены.

>>668305
Мне сложно сказать, что именно из себя это будет представлять. Вряд ли это будет что-то масштабное, точно не "новый майнкрафт". Если не смогу техническую основу нормальную сделать, то и вовсе будет просто тред на дваче.

Рад, что модификации террейна выглядят не super huevo. Я вообще хочу их сделать максимально гибкими и удобными. Если выйдет, конечно же.

>>668309
Нет, не использую. Пока на Юнити делал, я пытался сделать это через ecs, но не смог всю эту систему в нее вписать. Одна из проблем в том, что мне не особо требуется итерироваться через большое число каких-то объектов, чтобы получить большой буст перформанса. Ну или я не смог придумать, как свести проблему генерации террейна к форме, которая была бы подходящей для ecs. Другая проблема состоит в том, что у Юнитевского ecs есть ряд разумных ограничений, которые, к сожалению, не позволяют использовать классы. Из-за этого, например, я не могу использовать ComputeShader'ы и подобные штуки, а у меня на шейдерах весь террейн работает. Ну и прочие такие подводные камни я встретил.

В итоге, когда я все-же попытался сделать через ecs, то я просто итерировался через индексы чанков, а потом по индексу получал доступ к чанку и проводил нужные действия. Но это какая-то херня вышла, как мне кажется. Никакой пользы при такой реализации от ecs я не получил. Но, если что, я не пытаюсь заговнить ecs. Просто данную конкретную задачу я не смог нормально решить с ее помощью.
Аноним 16/05/20 Суб 23:04:44 67019847
Аноним 01/06/20 Пнд 11:26:55 67393648
>>653194 (OP)
Оп, ты использовал в unity какой-то встроенный инструмент для создания таких дырок в террайне?

И это реклама твоей гениальной игры? Кадр c 21:03: https://youtu.be/eV-B1LSy6wM
Аноним 08/06/20 Пнд 00:57:01 67534749
image.png 1914Кб, 1920x1080
1920x1080
Небольшой апдейт.

Решил недавно взять перерыв в пару недель. Занялся другим проектом, который напрямую не связан с игорями, ибо немного выгорел. Сейчас, вот, вернулся.

Так же я немного переосмыслил свой подход к разработке. Теперь буду стараться придерживаться более простой архитектуры и более простых подходов к процедурной генерации, чтобы суметь потянуть все это в одно рыло и не растягивать это все дело на миллионы лет. Посему теперь я делаю очень просто - есть чанки, они всегда одинаковые (нет разделения на lod'ы и т.д.), я просто буду выставлять их в нужные позиции и заново генерировать, когда это потребуется. Никаких qtree и подобных вещей. Может потом, когда я заставлю простой вариант работать нормально, я начну усложнять архитектуру системы, но это уже другой вопрос.

Если смотреть на текущий прогресс, то я откинулся где-то на вторую половину февраля, когда у меня на Unity был небольшой кусок террейна, который можно было разрушать и строить. Только теперь это сделано на Анриле, а так же все расчеты полностью происходят на cpu вместо видеокарты. В целом получается обновлять чанки достаточно быстро, несмотря на то, что я не пользуюсь "массовым параллелизмом", а просто разбиваю расчеты на пару потоков на процессоре. Думаю, что с Unity вариантом реализации главным боттлнеком оказалась необходимость пересылать данные с видеокарты в оперативную память каждый раз, когда нужно было обновить меши. Получается, что везде есть свои недостатки. Но все-же мне кажется, что новый вариант более перспективный.

Вот вам мерзкий говеный отвратительный скриншот, как доказательство того, что работа действительно идет.

>>670198
Спасибо большое за ссылки. Я сейчас немного глазами пробежался по статье из wiki, но потом уделю больше внимания.

>>673936
Нет, ничего не использовал. Не уверен, что сейчас для Unity есть какой-то ассет для подобных террейнов. Я найти не смог, по крайней мере. Есть некоторые примеры на github (и туториалы на youtube), но они все достаточно небольшие (хоть и очень полезные, на мой взгляд), т.к. сделаны просто для того, чтобы показать принцип работы.

Ну да, в целом. Но скорее это реклама паблика и просто небольшая пасхалка, которую было решено засунуть в игру.
Аноним 08/06/20 Пнд 01:46:35 67534850
Настройки X
Ответить в тред X
15000
Макс объем: 40Mб, макс кол-во файлов: 4
Кликни/брось файл/ctrl-v
Стикеры X
Избранное / Топ тредов