Da das Texturentutorial ja auch schon recht alt und nicht mehr so ganz Uptodate ist, dachte ich mir (danke Flash für den Gedankenanstoß), dass ich das mal überarbeiten werde. Mir stellt sich jetzt nur die Frage wie kompliziert man es gestallten sollte. Also zur Aufwahl ständen.
- Texturen laden per Hand und auch das Hochladen per Hand.
- Texturen laden mit glBitmap
- Texturen laden mit Textures
- Texturen laden mit glBMP

Ich denke mal das Laden per Hand sollte man nicht zu ausführlich erklären sondern in einem extra Abschnitt erklären. Dann aber auch hauptsächlich nur den Teil der auf OpenGL Seite zu tun ist. Für Fortgeschrittene sozusagen.
Ich persönlich tendiere eher auf eine Zwei Wege Lösung. Also einmal der Objekt orientierte Weg mit der glBitmap und ein mal der Procedurale mit der Textures.

Da bin ich aber auch schon beim nächsten "Problem". Meine glBitmap arbeitet anders als anderen Loader. Und zwar lege ich die Texturen mit der Oberkante nach Oben im Speicher ab wärend andere die Unterkannte nach oben ablegen. Ich habe selber bereits mehrfach an meinen Fähigkeiten gezweifelt aber die Cubemaps und die Cubemapdemo auf Sulaco haben meine arbeit bestätigt. Kurzer Hintergrund. Die Texturkoordinaten bei Cubemaps werden von OpenGL berechnet. Dabei hat man von außen keinerlei Einfluss drauf wie die Texturen dargestellt werden. Bei der glBitmap befinden sich die Texturen richtigherum in der Datei, werden so geladen und auch so an OpenGL gesendet. Dort werden sie auch richtig herum dargestellt. Bei der Textures müssen alle Texturen auf dem Kopf in den Dateien abgelegt werden. Die werden dann geladen und geflipped damit sie wieder richtig sind. Also scheine ich ja irgendetwas richtig gemacht zu haben. Das dumme daran ist nur, dass entsprechend die Texturkoordinaten auch anders sind. Und das könnte einen Anfänger ganz schön aus dem Gleichgewicht bringen.

Da ich ungern arbeit im Nichts versenke hier meine eigentliche Frage. Wie seht ihr das bzw was für einen Aufbau würdet ihr gerne sehen? Welche Loader etc. Oder habt ihr evtl. noch ganz andere Vorschläge?

Kaptiel1: Grundlagen

Kapitel2: Arbeiten mit der glBitmap (da das der "Boardeigene Loader" ist)

Kapitel3: Hinweise zu anderen Loadern.

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

Ich fände es ja genial, ein bisschen darüber zu erfahren, wie der Loader bestimmte Dateitypen in den RAM holt. Also bevor irgendetwas mit OGL gemacht wird.
Aber das wäre wahrscheinlich etwas viel und würde wohl auch an dem vorbeigehen, was 90% der User von einem Texturentut erwarten.
Trotzdem: Ich fänds klasse!

Lossy, da hab ich gleich mal eine Frage:
Ist es für dich in Ordnung, wenn ich die Methoden aus deinem Loader zum Laden eines JPEGs in den Speicher für mein Landschaftsprojekt benutze/kopiere? Bisher kommt meine Heightmap-Klasse nämlich nur mit Bitmaps zurecht und geht dabei den Umweg über TBitmap. Ich würde das ganze gerne um JPEGs erweitertern, habe allerdings nicht unbedingt die Motivation, einen eigenen Loader zu schreiben.

Robert

Also in meinem Loader gehe ich auch ausschließlich über TBitmap! Auch ein TGA wird kurzzeitig zu einem TBitmap. Da wäre es zwar einfacher es direkt in den Speicher zu laden, aber aus Gründen der Klassenstruktur und des streng abstraktem Denkens habe ich mich dafür entschlossen wie es ist. Geschwindigkeitstechnisch dürfte es kaum einbußen geben, da ich bei Bitmaps mehr oder weniger am Stück den Speicher kopiere. Also super schnelle Aktionen.

Das Laden der Dateien dürfte wohl für die Meisten uninteressant sein und vor allem benutze ich hauptsächlich vorgefertigte Klassen. Dadurch wieder das wieder alles recht unspektakulär. Aber sonst kannst du dir das gerne anschauen wie ich das gemacht habe und deinen Code davon "inspirieren" lassen.

PS: Evtl solltest du dir mal die PNG Klassen anschauen. Verlustfreie Kompression. Unterstützt format die lediglich einen Kanal haben. Grayscale also. Und du kannst die Pixel ohne Umwege aus der Klasse abfragen.

Vielen Dank, besonders für den Tipp mit den png-Klassen. Gerade die Möglichkeit, 1-Kanal-pics zu nehmen, gefällt mir doch sehr gut, da ich z.B. bei bitmaps mit 3 kanälen ganz schön overhead dabei hab.

Robert

*grml*

