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

Aktuelle Zeit: Fr Apr 19, 2024 03:48

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



Ein neues Thema erstellen Auf das Thema antworten  [ 12 Beiträge ] 
Autor Nachricht
 Betreff des Beitrags: VBOs ohne glew.h
BeitragVerfasst: Mi Nov 26, 2014 17:49 
Offline
DGL Member

Registriert: Do Nov 20, 2014 03:18
Beiträge: 36
Wohnort: Stuttgart
Programmiersprache: C++ (Java, Ada,...)
Hallo, ich bin es wieder.

Habe mich jetzt seit Wochen mit dem Thema beschäftigt wie VBOs funktionieren und ein Grundgerüst für mein Programm fertig gestellt.
(zur Erinnerung: Wir sollen das Uni-Gebäude nachmodellieren, so dass man in 3D durchlaufen kann, mit Wegfindungsroutingen, Beleuchtung. Quads sollen möglichst klein sein, so ca 10x10cm wurde vom Professor vorgeschlagen, damit die Beleuchtungseffekte und Texturen gut rüber kommen. Ich habe es anfangs aber schon auf 20x20cm heraufhandeln können.

Modeliert habe ich noch relatv wenig, da ich erst wissen musste in welchem Format meine Objekte vorliegen müssen um VBOs nutzen zu können. Nun steht das Projekt halb fertiggestellt da.
Heute habe ich aber erfahren, dass wir bis auf die vorinstallierten Bibliotheken keine weiteren Bibliotheken verwenden dürfen.
Wir benutzen:
PC: hexcore 3GHz
RAM: 32GB
GPU: NVIDIA 4GB (2 dedicated)

Code::Blocks
mit
freeglut Version 20700

Ist es möglich VBOs zu verwenden, ohne zusätzliche Bibliotheken einzubinden? Ich meinte bereits bei Projektstart, dass das so mit for-Schleifen, push/popMatrix, glBegin/glEnd nicht möglich wäre, alleine schon wegen der massiven Anzahl Polygone und framerate(selbst mit culling usw), aber irgendwie sehe ich selbst mit DisplayLists keinen grünen Streif am Horizont. C++ musste ich mir selbst rudimentär beibringen und mache mir meine eigenen LinkedLists usw.
Hat jemand eine Idee wie das am besten zu bewerkstelligen ist? 40 Tage sind bereits verstrichen, die ich zum größen Teil mit Recherche und C++ Syntaxtests verbracht habe. 20 Tage verbleiben um das Projekt fertig zu stellen.
Für Hilfe wäre ich sehr dankbar.

Schönen Gruß, Skeltek


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: VBOs ohne glew.h
BeitragVerfasst: Mi Nov 26, 2014 21:05 
Offline
DGL Member
Benutzeravatar

Registriert: Di Apr 29, 2008 18:56
Beiträge: 1213
Programmiersprache: Delphi/FPC
Hey,

ihr sollt in 60 Tagen ne neue Sprache (C++) lernen, ne neue API (OpenGL) lernen, dann das ganze Uni-Gebäude (bei uns wären das mehere 100 Räume) mit einer Genauigkeit von 20cm modellieren und das Ganze dann auch noch entsprechend verwalten und rendern, sodass man am Ende in Echtzeit da durchgehen kann? Das ist mehr oder weniger ne komplett eigene Engine :shock:
An welcher Uni bist du? Wie groß ist euer Team?
Und nebenbei gesagt: Wenn euer Prof will, das ihr eine ebene Fläche in mehere kleine Quads unterteilt, nur das der Lichteffekt "schön" aussieht, dann hat er keine Ahnung von aktueller OpenGL Entwicklung. Per-Vertex-Light ist Stand OpenGL 1.irgendwas. Seit OpenGL 2.0 (also seit 2004) gibt es Shader und somit Per-Pixel-Light. Vlt solltet ihr eurem Prof da mal ein kleines Update verpassen. Damit sinkt meiner Meinung nach auch der Arbeits-Aufwand, da es einfacher ist einen fertigen Per-Pixel-Light-Shader zum laufen zu bringen anstatt ne ganze Uni mit 20cm Quads zu rendern.

BTT: Irgendwo gab es mal ne Untersuchen wie viel schneller/langsamer DisplayListen im Vergleich zu VBOs sind. Der Unterschied war minimal. Wenn du dich also nich extra in VBOs einarbeiten willst würd ich sagen nimm DisplayListen. VBOs sind ein Bestandteil von OpenGL und sind somit ohne Fremd-Bibliotheken nutzbar. Du musst dir halt nur angucken wie du die nutzen kannst. Dazu gibts im Wiki ein Tutorial. Ansonsten kannst du dir mal den LazOpenGLCore angucken. Da gibt es eine Wrapper-Klasse für VBOs (uglcArrayBuffer). Das ist zwar in FreePascal geschrieben, aber das sollte relativ schnell nach C++ portiert sein, so viel Code ist das nicht. ;)

