Diskussion zu: Einblick in die grundlegende Funktionsweise von Grafikengines [Archiv]

Anmelden

Archiv verlassen und diese Seite im Standarddesign anzeigen : Diskussion zu: Einblick in die grundlegende Funktionsweise von Grafikengines

Leonidas

2010-03-15, 13:37:49

Link zum Artikel:
http://www.3dcenter.org/artikel/ein-einblick-die-grundlegende-funktionsweise-von-grafikengines

Exxtreme

2010-03-15, 14:18:15

Die Screenshots von Stunt Car Racer machen den Artikel top! :heart:

Ansonsten schon recht komplex das Ganze.

Affinator

2010-03-15, 15:23:54

Sehr interessant, wobei für mich leider (noch?) kein neues Wissen dabei war.

Kann man mit einer Erweiterung im Laufe der nächsten Zeit rechnen?

Auf jeden Fall ein sehr hilfreicher Artikel für einen ersten Einblick.

Grüße,
Affinator

Gast

2010-03-15, 18:41:25

Wo gibt es den Quellcode?

huha

2010-03-15, 19:53:05

Ich find den Artikel wirklich, wirklich grauenhaft.

Also gut, wo sollen wir anfangen?

Vielleicht bei einer Sache zuerst: Wikipedia-Links stören. Sie vermitteln den Eindruck, daß der Autor keine Lust hat, dem Leser die Konzepte zu erklären, die er im Artikel erwähnt und erwartet und stattdessen lieber auf die Wikipedia verweist. Im Artikel halte ich das für schlecht, da es ungemein ablenkt und die Verlinkung teilweise auch sehr unglücklich gewählt ist. Wichtige Dinge sollte man direkt im Artikel erklären oder ggf. zuvor auf Literatur zum Thema verweisen, die für das Verständnis wichtig ist. Der ganze Blumenstrauß Wikipedia-Links im Artikel wirkt auf mich, als hätte der Autor zwar Lust gehabt, mit Schlagwörtern um sich zu schmeißen, jedoch blieb diese aus, als es darum ging, diese kurz und prägnant so zusammezufassen, daß der Leser sich nicht erst durch große Wikipedia-Artikel kämpfen muß.

Der Artikel ist ziemlich seltsam strukturiert und verwirrt mich als Leser nur, wenn er mich nicht langweilt. Folgende Themen werden angeschnitten, allerdings wird keines wirklich behandelt:
1) Was ist überhaupt eine 3d-Engine/kurze geschichtliche Abhandlung
2) Wie macht man 3d-Modelle
3) Ausrechnen von Translation, Rotation, Projektion
4) Programmierung

Schon Punkt 1 ist ein Fehlschlag epischen Ausmaßes. Die Frage wird im Artikel nicht nur sinnlos philosophisch aufgegriffen, indem man sich weigert, abschließend zu klären, was nun als "echtes" 3d gesehen werden darf, sondern es werden auch noch durch unglückliche Formulierungen Dinge impliziert, die einfach nicht stimmen:
So wird impliziert, Mario Kart wäre ein Ausflug in die dreidimensionale Welt auf einer Konsole, die dafür kaum geeignet ist. Das ist allerdings grottenfalsch; Mario Kart ist 100% 2d, auch in der internen Repräsentation der Dinge. Mode 7 des SNES ist nur eine geschickte Verwendung der hardwarebeschleunigten Skalierung und Rotation von Hintergründen; alles, was sonst zu sehen ist, sind Sprites. Mode 7 ist absolut kein 3d, nicht mal getrickstes 3d. Es ist 100% 2d, mit dessen geschickter Anwendung man dem Benutzer vorgaukeln kann, die Handlung spiele sich im dreidimensionalen Raum ab.
Weiterhin wird behauptet, Polygongraphik komme ""echtem" 3D doch recht nah: Zumindest als mathematisches Konstrukt wird ein echter dreidimensionaler Raum vorgehalten." Das ist natürlich totaler Quatsch und der Autor weiß das auch. Auch Punktwolken (vulgo: Voxelgraphik) sind echtes 3d, als mathematisches Konstrukt wird dabei auch ein echter dreidimensionaler Raum vorgehalten (die Punkte haben ja dreidimensionale Koordinaten). Hier wird einfach wider besseren Wissens ein Text geschrieben, der zwar nicht per se falsch ist, da man sich nicht bequemt, irgendwann zu definieren, was man unter "echtem 3d" versteht und dies lieber der Phantasie des geneigten Lesers überläßt, aber der einfach völlig falsche Dinge impliziert.
Es wäre geschickter gewesen, statt der ausgesprochenen nicht-Frage nach "echtem 3d" darzulegen, welche Vor- und Nachteile die Verfahren haben, mit denen man um sich wirft. Steht zwar alles auch in der Wikipedia und den verlinkten Artikeln, aber wenn man so argumentiert, dann wäre eine reine Wikipedia-Linksammlung vollkommen ausreichend.

