Ich benötige zur Visualisierung von Atomen in bälde Kugeln und Stäbe/Zylinder.
Diese sollten möglichst Flüssig gerendert werden können, der Detailgrad einstellbar sein und Texturierbar sein.

Angedacht hatte ich erst Quadriken. Allerding wurde ja schon mehrfach erwähnt, dass selbige Suboptimal sein sollen. Hat jemand andere fertige Geometrien, die ich verwenden könnte. (Ist für ne Auftragsarbeit... )

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Pack die Quadricen doch in eine Display-Liste, dass dürfte die Dinger dann performant genug machen. Alternativ gab es mal von Jason Allen (Macher der glBmp.pas) eine gl-Objects Bibliothek die sehr viele Primitiven anbietet. Wenn du diese benötigst, kann ich die hochladen, da der Macher ja anscheinend nicht mehr aktiv ist.

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

Gibts bei denen Lizenzbestimmungen zu beachten?

Die Sache mit den Displaylisten klingt auch interessant. Ich müsste dann jedem Atom meines Atomgitters sagen, welche DL es zum Zeichnen Aufrufen soll. Eigentlich auch sehr simpel.

Was sind denn eigentlich DIE Nachteile von Displaylisten? Ich hab damit ja noch net so negative Erfahrungen damit gemacht.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Displaylisten verbrauchen im Gegensatz zu VAs bzw. VBOs einiges mehr an Grafikkartenspeicher, da dort ja nicht nur Vertexdaten bzw. Texturkoordinaten oder Normalen abgelegt werden müssen, sondern auch die Befehle. Und ausserdem macht man sich mit Displaylisten recht stark von der Intelligenz der genutzen OpenGL-Implementation abhängig. Während man bei ATI bzw. NVidia davon ausgehen kann dass der Treiber Befehle batchen kann (also aufeinanderfolgende glVertex-Aufrufe zusammenfasst) muss das bei anderen Herstellern nicht der Fall sein.

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

Kann man im Allgemeinen trotzdem davon ausgehen, dass DL einen Geschwindigkeitsvorteil bringen, auch ohne diese Optimierungen? (Ich soll bis zu 100000 Atome rendern)

(Ich hoffe darauf, dass du als Erfahrener sagst "Mach das mal so und so. Das ist das beste." )

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Kommt halt wie gewohnt darauf an wodurch du limitiert bist. Bist du durch den Vertexdurchsatz limitiert wird die Nutzung von Displaylisten mit großer Wahrscheinlichkeit (es sei denn du nutzt recht schlechte GL-Treiber, also z.B. die von Intel, S3) Geschwindigkeit bringen. Bist du durch andere Sachen limitiert (Füllrate, CPU) bringen die dir natürlich nicht sonderlich viel.

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

Also CPU kann ich als Engpass ausschließen. (es sind min 1.5GHz da, wahrscheinlicher 2GHz oder sogar 2.5GHz 64Bit)

NVIDIA GeForce4 MX 440 mit AGP8X als Grafikkarte. Hoffe Füllrate is da net das Problem.

Ich soll das Rendering allerdings auch direkt in ein Video schreiben. Also läuft das dann im Videorendermode komplett auf der CPU, und ansonsten (Vorschau) über die Graka.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Je nachdem wieviele Dreiecke für eine Kugel benötigt werden, wäre es auch sinnvoll mehrere Kugeln in einem Schritt zu rendern und dann VBO's zu nehmen. Selbst 100.000 Aufrufe von glDrawElements + Matrix setzen pro Frame sind schon ziemlich viel und bei Display Listen kommt dann bestimmt noch zusätzlicher Verwaltungsaufwand dazu.

Wenn ich im Vorschaumodus bin, ist die Sache ja net so wichtig. (Ich setzt einfach die Details bisl runter... )
Wenn ich allerdings das Videorendere möcht ich das schon in endlicher Zeit machen. Allerdings läuft das ja dann nur über die CPU und nichtmehr über die GraKa.

Mit welchem Befehl schreibe ich eigentlich den Inhalt des Framebuffers in eine Bilddatei, die ich später zu nem Video verarbeiten kann? Bzw. Was muss ich am Renderloop ändern, wenn ich in ne Datei statt auf die StdOut rendern will?

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Guck mir das glatt mal an.

VBOs hätten aber keinen Sinn, wenn nicht über die GraKa gerendert wird oder!? (eigentlich Logisch...)

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Also ich kanns weder Compilieren (Da fehlen wohl dateien) noch testen (Failed to Set Pixel Format).

Wenn ich genau wüsste, dass es auch hier funktioniert, dann könnte man den Code ja verwenden.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Ich habe es mal vor einiger Zeit ausprobiert und das Programm funktioniert. Eventuell sind da auf der Seite noch units die man laden muß. Ansonsten ist auch der Quelltext ja dabei, da sieht man wie es gemacht wird.

Gut...hab die fehlenden Files.
Damit komm ich weiter.
Ist die Videoaufname eigentlich von der Framezahl abhängig. Ich hab jetzt paar tests gemacht un es scheint, das Video is bisl holprig.

Schätze Displaylisten mit Quadricen sind erstmal die erste Wahl. Oder gibts Sachen die absolut dagegen sprechen. (VBOs bedeuten für mich zusätzliche Einarbeitungszeit.)

(Ich frag deshalb so nach, weil ich net in 1 Monat feststellen will "Hmmm...Eigentlich wär XYZ besser gewesen.)

_________________
Blog: kevin-fleischer.de und fbaingermany.com