Ich kann DeepCopy und Lossy ex nur zustimmen. Ich lerne auch gerade OpenGL, habe mir zuerst mal die vorhandenen Tuts zu gemüte geführt (btw: vielleicht sollte man im Wiki einen deutlichen Warnkasten anbringen...) , und mir würde ein Tut, welches zunächst einmal ohne Shader auskommt glaube ich mehr bringen. Anhand des vorhandenen Tuts will und kann ich nicht arbeiten, weil ich dann zwangsläufig einen Teil des Tuts "auslassen" und/oder "unbesehen kopieren" müsste, und das will ich freilich nicht. Trotzdem ist das Tut aber ein sehr guter Anfang, vielleicht - wenn du es nicht umarbeiten willst - kann man das Tut ja später als "ColorPicking II - mit Shadern" ins Wiki aufnehmen?

_________________
Bringe einen Menschen zum grübeln, dann kannst du heimlich seinen Reis essen.
(Koreanisches Sprichwort)

xD Okey ich meinte zu waran sogar, dass das Tut schon viel zu veraltet ist, da man mitlerweile mit Transform Feedback in OpenGL3 viel besser machen kann.

Man muss zur Shader Problematik noch sagen, Shader sind eine Grundlage von OpenGL, wie VBO, Lineare Algebra oder Texturen.
Wenn man schon bei Kamera, Color-Picking oder ähnlichen angelangt ist, dann muss man ja schon lange die Grundlagen Tuts hinter sich haben und sich mit GLSL schon mal beschäftigt haben. GLSL muss man ja nicht perfekt beherrschen aber wissen wie man nen Shader erstellt und zerstört und was da eigentlich passiert sollte erwartet werden können.

Die Tutorials sind mitlerweile nicht mehr Zeitgemäß geordnet, wo früher GLSL ein nette Extension war ist es heute die Basis von OpenGL und gehört direkt nach VBO und Textuern erwähnt. Was auch sinnvoll ist, da man nicht ewig auf OpenGL unter Version 1.5 sich rum treiben sollte. Wir sind heute bei 3.1 und 3.2 wird auch kommen. So dass man sich schon mal an OpenGL2 Orientieren sollte(zu 3 sind einfach keine Tuts da und mein Tut kommt auch momentan nicht vorran) und dort ist GLSL eine Kern Funktion und keine Extension mehr.
OpenGL3 kommt ohne ein Shader zu schreiben und zu binden gar nicht mehr aus, man kann nur über ein Fragmentshader und Vertexshader zeichnen, da die Pipeline endlich mal aufgeräumt wurde. Spätestens da muss man GLSL als Grundlage können, da man sonnst nicht mehr als ein Schwarzen Bildschirm haben wird.

Es ist also durchaus sinnvoll mal die beide Shader Tuts im Wiki zu lesen, auch wenn es weiter unten einsortiert wurde.

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

Projekte: https://github.com/tak2004

Also, wenn hier alle waran-bashing betreiben, muss ich ein paar positive Punkte aufzeigen:

1.Endlich mal wieder ein neues Tutorial
2.Ein Tutorial, das ein wirklich wichtiges Thema aufgreift
3.Beide Seiten sind behandelt: mit UND ohne Shader
4.Den Kommentaren nach zu urteilen, sogar verständlich geschrieben
5.Und für Kritik offen
6.Ich habs gelesen und war von der Formulierung positiv überrascht (@Lossy: ein kleines WTF wirft uns nicht aus dem Sattel. Ist praktisch üblicher Internet-Jargon)

Was will man eigentlich mehr? Worüber beschwert Ihr Euch eigentlich?


Ich selber habs nur flüchtig gelesen. Mein Eindruck: der Aufbau könnte verbessert werden, ich fand es zu lang. Vielleicht überlegst Du es Dir wirklich, es in zwei sinnvolle Stücke zu brechen.