Punkt zwei verfolgt einen löblichen Ansatz, scheitert jedoch daran, daß er wichtige Dinge zwar erwähnt, dann aber ignoriert. Der gewählte Ansatz taugt exklusiv für Wireframe-Modelle, da man mit der verwirrenden Begründung, daß es ja sowieso keiner merkt, gleich mal 1/3 der Dreiecke wegläßt. Ziel eines Artikels ist es jedoch, den Leser nicht unnötig zu verwirren, warum also einen Wireframe-only-Kunstgriff wählen, wenn es darum geht, die Grundlagen zu erklären? Bis man verstanden hat, warum man die Dreiecke weglassen kann (und warum das i.a. eine total verblödete Idee ist), vergeht einiges an Zeit. Außerdem bringt's natürlich nichts. Weiterhin ist mir völlig unverständlich, warum so an n-eckigen Polygonen festgehalten wird. n-eckige Polygone sind scheiße. Erstens funktioniert der ganze Spaß sowieso nur, wenn die konvex sind (wird im Artikel nicht erwähnt, warum auch?), zweitens arbeitet so absolut keine 3d-Engine. Im späteren Artikelverlauf wird uns das noch weiter verfolgen, da wir später sehen werden, daß der Autor die n-gon-Geschichte voll durchzieht und uns mit sinnlosem Code dafür belästigt, obwohl er zugibt, daß das keine 3d-Engine so macht. Besser wäre hier gewesen, einfach nur Dreiecke zu nehmen. Fertig.
Dieser Abschnitt des Artikels leidet aber dennoch an vielen Problemen: Er ist einfach verdammt schwer verständlich. Warum sind die Punkte nicht in einem Koordinatengitter eingezeichnet, so daß sofort klar ist, was der Autor meint? Stattdessen muß sich der Leser mit langen und trockenen Texten herumschlagen, aus denen er dann die Informationen ziehen soll und sich die Pyramide vorstellen. Ich gehe mal davon aus, daß der Leser der Zielgruppe besser damit bedient wäre, ein Koordinatengitter vorgesetzt zu kriegen, in dem die Punkte eingezeichnet sind, damit er die Sache etwas leichter nachvollziehen kann.
Generell ist die mangelnde Nachvollziehbarkeit ein großer Kritikpunkt am Artikel, vieles wird nicht erklärt und auch nicht sinnvoll visualisiert.

Drei: Problematisch. Die (höhere) Mathematik hinter der Sache läßt sich nicht mal eben so erklären, also zeigt man eben, wie das Zeug ausgerechnet wird. Meines Erachtens nach wird's hier wirklich schlecht, da der Artikel in belanglose Langeweile abdriftet. Jemand, der die Mathematik hinter der Sache nicht versteht, hat keine Chance, eine 3d-Engine zu bauen, warum rechnet man das Zeug also von Hand aus? Hier wäre ein Ansatz, der vereinfacht und symbolisch erklärt, was der Kern der Sache ist, anstatt sich daran zu ergötzen, Rotationsmatrizen hinzuschreiben und auf den Wikipedia-Artikel zur Matrixmultiplikation zu verlinken, weitaus sinnvoller und letztendlich ergiebiger gewesen. Wer sich in der linearen Algebra auskennt, für den ist das Zeug extrem langweilig, da selbstverständlich. Wer sich nicht darin auskennt, versteht überhaupt nicht, was das eigentlich soll und sieht nur die wenig interessante Rechnung. Wenn man schon Formeln und Gleichungen benutzen will, dann sollte man sie zumindest vernünftig erklären. Warum sieht die Rotationsmatrix beispielsweise so aus, wie sie aussieht? Wenn das FOV so leicht anzupassen ist, wo sind dann die Projektionsmatrizen, die dies demonstrieren? Die Mathematik dahinter wird dadurch zwar immer noch nicht erklärt, es hilft aber, die Rechnung etwas besser zu verstehen und illustriert zumindest die Komplexität der Sache.

Darauf folgen eine Menge wirklich, wirklich belangloser Aussagen, die absolut nicht erklärt werden. Warum brauchen Polygone Normale, um deren Orientierung festzustellen? Klar, für mich ist das selbstverständlich, ich gehöre aber auch nicht zur Zielgruppe des Artikels.

Der vierte Punkt: Die Code-Beispiele! Die Programmierung!
Erstens: Vektoren sind keine Vertices. Punkt. Ein Vertex ist ein Eckpunkt. Der kann vielleicht durch einen Vektor charakterisiert werden, aber ein Vektor ist nicht automatisch ein Vertex. Das ist eine extrem ungenaue und auch letztendlich falsche Formulierung, die einen falschen Eindruck erzeugt.
Ob man die Code-Beispiele braucht, sei mal dahingestellt. Etwas sinnlos ist es, auf n-eckige Polygone zu setzen (s.o.). Ebenfalls sinnlos ist es, auf eine so häßliche und schwer verständliche Sprache wie VB (?) zu setzen, aber das ist in diesem Fall geschenkt. Ich halte die Code-Beispiele einfach nicht für zielführend. Wer soll damit was anfangen können? Außerdem werden wohl viele Dinge nicht so umgesetzt, wie du sie beschreibst; wer keine Ahnung von der Materie hat, wird auch keinen Renderer hinkriegen, Codebeispiele hin oder her. Wer Ahnung davon hat, braucht die Minimal-Beispiele nicht. Wichtig ist das Verständnis der Mathematik, dann kann man sich das Zeug kurz zusammenschreiben. Fehlt dieses, dann nützen auch die größten und tollsten Code-Beispiele nichts.

