Diskussion:Grafik-Engine

Diese Diskussionsseite dient dazu, Verbesserungen am Artikel „Grafik-Engine“ zu besprechen. Persönliche Betrachtungen zum Thema gehören nicht hierher. Für allgemeine Wissensfragen gibt es die Auskunft.

Füge neue Diskussionsthemen unten an:

Klicke auf Abschnitt hinzufügen, um ein neues Diskussionsthema zu beginnen.

• Diskussionsregeln
• Hilfe zu Diskussionsseiten
• Sei sachlich und freundlich!
• Greife niemanden persönlich an!
• Geh von guten Absichten aus.

3D-Engine

Ich bin dafür, die zwei Artikel zusammenzulegen. Was denkt ihr? --Dkoelle 10:43, 18. Sep 2004 (CEST)

Ich unterstütze diesen Vorschlag. Ich würde dafür plädieren den Inhalt von 3D-Engine in Grafik-Engine zu integrieren, da Grafik-Engine der allgemeinere Begriff ist und dann ne Umleitung aus 3D-Engine auf Grafik-Engine machen. (Ich hoffe die Diskussion wird mal von noch mehr Leuten hier gelesen). Arnomane 15:35, 18. Sep 2004 (CEST)

Nachdem sich ja von den Leuten die sich auskennen keiner bereit erklärt hat das zu machen habe ich es schlussendlich zuammengefügt. Ist also erledigt. Arnomane 21:49, 26. Jan 2005 (CET)

Die Liste der Autoren des eingefügten Artikels 3D-Engine kann hier gefunden werden: [1]. -- Arnomane 21:46, 26. Jan 2005 (CET)

Inhaltliche Kritik

Hallo,

Was ist eine Grafik-Engine? Eine Grafikmaschine oder ein Grafikmotor? Ist es ein Programm oder ein Computerbauteil? Ich finden den Begriff "Engine" im Zusammenhang mit Software ziemlich erklärungsbedürftig und einem Laien müssen meine zugegebenermaßen etwas provokanten Fragen in den Sinn kommen. Leider war die bisherige Begriffserklärung dieses Artikels ziemlich nichtssagend und nennt nur weitere kryptische Begriffe wie Game-Engine. Da ich mich (obwohl computertechnisch doch einigermaßen bewandert) nicht für 3D-Computerspiele interessiere und folglich auch kein Experte auf diesem Gebiet bin, kann meine Begriffserklärung durchaus fehlerhaft sein. Ich plädiere jedoch dafür, unabhängig ob meine Erklärung richtig oder falsch ist den Begriff Grafik-Engine mit klaren deutschen Worten zu erklären (bitte nicht mit dem Argument kommen: "Das klingt im Deutschen so scheiße, darum verwenden wir lieber coole kryptische englische Begriffe.").

Des Weiteren ist der Artikel zur Zeit leider ziemlich hardwarelastig und erklärt zur eigentlichen Software so gut wie garnichts. Ein kompetenter Gamer kann da sicher mehr zu beitragen. Auch fehlt der Aspekt Virtuelle Realität ganz. Evtl. könnten man ja auch noch etwas mehr zu anderer Hardware die nicht Intel-PC-basiert ist sagen, wie Spielekonsolen und Hardware, wie sie insbesondere im Bereich der Virtuellen Realtität verwendet wird.

Arnomane 23:31, 25. Jul 2004 (CEST)

