Leistungsgrenze von B3D ?
Übersicht
BlitzBasic Blitz3D
|
Kernle 32DLLBetreff: Leistungsgrenze von B3D ? |
 Fr, Sep 21, 2007 18:47Antworten mit Zitat 
|
|---|---|---|
|
Huhu ^^
Bevor hier gewisse Leute wieder geqäult aufstöhnen: Nein, es geht hier nicht darrum ob man mit B3D Spiel XYZ programmieren kann ^^ Vielmehr interessiert es mich, was auf mittelklasse Rechnen von heute die mxaimalanzahl von Dreiecken ist, die B3D ruckelfrei rendern kann. Ich habe schon erlebt das mein PC mit nur 500 Dreiecken geruckelt hat, und manchmal läuft er noch bei 2000 Dreiecken flüssig (in B3D beides versteht sich) Wenn man von den ganzen Berechnugen usw. absieht die während dem Programmablauf anstehen könnten - was ist eine gute Dreiecksanzahl ? Grüßle: Kernle PS: Egal wohin, aber bitte nicht innen Smalltalk verschieben  (wenn überhaupt)
|
||
|
Mein PC: "Bluelight" - Xtreme Gamer PC [Video]
Meine Projekte: Cube-Wars 2010 [Worklog] Anerkennungen: 1. Platz BCC #7 , 1. Platz BCC #22 , 3. Platz BAC #89 Ich war dabei: NRW Treff III, IV ; Frankfurter BB Treffen 2009 |
||
Dreamora |
Fr, Sep 21, 2007 18:57 Antworten mit Zitat
|
|
|---|---|---|
|
Es gibt keine Polygonzahlen die da was nutzen.
Das hängt extrem davon ab, was die Polygone nämlich repräsentieren: - Anzahl Surfaces (-> mehr = mehr Performance verbrauch) - Sind Meshes davon Bone animiert? (beträchtliche Performance Kosten) - Wie gross ist die Overdraw Rate, sprich wieviel von dem was gerendert wird, wird von sonstwas direkt wieder überrendert. (je mehr, desto höher der Performance verlust und zwar über den Verlust durchs Rendern hinweg. Overdraw zerrt recht an der GPU, selbst an modernen GPU. Deswegen schaffen es vor allem Anfänger und Leute ohne irgend eine Ahnung mit recht simplen Partikeleffekten ein Spiel auf 40 FPS runter zu bekommen) - Wie gross sind die Texturen? - Wieviele Texturlagen hat es pro Surface? Was macht man sonst noch grafisch. Sprich zeichnet man in die Buffer, kopiert man sie rum für Bloom zb usw. Es war schon mit den GeForce 4MX (also GF2) möglich 500'000 Polygone mit 20-30 FPS auf'n Bildschirm zu zaubern bei nem mikrigen 1.5Ghz P4 Mobile. Aber das waren dann statische Objekte (in meinem Fall ein geomipmapped Terrainsystem auf dem jeder Block 512x512 grosse Texturen hatte) |
||
| Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen. | ||
|
hecticSieger des IS Talentwettbewerb 2006 |
Fr, Sep 21, 2007 19:07 Antworten mit Zitat
|
|---|---|---|
|
Die Fillrate ist entscheidet. Wenn du 10 Fullscreen Quads anzeigst, sind diese in der Regel langsamer als 10'000 Miniquads, die in ihrer Bildschirmfüllung grad mal ein Bildschirm abdecken könnten. Es unterscheidet sich auch welche Grafikkarte genommen wird. Meine Erfahrung bisher ist: GeForce hat weniger Probleme Bildschirmfüllende Quads anzuzeigen, als eine ATI. Dafür hat eine ATI generell weniger Probleme viele Quads anzuzeigen gegenüber einer GeForce.
Wenn man nun von den beiden oben genannten Problemen absieht, dann kommt auch der Prozessor ins Spiel. Wenige Quads anzuzeigen bedeutet weniger Rechenarbeit für den Processor, da fast alles hier die Grafikkarte macht. Während bei vielen Quads (zB Partikel) auch der Prozessor die Positionen, Rotationen usw. berechnen muss, und somit auch der Prozessor hier eine Rolle spielt. Mein System P4 2.8 GHz, 1GB RAM, ATI Radeon 9600SE alles ~3.5 Jahre alt, kann folgendes in etwa anzeigen: Ungefähr 8'000 Partikel (Quads also 16'000 Triangles) als Singlesurface deren Position und Rotation berechnet wird, mit etwa 60 FPS anzeigen. Oder ungefähr 8 Bildschirmfüllende Quads auch mit etwa 60 FPS. Hier ist aber auch entscheident, wie hoch die angezeigte Texturauflösung ist. Wird nur über ~512x512 die UV ausgelesen, so ist es wesentlich schneller als wenn 2048x2048 ausgelesen werden. Dabei ist es egal wenn auch 4 mal 512x512 per UV ausgelesen wird. Wie Dreamora schon sagte, ist auch die Anzahl der Surfaces entscheident und viele andere Dinge. Generell sollte man aich also nicht auf einen Mindeststandard festlegen, sondern lieber überall so Recourcenschonend programmieren wie nur möglich. Was auch sehr von belangen sein kann ist, wieviel wird neu positioniert. Während meine ATI kaum ein Unterschied (~1 %) zwischen neu berechneten Polygonen (zB Partikel) und Polygone die nicht mehr neu positioniert werden (zB statisches Hintergrundbild) macht, ist auf einer GeForce ein deutlicher Unterschied zu verzeichnen (~300 %). |
||
| Download der Draw3D2 V.1.1 für schnelle Echtzeiteffekte über Blitz3D | ||
|
|
Kernle 32DLL |
Fr, Sep 21, 2007 19:35 Antworten mit Zitat
|
|---|---|---|
Ok, danke erstmal für die schnellen Antworten 
Also ich habe ein Mesh das aus einer Surface, aber einigen Dreiecken besteht (512). Da gibt es noch keine probleme (rechenzeit 3 - 4 ms mit debugger an). Als ich noch etwas kleiner und dümmer war habe ich mal ein Terrain aus meshes erstellt (Link). Das hat selbst mit kleinen Terrains (~16x16) argst geruckelt... Soweit hab ich nach der obrigen "Checkliste" alles für mich abgearbeitet... bleibt nurnoch die Sache mit der Textur. Für mein aktuelles Terrain benutze ich eine Textur (auch nur eine Surface), die in der X und Y Größe die Formel "MapGröße*GlobaleTexturauflösung" (Globale Texturauflösung ist z.b. 128... damit skaliere ich alle geladenen texturen auf di richtige Größe) hat. Dabei entstehen teils recht große Texturen (und wie Dreamora in einem anderen Thread sagt gibt das große Performence einbuße)... gibt es da eine möglichkeit das System zu verbessern ? (Ich merke grad üprigens das ein User hier im B3D Forum anscheinend das gleiche oder ein öhnliches Problem hat) Grüßle: Kernle |
||
|
Mein PC: "Bluelight" - Xtreme Gamer PC [Video]
Meine Projekte: Cube-Wars 2010 [Worklog] Anerkennungen: 1. Platz BCC #7 , 1. Platz BCC #22 , 3. Platz BAC #89 Ich war dabei: NRW Treff III, IV ; Frankfurter BB Treffen 2009 |
||
Übersicht
BlitzBasic Blitz3D
Powered by phpBB © 2001 - 2006, phpBB Group