Ich finde, es wird ohnehin Zeit, alle die Dinge, ohne die wir nicht auskommen, langsam aber sicher auch auf Shader umzuschreiben. Ich verwende derzeit auch keine Shader, und es mag uns vielleicht nicht gefallen, aber wenns Euch noch nicht aufgefallen ist: OpenGL unterstützt uns nicht mehr wirklich. Ein Haufen Zeug haben sie bereits in den Abfallkübel geworfen (aka "deprecated"). Das ist so schlimm, dass sogar Tak2004 einmal kurz etwas blaß um die Nase geworden ist - kann aber auch eine Täuschung gewesen sein

Irgendwann einmal, wenn die Grafikchip Hersteller es satt haben, - und wir wissen nicht, wann das sein wird - stellen sie das ganze Zeug ein. Und dann sind wir auf uns selbst gestellt. Dann werden wir froh sein, ein paar unterstützende Tutorials zu haben.

@Traude: Ich lasse mich nicht bashen
Aber 3.) stimmt nur bedingt - jedenfalls ist es nicht meine Absicht das Kap. 4 ein "Ersatz" sein soll.

@DeepCopy, ich bin für berechtige Kritik immer zu haben, für unberechtige nicht.
Du sagst ich wäre auf deine (berechtigten) Kritikpunkte nicht eingegangen?



1) -> Wurde von mir geändert.

2) -> Ich habe extra zum Anfang des Kapitels etwas weiter ausgeholt, damit klar wird, dass jetzt Shader kommen (anstatt direkt mit dem Code anzufangen).

3) -> Schon mehrfach erwähnt: Es ist ein Shader-Tutorial, und das Hauptthema kommt bestimmt nicht an 2ter Stelle.

Also wenn du die einzelnen Revisionen des Tuts nicht verfolgst, wirst du auch nicht sehen, wie deine Kritik einfließt. Sorry...

@Tilman, ich werde mir mal anschauen, was du so geschrieben hast. Du meintest zwar, es wäre nicht Wiki-Fähig, du könntest es aber
evtl. so weit ausbauen, dass es so wird. In dem Fall könnte man sich die Shaderfrage sparen - Ich sage "-frage", weil es eigentlich
keine Diskussion ist. Wie schon erwähnt gibt es 2 Dinge im Tutorial, über deren Verwendung mit mir nicht diskutierbar ist:
Shader und Endianess.

Edit:
Es gibt mal wieder eine neue Version mit ein paar minimalen Überarbeitungen, die auch auf das hoffentlich im Wiki erscheinende
Tut von Tilman eingehen. Überarbeitet wurde 3.1 und 4.

Download wie immer hier: Link entfernt

Und nochmal an die Feedback-Leute:
Es geht mir momentan vordergründig um negative Kritik um das Tutorial zu verbessern. Wenn ihr das Tutorial gut findet, und
das hier schreibt, freut mich das natürlich (und bietet mir eine bessere Orientierung darüber, welche Kritikpunkte in der breiten Masse
vertreten werden, und welche "nur" persönlich sind) - aber seid bitte nicht sauer, wenn ich nicht gesondert darauf eingehe.

Es tut mir zu tiefst leid, wenn hier der Eindruck entstanden ist, dass warans Leistung nicht angemessen gewürdigt wurde oder er hier runtergemacht werden soll. Er hat ein Tutorial geschrieben und um Resonanz gebeten. Diese Resonanz hat er bekommen. Wenn auch eher negative Resonanz deutlich länger sind als "alles okay". Zu mal ich "gemecker" nie unbegründet im Raum stehen lasse.

