Советы по оптимизации

[burovalex]

Офигеть, ты мне раскрыл глаза на Z буффер. Это оказывается мощная штука!
На примере травы сделал тест, и оказалось что без альфы производительность возрастает в 3 РАЗА!!
1000 примитихных мешей с альфой скинули фпс до 40, в то время как 3000 таких же без альфы скинули до 45.

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

Я делаю камеру от первого лица, механика примитивная - каждый пучок находится в двухмерном массиве(z,x),меш ростет до нужного значения, затем переходит к размножению, т.е. пытается создать копию в соседнюю ячейку рандомом, после n попыток переходит в пассивный режим(ничего не пытается ) , трава и другая растительность будет использоваться в роли ресурсов, для реалистичности планирую использовать где-то от 500-1000 мешей в карде.

Ну траву без альфы я без проблем сделаю, но если надо сделать кустаники и т.п. что без альфы не обойтись.

пригодятся, потому что у тебя много её перекрывает друг друга.

Т.е. чем больше мешей без zбуффера пересекается в проекции камеры тем больше лагов?

[Mr_F_]

Т.е. чем больше мешей без zбуффера пересекается в проекции камеры тем больше лагов?

http://gamedev.stackexchange.com/que...se-depth-testi

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

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

[burovalex]

я бы склеивал в рантайме массивы травы сразу по дофига пучков в цельный меш

Я об этом думал, но меня завел в тупик тот факт, что мне надо будет взаимодействовать с травой, т.е. мне надо будет её срывать, вот тут я сдулся. Мне кажется это будет слишком сложно для меня, я запутаюсь. Ну допустим я напишу алгоритм, который будет собирать "пассивную" траву 10*10 ячеек в один меш, но иногда она должна становится активной чтобы проверять не появилось ли свободное место и каким то образом удалять отдельный пучок из этого меша (можно конечно заново считать данные с массива и переписать меш 10*10).

Я к чему распинаюсь, у меня карта загружается с обычного рисунка 64х64 пикселя террайном, где 60% поверхности под водой )), и в принципе это для первого уровня должно хватить)
Ну максимум я пока расчитываю карту 256х256, с 70% суши, и 30% растительностью, это примерно 20К мешей, с автофейдом максимум 70-80 будет рендериться допустим 7к мешей. Реально ли обойтись без сложностей?

[HolyDel]

а еще в хорсе есть инстансинг!

[burovalex]

По пути еще другой вопросик )
Как ты относишься к тому чтобы обрабатывать всё по фреймам - т.е.
frame=frame+1
if frame>10 then frame=1
If (frame mod 10)=1 then
часть операций 1
endif
If (frame mod 10)=2 then
часть операций 2
endif
Если не заметно глазу конечно, ели заметно допустим каждый 2-й 3-й кадр.
Как такой вариант?

[burovalex]

Да Holydel, я пробывал его, не почуствовал особого прироста производительности.. Может руки опять же не оттуда )

[Mr_F_]

Если не заметно глазу конечно, ели заметно допустим каждый 2-й 3-й кадр.
Как такой вариант?

хороший вариант.

Да Holydel, я пробывал его, не почуствовал особого прироста производительности.. Может руки опять же не оттуда )

а ты какой пробовал? в старых версиях ксорса был со склеиванием меша и передачей параметров в виде констант в шейдер - но тут уж тебе выгоднее просто склеивать, а в новых они таки добавили хардварный инстансинг (ps 3.0 only), не пробовал его юзать правда, погляди может на форуме ксорса/в списке команд чего)

[HolyDel]

Как ты относишься к тому чтобы обрабатывать всё по фреймам - т.е.

кое-кто, совсем недавно, хотел не запутаться

[burovalex]

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

[burovalex]

Ну, в общем понаступав на пару десятков граблей я пришел к выводу, что в блитце самой большой проблемой является большое количество ентитей. Особенно я это понял когда 300-400 рисованных облачков с альфой начало хавать фпс.
Начал разбираться с синглсёрфом.
с 10000 мешей начал снижаться фпс, и то не из-за рендера, а из-за большого списка.

Сделал перемещение x,y,z, поворот y, а вот поворот х работоет коряво. Если есть у кого рабочий вариант, покажите плиз.
выглядит код так

Global mesh=xCreateMesh()
Global surf=xCreateSurface(mesh)

Type cloud
	Field x#,y#,z#
	Field surface
	Field vertex[3]
	Field scale#
	Field rotx#,roty#
End Type