MfG Bergmann.

_________________
Aktuelle Projekte: BumpMapGenerator, Massive Universe Online
Auf meiner Homepage gibt auch noch paar Projekte und Infos von mir.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: VBOs ohne glew.h
BeitragVerfasst: Do Nov 27, 2014 08:45 
Offline
DGL Member
Benutzeravatar

Registriert: Mo Sep 23, 2002 19:27
Beiträge: 5812
Programmiersprache: C++
Wegen der Performance solch komplexer Szenarien sollte man sich mit Raumunterteilungstechniken wie z.B. Octrees auseinandersetzen, ansonsten wird man ein so umfangreiches Gebäude nicht performant und in Echtzeit rendern können.

Octrees sind ein sehr simples Konzept, und für jede Node kann man (wenns ohne VBOs gehen soll) auch einfach eine Displayliste verwenden. Octrees sind leicht zu implementieren und ein guter Kompromiss zwischen CPU und GPU.

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


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: VBOs ohne glew.h
BeitragVerfasst: Do Nov 27, 2014 09:16 
Offline
DGL Member
Benutzeravatar

Registriert: Mo Nov 08, 2010 18:41
Beiträge: 769
Programmiersprache: Gestern
Tjaja, wenn der Unterricht einen nicht auf die Sinnlosigkeit des Lebens vorbereiten wuerde.... Nun gut. Ich denke deine Hauptprioritaet sollte nicht auf VBOs und co. liegen. Das waere zwar wahrscheinlich sauberer usw., aber scheiss drauf. In der wirklichen Welt zaehlt auch nur der Termin und nicht wie schoen der Code ist. Ich denke du solltest dir jetzt also erst einmal hauptsaechlich um das Model-Format Gedanken machen.

Da ich nicht weis worauf euer Professor hinaus will, sollte es daher ruhig diese grosse Anzahl an Polygonen darstellen. Da du aber wahrscheinlich nicht so viele Polygone auf einmal darstellen kannst solltest du dir mal das Prinzip einer Portal-Engine anschauen. Hier kannst du ganz leicht die Sachen in einer Textur zwischen speichern und sparst so viel Arbeit. Wenn du keinen Compiler fuer ein entsprechendes Format hast kannst du auch einfach alles in so etwas wie einen Oct-,Kd- oder R-Tree packen. Diese haben Quader als Knoten und eigenen sich daher besser als zum Beispiel ein BSP-Baum fuer Texturen.

Noch einfacher gehts natuerlich wenn du dir eines der Level-Formate von Id-Software schnappst. Die sind alle wunderbar dokumentiert und frei verfuegbar. Aber die werden wahrscheinlich nicht in der Lage sein so viele Quads darzustellen.

_________________
Meine Homepage


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: VBOs ohne glew.h
BeitragVerfasst: Do Nov 27, 2014 20:53 
Offline
DGL Member
Benutzeravatar

