moin, moin

Ich habe ein Programm geschieben, mit dem man die Aerodynamischen Beiwerte von Flugzeugen berechnen kann.
Für die Darstellung der Flugzeugkonstruktionen und Ausgabe von Strömungsvorgängen habe ich OpenGl mit Rotations- , Schiebe- und Zommfunktionen verwendet.

Wer Intersse hat , kann sich das Programm unter www.freenet-homepage.de/frankranis (FLZ_Vortex_DEMO) herunterladen.

So nun zu meinem Problem :
Bei einigen Rechnerkonfigurationen kommt es zu mehrwürdigen Phänomenen bei der OpenGl-Ausgabe.
1) Verdeckte Objekte scheinen teilweise schlierenhaft durch die vorderen sichtbaren Flächen .
Dies habe ich auf mehren zur Verfühgung stehenden Rechnern beobachtet , aber nicht auf allen.
Dabei ist das Betriebssytem nicht entscheident ob Win2000 , XP oder Vista ist dabei Wurst.
2) War der erste Fehler unschön aber zu Verschmerzen ist der zweite auftretende Fehler richtig ärgerlich und füht zum Programmabsturz.
Die Flugzeugkonstuktion wird relativ um einen Flugzeugnullpunkt herum aufgebaut und dieser Nullpunkt ist dann im Raum verschiebbar.
Komme ich nun mit diesem Nullpunkt in die Nähe der Ränder des Ausgabefensters bricht das Programm mit einer Fehlermeldung ab und bleibt dann in einer dll der Grafikkartentreiber hängen.

Wie gesagt die Fehler treten nicht auf allen Rechnern auf, ich tippe daher auf ein Grafikartenproblem (Grafikkartentreiber), da jeder benutze Rechner eine andere Grafikkarte eingebaut hat.

Ich habe sogar nach einiger Suche eine Möglichkeit gefunden die Fehler in den Griff zu bekommen.
Man gehe in die Systemsteuerung , dann auf Anzeige / Einstellungen / Erweitert / Problembehandlug und stelle die Hardwarebeschleunigung auf einen Wert von 0-20%.
Danach funktionierte die OpenGl-Ausgabe auf allen Problemrechnern ohne Abstürze und ohne Schlieren.
Schön ist diese Lösung aber nicht .

Frage :
Ist das Phänomen bekannt und kann man es vielleicht durch irgend welche Eingriffe bei der Initalisierung von OpenGl in den Griff bekommen ?

Zum Programmieren benutze ich Delphi 5 mit der mit OpenGL12 .

Wäre super , wenn mir jemand Tipps geben kann.
Ich denke ich bin nicht der einzige der das Problem hat, oder etwa doch?

Gruß

Frank Ranis

Wenn du die Hardwarebeschleunigung deaktivierst sorgst du dafür, dass Windows dein OpenGL per Software berechnet. Das sollte nur eine absolute Notlösung sein. Für deinen Anwendung (die im übrigen interessant aussieht) mag das moch gehen, da du keine zu anspruchsvollen Sachen verwendest. Aber die Implementation von Windows ist fehlerhaft und hoffnungslos veraltet / langsam.

Zu deinen Problemen. Du würdest uns und dir einen riesen gefallen tun, wenn du bei solchen Grafikfehlern davon ein Bild anhängst (wenn möglich) und bei "Fehlermeldungen" diese mit ausgibst. Da deine Anwendung aber eher vom typischen Gebiet abweicht (primär sind hier Spiele und Spielerechner vertreten) solltest du auch erwähnen was dort für ein Grafikchip eingebaut ist. Also um uns eine ungefähre Richtung geben zu können.

Ist das System mit den Grafikfehlern (1) eigentlich auch das mit dem Absturz (2)?

1. "schlieren" könnte auch eine Art ZFighting sein. Dabei kann es passieren, dass Flächen die gleiche Tiefe besitzten und die Grafikkarte sich nicht entscheiden kann. Es kann also sein, dass die Grafikkarte mit den Tiefenbuffer Einstellungen nicht ganz klar kommt. Bei ältere Karten wurde der Tiefenbuffer mangels Speicher auch so klein wie möglich gehalten. 16 statt 24 Bit. Und je nachdem was du für Wert bei gluPerspective gesetzt hast kann es sein, dass sich die Flächen in einem Bereich des gesamten Wertebreiches ballen. Evtl könnte es sogar sein, dass du gar keinen hast, weil das Pixelformat ungünstig etc. In CreateRenderingContext wird evtl ein DescribePixelFormat aufgerufen. Dieses beschreibt das Format. Und in dem Descriptor steht in der Eigenschaft cDepthBits die Bittiefe für den Z-Buffer.

