Achtung - Realtiv viel zu lesen *g*
(thx @ Campersnightmare für Webspace, Bilder und Mapping wärend ich hier schreib ;)

Ich hab mal ein bissel mit der Forensuche Experimentiert... hab zwar nicht den Thread gefunden, den ich wollte aber der hier tuts auch ;)
http://www.thewall.de/forum/showtopic.php?threadid=489

Zitat:

Zweitens hat sich das mit den Dreiecken seit Quake geändert, will sagen: World-Polygone können sehr wohl Vierecke & mehr sein. Dafür spricht
1) die Skybox nimmt nur 6wpolys in Anspruch
2) r_drawflat 1
3) gl_log; ich war tatsächlich mal so verrückt die Logfile für den GL-Render erzeugen zu lassen (15MB nach 2 minuten) Daraus lies sich herauslesen, das HL durchaus Vierecke und Triangle-Fans (Vielecke) an den Renderer schickt.

Zitat:

Ich glaube, daß immer noch Dreiecke die Grundlage der ganzen Engine sind. Dafür spricht, daß z.B. quadratische Flächen immer mit mindestens 2 zu den polys beitragen --> wenn die Engine Vielecke verarbeiten kann, wieso dann nicht in einem solchen Fall (man könnte mit einer auf Vierecken basierenden Berechnung die r_speeds mal eben nahezu halbieren, würde aber sehr wahrscheinlich durch Rundungsfehler bei der Koordinatenberechnung für die Vertices dieser Vierecke sehr oft gewölbte Flächen erhalten --> welche 3D-Engine verträgt das?)?
r_drawflat sah in Quake genauso aus, wie jetzt ih HL. Leider hat Valve den gl_showtris-Befehl aus der Quake-Engine nicht in HL belassen, sonst könnte man sich auch jetzt die "wahren" Polygone (Dreiecke) anzeigen lassen (die Farbflächen bei r_drawflat zeigen nur die Texturflächen, jedoch nicht die Polygone, so wie sie die Engine sieht.

Und hier liegt meiner Meinung nach auch das Problem:
Die Grafikkarte kann nur Dreiecke berechnen, aber HL zählt halt auch belibige n-ecke als 1wpoly.

Folgende Situation:
Wir bauen einen Berg: 4*4 Brushes (je 64 Units)
Der Player steht auf dem Sky also auch noch ne Skybox (256*256*256 Innenmaß).
Zuerst der Sky:
6 Polyeder mit der Skytextur: 0 wpolies
http://mitglied.lycos.de/campersnightmare/newmap0002.jpg

Das ist ja schon mal ein Wiederspruch zum ersten Quote Punkt 1).

Naja... darum gehts mir hier nicht.
Jetzt bauen wir eine Wand aus 64³ Unit großen Polyedern. Diese werden an die Wand geschoben, so das durchs Backfaceculling der Compiler nur eine Sichtbare Seite entsteht. Also Pro Polyeder ein Face. Die Skybox produziert keine wpolies von daher ist die nicht intressant.
16 Polyeder, davon je 1 Face sichtbar: 16 Faces = 52 FPS 16 w_polies.
http://mitglied.lycos.de/campersnightmare/newmap0006.jpg

So. Jetzt teilen wir alle Polyeder in zwei Hälften (Diagonal).
Wir haben jetzt 32 Polyeder:
32 Polyeder, davon je 1 Face sichtbar: 32 Faces = 50 FPS 32 w_polies.
http://mitglied.lycos.de/campersnightmare/newmap0008.jpg

Nichts besonderes bisher. Dürfte jeder verstanden haben!

