Um die Leistungsfähigkeit meines 2D-Evaluator-Objektes zu testen - ich wollte wissen, ob Sichtbarkeitstest für die einzelnen Patches ausreichend sind, oder ob eventuell noch LOD integriert werden sollte - habe ich heute mal eine richtig große "Welt" erstellt, welche aus über einer Million Patches besteht (je nach Geh-/Laufgeschwindigkeit ca. 5 bis 20 Min. von einem Rand zum anderen).

Die Landschaft wurde über dem Heightfield eines Satellitenfotos erstellt, über das ich auch gleich die zugehörige Luftaufnahme als Textur legte. Damit die Landschaft aus der Nähe betrachtet nicht nur aus verwaschenen Farbflecken besteht, wollte ich dann noch eine Detailtextur drüber legen - und nichts funktionierte mehr.

Zuerst wurde die Textur weiß, nach der Veränderung der Verknüpfungsparameter verschwand dann das ganze Objekt von der Bildfläche. Etwas entnervt (ich war mir eigentlich ziemlich sicher, dass alles funktionieren sollte) speicherte ich die Szene als Delphisource ab - mit genau dem selben Ergebnis. Eine halbstündige Debugsession ergab keinerlei Aufklärung, schließlich kam ich auf die glorreiche Idee, das Ganze mal auf meinem Zweitrechner (Desktop, P4, GF3) auszuprobieren - und siehe da, alles klappte wunderbar.

Nun liebe ich solche Fehler, die sich nicht mal ordentlich reproduzieren lassen, natürlich ganz besonders. Andererseits wollte ich die Schuld aber auch nicht unbedingt auf den Radeon Treiber schieben (obwohl der - zugegebenermassen - etwas flapsiger programmiert scheint, als die Detonator Treiber von NVidia), wo doch die Radeon 9000 immerhin sechs programmierbare Textureinheiten zur Verfügung stellt. Lag also der Fehler doch in meinem Code? Versuchshalber zog ich die Programmierung der zweiten Textureinheit aus dem Evaluatorobjekt und fügte sie händisch an den Start der Renderschleife - und oh große Verblüffung, alles klappte einwandfrei. Das war nun wirklich seltsam, denn ich machte ja überhaupt nichts anderes, als halt vorher in der Display Routine des Objektes - also zog ich die Programmierung der ersten Textureinheit auch noch heraus - und das ganze Objekt war wieder verschwunden.
Mit meinem Latein etwas am Ende vertauschte ich versuchweise die Programmierung der Textureinheiten (aktivierte also als erstes die Textureinheit 2, band die entsprechende Textur daran und setzte allfällige Parameter und machte dann das selbe mit der Textureinheit eins - ich tat tatsächlich nichts anderes als folgendes Konstrukt:
<!--pas--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td>Delphi-Source </td></tr><tr><td id='CODE'><!--pas1--><pre>
e2dDefaultTextureSet[<span class='integer'>0</span>].TextureSettings := TextureSettings1; // aktiviert Textureinheit #0 und stellt potentielle Parameter ein
e2dDefaultTextureSet[<span class='integer'>0</span>].Texture := Santa_Fe_Stuck; // bindet Textur an das jeweilige Texture Target
e2dDefaultTextureSet[<span class='integer'>1</span>].TextureSettings := DefaultTextureSettings; // selbiges mit Textureinheit #1
e2dDefaultTextureSet[<span class='integer'>1</span>].Texture := textura4;
</pre><!--pas2--></td></tr></table><span class='postcolor'><!--pas3-->
durch dieses zu ersetzen (die Texturen und jeweiligen Parameter werden in der Reihenfolge ihrer Indizes an den OpenGL Renderer gesandt)
<!--pas--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td>Delphi-Source </td></tr><tr><td id='CODE'><!--pas1--><pre>
e2dDefaultTextureSet[<span class='integer'>0</span>].TextureSettings := DefaultTextureSettings; // Textureinheit #1
e2dDefaultTextureSet[<span class='integer'>0</span>].Texture := textura4;
e2dDefaultTextureSet[<span class='integer'>1</span>].TextureSettings := TextureSettings1; // Textureinheit #0
e2dDefaultTextureSet[<span class='integer'>1</span>].Texture := Santa_Fe_Stuck;
</pre><!--pas2--></td></tr></table><span class='postcolor'><!--pas3-->
und siehe da, alles funktionierte. Auch in Mcad klappte alles wunderbar, wenn ich dafür sorgte, dass die Textureinheiten in der jeweils umgekehrten Reihenfolge programmiert wurden (also zuerst die höheren Textureinheiten und dann erst diejenigen mit den niedrigeren Indizes).

Prinzipiell ist das zwar kein Problem (kann man ja leicht berücksichtigen), verwundern tut es mich aber dennoch, da dies nirgends dokumentiert war - immerhin sollte es meiner Ansicht nach egal sein, in welcher Reihenfolge Textureinheiten programmiert werden - und bei den NVidia Treibern ist dies auch der Fall. Mit TEXTURE_CROSSBAR kanns auch nichts zu tun haben, das braucht man ja nur, wenn man zwei beliebige Textureinheiten mittels COMBINE verknüpfen möchte (außerdem unterstützen sowohl die Radeon 9000 als auch die GF3 diese Extension).

Vielleicht kann ja noch jemand mit einer Radeon Karte dieses Verhalten nachvollziehen - und vielleicht hilft es auch weiter, falls mal aus unerklärlichen Gründen die Mehrfachtexturierung nicht klappen sollte.

Ach ja, hier gibt's noch einen ScreenShot der Landschaft (von meinem Notebook mit Radeon 9000 - welch Triumph , wenn man genau schaut, kann man auch die Detailtextur noch erkennen):


Hochladen tu' ich diesmal nichts, weil das Demo auch gepackt noch über 15 MB benötigt. Ist ja auch nichts Besonderes dran, außer dass es halt sehr groß ist (halbwegs intelligent programmierte Sichtbarkeitstests sind übrigens ausreichend - auch ohne LOD habe ich in 1400x1050 noch hohe Framerates, auch wenn ich alles soweit wie möglich runtertakte).

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

Doch.....der Screenshot ist gut zu sehen (aber vielleicht liegts an deiner Graka Enoritz aus den von Mars genannten Gründen...hehe)

Ne im Ernst....ich war gerade dabei mir das Tut von Phobeus (u.a. über Multitexturing) durchzulesen....da kommt der post genau richtig....ich bin jetzt leicht verwirrt :blink:

Hmm, bei mir klappt der Screenshot auch nur sporadisch. Liegt wahrscheinlich an Geocities - hab's jetzt auf meinen Chello-Account geladen.

@Verwirrung :rolleyes: :
Solche wollte ich keine stiften - das war halt nur eine Besonderheit, die mir heute in dieser Form zum ersten Mal aufgefallen ist. Also, damit alle was davon haben - wenn man MultiTexturing verwenden möchten, muss man

1) mittels glActiveTexture die Textureinheit festlegen
2) Textureinstellungen wie texture target (2D Texturen einschalten), texture environment, texture coordinate generation festlegen
3) die tatsächliche Textur an das zugehörige texture target binden