Registriert: Di Dez 27, 2005 12:44
Beiträge: 393
Wohnort: Berlin
Programmiersprache: Java, C++, Groovy
Soviel ich weiß, vereinfacht Glew nur das Laden von Extensions. VBOs sind aber bereits seit OpenGL 1.5 im Core, du müsstest also eigentlich auch ohne glew.h auskommen...

Falls deine Grafikkarte Geometry Shader unterstützt, könntest du die Wände auch mit einem Tesselierungs-Shader unterteilen.

_________________
Wenn Gauß heute lebte, wäre er ein Hacker.
Peter Sarnak, Professor an der Princeton University


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: VBOs ohne glew.h
BeitragVerfasst: Do Nov 27, 2014 22:55 
Offline
DGL Member

Registriert: Do Dez 29, 2011 19:40
Beiträge: 421
Wohnort: Deutschland, Bayern
Programmiersprache: C++, C, D, C# VB.Net
GLEW "vereinfacht" das Laden von OpenGL ganz allgemein, egal ob Core oder nicht.

Ich würde auf jeden Fall alles daran legen, dass es mit einem Schwung gerendert werden kann. Wenn auf aufwendige Effekte verzichtest sind auf einer modernen GPU 10⁷ Polygone schon locker drin, zumindest bei mir mit VBOs und meine Grafikkarte ist zwar gut und vor allen Dingen neu, aber definitiv auch nicht High End.

Die Wände mit so komplizierten Techniken zu unterteilen wäre sehr leistungsfressend und sinnlos. Einfach per Pixel Lighting. Das "unterteilt" automatisch in Pixel. Wenn Shader zur Verfügung stehen, ist das eigentlich genauso einfach wie Vertex Lighting, bietet aber eigentlich nur Vorteile.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: VBOs ohne glew.h
BeitragVerfasst: Fr Nov 28, 2014 01:31 
Offline
DGL Member

Registriert: Do Nov 20, 2014 03:18
Beiträge: 36
Wohnort: Stuttgart
Programmiersprache: C++ (Java, Ada,...)
Bergmann89 hat geschrieben:
VBOs sind ein Bestandteil von OpenGL und sind somit ohne Fremd-Bibliotheken nutzbar. Du musst dir halt nur angucken wie du die nutzen kannst. Dazu gibts im Wiki ein Tutorial.

Die Befehle habe ich hier auf dem Rechner nicht zur Verfügung, es selbst ohne Glew oder ähnliche Libs zu machen soll laut einem englischen Forum purer Masochismus sein - auch für Profis. Wir sollen ja nur das benutzen, was auf dem Hochschulrechner vorinstalliert ist; wobei das mehr sein könnte als mir bewusst ist. Schließlich wurde uns fast nichts beigebracht ausser grundlegendes glutI/O, glBegin/End, etwas über Licht, translationen/rotates und noch Kleinigkeiten. C++ hatten wir gar nicht.
Die Tutorials habe ich schon gesehen, aber ich weiss nicht was ich da einbinden müsste, soweit ich das mit meinem beschränkten Wissen sagen kann finde ich nur glut, glu, gl ung lgext im Ordner, keine Ahnung wie man das aktiviert.
Ich bin exterm lernfähig, aber das datamining benötigt Zeit.
Alleine eure Vorschläge im verbleibenden Zeitrahmen zu prüfen könnte zu zeitaufwendig sein, wobei gute dabei sind.

Sascha Willems hat geschrieben:
Wegen der Performance solch komplexer Szenarien sollte man sich mit Raumunterteilungstechniken wie z.B. Octrees auseinandersetzen, ansonsten wird man ein so umfangreiches Gebäude nicht performant und in Echtzeit rendern können.

Octrees sind ein sehr simples Konzept, und für jede Node kann man (wenns ohne VBOs gehen soll) auch einfach eine Displayliste verwenden. Octrees sind leicht zu implementieren und ein guter Kompromiss zwischen CPU und GPU.