Jetzt der Knackpunkt: Die Graka kann nur 3 Ecke verarbeiten. Bei unserem 1 Beispiel haben wir aber 16 wpolies in 4-Eckigen Flächen --> Bevor das Berechnet werden kann muss zuerst noch jede Fläche in Dreiecke unterteilt werden. Die Grafikkarten bekommt also in beiden Fällen 32 Triangles zu fressen. In beiden Fällen der gleiche Rechenaufwand für 2 Unterschiedliche wpoly-Angaben.
Ich weiß, auf dem 2 Bild hatte CN 2 FPS weniger aber das liegt höchstwarscheinlich daran, das jede 2. Fläche hochgescaled wurde, um zu verhindern, das der Compiler die Faces wieder zusammenschweißt.

Also sind in unserem Fall: 16wpolies = 32wpolies (q.e.d)

Fazit: Normalerweise mappt man ja mit 4-Eckigen Faces (Häuser und so). Aber sobald größe Anhäufungen von 3-Eckigen Faces auftreten, wie z.B. beim "Triangle Bergbau", sind die r_speeds natürlich viel höher als bei einem der mit 4-Eckigen Polys arbeitet, obwohl beide Methoden den PC gleich belasten...

cya Khan Reaper Kerensky

P.S. Wer Rechtschreibfehler findet darf se behalten ;)

"[...] you're going to burn in a very special level of Hell. A level they reserve for child molesters and people who talk at the theater." - Book

öhm was bringt mir das als mapper?
Also mich überzeugt das da nicht, habe aber auch keine Lust darüber nach zu denken da ich eh schon Kopfschmerzen habe, aber nette Ansätze :]

Es geht hierbei nur ums Mappen... mit Models hat das nichts zu tun ;)

"[...] you're going to burn in a very special level of Hell. A level they reserve for child molesters and people who talk at the theater." - Book

also soll das bedeuten, dass r_speeds gar keine r_speeds sind. normalerweise, so verstehe ich das, geben r_speeds die von der engine berechneten flächen an. jedoch, wie KhanReaperKerensky schrieb, ist das also völliger blödsinn. somit kann man sich also nicht generell an die r_speeds angaben halten, da sie ja "verfälscht" sind.
*grübel*

Ziel: 18
JuLis - Niedersachsen

Naja r_speeds sind schon r_speeds
Bloß man sollte eben dabei NICHT nur auf die w_polies achten sondern auf die Framerate. Dummerweise ist die natürlich auf einem schnellerem Rechner auch höher.

gibt einem zu denken, aber auch wenn sie total verfälscht sind...inzwischen orientieren sich so viele daran...die werte (max 600 bei dm usw) sind dann wahrscheinlich mittelwerte, denn bisher sind ja alle damit gut gefahren...
naja...hmmm...*grübel*

Jeff

Nur dass ich das jetzt richtig verstehe... r_speeds zeigen einem das hier. aber der Compu hat zu arbeiten als wären's solche Flächen?
Das ist ja 'ne derbe verarsche.

Ööööhm... und was sagt uns das jetzt? Mir ist die Erkenntnis dieses Experiments noch nicht ganz klar: selbstverständlich werden von der Graka immer nur Triangles verarbeitet aber es hat ja auch nie jemand behauptet, daß das ein "w_poly" ist. Meines Wissens nach steht das in der Welt von Quake für "world poly" und beschreibt eben die Flächen, die die Engine erstmal berechnet bevor die Graka daraus wasweißichauchimmer macht. Dabei spielen ja auch solche Sachen wie Texscaling, Visleafs usw. eine Rolle, wissen wir alle.

Was nun die Grafikkarte aus den w_polys macht, ist doch fürs Mappen völlig wurst, oder? Selbst wenn die Graka 800 w_polys in 197.325 Triangles aufteilt ändert das nichts daran, daß es 800 w_polys bleiben und das ist der Richtwert für Mapper. Und daß Du die Engine nicht einfach so dazu "zwingen" kannst, die Polys von vornerein passend für die Graka zu splitten zeigt ja Dein letzter Versuch: die fps sacken ab obwohl Du der Graka laut Deiner Theorie ja eigentlich einen Gefallen getan haben müsstest indem Du die 4ecke in 3ecke geschnitten hast.

