Войти
ПрограммированиеФорумГрафика

Объединение мешей с удалением невидимых треугольников. (3 стр)

Страницы: 1 2 3 4 5 Следующая »
#30
0:46, 22 июня 2019

MrShoor
> Чтобы определить лежит ли вершина внутри другого меша - можно пустить луч из
> вершины в любую сторону. Если получится четное количество пересечений - то
> вершина снаружи, если нечетное - то вершина внутри.
Ну вообще можно сказать, что такой алгоритм не будет работать, если луч случайно пересечёт вершину какую-то или прямоугольник, но вероятность очень малая.

#31
11:41, 22 июня 2019

MrShoor
> Все треугольники, у которых 3 вершины помечены - выкинуть.
Тор. в центре тора треугольник, вершины которого находятся внутри, при этом сам треугольник виден снаружи. Твой алгоритм его удалит.
Он рабочий только для convex hull геометрии.

#32
12:12, 22 июня 2019

0xc0de
Я тоже при просмотре многочисленных Speed Level Design задался этим вопросом = слишком уж много получается скрытой геометрии.
Где-то встречалось, что во многих играх очень плохо оптимизированы локации, и вот не этот ли момент там нагружает их?
Но действительно обратной стороной медали получается хранение и загрузка всех обработанных моделей, а это огромный минус.
Единственное пока что пришло на ум = это объединять в редакторе модели, входящие друг в друга, в одну = ландафт, здания и прочее.
Здесь уже, как ты написал вначале, нужно вычислять границы и обрезать всё стык в стык, но это нужно научиться собирать в одну и все соответствующие друг другу текстуры (альбедо и т.д.).
Можно ограничивать размеры получаемых моделей, чтоб не выходили огромные модели и текстуры, но тут наверняка тоже есть подвох, как минимум они будут реже отсекаться пирамидой видимости и Occlusion Query.

#33
14:03, 22 июня 2019

Daniil Petrov
> Можно ограничивать размеры получаемых моделей, чтоб не выходили огромные модели
> и текстуры, но тут наверняка тоже есть подвох, как минимум они будут реже
> отсекаться пирамидой видимости и Occlusion Query.
противоречишь сам себе, чем меньше модель тем больше шансов что она не попадет на отрисовку. В идеале вся статик геометрия сшивается в одну, после чего режется на чанки регулярных размеров. Единственное разделить полупрозрачную с непрозрачной.

#34
14:21, 22 июня 2019

Aroch
Ну я о чём и говорю, что по идее нужно просто оптимизировать рендер, а модели не трогать.

#35
15:12, 22 июня 2019

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

#36
15:14, 22 июня 2019

Aroch
> Тор. в центре тора треугольник, вершины которого находятся внутри, при этом сам
> треугольник виден снаружи. Твой алгоритм его удалит.
Да ну с чего бы мой алгоритм его удалит? Лучи, пущеные из вершин этого треугольника пересекут тор 2 или 0 раз. Это чётное число, а значит вершины видимы. А если хотя бы одна вершина видима - треугольник удалять нельзя.

#37
15:36, 22 июня 2019

MrShoor
> Да ну с чего бы мой алгоритм его удалит?
Сделай плазменный пистолет, который это дело будет резать, как сливочное масло :)

#38
17:19, 22 июня 2019
Но действительно обратной стороной медали получается хранение и загрузка всех обработанных моделей, а это огромный минус.

ага, экономим сотни килобайт на необрезанных моделях, потом запекаем загружаем и храним десятки мегабайт левых лайтмапов. Ну и рендерим тонны того, что не видно. 


#39
19:14, 22 июня 2019

MrShoor
> Да ну с чего бы мой алгоритм его удалит? Лучи, пущеные из вершин этого
> треугольника пересекут тор 2 или 0 раз. Это чётное число, а значит вершины
> видимы. А если хотя бы одна вершина видима - треугольник удалять нельзя.
нет, все вершины треугольника внутри тора, твои лучи пересекут его всего один раз. Ты не можешь представить тор и треугольник в центре него так чтобы вершины треугольника были внутри бублика? Мне что картинку рисовать?
Держи:
concav_hull_vs_triangle | Объединение мешей с удалением невидимых треугольников.