Ich dachte Octrees seien eher für Texturierung von 3d Modellen gut und sind bei größeren Szenarien bzw Spielengeschwindigkeitstechnisch nicht sehr leistungsstark

yunharla hat geschrieben:
Nun gut. Ich denke deine Hauptprioritaet sollte nicht auf VBOs und co. liegen. Das waere zwar wahrscheinlich sauberer usw., aber scheiss drauf. In der wirklichen Welt zaehlt auch nur der Termin und nicht wie schoen der Code ist. Ich denke du solltest dir jetzt also erst einmal hauptsaechlich um das Model-Format Gedanken machen.

Darauf lag meine Priorität schon relativ früh, allerdings wurde arg geargwohnt, wieso denn noch kaum was auf unserem Bildschirm zu sehen ist an Modellierung.(Habe Anfangs primär Leistungstests gemacht und selbst LoD Routinen entworfen um Polygonzahl mit Entfernung dynamisch zu reduzieren). Laut meiner damaligen Einschätzung kommt das Modellieren erst relativ am Ende der Entwicklung, nachdem man sich wenigstens etwas die Syntax der Programmiersprache anneignen konnte und überhaupt erstmal einen Plan hat...)
yunharla hat geschrieben:
Da ich nicht weis worauf euer Professor hinaus will...

Die anderen Studenten wissen es auch nicht so genau.
yunharla hat geschrieben:
Wenn du keinen Compiler fuer ein entsprechendes Format hast kannst du auch einfach alles in so etwas wie einen Oct-,Kd- oder R-Tree packen. Diese haben Quader als Knoten und eigenen sich daher besser als zum Beispiel ein BSP-Baum fuer Texturen.

Scheint mir ein zu großer Batzen an Recherche zu sein. Datamining im Netz um gute Quellen zu finden und eigenständig anzulesen ist ein echter Zeitfresser habe ich im Laufe der Wochen gemerkt.

dj3hut1 hat geschrieben:
Soviel ich weiß, vereinfacht Glew nur das Laden von Extensions. VBOs sind aber bereits seit OpenGL 1.5 im Core, du müsstest also eigentlich auch ohne glew.h auskommen...

Falls deine Grafikkarte Geometry Shader unterstützt, könntest du die Wände auch mit einem Tesselierungs-Shader unterteilen.

Tesselierungsshader klingt gut, würde mich auch reizen sowas zu programmieren. Allerdings habe ich ja nur noch 20 Tage und es sieht nach viel Recherchearbeit und Lesen aus.

OpenglerF hat geschrieben:
GLEW "vereinfacht" das Laden von OpenGL ganz allgemein, egal ob Core oder nicht.

Ich würde auf jeden Fall alles daran legen, dass es mit einem Schwung gerendert werden kann. Wenn auf aufwendige Effekte verzichtest sind auf einer modernen GPU 10⁷ Polygone schon locker drin, zumindest bei mir mit VBOs und meine Grafikkarte ist zwar gut und vor allen Dingen neu, aber definitiv auch nicht High End.

Die Wände mit so komplizierten Techniken zu unterteilen wäre sehr leistungsfressend und sinnlos. Einfach per Pixel Lighting. Das "unterteilt" automatisch in Pixel. Wenn Shader zur Verfügung stehen, ist das eigentlich genauso einfach wie Vertex Lighting, bietet aber eigentlich nur Vorteile.

Die Hardware dort ist relativ gut. Per-Pixel-Lightning bisher nur gehört und soweit ich das beurtailen in der Lage bin bei freeglut 20700 nicht machbar? Vielleicht irre ich mich ja auch.
Wir haben uns jetzt jedenfalls entschlossen innerhalb von 2 Tagen einfach komplett alles zu modelieren und in eine Hand voll Display Listen zu packen. Für die Kollisionsabfrage benutze ich vermutlich einfach eine separat definierte Liste mit sehr grob aufgelösten "Boundary-Polygonen"(so nenne ich die Idee jedenfalls), auf deren Durchschreiten ich die Spielerposition prüfe.
Problem ist auch, dass in der Mitte des Gebäudes eine große Halle ist, von der aus man praktisch jedes Stockwerk und jede Seite des Gebäudes sehen kann; daher kannich den größten teil des Innenraumes nicht einfach ausblenden. Mir ist im Grunde genommen alles recht, was die Performance auf ein Niveau oberhalb von 5-10 FPS bringen kann.