Was Dein Versuch also eigentlich nur bewiesen hat ist, daß "1 w_poly ungleich 1 Grakapoly" ist, aber das ist ja hinlänglich bekannt. Ich bin zwar kein Coder, aber meiner Meinung nach ist das auch der Grund dafür, daß die HL-Engine vergleichsweise langsam ist und selbst auf modernsten Rechnern noch an ihre Grenzen gebracht werden kann, während topaktuelle Engines mit Terraineditoren (Unreal Warfare, Lithtech Jupiter, Vulpine usw.) von vornerein mit Triangles arbeiten und diese wahrscheinlich viel direkter von der Graka interpretiert werden können. Ist aber nur eine Theorie, davon hab ich ansonsten wenig Plan.

[ - Mindmotor.Studios - ]|[ - Poke646 - ]|[ - Spaceman - ]

3.28 Uhr...

Nix zu tun? =)

K:R-I)Z++
"CSS ist cascading style sheets. Und nicht so'n Ranzspiel." - dp
In memory of Voice († 2005/03/30)

@Term: Die Frames sind bei beiden Experimenten eigentlich gleich. Das Problem is nur, das jedes 2 Dreieck hochgescalet ist, um zu verhindern, das die Compiler das wieder zu einem Face verbinden. Probiers selber mal ohne aus. Dann hasse 4wpolies. Dadurch das die Graka halt jedes 2te Dreieck anders behandeln muss wird das dann halt langsamer. Zu deinem letzten Absatz: Das gilt auch für die HL Models, von denen man ja auch mehr haben darf ;)

Ich will jetzt hier keinen dazu bringen, das der nimma auf die r_speeds schaut. Die altbekannten Werte sollte man auch weiter beibehalten. Aber sobald Triangleberge auftauchen, sollte man sich halt klarmachen, das die r_speeds dort höher seinen dürfen.

Der Grund warum ich das überhaupt ausprobiert habe, is das Presentationsforum. Dort ist mir mehrmals aufgefallen, das bei Berglandschaften halt schonmal wegen hohen polyzahlen gemeckert wurde. Aber das ist eben "normal".

"[...] you're going to burn in a very special level of Hell. A level they reserve for child molesters and people who talk at the theater." - Book

Aaah, so langsam verstehe ich worauf Ihr hinauswollt... allerdings ist Euch ein schwerer Denk- und Rechenfehler unterlaufen: die fps sagen nämlich in HL (gelinde gesagt) einen Scheiß über die Performance aus :) Hab's mal eben kurz durchgebastelt:

http://www.spaceman.de/half-life/fps01.jpg:

4 quadratische Flächen mit 240² Units, also von der Engine in jeweils 1 wpoly eingeteilt. Umd das Merging der Faces zu verhindern haben sie abwechselnde Texturen. Ergebnis? 72 fps.

http://www.spaceman.de/half-life/fps02.jpg:

Dasselbe nach Eurer Theorie in Dreiecken. Doppelt soviele wpolys aber genausoviel fps. Entspricht genau Eurer Theorie, soweit so gut. Aber:

http://www.spaceman.de/half-life/fps03.jpg:

Die 8 wpolys nochmal als Quadrate, und - hoppala! - die fps bleiben gleich. Aus meiner Erfahrung weiß ich nämlich, daß diese Zahl von 72 fps weder der Realität entspricht (mehr kriege ich nämlich nie) noch daß sie sich bei steigenden wpoly-Zahlen großartig verändert. Beweis:

http://www.spaceman.de/half-life/fps04.jpg:

Obwohl sich die Zahl der Flächen jetzt vervierfacht hat, tut sich bei den fps gar nix, außer das zu deren Berechnung nun zwischen 1 und 2 ms benötigt wird. Das liegt aber übrigens nur daran, daß ich zu der Zeit noch einige Tasks offen hatte.