#40
21:19, 22 июня 2019

Само по себе количество треугольников не особо нагружает картинку, поэтому из этой технологии можно выжать 1) лайтмапу 2) батчинг

В UE4 это реализовано в виде тулзы proxy geometry. Штука офигенная, но очень ситуационная. Она сшивает объекты, значительно понижая полигонаж, сшивая текстуры и материалы, в итоге получая 1 DC с кучи объектов. Обычно используется для среднего и дальнего плана. Минус: жрёт память как не в себя.

Но по-моему там нет возможности сшить объекты, просто удалив при этом невидимые полигоны.

В конечном итоге для ПК, мне кажется, проще грамотно настроить левел стриминг и стримить текстуры лайтмап, чем сидеть там как-то мержить все камни только ради экономии места лайтмапы. С этим давно никто не заморачивается, и игры по 70 гигабайт уже не редкость :)

Зато в мобилках это принципиально. У нас в проекте лимит в одну 1024 лайтмапу на один игровой уровень, и чтобы из неё выжать красивый свет - надо упарываться. По мере возможности удаляем невидимые полигоны и мерджим объекты. Вот здесь такая тулза вполне полезна.

Плариум писал под это тулзы: https://habr.com/ru/company/plarium/blog/348494/

#41
0:08, 23 июня 2019

Aroch
> нет, все вершины треугольника внутри тора, твои лучи пересекут его всего один
> раз. Ты не можешь представить тор и треугольник в центре него так чтобы вершины
> треугольника были внутри бублика?
А, ты про такой случай. Ок, да, в таком случае могут быть проблемы. Я думал о таком варианте на самом деле, но такое решается только реальным поиском пересечения треугольников, что достаточно дорого, а таких кейсов я тумаю у ТС будет катастрофически мало.

#42
0:56, 23 июня 2019

maks242
> Ну вообще можно сказать, что такой алгоритм не будет работать, если луч
> случайно пересечёт вершину какую-то или прямоугольник, но вероятность очень
> малая.

имелось в виду ребро а не прямоугольник? про прямоугольник непонятно
решается кэшированием точек пересечения, при этом за точку пересечения не считаем если точка находится внутри некоторой малой дельты дистанции уже существующих точек пересечений

#43
2:29, 23 июня 2019

Polyflow3d
> ага, экономим сотни килобайт на необрезанных моделях
Парень не понимает, что пишет :) вместо одной модели предлагает хранить кучу её огрызков, которые и места на диске / в памяти гораздо больше займут, и грузиться будут в несколько раз дольше )))
На счёт запекания лайтмапов разговор отдельный, я с ними ещё не разбирался, но хранить и грузить тонны огрызков одной и той же модели точно не айс!

#44
7:31, 23 июня 2019

Daniil Petrov

Парень не понимает, что пишет :) вместо одной модели предлагает хранить кучу её огрызков, которые и места на диске / в памяти гораздо больше займут, и грузиться будут в несколько раз дольше )))


Читай по слогам : "огызки" занимают килобайты мешей, а экономят мегабайты лайтмапов.
Сравнить можешь килобайты с мегабайтами?
Или у вас, имбицилов, там в голове какая-то альтернативная арифметика? 

На счёт запекания лайтмапов разговор отдельный, я с ними ещё не разбирался, но хранить и грузить тонны огрызков одной и той же модели точно не айс!

так че ты лезешь тогда со своим нубским мнением, если ты не разбирался ?
Что б ты знал - для оптимизации делают аж по 5 огрызков одной и той же модели - эти огрызки LOD-ы называются. А потом еще и свитчат их в рантайме. Прикинь?

arte_de_mort

Само по себе количество треугольников не особо нагружает картинку, поэтому из этой технологии можно выжать 1) лайтмапу 2) батчинг

ага, не нагружает.
А в серьезных проектах люди долбятся с лодами и импостерами от нечего делать. 

Страницы: 1 2 3 4 5 Следующая »
ПрограммированиеФорумГрафика

Тема в архиве.