Нуб вкатился в 3д. (2 стр)

Куб вкатывается в 3д.

TarasB
> Для софтрендера важно определиться со структурой уровня для начала.
> Порталы у тебя? Или бсп-нарезка? Или какой ещё способ не учитывать невидимые
> фрагменты уровня?
Да, я же в конкурсе был с ним, помнишь? Вот тот свой рендер немного допилил. Он умеет отбрасывать и рисовать с нулевым овердро.
По скорости на однопотоке на тысяче кубов +- как твой.

dave
> многопоточность
TarasB
> нахера на селероне это надо?
Уверен что распараллеливание надо. Все таки современные мониторы, а там где hd, а то и 4к.

/dev/null
> Если кубики всегда такие, как на скрине, то AABB vs Point/Sphere. Делается
> очень просто.
Пока не осилил. Сложно там с физикой. Пока воткнул простую проверку. Но наверное надо свой физ-движок писать, на будущее. Хоть для теста столкновений и простых штук.

122
> Он умеет отбрасывать и рисовать с нулевым овердро.
Надо отбрасывать не только грани, а целые куски уровня.

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

TarasB
> Надо отбрасывать не только грани, а целые куски уровня.
А я не знаю, как их отбрасывать.
Есть ограничение радиуса видимости, то есть вдалеке не рисуем. Пока все.
Планирую универсальный рендер, так что скажем порталы не то, это решение узкоспециальное. Может быть, есть универсальные варианты?

/dev/null
Он большой, однако. Пока не могу собраться с мыслями и выявить основу.

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

122
> 1. Центрирует она относительно экрана а не игрового окна. Как мне получить
> позицию моего окна?

case WM_MOUSEMOVE:
                GetClientRect(hWnd, &wRect);
                xPos = GET_X_LPARAM(lParam);
                yPos = GET_Y_LPARAM(lParam);
                x = (float)2 * xPos / (wRect.right - wRect.left)-1;
                y = (float)-2 * yPos / (wRect.bottom - wRect.top)+1;

Нет?

122
> Есть ограничение радиуса видимости, то есть вдалеке не рисуем. Пока все.
А как НЕ перебирать то, что за радиусом? Можно ПВС строить, но алгоритм постройки мудрёный шописец. Вот тут октодерево пригодится. А если есть октодерево, то можно вообще сразу для целых веток делать з-тест, например. Для этого желательно структуру рендера подгонять под возможность быстрого з-теста. Например, сделать з-буфер с иерархией.

Mr_Jack
Да вроде не то. Он размер окна возвращает, а зачем он мне, я его сам же и ставил.
Тут фишка вот в чем: центрируется курсор мышки относительно координат всего десктопа. А когда я получаю координаты мышки, они относительно окна. В полном экране совпадают. А в окне нет.
Как это решают белые люди?

Пока решил по-крестьянски. При старте прога центрирует курсор и снимает показания мышки. Как только кадров 5 подряд показания мышки будут идентичны, то все, эта позиция считается той что после центрирования.

TarasB
> А как НЕ перебирать то, что за радиусом?
У меня проще. Есть огромный 3d-массив, в ячейках которого хранится инфа про объекты рядом с этой ячейкой.
Таким образом чтобы рисовать только ближнее, перебираем этот массив только вблизи от камеры. Память жрет, но метод быстрый и несложный.

Попробую посмотреть про октодерево с иерархией з-буфера, но звучит морочно. А накладные расходы. Вот если это октодерево с тестами в конкурсные тысячу кубов добавить, оно фпс уронит?

Скрин.
Добавил кабину пилота. Стекла (их тут два) сразу уронили фпс с 280 до 130. Придется делать настройку, включать или нет стекла.
Зато там размытие в красном канале, преломление в синем и белая грязь в зеленом, в текстуре стекла. Удобно.

/dev/null
> на основе которого можно будет понять принципы оптимизации к примеру
Если по физдвижку, может мне проще словами будет понять.

Вот сейчас первая проблема: откуда физ-подсистема будет брать вершины геометрии? Вершины эти получать долго, да и непросто: для кубов они генерируются, например, для сложных объектов берутся из памяти хитрым образом. То есть дать физ-подсистеме список вершин - уже задача.
Один раз вершины готовятся для рендера картинки. Готовить для физдвижка их отдельно? Вроде долго. Брать те, что идут на рендер графики? Тогда физики за спиной не будет.
Как это вообще делается?

122
Тебе попроще или посложнее? Если попроще то бери кубы и сферы. Составные объекты потом можно делать. Если сложнее, то конвексы и составные тела из треугольников. Это к Суслику. Он у на физик. Я так и не распарсил алгоритм, тем более там их несколько.
В любом случае физическая модель сцены строится независимо от визуального представления. То есть ты сгенерил сцену с 1кк кубов, все 1кк кубов присутствуют на физической сцене всегда. Неважно какая часть рендерится. Оптимизация идет в движке, что я тебе кинул через AABB-дерево. Т.е. сначала пробегается по AABB дереву, чтобы найти объекты с которыми потенциально ты можешь столкнуться или столкнулся, и только потом в дело вступает более тяжелый алгоритм, вычисляющий столкнулся ли и какие силы применить к тебе и к другому объекту (если он не статический). Есть еще несколько подходов, но меня пока устраивает и этот.

122
> Он размер окна возвращает, а зачем он мне, я его сам же и ставил.
Возвращается положение окна относительно десктопа. Дальше можно все рассчитать.

> При старте прога центрирует курсор и снимает показания мышки.
Это явно не то. WinApi позволяет получить любые координаты. Максимум надо из одной системы координат перейти в другую.
GET_X_LPARAM(lParam) дает положение относительно окна приложения сразу.
GetClientRect(hWnd, &wRect) дает положение окна относительно десктопа.

Наврал немного. GetWindowRect(hWnd, &wRect) дает положение окна относительно десктопа.
GetClientRect(hWnd, &wRect) дает размер клиентской части.

122
> Есть огромный 3d-массив
Ну это не очень эффективно по памяти, особенно если уровень неоднороден.

122
> Попробую посмотреть про октодерево с иерархией з-буфера, но звучит морочно. А
> накладные расходы. Вот если это октодерево с тестами в конкурсные тысячу кубов
> добавить, оно фпс уронит?
Расходы на что? Дерево строится при инициализации уровня. Иерархия з-буфера - это морочно? Это просто одна из реализаций быстрого з-теста.

TarasB
> Расходы на что?
Я не знаю на что расходы, вот спрашиваю. На попытки отбросить ненужные ветки, может быть на организацию данных.

Mr_Jack
> Наврал немного. GetWindowRect(hWnd, &wRect) дает положение окна относительно
> десктопа.
Да, это ближе. А с ним не было проблемы того, что он не учитывал часть рамки окна при разных стилях винды? Вот типа такого: линк

+++

Картинка для отвлечения внимания.

Архив.