Genau das Tool meinte ich. Für den Einstieg bzw. schnelle Umsetzung von FF nach Shader ist dass Tool gut geeignet, allerdings wie gesagt für Lernzwecke, die Shader sind also so geschrieben dass man sie versteht, und nicht bis aufs letzte optimiert.

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

mir geht es nicht ausschließlich um die syntax, sondern eher darum, wie man einen shader jetzt im programm einbindet.

aber du hast schon recht, diese vertex-beleuchtung is nich die beste

Ich hab hier RenderMonkey rumliegen, damit lässt sich nach ein wenig Einarbeitungszeit ganz gut arbeiten.

@GlBegin/GlEnd: ich bin ehrlich gesagt auch kein Freund davon. Mir will es einfach nicht in den Sinn wieso ich erst expliziet etwas ankündigen muss anstatt gleich sagen zu können "zeichne hier und hier und hier nen Polygon". Das ist meiner Meinung nach für einen Anfänger auch einfacher, da er sich nicht erst mit all den GLBEGIN Modes auseinandersetzen muss.

_________________
(\__/)
(='.'=)
(")_(")

Hallo,

wo ist denn das Problem mit glBegin?
Ich finde glBegin eher genial, wie will man sonst ein Polygon mit einer variablen Anzahl von Eckpunkten, Farben, Normalen, Texturkoordinaten etc. zeichnen?
Eine einzelne Funktion, der man diese ganzen Daten als Parameter übergibt ist meiner Meinung nach ziemlich häßlich.
Ein Objekt würde eventuell noch infragekommen, aber dafür bräuchte man extra Speicherstrukturen (z.B. variable Listen ), ist auch nicht so schön.

Viele Grüße
dj3hut1

Was das Problem mit glBegin() ist, wurde im Thread schon besprochen. Dazu zählen
- Overhead bei der Treiberentwicklung für mehrere "Pfade"
- glBegin() und was dazu gehört, lassen sich kaum auf moderner Hardware abbilden
- daher um Vielfaches langsamer und CPU intensiv
- eventuell möchte man Entwickler "umerziehen" performantere Möglichkeiten in Betracht zu ziehen, damit das Ansehen von OpenGL wieder hergestellt wird gegenüber Direct3D?

Wenn du mal mehr und mal weniger viele Vertices zeichnen möchtest - bitte nenne doch einen Anwendungsfall - kannst du zum Beispiel bei einem LOD-System verschiedene Index-Listen in deine Vertexdaten verwenden. Angenommen, du hast einen Zylinder mit 64 Seiten aus der Nähe. Dann zeichnest du in großer Entfernung mit einem glDrawElements Aufruf einfach eine Elementliste, die nur 8 Seiten zeichnet. Dafür brauchst du dann überhaupt keine CPU-Leistung mehr, abgesehen von der Entfernungsberechnung. Finde ich klasse!

Wie das ohne glBegin laufen soll kann ich mir bis jetzt gar nicht vorstellen. Ich denke da sollten bald ein paar Tutorials erweitert werden. Ich bin kein großer Fan von zu viel OOP, ich hasse es, durch Units von Komponenten zu scrollen und tausende Prozeduren zu sehen, die alle nur ein paar Zeilen lang sind, statt einfach mal ein paar ordentliche. Ich hoffe es wird nicht so schilmm, denn ich bin ein Fan von einer Mischung aus Normal und OOP.

Was evtl. auch nicht unerwähnt bleiben sollte. Das Grundgerüst von OpenGL so wie es jetzt existiert wurde vor/um 1995 entwickelt. Seit dem hat sich ein ganz kleines Bisschen was getan. Zum Beispiel. T&L, VBO, Multitexturing, Vertex Shader, Fragment Shader, Geometrie Shader. In den letzten 13 Jahren hat sich die Hardware und selbst OpenGL in eine Richtung entwickelt die zu Begin nicht absehbar war. Irgendwo muss man einen Strich ziehen und komplett "neu" anfangen und die ganzen Altlasten und Relikte rauswerfen. Alles andere wird irgendwan nur krampfig. Und dieser Schritt ist meiner Meinung nach mehr als überfällig.