http://www.spaceman.de/half-life/fps05.jpg:

Hier hab ich nun die anderen Tasks dichtgemacht (wieder 0 ms) und mal versucht, die wpoly-Zahl in eine Höhe zu schrauben, bei der die fps einbrechen. Bei 100 wpolys jedenfalls noch nicht.

http://www.spaceman.de/half-life/fps06.jpg:

Dasselbe gilt für die Triangle-Lösung derselben Fläche (= 200 wpolys), allerdings wird hier nun länger für die Berechnung benötigt (1 ms).

http://www.spaceman.de/half-life/fps07.jpg:

Zu guter Letzt mal eine reale Szene aus Poke646: Obwohl hier die wpolys 150 mal höher liegen als beim ersten Durchlauf oben, sinken die fps nur maximal um die Hälfte ab, und das obwohl auch noch 10646 epolys dazukommen!

Mein Fazit: nach den fps zu mappen ist wie russisch Roulette. Erstmal stimmen sie selbst auf der eigenen Kiste eigentlich nie, dann werden sie von unendlich vielen anderen Faktoren im späteren Spiel beeinflusst (Models, Sprites, Bildschirmauflösung usw.). Und natürlich sehen sie auf einem anderen Rechner ggfls. wieder völlig anders aus. Der einzige Richtwert für HL-Mapping bleibt also weiterhin die wpoly-Zahl, unabhängig davon ob ich Dreiecke, Vierecke oder 16-seitige Zylinder baue.

[ädit]
Seit wann ist denn der Image-Tag verhunzt?
[/ädit]

[ - Mindmotor.Studios - ]|[ - Poke646 - ]|[ - Spaceman - ]

Hallo!

Evtl. klärt das Tutorial "Node Optimierung" (UnrealEd Grundlagen) ein paar Dinge:
http://unrealed.gamesweb.com/index.php?P=tutorial&D=2-node

Ist zwar nicht HL, aber beschreibt ganz gut ein 'BinarySpacePartioning-Tree' (BSP-Tree) aufgebaut ist und den sollte HL auch haben. Könnte sein das es euch hilft. Auch wenn nicht, es ist auf jeden Fall sehr interessant...

Viel Spaß noch und macht weiter so! ;-)

Cu,

Cyber

Team -=|Poke646|=-

Zitat:

daß diese Zahl von 72 fps weder der Realität entspricht (mehr kriege ich nämlich nie)

hast du es je mit fps_max versucht ? ;-)

@Term

"diese Zahl von 72 fps weder der Realität entspricht"

die anzahl der Frames ist standartmässig auf 72 begrennzt und ansonsten hängt die Zahl auch vom Monitor ab, was man nur bei eingeschalteten V-Snyc bemerkt, wenn du sowas also testest must du min das V-sync deaktivieren und in der config file (glaub ich, muss selbst mal nachschauen ob´s da so einen eintrag gab), die maximale frame zahl ändern um die tatsächliche maximale fps zahl zu bekommen

meine meinung ist, das hochauflösende texturen teilweise mehr auf die performance drücken

also könnte das doch stimmen *grübbel*

/edit
khani (unten)

schwächer!? :O
die reicht noch (700mhz 224MB SDRAM)
und warts ab wenn ich in 2monaten meine gf3 hab
meine graka bzw. der winxp treiber (der meine framerate bei hldm teilweise unter 10 fps bringt) sind der grund...
hätt ich das mit 98getestet ;)

Entweder fps_max 120 mal machen oder ganz einfach ne schwächere Maschine nehmen *zuCNwink*.

Das Problem meiner Meinung nach besteht bei deinem Beispiel das das ganze bei 72FPS bleibt.

"[...] you're going to burn in a very special level of Hell. A level they reserve for child molesters and people who talk at the theater." - Book

