Hallo!

Ich muss für die Uni ein OpenGl-Spiel erstellen (mein erstes). Gibt es irgendwelche Anhaltspunkte, wie viele Polygone/Vertices so ein Level beinhalten darf, damit alles noch flüssig läuft? Ich bräuchte da mal einen Anhaltspunkt.

Nun, theoretisch beliebig viele.
Worauf es ankommt ist, wie gut du dein Rendern optimierst. Ich denke hierbei an Octree, Vertex Buffer Object (siehe Tutorial Vertexbufferobject), Frustum Culling und so dinge.

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Jede Grafikkarte hat ein maximales Vertice/s Limit, das wird man aber nie erreichen, da es rein theoretisch ist und in der Praxis noch einiges an Arbeitsaufwand reinspielt.
Es kommt immer auf die Komplexität der Szene an, ob man shader verwendet, wie und was zeichnet man, was kommt noch so an weiteren Berechnungen ausserhalb des Renderers vor.
Wenn du 20MTris hast dann bist glaube schon gut dabei, wobei das 20.000.000 Triangle pro Sekunde bedeutet.
Unreal Engine 2 hat z.B. auf hohe Trianglecounts gesetzt und mit Verticelighting ziemlich gut ausgesehen.
Wie mein Vorredner schon erwähnt hat, macht ein Spatial system viel Performance aus, dabei ist ein Spatial system ein Code, der den Raum unterteilt.
Beispiele sind Octree,Quadtree,Binarytree,... .
In verbindung mit einen Sichtbarkeits algorythmus, z.B. Sichtbarkeitstabellen, Occlussion culling oder Frustum culling, kann man dann effektiv die Sichtbaren Elemente bestimmen und Zeit und Power einsparen(höhere MTris sind die Folge).
Am einfachsten sind eigentlich Octree+Frustumculling.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Ich würde sagen, um meine Vorredner zusammen zu fassen, mach dir darüber erstmal keine Gedanken.

Deine ersten Spiele werden sicherlich nicht wegen der Vertices langsam laufen, sondern wegen den üblichen Fehlern wie z.B. ständiges Texturenladen, ständiges Texturenwechseln schlechte Codegliederung, etc.
Dort steckt man als Anfänger das meiste Lehrgeld rein.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Um da evtl. noch eine andere Sichtweise mit einzubringen. 20 Millionen Dreiecke (1 Viereck = 2 Dreiecke) Pro Sekunde sind zwar eine schöne Zahl aber es gibt selten ein Spiel was nur 1 Bild in der Sekunde darstellt. Bei mikrigen 20 Bildern in der Sekunde hast du "nur" eine Million Dreiecke. Aber ich meine bei S.T.A.L.K.E.R. ist es möglich, dass einzelne Szenen bis zu 1 Million Dreiecke haben können.

Die theoretischen Angaben der Chips sind auch wirklich nur theoretisch zu sehen. In Wirklichkeit ist der Durchsatz um einiges geringer. Mit meiner alten ATI Radeon 9600 Pro konnte ich bis zu ca 60 Millionen Dreiecke pro Sekunde zeichnen. Mit der X800 (gleiche Chiparchitektur aber doppelt so schnell) waren es schon ca 180 Millionen pro Sekunde. Von meiner aktuellen Karte weiß ich das gar nicht.

Je nachdem wie die Karte ausgebaut ist (verwendeter Speicher/Geschwindigkeit) kannst du auch Probleme mit der Füllrate bekommen. Die Füllrate ist die Geschwindigkeit des Speichers. Wenn du eine Textur darstellst oder Speicher innerhalb der karte bewegst oder was in den Framebuffer geschrieben werden muss geht das alles auf die Füllrate. Der beste Chip nützt nichts, wenn der Speicher langsam ist. So konnte ich bei meiner Version der X800 in einigen Fällen den Chip um ~15% übertackten aber im Endeffekt hat es nur ~1% mehr Leistung gebracht.

Massiv Shader gehen zum Beispiel auf die Rechenleistung der GPU was indirekt auch den maximalen Durchatz an Dreiecken als auch die Füllrate beeinflusst.

Je nachdem wie komplex es werden soll, solltest du dir vielleicht überlegen welche Hardware du als Ziel hast. Wenn es nicht so komplex wird, dann kannst du sicher recht unbeschwert an die Sache rangehen. Dann sollten recht einfache Technicken bereits ausreichen um es auf halbwegs aktueller Hardware schnell genug hinzubekommen.

Ich ziele in etwa in die Größenordnung von 100k(pro frame), damit es auch auf älterer Hardware noch vernünftig läuft. 6-stellig ist jedenfalls ein guter Richtwert.

_________________

Hey Danke schonmal für eure Antworten. Dann schau ich einfach mal wie das hinhaut