Files |  Tutorials |  Articles |  Links |  Home |  Team |  Forum |  Wiki |  Impressum

Aktuelle Zeit: Mi Jul 16, 2025 19:29

Foren-Übersicht » Programmierung » OpenGL
Unbeantwortete Themen | Aktive Themen



Ein neues Thema erstellen Auf das Thema antworten  [ 20 Beiträge ]  Gehe zu Seite 1, 2  Nächste
Autor Nachricht
 Betreff des Beitrags: Performanceverlust durch glColor?!?
BeitragVerfasst: Mi Feb 09, 2005 22:18 
Offline
DGL Member

Registriert: So Nov 16, 2003 14:37
Beiträge: 37
Mir ist gerade etwas sehr interessantes aufgefallen: Wenn ich ein von mir geladenes Mesh (ich versuche gerade die Grundzüge eines Loaders für das LDRAW-Format -> http://www.ldraw.org/ auf die Beine zu stellen) mitels glColor3f einfärbe, geht die Framerate im Vergleich zur "farblosen" Variante um 150 bis 200 FPS zurück :shock: Woran kann das liegen??? Damit hätte ich wirklich nicht gerechnet...


Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Feb 09, 2005 23:06 
Offline
DGL Member

Registriert: Do Mai 30, 2002 18:48
Beiträge: 1617
nun, der verlust ist wirklich ein wenig hoch - eventuell rufst du glColor einfach zu oft auf, obwohl es gar nicht nötig ist, die farbe also schon nach wunsch gesetzt ist?


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Feb 09, 2005 23:16 
Offline
DGL Member

Registriert: So Nov 16, 2003 14:37
Beiträge: 37
Zitat:
eventuell rufst du glColor einfach zu oft auf

Nein, daran liegt es glaub ich nicht, weil ich das Modell bevor ich rendere in eine Displayliste packe...


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Feb 09, 2005 23:52 
Offline
Guitar Hero
Benutzeravatar

Registriert: Do Sep 25, 2003 15:56
Beiträge: 7810
Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Guck dir mal die OpenGL Errors an. Eventuell taucht irgendwo ein Fehler auf der die GL ausbremst. (glGetError und gluErrorString)

Displaylisten an sich sollten ja eher keine probleme mit glColorf3f haben. Das wird ja mit einkompiliert.Hast du noch mehr als nur glColor eingefügt? Matrix-Operationen sind z.B. nicht ganz so performanzgünstig.

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


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Feb 10, 2005 10:55 
Offline
DGL Member

Registriert: So Nov 16, 2003 14:37
Beiträge: 37
Ich hab jetzt mal einen Performancegewinn erzielt... Ic hab in der Tat glColor zu oft aufgerufen, weil das Dateiformat, das ich verwende Zeilenweise arbeitet. In jeder Zeile wird ein Dreieck, Viereck, usw beschrieben, das auch ein Farbattribut besitzt. Ich hab den Fehler begangen und hab die Zeile gelesen, die Farbe mit glColor gesetzt, das Dreieck gezeichnet und den selben Spass mit jeder weiteren Zeile wiederholt. Jetzt verwende ich glColor nur noch, wenn die Farbe geändert wird und habe dadurch ca. 370 FPS. Aber auch das erscheint mir noch immer seltsam im Vergleich zur Version ohne Farbe, wo ich gut 480 FPS erreiche.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Feb 10, 2005 11:27 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 05, 2002 10:35
Beiträge: 4234
Wohnort: Dortmund
Wie wäre es denn, wenn du uns einmal ein bisschen Quellcode gönnst und evtl wäre der Name deine Grafikkarte auch nicht so verkehrt? So aus dem reinen Erzählen deiner Seits können wir nur schlecht erraten was genau bei dir das Problem ist.

Sind in dem Format Dreiecke und Vierecke nach Lust und Laune vermischt? Machst du für jede Zeile ein glBegin und ein glEnd?


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Feb 10, 2005 11:36 
Offline
DGL Member

Registriert: So Nov 16, 2003 14:37
Beiträge: 37
Ich hab eine Radeon 9600 und im Moment verwende ich nur Dreiecke. Ich schalte am Anfang mit glBegin(GL_TRIANGLES) die Dreiecke ein und hangle mich dann mit einer for-Schleife durch die Datei.

Aber sehts euch selbst an:

Code:
  1.  
  2. unit DATLoader;
  3.  
  4. interface
  5.  
  6. uses Classes, dglOpenGL, SysUtils;
  7.  
  8. type
  9.   TDATTriangle = record
  10.     color,
  11.     x1, y1, z1,
  12.     x2, y2, z2,
  13.     x3, y3, z3 : integer;
  14.   end;
  15.  
  16.   T3DVector = record
  17.     x, y, z : double;
  18.   end;
  19.  
  20.   TDATLoader = class
  21.   private
  22.     Data    : TStrings;
  23.     DspList : Gluint;
  24.     Color   : Integer;
  25.     function BuildDATTriangle(Line : String): TDATTriangle;
  26.     function CalcNormalVector(Triangle : TDATTriangle): T3DVector;
  27.     procedure SetColor(LDrawColor : integer);
  28.   public
  29.     constructor Create; virtual;
  30.     procedure LoadAndBuild(FileName : String);
  31.     procedure Render;
  32.     destructor Destroy; override;
  33.   end;
  34.  
  35. implementation
  36.  
  37. procedure TDATLoader.LoadAndBuild(FileName : String);
  38. var
  39. i, LineType : integer;
  40. Triangle    : TDATTriangle;
  41. Normal      : T3DVector;
  42. begin
  43. Data:=TStringList.Create;
  44.   try
  45.   Data.LoadFromFile(FileName);
  46.  
  47.   DspList:=glGenLists(1);
  48.   glNewList(DspList,GL_COMPILE);
  49.  
  50.   glBegin(GL_TRIANGLES); //nur vorübergehend!! TRIANGLE_STRIP ist besser, benötigt aber Unterobjekte!!
  51.  
  52.   for i:=0 to Data.Count-1 do
  53.     begin
  54.     LineType:=StrToInt(copy(Data.Strings[i],0,1));
  55.  
  56.     case LineType of
  57.       0 :
  58.       begin
  59.       end;
  60.  
  61.       3 :
  62.       begin
  63.       Triangle:=BuildDATTriangle(Data.Strings[i]);
  64.       //Normal:=CalcNormalVector(Triangle);
  65.  
  66.       //glNormal3f(Normal.x,Normal.y,Normal.z);
  67.       SetColor(Triangle.color);
  68.       glVertex3f(Triangle.x1,Triangle.y1,Triangle.z1);
  69.       glVertex3f(Triangle.x2,Triangle.y2,Triangle.z2);
  70.       glVertex3f(Triangle.x3,Triangle.y3,Triangle.z3);
  71.       end;
  72.     end;
  73.    
  74.     end;
  75.  
  76.   glEnd;   //von GL_TRIANGLES
  77.   glEndList;
  78.  
  79.   finally
  80.   Data.Free;
  81.   end;
  82. end;
  83.  
  84. procedure TDATLoader.Render;
  85. begin
  86. glCallList(DspList);
  87. end;
  88.  
  89. function TDATLoader.BuildDATTriangle(Line : String): TDATTriangle;
  90. var
  91. index : integer;
  92. begin
  93. delete(Line,1,2);  //LineType und erstes Leerzeichen löschen
  94.  
  95. index:=pos(' ',Line);
  96. Result.color:=strtoint(copy(Line,1,index-1));
  97. delete(Line,1,index);
  98.  
  99. index:=pos(' ',Line);
  100. Result.x1:=strtoint(copy(Line,1,index-1));
  101. delete(Line,1,index);
  102.  
  103. index:=pos(' ',Line);
  104. Result.y1:=strtoint(copy(Line,1,index-1));
  105. delete(Line,1,index);
  106.  
  107. index:=pos(' ',Line);
  108. Result.z1:=strtoint(copy(Line,1,index-1));
  109. delete(Line,1,index);
  110.  
  111. index:=pos(' ',Line);
  112. Result.x2:=strtoint(copy(Line,1,index-1));
  113. delete(Line,1,index);
  114.  
  115. index:=pos(' ',Line);
  116. Result.y2:=strtoint(copy(Line,1,index-1));
  117. delete(Line,1,index);
  118.  
  119. index:=pos(' ',Line);
  120. Result.z2:=strtoint(copy(Line,1,index-1));
  121. delete(Line,1,index);
  122.  
  123. index:=pos(' ',Line);
  124. Result.x3:=strtoint(copy(Line,1,index-1));
  125. delete(Line,1,index);
  126.  
  127. index:=pos(' ',Line);
  128. Result.y3:=strtoint(copy(Line,1,index-1));
  129. delete(Line,1,index);
  130.  
  131. Result.z3:=strtoint(copy(Line,1,length(Line)));
  132. end;
  133.  
  134. function TDATLoader.CalcNormalVector(Triangle : TDATTriangle): T3DVector;
  135. var
  136. CrossProduct : T3DVector;
  137. Length       : double;
  138. begin
  139. CrossProduct.x:=Triangle.x2*Triangle.y3-Triangle.x3*Triangle.y2;   //Kreuzprodukt berechnen
  140. CrossProduct.y:=Triangle.x3*Triangle.y1-Triangle.x1*Triangle.y3;
  141. CrossProduct.z:=Triangle.x1*Triangle.y2-Triangle.x2*Triangle.y1;
  142.  
  143. Length:=sqrt(sqr(CrossProduct.x)+sqr(CrossProduct.y)+sqr(CrossProduct.z)); //und den Normalvektor normieren
  144. Result.x:=CrossProduct.x/Length;
  145. Result.y:=CrossProduct.y/Length;
  146. Result.z:=CrossProduct.z/Length;
  147. end;
  148.  
  149. procedure TDATLoader.SetColor(LDrawColor : integer);
  150. begin
  151.   case LDrawColor of
  152.     0  : if Color<>LDrawColor then begin glColor3f(0.13, 0.13, 0.13); Color:=LDrawColor; end else begin end;
  153.     7  : if Color<>LDrawColor then begin glColor3f(0.76, 0.76, 0.76); Color:=LDrawColor; end else begin end;
  154.     8  : if Color<>LDrawColor then begin glColor3f(0.39, 0.37, 0.32); Color:=LDrawColor; end else begin end;
  155.     15 : if Color<>LDrawColor then begin glColor3f(1, 1, 1); Color:=LDrawColor; end else begin end;
  156.     47 : if Color<>LDrawColor then begin glColor4f(1.00, 1.00, 1.00, 0.90); Color:=LDrawColor; end else begin end;
  157.   end;
  158. end;
  159.  
  160. constructor TDATLoader.Create;
  161. begin
  162. inherited Create;
  163. Color:=-1;
  164. end;
  165.  
  166. destructor TDATLoader.Destroy;
  167. begin
  168. if DspList > 0 then glDeleteLists(DspList,1);
  169. inherited Destroy;
  170. end;
  171.  
  172. end.
  173.  


p.s.: Bitte nicht über die Funktion BuildDATTriangle lästern ^^ - ist nur vorübergehend so unelegant gehalten.

Lossy eX: Code durch Pascaltag ersetzt


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Feb 10, 2005 12:01 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 05, 2002 10:35
Beiträge: 4234
Wohnort: Dortmund
Also so weit sieht das für ganz gut aus und eine Radeon 9600 sollte mit glColor wahrlich keine Probleme haben.

Das hat zwar höchstwahrscheinlich nichts mit dem Farbproblem zu tun aber ich weiß auch nicht ob das zu Problemen führen kann. Kann es sein, dass dein Model wahnsinnig groß ist? Und zwar lädst du deine Koordinaten in einen Integer und übergibst diese dann als Single. Delphi Konvertiert das für dich und OpenGL bekommt davon nichts mit. Aber um eine genügend große Auflösung mit einem Integer hinzubekommen müssen dessen Werte schon richtig groß sein. Also so im 1000 - 10000 Bereich minimum. Denke ich mal. Ich habe so etwas noch nicht ausprobiert. Aber evtl. probierst du es mal in dem du das Model nicht ganz so groß lädst. Also anstelle deiner Integer X, Y und Z benutzt singles. Beim Laden teilst du diese dann erst einmal durch einen hardcodierten Wert. Je nachdem wie groß das Model ist. Kann ich ja so nicht genau sagen.

In etwa so
Code:
  1. Result.x1 := strtoint(copy(Line,1,index-1)) / 1000;


Vielleicht hat das ja einen Effekt auf das Gezeichnete. Vielleicht aber auch nicht. Kann ich so nicht sagen. Ist nur an dem Haarem herbei gezogen. ;-) Aber ein Versuch schadet nicht. Denke ich mal.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Feb 10, 2005 12:27 
Offline
DGL Member

