Проекты
GameDev.ru / Проекты / Форум / Прототипы, демо, свой движок (3 стр)

Прототипы, демо, свой движок (3 стр)

Advanced: Тема повышенной сложности или важная.
Страницы: 1 2 3
RostislavPПостоялецwww17 окт. 20181:54#30
Как собирается сам проект, VS не используется (только для дебага), так как он все только усложняет. Батч файл, пара команд и все готово, ничего не нужно искать через 100500 меню, все всегда под рукой.

Изображение

Правка: 17 окт. 2018 4:28

RostislavPПостоялецwww17 окт. 20182:09#31
Скрин из редактора и вопрос, может кто смог бы дать что нибудь почитать по оптимизации коллизии для частиц или какие вообще сейчас тенденции по системам частиц?

Изображение

Правка: 17 окт. 2018 4:33

RostislavPПостоялецwww17 окт. 20183:31#32
Вообще в планах есть идея сделать свой небольшой билд тул, сериализацию + компиляцию в самом проекте. С минимуом внешнего воздействия. Типа, сразу в коде мы пишем что мы хотим собрать и это же собираем используя тот компилятор который мы указали. Там же указываем библиотеки и другие зависимости. Примерно в таком ключе я сам и работаю, имея под рукой только командную консоль и "блокнот" (emacs). Для собственного использования так или иначе пишу, но хотелось бы знать - интересно ли это кому-то еще, или всех вполне устраивает cmake, vs и другие тулзы, которые требуют глубокого погружения в их "эко"-систему для организации проекта, вместо того что-бы на знакомом себе языке (C/C++) писать, то что конкретно нужно сделать?
Mr FПостоялецwww17 окт. 201811:14#33
RostislavP
О, я делал снежок с коллизией LostFrame'у для игры)
Рисуешь в текстуру карту высот, достаточно только видимые сверху объекты. Если локация мелкая, можно вообще 1 раз на старте это сделать, если большая - обновлять при смещении камеры на метров 5. Обновление можно размазывать на несколько кадров.
С картой высот уже можно накодить, чтоб он не падал сквозь всё, при этом хранить промежуточный стейт нигде не надо, достаточно чисто вертексного шейдера на облаке квадов и текущего времени.
Кроме того ещё можно делать коллизию с экранной глубиной, но со снегом это не очень годится. Я думаю попробовать такое для всяких обломков отлетающих, стёкол бьющихся.
Делать какие угодно частицы на ЦПУ я бы точно не стал ни при каких обстоятельствах.

Правка: 17 окт. 2018 11:19

RostislavPПостоялецwww17 окт. 201812:41#34
Mr F
Отличная идея. Только тут геймплейно важно чтобы частицы всегда падали даже там куда камера не смотрит + нужно знать о столкновении на cpu...

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

RostislavPПостоялецwww9 ноя. 20180:28#35
Парочка простых эффектов: объемный свет и потоки воды

Изображение
Изображение

DanilwПользовательwww9 ноя. 20185:08#36
>какие вообще сейчас тенденции по системам частиц?
хавок физикс в 2002 на 1ггц селероне сотни частиц с геометрией(всей сцены) сталкивал в играх под xbox(самый первый) без тормозов
очевидно что любая физикс либа потянет (я тыкал box2d, ок спокойно дает работать с десятками тыщ частиц одновременно с малой нагрузкой на CPU)
RostislavPПостоялецwww12 ноя. 201811:35#37
Danilw
Ну вот тут bullet съедает +-10ms на новом i5'ом. Плюс это еще зависит от общей сложности сцены.

Как минимум с голым bullet, в сложной сцене, явно нужно переносить расчет с cpu.

Страницы: 1 2 3

/ Форум / Проекты / Оцените

2001—2018 © GameDev.ru — Разработка игр