forum.boolean.name
Страница 7 из 12 < 123456 7 89101112 >
Показывать 64 сообщений этой темы на одной странице

forum.boolean.name (http://forum.boolean.name/index.php)
-   3D-программирование (http://forum.boolean.name/forumdisplay.php?f=12)
-   -   Советы по оптимизации (http://forum.boolean.name/showthread.php?t=17056)

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

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

Ну траву без альфы я без проблем сделаю, но если надо сделать кустаники и т.п. что без альфы не обойтись.
Цитата:
пригодятся, потому что у тебя много её перекрывает друг друга.
Т.е. чем больше мешей без zбуффера пересекается в проекции камеры тем больше лагов?

Mr_F_ 13.11.2012 01:01
Ответ: Советы по оптимизации
 
Цитата:
Т.е. чем больше мешей без zбуффера пересекается в проекции камеры тем больше лагов?
http://gamedev.stackexchange.com/que...se-depth-testi

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

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

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

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

HolyDel 13.11.2012 02:09
Ответ: Советы по оптимизации
 
а еще в хорсе есть инстансинг!

burovalex 13.11.2012 02:13
Ответ: Советы по оптимизации
 
По пути еще другой вопросик )
Как ты относишься к тому чтобы обрабатывать всё по фреймам - т.е.
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 13.11.2012 02:21
Ответ: Советы по оптимизации
 
Да Holydel, я пробывал его, не почуствовал особого прироста производительности.. Может руки опять же не оттуда )

Mr_F_ 13.11.2012 02:43
Ответ: Советы по оптимизации
 
Цитата:
Если не заметно глазу конечно, ели заметно допустим каждый 2-й 3-й кадр.
Как такой вариант?
хороший вариант.

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

HolyDel 13.11.2012 02:53
Ответ: Советы по оптимизации
 
Цитата:
Как ты относишься к тому чтобы обрабатывать всё по фреймам - т.е.
кое-кто, совсем недавно, хотел не запутаться :)

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

burovalex 19.11.2012 00:13
Ответ: Советы по оптимизации
 
Ну, в общем понаступав на пару десятков граблей я пришел к выводу, что в блитце самой большой проблемой является большое количество ентитей. Особенно я это понял когда 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 19.11.2012 19:01
Ответ: Советы по оптимизации
 
ржачна. мне нравится. ты только предупреждай, чтобы люди больные эпилепсией это не смотрели.

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

burovalex 20.11.2012 06:08
Ответ: Советы по оптимизации
 
Блин, да суть то не в том как выглядит, а как работает )

HolyDel 20.11.2012 20:03
Ответ: Советы по оптимизации
 
на самом деле нормально работает. шустро.
просто медия слабовата.

а в том примере, где 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 21.11.2012 23:15
Ответ: Советы по оптимизации
 
Я тоже ее видел. Я согласен что она выглядит круто.
Я не согласен с приводимыми автором цифрами. Ибо они противоречат теоретическим пределам современного железа.


Часовой пояс GMT +4, время: 02:33.
Страница 7 из 12 < 123456 7 89101112 >
Показывать 64 сообщений этой темы на одной странице

vBulletin® Version 3.6.5.
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Перевод: zCarot