screen space planar reflection. Это трассировка отражения по поверхности (как SSR),
+ самый быстрый метод рендеринга отражений для воды в рантайме. В отличии от классического SSR тут нет реймарчинга.
+ pixel-perfect метод рендеринга в сравнении с другими методами SSR.
+ работает в forward режиме, так как не требуются нормали и достаточно буфера глубины.
- работает только на плоских поверхностях, игнорируя нормали.
- артефакты свойственные скринспейс техникам.

Планарные отражения
+ нет артефактов как у SSR
- дорого
- имеют те же минусы с нормалями

Кубмапа окружения.
+ самый существенный плюс, это отражение более приближенное к реализму.
+ можно рендерить десятки источников света за одно чтение кубической карты в шейдере. Не нужно городить огород из массива источников света, тайлингом, pbr бликами и т.д. Визуально выглядит физично, например солнечные дорожки.
+ можно рендерить источники света разной формы. Например всякие неоновые лампы, притом опять же с реалистичным бликом. Хотя можно пойти дальше и опять же рендерить всю сцену :)
+ можно запечь дальние планы (горы/небо)
+ можно объединить статичные кубмапы с ssr.
+ можно интерполировать отражение между несколькими статичными кубмапами.
- Рендерить её в рантайме очень дорого, хотя можно сделать пару оптимизаций (например рендерить только видимые стороны/рендерить стороны в разных кадрах/и т.д.)
- Так же проекция кубмапы захватывает и область под водой, что вываливатся в артефакты, когда дно перекрывает всё отражение.

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

Собственно вопрос как можно побороть минусы?
Можно ли как-то рендерить физически коректные нормали в screen space planar reflection?
Как избавиться от артефактов кубмапы ниже плоскости воды? Городить огород из плоскостей отсечения при рендеринге сторон? Есть ли способ проще?

Правка: 11:23

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

Почему такое происходит, я понимаю:

Попытался считать не столкновение с треугольником, а с треугольной призмой с утолщением внизу:

Думал, поможет, но результаты неудовлетворительны, работает криво.

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

Как вы с таким боретесь?

Правка: 6:17

На сколько я знаю это классическая задача комиваяжера (без ограничения посещения вершин) ?
И она не имеет эффективного решения (NP сложность). Или это ни так?

На вскидку: найти пути до каждой голды, выбрать минимальный, найти от этой голды снова до остальных, минимальный.. В общем жадный алго. За один проход я чтото не вижу решений.

Правка: 6:57

Хочется проехаться на волне ностальгии и запилить дему в стиле оригинальной Кваки и грядущего Wrath: Aeon of Ruin. Какое двигло подобрать?

Сама первая Квака—по идее, самый труъшный вариант, но не хочется связываться с архаичным BSP tree и системой порталов. Плюс—должны быть диалоги и заскриптованные сцены, а я уже не помню, насколько гибок QuakeC и насколько можно с его помощью "расширить и углубить" геймплей.

Требования:

1. Визуальная эстетика первой Кваки.
2. Жанр—action/adventure, т.е. и пострелять, и покастовать спеллы, и поюзать предметы.
3. Диалоги и заскриптованные сцены.

Правка: 19:54

Пробую инпортировать в UE4 свою простую скелетку, но что-то идет не так. Создал куб 100x100x100см, скелет из 2х костей, добавил 1 экшн анимации, экспортирую.

Рассмотрим пример:
Мы вращаем объект A, создаем операцию, которая хранит предыдущее и текущее состояние трансформации и ссылку(sharedptr) на объект A.
Следующим действием мы удаляем объект A и создаем операцию, которая хранит атрибуты объекта, чтобы можно было его создать заново при undo. Тут возникает проблема, что предыдущая операция хранит ссылку на удаленный объект, т.е. объект все еще живой, но его нет в сцене, при этом в сцену при undo добавляется новый объект - копия старого, на который все еще указывает sharedptr предыдущей операции вращения объекта.

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

Другой вариант, который приходит в голову - поместить объект в некую обертку:

class ObjectLink : public RefCounted
{
   Object * pObject;
};

Третий вариант - хранить не указатели, а уникальные идентификаторы объектов, а сами объекты доставать их хэша.

Посоветуйте, как лучше сделать.

Правка: 15:39

const int N = 4;
const int tile_size = 64;
int grid[N][N] = {};

int width = tile_size * N;
int height = tile_size * N;
int xpos = 0;
int ypos = 0;

int pixel_x;
int pixel_y;

int n = 0; 
for (int i = 0; i < N; ++i) {
  for (int j = 0; j < N; ++j) {
    n++;
    grid[i + 1][j + 1] = n;
  }
}

void cursor_position_callback(GLFWwindow* window, double x, double y)
{
  xpos = static_cast<int>(x) / tile_size;
  ypos = static_cast<int>(y) / tile_size;
}

void mouse_button_callback(GLFWwindow* window, int button, int action, int mods)
{
  if ((button == GLFW_MOUSE_BUTTON_LEFT) && action == GLFW_PRESS)
  {
    int dx = 0;
    int dy = 0;

    if (grid[xpos + 1][ypos] == 16) { dx = 1; dy = 0; };
    if (grid[xpos][ypos + 1] == 16) { dx = 0; dy = 1; };
    if (grid[xpos][ypos - 1] == 16) { dx = 0; dy = -1; };
    if (grid[xpos - 1][ypos] == 16) { dx = -1; dy = 0; };

    int n = grid[xpos][ypos];
    grid[xpos][ypos] = 16;
    grid[xpos + dx][ypos + dy] = n;

    std::cout << "Cursor position at (" << xpos << " : " << ypos << ")\n";
  }
}

Правка: 16:34