Ohne Shader vs Shader vs Transform Feedback: Es wird immer eine neuere Technologie. Das war schon immer so und das wird auch immer so bleiben. Ich für meinen Teil bin kein Technologieverweigerer, auch wenn einige sicher den Eindruck haben werden (auch schon vor dem Tutorial). Ich bin allerdings auch niemand, der blind neuen Technologien hinter her rennt. Ich bin für den verhältnismäßigen Einsatz von Technologien. Und dazu gehört nun mal, dass man immer bedenken muss wofür die Anwenung entwickelt wird und entsprechend dessen dann die passenden Techologien auswählt. Das hat dann nichts mit dem Erfahrungsgehalt des Entwicklers zu tun sondern mit dem Ziel der Anwenung. Auch wenn Großteil der Leute hier Spiele entwickeln will, dann tun das bei leibe nicht alle. Ich find es da nicht fair, dann neue Technologien aufzunötigen. Zu mal diese beiden Wege ja nun auch extrem dich beieinander liegen. Meiner Meinung nach könnte man den "Ohne Shader" Abschnitt dann besser auch ganz weglassen. Das ist doch nur ein pseudo Kompromis. Wenn ich nicht wüsste was beim ColorPicking gemacht werden müsste, dann würde mich dieser Abschnitt eher verwirren als dass er tatsächlich helfen würde. Auch wenn sich das vielleicht hart anhört aber so sehe ich das.

WTF: Das wirft mich nicht aus dem Sattel. Allerdings der Trend der letzten Jahre macht mir irgendwo Angst. Iwie wird jeder Scheiß willenlos abgekürzt und mit Anglizismen zu gepowered. Dazu kann ich nur sagen. Yeah! Pisastudie FTW.
Nein. Ironie bei Seite. Gegen locker habe ich überhaupt nichts. Ganz im Gegenteil. Aber ich fand den Anfang schlicht unpassend. Nicht nur wegen dem WTF.


Und was das Tutorial angeht. Waran hat mittlerweile klar gemacht, dass er sein Tutorial nur auf Shader bassieren lassen möchte. Was auch vollkommen sein gutes Recht ist. Ich habe meine Meinung mittlerweile mehrfach kund getan, dass ich das nicht so gut finde. Sonst habe ich zu dem Thema Tutorial nichts weiter zu sagen. An der Stelle aber noch mal ein großes Dankeschön an Waran für die Mühe und den Umfang des Tutorials.

Ich möchte auch mal kurz meinen Senf dazugeben, was die "Shader/Nichtshader/OpenGL3/neue Techniken"-Problematik betrifft.

Als ich angefangen habe mit OpenGL zu Programmieren, tat ich das mit reiner WinAPI und Delphi. Irgendwann empfahl man mir dann SDL, weil Plattformunabhängigkeit einem kleine aber genügsame Spielenutzer einbringt (Linuxer z.B.). So weit so gut. Ich werfe nun aber auch in dem Raum, dass z.B. SDL mit OpenGL3 noch "so seine Probleme hat" und dass viele Linuxkisten trotz topaktueller Software u.U. etwas ältere Hardware haben - oder die OpenGL Treiber "unausgereift" sind. Auch der Trend der Netbooks sollte imho nicht ignoriert werden. Worauf ich hinauswill, ist: Mein Ubuntu mit seinem Intel-Treiber auf meinem System kann im Moment nur OpenGL 1.4 - d.h. KEINE Shader (mit glSlang), aber trotzdem programmiere ich auf diesem System kleine Spiele. Warum auch nicht? Ich bin Hobbyprogrammierer, da ist es, denke ich, durchaus legitim richtig einfache Spiele zu schreiben, die dann in einem angemessenen Zeitrahmen und mit angemessenen Aufwand fertig werden. Die "neuen Techniken" sind schön anzuschauen und sollten auch nicht verteufelt werden. Aber sie sind für mich (und hier kommt ein wichtiger Punkt ins Spiel) nicht DIE Grundlage von OpenGL. Jeder soll für die Version programmieren, die ihm gefällt. Und wenn ein Anfänger die nächsten 15 Jahren im Immediate Mode programmieren will, ist das seine Sache und ich finde es falsch ihm krampfhaft Shader, VBOs und "son Kram" andrehen zu wollen.

