3D.ru

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

На видео уже тест с подключенной системой воды. Тест пока в пределах одной машины, но работает пока достаточно быстро. Самое приятное, что API самого двига почти не менялось, значит последнее решение получилось не плохим. Но из за сетевой передачи внутри слишком много конвертаций происходит, так что пару дней потрачу на вылизывание кода, а после уже попробую на двух-трех компах запустить. Стараюсь пилить сразу с расчетом на легкую замену "транспорта" сервер/клиента.

У!!! Молодца! Затащил!!!

Что за тип сети стандартная юнитевская?

lawsonilka писал(а):Что за тип сети стандартная юнитевская?

Нет, своя на сокетах.

bwolf88 писал(а):

lawsonilka писал(а):Что за тип сети стандартная юнитевская?

Нет, своя на сокетах.

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

bwolf88, скажите, а сталкивались ли вы с проблемой ограничения количества вершин в меше, если в сгенерированном меше было больше ~65000 вершин то юнити выстреливал ошибку. Если да то как вы решили эту проблему?

Gypnori писал(а):bwolf88, скажите, а сталкивались ли вы с проблемой ограничения количества вершин в меше, если в сгенерированном меше было больше ~65000 вершин то юнити выстреливал ошибку. Если да то как вы решили эту проблему?

Ограничиваю размер меша.
Каждый куб имеет 24 вершины.
Самый плохой расклад, когда кубы расположены в шахматном порядке, тогда рисуются все треугольники и вершины куба.
В шахматном порядке количество кубов это половина от всех.
А дальше простой рассчет, допустим стандартный майнкрафтовский чанк:
((16х16х16) х 24 вершины) / 2 = 49152 вершины, что вполне подходит.

Значит всё таки 16х16х16 чанк, просто и на ветке геймдейва http://www.gamedev.ru/code/forum/?id=161884, и ещё в нескольких источниках я встречал информацию о том что более кошерно использовать чанки 32х32х32, хотя так толком и не понял какая от них польза .
У меня к вам ещё такой вопрос, вот много поднималось тем освещения, рендера, структуры воксельных движков, но очень мало информации по физике, в юнити при создании нового меша, в смысле при передачи в меш уже готовых параметров на мешрендер уходило 1 - 2 мс, на меш коллайдер 24 - 28 мс. В той же ветке на геймдейве много людей говорило что они используют свои физ. движки, в том числе и те кто сидит на юнити, я погуглил на эту тему, но ничего толкового не нашел, да используются специальные параллелепипеды в которые помещаются объекты, просчитывается их столкновения, если столкновение произошло то просчитываем более точно по вершинам (тут вообще кроме расчета примитивов типа сферы, куба и капсулы я ничего не нашел, как например работать с объектом типа меша чанка), но главный вопрос как быть с оптимизацией, вот человек сделал систему столкновений на opengl https://www.youtube.com/watch?v=Lg0kOoiCI80, и сделал два варианта одна в лоб просчитывает все объекты каждый кадр, вторая через октодерево, при нескольких сотнях объектов всё тормозит что с деревом что без (смотрите в конце ролика), а ведь там нету ни гравитации, ни трения, ни джоинтов, просто внутри куба произвольно болтается сотня объектов. До этого я даже не интересовался как устроен физический движок и думал что PhysX так не важно работает потому что расчитывает множество разных факторов и сил, и что если сделать движок в котором будет только гравитация, проверка столкновений и раейкастинг, он будет работать ещё шустрее рендера, а сейчас даже не знаю что делать, пока что я отказался даже от попыток сделать свой велосипед т.к. думаю что он у меня получится с одним квадратным колесом. Правда я так и не пробовал оптимизировать меш колайдеры гридиком, может если на нём радикально сократить количество полигонов он станет работать быстрее. Хотелось бы услышать ваше мнение на этот счёт.

и ещё в нескольких источниках я встречал информацию о том что более кошерно использовать чанки 32х32х32, хотя так толком и не понял какая от них польза

Можете юзать и 32х32х32, но тогда в любом случае даже используя алгоритмы упрощения геометрии будет вероятность поймать эту ошибку.
Второй момент - физический движок достаточно узкое место и создание мешколлайдера более 12-15к вершин будет ощутимо бить по производительности.
Я для себя установил планку в 10к, обновление такого мешколлайдера проходит достаточно незаметно. Естественно любые меш коллайдеры рекомендуется максимально упрощать.
Самый простой способ для кубических мешей использовать гриди алгоритм, но даже он не спасет при шахматной расстановке блоков. Гридик очень хорош на относительно плоских или средней сложности поверхностях, на сложных - получите практически обычный кубочанк, только с бОльшими расчетами.
Второй способ это ограничить чанк мешколлайдера размерами 8х8х8 (для кратности со стандартным МК чанком). Получите 4 физических чанка на 1 визуальный. У меня свой контроллер мешей и нет зависимости визуальной и физической составляющей конечного меша. Нет зависимостей даже между визуальными мешами разных категорий. То есть я могу построить визуальные чанки 32х32х32, а физические 13х16х19 или сделать визуальную часть кубической, а физическую сглаженной и все будет работать и обновляться только та область, которая изменена в соответствующей категории.

По поводу своих физических движков - физикс вы не переплюнете 100%, но можно сделать свой воксельный псевдофизический движок с вокселькастингом, который будет ориентироваться исключительно на воксельную информацию, а не меши, тогда вам вообще не нужны будут коллайдеры. У меня так к примеру работает курсор )).

Подскажите пожалуйста, почти осилил Marching Cubes, меш строится, но он очень уж "кубический". Как его сгладить?



Код: http://pastebin.com/3Zkv12AZ

-------------

Всё, разобрался, у меня была кривая функция Density.

Фигачу редактор воксельных объектов.
Есть аналоги - PicaVoxel например, но я буду добавлять редактирование не только цветных кубиков.
Пилю чуть больше пары недель поэтому сделаны только базовые фичи:
- импорт с Magica Voxel (.vox) и картинок
- Транформации воксельной карты - ресайз, поворот, отражение, смещение
- Несколько вариаций распаковки меша - гриди кубы, Marching Cubes с фиксированным объемом (правда убого с покраской получилось) и мой Surface алгоритм пока тоже с фиксированным объемом и без гриди
- Рисование: добавление, раскраска, удаление вокселей в нескольких вариациях - Бокс, кисть, вытягивание и заливка. Все это можно проделывать в любом скейле и повороте объекта
- Можно сохранять в префабы (пришлось свои меш объекты чутка переделать) и использовать как воксельные объекты в рантайме изменяя геометрию. Рантайм курсор пока не сделал, но на видео в редакторе я модифицирую в рантайме.

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

Пока это выглядит так:

bwolf88 Здравствуйте, прочитал что в новой версии ввели массивы текстур и что это должно решить проблему с артефактами от мипмапов, не знаете так ли это, пробовали ли вы использовать эти массивы? А то я уже с горя на LWJGL переходить собрался

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