Точечные источники освещения отбрасывают очень уж жёсткие тени. Для теней многоугольников можно упростить рейкастинг, например, как тут ncase.me/sight-and-light.
Мягкие тени сделать сложнее, т.к. источник света не точка, а, например, отрезок. И вместо видно/не видно точку нужно считать под каким углом виден отрезок освещения из точки (получается как-бы обратный рейкастинг от точки к источнику/ам освещения). Хотя это и вычислительно сложно, можно заранее «запечь» карту освещения для статических источников.
«а падение производительности было внушительным»
Думаю для Roguelike можно скрыть падение производительности, заранее посчитав тени для позиций на смежных клетках (т.к. игрок двигается по целым клеткам), и делать плавный переход между уже готовыми картинками. Большую часть реального времени мир статичен, и если он выглядит хорошо, то этого, пожалуй, достаточно.
Можно не останавливать луч при контакте с поверхностью, а лишь «ослаблять» его ярокость в зависимости от пройденного «внутри» поверхности пути (как в тумане, луч вошёл в тучку :) )
Тогда тени будут мягче. Картинка темновата, вне контакта с препятствиями яркость можно не менять. Думаю что для плотного леса должно хорошо смотреться, т.к. будет видно что все деревья как-то участвуют в построении тени, а не только первый ряд, который всё перекрыл
Это не очень «реалистично» :).
Обычно в основе реалистичности лежит какая-то модель, приближённая к реальности, ну например:
— деревья перекрывают (k) половину освещённости
— соответственно два дерева перекроют k*k, три k*k*k и т.д. (получается не альфа смешивание, а просто умножение на коэффициент «тени»)
— рассчитанный коэффициент пересчитывается для гамма-кодированных значений цвета и уже по нему делается альфа-смешивание.
Ну какой-то такой «реализм» :)
Но она на то и пирамида, что на большой крепкой основе надстраиваются новые уровни, их нельзя просто взять и искусственно убрать / игнорировать. Удовлетворение потребностей более высокого порядка не идёт в ущерб более низким, они всё равно учитываются. Если для небиологического существа этих более низких уровней нет, то они и не будут учитываться. Пока с базовыми потребностями нет проблем — эта особенность будет скрыта при решении общих потребностей высокого порядка, но в долгосрочной перспективе это может привести к серьёзным последствиям.
Вот как раз я и хотел поднять вопрос стимулов. Продуктивное взаимодейсвие требует общих интересов. Если человеческая пищевая цепочка объективно не требуется для небиологических людей, то они не будут непосредственно заинтересованы в её развитии, ведь для них это лишь искусственная проблема. Гораздо интеллектуальнее заниматься объективными и естественными проблемами своего собственного существования, развивая, например, производство электричества.
Если небиологические люди будут иметь другую пищевую цепочку и эта пищевая цепочка не будет пересекаться, то в чём будет их объективная заинтересованность в сохранении человеческой?
По логике когда пользователь доскроллил до изображения, то он ожидает увидеть его уже загруженным, значит загружать его надо раньше, чем область просмотра зацепит край изображения. И тем раньше, чем больше размер изображения. Это можно решить отдельной «увеличенной» областью, по которой будет начинаться загрузка.
GLSL проделал довольно долгий путь к вебу, за это время создано множество инструментов для работы с ним, полностью поддерживающими подмножество языка для WebGL.
Хотя
Можно считать количество каждого встречающегося значения 0-255 в массиве и по этой статистике уже пересчитывать разные варианты «усреднения», не сканируюя всю картинку заново, раз «усреднение» всё равно поканальное. Хотя это скорее оптимизация для больших размеров картинки.
Поскольку это производные от изображения данные, их можно рассчитать заранее (Каким-нибудь ImageMagick, например) и передавать уже готовые рядом с картинкой. Онлайн-рассчёт это хорошо, но пользователи устройств с питанием от аккумулятора, возможно, будут недовольны раходом батареи :(
Как-то это сложно и непонятно зачем.
Возможно, когда шейдеры ещё были медленными, хитрое использование сэмплера текстур и давало какие-то ощутимые вычислительные преимущества, однако сейчас какой смысл читать четыре текселя, если коэффициенты можно явно читать с RGBA одного?
Невидимые части делятся на две категории:
1 Находящиеся сзади модели.
Полагаю что это и есть полигоны для Backface culling, они отбрасываются не потому что чем-то заслонены, а просто по ориентации, т.к. рисуются только с одной стороны.
По времени непосредственно на отрисовку — один рендер на ракурс всего. В пиксельный шейдер прокидывается индекс треугольника и по нему выставляется цвет фрагмента, меш рисуется целиком.
Приведённый алгоритм выглядит не очень эффективным — для одного треугольника делать рендеринги со всех позиций?
Для каждого треугольника можно писать в буфер цвета его индекс, чтобы потом из картинки найти полный набор отображаемых треугольников. Дополнив этот набор со всех позиций — убрать те треугольники, индексы которых не встречались.
Мягкие тени сделать сложнее, т.к. источник света не точка, а, например, отрезок. И вместо видно/не видно точку нужно считать под каким углом виден отрезок освещения из точки (получается как-бы обратный рейкастинг от точки к источнику/ам освещения). Хотя это и вычислительно сложно, можно заранее «запечь» карту освещения для статических источников.
Думаю для Roguelike можно скрыть падение производительности, заранее посчитав тени для позиций на смежных клетках (т.к. игрок двигается по целым клеткам), и делать плавный переход между уже готовыми картинками. Большую часть реального времени мир статичен, и если он выглядит хорошо, то этого, пожалуй, достаточно.
Тогда тени будут мягче. Картинка темновата, вне контакта с препятствиями яркость можно не менять. Думаю что для плотного леса должно хорошо смотреться, т.к. будет видно что все деревья как-то участвуют в построении тени, а не только первый ряд, который всё перекрыл
Обычно в основе реалистичности лежит какая-то модель, приближённая к реальности, ну например:
— деревья перекрывают (k) половину освещённости
— соответственно два дерева перекроют k*k, три k*k*k и т.д. (получается не альфа смешивание, а просто умножение на коэффициент «тени»)
— рассчитанный коэффициент пересчитывается для гамма-кодированных значений цвета и уже по нему делается альфа-смешивание.
Ну какой-то такой «реализм» :)
Хотя
Поскольку это производные от изображения данные, их можно рассчитать заранее (Каким-нибудь ImageMagick, например) и передавать уже готовые рядом с картинкой. Онлайн-рассчёт это хорошо, но пользователи устройств с питанием от аккумулятора, возможно, будут недовольны раходом батареи :(
Возможно, когда шейдеры ещё были медленными, хитрое использование сэмплера текстур и давало какие-то ощутимые вычислительные преимущества, однако сейчас какой смысл читать четыре текселя, если коэффициенты можно явно читать с RGBA одного?
Полагаю что это и есть полигоны для Backface culling, они отбрасываются не потому что чем-то заслонены, а просто по ориентации, т.к. рисуются только с одной стороны.
По логике они являются источником отражений света, но в самой карте не нужны.
Для каждого треугольника можно писать в буфер цвета его индекс, чтобы потом из картинки найти полный набор отображаемых треугольников. Дополнив этот набор со всех позиций — убрать те треугольники, индексы которых не встречались.