Vielen Dank für alle Antworten, ich hoffe ich habe keinen von euch vergessen!

Schöne Grüße, Skeltek

ps: Denke wir werden erstmal das meiste mit glBegin/End machen(mein Teamkollege hätte mit drawElements noch größere Probleme).
Danach ersetze ich glVertex3F(...) durch "addVertexToLinkedList(eigene Methode)", und gebe als return ein Format zurück, dass ich für drawElements verwenden kann.
(Wie baue ich da die Texturen ein? Beherrschen VertexArrays Texturbespannung?)
Lösche dann alle glBegin/End.
Den Rückgabewert setze ich in eine DisplayList(können Displaylisten MipMapping oder Vektorsharing? oder muss ich je nach Entfernung unterschiedliche Displaylisten machen für ein LoD?).
Klingt das nach einem Plan?

ps: Falls jemand von euch der es "drauf" hat zu fällig Skype benutzt können wir auch gerne mal kurz quatschen. Denke das geht auch viel schneller als Forenbeiträge schreiben und stresst weniger :-) Die Resultate kann man ja später immer noch hier rein posten damit andere noch etwas von den gängigen Fehlern eines blutiger openGL Anfängers haben.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: VBOs ohne glew.h
BeitragVerfasst: Fr Nov 28, 2014 02:39 
Offline
DGL Member

Registriert: Do Nov 20, 2014 03:18
Beiträge: 36
Wohnort: Stuttgart
Programmiersprache: C++ (Java, Ada,...)
Bergmann89 hat geschrieben:
VBOs sind ein Bestandteil von OpenGL und sind somit ohne Fremd-Bibliotheken nutzbar. Du musst dir halt nur angucken wie du die nutzen kannst. Dazu gibts im Wiki ein Tutorial.

Habe GL_ARRAY_OBJECT_BUFFER hier nicht gefunden, aber ein GL_ARRAY_OBJECT_BUFFER_ATI.
Gibt es da irgendeinen relevanten Unterschied? Sind nun doch VBOs bei mir möglich?
Wobei der Parser mir kein glBindBuffer zur Verfügung stellt... würde ja gerne noch recherchieren, aber war heute wieder ein langer Tag. Gute Nacht :-)


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: VBOs ohne glew.h
BeitragVerfasst: Fr Nov 28, 2014 09:23 
Offline
DGL Member
Benutzeravatar

Registriert: Mo Nov 08, 2010 18:41
Beiträge: 769
Programmiersprache: Gestern
Ok, dann wollen wir mal. Extensions laden ist sehr einfach, besorg dir am besten erst einmal den "glext.h"-Header. Dort hast du schon einmal alle Typen und Konstanten definiert.
Das eigentliche Laden sieht unter Windows dann in etwa wie folgt aus (Linux und co. sollten ähnlich sein) :
Code:
  1.  
  2. PFNWGLSWAPINTERVALEXTPROC wglSwapIntervalEXT = NULL;
  3.  
  4. ....
  5. hRC = wglCreateContext(hDC); //zuerst muss ein ganz normaler OpenGL Context aktiv sein
  6. ...
  7. //wenn der Context erstellt wurde kannst du dir die Funktionen aus der Bibliothek holen
  8. wglSwapIntervalEXT = (PFNWGLSWAPINTERVALEXTPROC)    wglGetProcAddress("wglSwapIntervalEXT"); //Zeiger auf die Funktion besorger
  9.  
  10.  