Ebenfalls falsch ist die Idee, daß Geometriedaten bei Rotationen und Translationen geändert werden. Das Zeug ist statisch und wird erst bei der Projektion berücksichtigt. In einer idealen Welt macht das freilich keinen Unterschied, wir bewegen uns aber in einem Computerprogramm nicht in einer idealen Welt. Da wir nur mit Datentypen begrenzter Präzision arbeiten, führt jede Berechnung dazu, daß wir Informationen verlieren und ungenauer werden. Es ist also nicht zu empfehlen, unsere Geometrie sukzessive immer wieder zu verändern, da das letztendlich dafür sorgt, daß sich die Objekte verändern. Gerade bei sehr kleinen Rotationswinkeln oder großen Translationen kann dies bei Gleitkomma-Zahlen zu Problemen führen. Das Fachgebiet der Numerik beschäftigt sich übrigens u.a. damit, wie man Berechnungen anstellt, damit das nicht zu einem allzu großen Problem führt. Wichtigster Punkt ist allerdings, daß man idealerweise die Geometriedaten statisch hält und nur die Parameter für die Projektion ändert. Das führt zu wesentlich weniger Ungenauigkeiten.

Meines Erachtens nach ist der Artikel zwar ambitioniert geschrieben, aber letztendlich ziemlich undurchdacht. Es gibt noch wesentlich mehr Kritikpunkte, die ich daran auszusetzen habe, aber letztendlich ist meine große Kritik, daß so wenig über die wirkliche Funktionsweise geschrieben wurde, sondern einfach in einer Stream-of-Conciousness-Art alles zusammengetragen wurde, was einem spontan zu 3d-Graphik einfällt. Und so liest es sich eben auch.
Geschickter wäre hier eine Vorgehensweise gewesen, die sich im Bewußtsein an die Komplexität der Materie dieser nähert und versucht, den Kern herauszuarbeiten. Hier kann man gut mit Metaphern arbeiten, ohne die Korrektheit zu kompromittieren. Man kann so einen Artikel schreiben, ohne eine einzige Formel oder eine einzige Codezeile zu erwähnen und ihn dennoch so halten, daß nachher klar ist, was eigentlich passieren muß, bis ich von der Idee meines Objektes zu dessen Repräsentation auf meinem Bildschirm komme.

-huha

Klingone mit Klampfe

2010-03-15, 20:38:55

Man kann so einen Artikel schreiben, ohne eine einzige Formel oder eine einzige Codezeile zu erwähnen und ihn dennoch so halten, daß nachher klar ist, was eigentlich passieren muß, bis ich von der Idee meines Objektes zu dessen Repräsentation auf meinem Bildschirm komme.

-huha

Dann schreib' Du doch einen.

Pinoccio

2010-03-15, 20:47:38