Um auf warans (gutes) Tutorial zurückzukommen: Ich finde es super. Ich finde es auch gut, dass es auf Shader setzt, viele/alle moderne Grafikkartzen können diese auch benutzen. Aber halt nicht jede Hardware. Deshalb finde ich auch das 4. Kapitel gut. Man könnte vielleicht noch anmerken, dass Leute, die eh Shader einsetzen, hier getrost zu Kapitel 5 springen können und fertig is. Was ich NICHT gut finde, ist alles auf "modern" machen zu wollen, wie TAK2004 es fordert. Die Reihenfolge ist so, wie sie ist, gut und auch ein paar neue "altmodische" Tutorials wären noch angebracht, denn wir sind keine Copy&Paste Fabrik. Wir geben Tutorials, damit andere Leute irgendwann selbstständig OpenGL programmieren können und erstmal die Grundlagen raffen. Und da sollte es ein Angebot für Anfänger und Semiprofis geben und man sollte nicht in Dogmen ertrinken. <_<

Solche Sätze wie finde ich in dem von mir erörterten Zusammenhang nicht gut. Ich programmiere im Moment (ca.) OpenGL 1.3. Was höheres brauch ich für meine Spieleideen nicht. Eh ich die Zeit und Muße habe, mir ne neue Hardware zu kaufen (im Moment fehlt mir z.B. das Geld), mich mit Shadern zu befassen, Schatten zu raffen und mich mit den mathematischen Grundlagen auseinanderzusetzen, damit meine Spiele "ansehnlich" aussehen, würde viel Zeit ins Land gehen - und OpenGL ist "nur" ein Hobby und nicht DAS Hobby und ich habe noch anderes zu tun und will auch "was sehen".

Ich hoffe, ihr versteht, was ich meine.
Tolles Tut, waran

LG Ziz

_________________
Denn wer nur schweigt, weil er Konflikte scheut, der macht Sachen, die er hinterher bereut.
Und das ist verkehrt, denn es ist nicht so schwer, jeden Tag zu tun als ob's der letzte wär’.
Und du schaust mich an und fragst ob ich das kann.
Und ich denk, ich werd' mich ändern irgendwann.
_________________Farin Urlaub - Bewegungslos

Also Transform-Feedback gibt es nicht - keine Panik
Im Moment ist das glReadPixels zwar durchaus der Flaschenhals in der Implementierung, aber
wenn man das Kosten-Nutzen-Verhältnis bedenkt ein durchaus legitimer:

- ReadPixels wird nur bei der Selektion aufgerufen. Wenn die Selektion also mal mit nur 50 statt 500 FPS läuft,
ist das zu verschmerzen.
- Transform Feedback würde die Hardwareanforderungen massiv in die Höhe schnellen lassen (GeForce 8, Minimum),
während OpenGL2-Grafikkarten schon für ein paar Euro in der Wühlkiste zu bekommen sind.

-> lohnt nicht.


Nachdem ich das ganze ein bisschen verfolgt habe, sieht der Plan wie folgt aus: Ich lasse das Kapitel 4 auf jeden
Fall drin, werde aber beide Möglichkeiten (Immediate-Mix und VA/VBO) besprechen und eben im Kontext der
Zielgruppe (etwas erfahrener; benutzt nur keine Shader, weil die Hardware es nicht bietet; große Programme)
bewerten.

Edit:
Leider ist es doch ein bisschen länger geworden... deswegen werde ich den Vorschlag hier nicht einquoten.
Die aktuelle Version mit dem neuen sowie alten Tut lässt sich an der üblichen Stelle runterladen.

Also ich will auch mal meinen Senf dazu geben.