2. Ich hatte früher mal bei einer Anwendung das Problem, dass die ziemlich komisch aussah. Dabei hatte ich sich um einen Laptop mit Intel chip gehandelt. Und die OpenGL Implementation von Intel war zu mindest früher nicht so wirklich die Wucht. Evtl solltest du mal schauen ob aktuelle Grafiktreiber installiert sind. Sonst kann ich da gerade nicht viel zu sagen.

Hallo Frank,

das sieht ja mal echt schick aus. Auf meinem Rechner hier auf der Arbeit (Geforce2 GTS) läuft es einwandfrei. Keine Schlieren. Kein Absturz.

zu 1)
ich tippe mal ganz stark auf die grafikkarten. bzw auf standard windows treiber. je nachdem welche billig-grafikkarte da verbaut wurde kann die eventuell so gut wie garkein opengl 1.2 .
und wenn man nun die hardwarebeschleunigung deaktiviert wird das ganze in software gerendert. und schon funktionierts.

zu 2)
könnte das vielleicht eine division durch 0 sein?


hast du eine liste der verwendeten grafikkarten? versionsnummern der treiber?


p.s.
funktionieren die berechnungen auch im kleinen masstab? dann könnte ich mich ja doch mal an eine eigenkonstruktion setzen statt fertige flieger zu holen


gruß

damadmax

_________________
Es werde Licht.
glEnable(GL_LIGHTING);
Und es ward Licht.

Zitat aus einem Java Buch: "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"

on error goto next

Hallo Lossy eX,

danke für deine rasche Antwort.

Ich habe hier zwar zwei Bilder, bin aber zu dösig , die hier abzubilden, gibt es da nen eifachen Trick ?

Mein Platzrechner:
Grafikarte S3ViRGE
Win2000
Hier tritt nur der Fehler mit den Schlieren auf, Programmabstürze hatte ich nicht.

Mein Laptop:
Grafikarte VIA Chrome9
Zunächts Vista (schei....) , dann mit WinXP , bei beiden Betriebssystemen der gleiche Fehler.
Hiert tritt sowohl der Schlierenfehler als auch der Bock mit dem Absturz auf , sobald man mit der Hardwarebeschleunigung auf über 20% geht.
Die Fehlermeldung muß ich heute abend noch mal provozieren, habe den Laptop gerade nicht zur Hand.

Kam gerade noch ne frische Fehlermeldung von einem Kollegen rein.
Die gesamte OpenGl-Szene wird nur schwarz dargestellt, also schwarze Linien und schwarze Flächen.
Er hat einen WinXP-Rechner mit
Nvidia GeForce 7600 GS-Grafikarte.
Ob die Geschicht mit dem runterfahren der Hardwarebeschleunig geht habe ich noch nicht gefragt.

Was mir so ein bisschen Sorgen macht ist , dass recht häufig Fehler auftreten .
Ich habe bald die Befürchtung dass ich bei der Initalisierung von OpenGl Bockmist gebaut habe, unten die Ini-Routine .
Habe ich seit Urzeiten so drinnstehen (irgendwo mal abgeschrieben) und funtze ja auch irgendwie (wie man sieht, mehr schlecht als recht).
Bei manchen Einstellungen kann ich nur raten , wofür die gut sind .

Mein Spezialgebiet ist halt die Aerodynamik, nicht OpenGl an sich , ich fand es halt passend für meine Anwendung und bin mit den Möglichkeiten die mir OpenGl bereitstellt eigendlich auch ganz glücklich.


Gruß

Frank Ranis





Edit Lossy: Pascaltags hinzugefügt.

Hallo damadmax,

1) kann gut sein , das billige Grafikarten der Grund sind , gibts denn eine Softwaretechnische Lösung, die Hadwarebeschleunigung beim Start des Programmes runterzusetzen und beim Schließen wieder auf den alten Wert zu bringen?
Ich habe nur wenig Lust jedem Programmnutzer , der Probleme hat, durch die Systemststeuerungseinstellungen zu jagen .

Eine Frage ist dann aber, warum gibt es bei euch OpenGl-Anhängern nicht auch diese Probleme, die müßten dann doch alle Nase lang auftreten.
Es hat doch nicht jeder die Nonpulsultra-Grafikarte im Rechner stecken.

