Immer wieder behaupten hier Leute (auch fähige Leute), neuere Engines könnten 10^x-mal mehr Polygone darstellen als HL, was auf Quake basiert. Diesen Leuten rate ich einmal folgendes Dokument von Tim Sweeney (Unreal-Engine): http://unreal.epicgames.com/Zones.htm

Schon erstaunlich, das die Engine am 21.7.99 (d.h. _nach_ Half-Life) nur 200 Polygone auf einem Bildschirm hatte! Ich hab leider keine Daten zu UT gefunden, aber ich kann mir nicht vorstellen, dass die Polygonzahlen hier auf einmal auf 10000 raufgeschnellt sein sollen....

Und es deckt sich eigentlich auch mit den logischen Ideen... die Half-Life-Engine stellt Polygone (GL) einfach mit mehreren Funktionsaufrufen dar (simplifiziert):

glCoordinates(1, 2, 3, 4);
glUseTexture("Texturname");
glUseLightmap(Lightmap für dieses Face);

Neuere Engines verwenden logischerweise mehr oder weniger die gleiche Befehlsfolge (was sonst?). Warum also sollten sie soviel mehr Polygone gleichzeitig auf den Bildschirm werfen können?

cu,
Prefect

Widelands - Gemütliche Aufbaustrategie, Free Software
Noch ein Blog - Lerne, wie die Welt wirklich ist, aber vergiss niemals, wie sie sein sollte.

hmmm stimmt schon das neue Engine einfach von der Hardwarepower auch nicht vielmehr Polygone darstellen können (republicengine 100000polys lol)...aber die Entwicklung beschränkt sich ja nicht nur auf die Polygonanzahl auch das vising und lod entwickeln sich weiter...ich denke das wichtigste an einer modernen Engine ist das Lod und ein perfektes vising...

-=B.L.Ä.N.D.E.R=-

Klar.. was man an Unreal sehen kann. Das ändert nichts daran, dass die Engine tatsächlich bei weitem nicht so viele Polygone darstellt... das sollte auch eigentlich klar sein.

cu,
Prefect

Widelands - Gemütliche Aufbaustrategie, Free Software
Noch ein Blog - Lerne, wie die Welt wirklich ist, aber vergiss niemals, wie sie sein sollte.

Ja, ich denke auch, dass die Anzahl der von der Engine selber erstellen Polygone ziemlich gleich geblieben sein dürfte (na gut, plus die paar, die ein 1Ghz gegenüber nem p200 ausmacht). Jedoch wird mit ziemlicher Sicherheit bei neuen Engines zu den Leistungsdaten auch das hinzugerechnet, was eigentlich die Grafikkarte macht, zum Beispiel curved surfaces. Mit denen hat nämlich AFAIK die Engine recht wenig am Hut, das geht eher nach dem Motto "lass die GeForce das mal machen...". Das dabei natürlich wahnsinnig viele Polygone entstehen ist klar, aber wie wenige davon liefen tatsächlich durch die Engine, sprich: wie wenige wurden im Level definiert?

TheTinySteini
Coder Poke646
"Don't Panic" - Hitchhiker's Guide to the Galaxy

Ich glaub ma, dass die mehr darstellen können, da die Hardware beser ausgereizt bzw. angesprochen wird. Bei HL wird die immer noch auf VOODOO1-Niveau angesprochen. Neuere Engines können halt die Fähigkeiten der Karten besser ausnutzen. Bei älteren Engines ist es ja oft so: bis zu einer gewissen Poly-Anzahl hat man perfekte Framerates, dann geht es steil bergab mit den fps. Neuere Engines nutzen halt die Fähigkeiten einer z.b. Geforce aus, was HL garnicht kann (da es beim Release gar keine gab).
Wie dat nu gecodet ist oder so: ka. Ich bin grad ma knapp über "Hello World!" *g*

caedes

Deutschland rückt nach Einschätzung der Sicherheitsbehörden im Superwahljahr verstärkt ins Visier von Terroristen.

Ich glaub, dass eher das Gegenteil der Fall ist: Sie reizen die Hardware weniger aus. Kaum ein Entwicklerteam wird sich heute noch die Mühe machen, mit Assemblercodes und so weiter das letzte Quäntchen Speed aus der Engine rauszuholen. Warum auch? Gibt schließlich DirectX 8 und GHz, so zumindest die Argumentation der Programmer. Es ist eigentlich schon fast ein Wunder, dass HL nen Softwaremodus hat und der auch erstaunlich gut läuft.
Leider scheinen auch immer weniger Entwicklerteams OpenGL zu unterstützen, obwohl ich OpenGL gegenüber DirectX den Vorzug geben würde - is einfach irgendwie besser.