Registriert: So Nov 16, 2003 14:37
Beiträge: 37
So, ich hab mal die Integer auf Single geändert.
Zu deinen Vermutungen: Ja, das Model ist sehr groß (aber sehr polygonarm), wird aber mit glScalef auf die nötige Größe geschrumpft. Ich hab aber mal das glScalef rauskommentiert und deinen Ansatz mit dem hardgecodeten Faktor probiert - mit dem Effekt das sich die Framerate nicht geändert hat. Ich bekomme aber langsam den Verdacht das es sich um ein Füllratenproblem handelt, denn wenn ich das Modell rotieren lasse ist die Framerate immer dann am niedrigsten, wenn man es direkt von vorne oder hinten sieht. Ich werd mir wohl mal Backfaceculling ansehen...


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Feb 10, 2005 13:34 
Offline
Guitar Hero
Benutzeravatar

Registriert: Do Sep 25, 2003 15:56
Beiträge: 7810
Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Das solltest du wirklich!
Aber der Performance einbruch erscheint wirklich erst durch das glColor? Is bisl seltsam...

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


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Feb 10, 2005 15:40 
Offline
DGL Member

Registriert: So Nov 16, 2003 14:37
Beiträge: 37
Jep, is scho seltsam... Aber kurz etwas andres: Sobald ich Licht aktiviere sieht alles -sehr- seltsam aus. Liegt das daran, dass das Modell aus relativ wenigen polygonen besteht?? Die Normalen dürften passen (Wie ich sie berechne steht im obigen Sourcecode). Smoothshading und GL_COLOR_MATERIAL sind an.


Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Feb 10, 2005 17:31 
Offline
DGL Member