Vorn weg an Selligmann: Du musst kein SDL benutzen wenn es für dein Tutorial keinen Sinn macht. Vielmehr wurde easySDL geschaffen um dieses Problem zu umgehen. easySDL bietet ein komplettes Framework wo nach Möglichkeit nur noch der interessante Code reingepackt werden muss um zu funktionieren. Es ging hier um Zeitersparnis, nicht um Zwang.
Was aber nicht vergessen werden darf: Wir haben hier nicht nur Windows Nutzer sondern eine stetig steigende Quote an Linuxern (und jetzt auch Mac-Usern ), da ist ein Windows-Only-Beispiel einfach nicht angemessen.

@Tutorial:
Das Thema ist definitiv interessant, da jeder der die GL Selektion benutzt hat, schon an der Tischkante genagt hat, wenns mal wieder nicht, oder nur langsam ging.

Ich seh das Thema aber wie Ziz. Als ich Shader gelesen habe, dachte ich mir "Super. Also ein Tut was dir nix nützt." Ich schreibe auch auf GL1.4 und wüsste auch nicht, wozu ich jetzt mehr vorraussetzen sollte. (Meine HW kann auch gar keine Shader. Weder PC, noch Laptop noch NetBook).
Das finde ich dahingehend ärgerlich, da es überflüssig ist. Bei der "Technik Colorpicking" spielen Shader erstmal gar keine Rolle. Man kann es damit machen, vielleicht sogar sehr elegant, man muss aber nicht. Ich denke, dass kommt im Tutorial nicht so rüber und Lossys Befürchtungen dass Leute dann einfach Code ohne drüber nachzudenken übernehmen ist berechtigt. Schließlich werden sie vom Forum aus direkt dahin verwiesen ("ließ dir das mal durch!") und dann nimmt man was man kriegen kann.

Beim Hobby Spieleprogrammierung ist es wie bei Spielen: Die einen Zocken weils ihnen Spass macht, die anderen wollen Pro-Gamer werden. Viele Hobbyprogrammierer programmieren, weil sie ihre Ideen umsetzen wollen und weil das ihnen Spass macht, andere wollen die neuesten Technologien einsetzen und mit Spielefirmen konkurrieren, oder machen das vielleicht beruflich bzw. wollen das mal machen.

OpenGL hat den Vorteil, dass es Anfängern einen guten Einstieg gibt. Shader sind aber ein Thema was nicht mit Texturen oder Blending zu vergleichen ist. Das ist eine komplett neue, höhere Stufe.

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

Ich seh gerade das Tillmann das Thema von der Anfänger-Seite aus angeht. Das ist denke ich ein guter Kompromiss.

Dann könntest du in deinem Tutorial in der Einleitung auf das Anfänger Tutorial hinweisen, und erklären, dass du dieses Prinzip mittels Shader umsetzen willst und damit auch GL3 kompatibilität erreichst.

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

Also erstmal vorweg: Ich finde es gut, dass du deinen Senf dazugeben willst, aber, ohne jetzt
pampig wirken zu wollen, dafür solltest du das Tutorial schon lesen ^_^

Wie dir dann aufgefallen wäre:
- Mache ich ganz klare Angaben über die Zielgruppe (damit keine Missverständnisse entstehen)
- Verweise ich bereits auf das Tutorial von Tilman

Allein von den Posts in diesem Thread auszugehen reicht nicht, weil sich das Tutorial vom
Ersten bis zum Letzten immer wieder ein bisschen entwickelt hat. Gewisse Themen sind deutlicher
geworden, dazugekommen oder wurden ganz umgeschrieben.

Und OpenGL3-Kompatibel ist das Tutorial noch lange nicht, nur weil ich Shader benutze. Damit
wird lediglich die vernünftigste Art es unter OpenGL2 zu machen beleuchtet

Möchte meinen Senf zum Thema Anfänger-Tutorial auch noch dazugeben:
In der Forenübersicht steht sehr Schön:

Shader - Das Forum für die Fortgeschrittenen unter Euch rund um das Thema Shader.