Aber hey. Es könnt schlimmer sein. Wenn man mit D3D neue Features benutzen möchte muss man seinen Rendercode komplett umstellen. COM sei dank.

Man muss auch ein bischen vorsorgen, für Raytracing, deffered shading(wird eine sehr große rolle spielen, aufgrund von consolen) und anderen dingen. Ein bischen vorher hab ich auch schon erwähnt, das MGPU und MCPU entwicklung sich stärker in den Mittelpunkt schieben wird. Ich glaube seit nen halben Jahr sind die multicore gpu's raus und es gibt bei der optimierung auf diese noch Problemstellen(z.B. Occlusion culling), die auch noch vorsorglich verbessert werden sollten.
Aktuell werden die Grafikkarten sehr gut ausgenutzt(sind schon nahe Fotorealismus) aber was völlig vernachlässigt wird ist Physik und KI. Seit einiger Zeit schiessen ja Middleware für KI und Physik aus den Boden, die schon echt was drauf haben und man sich fragt, wie konnte man die völlig zurückgebliebenden NPC verkraften. Es wäre z.B. super, wenn man in den Treiber ein hull algo mit implementieren könnte, dann würde Physik und KI wesentlich einfacher und vorallem schneller seine arbeit verrichten können.
In der Regel verwendet man qhull, um die Hüllen zu berechnen aber das ist CPU basiert und die GPU kann sowas in bruchteilen erledigen Da die Welten mitlerweile dynamisch sind, da mehr Leistung zur verfügung steht, werden auch zur laufzeit Hüllen generiert und das ist ned schön, wenn man beim zerfetzen eines Felsen aufeinmal ein kurzes ruckeln hat, weil er die hülle neu berechnen muss. So ein Task kann auch super parallelisiert werden und stört die neuen grakas nicht im geringsten(kann in ruhepausen zwischengequetscht werden) und auf den alten braucht es halt ein paar ms, je nach komplexität.

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

Projekte: https://github.com/tak2004

Wie wärs mit einer Funktion, einem Parameter für den Typ der Daten und dann schiebt man alles via Array/Buffer/WasAuchImmer rüber.

_________________
(\__/)
(='.'=)
(")_(")

Hallo,



Ok, nur mal so als Beispiel, wo der Unterschied wäre, für ein einfaches Fünfeck :



oder :



Viele Grüße
dj3hut1

Mhh.
Bei mir würde das 5 Eck, im immidate mode, so dargestellt werden.


Mit VBO so.


Mit D3D so.


...

