Hi Leute,

zur Zeit verwende ich für dynamische Objekte die VBO´s zur Darstellung. Auf meinem Arbeitssystem (Intel HD 4000) funktioniert das einwandfrei,
jedoch auf einem anderen (Radeon 3650) produziert die Verwendung der VBO´s gewaltige Fehldarstellungen!

Frage 1: Gibt es eine Lösung die die Verwendung von VBO´s ermöglicht?
Frage 2: Gibt es eine Liste der Grafikkarten die VBO´s unterstützen oder gar eine Möglichkeit eine Funktion zu implementieren
die mir angibt ob die Grafikkarte des aktuell verwendeten Systems diese unterstützt?
Frage 3: Oder mache ich vllt. gar einen Fehler?! (bin ja noch neu in der opengl - Welt)

_________________
_______________________________________
Lets move over mountains and through valleys:
GL.Map2(,,,,,,,,,)
GL.MapGrid2(,,,,,,,,,)
GL.EvalMesh2(,,,,,,,,,)

Frage 3 ist schwer zu beantworten.

Für Frage 2 gibts Datenbanken. Diese Liste ist auf jeden fall ein guter start.

Für Frage 1: Probier mal aktuelle Treiber.

grüße

_________________
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

Vielen Dank. Ja, gut für Frage 3 hätte ich meinen Source - Code anhängen sollen ;D, aber
da es ja auf meinem System funktioniert und ich mir die Nutzung von VBO´s über ein Video-
tutorial beigebracht habe, gehe ich mal von diesem Punkt nicht aus.

Aber um nochmal auf Frage 2 zurück zu kommen: Hat jemand schonmal die Grafikkartenin-
formationen ausgelesen und damit gearbeitet? Das wäre eine Lösung mit der ich mich an-
freunden könnte um schon beim Start meines Programmes die Darstellung zu wählen (mit VBO´s
oder ohne).

_________________
_______________________________________
Lets move over mountains and through valleys:
GL.Map2(,,,,,,,,,)
GL.MapGrid2(,,,,,,,,,)
GL.EvalMesh2(,,,,,,,,,)

Hier würde ich stark zweifeln, denn aus eigener Erfahrung weiß ich das sich zum Beispiel NVIDIA Karten und ATI Karten unterschiedlich verhalten, bei mir war es beim Umstieg auf VBO's zu Anfang auch so, dass es bei mir zuhaus einwandfrei lief aber auf NVIDIA und INTEL Karten krachte es herbe.

Dazu gibts auch einen thread von mir http://www.delphigl.com/forum/viewtopic.php?f=10&t=10803

letztendlich war der "Fehler meinerseits" ein falsch gesetztes Finalize.
das war ATI völlig egal aber NVIDIA wurde zu nviDIVA.


schon vor längerem hatte ich einen ähnlichen Fall bei der Verwendung von Texturen, auch hier gab es Unterschiede, die damals zwar nicht zum Absturz führten aber zu einem ungewünschten Abdunkeln der gesamten Szene auf NVIDIA.

Okay, danke. Ich werd mir mal deinen Thread durchlesen.

_________________
_______________________________________
Lets move over mountains and through valleys:
GL.Map2(,,,,,,,,,)
GL.MapGrid2(,,,,,,,,,)
GL.EvalMesh2(,,,,,,,,,)

Also sehr viel weiter gebracht hat mich der Thread nicht. Ich poste einfach mal meinen Source-Code.
Also aktuell ist das Zeichnen über VBO´s nicht gerade schneller als im Intermediate Mode!
Zustätzlich generiert die Nutzung von VBO´s auf einem weiteren Rechner Fehldarstellungen, auf meinem
Arbeitssystem (Intel i5 Core, Intel HD 4000 Graka) läuft es allerdings einwandfrei. Nur eben nicht schneller
bzw. flüssiger, wenn ich die Framerate beobachte.

Die folgende Funktion rufe ich beim laden der Windows-Form auf:


Die folgende Funktion wird im Paint-Event meiner glControl aufgerufen:


Die Vertex-Liste, welche bei Generierung des VBO´s in ein Array verpackt wird über .ToArray(), wird in jedem Programmzyklus
größer, was auch gewollt ist. Sprich es werden neue Verticies hinzugefügt.

_________________
_______________________________________
Lets move over mountains and through valleys:
GL.Map2(,,,,,,,,,)
GL.MapGrid2(,,,,,,,,,)
GL.EvalMesh2(,,,,,,,,,)

Für mich sieht das so aus als ob bei jedem Frame auch ein neues VBO erzeugt wird.