TheTinySteini
Coder Poke646
"Don't Panic" - Hitchhiker's Guide to the Galaxy

@ttt: schon, sie werden net voll ausgereizt, aber benutzt.
Daher kann Q3 ja auch ca. 10x so viele Polys darstellen wie HL. Das liegt vielleicht auch daran, dass John Carmack OpenGL benutzt und net diese schwuchtelige, verweichlichte D3D. (Falls ein Homosexueller Mitbürger das liest: bitte net persönlich nehmen, war net bös gemeint).

caedes

Deutschland rückt nach Einschätzung der Sicherheitsbehörden im Superwahljahr verstärkt ins Visier von Terroristen.

Die Behauptung, Q3 könne 10x mehr Polygone darstellen als HL halte ich für ein Gerücht. Ich habe leider keine harten Daten mehr (und unter Linux mit emuliertem HL kann ichs eh nicht wirklich testen), aber ich hatte mal diese DM-Karte pipes. Da waren 1000+ wpolys und 20 Bots (sowie jede Menge Items, also insgesamt sicher >20,000epolys) gleichzeitig auf dem Bildschirm. Zusammen mit Bot AI (die ja auch nicht gerade wenig CPU frißt) lief das ganze so bei 20-25 fps. Bei Q3 auf dem CTF Spacelevel (Q3CTF4 oder so) lief das Spiel mit 11 Bots (auch meistens alle gleichzeitig sichtbar) nicht viel schneller - vielleicht knapp über 30 fps zu den besten Zeiten, wobei sich hier ja noch die Frage stellt, ob Q3 eigentlich ein effektives LOD (Level of Detail)-System hat, das würde nämlcih wieder die epoly-Zahl relativieren.

Für mich sieht das also nicht ganz so aus, als könne Q3 10x mehr Polygone darstellen als HL.

John Carmack verwendet OpenGL. Half-Life auch.

Außerdem verwendet HL im OpenGL-Modus automatisch Texture&Lighting-Features von Grakas wie den Geforces. Lest euch ruhig die Dokus durch, das stimmt so, da die Matrixkonversion nicht vom Spiel, sondern vom OpenGL-Layer gemacht werden. Nur D3D ist halt zu ineffizient designt, so dass D3D-Programme ein Update benötigen um von T&L zu profitieren. Daher kommt wahrscheinlich dieses Gerücht von tollen neuen Features, die die Geschwindigkeit erhöhen, aber erst von den Programmen unterstützt werden müssen.

Alle anderen Features, die sich ernsthaft auf die Geschwindigkeit auswirken sind so technische Spielereien wie z.B. die erweiterten per-pixel-ops bei der GeForce3. Aber da HL sowas ja eh nicht macht fließt es in unsere Berechnungen nicht mit ein...

cu,
Prefect

Widelands - Gemütliche Aufbaustrategie, Free Software
Noch ein Blog - Lerne, wie die Welt wirklich ist, aber vergiss niemals, wie sie sein sollte.

Hat Q3 überhaupt ein lod??? *glaubt nicht dran*

-=B.L.Ä.N.D.E.R=-

Q3 Curved Surfaces sind lod und die models haben afaik einen 3 stufen lod. die soliden levelstrukturen nicht.

heutzutage gehen vielmehr die texturen auf die geschwindigkeit als die polygone. wir haben hier maps mit >60.000 polys gleichzeitig ohne models die ohne probleme auch auf einem 300er laufen würden
doch 80 tgas (texturen) in einer min. auflösung von 256x256 die in der engine im optimal fall mit 1:1 gezeichnet werden rauben sogut wie jeder grafikkarte den letzten funken ram. klar man braucht jetzt eine menge mipmaps, die texturen müssen je nach ramstärke angepasst werden aber tgas fressen nunmal einen haufen mb. "texturenlod" hin oder her.

