3D.ru

Когда "кубик" делаешь динамическим ему назначай сфера/бокс коллайдер, и двигай просто физикой, а когда столкнется уже переводи в мешколайдер.

Tolking писал(а):Когда "кубик" делаешь динамическим ему назначай сфера/бокс коллайдер, и двигай просто физикой, а когда столкнется уже переводи в мешколайдер.

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

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

Частично решил проблему с коллайдерами при распаковке сглаженных поверхностей (с кубиками достаточно гридика).
Проблема заключалась в том, что просвоение сложного физического коллайдера, сложного всмысле по количеству вершин и трисов, довольно натужное занятие. Даже десяток мешей с 5к вершинами в Update ощутимо просаживают фпс на моей машинке.
Ответ как всегда находился на поверхности. Поскольку у меня каждый слой меша распаковывается отдельно, ничто не мешает уменьшить чанки слоя коллайдера. По древним тестам, когда я еще колупался с объектным конструктором, 4-5к физических объектов на сцене обновляются безболезненно (после 20к уже начинались видимые просадки на 4 юньке). При размере плоскости чанка 8х8 квадратов (вместо стандартных 16х16 или еще бОльших) поверхность 512х512 покрывается всего 512 физическими объектами. Под плоскостью я подразумеваю любую поверхность которую можно покрыть слоем в 1 чанк, то есть это вполне может быть достаточно искривленная поверхность типа террейна.
А раз распаковка коллайдера не зависит от материала, то вполне достаточно одного объекта на чанк +еще 4-5к физ объектов запаса на сложные модели .

Да будет свет!
Тест воксельного minecraft like света вместе с направленным юнитековским Directional, даже тени работают , шейдеры естественно ручками писанные.
Сейчас ограничение в 15 градаций и соответствующую дальность распространения, но сам расчет не заточен конкретно на эти ограничения, то есть можно дальность повысить ну и нагрузку соответственно.

Теперь хочу электричество и простенькие механизмы попробовать.

Думал как проверить связку модулей, самое подходящим оказалось запилить лаву. Движение лавы идет за счет модуля движения воды, освещение за счет модуля освещения, при этом они полностью изолированы и даже работают в разных потоках и отключив движение - получается просто светящийся блок. Стремно то, что на расчет света из-за объема уходит в среднем в 15 раз больше времени, чем на движение, то есть огромную кучу движущегося света хрен сделать. Ну я пока не додумался как это дело можно ускорить оставив изолированность.

Светимость и освещение у Вас разные вещи? Может освещение нужно только для граничных блоков, а светимость для остальных?

Светимость и освещение у Вас разные вещи? Может освещение нужно только для граничных блоков, а светимость для остальных?

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

При расчетах я не могу заранее знать какие блоки будут рисоваться, какие двигаться и т.д., потому что все расчеты идут в глобальных назвязанных системах (назовем это сервером для простоты), а отрисовка в локальной части (назовем клиентом) и глобальная часть общается с локальной только путем передачи изменений, а локальная их приемом (ну и передачей того что натыкал курсором юзер). Все системы-обработчики изолированы внутри себя и кроме общей карты у них нет никаких данных. То есть они вообще ничего не знают за пределами себя, даже о ядре - полная изолированность, что в теории (не пробовал еще) позволяет из отключать/заменять на горячую.
А в локальной части, у одного клиента я могу рисовать все блоки, а у другого только землю и траву к примеру и как то по особому их осветить добавляя нативное Unity освещение (как сейчас) или вообще не применять параметры светимости блока.

Я имел в виду, что светимость != освещение. Ну как шейдер SelfIlluminance, который светится, но не освещает.

Это зависит от алгоритма отрисовки, может быть и =.
Вообще я подумываю для каждой грани брать максимум от собственной светимости и светимости соседа. Это актуально в случае блоков-лампочек например и тогда светимость будет равна освещению. В случае непрозрачных блоков их собственная светимость обычно = 0, так что естественно освещаться грани будут только за счет соседей.

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

Разрушаемость и физика воды выглядят очень круто. А вы это просто из интереса делаете или хотите в какой нибудь своей игре применять?
Я думаю, что многие хотели бы поиграть в Dwarf Fortress с хорошей 3д графикой (симулятор управления поселением гномов с очень продвинутой физикой).

Даже не знаю как более точно описать.
Из интереса 146% + мне нужна полностью динамичная легко НАДстраиваемая 3Д песочница, а лучше майна песочницы пока не придумали, поэтому я сейчас ориентируюсь больше на него, но только с достаточно ограниченными размерами.
Большой мир со сменой детализации я не потяну, не столько из-за геометрии (смены детализации), сколько из-за подсистем которые хочу реализовать. На большие пространства такие подсистемы все равно не рассчитаны, а вот в небольшом мирке вполне .
Выльется это в полноценную игру - врятли, у меня просто не хватит тямы на сюжет и хорошие ресурсы + я начинаю скучать когда занимаюсь чем то отличным от кодинга, хотя иногда бывает полезно отдохнуть за клепанием каких-нибудь атласов.
Скорее получится полудвиг-полупесочница, я надеюсь что получится .

Понятно)) Меня вот еще заинтересовал алгоритм воды для 2д. Сейчас в стиме популярны различные 2д игры - симуляторы с видом сверху. Например RimWorld(он еще не вышел в стиме но игра классная http://store.steampowered.com/app/294100) или Prison Architect (http://store.steampowered.com/app/233450/). Я думаю, что если сделать игру с графикой как в этих двух играх в сеттинге майнкрафта/дварф фортресса(2д симулятор создания поселения гномов с различными уровнями глубины и реалистичной симуляцией разрушения блоков и воды) то продажи будут очень большие. Хотя времени в это придется вложить изрядно конечно.

О римворлд в стиме появился, надо будет взять его.

Вот чувак пилит туторы как сделать подобную игру
https://www.youtube.com/channel/UCPXOQq ... CwEO60Y8jQ

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

bwolf88 писал(а):О римворлд в стиме появился, надо будет взять его.

Вот чувак пилит туторы как сделать подобную игру
https://www.youtube.com/channel/UCPXOQq ... CwEO60Y8jQ

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