Sorry, hatte das mit fps_max vergessen, aber das Ergebnis wird auch so nicht anders. Meine fps gehen in diesem Fall nicht über 100, also habe ich mal schnell ein weiteres Experiment gemacht:

http://www.spaceman.de/half-life/fps08.jpg:

Ein Haufen 8-seitige Zylinder in die Skybox gesetzt. 32 wpolys, 100 fps und (das halte ich für wichtig!) 1 ms für die Berechnung. Laut Eurer Theorie müsste also jetzt die Graka jeden Zylinder in 8 Dreiecke aufteilen und wenn ich Ihr das in HL schon abnehme, erhalte ich dieselbe Performance bei 8-facher wpoly-Zahl. Aber Pustekuchen:

http://www.spaceman.de/half-life/fps09.jpg:

Die fps bleiben völlig identisch (irgendwie krieg ich meine Maschine so nicht in die Knie :)) aber zur Berechnung werden jetzt 2 ms benötigt. Doch laut Eurer Theorie dürfte es überhaupt keinen Unterschied machen, da ich ja lediglich die Dreiecke bilde, die die Graka sowieso bauen muß.

[ - Mindmotor.Studios - ]|[ - Poke646 - ]|[ - Spaceman - ]

Vielleicht braucht das Aufteilen der Graka weniger Performance als das "manuelle" ?!

Zitat:

Cybermessias postete
Evtl. klärt das Tutorial "Node Optimierung" (UnrealEd Grundlagen) ein paar Dinge

Nee, tut es leider nicht :) Schließlich bezieht es sich auf den UnrealEd und der hat durch das Prinzip der Subtraktion halt von vornerein eine gänzlich andere Art die Welt aufzubauen. Außerdem sagt das Tut ja wenig über das hier besprochene Problem aus, denn auf die von der Graka berechneten Polygone/Triangles geht es auch nicht ein. Eigentlich werden mehr die Grundlagen von Polys, Vertices und Faces erklärt wie sie auch in den r_speed-Artikeln zu finden sind, allerdings eben funktional anders weil die Unreal-Engine da anders arbeitet.

[ - Mindmotor.Studios - ]|[ - Poke646 - ]|[ - Spaceman - ]

@Pope: Jep, genau das meine ich! Die "manuelle" Aufteilung, also das Vorkauen der Triangles schon durch den Mapper beim Bauen der Karte, kann eigentlich nie so schnell sein, wie derselbe Rechenprozess von der Engine ausgeführt. Ich werde vielleicht gleich nochmal ein Experiment mit 1000 4-eckigen und 1000 3-eckigen wpolys machen und dabei versuchen meinen Rechner irgendwie in messbare fps-Bereiche zu zwingen :)

[ - Mindmotor.Studios - ]|[ - Poke646 - ]|[ - Spaceman - ]

könnte ergebnis 2 nicht daher kommen, das du 2 Texturen verwendet hast, während du bei Test 1 nur eine verwendet hast?
versuch mal bei test 1 jeden zweiten zylinder mit textur 2 zu belegen...

Zitat:

Das Laxativum postete
könnte ergebnis 2 nicht daher kommen, das du 2 Texturen verwendet hast, während du bei Test 1 nur eine verwendet hast?

Ne ne, das wär ja noch schöner. Also bei einer 128er Tex mehr oder weniger sollte keine Engine oder Grafikkarte der Welt überhaupt eine Zuckung in Sachen Performance machen :) Und mein definitiv letztes Experiment zu diesem Thema unterstreicht das auch nochmal:

http://www.spaceman.de/half-life/fps10.jpg

Ich habe versucht, soviel wpolys wie möglich in eine Szene zu packen. Mehr ging leider nicht, da ich dann logischerweise einen max_leaf_faces error kriege. Da ich das Ergebnis aber auch nicht mit Hintbrushes verfälschen wollte, habe ich jetzt "nur" 768 wpolys in der Szene, alle quadratisch. Um den Rechner überhaupt zu fordern, habe ich jede Menge epolys verbaut. Ich hab extra ein paar mehr Screenshots gemacht und die fps-Werte verglichen: max 59, min 45.

