Ich denke mal, das die Frage hier ertsmal gut aufgehoben ist, ansonsten Entschuldigung.

Problem: Die Texturen werden nicht korrekt auf das Objekt gemappt.
Vorgeschichte:
ich hatte eine tolle 3D-Umgebung mit Bäumen, Skysphere, Boden schon fertig, zu Testzwecken.
Jedoch lag die Framerate bei ca. 10000 Bäumen a ca. 10 triangles und einigen Boden-Quads nur bei 20 frames.
Texturen wurden alle geladen und auch korrekt dargestellt, auch mit Transparenz.
Deshalb traute ich mich an die VBOs. Weil ich die Daten nicht per Hand schreiben wollte bastelte ich auch mal einen OBJ-Loader.

Nun zum Problem:
Das lesen der Daten, sowie erstellen der Texturen sind sicher nicht mein Problem, denke ich, wie sonst so oft. Die Texturcheckliste hab ich auch angeguckt, das passt auch alles soweit. Power of Two, Texturen enabled...
Aber ich glaube ich hab ein Problem was die Verständnisweise von VBOs angeht. Bei nur VertexArrays ist mir klar, dass ich für jedes Vertex Normalen, TextureKoordinaten etc. habe, und beim rendern alles abgearbeitet wird. D.h ein Vertex kann 2 TexturKoordinaten haben, kommt dafür aber auch 2 mal vor, an der entsprechenden Stelle.
Das auch nur eine Textur gebunden werden kann ist auch soweit klar. Nun liegt es auf der Hand, weil das Obj-Format ja IndexListen benutzt, auch diese in Opengl zu nutzen.
Also dem VBO die Indexliste zu übergeben etc. Das klappt auch alles wunderbar, aber sind die gebundenen Buffer auch PRO Vertex oder sind diese auch PRO Index möglich? Irgendwie fehlt mir da ein Puzzelstück für das Verständnis.
Die Normalen scheinen richtig genutzt zu werden, weil wenn ich eine Normale, z.b. in Blender, ändere wird das Face in Opengl auch nicht angezeigt, von der einen Seite, sondern von der Anderen (cullface halt, kann aber auch zufall sein).
Also ich hab z.b. einen Würfel mit 24 Punkte(/3 = 8 Vertexen/Vertices(?)), 72 Texturkoordinaten(/2 = 36), 108 Normalen(/3 = 36) und 36 Indexe.
Der Würfel wird korrekt gerendert, aber die Texturkoordinaten sind total falsch, und das liegt sicher nicht an der Bildspiegelung, weil sie doch sehr stark auf dem Objekt gebrochen werden. Das Objekt wird beim exportieren Trianguliert, aber egal ob ich erst Trianguliere, dann UV-Mapping mache und dann Exportiere, oder UV-Mapping mache und dann beim Exportieren Trianguliere es kommt ein ähnliches Ergebnis bei raus.

Deshalb stellen mir sich noch 2 Fragen zum verständnis.
1. Wenn man nur per Vertex in die Buffer speichern kann, müsste ich ja bei verschiedenen Textkoordinaten auch den Vertex doppelt haben, was ja gerade den Index-Vorteil total zunichte macht, oder?
2. Wenn ich die Texturen nicht alle in einer Textur habe, dann müsste ich ja jedes Objekt zerteilen in entsprechende VBOs anfügen und dann rendern. Wäre jetzt nicht das Problem, aber wenn man sehr viele kleine unterschiedliche Objekte benutzt, dann hätte man doch einen massigen Overhead an VBOs, was doch deutlich das Ganze verlangsamen würde? oder etwa nicht. Wenn man viele gleiche Objekte rendert wäre es ja nicht so tragisch, aber wenn man z.b. ein Spiel macht, wo es auch verschiedene Kisten z.B. geben soll, dann wär das doch echt schlecht gelößt?

Ich glaube ich habe viel zu viele Fragen und Informationen gegeben und dafür andere wichtige Infos vergessen.
Ich entschuldige mich außerdem für die mangelnde Rechtschreibung vor allem am Ende. Es war schon recht spät und die Müdigkeit nahm zu.
Falls noch jemand durchsteigt durch mein Wirrwarr, wäre ich sehr froh und bedanke mich schon im Vorfeld.
mfg revolte.
und eine gute Nacht =)

EDIT: Code und auch bsp. Bilder kommen später wenn ich wieder wach bin.
EDIT: Bilder hinzugefügt um das Problem zu Zeigen, vll liegts ja doch an was anderem.

Hier die Obj Datei vereinfacht

Und unten die entsprechenden Bilder und die Textur (eigentlich eine 512x512 Targa-Datei).
Vll bringt es ja was. Vielen Dank