Unter der Überschrift "Funktion" geht der Artikel auf die 3D-Darstellung ein und beschreibt die Darstellung in einem 3D-Raum mit Hilfe der x-, y- und z-Achse. Dabei stellt der Artikel das so dar, als wäre diese Ausrichtung der Achsen festgelegt und bei jeder Engine identisch. Dem ist in der Realität aber nicht so. Bei manchen zeigt die positive Z-Achse z.B. nicht "in" den Bildschirm hinein, sondern in die andere Richtung. Bei wieder anderen ist y und z anders, also z die vertikale Ausrichtung, und y die "in den Bildschirm hineingehende". Hier ewird allerdings fest von einem "linkshändigen" Koordinatensysstem mit Z als "Tiefe" ausgegangen. Das erweckt den Eindruck, als sei das bei allen Engines der Fall, oder als müsste das aus irgendeinem Grunde so sein. Den Teil sollte man meiner Menung nach also entweder allgemeingültig gestalten, oder aber gar nicht darauf eingehen. Letzteres fände ich angebrachter, da es der Engine jeweils selber überlassen ist, wie sie was darstellt oder welches Korodinatensystem sie verwendet.

Relation der Integration von Freien Entwickler-Portalen in Wikipedia's

Ich freue mich das Ihr das Wikipedia auf einen informativ hochwertigen Stand bringt. Ich möchte
euch jedoch bitten, die von Anderen Usern als Relevant definierten Einträge nicht ohne Diskussion,
geschweige den ohne vorheriges genaues Studieren der Webinhalte, aus einem Wikipedia löscht.
Ein Wikipedia ist meines erachtens ein Sammelknoten aller Informationen, gut strukturiert und
gegliedert, übersichtlich veröffentlicht in Wikipedia-Artikeln.
Ich bitte euch daher das Link-Outdating des exWARE-Programmierer Portals, zurückzunehmen.
Bei Fragen, anregungen & Kritik mail mir bitte, matthias.kaschubowski@gmx.de

Gruß Exelsior.

---

Ich wäre sehr Dankbar wenn es auch ein paar Literaturhinweise zu den entstprechenden Engines gäbe.

---

In Wikipedia heißt es grundsätzlich erstmal sei mutig. Nachdem du den Weblink eingefügt hast (ohne Rückfrage, da das ja zunächst erstmal nach dem Prinzip nicht nötig ist) habe ich ihn entfernt, weil mir nach einigem Stöbern auf der Seite (die ich durchaus gut gemacht finde und auch Respekt vor der Arbeit habe, da ich selber nicht so eine schöne Seite basteln könnte) nicht klar ersichtlich wurde, ob diese tatsächlich das beste deutschsprachige Portal zu diesem Thema ist. Ich habe nach flüchtigem Blick nicht so viel Communityleben gesehen, es sah mir alles sehr nach Aufbauphase aus. Zumdem fand ich keine über das Thema wirklich hinausgehenden Infos dort, die nicht schon auf den Weblinks der einzelnen Softwareprojekte wären. Ich habe daher nach demselben Sei-mutig-Prinzip den Weblink entfernt. Da ja nun eine Meinungsverschiedenheit vorliegt ist jetzt und nicht vorher eine Diskussion angebracht.

Zweitens ist Wikipedia kein Linkverzeichnis (Ein offenes Linkverzeichnis ist bspw. http://dmoz.org ). Das heißt maximal 5 Weblinks in Artikeln und in sehr gut begründeten Ausnahmen (wenn die Weblinks die Quellen des Artikels sind) mal mehr. Wir wollen nicht einfach alle Informationen verlinken, sondern die Informationen selber in den Artikeln in der Wikipedia haben.

Und da wäre ich auch schon beim wunden Punkt. Dieser Artikel braucht dringend Verbesserung von Leuten die Ahnung von der Materie haben (zudem existiert ein Doppelartikel, was auch behoben werden muss). Und ich nehme mal an, dass du vom Fach bist. Du bist also herzlich eingeladen hier mitzuwirken. Und ein schlechter Artikel der auf eine Seite von dir verweist kann nun wirklich nicht in deinem Interesse sein.

Außerdem ist man in Wikipedia generell aus naheliegenden Gründen skeptisch, wenn der Homepageersteller selber den Weblink auf seine Seite in Wikipedia setzt, da es dann doch sehr wahrscheinlich ist, dass dies keine objektive Auswahl darstellt.

Also alles in allem: Seh es nicht als persönlichen Angriff auf deine harte Arbeit mit der Webseite. Ich würde mich freuen, dich an den Artikeln zum Thema Computergrafik als Autor zu sehen. ich hoffe du liest dies hier, da ich es nicht für sinnvoll erachte dieses privat per Email zu erörtern, um den Anlauf und die Argumente transparent für alle darzustellen. Arnomane

Rendern

der begriff grafik-engine ist sehr allgemein. es meint verschiedenste engines, die alle 3dimensionale bilder errechnen. mal schneller, mal langsamer ^^.

ich habe den part mit den engines in besonders filmen mal überarbeitet. da waren ein paar sachen lückig. "maja" (!MAYA!). Und die Programme rendern das bild nicht, sondern meist speziell integrierte software-render wie mental ray. dazu kommt noch ein link. das thema ist schon komplexer ;)