...(y) Volle Zustimmung. :-(

Für die Translation wird zu einem Vektor, der verschoben werden soll, einfach ein Richtungsvektor aufaddiert.Ich bin bislang davon ausgegenagen, daß man das mit homogenen Koordinaten macht, also in 4D rechnet und auch die Translation als Matrix schreibt.

mfg

Gast

2010-03-15, 21:03:16

Sagt mal, habt ihr keine interne Qualitätssicherung? Die Idee des Artikels ist ja ziemlich lobenswert und das ist ja auch eigentlich genau die Art von Artikel, die ich seit langer, langer Zeit auf dem 3DC vermissen. Das 3DC ist mit Artikeln um diese Thematik schießlich groß geworden, wie man am Namen erahnen kann. Doch was man hier lesen kann, gleicht eher einem schlechten Witz. Wenn Huha den Artikel auseinander nehmen kann, dann ist doch wirklich etwas schief gelaufen.

mks

2010-03-15, 21:08:46

Ich finde den Artikel prinzipiell nicht so schlecht, auch wenn es tatsächlich ein paar Mängel gibt.

Auch wird mal wieder das Raytracing verklärt... Durch Raytracing erzeugte Bilder sind nicht "mehr 3D" als durch Projektion und Rasterung erzeugte Bilder. Im normalen Fall sind die Ergebnisse der Sichtbarkeitsberechnung("Primary Rays") sogar identisch. Dass es mit Raytracing leichter möglich ist, andere Optiken als die Lochkamera zu simulieren, ist eine andere Geschichte.

Auch beim Shading erzeugt Raytracing nicht automatisch tolle Bilder. Prinzipiell stehst du bei beiden Verfahren nach der Sichtbarkeitsberechnung ersteinmal an genau der gleichen Stelle. Du kannst bei beiden Verfahren die üblichen "Tricks" anwenden, oder aber auch einen kompletten Pathtracer verwenden ( auch wenn Rastern+Pathtracing wenig Sinn macht, man hat die Nachteile beider Verfahren und die langsame Geschwindigkeit eines Pathtracers ).

Das musste ich mal sagen, auch wenn ich eigentlich ein Raytracingfan bin. (Einen Raytracer zu programmieren macht einfach mehr Spaß...)

huha

2010-03-15, 21:22:30

Dann schreib' Du doch einen.

Dazu fühle ich mich aufgrund meines nur extrem rudimentären Wissens um die Thematik nicht in der Lage. Ich hoffe mal, daß du das verstehen wirst.

-huha

Robbson

2010-03-15, 22:28:43

Neomi

2010-03-15, 23:12:49

So sehr ich auch gerne den Versuch würdigen würde, ein doch eher komplexes Thema einfach zu erklären, so sehr ist dieser Versuch in die Hose gegangen. Daß sich manche Dinge nicht für größere Zielgruppen passend vereinfachen lassen, ohne dabei verfälscht zu werden, sieht man immer wieder. In dem Fall merkt man aber inhaltlich sehr deutlich, daß du selbst noch ein Laie auf dem Gebiet bist und einige der grundlegenden Konzepte selbst noch nicht verinnerlicht hast. Deine Erklärungen sind oft für das Thema belanglos, wahnsinnig umständlich bzw. ineffizient oder auch falsch. Du vermischst auch gerne Dinge, die man nicht vermischen sollte. Willst du jetzt eigentlich Grafikengines, Renderer oder Grafik-APIs behandeln? Da fehlt einfach die Struktur, wie huha schon sagte.

Mal der Reihe nach...

"..., was Grafikkarten so bearbeiten: Polygone, Vektoren, Matrizen, Rasterizer, Grafikengines etc."

Schon in der Einleitung geht es los. Bearbeiten ist eigentlich das falsche Wort, da die von dir genannten Dinge nicht verändert werden. Verarbeitet werden Ressourcen, das sind hauptsächlich Vertices und Dreiecke, die diese Vertices referenzieren, dazu noch Texturen. Matrizen und diverse Renderstates spielen dabei auch eine Rolle, gelten aber eher als States und weniger als Daten. Bearbeitet werden Rendertargets und Depth-/Stencilbuffer, wobei letztere ja nur ein Hilfskonstrukt sind. Rasterizer ist hier ganz falsch, das ist ein verarbeitender Funktionsblock in der GPU (oder Softwareengine). Und eine Grafikengine wird schon gar nicht verarbeitet, denn das ist der Teil der Software, der über eine API den Renderer mit Arbeit versorgt.

Zum Thema "Super Mario Kart" und "echtes 3D" hat huha ja schon genug gesagt, aber wieso sprichst du da Avatar an? Dort geht es eher um Stereoskopie, ein ganz anderes Thema als dein Artikel.

Der Vergleich des Bildschirms mit einer Seite eines Würfels, in dem die 3D-Welt ist, ist auch mal ziemlich verkehrt. Der Sichtbereich entspricht keinem Würfel, sondern einem Pyramidenstumpf. Und die 3D-Welt ist auch nicht im Pyramidenstumpf, sondern der Pyramidenstumpf in der 3D-Welt. Bei Bewegungen werden die Positionen der Vertices von Objekten nicht angepaßt, die liegen im sogenannten Local Space des Objektes vor und bleiben auch dort. Erst beim Rendern selbst werden sie umgerechnet, aber das Original nicht verändert.

Wie lange werden jetzt schon nicht mehr ungefüllte Drahtgittermodelle verwendet? In der Contenterstellung natürlich schon, in den Spielen selbst aber schon ewig nicht mehr. Sämtliche Ausführungen zu Liniendarstellung inklusive Bresenham und "Tricks" mit weggelassenen Dreiecken hättest du dir sparen können, die sind schon seit Ewigkeiten belanglos. Wobei der Bresenham-Algorithmus auch nicht in die Grafikengine gehört, sondern in den Renderer. Einzig und alleine gefüllte Dreiecke sind seit langer Zeit für Spiele relevant. Nicht nur, weil Dreiecke immer konvex sind, sondern auch weil drei Punkte immer in einer Ebene liegen.

Weiter geht es mit der Projektionsmatrix. Warum 3x2? Du erwähnst später noch den Z-Buffer und die Perspektivenkorrektur, nimmst denen aber jede Grundlage. Eine normale Projektionsmatrix ist 4x4, weil neben x und y auch z (Tiefe) und w bzw. genauer rhw (für die Perspektive) nötig sind. Der Vektor (dem Laien knallst du da noch ein unerklärtes "transponiert" vor den Latz), der mit einer solchen Matrix multipliziert wird, benötigt auch seine vierte Komponente (w, implizit meist 1 vor der Projektion), damit das funktioniert.

Punkt für Punkt zu deiner Auflistung in "Zu einem Computerspiel ist es aber noch weit"...

1. Du benutzt hier einfach "Framebuffer" für alles, unterscheiden sollte man aber zwischen Frontbuffer und Backbuffer. Auf den Bildschirm kann man nicht zeichnen, sondern höchstens in den Frontbuffer, während der dargestellt wird. Dann sieht man auch den Aufbau. In der Regel zeichnet man deshalb in einen Backbuffer, der dann je nach Variante in den Frontbuffer kopiert wird (niemals in den Bildschirm) oder selbst zum Frontbuffer wird, während der alte Frontbuffer zum Backbuffer wird.

2. Der Z-Buffer ist nicht ineffizient, sondern die bisher performanteste und problemloseste HSR-Variante für Rasterizer.

3. Du läßt das so klingen, als ob ein Raytracer diese Berechnungen automatisch macht (falsch) und ein Rasterizer durch Zusatzarbeit langsamer wäre (auch falsch). Die Berechnung des Beleuchtungsmodells ist bei beiden gleich aufwändig. Die Schattenberechnung benötigt beim Raytracer Sekundärstrahlen, beim Rasterizer einen Lookup in einer vorher berechneten Shadowmap (ein zusätzlicher Renderpass, kein Algorithmus im eigentlichen Sinne). Allerdings hattest du hier gar nicht erst einen Rasterizer erwähnt, sondern einen Raytracer gegen Polygongrafik gestellt. Da Polygongrafik nur die Art der Daten beschreibt und die auch per Raytracer berechnet werden können, war der Vergleich unpassend.

4. Einfach nur "viele Berechnungen" ohne auch nur zu erklären, was dafür nötig ist. Außerdem werden Texturen nicht verzerrt und aufgetragen, sondern es werden passende Werte aus ihnen geholt. Also eher ein Nachschlagewerk (pro Pixel) als eine Tapete.

5. Direct3D und OpenGL sind nicht einfach Hardware-APIs, es können genauso auch Software-Renderer dahinterstecken. Mesh-Loader sind nicht Teil dieser APIs, sondern allerhöchstens in Zusatzbibliotheken (D3DX ist nicht D3D) zu finden. Beleuchtung bieten die APIs auch nicht, das Lichtsetup muß man schon selbst liefern. Entweder als Fixed Function Setup (spielt eigentlich schon lange keine Rolle mehr) oder als entsprechenden Shadercode. Und auch die Schattierung ist kein Teil der API, die Shadowmap muß man schon selbst (unter Nutzung der API natürlich) berechnen.

6. Normalenvektoren werden pro Vertex hinterlegt (sonst gäbe es nur harte Kanten), nicht pro Dreieck. Die Normale der Fläche und damit die Einordnung in Frontface und Backface im Rasterizer (konkret: Triangle Setup) ist grundsätzlich implizit durch die drei Positionen der Vertices gegeben.

6. die zweite: "Direct3D kümmert sich von selbst darum, dass Kamera und Welt stets konsistent zueinander bleiben, d.h. subjektive Rotation und Translation der Objekte etwa bei einer Kamerafahrt berechnet die API selbst." Das ist falsch, wenn man nicht vom veralteten Fixed Function Setup ausgeht. Die komplette Matrixmultiplikation vor der Zuweisung zu einer Shaderkonstante oder, wenn Zwischenergebnisse für weitere Schritte nötig sind, die Multiplikation der Vektoren mit nicht zusammengefaßten Matrizen im Vertexshader muß der Programmierer schon selbst machen. Überhaupt hast du dich über Matrixmultiplikation komplett ausgeschwiegen.

In den Codebeispielen wird dann noch deutlich, daß du von Matrixmultiplikation selbst noch nichts gehört hast. Dazu noch die Sprache... wer sich mit 3D-Engines ernsthaft beschäftigen will, wird eh nicht um C++ rumkommen. Für manche anderen Sprachen erscheinen zwar mit gewisser Verzögerung Wrapper, aber C++ ist dort einfach das Mittel der Wahl.

Zu deinem Schlußwort noch eines: Raytracing ist kein Luftschluß, es wird schon seit zig Jahren erfolgreich eingesetzt. Zwar nicht zum Echtzeitrendering, aber eben dort, wo es sinnvoll ist. Es ist einfach eine andere Herangehensweise mit anderen Vor- und Nachteilen.

Das sind nichtmal alle Mängel, die da zu finden sind. Insgesamt macht dein Artikel einen weiten Bogen um Grafikengines, der Großteil beschäftigt sich bloß mit veralteten und teilweise falschen Vorstellungen eines Renderers. In dieser Form kann der Artikel mehr schaden als nutzen, indem Laien ihn lesen und so ein gefährliches Halbwissen aufbauen. Mein Ratschlag für dich ist, alles zu vergessen, was du über 3D-Grafik zu wissen glaubst, und nochmal sauber neu zu beginnen. Und dann bitte die Konzepte verinnerlichen und verstehen, nicht einfach irgendwelche Formeln abtippen bis was scheinbar funktionierendes rauskommt. Besorg dir das aktuelle DirectX SDK, die Tutorials sind dort eigentlich recht gut und auch die Grafikpipeline ist gut erklärt.

Gast

2010-03-17, 15:17:34

Nahaz

2010-03-17, 16:18:01

Nun der Chefredakteur sollte dazu vielleicht mal was sagen...
Ich werde das mal etwas "anschieben".

Allerdings muss ich auch mal eine Lanze für BAGZZlash brechen. Es war sein erster Artikel, es ist klar dass da noch nicht alles 100% rund läuft. Im Punkt Qualitätskontrolle haben wir aber sicher noch Optimierungspotential und das ist sicher nicht die Schuld von BAGZZlash.

Popeljoe

2010-03-17, 16:36:26

Pakko

2010-03-17, 16:56:03

Ich will den Artikel inhaltlich nicht kritisieren - dafür kenne ich mich auf dem Gebiet nicht gut genug aus.

Aber für eine Redaktion sollte es doch nicht der Anspruch sein, auf Artikel-Kritik mit der Argumentation "Wenn du des es besser kannst, dann schreib doch selber einen Artikel" zu reagieren. Die Argumentation kann man bei einem User-Artikel durchgehen lassen, aber nicht für ein kommerzielles Projekt wie es das 3DCenter ist (auch wenn der Autor vermutlich keine Entlohnung erhält).

Gast

2010-03-17, 17:16:39

Außerdem:
Klar hat dieses Forum ein gewaltiges Potential was das Wissen um die technischen Hintergründe von Grafikengines usw. angeht.
Nur stellt sich leider Keiner der Wissenden für einen Artikel zur Verfügung.
BAGZZlash wäre sicher der Erste, der "Hurra" schreien würde über entsprechende Unterstützung.
Nur kommt da Niemand!
Momentan gehen wir aus genau diesem Grund in Schönheit zugrunde und da ist es mir lieber, wenn BAGZZlash sich hinstellt und schreibt.
Jeder User, der meint es besser hinzukriegen, ist herzlichst eingeladen sich zu versuchen! ;)

