also ich bin langsam aber sicher der Meinung das ich irgendwas total grundlegendes total falsch mache....
ich bastel ja grad an so nem Mini Raumschiff... die Hülle vom Level allein besteht aus knapp 2000 Polygonen.
Alles in einer DisplayList drin, nur... wenn ich da jetzt durchlaufe (durch das reine Level, also nur die EINE DisplayList) gibt es stellen wo es mit 300 FPS läuft und andere wo es nur mit 30 FPS geht... ich hab absolut keine ahnung woran das liegt...
Mein Level hab ich mit Maya erstellt, dann nach *.obj exportiert und dann die OBJ Datei eingelesen und daraus die DisplayList erstellt..
gibt es irgendwas grundlegendes super wichtiges was ich vieleicht nicht weiß oder so...? (Wenn ich die Texturen weglasse geht es überall im Level gleichschnell eigentlich... und die Texturen, da ist keine größer als 256x256...
Hat irgendwer ne ahnung woran das liegt..???
Weil wenn ich mir dann vorstelle, das ich ja mal Riesen Level mit tausenden Polygonen machen möchte... wenn das schon bei 2000 stück so ruckelt... *seufzt*
mhh... nochmal ne "andere" frage... Ihr kennt ja sicher Diablo 2.. da das das einzige PC Spiel ist, was ich jemals richtig gespielt hab kann ich nur sagen wie's da war.. *g*
Also auf der Packung steht drauf "Pentium 233"... damals hatte ich nen P3 500 mit ner Diamond Viper V770... und hatte bei dem Spiel immer ca. 20 - 30 FPS...
Dann kaufte ich mir ne neue GrafikKarte (die ich jetzt immernoch habe) "PowerColor 64mb GeForce GTS 2 Pro"... hatte allerdings immernoch nur 20 - 30 FPS
nun hab ich keine Ahnung ob es damals an der CPU lag oder so... aber aufjedenfall hatten alle anderen mehr FPS.. *g*
Deswegen.. kann es sein das meine GrafikKarte nich so die wirklich allerbeste ist..??
Registriert: Mo Sep 23, 2002 19:27 Beiträge: 5812
Programmiersprache: C++
Warum deine Rendergeschwindigkeit so niedrig ist, ist wirklich fragwürdig.Aber es kann an der Art und Weise liegen, wie Maya die Objekte exportiert.Das Drahtgittermodell von deinem Delphin z.B. hat sehr eigenartig ausgesehen.
Kannst ja mal zwei gleiche Objekte jeweils mit Maya und 3DS-Max machen, in deine Anwendung laden, und dann siehste ja welches Programm brauchbarere Daten exportiert (ich Tipp auf 3D-Studio).
Eventuell ist aber auch der OBJ-Loader den du nutzt nicht besonders brauchbar, weil er z.B. kein Back-Face-Culling nutzt.
BTW : Es ist eine sehr schlechte Idee, einen grösseren Level komplett in eine Displayliste zu kompilieren, da man dann ja keine Geometrieoptimierung wie z.B. Octrees, Frustum-Culling oder BSP betreiben kann...hier könnte also auch dein Problem liegen!
Und zu Diablo 2 : D2 hat im Singleplayer eine feste Framerate.Das läuft auch auf 3Ghz-Rechnern mit GF4 mit 25fps.Nur im Multiplayer-Modus ist die Framerate nicht fest und lässt auf die Leistung des Rechners schliessen.
Also der Export von Maya ist eigentlich ok denke ich...
Sind halt einfach alle Vertex'e nacheinander aufgelistet. (Das der Delphin so komisch aussah liegt einzig an der Textur die ich auf den draufgemacht hab, und ihn damit halb transparent gemacht hab)
Das es nicht gut ist alles in eine DisplayListe zu machen weiß ich ja... nur, ich hab mir gedacht "Bei einem Level mit <2000 Polygonen"... da brauch ich nich wirklich den aufwand von nem Octree etc machen...
Es könnte wirklich an den Texturen liegen. Ich hatte mal ein ähnliches Problem mit einer ATI Rage Mobility Karte, die plötzlich langsamer wurde, als der generische OpenGL Software Renderer von Microsoft, sobald ich Texturen > 128x128 Pixel darstellen wollte.
Der Witz dabei war - die Karte hatte keinerlei Probleme mit größeren Texturen, DirectX funktionierte einwandfrei, es war in Wirklichkeit ein schlecht programmierter OpenGL Treiber, der was weiß ich wie umständlich aufgesetzt war (und der Treibersupport von ATI ist echt unter aller S**, zumindest ältere Karten betrifft).
Da du eine NVidia Karte hast, solltest du evtl. mal den neuesten Detonator Treiber installieren.
Überprüf auch mal, obs dann ruckelt, wenn sehr viele Texturen gleichzeitig dargestellt werden - obwohl, in einer 64 MB Karte haben eigentlich über 200 Texturen deiner Größenordnung Platz (256*256*4=256KB) - die ATI Rage Karte hatte im Vergleich nur 4 MB.
Ansonsten könnte es natürlich auch sein, dass du die hohe Framerate genau dann bekommst, wenn nur wenige Polygone dargestellt werden und die niedrige, wenn du grad am Rand deines Levels stehst und über sämtliche Details schaust - denn natürlich cullt OpenGL auch dann Polygone gegen das Frustum, wenn du selbst kein Frustum Culling für deine Geometrie implementierst, und bei 2000 Polygonen ist der Verwaltungsaufwand die Schnittpunktdaten zum OpenGL Renderer zu senden und zu transformieren noch nicht so sehr hoch, insbesondere wenn du eine DisplayList verwendest.
Es wird Zeit eigenes Frustum Culling zu implentieren, wenn die Framerate auch sinkt, wenn eigentlich gar nichts zu sehen ist . (Zum Testen verwende ich übrigens immer einen Software Renderer - entweder den von Microsoft oder MesaGL wenn ich Funktionalität > OpenGL 1.1 brauche - und zwar auf einem 1.2 Ghz PC, wenns da halbwegs akzeptabel läuft (oder zumindest läuft...), weiß ich, dass ich das Programm überall vorführen kann, ohne dass es peinlich wird).
Als akzeptable Lösung für mittelgroße Levels kannst du es ja so machen, dass du diese aus mehreren Teilen zusammensetzt (sozusagen ein im Vorhinein berechneter OctTree) und dann mittels Bounding Spheres oder Boxes die Sichtbarkeit des jeweiligen Teils überprüfst, bevor du die zugehörige DisplayList aufrufst.
Das nützt dir natürlich immer noch nix, wenn du grad in einer Ecke stehst und das ganze Level in seiner vollen Pracht vor dir im Frustum liegt - dann musst du dein Programm entweder so aufbauen, dass dies nicht der Fall sein kann (z.B. die Sichtweite einschränken) oder dir über einen guten LOD-Algorithmus Gedanken machen.
Ja... das es ruckelt ist ja grad nur wenn ich das komplette Level überblicke..
Aber (!) ich war eigentlich der Meinung , dass ein Level das aus nur 2000 Polygonen besteht ruckelfrei gehen sollte... (Also es ruckelt nicht, aber die FrameRate geht halt runter)
Das komische ist ja auch, wenn ich in meinem Spiel was ich bastle Objekte mit 50.000 Polygonen lade.. die dinger kann ich drehen etc so schnell ich will, hab immer 100 FPS (VSynch.. )
und wenn ich dann da durch die gänge lauf', in nem Level mit nur 2000 Polygonen, und die FPS zahl sinkt auf 80 runter wenn ich alles überblicke...? ich weiß ja nich... *seufzt*
Natürlich kann ich die 2000 Polygone nochmal in 100er Päckchen aufteilen, aber irgendwie... na ja, egal.. *g*
Au'revoir,
Aya~
PS: Detonator treiber hab ich schon die neuesten..
also ich hab grad 2 dinge rausgefunden woran es liegt/lag...
1.) Ich sollte unbedingt Maya beenden wenn ich mich auf die FPS zahl verlassen will :crazy:
2.) Meine "SkyBox"... wenn ich die weglasse geht alles wunderbar super schnell... Die SkyBox ist aber nur nen riesen Großer würfel (6 Quads ) der halt die komplette Scene umgibt... mit ner Textur von 256x256 darauf (welche allerdings mehrmals nebeneinander darauf ist..)
1) Der Datenübertragungs- und Transformationsgeschwindigkeit, also wie schnell Schnittpunkte zum OpenGL Renderer gesendet werden können, Transformation eben dieser Schnittpunkte, sowie der zugehörigen Normalvektoren und Texturkoordinaten und die Berechnung der korrekten Vertexfarben über Materialeigenschaften und Lichtquellen.
Auf schnellen Computern sollte dies nicht das Problem sein, insbesondere moderne Grafikkarten (auch deine Geforce )haben ja uch bereits eine T&L Engine implementiert, die dem Prozessor da viel Arbeit abnimmt.
2) Der Pixelfillrate, da muss jetzt die Grafikkarte die vorher berechnete Szene tatsächlich zeichnen - und die ist jetzt auch wieder von vielen verschiedenen Faktoren abhängig: aktivierte Textureinheiten, Farbinterpolation, Antialiasing, Texelinterpolation, aktivierte (Z-, Alpha-, Stencil-) Buffer.
Insbesondere bei großen Texturen die oft innerhalb eines Polygons wiederholt werden, gibt es das Problem, dass der Grafikprozessor um eine einzige Scanline eines Polygons zu zeichnen, wie wild im Speicher herumhüpfen muss, um sich die korrekten Daten zu holen - bei kleinen Texturen nicht so wild, die können prozessorintern gecacht werden, auch wenn die Textur nur einmal wiederholt wird nicht so tragisch, weil die Daten dann halbwegs nacheinander im Speicher liegen und eher vorhergesagt werden kann, woher die nächsten kommen werden.
Eine andere Möglichkeit könnte sein, dass du einen WRAP Modus verwendest, den deine Grafikkarte nicht hardwaremäßig unterstützt (GL_MIRROR_REPEAT ?) und deshalb von OpenGL Treiber softwaremäßig - und langsam - umgesetzt wird. Ist nur eine Möglichkeit.
und.. du meinst es liegt also daran das ich die Texturen da bis zu 50 mal auf einem Polygon mache, ja..?
mh... dann müßte es doch rein theoretisch schneller werden wenn ich dieseseine Polygon in 50 aufteile und dann die Textur nur einmal/Polygon verwende... oder??? *testen geht*
Das mit den 50 Polygonen nützt nur was, wenns wirklich am WRAP mode gelegen hat. Am Speicherdurchsatz ändert sich ja nix, die Textur muss immer noch 50 mal durchlaufen werden.
Wenn ich es auf mehrere Polygone verteile klappt es... Jetzt ruckelt's selbst dann nichmehr wenn ich komplett alle objekte sichtbar hab.. (Also wenn ich FrustumCulling etc ausschalte)
Also manchmal habe ich wirklich das Gefühl, dass die Treiberprogrammierer etwas schlampig vorgehen. Wär doch kein Problem, ein Polygon, das eine Textur oft wiederholt automatisch (zumindest während des Kompilierens einer Displaylist) aufzuteilen, wenn die Grafikkarte hardwaremäßig wiederholte große Texturen aufgrund des (fehlenden) Speicherdurchsatzes nur mangelhaft unterstützt - dabei sind NVidia Karten noch relativ gut geeignete Karten zum OpenGL Programmieren, da NVidia sich auch mehr oder weniger aktiv an der Entwicklung von OpenGL beteiligt.
Ich meine als Programmierer sollte man solche Szenarien wirklich nicht berücksichtigen müssen, ich bin sicher dass in den meisten Grafikkarten Leistungsreserven von bis zu mehreren hundert Prozent stecken würden, wenn die Treiber wirklich intelligent programmiert wären. (Schon mal überlegt, wie z.B. die Grafikleistung einer Playstation 1 (Leistungsniveau eines 486ers ohne besondere Hardware 3D-Beschleunigung) erreicht wurde ??) - aber bei der rasanten Entwicklung der Hardware kann man ja schon froh sein, wenn die Treiber wenigstens halbwegs fehlerfrei funktionieren, von Optimierungen ganz zu schweigen.
Na ja, genug lamentiert, bin auf jeden Fall froh, dass sich alles in Wohlgefallen aufgelöst hat (mich würde das Endprodukt übrigens auch interessieren )
Mitglieder in diesem Forum: 0 Mitglieder und 10 Gäste
Du darfst keine neuen Themen in diesem Forum erstellen. Du darfst keine Antworten zu Themen in diesem Forum erstellen. Du darfst deine Beiträge in diesem Forum nicht ändern. Du darfst deine Beiträge in diesem Forum nicht löschen. Du darfst keine Dateianhänge in diesem Forum erstellen.