трава, ландшафт, большие пространства

[f0x]

Впилил намедни в двигло, кроме прочего, фруструм куллинг и лоды (да, я тормоз, знаю, не пинайте ногами). Сцена сразу забегала в 60фпс с прекрасной детализацией ближнего плана. Это я про деревья и прочие крупные объекты.
А вот с травой - проблема, и не одна.
Видяха-то успевает ее нарисовать на разумную дистанцию перед камерой. А вот процессор подготовить данные - нет, в итоге фпс падает на пол.
Понятно, что анализировать надо не всю карту распределения травы а только часть около камеры, но я что-то недогоняю как вычислить требуемый кусок, т.е. область в карте по положению камеры.
Вторая головная боль - большие дельты по высоте в ландшафте: если делать меш травы большим куском (чтобы не умереть на ДИПах инстансов), выходит так что квадратный-плоский кусок травы лежит на наклонном ландшафте, что, понятно, ни в какие ворота не лезет((
"Мельчить" куски не получается и по другой причине - размерность ячейки сетки ландшафта и ячейки карты распределения сильно больше, чем адекватный размер блока травы.
Ну и сверху, есть опасение что разгрузив процессор, так или иначе нагружу больше видяху, и воз останется на том же месте.
Так что не помешали бы какие-нибудь соображения на этот счет. И да, "длинные" решения не подходят ибо заточка под 64к и раздувать код не хотелось бы.
_________________
кто сделал демку тот и выиграл (с) uncle night (?)

[Mikle]

[f0x]

Mikle, а можно ссылочку на QTree? гугл выдает что-то не относящееся к теме(((
И еще вопрос, если делать "сдвиг" - то по двум осям. Как описать его, учитывая некоммутативность 3д-преобразований, в матрице?
_________________
кто сделал демку тот и выиграл (с) uncle night (?)

[Mikle]

[f0x]

У меня так и так данные из скаттера попадают в инстансер, в котором объект допиливается матрицами, так что лучше через них.
Идея с наклоном выглядит здраво, попробую реализовать - сам рельеф пока без лодов, но выглядит для моих задач неплохо (возможно попробую еще с меш репроекцией, но это уже детали).
Почитал по quadtree, понял о чем ты, но кажется это не тот случай. У меня алгоритм такой:
на гпу строится карта расположения (2д), скаттер ее читает (есть ключ, зона ошибки, джиттеры, вобщем все что надо), и выдает наружу массив координат (строится 1 раз).
затем рисуются инстансы, принимая координаты из этого массива. если бокс объекта не проходит фруструм куллинг - отрисовка не выполняется. Но точки всегда перебираются все.
пачки инстансов рисуются в несколько проходов (по числу лодов) с отсечением near/far (отсечка внутри фруструм куллинга) от ближних к дальним, так что переключение вертекс-буфера происходит 1 раз на каждый уровень лода. В принципе можно сделать аддитивный лод (добавлять детали а не менять буфер), но это ситуацию не меняет в целом.
Для деревьев работает неплохо - инстансов не запредельно много, зона видимости большая, среднее отношение проверок к отрисовкам примерно 3/1.

Поскольку есть карта распределения, я так понимаю что можно брать информацию из xz позиции камеры, и далее читать квадрат или окружность определенного радиуса, но не совсем догоняю как из матрицы камеры (при работе в редакторе - он ничего не знает о pos/lookat, есть только рабочая вью матрица) получить эти самые xy и затем перевести в пространство карты, чтобы заново построить массив координат. Нужно ли учитывать масштабирование? Как учитывать удаление от поверхности?
_________________
кто сделал демку тот и выиграл (с) uncle night (?)

[Ized]

Rendering Countless Blades of Waving Grass

Если у тебя CPU bound, то нагружай сильней видяху - переноси все, что можно на GPU. И надеюсь, ты используешь хардварный инстансинг?

[f0x]

Ized, спасибо, читаю...
Инстансинг... говно у меня инстансинг. Но я исправлюсь)

upd: технику эту знаю, уже попробовал, все норм,заморочка не в этом.
_________________
кто сделал демку тот и выиграл (с) uncle night (?)