Und in diesem PDF findest du folgende wichtige Erläuterung: "Currently only the GL_LUMINANCE_FLOAT32_ATI and GL_RGBA_FLOAT32_ATI formats are supported for vertex textures. [...] Be aware that using other texture formats or unsupported filtering modes may cause the driver to drop back to software vertex processing [...]"

Außerdem hat nVidia einen Code-Schnippsel dazugelegt, der dir helfen könnte:


Bevor du deine alte Hardware aufgibst würde ich zumindest das Format und die Filter so einstellen wie von nVidia empfohlen.

Hey,

also mit den Werten gehts, aber ich komm im Shader nich an die Daten ran, habs über r, g, b und a probiert, aber ich hab jedesmal n schwarzen bildschirm, also multipliziert er da immer mit 0.0


MfG Bergmann

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

GL_NEAREST_MIPMAP_NEAREST? Damit sagst du, dass die Textur MipMaps besitzt. Was sie aber nicht hat. Und damit ist die Textur eigentlich nicht gültig. Also sollte dort GL_NEAREST ausreichen.

[edit] Noch eine kleine Anmerkung. Das GL_LUMINANCE_FLOAT32_ATI funktioniert nur auf ATI Karten. Du musst also überprüfen ob die Erweiterung überhaupt vorhanden ist. Wenn nicht und sollte es sich dennoch um eine ATI Karte handeln musst du darauf reagieren (wie auch immer das jetzt aussieht). Im Falle einer NVidia Karte dürftest du die Textur aber auch nicht als GL_LUMINANCE_FLOAT32_ATI hochladen sondern in etwas NVidia taugliches. Sonst funktioniert die Textur auf NV nicht. Das was du damit gerade machst ist extrem auf einen Hersteller zugeschnitten. Du musst also immer sicherstellen auf welchem System du dich befindest und wie du vorgehen musst. Ansonsten solltest du nach praktischeren Alternativen suchen.

hä, aber in der PDF oben (die ja von NVIDIA is) steht doch ich soll das so benutzen?! ich hab mich auch gewundert, aber solange es geht^^

€: mit GL_NEAREST gehts jetzt. Läuft bei max 320FPS bei 100% CPU oder mit 75FPS bei ca 5% CPU... Also VIELEN DANK!

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

Hab nicht gesehen, dass das von NVidia ist. Ist aber trotzdem ist es eine ATI Erweiterung.

Ich muss gestehen habe jetzt erst gesehen was du vor hast. Und ich bin etwas entsetzt. Ich finde diese Lösung ziemlich überzogen. Das ist aber nur meine Meinung und wahrscheinlich dürfte ich mich damit auf einem einsamem Flur befinden. Ja. glMapBuffer ist grotten langsam. Habe ich selbst schon feststellen dürfen. Selbst im Modus GL_WRITE_ONLY dauert es wesentlich länger das VBO zu Mappen als es neu zu befüllen. Theoretisch ist zwar MapBuffer besser aber praktisch dadurch nicht nutzbar. Ich weiß gerade nicht wie schnell glSubBufferData war. Deswegen gibt es zwei Alternativen. Das prinzip ist aber identisch.

Hier eine Alternative wie ich es wohl gemacht hätte. Du kannst ja 1 VBO machen in dem alle Vertex Daten vorhanden sind. Aber wer hat denn gesgt, dass du das VBO immer komplett an einem Stück zeichnen sollst? Das ist der Idealfall aber nicht zwanghaft notwendig. Du könntest das VBO ja nur als Buffer betrachten. Also du fängst vorne an und füllst eine Zeile in das VBO (glSubBufferData). Die Zweite kommt dann dahinter und so weiter. Wenn du das VBO jetzt komplett gefüllt hast, dann schmeißt du die älteste Zeile wieder raus. Also du übreschreibst dann die erste Zeile wieder. Anschließend die Zweite etc. Am Ende fängst du also wieder vorne an. Das Zeichnen läuft dann Ebeneso. Du zeichnest zu erst die neuste Zeile und arbeitest dich dann zur Ältesten vor. Du kannst die Daten dann aber auch nur Zeilenweise zeichnen. Per Vertexshader könntest du dann die Zeilen an die richtige Position schieben. Entsprechend könnte du da sogar auf die X oder Y Position verzichten. Da die ja pro Zeile fix ist. Die Position für den Shader könntest du entweder per uniform (oder wie das heißt) an den Shader übergeben oder sogar mit glTranslate setzen.

