Tach allerseits.

Ich versuche eben eine Heightmap mit Normalen aufzurüsten.
Leider wird die Geometrie jedoch nicht mehr gezeichnet, wenn ich die Normalen aktiviere.

Die Vorgehensweise habe ich aus einem NeHe tutorial gelernt.
Dort wurde der zweite Buffer jedoch nicht mit Normalen, sondern mit Texturen gefüllt.
Texturen brauche ich aber keine - Beluchtungs-Effekte aber schon!

Ich habe mir also zwei Vertex-Arrays gebastelt welche die gleiche länge haben.

Nachdem diese gefüllt sind binde ich diese folgendermassen:



Im render code rufe ich dann so auf:



Zunächst soll eine Heightmap MIT NORMALEN gezeichnet werden und anschliessend noch ein Wireframe drüberglegt werden.
Solange ich die Normalen weder binde noch rendere funkzt alles tiptop.

Bitte helft mir die Normalen noch hinzubekommen dann bin ich wunschlos glücklich

ach ja und wer genaueres über das tutorial möchte:
http://nehe.gamedev.net/
bzw. Lektion 45
http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=45
freue mich auf antworten

Habe das Thema mal verschoben.

Also spontan würde ich behaupten, dass du glEnableClientState erst nach dem entsprechenden gl*Pointer aufrufen solltest. Bzw eigentlich genügt es, wenn du alle States direkt vor dem Zeichnen aktivierst.

PS: Laut einem Dokument von NVidia sollte glVertexPointer der letzte gl*Pointer Befehl sein den du aufrufst, da dieser diverse Dinge initialisieret die bei anschließenden gl*Pointer noch mal initialisert werden müssten. Wenn ich das richtig in Erinnerung habe. Aber sollte wohl eher kaum einen markanten Unterschied mit sich bringen.

Beim Füllen bindest zu die beiden Buffer hintereinander und rufst dann 2x glBufferData auf. glBufferData wirkt sich nur auf den aktuell gebundenen Buffer aus. Daher wäre richtiger:

glBindBuffer(,Vertex)
glBufferData(,Vertex)

glBindBuffer(,Normalen)
glBufferData(,Normalen)

Habe eure Vorschläge bereits umgesetzt und....

... es tut

Jupeida und jupeidi!

Ihr seid spitzte! VIELEN DANK!

__________________________________________________________
(________)_\__|___|__/____/__\____|____\__|__|_\__\__/__/_
___|__|_____|__\_/__|____/____\___|__|\_\_|__|__\__\/__/__
___|__|_____|_______|___/__()__\__|__|_\_\|__|___>____<___
___|__|_____|__/_\__|__|________|_|__|__\____|__/__/\__\__
___|__|____/__|___|__\_|__(__)__|_|__|___\___|_/__/__\__\_

Warum trennst du die Koordinaten und Normalen? Das kannst du in ein VBO schieben und entsprechend über den Offset adressieren.

_________________
__________
"C++ is the best language for garbage collection principally because it creates less garbage." Bjarne Stroustrup

Wie mienst du das?

Habe mir mal die Variante von Nico mit glInterleavedArrays angesehen.
Den Ansatz finde ich bisher den schönsten.
Dort wusste ich dann aber nicht wie ich die Methode aktiviere.

Jaja, das wird wohl die Geschichte mit dem Header sein um den ich mich immer herumgemogelt habe.

Prinzipiell müsste es aber doch so ähnlich gehen wie die anderen ARB Funktionen:

-> auch aus dem NeHe Tutorial.

Wahrscheinlich meist du das aber anders:
etwa so?

(poste das mal einfach ohne probiert zu haben )

ps: toller footer sehe ich au so!
dieses forum ist trotzdem das beste für OpenGL

Nein ich meinte wirklich nur EIN VBO



Du siehst Position und Normalenvektor sind in einen Feld und durch den Offset bei den Pointer-Funktionen teilt man OpenGL mit, wie die Informationen im Feld aufgebaut sind. Durch den Offset weis das System nun, dass die Positionen nicht hintereinander im Feld liegen, sonder "irgendwas" dazwischen. Das geht mit allen Daten, welche über so eine Pointer-Funktione gesetzt werden können (Farbe, Texturkoordinaten, Attribute für glSlang)

_________________
__________
"C++ is the best language for garbage collection principally because it creates less garbage." Bjarne Stroustrup

Kann man dadurch auch den Speicher minimieren?

Mein Problem ist bei zu hohen Auflösungen, dass der RAM voll wird

Ich versuche also folgendermassen den Speicher anzulegen, aber wenn vertexCout zu gross ist - krach


Wenn ichs recht sehe kann ich mit deiner Methode einfach die Anzahl Pointer reduzieren.
Bringts das schon?

Was ich auch nicht ganz verstehe, ist wo die Daten am Schluss (nach dem Binden) liegen?
Ein Memoryleak habe ich nicht, aber wenn die Datei geladen ist steht der RAM immer an höherer stelle als zuvor.
Eigentlich habe ich mir vorgestellt, dass die Daten nun wirklich nur noch auf der Grafikkarte liegen und mein RAM wieder frei ist.

Gruss

Nein, es werden dadurch ja nicht weniger Daten, sie werden nur anders gelagert in deinem Programm. Bei der Ein-VBO-Variante brauchst du einen größeren zusammenhängenden Speicherblock, dafür sparst dir halt einmal den Buffer-Wechsel. Du kannst auch weiterhin mit deinen 2 VBOs arbeiten, wenn das so funzt.



Mit glBindData schaltest du erstmal nur einen Buffer aktiv, mehr nicht! Das Reservieren von Speicher passiert dann mit glBufferData. Sobald du dein VBO gefüllt hast, kannst/solltest du die externen Puffer wieder freigeben.


Nach dem Füllen also nicht das delete[] vergessen. Effektiv hast du nach dem Betanken des VBOs also nur noch die ID, mit welcher du arbeitest (wenn ich jetzt mal von nem statischen einmal betanktem VBO ausgehe)

Also sozusagen

1. Puffer im eigenen Programm anlegen und mit Daten füllen (new Vertex[ganz_viele])
2. VBO-ID generieren und binden
3. Mit glBufferData die Daten vom eigenen Programm in den VRAM kopieren lassen, so füllst du das VBO
4. eigene Puffer wieder freigeben (delete[] pPuffer), die Daten im VRAM verbleiben

_________________
__________
"C++ is the best language for garbage collection principally because it creates less garbage." Bjarne Stroustrup

unwichtig