Meilensteine der 3D-Grafik-Engines

können andere studios die engines von Freelancer und Morrowind wirklich lizenzieren? ich bild' mir ein, nicht... außerdem wundere ich mich, dass Criterion's RenderWare nicht aufgeführt ist. ich würd' sie auch gerne hinzufügen, finde aber keine jahreszahl, wann sie das erste mal genutzt wurde... –jello ¿? 19:46, 14. Mai 2005 (CEST)

• Freelancer ist eine eigens entwickelte Engine, Morrowind basiert wie auch Gothic I+II auf der Gamebryo Engine --Olliwood 21:08, 5. Jun 2005 (CEST)

Hmm, stehen unter "Meilensteine der 3D-Grafik-Engines" nun wirklich die Meilensteine der 3D-Engines oder die bekanntesten Spiele? Den Schritt von Doom zu Doom2 würde ich nicht als Meilenstein in der Geschichte der 3D-Engines sehen, ebenso wie von Quake2 zu Quake3. Wo sind dort die Meilensteine? Unter Meilensteine würde ich verstehen, wenn es sich wirklich um was neues, revolutionäres, etc handelt. Das sehe ich bei den meissten aufgeführten aber nicht. Wo ist bei Doom2 z.b. der Meilenstein im Vergleich zu Doom?

Ich sehe jetzt erst die Kommentare, ich habe bereits Doom II und Freelancer entfernt. Eigentlich könnten da noch ein paar raus, auch Doom, da es zwar als Spiel und Engine ein großer Erfolg war, aber technisch war es im Vergleich zur früheren Ultima-Underworld-Engine ein Rückschritt. Ebenso sind ein paar spätere Engines nur leicht verbesserte Versionen (mehr Polygone etc.) die kaum unter den Begriff "Meilenstein" fallen. -- Darklock 09:44, 29. Mai 2006 (CEST)

Polygone und Spieleengines

Ich bin mir ziemlich sicher das Die Engines von Spielen nur dreiseitige Polygone darstellen können. Sollte aufgenommen werden, wenn sich es wirklich stimmt. Kenne nämlich kein Spiel das vier oder mehrseiteige unterstützt. Tobias Rütten

Du meinst vermutlich Polygone mit drei Ecken, bzw 3 Verticen (müsste das Plural von Vertex sein. Keine Ahnng wie das deutsche Wort dazu ist), also kurz: Dreiecke :) Diese Limitierung kommt nicht von den 3D-Engines, sondern von der (aktuellen) 3D-Hardware, und bezieht sich eigentlich auch nur auf texturierte Polygone (da Dreiecke in einem 3D-Raum immer eine gerade Fläche, also niemals gebogen, sind). Bei z.B. nicht texturierten Polygonen (z.B. reiner Liniendarstellung) spielt das keine Rolle. Sicherlich hast Du natürlich Recht, dass heutzutage eigentlich immer diese Art der Polygone verwendet werden. Aber was ist mit den alten 3D-Engines, wie z.B. die damals in Doom, Elite, Duke Nukem, etc verwenmdet wurden? Wenn man nun das von Dir vorgschlagene mit den Dreiecken in den Artikel einbaut, dann verliert er meiner Meinng nach an Allgemeingültigkeit, weil er sch zu sehr auf aktuelle/heutige Verfahren beschränken würde. -- 80.141.248.160 11:48, 30. Nov 2005 (CEST)