Tja, und zumindest im Fall meiner Radeon (und meiner Treiberversion) sollte dies so geschehen, dass die Textureinheiten in umgekehrter Reihenfolge befüllt werden (also Texture unit 0 als letztes). Warum dies so ist - ich weiß es nicht, auf der Geforce 3 ist es jedenfalls nicht notwendig - also kann es zumindest nicht schaden, wenn man sich daran hält.

Hat man es dann geschafft, wird man z.B. mit so einem Bild belohnt:

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

Ich hab bei meinem Umstieg auf ne Radeon9700 auch bemerkt, das die Radeontreiber in Sachen OpenGL weniger verzeichlich sind als die nVidia-Treiber und anscheinend auch hier und dort ein paar Eigenheiten haben.Das liegt halt daran, das ATI ihr Hauptaugenmerk auf D3D legen, während nVidia sich eher auf OpenGL konzentrieren.

Ganz stark macht sich das z.B. im Selektionsmodus bemerkbar.Dort hatte ich bisher ein SwapBuffers(DC) drinne, das auf meiner GF4 keine Probs machte, während es auf meiner Radeon zu schweren Darstellungsproblemen führte.
Genauso die Sache mit glPush bzw. glPopAttrib, die auf ner GeForce kaum Leistung kosten, während sie die Framerate auf meiner 9700er Radeon in den Keller zogen.Bin mal gespannt auf welche Probleme ich noch so stoße...allerdings hab ich jetzt den Vorteil, dass ich sowohl nen Rechner mit ner Radeon als auch nen Rechner mit ner GeForce zur Verfügung habe, womit sich solche Probleme schnell aufspüren lassen.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

mensch....wenn ich mal mehr Zeit und Wissen habe, muss ich mich mal ein bisschen mehr mit Mcad beschäftigen.....der 2. Screenshot sieht übrigens genial aus......