Zurück zum Thema Bäume:
Wenn du keinen Bock auf Recherche hast, nimm einen R-Baum. Da braucht man nicht viel wissen :) Schau dir einfach mal die Bilder auf der rechten Seite an:
Code:
  1.  
  2. Du gehst von der Wurzel aus durch den Baum bis du ein Leaf findest (ohne Kinder-Knoten).
  3. Für jeden Knoten:
  4. Suche das Knoten->Quader das am wenigsten vergrößert werden muss.
  5.  
  6. Polygon in Knoten einfügen (Knoten->Vergrößern)
  7.  
  8. Wenn Knoten->AnzahlDerInhalte > DeineGrenze:
  9. Teile den Knoten
  10.  


Oct und KD-Tree sind ähnlich einfach. Zu beachten ist das du nur das Insert und Search brauchst.

das Grundprinzip von Portalen findest wunderbar hier erklärt.

Alternativ kannst du auch die Portale manuell bauen, damit wärst du aber abhängig von irgendwelchen kram im Editor.

_________________
Meine Homepage


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: VBOs ohne glew.h
BeitragVerfasst: Fr Nov 28, 2014 13:05 
Offline
DGL Member

Registriert: Do Dez 29, 2011 19:40
Beiträge: 421
Wohnort: Deutschland, Bayern
Programmiersprache: C++, C, D, C# VB.Net
OpenGL Features haben nichts mit dem verwendeten OpenGL Context Loader zu tun. Also das geht immer. Allerdings wirst du für alles jehenseits der längst veralteten OpenGL Steinzeit, die nicht mehr im Geringsten die heutige Hardware widerspiegelt, notwendig haben eben einen OpenGL Loader zu verwenden, der dir die OpenGL Methoden und Definitionen bereit stellt, die über 1.1 hinausgehen. Das kann man natürlich auch selber machen, ist aber im wesentlichen Zeitverschwendung. Besser nimmt man zum Beispiel GLEW, glLoadGen oder GL3W. GLEW ist extrem einfach zu verwenden.

Unabhängig davon würde ich mir auf Dauer eine modernere Plattform aussuchen. GLUT ist im Wesentlichen uralt. FreeGLUT wird zwar scheinbar noch weiterentwickelt, geht aber in die selbe Zeit zurück und bietet aus heutiger Sicht sehr wenig. Muss also nicht wirklich sein. Ich verwende zum Beispiel immer GLFW, dass ist sehr klein und ist sehr einfach zu verwenden. Wenn du unter Zeitdruck stehst, wird es FreeGLUT aber diesmal auf jeden Fall auch noch tun.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: VBOs ohne glew.h
BeitragVerfasst: Sa Nov 29, 2014 07:10 
Offline
DGL Member

Registriert: Do Nov 20, 2014 03:18
Beiträge: 36
Wohnort: Stuttgart
Programmiersprache: C++ (Java, Ada,...)
Hi,
ohne einen neuen Thread nur für mich aufzumachen, würde ich heute gerne meine Objekte als VectorArrays umschreiben.
Was ich mich frage ist, ob man VektorArrays mit Texturen kombinieren kann ... und falls ja, ob das dann mit MipMaps noch automatisiert funktioniert oder ich manuel LoD steuern muss.
Habe einen TGA Loader eingebaut, mit Texturen hantiert, VektorArrays, drawElements usw alles eingesetzt. Finde nur im Netz keine Quellen, die VektorArrays in Kombination mit Texturen besprechen. Muss man da jedem Texturpunkt einen eigenen Array zuweisen?.

Habe mich übrigens für eine eigene Baumstruktur entschieden welche alle Räume unterteilt, damit ich über diese sowohl für meinen DisplayManager als auch für meinen KollisionManager gleichzeitig Vorselektieren kann. Bewegliche Objekte wird es kaum geben, daher kann ich relativ viel in die Zeichenroutine des Raumes einbinden.
Bodentexturierung erfolgt teils zufällig, erstellt einen Array[][] und daraus dann eine DisplayList. Da würde ich gerne während der Initialisierung als Zwischenschritt alles in einen Vektorarray packen bevor der in die DisplayListe kommt.

