FPS atkarībā no trīstūru skaita

[koderis]

C++ un 3D programmēšanu sāku apgūt nesen, tāpēc varbūt kaut ko daru nepareizi.
Ideja tāda, ka vēlos uztaisīt pamatdzinēju Minecraft tipa spēlei, bet pagaidām ir problēmas ar performanci.
Izmantoju irrlicht dzinēju.
Man ir 200x100x200 pasaule. Pasaules ir sadalīta 32x32x32 blokos (nodēs), kur katram blokam ir uzģenerēt mesh buferis priekš katra veida redzamās plaknes. Tas ir tas, ko man izdevās pašam sameistarot optimizējot.
Kopā scēnā ir ap 250`000 trīstūru, bet problēma ir tā, ka man šie 250`000 trīstūri renderējas ar 5-7 FPS, kamēr, atradu šādu, http://dave.uesp.net/wiki/Block_Land_1, kuram 7`000`000 trīstūri renderējas ar 30 FPS.
Es to visu laižu uz T3200 dual core nodebooka ar mobile express 45 chipset. Uz ko laiž otrā piemērā, īsti nezinu.
Tātad jautājums:
Vai tik milzīgā renderēšanas spēju atšķirība ir tīri saistīta ar grafisko karti, vai ir vēl kādas lietas, ko es varētu darīt nepareizi?

Man tas izskatās šādi:

[snake5]

Trijstūri nav vienīgie, kas ietekmē zīmēšanas ātrumu. Izmetot visus faktorus, kas uz šo gadījumu neattiecas, paliek zīmēšanas funkciju izsaukumu skaits, vertex'u formāts (efektīvi ir 4n un visefektīvākie ir 32n lielumi, baitos), procesora ātrums un tevis pieminētais videokartes ātrums.

Tomēr lai kaut ko vairāk pateiktu, ir jāzina šīs lietas:
1) Cik batch'u (zīmēšanas funkciju izsaukumu) katrā blokā un cik trijstūrus katrs zīmē?
2) Kāds ir lietotais vertex'u formāts (precīzi - katra elementa pozīcija un izmērs)?
3) Kas ir 200x100x200? Mazo vai lielo bloku skaits? Ja mazo, tad kāpēc tas nav 32n izmērs? It kā neliels ierobežojums, bet vēlāk spēs palīdzēt efektīvi optimizēt ar datu struktūrām, kas visu dala uz pusēm / vienādās daļās.

Par kaut kā darīšanu nepareizi runājot - ceru, ka Y ass nav izvēlēta kā tā, kura norāda virzienu uz augšu / uz leju (tāds iespaids radās pēc 200x100x200 secības). Tā ir ne tikai krimināla stila kļūda, bet arī efektīvs traucēklis, kas prasīs datu vizuālu un reālu pārstrukturēšanu katru reizi, kad būs nepieciešams strādāt tikai ar horizontālās plaknes asīm (vector2(x,z) taču izskatās neintuitīvi, vai ne? It īpaši tad, kad tos pašus datus vajadzēs nolasīt pēc 2d vektora y ass...).

P.S. http://origin-developer.nvidia.com/docs ... hBatch.pdf

[koderis]

1)Sanāk, ka ir 6x3x6 lielie bloki. Katrā blokā ir līdz 5 dažādām tekstūrām, kur vienādās tekstūras saliek vienā mesh buferī. Tākā izmantoju Irrlicht dzinēju, nevis opengl pa tiešo, tad nevaru precīzi pateikt, kas viņam būs bach calls, bet pieļauju, ka katram mesh buferim tam vajadzētu būt vienam. Tātad 6x3x6x5=540. Reāli nedaudz mazāks, jo dažos lielajos blokos varētu nebūt visas tekstūras, līdz ar to arī nebūs mesh buferis.
Savukārt katrs trīstūris ir puse no mazā 1x1x1 bloka skaldnes. Doma jau protams vienādas tekstūras blakusesošu kubu maliņas apvienot un tādā veidā vidēji varētu samazināt trīstūru skaitu 3-5 reizes, bet pagaidām gan primāri interesē palielināt FPS uz esošo trīstūru skaitu.
2)Izmēri ir tādi - mazā kubiņa malas ir 1 vienību garas, līdz ar to visi dati būtībā sanāk veseli skaitļi. katrai plaknei (mazā bloka šķautnei) es mesh buferī ierakstu 4 vertices un 6 indicies, attiecīgi kubiņam koordinātēs 0,0,0 augšējā plakne būtu vertices: 0,1,1, 1,1,1, 1,1,0, 0,1,0, un idices 0,1,2,0,2,3, attiecīgi nākošajām plaknēm ar to pašu tekstūru tajā pašā buferī, būtu jauni vertices un attiecīgie indices.
3)200x100x200 ir mazo izmērs. Man ir tā, ka no kartes, kas ir 3d masīvs tiek uzbūvēti lielie bloki, līdz pilniem blokiem, tāpēc patiesais kartes izmeŗs būs nedaudz mazāks - 192x96x192.