Da kann ich nur zustimmen - es ist auf jeden Fall besser, wenn man seinen Code auf einer möglichst breiten Palette von Systemen testen kann. Es nützt einem ja nichts im stillen Kämmerlein ein mega-geniales Programm zu entwerfen, wenn's dann nur bei zwei von zehn Leuten läuft.

@Enoritz, Geschwindigkeit
Tja, diese Information wird dir nicht so sehr viel nützen, weil du ja nicht vergleichen kannst. Ich habe mit der Radeon 9000 und einem 1.3 Ghz Pentium M aber über 100 FpS (1400x1050), schalte ich sämtliche Energiesparoptionen ein (600 Mhz, GraKa Prozessor und Ram auf niedrigstem Level) sind's immer noch 35. Man könnte das Ganze noch optimieren, was aber meiner Ansicht nach nicht notwendig ist - da sogar auf älteren Rechnern mit einer niedrigeren Auflösung noch genügend Leistungsreserven drinstecken sollten (so ein Geschwindigkeitsmonster ist die Radeon 9000 ja nicht).

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

@deaktiviert

hmm - da hab' ich jetzt zuviel Columbo geschaut . Vielen Dank für die Blumen

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

Hmmm. Gut zu wissen, dass es solche Probleme gibt.

Eines konnte ich bei mir allerdings auch noch feststellen. Ich hatte bei mir ein kleines Surface gerendert (128x128, TRIANGLE_STRIP, 2 Schleifen aus einer Matrix).
<!--pas--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td>Delphi-Source </td></tr><tr><td id='CODE'><!--pas1--><pre> <span class='reserved'>for</span> Row := Low(FHeightMap[Col]) <span class='reserved'>to</span> High(FHeightMap[Col]) -<span class='integer'>1</span> <span class='reserved'>do</span> <span class='reserved'>begin</span>
glBegin(GL_TRIANGLE_STRIP);
<span class='reserved'>for</span> Col := Low(FHeightMap) <span class='reserved'>to</span> High(FHeightMap) -<span class='integer'>1</span> <span class='reserved'>do</span> <span class='reserved'>begin</span>
glTexCoord2f(Col / High(FHeightMap)-<span class='integer'>1</span>, Row / High(FHeightMap)-<span class='integer'>1</span>);
glVertex3f(Col -<span class='integer'>1</span>, FHeightMap[Col ][Row ], Row -<span class='integer'>1</span>);
glTexCoord2f(Col / High(FHeightMap)-<span class='integer'>1</span>, (Row + <span class='integer'>1</span>) / High(FHeightMap)-<span class='integer'>1</span>);
glVertex3f(Col -<span class='integer'>1</span>, FHeightMap[Col ][Row +<span class='integer'>1</span>], Row );
<span class='reserved'>end</span>;
glEnd;
<span class='reserved'>end</span>;</pre><!--pas2--></td></tr></table><span class='postcolor'><!--pas3-->
An und für sich überhaupt nichts wildes. Nicht mal für meine alte TNT2. Allerdings scheinen die Radeon im iterativen Modus mal so voll in den Keller zu gehen. Im Vergleich zur TNT2 hat da die Radeon 9500 Pro gerade mal 50% mehr Leistung.
Bei einem anderen Programm (Delphi3d.net VBO) hatte die Karte dann ihr wahres Gesicht gezeigt. 100 MT/s anstelle von 2.4MT/s.

Hm, kann es evtl daran liegen, dass du, wenn du die Texturobjekte von "unten nach oben" programmierst, dass du dann am Ende nicht mehr das erste Objekt als aktives nimmst und es bindest?

Das wäre so mein Einfall zum Problem.
Sry, wenn ich dir jetzt was unterstellt hab

mfg,
Dennis.

_________________
Bush's on a highway to hell with the whole world blind, leading it straight into the flames.

Nein macht ja nix. Eine Idee ist es auf jeden Fall. Allerdings SOS hatte ja geimeint, dass die Radeon auf D3D ausgelegt ist und das eine Testprogramm belegt diese aussage auch wieder. Dort werden nämlich keine Texturen und kein Licht verwendet. Und es ist trotzdem langsam. Das liegt wohl irgendwie an der OpenGL implementation der Graka.
Ach ja ich für meinen Fall finde die Resultate des Tools sehr interessant.
<a href='http://www.fl-tw.com/opengl/GeomBench/' target='_blank'>http://www.fl-tw.com/opengl/GeomBench/</a>