Registriert: Do Nov 20, 2003 19:52
Beiträge: 48
Wohnort: Tillingen bei Chemnitz
Schau dir am besten mal die berechneten Normalen mit dem Debugger an. Sieht für mich so aus als würden die Normalen einmal 'richtigrum' und einmal 'falschrum' berechnet, also bei einem Dreieck zeigen sie nach außen und beim nächsten nach innen ins Auto.

_________________
...die Idee ist gut, doch die Welt noch nicht bereit...


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Feb 10, 2005 18:04 
Offline
DGL Member
Benutzeravatar

Registriert: Di Dez 02, 2003 12:47
Beiträge: 300
Wohnort: Marburg
Außerdem sieht man in den Farben auch nicht viel Variation (durchs Licht) eventuell haben die Normalen abgesehen von falscher Richtung auch falsche Längen (entweder bei der Übergabe auf die Länge 1 bringe oder zu begin
glEnable(GL_NORMALIZE);
aufrufen (kostet aber Performance))...
Kann natürlich sein, du weißt das schon längst :-)

_________________
Nothing, oh sweet nothing,
today we are doing nothing at all...
http://www.geo-progs.de


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Feb 10, 2005 18:29 
Offline
DGL Member

Registriert: So Nov 16, 2003 14:37
Beiträge: 37
Die Normalen zeigen in die richtige Richtung, mit GL_NORMALIZE sieht das ganze aber trotzdem um Welten besser aus. Ich hab mir mal die Werte meiner normierten Vektoren angesehn und bemerkt das sie nicht normiert sind... Ich hab da ein paar selbst nachgerechnet und bin nicht auf den erwünschten Betrag von 1 gekommen...

edit: Haben doch den richtigen Betrag, hab nur nicht genau genug gerechnet. Also scheinen sie doch in die falsche Richtung zu zeigen. Wie bringe ich diese Vektoren in die richtige Richtung??


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Feb 10, 2005 18:58 
Offline
DGL Member

Registriert: Do Apr 08, 2004 16:55
Beiträge: 516
Wenn ich es richtig verstanden habe was falsch ist dann musst du die dinger umdrehen indem du die Vectoren anderst rum definierst.

_________________
Shareholder und Leitender Entwickler bei Pipedream-Games.

Zitat: Siehst du diesen Park da unten? Jeden Tag lernen sich darin Menschen kennen und verlassen einander. Und du hast dein ganzes Leben Zeit darin zu gehen.


Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 20 Beiträge ]  Gehe zu Seite 1, 2  Nächste
Foren-Übersicht » Programmierung » OpenGL


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 12 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.

Suche nach:
Gehe zu:  
cron
  Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de
[ Time : 0.012s | 14 Queries | GZIP : On ]