Jeder Kapselt fein sein Code in Funktionen und oder Klassen, z.B. den Fenstercode, zum erstellen von GDI und X11 Fenster oder nutzen solchen von anderen.
SDL, OpenAL, RTL/STL/LCL,... wieso soll es dann so schwer sein, auch OpenGL Code zu verpacken ?
Ich kann mir nicht vorstellen, dass jemand von euch direkt auf Alsa, DSound oder OSS programmiert sondern OpenAL, FMod oder ähnliches verwendet.
Wieso ? Weil es einfacher ist und einen viel Zeit abnimmt. Das einarbeiten in die einzelnen API's kostet viel wertvolle Zeit und den Code dann zu debuggen noch vielmehr.
Statistisch verwenden wir ~75% unserer Zeit, an einer Software, für das beheben von Fehlern.
Es ist auch Statistisch wiederlegt, dass die Fehlerrate mit steigender Zeilenanzahl wächst, sogar das Gegenteil ist der Fall.
Komplexere Abläufe enthalten in gekapselter Form weniger Fehler als der direkt geschriebene Code.
Bei komplexer Software, wie einen Spiel hat die Industrie schon lange den Einsatz von externen Game Engines, Middleware und Hilfstools als sinnvoll erkannt.
Also frage ich mich doch, wieso stört es keinen 50 Zeilen Windows und 30Zeilen X11 Code in 2 SDL Funktionen gekapselt zu verwenden aber bei 10Zeilen OpenGL Code sich völlig daran zu verbeissen ?
Mitlerweile wissen wir doch alle, dass Funktionalitäten, wie der immidate Mode eine großen Anteil Code im Treiber ausmacht und durschnittlich gesehen nur von einer verschwindend geringen minderheit verwendet wird.
Ist es wirklich fair gegenüber den Spielern und der Industrie zu sagen "Ich will dieses Feature weiterhin haben.", obwohl die Treiberentwickler ~23%(30% codeeinfluss bei 75% debugzeit=22,5%) der Zeit damit verbringen das beinahe tote Feature am leben zu erhalten ?
Wäre es nicht einfacher sein Code zu Kapseln, die vielen Vorteile zu geniessen und fast 1/4 der Zeit für viel wichtigere Dinge, wie z.B. neue Features, zu verwenden?
Ich glaube, dass es vielen nur schwer fällt gegenüber neuerungen offen zu sein und sich an kleinigkeiten klammern.
Also ich hoffe doch, dass jeder Weise genug ist, seine kostbare Lebenszeit sinnvoll einzusetzen.

My2Cent zum Thema immidate mode.

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

Projekte: https://github.com/tak2004

Ich habe mal kurz nachgedacht wie die Zukunft aussehen könnte...

OpenGL 3 wird von allen wichtigen Parteien und Krhonos verabschiedet. Binnen kurzer Zeit haben nVidia, ATi und Intel OpenGL 3 Treiber auf dem Markt, da der Unterschied zu OpenGL 2.x doch relativ gering ist. Diese Treiber werden zunächst noch nicht komplett optimiert sein, aber dennoch das Potential spürbar machen. Jede größere, aktuelle OpenGL Software wird versuchen den Sprung zu machen, da Treiberunterstützung auf breitem Feld vorhanden ist und Geschwindigkeitsvorteile winken. Nach 2 Jahren wird OpenGL 2.x offiziell von den Hardware Herstellern nicht mehr unterstützt. Wie auch bei einigen neu entstehenden OpenSource Projekten wird der Fokus auf Emulation von OpenGL 1.x-2.x über OpenGL 3 gelegt. Der Bestand an alter Software macht dies erforderlich und dank der hohen Performance neuer Hardware laufen die alten Programme auch mehr oder weniger gut.
Es wird erstmals 2 Programmbibliotheken für OpenGL geben. OpenGL 1-2 werden von der bekannten DLL unterstützt und OpenGL 3 bekommt eine neue DLL mit aufgeräumter Codebasis und verbesserter Ladezeit, denn bereits jetzt ist der nVidia OpenGL Treiber 6,7 MB groß.
Große Fluktuationen von D3D Entwicklern hin zu OpenGL sehe ich nicht kommen, aber vermehrt kleinere Cross-Platform-Projekte, die OpenGL 3 voraussetzen u.a. um die Grafikkarte als mathematischen Koprozessor zu verwenden.

...und in drei Jahren poste ich hier nochmal und schreibe: "Ich hab's euch ja gesagt!"

Klingt sehr logisch und mich feut das überhaupt nicht. Warum OpenGL nicht wie die UnrealEngine: Es gibt kein Release, sondern immer wieder Verbesserungen - einzelne Teile werden neu programmiert und somit verbessert - die UnrealEngine 3 existiert daher nicht. Ich hasse Versionen, ein Build x gefällt mir besser. Das hat an sich auch wieder Nachteile, aber kleine Updates lassen sich leichter durchführen und die Abwärtskompatibilität ist leichter beizubehalten. [OT]Dass die UnrealEngine eine der besten Engines der Welt ist, sehe nicht nur ich so, zumal sie eine der wenigen ist, die weder OpenGL noch DirectX benachteiligen, also beides gut unterstützen.[/OT]