_________________
System: Phenom XII X4 955 3,21Ghz , GTX 560 TI, 4GB-Ram, Windows 7 64x

1. Ja das geht glaube ich nicht anders
2. Du kannst auch teile eines VBOs rendern. Also brauchst du nicht mehrere VBOs. Allerdings sind ständige Texturwechsel und die erhöhte DrawCall Zahl der Performance nicht unbedingt förderlich.

_________________

1.) Wenn du 130 Normalen hast, dann hast du auch 130 colors,vertice,texcoords und über 130 indices.
Erklärung: Der Index zeigt auf das Element in allen gebundenen Listen und wenn diese nicht alle ihre Daten an den richtigen stellen haben, dann wird es murks.
Der erste Anschein trügt, das VBO ist immernoch im Vorteil, es treten für ein Vertice nur unterschiedliche Texturkoordinaten und Normalen auf, wenn das Face flat shaded ist.
In der Regel sind aber der größte Teil eines Models smooth shaded und damit teilen sich alle Nachbarn die gleichen vertice,normal,color und texcoords(vbo ist nun wieder im vorteil).
2.) Du kannst deine komplette Welt in nen VBO packen, wenn es dir gefällt aber ändern tut sich da nicht viel.
Wenn man VBO mit Indices verwendet, dann führt man eine Facelist.
Jede Fläche besitzt ein start,count und texturid/materialid/... .
Wenn man dann zeichnet, dann wird die Facelist genommen und in einer schleife folgendes getan.


Wenn man das Objekt mehrfach verwendet, dann sollte eine 2. Zeichenfunktion hinzu oder die orginal Zeichenfunktion noch überarbeitet werden.
Denn wenn man dann das Objekt 100 mal zeichnet, dann wird 100 mal die Textur gebunden und entfernt.
Hier lohnt es sich ein flag in die funktion zu implementieren, BatchDraw:BatchTyp(BatchStart,BatchDraw,BatchEnd) oder so ähnlich.
Wenn es wirklich ein BatchDraw ist(ein stappel von gleichen Aufrufen), dann wird je nach dem welcher der 3 Typen gesetzt ist Bind und Unbind Part weggelassen.
Nun musst nur noch deine zu Zeichnenden Models zu Batches zusammen fassen.
Am einfachsten ist es, ein record Batch zu erstellen, wo Model und anzahl drin steht.
Alle zu zeichnenden Models durchgehen und den Counter für den passenden Batch erhöhen.
Nun gehst die Batchaufträge durch, schnappst dir deine alte zeichenroutine und übergibst den Batch.
Faceliste wird in einer Loop durchgearbeitet.

Ist erstmal ziemlich undurchsichtiges Thema aber wenn man das mit der implementierung verinnerlicht hat, dann versteht man, wieso die variante so gut ist und wieso dies so funktioniert.
Ein paar Infos:
Das Model baut sich aus Faces auf, ein Face stellt hierbei eine Textur dar.
Wenn man also im Model 2 Texturen benutzt, dann hat man 2Faces.
Wenn wir also das Model(Baum) 100 mal zeichnen wollen, dann wären das 200 Textur bind und unbind.
Nun machen wir nen Batch(auch als softinstancing bekannt) draus.
Also haben wir nun ein Batch, wo das Model drin liegt und bei count 100 steht, sowie die position/scale/rotation jedes Models als liste.
Nun ruft man den drawcall auf und übergibt die Liste mit postition/scale/rotation und 100.

<pseudocode>
bindVBO
for obj=0 to objende do
{
pushmatrix
translate
rotate
scale
for f=0 to faceende do
{
if f=0 and obj=0 then bindTexture
drawface
if f=faceende and obj=objende then unbindTexture
}
popmatrix
}
unbindVBO
</pseudocode>
Anfallen tuen nun folgende Aufrufe:
1VBO wird gebunden//vorher 100
1VBO wird entfernt//vorher 100
2Texturen werden gebunden//vorher 200
2Texturen werden entfernt//vorher 200
100 translate//vorher 100
100 rotate//vorher 100
100 scale//vorher 100
200 glDrawRangeElements//vorher 200
100 push//vorher 100
100 pop//vorher 100
400 if//vorher 0(2if pro face=4if pro objekt=400)

Wir haben nun 99 VBO bind,99 VBO unbind, 198 Texturbind und 198 Texturunbind gespart und dafür 400 if hinzugeholt.
Erstma haben wir die Aufrufanzahl verringert aber viel besser ist, wir haben die 594 OGL calls gegen 400 if calls eingetauscht.
Die fast 600 Opengl Aufrufe werden mit der GPU gesynct und die 400 if nicht, die kann die CPU sofort und sehr kostengünstig und stupide abarbeiten.