Vielleicht sollte ich mich dann mal für einen Artikel über den Aufbau und die Architektur einer GPU melden. Ich habe zwar keine Ahnung davon, aber die scheint ja auch nicht mehr notwendig für die Veröffentlichung auf dem 3DCenter zu sein. Da es dann außerdem mein erster Artikel ist, macht es ja ohnehin nichts.

Ich kann ehrlich gesagt kaum glauben, dass kein einziger der 3D-Gurus intern mal auf den Artikel geschaut hat und mal Verbesserungsvorschläge gebracht hat.

Klingone mit Klampfe

2010-03-17, 20:23:16

Ich kann ehrlich gesagt kaum glauben, dass kein einziger der 3D-Gurus intern mal auf den Artikel geschaut hat und mal Verbesserungsvorschläge gebracht hat.

Wer soll denn das sein? Außer Coda ist von der alten Garde keiner mehr übrig.

Robbson

2010-03-17, 20:45:38

Wer soll denn das sein? Außer Coda ist von der alten Garde keiner mehr übrig.

Kann ich mir schwer vorstellen, wie diese Seite zeigt:
http://www.3dcenter.org/impressum/team

Und die stets kompetenten täglichen News dürften ja ebenso von jemanden geschrieben werden und stammen nicht von Geisterhand.