Auch aktuellere Engines benutzen ab und an viereckige Polygone, in Die Siedler 3/4 (oder war es 5? Ich werde alt) war das z. B. meines Wissens nach der Fall. -- Darklock 10:03, 29. Mai 2006 (CEST)

Plural Vertex: "Vertex" -> "Vertizes" als Anlehnung an die Schreibweise "Index" -> "Indizes" (david scherfgen / 3D-Spiele-Prog. mit DirectX9 und C++)

Überarbeitung dringend notwendig

Mir sind einige Passagen aufgefallen, die eine Überarbeitung gut vertragen könnten, leider habe ich im Moment kaum Zeit dazu. Die Zusammenlegung der beiden Artikeln hat auch dazu geführt, dass viele Informationen doppelt im Artikel vorhanden sind

Die Achsen im Visuellen

Den Sinn der "Abbildung" erschließt sich mir nicht, weil:

• im Text gar nicht darauf eingegangen wird, dass die dreidimensionale Welt meistens mithilfe ebendieser Achsen dargestellt wird.
• in Bezug auf die verschiedenen verwendeten Kordinatensysteme (LHS und RHS) höchstens Verwirrung stiftet.

Die Grafikengines anderer Spiele bzw. Programmen allgemein sind hingegen so trivial, dass sie im Grunde keine Rolle spielen und man sie höchstens mit einer Game Engine in Verbindung bringt.

Hier ist mir nicht klar, was damit gemeint ist.

Die Abschnitte Film und Spiel müssten komplett überarbeitet werden, neben dem teils grauenhaften Stil wiederholt sich hier fast jeder Satz in irgendeiner Form, der Absatz "Unterschiede Film und Spiel" ist eigentlich die Wiederholung der in den oberen Absätzen vorweggenommenen Informationen.

Im Bereich "Meilensteine der 3D-Grafik-Engines" fehlt meiner Ansicht nach die Begründung, warum die Engines Meilensteine verkörpern.