zwischen optimierung, bugs und falscher implementierung ist ein unterschied, es mag ja sein, dass ATI Karten bei OpenGL keine so gute Performance haben wie NVIDIA, aber ich kann mir nicht vorstellen, dass dabei inkompatibilitäten auftreten und das bei Techniken, die als Standard gelten.

im übrigen war das nicht auf dein Post bezogen
das war ein Gedanke zum allgemeinen Problem

mfg,
Dennis.

_________________
Bush's on a highway to hell with the whole world blind, leading it straight into the flames.

Die Performance der ATI-Karten ist sowohl in D3D als auch in OpenGL besser, und zwar besonders dann wenn man Bildqualitätsfeatures wie AA oder AF aktiviert.

Was allerdings "schlechter" ist, ist die Fehlertoleranz der OpenGL-Treiber.Während nVidia-Treiber einiges verzeihen, quittieren die ATI-Treiber einige Fehler schonmal mit nem Hardlock.Ich hab mal aus Versehen vergessen ein glBegin(GL_TRIANGLES) mit nem glEnd zu quittieren, was meinen Rechner komplett festgefroreren hat.Mit ner GeForce4 wärs nicht passiert...das ist zwar nervig, zwingt einen aber dazu weniger Fehler zu machen

Wenn man allerdings korrekt proggt, und sich auch 100% an Standards hält (was durch die Tatsache, das viele Tuts auf GeForce-Karten geschrieben werden allerings stark erschwert wird), sollten ATI-Karten weder Probleme machen noch langsamer sein.Schlimm wirds halt dann, wenn man (so wie ich) nach langjähriger Programmierung von nVidia zu ATI wechselt...das hat jetzt allerdings den Vorteil, das ich auf beiden Herstellern testen kann und so Probleme im Vorhinaus vermeiden kann.Allerdings geht ihn Sachen grottige OpenGL-Treiber und Unterstützung nichts über meine alte KyroII...das war wirklich schlimm.

Mein NapalmBomber3D läuft jetzt, nachdem ich den Rendercode an die Eigenheiten meiner Radeon9700 angepasst hab ein gutes Stück schneller als auf meiner alten GeForce4 Ti4-4400.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

So zu sagen "gezwungene Optimierungen"?

Aber das Problem mit dem Hardwarelock kann ich auch nur bestätigen.
Diese Testprogramm hat auch die Möglichkeit Vertex Array Objects zu testen. Allerdings mir dem 3.2 Treiber von Ati hat sich dabei jedes mal meine Kiste aufgehangen. Mit dem 3.4er geht es auf einmal.

@Dennis:
Über die Performance beklage ich mich auch nicht (genaugenommen beklage ich mich überhaupt nicht ) - deine Idee mit den "umgekehrten" Textureinheiten ist ausserdem gut - denn sobald vor dem tatsächlichen Rendern eine andere Textureinheit als die erste aktiv ist, sieht man nichts mehr.
Allerdings machte (und mache) ich nichts anderes, als zuerst mittels glActiveTexture die Textureinheit festzulegen, Texturumgebung und -koordinatengeneration einzustellen - und dann das Texturobjekt dranzubinden. Es sollte nicht notwendig sein die Textureinheit zurückzusetzen, da ohnehin vor dem Binden der einzelnen Texturen explizit gesagt wird, welche Textureinheit denn nun zum Handkuss kommt.
Für OpenGL Kommandos ist ja z.B. definiert, dass glTexCoordxx Kommandos sich automatisch auf die erste Textureinheit beziehen - unabhängig davon, welche gerade aktiv ist (und mit glMultiTexCoordxx Kommandos kann man Textureinheiten völlig unabhängig ansteuern, ohne sich um die Aktive kümmern zu müssen).

Übrigens - ein Bug hat sich bisher konsequent durch sämtliche von mir getesteten ATI Karten gezogen (von ATI Rage Mobility M1 über ATI Rage Pro 128 bis zu meiner jetzigen Radeon 9000): die Befehle

werden beide mit einem Invalid Enumerant (bei Aufruf von glGetError) "belohnt", anstatt dass die Behandlung des specular lights geändert würde.
Aber bevor ich jetzt zu kritisch wirke - ATI hat sich wirklich sehr gebessert, was OpenGL Treiber betrifft, und genaugenommen ist die Texturierung ohnehin nicht wirklich ein Problem, da sie ohne jeglichen Performance- oder Qualitätsverlust zum Laufen zu bekommen ist.

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/