Zur Kollisinsabfrage bekommen alle Wände, Böden und Objekte ein grobes Netz aus Kontrollolygonen, die ich in eine extra Liste als Raumattribut packe und dann auf "Durchschreiten" prüfe. Beim Feststellen einer Spielerposition "hinter" einem dieser Polygone, wird der vertikale Anteil des Positions-Mißstandes auf die Oberfläche zurückgesetzt und der Geschwindigkeitsvektor korrigiert.
Konkave Flächen und Ecken bekommen ein etwas verlängertes Polygon, um ein "Durch Ecken gehen" zu verhindern.
Habe die Routinen bereits an einem einzelnen nicht gezeichneten Polygon bereits getestet und geprüft, ab wann man "hinunterfällt" und es funktioniert so schonmal.

Klingt nach nem Plan?

Viele Grüße, Skel

achja... wieso drücke ich strg-shit-s zum posten? >.>


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: VBOs ohne glew.h
BeitragVerfasst: Sa Nov 29, 2014 16:29 
Offline
DGL Member
Benutzeravatar

Registriert: Fr Mai 31, 2002 19:41
Beiträge: 1278
Wohnort: Bäretswil (Schweiz)
Programmiersprache: Pascal
Zitat:
ohne einen neuen Thread nur für mich aufzumachen, würde ich heute gerne meine Objekte als VectorArrays umschreiben.
Was ich mich frage ist, ob man VektorArrays mit Texturen kombinieren kann ... und falls ja, ob das dann mit MipMaps noch automatisiert funktioniert oder ich manuel LoD steuern muss.
Habe einen TGA Loader eingebaut, mit Texturen hantiert, VektorArrays, drawElements usw alles eingesetzt. Finde nur im Netz keine Quellen, die VektorArrays in Kombination mit Texturen besprechen. Muss man da jedem Texturpunkt einen eigenen Array zuweisen?.


Wen du da hier meins, ja.

Code:
  1. type
  2.   TQuad = array[0..1] of Tmat3x3;
  3.  
  4. const
  5.   Quad: TQuad =
  6.     (((-0.8, -0.8, 0.0), (0.8, 0.8, 0.0), (-0.8, 0.8, 0.0)),
  7.     ((-0.8, -0.8, 0.0), (0.8, -0.8, 0.0), (0.8, 0.8, 0.0)));
  8.  
  9.   QuadTextureVertex0: array[0..5] of TVector2f =
  10.     ((0.0, 0.0), (3.0, 3.0), (0.0, 3.0),
  11.     (0.0, 0.0), (3.0, 0.0), (3.0, 3.0));  
  12.  
  13.  
  14. begin
  15.   .....
  16.   glGenVertexArrays(1, uiVAO);
  17.   glGenBuffers(3, uiVBO);
  18.  
  19.   glBindVertexArray(uiVAO[0]);
  20.   // Array für das Quad selbst
  21.   glBindBuffer(GL_ARRAY_BUFFER, uiVBO[0]);
  22.   glBufferData(GL_ARRAY_BUFFER, sizeof(Quad), @Quad, GL_STATIC_DRAW);
  23.   glEnableVertexAttribArray(pos_id);
  24.   glVertexAttribPointer(pos_id, 3, GL_FLOAT, False, 0, nil);
  25.   // Array für die Texturkoordinaten
  26.   glBindBuffer(GL_ARRAY_BUFFER, uiVBO[1]);
  27.   glBufferData(GL_ARRAY_BUFFER, sizeof(QuadTextureVertex0), @QuadTextureVertex0, GL_STATIC_DRAW);
  28.   glEnableVertexAttribArray(texture_id0);
  29.   glVertexAttribPointer(texture_id0, 2, GL_FLOAT, False, 0, nil);
  30.   .... 

_________________
OpenGL


Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 12 Beiträge ] 
Foren-Übersicht » Programmierung » OpenGL


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 40 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.240s | 17 Queries | GZIP : On ]