Gast

2010-03-17, 21:05:10

Wer soll denn das sein? Außer Coda ist von der alten Garde keiner mehr übrig.

Wie sieht es mit Exxtreme aus? Er trägt ebenfalls den Titel, applaudiert jedoch beschämenderweise zum Artikel (vielleicht war er jedoch auch nur so gemein und meinte, dsas die Screenshots das einzig Gute am Artikel sind X-D), Aths ist meines Wissens doch ebenfalls noch aktiv, ebenso Demirug. Da hätte man wirklich nicht mal kurz an die Türe klopfen können und mal freundlich fragen ob das so okay ist? Niemand verlangt ja von ihnen den Artikel umzuschreiben und großen Zeitdruck kann es ja auch keinen gegeben haben, schließlich steht kein Sponsor dahinter. War der Gedanke also wirklich "besser sowas, als gar keinen Artikel"? All die Jahre gings ja auch ohne. Stattdessen erbarmt sich Neomi, welcher ebenfalls kein unbeschriebenes Blatt ist, den Artikel hier öffentlich sorgfältig zu analysieren und zu korrigieren. Mehr als ich überhaupt erwartet hätte. Trotzdem gab es keinen Dank oder eine sonstige Reaktion. Für mich wäre das selbst noch frustrierender, als den Artikel zu lesen.

Ich mein, wie will man das 3DC so noch ernst nehmen? Wäre der Artikel bei Computerbase erschienen, dann wäre dieses Forum hier garantiert in Gelächter ausgebrochen und man hätte den Artikel Wort für Wort in der Luft zerrissen.

Und Pakko kann ich ebenfalls nur zustimmen. Das hier ist kein Kindergarten, wo man Punkte für den Versuch bekommt. Sowas schadet einfach der Reputation des 3DC und am Ende wird dann geweint, dass keiner der Hersteller mal eine Graka, CPU oder ein Board für einen Test sponsort.

Wie ich bereits in Beitrag #8 geschrieben habe, ist die Idee wirklich lobenswert, aber das ging gründlich in die Hose und der Artikel sollte schleunigst verschwinden.

Black-Scorpion

2010-03-17, 21:49:57

Kann ich mir schwer vorstellen, wie diese Seite zeigt:
http://www.3dcenter.org/impressum/team

Und die stets kompetenten täglichen News dürften ja ebenso von jemanden geschrieben werden und stammen nicht von Geisterhand.
Afaik sind die News allein Leos Revier.

Leonidas

2010-03-18, 00:49:34

Dass sich noch keiner der Beteiligten zu diesem Desaster geäußert hat, spricht ja wohl Bände. Der "Artikel" steht immer noch in seiner Urfassung auf der Hauptseite und keinen scheint es zu kümmern. Ich mein, hier wurde sachliche Kritik zum Artikel geäußert und es wird nicht einmal kommentiert, geschweige denn drauf eingegangen. Das kann doch nun wirklich nicht den Qualitätsstandards des 3DCenters entsprechen.

Ich stehe hier ehrlicherweise ein wenig zwischen den Stühlen. Der Artikel stand mehr als drei Wochen im internen Bereich und hatte dort auch schon seine Kritik wegbekommen. Allerdings - und das ist der entscheidende Punkt - fehlten klar Impulse zu seiner Verbesserung. Ich muß klar sagen, daß wir zwar gut im kritisieren sind, aber wenig dazu getan haben, den Artikel zu verbessern, bevor er dann rausging.

Und das ärgert mich maßlos. Hier hätten wir wirklich besser sein können. Es war aber genügend Zeit, um den Artikel vorab zu verbessern. Insofern ist einiges der aktuellen Kritik schon irgendwie seltsam - da wurde viel Zeit in die Kritik gesteckt, welche vorher nicht in die Verbesserung des Artikels gesteckt wurde. Wie gesagt - ich ärgere mich maßlos.

Ich kann nur alle ermahnen, es das nächste Mal besser zu machen. Der interne Bereich ist eigentlich genau dafür da.

Frage: Sollte der Artikel wirklich runter von der Startseite? Oder gar aus dem Artikelarchiv raus? Letzteres gefällt mir weniger, 3DC steht auch zu seinen Fehlern. Wenn er nur von der Startseite runtersoll, wäre das wohl ok.

