Войти
ФлеймФорумОбщее

Пароль на архиве с исходниками Game7? (4 стр)

Страницы: 1 2 3 4 5 6 7 Следующая »
#45
14:04, 28 мар. 2005

CyberZX
Сайба. Это не яд. Это стеб. Но не над маленькими. А над всеми, кто думает, что нам было просто. И что мы эту игру сделали играючи. А Флаю не помешает, как ты выращаешься, такой пиар. Ему любой не поешает. И вообще, любые обсуждения, включаяя эту ветку, лишь макушка айсберга. Если ты посмотришь на картину целиком (а это с твоей точки зрения просто не возможно), то тебе откроется банальная истина. В нашей жизни каждый устраивается как может. И когда ему начинают вставлять палки в колеса, пусть и детки, то злость контролировать не просто. В лучшем случае, начинаешь стебаться над детками, в худьшем, кидаться с них какашками.
Так что когда я начинаю так себя вести, это лишь результат, которого все ждут. Ну а раз ждут, пусть его получат.


#46
14:10, 28 мар. 2005

CyberZX
> будь гордым, делай свое. делай лучшее.

Вот это отличные мысли! Сделаем своё!

Как говорится: "Надерём задницы!"

#47
14:14, 28 мар. 2005

Лично мне вообще пофигу, что здесь говорят и что думают обо мне в частности. Тем более большинство - дети. Я с этого жука уже многое получил (речь не о X800). И это только начало... А весь этот стеб иногда доставляет нам удовольствие и поддерживает дискуссию об игре :-)

#48
14:17, 28 мар. 2005

Zulus
"А то что в этой ветке происходит, называется управляемый Флейм. Пока он интересен мне и Флаю, он будет жить. Как наскучит, можно будет его медленно свести на нет. "
Достойно Наполеона :).

#49
14:27, 28 мар. 2005

CyberZX
Я всё это учитывал.
Тем более, я же не предлагаю выводить один треугольник за батч.
Ну сам посуди, на средних видюхах (Radeon9200-9600 / GF FX) рекомендуют 500 батчей, а в этой игре их 50-70. Почему число батчей нельзя увеличить в 2-4 раза?
Ведь при таком сравнительно малом их кол-ве при параллельной работе CPU и GPU, реcурсы процессора останутся частично невостребованы, а GPU будет несколько перегружен невидимой геометрией, т.е. будет опережать CPU.
Речь тут идёт не о направлении оптимизации, а об её оптимальности. "Всё есть лекарство и всё есть яд, важна только мера." Я лишь хочу указать, что золотая середина возможно выбрана неправильно.

Fly
>Ты даже не понимаешь сути проблемы с батчами. Ты бы поэкспериментировал для начала, а потом советовал бы алгоритмы.
Хм. Чего именно я не понимаю?
Верны ли следующие утверждения:
Батч -- это каждый вызов D3D: DrawIndexedPrimitive, OGL: DrawElements, DrawArrays, glBegin/glEnd (вызовы glVertex батчами не являются). Смена стейта приравнивается как минимум двум батчам.
Batching -- группировка геометрии, позволяющая выводить большее число тр-ков за один батч.

#50
14:34, 28 мар. 2005

Zulus
Интересно, обвинение в воровстве кода:
http://www.gamedev.ru/forum/?group=11&topic=55&page=32
это ваш же ход под вымышленным ником для, так сказать, поддержания интереса?

#51
14:41, 28 мар. 2005

tav
а как связана оптимизация кулинга с количеством батчей? ты хочешь делать отсечение софтварно?
а что делать на машинах,  на которых эта игра будет CPU-bound?

#52
14:45, 28 мар. 2005

tav
а вообще оптимизация вывода геометрии интересная тема, но в этом топике она лишняя. тут как я понял стебутся

#53
14:55, 28 мар. 2005

CyberZX

Правильная мысль. Если эта тема будет где-нибудь в адвансетах, я ее буду с удовольствием читать. А тут возникает некомфортное ощущение, что мы вам мешаем.