Lektion 1 bis Lektion 4 der Einsteigertutorials habe ich im Zuge der DGL-Qualitätsoffensive Ende März komplett überarbeitet (irgendwann hatte ich mal Zeit).
Lektion 2 und 3 habe ich bereits ins Wiki portiert, die anderen beiden haben begonnen auf meiner Festplatte Schimmel anzusetzen.

Wenn du Interesse hast, kann ich dir die Dokumentversion der überarbeiteten Fassung (die, die auch auf der Delphi-Tage-CD ist) zusenden. Damit vermeiden wir Wiederholungen. Wenn es noch Wünsche seitens der Community gibt können wir die Version entsprechend erweitern und überarbeiten. Ein Kapitel über deinen Loader fehlt beispielsweise.

Ich hoffe, dass ich am Wochenende etwas Zeit finden kann und mit meinem Gewissen endlich wieder ins Reine komme . Dann sollte zumindest Kapitel 1 im Wiki zu finden sein…

_________________
Nichts auf der Welt ist so gerecht verteilt wie der Verstand. Denn jederman ist überzeugt, dass er genug davon habe.
Rene Descartes, frz. Mathematiker u. Philosoph, 1596-1650

Ah. Genau. Jetzt wo du es sagst. Ich erinnere mich da an etwas. *cdrauskram* (nein ich war nicht da)

Ich denke mal, wenn wir da evtl 1-2 Kapitel hinzufügen sollte das vollkommen ausreichen. Vor allem da bei meinem Loader ja die Koordinaten noch anders sind als bei der Textures.

[edit] Also wie man mit existierenden Loadern eine Textur darstellt. Das ist ja doch nicht immer unbedingt leicht.

Ja genau. Existierende Loader noch dazu und glaux.dll aus dem Wortschatz des DGL-Boards verbannen. Schwerpunkt wie gesagt bei den Loadern auf deinen eigenen. Der bietet viele möglichkeiten und ist außerdem leicht zu handhaben... . Paar Worte zu den Unterschieden zwischen existierenden Loadern wären auch nicht schlecht. Aber da erzähl ich dir nix neues...

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

Auch auf die Gefahr mich unbeliebt zu machen. Ich persönlich würde den Schwerpunkt am liebsten eher auf SDL_Image sehen, da dieses ohne Änderungen auch Plattformunabhägig funtkioniert (tun Lossys auch?) und nahezu jedes Bildformat frißt. Allerdings wäre es vielleicht wirklich nicht verkehrt ein vertiefendes Tutorial anzustreben, dass anfangs ein wenig Theorie übers laden (allgemein) vermittelt, danach alle üblichen Loader vorstellt (vielleicht gar vor-/nachteile beleuchtet: leicht zu verwenden, aber keine Alphas). Dann vielleicht noch als krönenden Abschluss darauf eingehen, wie man selbst z.B. über einen Algorithmus (Perlin Noise?) dynamisch eine Textur im Speicher generiert. Dann haben wir ein vertiefendes Tutorial, dass wir unter dem bestehden Anhängen können und einen leicht zu verdauenden happen auf dem man auch leicht verweisen kann, wenn die Loader-Frage gestellt wird.

_________________
"Light travels faster than sound. This is why some people appear bright, before you can hear them speak..."

Als ich würde vorschlagen zu zeigen wie man eine Lade Funktionen für eine TGA-Datein programmiert. Und zwar eine die ein OpenGL Bild Objekt zurückgibt welches man dann auch in OpenGL funktionen direkt verwenden kann. Anhand dieser Funktion sollte erklärt werden wie das grundsetzlich abläuft. Danach wäre es natürlich nicht schlecht wenn man den SDL und glBitmap Loader, als mögliche und gute Verpackung dieser Funktionen vorstellt und kurz erklärt wie diese funktionieren.


Bei der Texturgenerierung sei noch erwähnt das es bereits ein Tutorial dazu gibt und Red damals sogar eine Fortsetzung angekündigt hatte. Dieses Tutorial sollten wir meiner Meinung nach updaten und es zum Nachfolger des Texturierungs Tutorials machen.

Bisher hat Red in seinem Tutorial erklärt wie man einen Editor programmiert und eine Anwendung, die diese Ergebnisse dann nutzt. Diese Anwendung arbeitet soweit ich weis sogar noch mit Canvas.

Ich würde vorschlagen den ganzen Editor auf OpenGL umzustellen und die verschiedenen Schichten mit Hilfe von Blending umzusetzen. In der neuen Version sollte dann auch der "Perlin Noise" Effekt erwähnt und benutzt werden.
-> Mit einem Verweis auf den guten Artikel dazu im Wiki.

Ich würde vorschlagen erstmal Red zu fragen, inwiefern er dass selbst machen möchte. Oder ob er es erlaubt das jemand anders (zum Beispiel ich) sein Tutorial, als Grundlage für ein neues verbessertes Tutorial nutzt.

MfG
Flo

_________________
Danke an alle, die mir (und anderen) geholfen haben.
So weit... ...so gut

Auf jeden Fall sollte das auch mal selbst erklärt werden, weil viele Leute die fertigen Units nehmen und gar nicht wissen was da passiert.