ebenso die meshes mit skins um die 2048x2048. die polygone sind da fast zweitrangig. ob unsere engine nun 10x schneller ist kann ich nicht beurteilen. da müsste man einfach einen hl level mit x polys ohne texturen bauen und daneben einen mit unserer mit x polys und die belastung abfragen.
selbiges hat gumble ja schon bei quake3 gemacht. die r_speeds in seinem von hl konvertierten level waren weitaus höher da die leafs wohl noch schlampiger unterteilt werden. da helfen dann in vielen maps auch keine arenaportals.
allerdings kann es sein, dass q3csg die bsp änlich winbsp decompiled hat und somit eine menge überflüssigen mist produziert hat.

ganz klar, dass mit immer schneller werdender hardware die programmierer träge werden.
mal sehen wie es wird wenn wir uns grafikkarten via software updaten können und wie spiele das dann ausnutzen können.

@prefect: ja, bei 1000 wpolys macht HL ja auch noch net schlapp. Aber versuch's ma mit 10.000 wpolys. Q3 kann das. HL sicher net. bei sovielen Polys überholt Q3 HL einfach.

caedes

Deutschland rückt nach Einschätzung der Sicherheitsbehörden im Superwahljahr verstärkt ins Visier von Terroristen.

Nun, wenn man bei Grafikkarten-Tests die Frameanzahlen verglichen sieht zwischen ner Q3-Demo und ner HL-Demo, dann is die HL-Demo meist weit abgeschlagen. Ich habe allerdings folgende Vision woran das liegt: An dem ziemlich umfangreichen HL-Code, der mit einer der besten AIs (zumindest zu der Zeit) und vielen guten Funktionen arbeitet. Dadurch ist selbst in einfachen Maps immer eine recht hohe Systemlast vorhanden. Die wird allerdings durch größere Maps nicht sehr viel erhöht, aber irgendwann is halt bei 100% Schluss...
Q3 und so haben aber allesamt einen recht übersichtlichen Code - kein Singleplayer, nur so ein paar Gamemodis. Das macht schon einiges aus. Dann wird auch noch die 3D-Grafik fast komplett der Grafikkarte bzw. OpenGL/Direct3D anvertraut und schon hat man ein schnell laufendes Spiel. Naja... bisschen sehr einfach dargestellt, aber ich hoffe es trifft den Punkt...

TheTinySteini
Coder Poke646
"Don't Panic" - Hitchhiker's Guide to the Galaxy

äähhh ttt... ich glaub ma, dass die Q3-Bot-AI sehr viel komplexer ist als die HL-KI.

caedes

Deutschland rückt nach Einschätzung der Sicherheitsbehörden im Superwahljahr verstärkt ins Visier von Terroristen.

also 1) wie prefect schon sagte unterstützen alle spiele die opengl benutzen T&L u.a features; bei D3D is das alles nachträglich dazugekommen ...

2) die Half-Life engine is meiner meinung einfach langsamer da valve diverse funktionen dazu gecoded hat (bei models usw. wie bones mit komplexen transformationen u.v.w) die eben nicht so schnell sind wie die von carmack gecodedeten formeln und daher einfach die quake1 engine bremsen, da ja auch jedes Frame transformationen für jeden bone/vertex u.s.w durchführen müssen. (Ich behaupte einfach mal das es Valve nich so mit 3Dengines drauf hat, wenn man davon ausgeht das Half-Life valves erstes werk is und auch noch auf ner komplett nichSelbstGebastelten engine aufbaut ) -> will heißen: der valve code der dazu gekommen is "bremst" die alte engine =P

... was anderes kann es ja eigentlich nicht sein, da alle engines letztendlich nur auf (kurz gesagt)
Quellcode:
transform_triangle()
prepare_scene()
while(triangle)
  drawTriangleWithTextureAndColor()
  triangle++


da ja alles in der while schleife theoretisch fast das minimum is was gemacht wird und werden kann, muss es ja zwangsläufig das prepare_scene() (welche dreiecke werden gezeichnet; wie wird entschieden was gezeichnet wird; etc) und transform(scale,move,rotate,mirror etc ...) zeugs sein was die framerate der einzelnen engines und spiele beeinflusst und voneinander unterscheidet.

So, jetzt geh ich (gleich) pennen!

[edit]
Zumindest bei engines die auf DrawPerPoly-basis arbeiten trifft das oben zu,
z.B. bei Raytracern könnte das wieder ganz anders aussehen, oder Voxel engines o.ä. das raytracer ja per-pixel rendering machen (die griechen grüßen)
und voxels ehe 1337 sind =()

voxels an die macht *G*

[edit]
dummes board kappt mein text =P

Another1

...relaxing..atm =)
... und Schweiz suckt!