Runājot par y asi, tad tā ir uz augšu ejošā ass, bet to es es izvēlējos tā, jo visos irrlicht piemēros, no kuriem mācījos arī tā bija.

[snake5]

540 nav nemaz tik liels skaitlis. Ja procesors nav galīgi "mīksts" (<1.5 GHz), tīri 540 batch'i varētu dot pat 100+ fps.

jo visos irrlicht piemēros, no kuriem mācījos arī tā bija

Populisms. Visos vecajos modelēšanas rīkos arī bija tas pats, bet viņiem tajā laikā (kad 3D grafiku sāka veidot) nemaz nebija tādas lietas, ko sauc par virtuālo kameru - bija tikai modeļa transformācijas matrica. Attiecīgi tika izmantota ekrāna koordinātu sistēma, ko spēlēs (kuras nav sidescrolleri) izmantot ir diezgan bezjēdzīgi.

P.S. Neatbildēji vēl par vertex'u formātu. Ja lieto to pašu S3DVertex, tur sanāk 36 baiti. Nebūs visātrākais variants, bet pārāk lēnam arī nevajadzētu būt. Attiecīgi vērā ņemamu ātruma problēmu no tā nebūs.

P.P.S. Varbūt vari iedot kaut ko testējamu (vēlams kopā ar kodu)? Būs vienkāršāk noteikt, vai vainīgs ir dators.

[koderis]

Skaidrs, tātad jāpapēta Irrlicht dzinēja iekšējā struktūra - ko viņš īsti dara ar tiem mesh buferiem.

Vertex formāts ir S3DVertex - vismaz tā saucās Irrlicht klase, kura definē vertexu.


Test aplikāciju pieliku postam, kā divi rarus, jo limits 1MB.

[bubu]

mobile express 45 chipset.

Tā arī ir problēma, tas GPU ir pamatīgs nīkulis.

[bubu]

(vector2(x,z) taču izskatās neintuitīvi, vai ne?

Koordināšu sistēmas izvēle ir tas pats, kas koordināšu sākuma punkta izvēle. Vienam tas ir Rīgā, citam Ventspilī, citam zemeslodas centrā. Intuitīvi vai nē - tas ir katra paša darīšana un izvēle. Man terrainam arī ir y vertikāli, un plaknē operēju ar x un z. Man tas liekas ļoti normāli inuitīvi. Nesaprotu problēmu - vai tas arī ir kārtējais "es daru pareizāk nekā visa cita pasaule, un man tāpēc ir taisnība"?

[snake5]

Koordināšu sistēmas izvēle ir tas pats, kas koordināšu sākuma punkta izvēle.

Pasaki to vēlreiz un ar nopietnu sejas izteiksmi tad, kad atradīsi cilvēku, kurš, veidojot līmeņus uz mūsu planētas, izvēlēsies kādas citas planētas centru kā sākuma punktu (tieši tā man izskatās cilvēki, kas spēlēs, kur pamatkustība notiek uz horizontālas plaknes asīm, izvēlas Y asi vertikāla virziena norādīšanai). Visam ir savas robežas un pielietojumi.

Tā arī ir problēma, tas GPU ir pamatīgs nīkulis.

Mans R4850 no visaptverošā skata vairāk par 30 fps neizspieda. Tāpēc uzdrošināšos apgalvot pretējo.

Anyway, iesaku visu notestēt ar GLIntercept un paskatīties, kas tur galā sanāk.
Hint: viss logfails piedzīts pilns ar compatibility mode funkciju izsaukumiem. Izskatās, ka pie katra meshbuffera zīmēšanas tiek viss stāvoklis no jauna pārstādīts - matricas (arī tekstūru!!), tekstūras, EnableClientState/DisableClientState, u.tml.
Tāpēc iesaku paņemt citu renderētāju vai pat dzinēju. Šis ir vienkārši smieklīgs.

[bubu]

Pasaki to vēlreiz un ar nopietnu sejas izteiksmi tad, kad atradīsi cilvēku, kurš, veidojot līmeņus uz mūsu planētas, izvēlēsies kādas citas planētas centru kā sākuma punktu (tieši tā man izskatās cilvēki, kas spēlēs, kur pamatkustība notiek uz horizontālas plaknes asīm, izvēlas Y asi vertikāla virziena norādīšanai). Visam ir savas robežas un pielietojumi. ;)

Uzmini kā man izskatās cilvēki, kas apgalvo, ka std::vector ir lēnāks par C masīvu vai savu klasi?

[snake5]

Diez vai šādi.
Bet nu dažreiz nenāk par ļaunu uz lietām paskatīties citādāk...