Abstrakte Programmierinterfaces sind sehr flexibel aber man kann auch viel Performance dadurch verliegen, wenn man nicht überlegt.
Die Variante ist extrem schnell und darüber sollte, meines Wissens, nur noch das Hardware Instancing(benötigt eine aktuelle GPU) kommen.

Optimierung auf Modelbass:
Oft werden gerade bei Fauna ganze sets gemodelt also 3-4 Bäume in ein Model gepackt, damit würde in dem Beispiel von 100 Obj nur noch 25 Objekte verarbeitet werden müssen.

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

Projekte: https://github.com/tak2004

mhh das klingt ja schon gut, so was hatte ich auch vor zu machen, nur nicht auf dieser Ebene, wollte aber erstmal gucken, ob das auch einfach geht.
Zur Zeit mach ich alles noch recht statisch und per hand, später solls doch dynamischer sein, das Objekte laden und rendern, wenn man durch die Welt läuft.
Ich weiß auch nicht ob ich dein konzept 100%ig Verstanden habe, bzw. ob es genau das richtige für mich ist, wenn ichdas genau so mache.
Mein aktuelles Problem sind glaub ich auch noch mehr die Texturkoordinaten und dann erst die Zerteilung der Objekte und deren Sortierung.
Beispiel:
Also ich hab 4 Vertexe, damit kann ich ja 2 Dreiecke zeichnen die aneinander hängen. Wenn jedes der beiden andere Texturen haben soll, muss ich das nacheinander rendern. Also müsste ich quasi 2 TextcoordBuffer haben, die dann gebunden werden für die entsprechende Textur?
Mh irgendwie gibt es so viele Möglichkeiten und die bringen mich durcheinander.
mfg revolte
p.s. ich sitze am Laptop, dort gehen einige Tasten nicht, also Bitte nicht wundern ohne Leertaste isses ein bisschen schwer *g*

_________________
System: Phenom XII X4 955 3,21Ghz , GTX 560 TI, 4GB-Ram, Windows 7 64x

Du hast ein Vetex-,Normal-,Texcoord- und Indexarray für das ganze Model.
Durch die Indices gibt man an, wo er anfangen soll und wieviele vertice verarbeitet werden sollen.
Wenn du also 3 Texturen hast, dann brauchst du mindestens 3 zeichenaufrufe und die 3 Texturbindings.
In etwa so kann man sich das vorstellen.
bindeTextur(1)
Zeichne(face[0].Start,f[0].count)
bindeTextur(2)
Zeichne(face[1].start,face[1].count)
bindeTextur(3)
Zeichne(face[2].start,face[2].count)
Also Textur binden und dann sagen welche Indices er benutzten soll.
Man muss nicht den ganzen array durchjagen, man kann auch teile davon verwenden und durch die Indices geht das sehr einfach.
Idealerweise verwendest du Triangles oder Trianglestripes und musst somit mindestens 3(1 Triangle) Indices haben.
Guck vieleicht mal in die Tutorial Sektion vom wiki, wenn du das noch nicht gemacht hast.
http://wiki.delphigl.com/index.php/Tutorial_Vertexbufferobject

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

Projekte: https://github.com/tak2004

erstmal danke für deine geduld
Also das VBO an sich klappt ja wunderbar. Ich hab das Tutorial auch schon des öfteren gelesen (Vielen Dank an den Schreiber ), jedoch gibt es in Java kleinere Unterschiede, aber die sind kein Problem. Ich kann ja auch richtig komplexe Objekte mit meinem Loader laden. Z.B. hab ich aus dem Internet ein .obj Zug mit 77mb Dateigröße und etlichen zehntausenden Zeilen an Vertexe und Faces. Die Objekte müssen zwar Trianguliert sein, dass lässt sich jedoch verkraften. Und später selber Triangulieren wird vll auch eingebaut.
Aber das Hauptptoblem sind bisher die Texturen.
Für die Normalen kann man ja, falls ein Vertex mehrere Normalen hat ja einen Durchschnittswert erechnen, das geht ja dann alles noch wunderbar.
Ich hab mir das von dir auch nochmal durchgelesen und es klingt gut und ich hatte so was ähnliches im Kopf.
Wenn ich wirklich mehrere Texturen habe, dann gucke ich welche Objekte diese nutzen und rendere die entsprechende VBO teile mit der Textur. das hab ich in etwa auch verstanden, da lässt sich sicher viel Optimieren, dass ist auch gut so *g* Hab ich hier auch desöfteren so gelesen, deswegen hab ich vermutlich auch so ne ähnliche Idee im Kopf.
Auch für den Fall das ich nun für Total belemmert gehalten werde. Das alles ist ja schön und gut aber ich krieg ja nichtmal die korrekten Texturkoordinaten für eine Plane aus 2 Triangles. Das frustriert schon. Das erste Triangle wird korrekt mit der Textur gemappt, das Zweite besteht nur aus den letzen Pixeln der ersten Textur ,verschmiert z.B. oder aus roten und schwarzen Streifen oder wie in den Screens oben total verzerrte Strukturen. Selbst wenn ich nur 1.0f und 0.0f als Kombination für die Koordinaten verwende.
Sobald ich das hinbekomme, dann kümmere ich mich um die korrekte Aufteilung etc. oder ich steige erstmal nur auf VBOs ohne Index um, da sollte das ja einfacher gehen.
Bisher hab ich alles hinbekommen, aber diese Texturen rauben mir echt die Nerven, ich hoffe ihr habt noch ein paar Nerven übrig, vielen Dank schonmal