Wenn der Bereich "Kommerzielle & Open-Source Engines" beibehalten wird, dann gehört meiner Meinung nach mindestens ein "kein Anspruch auf Vollständigkeit"-Hinweis hinein. Ist mit zFXc-Engine die ZFXCE (http://zfxce.sourceforge.net/) gemeint? Der Link zu der Axiom-Engine zeigt auf eine information.com-Seite.

Der Absatz "Schnittstellen für Grafik-Engines" ist auch Bestenfalls eine wirre Gedankensammlung.

--Aule 15:24, 20. Feb 2006 (CET)

Doom 3 Engine umbenannt

Im letzten Abschnitt dieses Artikels http://www.gamezone.de/news_detail.asp?nid=53254 wird erwähnt, das die Doom 3 Engine nun id tech 4 genannt wird. vielleicht sollte dies in der tabelle in klammern erwähnt werden

Beschreibung ungenau

die verwendete terminologie im einleitungsteil ist äußerst ungenau. für mich tritt dort nicht genau hervor, was eine grafik engine wirklich ist (nämlich eine höhere abstraktionsebene zum ansprechen der grafikhardware, die z.b. entitys etc kennt - die hardware kennt das nicht). es wäre gut dort mehr fachterminologie zu verwenden und die beschreibung mehr auf den punkt zu bringen; einmal so, dass "novizen" verstehen, worum es geht und vielleicht auch so, das etwas fortgeschrittene programmierer auch etwas damit anfangen können. --Fredfeuerstein 21:38, 10. Aug. 2008 (CEST)

Unterschiede Film und Spiel - Anzahl der Bilder pro Sekunde

Zu: "Ein Bild (1 Sekunde ~24 Bilder) wird beim Film bis zu 90 Stunden lang berechnet, für das Spiel müssen hingegen 24 Bilder in einer Sekunde berechnet werden."

Grundsätzlich ist es richtig, dass bei einem Spiel (oder anderen Grafikvisualisierungen, die den Anspruch 'Echtzeit' mit sich führen) 24 Bilder pro Sekunde berechnet werden müssen. Mindestens 24 Bilder pro Sekunde. Richtig flüssig (das Auge empfindet die Bewegung als zusammenhängend) wird es zumeist erst ab Bildwiederholraten von 60hz - je nach Bewegung im Bild. Eine höhere Frequenz wird vom Auge durchaus wahrgenommen, TFT-Monitore haben aber zumeist eine max. Bildwiederholrate von 60hz. Das Problem ist die fehlende Bewegungsunschärfe, die durch Filmaufnahmen festgehalten wird (Linsenöffnung, Belichtung des Bildes während ein Objekt in Bewegung ist). Eine mit dem Computer in Echtzeit gerenderte Bildfolge besteht aus Einzelbildern die jeweils gestochen scharf sind. Ist dann die Bewegung im Verhältnis zur Framerate zu hoch, nimmt das Auge sie als ruckartige Bewegung wahr.

Ich denke, das könnte man mit in diesen Artikel einarbeiten, da viele Computerspieler oft eine Disukussion über zu geringe FPS führen. Als Quelle könnte folgender Artikel dienen: http://www.daniele.ch/school/30vs60/30vs60_1.html

-- pronz (01:56, 19. Jun. 2009 (CEST), Datum/Uhrzeit nachträglich eingefügt, siehe Hilfe:Signatur)

Link zu Render Engine

Ist der link zur Render Engine überhaupt sinnvoll? Er führt nur zu einer Liste von Techniken die eine Renderengine einsezten: HTML, DTP und die 3D- bzw Grafikengine. Erste beiden haben nix mit der Grafikengine zu tun die in Filmen und Spielen eingesetzt werden, somit führt der Link schlussendlich wieder zur anfänglichen Seite. Ich hoff ihr versteht was ich meine :) (nicht signierter Beitrag von 192.132.229.1 (Diskussion) 14:58, 11. Nov. 2010 (CET))

Welche Grafik-Engines arbeiten mit NURBS?

Guten Tag,

durch diesen Artikel mit dem Link "NURBS-Engine" bin ich hier gelandet, nur finde ich den Begriff NURBS hier nirgends erwähnt. Nun frage ich mich, ob es seitens der Hersteller darüber keine Auskunft gibt, oder ob inzwischen sowieso praktisch alle mit NURBS arbeiten und es deshalb nicht weiter erwähnenswert ist. Gruß -- Friz 77.186.144.172 09:45, 13. Feb. 2011 (CET)

Man braucht nur Strahlensatz und Trigonometrie