Function CloudCreate(x#,y#,z#,scale#,rotx#,roty#)
cloud.cloud=New cloud
	cloud\x=x : cloud\y=y : cloud\z=z
	cloud\scale=scale
	cloud\rotx=rotx : cloud\roty=roty
	cloud\surface=surf
	cloud\vertex[0] = xAddVertex (cloud\surface,cloud\x-cloud\scale*Cos(roty),cloud\y+cloud\scale*Cos(rotx),cloud\z-cloud\scale*Sin(roty-rotx),0,0)
	cloud\vertex[1] = xAddVertex (cloud\surface,cloud\x+cloud\scale*Cos(roty),cloud\y+cloud\scale*Cos(rotx),cloud\z+cloud\scale*Sin(roty+rotx),1,0)
	cloud\vertex[2] = xAddVertex (cloud\surface,cloud\x+cloud\scale*Cos(roty),cloud\y-cloud\scale*Cos(rotx),cloud\z+cloud\scale*Sin(roty-rotx),1,1)
	cloud\vertex[3] = xAddVertex (cloud\surface,cloud\x-cloud\scale*Cos(roty),cloud\y-cloud\scale*Cos(rotx),cloud\z-cloud\scale*Sin(roty+rotx),0,1)
	tr1=xAddTriangle(cloud\surface,cloud\vertex[0],cloud\vertex[1],cloud\vertex[2]) 
	tr2=xAddTriangle(cloud\surface,cloud\vertex[0],cloud\vertex[2],cloud\vertex[3])
	tr3=xAddTriangle(cloud\surface,cloud\vertex[2],cloud\vertex[1],cloud\vertex[0]) 
	tr4=xAddTriangle(cloud\surface,cloud\vertex[3],cloud\vertex[2],cloud\vertex[0])
	xLogMessage(cloud\surface)
End Function

Function CloudUpdate(cloud.cloud)
xVertexCoords(cloud\surface,cloud\vertex[0],cloud\x-cloud\scale*Cos(cloud\roty),cloud\y+cloud\scale*Cos(rotx),cloud\z-cloud\scale*Sin(cloud\roty)+cloud\scale*Sin(cloud\rotx))
xVertexCoords(cloud\surface,cloud\vertex[1],cloud\x+cloud\scale*Cos(cloud\roty),cloud\y+cloud\scale*Cos(rotx),cloud\z+cloud\scale*Sin(cloud\roty)+cloud\scale*Sin(cloud\rotx))
xVertexCoords(cloud\surface,cloud\vertex[2],cloud\x+cloud\scale*Cos(cloud\roty),cloud\y-cloud\scale*Cos(rotx),cloud\z+cloud\scale*Sin(cloud\roty)-cloud\scale*Sin(cloud\rotx))
xVertexCoords(cloud\surface,cloud\vertex[3],cloud\x-cloud\scale*Cos(cloud\roty),cloud\y-cloud\scale*Cos(rotx),cloud\z-cloud\scale*Sin(cloud\roty)-cloud\scale*Sin(cloud\rotx))
End Function

Посоветуйте что надо доработать

[HolyDel]

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

[burovalex]

Че вы наезжаете?! Здесь сосредоточено 10000 мешиков. У меня на игровом буке фпс было 50 (и то тормозит не из-за рендера, а из-за того что надо пройти по 10к записей за каждый проход), правда в начале пока не сдвинешь камеру лагает сильно, не понятно с чем связано.
Подскажите как поворачивать вертексы по оси Х, у меня в примере должны крутиться, а они только слегка наклоняются

[burovalex]

Блин, да суть то не в том как выглядит, а как работает )

[HolyDel]

на самом деле нормально работает. шустро.
просто медия слабовата.

а в том примере, где 5 лямов - Эти 5 лямов были лишь со слов автора. Хотя выглядело куда круче, да.

посчитаем:
1 - пропускная скорость шинф PCI-E 16x на процессорах с архитектурой SandyBridge составляет 5GB/s. или
5 368 709 120 бит в секунду. кажется много, но это всего лишь
671 088 640 байт в секунду. На один спрайт нужно два триса. это 6 вершин. на каждую вершину нужно 12 байт на позицию, 8 байт на текстурные координаты. я опустил нормали и цвет, но может они в блице и не используются. хз. итого 120 байт на трис, на 5 000 000 спрайтов нужно соответственно 600 000 000 байт.
итого такая сцена с отправкой каждый кадр всех вершин на гпу по шине будет работать со скоростью чуть более одного фпс. а так-как у автора было значительно быстрее, значит за этими цифрами пряталась какая-лиюо хитрость. Или данные обновлялись не все, или было 5 000 000 травинок по сотне на каждый спрайт, или еще что-то.

[HolyDel]

Я тоже ее видел. Я согласен что она выглядит круто.
Я не согласен с приводимыми автором цифрами. Ибо они противоречат теоретическим пределам современного железа.