Robbson

2010-03-18, 00:57:54

Frage: Sollte der Artikel wirklich runter von der Startseite? Oder gar aus dem Artikelarchiv raus? Letzteres gefällt mir weniger, 3DC steht auch zu seinen Fehlern. Wenn er nur von der Startseite runtersoll, wäre das wohl ok.

Ich würde sagen, der Artikel verschwindet erstmal ganz und erscheint nach einer Überarbeitung wieder auf der Titelseite. Besser einen Fehler gutmachen und den Schaden begrenzen, als zusehen, wie sich zukünftig Leute darüber aufregen, die im Archiv herumstöbern... schließlich finden sich da ja auch die wahren Schätze. ;-)

Da haben am Ende alle etwas 'von: Der Artikelschreiber, die Leser und natürlich das 3DC.

Witzigerweise hat die Sache dazu geführt, daß ich mir erstmalig ernsthaft darüber Gedanken gemacht habe, selbst einmal einen Artikel fürs 3DC zu schreiben... natürlich nicht ohne die Revision der Experten und da gibt es hier viele.

Robbson

mapel110

2010-03-18, 00:59:20

Wie wärs mit einem Nachtrag, das bald eine Erweiterung/Korrektur zu dem Artikel erscheinen wird?!

Leonidas

2010-03-18, 01:13:24

Schaffen wir es, denn eine Erweiterung/Korrektur für diesen Artikel auf die Beine zu stellen?

Coda

2010-03-18, 01:18:33

Ich kann ehrlich gesagt kaum glauben, dass kein einziger der 3D-Gurus intern mal auf den Artikel geschaut hat und mal Verbesserungsvorschläge gebracht hat.
Glaub mir, ich habe einiges kritisiert an dem Artikel. Bin hier auch vor vollendete Tatsachen gestellt worden.

Gast

2010-03-18, 01:20:53

Wie wärs mit einem Nachtrag, das bald eine Erweiterung/Korrektur zu dem Artikel erscheinen wird?!
http://i729.photobucket.com/albums/ww300/seanachie/NotSureIfSerious.jpg

Schaffen wir es, denn eine Erweiterung/Korrektur für diesen Artikel auf die Beine zu stellen?

Das ist eine wirklich gute Frage. Mit einem anderen Autor könnte es durchaus etwas werden, denn wenn man auf Neomis Meinung Wert legt (schießlich ist/war er Spieleentwickler), dann ...

Mein Ratschlag für dich ist, alles zu vergessen, was du über 3D-Grafik zu wissen glaubst, und nochmal sauber neu zu beginnen.

wird das mit dem aktuellen nichts.

Robbson

2010-03-18, 01:39:19