Ich habe eher meine Routinen im Verdacht, aber dafür seit ihr ja hier die Spezialisten, die ich fragen muß.

2)
> könnte das vielleicht eine division durch 0 sein?
Dann müsste es ja auf jedem Rechner knallen , für die Positionierung des Flugzeugnullpunktes benutze ich



dann die Zeichnung relativ um diesen Nullpunkt und danach wieder zurück



>p.s.
>funktionieren die berechnungen auch im kleinen masstab? dann könnte ich mich ja doch mal an eine eigenkonstruktion setzen statt fertige flieger zu holen

Oh, ein Modellflieger, hätte ich hier gar nicht erwartet.

Du kannst damit eigentlich jedes Flugzeug rechnen, solange deine Geschwindigkeit unterhalb der Schallmauer bleibt.
Ob Du nun einen Spatz oder eine A380 rechnen willst ist dabei eigentlich Wurst.

Das Programm ist auch lange noch nicht fertig, die Wunschliste ist noch km lang.
Ziel ist es, irgend wann mal die Eierlegende Wollmilchsau im Bereich der Modellfliegerkonstruktion zu schaffen.
Von den Millionenteuren Cray-Rechnern mit passender Software kann man als Modell-Pilot ja nur träumen und selbst im Traum ist es noch unbezahlbar.


Gruß

Frank

// Edit Lossy: Pascaltags hinzugefügt.

Das Schlieren wird wohl wirklich durch einen nicht vorhandenen Z Buffer entstehen. Bei CreateRenderingContext der vierte Parameter. Trage dort direkt nach der 32 mal eine 16 ein. Denn je nachdem was die Grafikkarte unterstützt wird das passenste Format ausgewählt. Und es scheint so als ob sie Tiefenbufferlose RCs unterstützt. Was dann zur Folge hat, dass die alle die gleiche Tiefe haben und der Tiefentest immer true zurück gibt. Also verdeckt nie eine Flächen die Andere.

Das mit dem Schwarz liegt höchstwahrscheinlich an deinem Licht. Wenn du mit glScale deine Objekte vergrößerst bzw verkleinerst, dann müsstest du auch die Normalen anpassen. Das kann man aber auch automatisch berechnen lassen. Könnte evtl schon ausreichen. Ansonsten kann es sein, dass da am Licht noch etwas fehlt was die Karte gerne haben möchte.


Chrome9: Das klingt spannend. So spontan würde ich sagen. Schau ob da ein aktueller Treiber installiert ist. Wenn nicht tu es. Und sollte das Problem immer noch auftreten, dann solltest du mal alles unnötige aus dem Programm rauspacken. Evtl auch eine kleine Testanwendung machen mit der du auf dem System etwas rumspielen kannst. Vielleicht kannst du das Problem ja eingrenzen und dann aufpassen, dass es nicht mehr auftritt.

Das Polygonoffset in deinem Code brauchst du das? Wenn nicht würde ich es auch nicht aktivieren. Also trifft eigentlich auf alles zu. Was man nicht braucht sollte man nicht aktivieren.

Wenn du viel mit älteren System zu tun hast, dann solltest du auch darauf achten, dass alle die Dinge du du benutzt auch wirklich verfügbar sind. Ansonsten kann das seltsame Effekte hervorrufen. Also wenn du eine OpenGL 1.2 funktionalität benutzt aber die Karte nur 1.1 kann dann wird sie das ignorieren. Da dein Header aber nur 1.2 kann ist die chance etwas zu erwischen was die Karten nicht können relativ gering. Wichtiger wird das wenn du irgendwann mal unsere Header (dglOpenGL.pas) benutzt.

PS: Bei uns tritt so etwas nicht auf, weil hier in erster Linie der Fokus auf Spiele bzw auf dem grafischen Bereich liegt. Ein minimum an vorhandener Hardware darf man dort erwarten. Wenn nicht sogar recht aktuelle Systeme. Wobei hier aber auch nicht alles Problemlos läuft. Die Probleme sind nur andere.