_________________
System: Phenom XII X4 955 3,21Ghz , GTX 560 TI, 4GB-Ram, Windows 7 64x

Du könntest mal probieren nur mal testweise die Texturkoordinaten als Farbwerte zu verwenden und die Objekte ohne Textur zu rendern. Nur um zu schauen, wo das Problem liegt.

Gruß Lord Horazont

_________________
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

Wenn ich das richtig verstanden habe, dann hast du unterschiedlich große arrays.
Ich kenne mich mit dem Obj file leider nicht aus aber so wie ich es sehe hast du ne vertice liste, texturliste und am ende ne indexliste.
Bei VBO kannst du nur ein Index angeben und nicht mehere also müssen alle arrays auf das maximale array erweitert werden und die inhalte dupliziert werden.
Wenn du 8 Vertice hast aber 32 Texcoords, dann musst du dein Vertexarray auf 32 Vertice bringen und zu jeder texturkoord das passende Vertex in den array packen. Nun stimmen die Listen erstmal, nun müssen die Indexliste korrekt erstellt werden, wenn ich aus den Daten im ersten Post korrekt lese, dann hast du das index auf das Vertex, ein Index auf die Texcoord und noch ein normal Index. Da du deine Arrays auf das maximum von Texcoord gebracht hast, musst du in den Indexarray nun die Indices von Texcoord nehmen.

In deinen Post hattest du 8 Vertice,32Texcoords,32Normals,32Indices also sieht deine endgültigen listen so aus.
32Texcoords.32Normals,32Indices und 32Vertice
In den Daten von dir erkennt man wunderbar, das die Box flat shaded ist(jedes Face hat die gleichen Normalindices) und das nach den Texcoords gegangen wurde(geht von 1-32).
Dies(Box mit flat shading und texcoords pro face) ist übrigens das beste Beispiel für worst case bei VBO ^^.

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

Projekte: https://github.com/tak2004

ich glaub ich könnt dich knutschen xD
Das ergibt sinn! Ja manches muss mir dann doch quasi vorgekaut werden. Das eine Box gerade der schlimmste Fall ist war schon irgendwie zu sehen, aber der Rest nicht, Danke! jetzt hab ich ne Idee das Ganze umzubasteln und umzusetzen.
Und wenn der schlimmste Fall, geschafft ist, sollte der Rest ja auch gehen dann. So nun Danke ich und mache erstmal weiter meiner Wege, bis zum nächsten Denkfehlerproblem.
Mit besten Dank ein aufgeleuchteter revolte

_________________
System: Phenom XII X4 955 3,21Ghz , GTX 560 TI, 4GB-Ram, Windows 7 64x

Auch eine gute Idee, sofern weiterhin Probleme bestehen, werde ich zuerst dadrauf zurückgreifen um das Problem weiter einzugrenzen. Auch danköö =)

_________________
System: Phenom XII X4 955 3,21Ghz , GTX 560 TI, 4GB-Ram, Windows 7 64x

Ich hatte vorige Woche ein Artikel im Wiki zu einen OpenGL angepassten und auf geschwindigkeit getrimmten Format geschrieben.
Finden kannst du den Artikel hier, dazu gibt es auch ein exporter und den Loader in C++.

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

Projekte: https://github.com/tak2004

Ja das hab ich schon gelesen, aber ich wollt erstmal was selber versuchen, um mich ein bisschen einzufummeln. Bisher hab ich auch nur einen Readaufruf und für den Anfang reicht das. Aber ich werd das alles mal im Auge behalten
mfg revolte

_________________
System: Phenom XII X4 955 3,21Ghz , GTX 560 TI, 4GB-Ram, Windows 7 64x