#54
15:03, 28 мар. 2005

CyberZX
>а как связана оптимизация кулинга с количеством батчей?
Предположим, есть большааая куча треугольников. Мы берём её и нарезаем на куски кубической формы.
Если слепо следовать идеологии "меньше батчей -- быстрее работает", то минимальный размер куба-куска будет достаточно велик и таким образом в кадре будет не более сотни таких кубиков. Если за батч выводить всего один такой кубик, то число батчей будет характеризоваться числом видимых кубиков, т.е. тоже будет около сотни.
Что я предлагаю вот уже третью страницу. Нарезать куски меньшего размера, тогда их станет больше, а треугольников в каждом меньше. Спрашивается зачем? Ведь число батчей возрастёт. НО, если у нас будут гигантские кубы, то велика (даже очень) вероятность того, что больше половины третьей части выводимых кубов просто не видна. Т.е. если нарезать кубики помельче, точность frustum culling'а возрастёт, суммарный объём нагрузки на GPU снизится, т.е. GPU не будет обрабатывать невидимую геометрию, которую он до этого обрабатывал.
Аргументирую всё это я тем, что при расчёте ~50000 тр-ков в кадре, такую геометрическую сложность потянет далеко не high-end система, а значит выводить тысячи тр-ков за батч, как это советует, NVIDIA, не имеет смысла в данном случае.

>тут как я понял стебутся
Не обращай внимание.

#55
15:21, 28 мар. 2005

tav

Сейчас делаю ландшафт. Пришел к "нарезкам", динамически изменяемого размера. Примерно так:

.....................
....C1...............
....222..............
....3333.............
...444444............
...5555555...........
...66666666..........
...777777777.........
..88888888888........
..999999999999.......
..0000000000000......
Тр-ки с одинаковой цифрой - в одном индексбуфере.
Направление полос выбираю то, что ближе к перпендикуляру с лучем зрения.
Всегда виден только необходимый минимум тр-ков, а число фрагментов невелико.
Сейчас пробую сделать ЛОД, за счет пропуска вершин при удалении.
Думаю это (за исключением ЛОДа) подойдет не только для рег. сетки, а для любой статичной геометрии.

#56
16:27, 28 мар. 2005

tav
ты банально предлагаешь перевести куллинг с GPU на CPU. Но то, что ты предлагаешь находится слишком на низком уровне, что бы быть эффективном. В крайнем случае, лучше и эффективнее использывать Oclussion Query и early z-rejection. А на высоком уровне использывать AABB, BSP, Quad и прочиее trees.

#57
17:26, 28 мар. 2005

CyberZX
Хм. Неужели я совсем разучился объяснять.
>Но то, что ты предлагаешь находится слишком на низком уровне, что бы быть эффективном.
Я предлагаю всего лишь оптимизировать octree, но не саму структуру и принцип построения, а содержимое дерева.
Т.е. всего навсего увеличить глубину рекурсии в дереве, чтобы последний уровень дерева содержал более мелкие узлы (т.е. с меньшими BBOX-ами, с меньшими по сравнению с теми, что сейчас есть в игре).
Но поскольку дерево строится не из кучи полигонов, а из мешей статичных объектов, то я предложил способ разделения этих объектов на более мелкие части без какого-либо вмешательства со стороны моделлеров. Таким образом, когда одна из мелких частей объекта не видна, она не отправлялась на граф. конвейер, без этого разделения объект будет выводится целиком, хотя может быть так, что бОльшая его часть не видна, а так будут выводится только видимые куски объекта (их видимость определяется опять таки по их BBOX-ам).
Что именно тут не понятно?

Mikle
Это, конечно, здорово, но у меня назревает идея, как мне кажется, получше. Буду обдумывать.

#58
18:15, 28 мар. 2005

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

#59
18:59, 28 мар. 2005

Даже набив свою голову шкафом знаний, человек не становится мудрым.

Страницы: 1 2 3 4 5 6 7 Следующая »
ФлеймФорумОбщее

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