http://www.spaceman.de/half-life/fps11.jpg

Dieselbe wpoly-Zahl, diesmal allerdings als Triangles. Doch obwohl laut Khans Theorie die fps jetzt definitiv ansteigen müssten (die Engine hat ja nur die Hälfte zu rechnen), komme ich auf max 56, min 39 (also sogar etwas weniger). Und das übrigens bei nur einer anstatt 2 Texturen (soviel zu Lax' Theorie).

Genaue Ergebnisse werden wir sowieso nur bekommen, wenn jemand mit einer extrem alten Maschine (233er oder so) und grottenschlechten Graka (Voodoo 2 und schlimmer :)) mal ein paar Feldversuche startet.

[ - Mindmotor.Studios - ]|[ - Poke646 - ]|[ - Spaceman - ]

wenn ich mal was zu achteckigen zylindern sagen darf, ich denk mal, die chiphersteller sind so intelligent, dass sie die graka diese dinger in nur 6 dreiecke aufteilen lassen anstatt in 8 !! wenn man den mittleren eckpunkt aus Sir_Pepe's bild auf einen "echten" eckpunkt setzt, kann man den cylinder in 6 dreieke zerteilen, von daher sinds (wahrscheinlich) nicht wirklich achtmal so viele dreiecke, wenn die graka das selbst zerteilt...

fazit: wir haben also herausgefunden, dass fast alles, was wir über r_speeds wissen völliger schwachsinn ist, oder nich??? :P

Zitat:

"ich denk mal, die chiphersteller sind so intelligent"

die Triangulierung geschieht nicht erst zur laufzeit!, das wird schon lange vorher gemacht, das wäre sonst etwas zu performance raubend, wer mit Programmen wie Max z.B. Arbeitet weiss das sowas unter umständen ganz schön dauern kann, auch diese Renderer können nur mit Trigonen Arbeiten, selbst eine Freiform-Fläche wie die Nurbs werden vorher in eine Fläche aus Trigonen umgerechnet, die heutigen Grafikkarten könnem mit Dreiecken besser umgehen, es kommt aber drauf an wie man diese dreiecke der Grafikkarte übergibt, ich kann ihr z.B. jedes einzeln übergeben, das kann sich dann negativ auf die performance auswirken da dies den Bus stärker Belastet etc, ich kann ihr die Dreiecke auch zusammenhängend übergeben, wenn sich mehrere Dreiecke z.B. ein Vertex teilen, dann brauch ich dieses vertex ja auch nicht für jedes Dreieck extra schicken, ich denk das hier der unterschied liegt, wenn man in HL eine Polygonfläche mit mehr als 3 ecken hat, denn werden die Poylgone zusammenhängend übergeben und wenn der Mapper diese Triangulierung im Vorfeld manuell erledigt, nimmt er der engine die möglichkeit diese optimierung durchzuführen

PS: die Trigon-durchsatzzahlen die bei den Grafikkarten angegeben werden wie der Geforce, beziehen sich auf zusammenhängende Dreiecke ;D

jo ... könnte schon alles so sein, wie ihr euch das vorstellt ...

für mich ergibt sich aber das problem, das (wie schon von anderen erwähnt):

1. die hl-engine nu wirklich schon alt ist ....
2. die hl-engine einfach nich in der lage ist mehr als 100fps darzustellen, egal ob man bei fps_max 1000 oderso eingibt.
3. es jetzt schon zum problem wird jemanden zu finden der noch auf ner gurke rumeiert, die langsamer als 500Mhz ist ... womit sich das performance-problem in wohlgefallen auflösen sollte.

man man man, immer muss man sich erst aufregen, bevor was funktioniert!