Konnte ich mir jetzt nicht verkeifen

_________________
Gruß Andreas (aka DeepCopy) - Sic Luceat Lux

Classified Directive: initialization write in function for finalization, repeat until public case uses begin, if not case type as default, var in virtual override for while, in case of class type type asm until read begin.

Nicht jeder, der den Weg ins Forum findet, findet auch den Weg in die Tutorialsektion des Wikis und umgekehrt.

_________________
Denn wer nur schweigt, weil er Konflikte scheut, der macht Sachen, die er hinterher bereut.
Und das ist verkehrt, denn es ist nicht so schwer, jeden Tag zu tun als ob's der letzte wär’.
Und du schaust mich an und fragst ob ich das kann.
Und ich denk, ich werd' mich ändern irgendwann.
_________________Farin Urlaub - Bewegungslos

Ok. Erwischt...

Ich habs mir jetzt mal durchgelesen und ich finde, es kann so ins Wiki. Die Anfänger-Variante sollte dann entsprechend auch ins Wiki mit dem Hinweis, dass in Warans Tutorial im Kapitel 4 eine Optimierung der shaderlosen Variante verfügbar ist.

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

Ich wollte zu dem Thema eigentlich meine Klappe halten, allerdings habe ich noch eine wirklich ernst gemeinte Frage.

Und zwar geht es um den vierten Abschnitt. Dort beschreibst du schön, dass die DisplayListen aus dem ShaderTeil "state complete" sind und das Optimum für den Treiber darstellen. So weit so klar. Allerdings stelle ich mir dort ernsthaft die Frage was der Treiber macht, wenn da nur ein einziges Mal glColor drin steck. Aber massive Vertexmengen. Erzeugt er in dem VBO, dann einen kompletten FarbBuffer oder setzt er es außerhalb? Also wie wenn man die Farbe mittels glColor außerhalb eines echten VBOs setzen würde. Was aber laut deiner Aussage auch wieder imediate wäre und damit auch wieder suboptimal. Bzw spannend wäre es, wenn ich der DisplayListe 2-3 Mal glColor stecken würde.

Hast du irgendwelche fachliche Quellen/Spezifikationen/etc die das Thema etwas näher beschreiben. Und "weil es so ist" bzw. Personen aus dem irc lasse ich da mal nicht als Antwort gelten. Auch die müssenn es irgendwoher haben.

Es ist in der Tat so, dass der Treiber ein vollständiges VBO erstellt (d.h. die Farbdaten wiederholt parallel neben die Vertexdaten kopiert).
Das ist aber natürlich kein Gesetz, sondern hängt ganz vom Treiber ab - wobei es bei aktueller Hardware definitiv günstiger ist, Speicher
für Performance zu opfern.

Wenn ich mich recht erinnere, ist die Quelle dafür "OpenGL Performance Programming by Eskil Steenberg" (Vortrag auf der
Blender Conference 2006 - das Video dazu kann man sich per Torrent von blender.org herunterladen).

Ich schaue es mir aber nochmal an, damit ich dir sicher sagen, ob es auch wirklich die Quelle war (das Video lohnt sich aber auch
so - also Anschauen schadet nicht).

Edit:
Die relevante Stelle in dem Video kommt ab ca. 20:05 - da spricht er darüber, wie fürchterlich es für den Treiber ist,
wenn man Displaylisten erstellt, die nicht komplett sind. Leider lässt er sich nicht darüber aus, wie die Listen nun intern
verarbeitet und hochgeladen werden. D.h. ich muss weiter suchen um dir ne gute Quelle zu liefern

Newest Edit:
Ich habe tatsächlich nichts gefunden (von wegen das DLs exakt wie VBOs behandelt werden)... d.h. bis ich mir nicht selbst
das Gegenteil bewiesen habe, fliegt das mit dem DL = VBO aus dem Tutorial raus.