Da gerade vom Artikelarchiv die Rede war, konnte ich es mir nicht nehmen, dort ein wenig herumzustöbern. Dummerweise befinden sich die besten Artikel im Archiv der alten Seite und nicht im Archiv der aktuellen, da muß man erstmal drauf kommen (ist wie mit der Kirche um's Dorf: Ein Archiv im Archiv).

Darunter befinden sich viele theoretische, d.h. zeitlose Abhandlungen, etwa zum Multisample-AA oder HDR Rendering, die man ohne oder mit geringstmöglichem Bearbeitungsaufwand auch heute bedenkenlos vorzeigen kann. Solche Sachen gehören auf die Titelseite, idealerweise mit einem passenden Symbolbild dazu, das etwa bei Neuankömmlingen das Interesse am Thema und dem 3DC wecken könnte. Oder ist die Philosophie beim 3DC doch eine ganz andere?

Und immerwieder aktuell: im Forum gibt es so viele gute Beiträge und Diskussionen, aus denen man tolle Artikel zaubern könnte, die dann auf der Titelseite entsprechend der Zugriffszahlen ausgestellt sind (Motivation für Artikelschreiber)...

:smile:

Robbson.

Robbson

2010-03-18, 02:07:51

Schaffen wir es, denn eine Erweiterung/Korrektur für diesen Artikel auf die Beine zu stellen?

Historischer Abriss von 2D bis 3D in Games, 3D Grundlagen, Lineare Algebra, der Bezug zu heute und auch noch die Programmbeispiele zum selbermachen... das alles zusammen in einem Artikel? Die Frage ist wohl vielmehr, was man besser herauswirft und auf welchen Themenkomplex man sich konzentriert.

Oder man gibt wirklich nur einen allgemeinen (aber vollständigen oder zumindest gleichmäßig verteilten) Überblick, verzichtet dabei auf Quellcode, Matrizen und überflüssige Details.

Robbson

Baalzamon

2010-03-18, 17:15:22

Also nach dem Lesen der Artikelüberschrift hatte ich mich schon richtig gefreut: Endlich 'mal wieder ein interessanter Artikel beim 3D-Center und keiner über LowCost-Grafikkarten oder Computer-Peripherie.
Und dann auch noch so ein komplexes Thema: "die Funktionsweise heutiger 3D Grafik Engines". Da war mir klar: aths & Co laufen zur Hochform auf.

Ich dachte mir: genial! Mehr Erfahren über aktuelles etwa im Bereich Scene Management und Occlusion Culling (Octree, dPVS, Multi-Scenegraphen, umbra, ...), GPU-CPU Limitierungen, DrawCall-Minimizing, LOD, eventuell auch moderne Shader, LOD, Tessellation, RT Shadows usw. auf mindestens 10 Seiten.

Und dann das: Grottig dargebotenes Mathematik-Grundwissen aus der 8. Klasse kombiniert mit den Grundlagen zur 3D Grafik aus den 80er Jahren... :confused:

Möglicherweise werdet Ihr mich jetzt für arrogant halten, aber ich hoffe doch sehr, daß dieser Artikel nur als Aprilscherz gedacht war und etwas verfrüht auf dem Server gelandet ist. Ich kann mir schwer vorstellen, daß bei den Betreibern vom 3DCenter solch ein fehlerbehaftetes, miserabel formuliertes und lustlos geschriebenes Werk (siehe auch Kritik von huhu) 'mal eben durchgewunken wird. Und vor allem: Das Niveau passt überhaupt nicht zum 3DCenter, DER Community zu 3D & Co im deutschsprachigen Raum.

Ich hätte ja nichts gegen einen Artikel mit den Grundlagen zur allgemeinen 3D-Grafik (und mit einer anderen Überschrift!), aber selbst dem wird der Artikel nicht gerecht, da reicht in der Tat eine Linksammlung zur Wikipedia und einigen anderen Ressourcen im Netz... oder einem guten Buch.

Der Artikel erweckt darüber hinaus den Eindruck, der Autor hätte nach Fertigstellung der ersten Seite keine Lust mehr gehabt, sodaß alle anderen interessanten Themen nur noch mit müden Stichpunkten behandelt wurden: Texturierung, Hidden Surface Removal, Beleuchtung/Schattierung, etc. ... nach dem Motto: Gut daß ich's wenigstens erwähnt habe!

Insgesamt scheint mir der Autor den Unterschied zwischen "Grundlagen von 3D" und "Grundlagen von 3D Grafik-Engines" nicht zu kennen. Letztere bauen heute auf APIs wie OpenGL und Direct3D auf und müssen sich längst nicht mehr um die Rasterisation-Basics kümmern, sondern um darauf aufbauende Problematiken (siehe oben).
Von daher ist der Artikel völlig am Thema vorbei: 6, setzen!

Robbson
Dem kann ich nur vollkommen zustimmen. Du hast viele Punkte die auch mir aufgestossen sind, schön auf den Punkt gebracht. Auch ich habe mich zuerst gefreut: Endlich mal eine Zusammenfassung was heutige 3D-Engines leisten (müssen).

Aber der Artikel ist weder Fisch noch Fleisch. Auch gewinne ich beim lesen den Eindruck, das der Artikelschreiber leider nicht wirklich weiss worüber er da schreibt, sonder zusammengetragenes Wissn aus Wikipedia wiedergibt, ohne selber die Zusammenhänge verstanden zu haben, oder wenn er sie verstanden hat, sie nur unzureichend miteinander in Verbindung bringen und erklären kann.

Ich weiss nicht so recht. Sicherlich muss man nicht immer den Maßstab einer wissentschaftlichen (oder universitären) Arbeit an diese Artikel stellen, aber mMn werden hier auch grundlegende Dinge nicht beachtet (zB am Anfang eine kurzen Überblick geben womit sich der Artikel beschäftigt, am Ende eine Zusammenfassung der Ergebnisse usw.).

Ich kann mich dem Tenor in diesem Thread nur anschliessen: Dieser Artikel erreicht leider nicht das Niveau das ich vom 3D-Center erwarten würde. :(

Gast

2010-03-19, 14:16:05

Ich möchte mal anmerken, dass mir GRADE die VB Quellcodes sehr gut gefallen haben.

Diesen Codes kann ich fast mehr entnehmen als dem Artikel selber.

Die Funktion PrepRotMatrix würde mich noch interessieren.

del_4901

2010-03-19, 23:32:46

Ich muss ehrlich sagen, das iach auch ein bischen erschrocken von demArtikel war. Und man kann das Thema glaube ich auch gar nicht so allgemein anfassen, wenn man es gut machen moechte. Das ist ja schon der Stoff fuer eine komplette Artikelserie. Ich denke man hat sich einfach mit diesem doch sehr allgemeinen Thema total ueberhoben, und das laesst sich jetzt auch nur sehr schlecht nacharbeiten.

Nahaz

2010-03-20, 13:47:13

Vor einigen Tagen hatte ich in diesem Thread Leonidas öffentlich scharf kritisiert. Die besagten Posts habe ich mittlerweile gelöscht da ich eingesehen habe dass mein Verhalten falsch war. Letztlich kann mein Verhalten als Musterbeispiel gelten wie man sich in der Öffentlichkeit nicht verhalten sollte. Bei Leo selbst habe ich mich bereits entschuldigt. Da wir ein sehr gutes persönliches Verhältnis pflegen, hat er diese auch angenommen. Das nur zur Information falls sich jemand fragen sollte warum hier Posts fehlen.

RavenTS

2010-04-11, 14:40:30

Nun sind gute 4 Wochen vergangen. Wird bei diesem Artikel noch irgendwas passieren, läuft da eine Korrektur im Hintergrund oder wie sieht es aus?

Aus der Sicht eines einfachen Forenusers/Lesers ging da bei der Vorbereitung mal wieder etwas schief, nach Veröffentlichung gab es einige, weitgehend konstruktive Kritik, aber dann scheint nichts mehr passiert zu sein...

Gast

2010-05-04, 21:50:58

Wie sieht es nun mit dem Artikel aus? Kommt da noch was?