Also Unreal Engine3 ist ned schlecht, dass wir uns nicht falsch verstehen aber wenn du mal mit programmiert hast oder dir mal den sourcecode angeguckt hast(meine wenigkeit), wirst du es überhaupt nicht mehr mögen. Wöchentlich ändern sich der Sourcecode, man muss ständig die branches integrieren und das ist ne arbeit, die für eine Person allein reicht. Zum glück gibt es nur selten große updates, wo sich wirklich was an der Basis verändert.
Also das arbeiten mit der Unreal Engine 3 ist einsame spitze, in keiner Engine kannst du schneller Ergebnisse erzielen aber es zu erweitern ist echt häftig.
Ein Freund von mir hat letztens mal den Test gemacht und in Crysis,UE3 und HL² versucht das gleiche Model mit texturen und shader zu exportieren.
UE3 hat er ~5min gebraucht, Crysis ~2h und HL² hat nen halben Tag gedauert. Ich denke das macht ziemlich klar, wieso UE3 so gerne lizensiert wird.
Noch dazu ist UE3 meines wissens der einzige, der hot asset support hat. Also hui für grafiker und etwas pfui für programmierer.
Allerdings hat man als programmierer eh nicht viel zu lachen, das gleiche neue feature muss für xbox360,pc und ps3 parallel programmiert werden, also 3mal aufwand für die gleiche sache.
In der Regel hat man eine Mainversion.Subversion.Patchversion.Devversion also 4 Versionscounter, die ein Stück Software beschreiben.
Änderungen an der Basis, Funktionserweiterung, Bugfixes, Testversion für Neuerungen und Änderungen.
Die 4. version sieht man nach aussen nicht und die 3. wird oft mit der 2. nummer gemixt.
Aktuell wäre bei OpenGL die korrekte Versionierung so zu beschreiben Mainversion(1-2).Subversion(1-9).Vendor Build(xxxx).
ATI bringt jeden Monat auf den gleichen Tag immer ein Build und wenn nur die readme sich verändert hat.
Also jeden Monat einen 2.1 OpenGL Treiber der durch seine Vendor Buildnummer erkennen lässt, ob er optimierung x oder ext y zusätzlich drin hat.
Die Basis, auf die alle Kartenhersteller bauen müssen ist aktuell 2.1 aber was mit der Build version noch drin ist, legt eine 3. Nummer fest und damit ist absolute kompatibilität gewährleistet. Als Spieleentwickler sage ich, alles was in x.y drin ist kann ich verwenden und für spezielle nicht notwendige Features kann ich ja .z prüfen.

Meiner Meinung nach ist die Versionskennzeichnung von OpenGL sehr übersichtlich und bedarf keiner korrektur aber einer höheren Frequenz(z.B. alle 6Monate).
Alle 6Monate kommt ein neuer NV,ATI oder IBM Chipsatz raus und es wäre toll, wenn dann schon die letzten wichtigen Extensions/ARB zu einer ARB/Basis Funktion geschafft hätten. Das erleichtert die Arbeit, für die Entwickler der Frameworks.

edit:Übrigens hat Unreal auch Versionen Unreal1, Uneral2,Unreal 2.5,Uneral 2X, Unreal3,Unreal3 MMOG,... finde leider die Seite von epic dazu ned.

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

Projekte: https://github.com/tak2004

Meinst vielleicht das UDN? http://udn.epicgames.com/

UE 2.5X war ja damals der Branch für die XBox. Bei der 3er ist die Codebasis laut Epic doch auf allen Plattformen lauffähig, da würde ich die spezialisierungen zum MMO/wasAuchImmer/ nicht als eigene Branch sehen, denn das würde zu spezifisch werden.

_________________
(\__/)
(='.'=)
(")_(")