_________________
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

Das erzeugen wird ja in meiner ersten aufgeführten Funktion gemacht. Und diese wird beim Start des Programmes, also im Load-Event meiner
Windows-Form aufgerufen. In jedem Programmzyklus die letztere aufgeführte Funktion. So sollte dann eigentlich nicht permanent ein
neues VBO erzeugt werden. Oder verstehe ich da was falsch?

Und wieso ist die Framerate im Intermediate Mode genau die selbe wie bei Nutzung der VBO´s? Sollte doch eigentlich ein gewaltiger Unterschied
sein. Im Intermediate Mode bricht bei mir die Framerate auf 45 herunter, was aber auch bei den VBO`s passiert. Ohne die Darstellung dieses
Vertex - Arrays bzw. der Vertex - Liste ist sie stabil bei 200.

(Zur Info: Ich verwende die OpenTK Wrapperklassen).

_________________
_______________________________________
Lets move over mountains and through valleys:
GL.Map2(,,,,,,,,,)
GL.MapGrid2(,,,,,,,,,)
GL.EvalMesh2(,,,,,,,,,)

schuss ins blaue:



laut wiki will glvertexpointer als letzten wert einen pointer, du übergibst eine 0, ich weiß das ich damit auch mal gegen die Wand gelaufen bin. Weil manche Systeme das akzeptieren und andere nicht.

Nein daran liegt es nicht, die Funktion aus der OpenTK-Library sieht folgender maßen aus:

GL.VertexPointer(int size, VertexPointerType type, int stride, int offset);

Kann es sein, dass es vllt. an der Größe des Arrays liegt? Denn im Laufe des Programmes
erreicht es eine Größe von etwa 10000 Verticies.

_________________
_______________________________________
Lets move over mountains and through valleys:
GL.Map2(,,,,,,,,,)
GL.MapGrid2(,,,,,,,,,)
GL.EvalMesh2(,,,,,,,,,)

VBO's sind älter als die Steinkohle und in den Bereichen geht eigentlich nix schief, weil sie schlicht weg von jedem Spiel genutzt werden und es schon in der Entwicklung auf fallen würde, wenn da ein Bug rein kommt.
Der meiste Fehler ist die falsche verwendung und Folgefehler.
Hobbyisten tendieren dazu keine Fehler zu tracken, erst wenn was sichtlich nicht mehr geht.
Oft sind Treiber auch so nett und tollerieren falsche benutzung, NVidia ist da berühmt drin, während andere wieder sehr nahe an den Specs arbeiten.
So kommt es dann vor, dass man mal zwischen verschiedenen Modellen, einer Firma auf einmal Probleme bekommt, weil das neue Modell auch ein neuen Treiberbranch benutzt und dort vieleicht nicht so nett mit Fehlern umgegangen wird.
Daher ist zu empfehlen, erstmal den Treiber auf entstehende Fehler zu fragen, dann die Befehle mal mit der Manpage ab zu gleichen und dann die Parameter auf falsche Inhalte zu prüfen.
VBO sind nicht so einfacher wie der rest von OpenGL, daher kann man hier schnell mal ein Fehler machen, wenn man sich nicht an die Manpage hält und der Treiber einem nicht den Fehler um die Ohren haut.
Oft sind es kleinigkeiten, wie falsche targets disabled/enabled oder Objekte gebunden.
Ein klassiker ist mehr zu rendern, als man an Daten zur verfügung stellt.

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

Projekte: https://github.com/tak2004

Okay, aber wie frage ich beim Treiber an auf entsprechende Fehler. (hin noch frisch in der opengl-welt)

_________________
_______________________________________
Lets move over mountains and through valleys:
GL.Map2(,,,,,,,,,)
GL.MapGrid2(,,,,,,,,,)
GL.EvalMesh2(,,,,,,,,,)

Als ich vorhin den Beitrag geschrieben habe stand doch definitiv noch ein this.GenVBOWoundTube() im ersten Teil der if-Abfrage in der DrawWoundTube()-Funktion.
Bin ich jetzt verrückt?

_________________
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

ich denke das kann ausgeschlossen werden, ich rendere bis zu
vertices, die framerate geht dabei runter auf 5-20 je nach rechner.

OpenGL Funktion zum Fehler abfragen.
http://www.opengl.org/wiki/GLAPI/glGetError
OpenGL Debugger, der einfach glGetError hooked und ein bischen komfortabler ist.
http://www.gremedy.com/download.php

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

Projekte: https://github.com/tak2004