Im Speicher müssten nur die neuen Zeilen aktualisiert werden (eine Zeile pro Frame) alles andere hängt von der Zeichenreihenfolge ab. Du würdest obendrein die Anforderungen für vertexshader massiv herunter schrauben und obendrein noch Speicher für die überflüssige Textur.

Die andere Variante wäre die falls glSubBufferData zu langsam wäre. Dann wäre es zwar auch Möglich die 50 Zeilen jeweils als seperates VBO zu machen. Die müsstest du nur ein Mal befüllen und dann wäre gut. Blöde wäre dann nur, dass man öfters zwischen den VBOs wechseln muss. Allerdings weiß ich nicht ob das in der Größenordnung so ausschlaggebend wäre.

Schätze mal nVidia wollte oder durfte nicht noch eine Extension anlegen, die die gleiche Semantik wie die von ATi hat. Die Texturkompression von S3 hat auch jeder große Hersteller übernommen.
Was war denn nun die Performancebremse? Der Filter oder das Texturformat? Würde mich mal interessieren. Habe das selber noch nie ausprobiert, nur ein paar PDFs zusammengerafft.

GL_NEAREST_MIPMAP_NEAREST steht im PDF weil die da anschließend das MipMap-Level aus der Texturkoordinate auslesen.

Ganz schön esoterisch, oder?

Hey,

@Lossy eX: So ähnlich wie du es beschrieben hast mach ich es doch gerade. Bei jedem Frame eine Zeile der Textur überschreiben, das VBO nur als Buffer für die Vertexdaten (die sich nie ändern) und der Rest wird im VertexShader zusammengebaut. Ich könnte das natürlich jetzt auch noch alles auf das VBO umbauen und dann im Shader verschieben, aber ich denke so viel mehr Leistung wird das nich bringen, oder täuche ich mich da?!

@NerdIII: Also der FPS einbruch lag an dem TexturFormat. Sobald ich das geändert hatte war alles OK. Nur mit dem GL_NEAREST_MIPMAP_NEAREST konnte ich nicht auf die Daten zugreifen und hatte demzufolge ein schwarzes Bild. Also hab ich den Filter auf GL_NEAREST gesetzt un schon hat alles 1a funktioniert...

MfG Bergmann

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

Mir geht es nicht um die Leistung. Sondern darum, dass es meiner Meinung nach übertrieben kompliziert ist und übertriebene Hardwareanforderungen besitzt. Von Prinzip her ist dein einziges Problem wie du die Höhendaten auf deine Vertices bekommst. Um das zu realisieren packst du das in eine Textur und liest diese Textur aus dem VertexShader aus. Was aber die Hardwareanforderungen in die Höhe treibt.

Meiner Meinung nach ist das Einzige was du tun musst ein VBO passend zu erstellen. Je nach Geschwindigkeit von glSubBufferData für jede Zeile ein eigenständiges VBO oder aber alles in eines. Musst dann nur ähnlich wie mit der Textur eine virtuelle Datenverwaltung erstellen (aber immer Zeilen und nicht spaltenweise). Selbst wenn du die Position dann mit einem VertexShader machst sind die Hardwareanforderungen wesentlich geringer.

Auch für den Fall, dass das etwas hart klingt. Neuere Technologien gut und schön. Aber die sollten angemessen sein. Und ich finde die Visualisierung jetzt nicht so dolle, dass man da solch eine Technologien verlangen sollte. Zu mal es auch wesentlich einfacher geht. Kann auch gut sein, dass es daran liegt weil ich schon entsprechend lange beruflich programmiere und deswegen nicht mehr immer direkt hinter jeder neuen Technologie hinterher springe. Es spricht ja auch nichts gegen neue Techniken. Wenn es angemessen ist.

Das ist aber nur meine Meinung. Wenn du der Meinung bist, dass es so klasse ist wie es ist, dann ist das so. Ist ja dein Projekt.

Ah, jetz hab ich verstanden wie du das meinst. Na klar is es doof, wenn so ne Minianwendugn die neuste Hardware braucht. Ich bin aber soweit erstmal zufrieden das es schneller läuft und werds auch erstmal so lassen. Ich muss mich erstma bisl um meine Prüfungen kümmern, danach werd ich das dann sicher nochmal überarbeiten...

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