Also das älteste, was ich hier Grafikkartentechnisch zu bieten haben, ist besagte Geforce2 GTS. Und auf der läuft dein Prog wie gesagt ohne Probleme.
Werde ich heute abend mal auf einer 5900GT und einer 8800GTS probieren. Habe neulich ein kleines Testprogramm (in einem Würfel herumspringende Kugeln) auf dem Dellnotebook meiner Freundin getestet. Irgendeine ATI xxxx (muss ich nachsehen). Satte 2 FPS. Allerdings konstant. Egal wieviel Geometrie vorhanden war. Aktivierte Shader. Keinerlei Fehler. Nur eben echt langsam.

Ob man OGL direkt im Softwaremodus aktivieren kann weiss ich nicht. Da gibt es hier aber Leute, die das wissen.


Aber mal was ganz anderes. Ich find das Programm echt klasse.
Mal sehen ob ein Aerodynamik-noob seinen fliegenden Traum von einem Nurflügler-Slowflyer Marke Eigenbau realisiert bekommt

_________________
Es werde Licht.
glEnable(GL_LIGHTING);
Und es ward Licht.

Zitat aus einem Java Buch: "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"

on error goto next

Hallo

@ Lossy eX

Leider hat die Einstellung

hrc := CreateRenderingContext(dc, [opdoubleBuffered], 32, 16, 0, 0, 0, DummyPAL);

anstelle von

hrc := CreateRenderingContext(dc, [opdoubleBuffered], 32, 0, 0, 0, 0, DummyPAL);

in Punkto Schlierenbeseitigung nichts gebracht.

Der Einbau von

glEnable(GL_NORMALIZE)

sowie das Abschalten von

// glPolygonOffset(0.05, 2);

hatten auch keinen sichbaren Effekt.

Hier noch mal alle Grafikartendaten meines Notebooks mit beiden Fehlern.
Grafikkarte : Via Chrome9 HC IGP
Chiptyp: Via Chrome9 HC IGP
Speicher : 128 MB
Treiberanbieter: S3Graphics Co. Ltd
Treiberdatum: 15.11.2006
Treiberversion : 6.14.10.78

Dann werde ich mal suchen und schauen, ob es einen neueren Treiber gibt.

Wenn es für mein Problem keine weiteren Ideen gibt , werde ich wohl oder übel in meiner Anleitug eine Seite für Problembehandlung einbauen müssen.
Und dort dann die Vorgehensweise mit der Minimierung der Hardwarebeschleunigung beschreiben, besser eine schlechte Lösung als gar keine.

Noch einen witzigen Effekt habe ich festgestellt.
In meinem Platzrechner ist ja eine Grafikarte S3ViRGE eingebaut.
Scheint ne Uralt_Karte zu sein , hat nämlich nur 4MB
Bei 100% Handwarebeschleunigung ist ein flüssiger Bewegungsablauf (Rotieren, Schieben , Zoomen) in Grafikfenster nicht möglich, alles stottert und ruckelt.
Selbst der Mauszeiger ist am flickern.
Bei 20% ist alles wieder tuti, so wie ich es haben will, hier ist also weniger mehr.


@ damadmax

Wenn es dir nicht zu viel Mühe macht , dann probiert das Programm bitte mal auf mehreren Rechner aus .
Über die Fliegerei zu schnacken ist hier wohl nicht der richtige Ort, kontaktier mich doch einfach über Mail, die Adresse steht in der Info des Programmes.

Gruß

Frank

PS: Gibt es hier im Forum eine Anleitung , wie ich die Bilder uploaden kann, ich bekomme das einfach nicht hin.

also mal kurze Rückmeldung:

8800GTS => läuft einwandfrei
5900GT => läuft einwandfrei
SiS 651 => läuft nicht, kann keinen Context erstellen, "Out of Videomemory"

daß die SiS nicht läuft sehen ich nicht als problem. das liegt definitiv an der Karte...

Nochwas anderes:
Unter bestimmten, zur Zeit nicht weiter definierbaren, Umständen verlieren alle Eingabefelder ihre Werte. Also nicht 0 sondern wirklich leer.
Und zwar scheint das während der Berechnung aufzutreten. Sie startet und bricht dann ab mit der Meldung "ungültiger Integerwert" oder sowas.
Ich versuche das mal zu reproduzieren!

_________________
Es werde Licht.
glEnable(GL_LIGHTING);
Und es ward Licht.

Zitat aus einem Java Buch: "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"

on error goto next

Vllt kannst du Mesa mit ausliefern, und das als fallback bei Grafikproblemen nutzen. Ich habe allerdings noch keine Erfahrung damit, und weiss auch nicht, ob die Lizenz das erlaubt.
http://www.mesa3d.org/

_________________