Zunächst mal muß man verstehen: wie wird Licht gestreut und wie wird es vom Auge gesiebt, sodaß das Abbild einer Zentralprojektion entspricht? Also: Das Licht breitet sich in der Regel punktförmig von der Lichtquelle (etwa einer Glühbirne) aus, das heißt, man denkt es sich so, daß die Photonen als mehrere Striche mit sämtlichen Winkeln von der Lichtquelle wegschießen. Treffen die Photonen auf einen Punkt im Raum, wird es von diesem ebenfalls punktförmig weggestreut. Ein beleuchtetes Objekt im Raum, das aus mehreren gedachten Punkten besteht, hat aber Polarisations- und Absorbtionseigenschaften. In der Regel wird das meiste Licht in die Richtung reflektiert, die dem Lichteinfallswinkel entspricht. Das nennt man Polarisationseigenschaften; die spielen aber nur eine untergeordnete Rolle. Wichtiger ist schon, zu wissen, daß die Rückstreuung vom Objektpunkt so erfolgt, daß das Licht das Objekt nicht durchdringen kann. Es wird also in der Regel nur in die dem Lichteinfallsstrahl zugewandte Seite reflektiert. Bei Glas gibt es zwar Brechungsphänomene, die optisch was hermachen können, aber dennoch extrem aufwendig zu berechnen sind und daher auch nur eine untergeordnete Rolle spielen. Die Farb- und Helligkeitswerte des Lichtquellenlichts werden bei Rückstreuung von einem Objektpunkt mit dessen Reflektionseigenschaften verrechnet. Hätte man etwa eine graue Fläche, die nur die halbe Lichtmenge reflektiert, könnte man Weiß ( R:255, G:255, B:255) mit 0,5 multiplizieren, wodurch sich dann Grau ( R:128, G:128, B:128) ergeben würde. Man kann das auch mit allen RGB-Kanälen getrennt machen, wodurch dann der Objektpixel einen Farbwert erhält. Ob man die realen Reflexionseigenschaften wirklich mit einer simplen Multiplikation nachbilden kann, oder ob die Sache sich nicht vielleicht doch eher logarithmisch verhält, spielt nur eine untergeordnete Rolle. Die Rückstreuung von mehreren Objekten untereinander auf sich gegenseitig ( beispielsweise von einer weißen Wand auf eine der Lichtquelle abgewandten Wand) kann man in der Praxis ebenfalls nicht berechnen. Was im Auge geschieht, damit das Objekt oder präziser der Objektpunkt bei zunehmender Entfernung kleingestaucht und in die Bildmitte gepfercht erscheint, kann man sich mit einer Lochkamera bzw. Camera Obscura ebenfalls leicht veranschaulichen. Vor der Projektionsfläche sei eine Dunkelkammer und auf der Fläche vor der Projektionsfläche in der Mitte ein Loch, durch das Licht eintritt. Somit fungiert die Fläche vor der Projektionsfläche als Winkelsieb, das heißt, von jedem Objektpunkt kommen nur die rückgestreuten Strahlen durch die Fläche mit dem Loch, die gemeinsam mit der relativen Position des Objektpunkts zum Loch in der Blende einen bestimmten Steigungswinkel besitzen, mit dem dann das einfallende Licht hinter der Blende vom Loch ausgehend auf die Projektionsfläche trifft. So simuliert man grob die Funktionsweise eines Auges. Man verwendet hierfür den Strahlensatz. Das heißt: das Objekt hätte X, Y und Z-Koordinaten und die Position des Brennpunkts, also des Lochs in der Blende, die Koordinaten X2, Y2 und Z2. Nun subtrahiert man X von X2 und teilt das Resultat durch Z Minus Z2. So erhält man den X-Steigungswinkel, der mit einem Skalierungsfaktor multipliziert zur X-Bildschirmmitte addiert wird und somit die X-Koordinate auf dem flachen Bildschirm ergibt. Dasselbe macht man mit den Y-Koordinaten der beiden Punkte und erhält den Y-Wert auf dem Screen. Es können selbstverständlich auch negative Werte herauskommen. Das Bild steht zwar auf dem Kopf, aber dann subtrahiert man sie eben von der Bildschirmmitte. Die Y-Koordinate im Grafikspeicher errechnet man übrigens dadurch, daß man sie einfach mit der X-Auflösung multipliziert. VGA-Modus 13h. Das waren noch Zeiten... Die Zentralprojektion hat in meinem Testprogramm tatsächlich gut funktioniert. Das Problem waren die Drehungen. Möchte man die Kamera bzw. das "virtuelle Auge" drehen, wäre das dasselbe, als würde man die Welt um den Brennpunkt drehen. Man multipliziert hierfür die "B- und C-Koordinaten" bei einer Drehung um die "A-Achse" mit irgendwelchen Sinus- oder Cosinus-Werten. Das heißt, die Koordinaten in der A-Ebene bleiben unverändert. Eigentlich müßte man das um alle drei Achsen nacheinander machen können, allerdings besteht hier ein krasses Verständnisproblem, weil die Drehungen nicht kommutativ sind. Das mutet paradox an. Das Paradoxon geht folgendermaßen: dreht man etwa einen Würfel erst 90 Grad um die X-Achse nach hinten und dann 90 Grad um die Z-Achse nach rechts, dann ist er hinterher anders gedreht, als würde man ihn erst 90 Grad um die Z-Achse nach rechts und dann 90 Grad um die X-Achse nach hinten drehen. Schaut man aber geradeaus und sieht unter sich den Boden und schaut erst senkrecht nach unten und dreht sich dann 90 Grad nach links, so befindet sich der Boden hinterher relativ zum Auge an derselben Stelle, als würde man sich erst um 90 Grad nach links drehen und dann senkrecht Richtung Boden schauen. Ich glaube, es liegt daran, daß man mit einem Computer nicht simultan um zwei Achsen drehen kann. Der kann das aufgrund physikalischer Einschränkungen nicht berechnen. Es verspult auf jeden Fall. Aber hoffentlich ist es egal... Nun geht es vor allem um Geschwindigkeit und um Organisation. Man könnte mit der Zentralprojektion etwa gedrehte Kacheln oder Sprites projizieren. Man kann, und das ist eine bessere Idee, aber auch jedem Objekt eine Gruppe aus Pixeln mit X-, Y- und Z-Koordinate und einem Farbwert spendieren, die fortlaufend und gemeinsam in einen Puffer im RAM geschrieben werden, bevor sie projiziert werden. Dabei werden jeder Pixelgruppe gemeinsame einmalige relative X-, Y- und Z-Koordinaten zugewiesen, mit der sie in der Welt plaziert werden. Wegen der Drehungen einer Pixelgruppe denkt man sich einen Quader um die Pixelgruppe und betrachtet zu Optimierungszwecken nur dessen Kanten. Eine Idee besteht weiter darin, für dieselbe Objektdarstellung ebendiese Darstellung umskaliert mit einer unterschiedlichen Anzahl Pixel mehrfach als auswählbare Pixelgruppe in einem Puffer abzulegen. Die Auswahl der konkreten Pixelgruppe für die jeweilige Darstellung erfolgt anhand einer gepeilten Entfernung vom Brenn-, also Projektionspunkt. Sind die Objekte weiter vom Brennpunkt entfernt, wird eine niedriger aufgelöste Pixelgruppe ausgewählt. So können sehr viele weiter entfernte Objekte dargestellt werden, ohne daß der Rechner dabei in die Knie geht. Weiterhin gibt es ein Problem mit sich überschneidenden Objekten. Man kann dieses Problem so lösen, daß jeder zu jeder Koordinate auf dem flachen Screen der Z-Wert des dort zuletzt hinprojizierten Pixels gespeichert wird (etwa in einem 2D-Array, was lahmt) und ein weiterer Pixel immer dann projiziert wird, wenn dessen Z-Wert diesen Z-Wert unterschreitet. Und richtiges Raytracing geht als nicht, weil es zuviel Rechenleistung benötigt. Von der Grundidee zwar simpel: das Licht einfach punktförmig und rekursiv ausbreiten, an Reflexionspunkten die Farbwerte der in der Rekursion folgenden Strahlen berechnen und die jeweiligen Folgestrahlen aus dem Rekursionslauf entfernen, wenn sie absorbiert werden. Das geht zwar theoretisch schon, aber es kann Monate dauern. Es ist aber andererseits optisch schon ziemlich eindrucksvoll, wenn man als "Textur" echte Fotos verwendet. Da kann man das Fehlen von einem eindrucksvollen Schattenwurf und Rückstreung verschmerzen. Nur ein paar Überlegungen. Man müßte noch mit einem Testprogramm prüfen, ob es klappt. Es könnte dennoch als Anleitung für eine komplette 3D-Engine reichen, wenn die Sache mit den Drehungen klappt. (nicht signierter Beitrag von 2.205.62.106 (Diskussion) 21:50, 15. Dez. 2013 (CET))