Ergebnis 1 bis 12 von 12

3d-Welten erzeugen (in Python?)

  1. #1 Zitieren
    Veteran
    Registriert seit
    Jun 2012
    Beiträge
    629
    Wie erzeugt man am einfachsten/effizientesten(/oder überhaupt) 3d-Welten?
    Und zwar am liebsten von Grund auf.
    Ich weiß, dass es große Programme gibt, mit denen sowas möglich wäre, wie Unity und Blender, in denen man 3d-Modelle modellieren kann.
    Allerdings will ich nicht so gerne riiiesige, bereits vorhandene Programme/Programmbibliotheken benutzen, die man erst Monate-lang studieren muss, um zu entdecken, was da überhaupt alles drin ist.

    Ich würde gern alles von Grund auf aus dem Nichts programmieren, wie bisher, einfach in ein Textdokument. Und zwar, damit man alles, was vor sich geht, auch selbst nachvollziehen kann.

    Ich habe bisher in Python programmiert und 2d Sachen gemacht.
    Z.B. Fenster erzeugt, JPEGs/PNGs reinzeichnen lassen, wenn der User Tasten drückt Koordinaten ändern, sodass sich die Position der Grafiken ändert = Figur bewegt sich.

    Jetzt würd ich gern wissen, was ist die grundlegende Sache, die man sich aneignen muss, um eine 3d Welt in so einem Fenster zu erzeugen.
    Ich denke da so ganz basic an sowas wie Civ3 oder Civ4:
    Die "Map" ist quasi ein Quadrat, dass auf dem Boden liegt, man schaut isometrisch drauf, vielleicht kann man die Kamera rotieren. Und auf der flachen Map können dann Objekte platziert werden, die dann Gebirge oder Spielfiguren darstellen. Solche Dinge.

    Was sollte man sich angucken, um so grundlegende 3d-Modelle in sein Fenster zu programmieren?
    Gothicforum ist offline

  2. #2 Zitieren
    Ritter Avatar von Feuerstern
    Registriert seit
    Sep 2007
    Beiträge
    1.798
    Die Modelle selber werden in der Regel nicht "programmiert" sondern in einem 3d Programm modelliert, wie z.B. Blender, 3ds Max oder Cinema 4d. Wenn die Welt inteaktiv sein soll würde man dann eine Engine verwenden in der man diese Modelle lädt und dann die Spiel Logic progrtammiert. Z.B. Unity oder die Unrel Engine (Blender bietet wohl auch eine Engine).
    Du kannst 3d Modelle theoretisch auch ohne ein 3d Programm erstellen, aber das ist nicht wirklich sinnvoll. Das wäre als würdest du in einem 2d game deine Bilder zeichnen indem du die Linien und Kreise und deren Positionen im Programm Code definierst und so versucht aufwendige Bilder zu erstellen. Das wäre bei 3d Modellen nochmal um ein vielfachen aufwendiger.

    Ich vermute also du möchtest eher eine 3d engine selbst programmieren. Das ist möglich, aber da brauchst du viel low level wissen und musst dich mit Vulcan, DirectX oder OpenGL
    auseinandersetzen. Dazu kommt dann noch eine Menge Linearer Algebra und Matrizen Rechnungen. Wenn du viel Zeit hast ist das machbar, aber wirklich sehr aufwendig. Ob Python da die beste Sprache ist außerdem fraglich. Die meisten Engines sind zumindest in C oder C++ geschrieben.
    Feuerstern ist offline

  3. #3 Zitieren
    Veteran
    Registriert seit
    Jun 2012
    Beiträge
    629
    Ok, ich verstehe. Gute Erklärung mit dem Zeichnen aller Linien statt Nutzen einer Bild-Datei.

    Also wenn ich Unity oder Blender benutze, um ein 3D-Modell zu machen, dann speichere ich es hinterher in einer
    "3d-Modell-Datei" wie "character.blend" (oder was immer die Endung ist) und dann schreibe ich in meinen Programm-Code so wie bisher

    "pygame.image.load('background.png')"
    nun
    "pygame.3d.load('character.blend')" (oder so)

    und dann benutze ich das vorbereitete Modell als Variable?



    Und Unity benutzen hieße, Python aufgeben und eine andere Sprache lernen.
    Wenn ich Unity benutze, kann man das fertige Projekt dann exportieren und es läuft dann auch bei jemandem auf dem PC, der Unity nicht installiert hat?
    Gothicforum ist offline

  4. #4 Zitieren
    Ritter Avatar von Feuerstern
    Registriert seit
    Sep 2007
    Beiträge
    1.798
    Zitat Zitat von Gothicforum Beitrag anzeigen
    "pygame.image.load('background.png')"
    nun
    "pygame.3d.load('character.blend')" (oder so)
    Ich habe mit pygame selbst keine Erfahrungen, aber so in etwa kannst du dir das mit einer 3d engine vorstellen. Diese bietet dir bereits einen Rahmen mit Grundlegenden Funktionen die du auf das 3D Objekt anwenden kannst.


    Zitat Zitat von Gothicforum Beitrag anzeigen
    Und Unity benutzen hieße, Python aufgeben und eine andere Sprache lernen.
    Wenn ich Unity benutze, kann man das fertige Projekt dann exportieren und es läuft dann auch bei jemandem auf dem PC, der Unity nicht installiert hat?
    Unity ist nur eine von vielen Engines. Es kommt drauf an worum es dir geht. Wenn es dir darum geht Erfahrung in python zu sammeln und vieles selbst zu machen kann es Sinn machen auf eine komplett fertige Engine zu verzichten und selbst zu versuchen etwas zu entwickeln. Du solltest damit aber nicht zu viel erwartet da der Aufwand sonst schnell gigantisch wird.
    Hast du hingegen ein konkretes Projekt vor Augen und es geht dir mehr um das Endergebnis, als um den Weg dahin, dann ist es besser zu einer fertigen Engine zu greifen die dir schon vieles abnimmt. Die Programmiersprache sollte dabei allerdings zweitrangig sein. Die Grundlagen lassen sich meist schnell erlernen und falls du dich zu sehr auf python einschießt hast du am Ende nicht mehr viel Auswahl in dem Bereich.

    Das mit dem "exportieren" sollte gehen. Soviel ich weiß lässt sich das alles am Ende in einen Installer packen. 100% Sicher bin ich mir da aber nicht.
    Feuerstern ist offline

  5. #5 Zitieren
    Veteran
    Registriert seit
    Jun 2012
    Beiträge
    629
    Gibt es denn ein gutes, ausführliches Buch, dass zu empfehlen wäre zum Thema "3d Engines (selbst programmieren)"?
    Gothicforum ist offline

  6. #6 Zitieren
    Tieftöner Avatar von Lookbehind
    Registriert seit
    Dec 2007
    Beiträge
    15.176
    Ein Buch ... uff ... nein. Mit einem Buch wirst du da nicht hin kommen. Aber für den Anfang würde ich mal ein paar Mathe-Bücher empfehlen. Lineare-Algebra, Kurvendiskussion, Differential und Integral-Rechnung, Matrizen, ... so was alles. Ich hab dafür vor gefühlten Ewigkeiten auf den Papula zurückgegriffen. Das sind mehrere Bände, die waren damals ganz gut.

    Um das vielleicht mal ein wenig in Perspektive zu rücken. Dein Standpunkt im Eingangspost ist in etwa der Folgende:
    Ich hab schon ein paar Ikea-Möbel zusammengebaut, das kann ich ganz gut. Jetzt will ich ein Auto bauen, aber ich will keinen Bausatz (ja, es gibt Bausätze für Autos) weil da die Anleitung so lang und kompliziert ist. Ich will das von komplett selber konstruieren und bauen. Wo finde ich das passende Handbuch?

    Das ist ein bisschen überspitzt, aber macht vielleicht deutlich, dass dein Vorhaben deutlich mehr umfasst, als man in 2-3 Tutorials abhandeln könnte. Hier geht es um Hintergrundwissen und ein Verständnis für die Grundlagen. Für dein Vorhaben kommen Themen aus vielen verschiedenen Fachrichtungen zusammen. Du brauchst wissen über Geometrie, Persepktive und Projektion, über Algorithmik, Laufzeit und Komplexitätstheorie, über Datenmodelle, Parallelisierung und Schnittstellen, und das ist nur das, was mir ohne beim Tippen an zu halten eingefallen ist.

    Darum kam auch der Einwand, dich zu fragen was dein Ziel ist.
    Wenn es dir darum geht zu lernen, dann Go! Das ist viel und wird nicht einfach, aber es ist definitiv machbar und ich kann dich dazu nur ermutigen. Das wird zwar eine ganze Weile dauern, kann die Mühe aber absolut wert sein.
    Wenn es dir darum geht ein Projekt fertig zu stellen, dann wäre es besser, auf eine fertige Engine zurück zu greifen. Da sind die Handbücher zwar lang und man muss immer noch viel lernen. Aber verglichen mit dem Weg das von Grund auf zu machen, ist das die Abkürzung.
    Lookbehind ist offline

  7. #7 Zitieren
    Veteran
    Registriert seit
    Jun 2012
    Beiträge
    629
    Zitat Zitat von Lookbehind Beitrag anzeigen
    Aber für den Anfang würde ich mal ein paar Mathe-Bücher empfehlen. Lineare-Algebra, Kurvendiskussion, Differential und Integral-Rechnung, Matrizen, ... so was alles.

    Um das vielleicht mal ein wenig in Perspektive zu rücken.

    Du brauchst wissen über Geometrie, Persepktive und Projektion, über Algorithmik, Laufzeit und Komplexitätstheorie, über Datenmodelle, Parallelisierung und Schnittstellen, und das ist nur das, was mir ohne beim Tippen an zu halten eingefallen ist.

    Darum kam auch der Einwand, dich zu fragen was dein Ziel ist.

    Wenn es dir darum geht zu lernen, dann Go!

    Wenn es dir darum geht ein Projekt fertig zu stellen
    Ja, das sehe ich ein, dass das vielleicht viel zu komplex ist.

    Es geht mir auch um genau dieses "In-Perspektive-rücken". Ein Buch (oder meinetwegen Tutorial-Reihe), das einem zeigt, "für 3d Engines wird Matrizenrechnung, Differential und Integral-Rechnung und Kurvendiskussion benutzt. Und jetzt folgt ein Kapitel über Matrizen und wofür genau sie in einer Engine benutzt werden und dann ein Kapitel darüber, wie die eine Engine es so macht, die andere Engine aber ganz anders."

    Ich will nicht zwingend meine eigene Engine programmieren, sondern ich will verstehen, was eine Engine alles beinhaltet und was genau es ist, was ich kriege, wenn ich z.B. einfach Unity nehme und es dann daher nicht mehr selbst machen muss.

    Bei Unity kann ich ja einfach auf den Button klicken und dann die Kamera hier positionieren. Oder jenen Button klicken und dann verschiebe ich die Lichtquelle nach dort drüben.
    Was genau da passiert, kriege ich aber überhaupt nicht mit.
    Ich will nur verstehen, was genau es ist, was ich mir selber-zu-machen spare, wenn ich dieses bereits Fertige benutze.

    Meine Ziele sind also fast dreierlei:
    -verstehen, was grundsätzlich die 3d-Objekte in mein Fenster bringt
    -einen Überblick gewinnen, was alles in einer fertigen Engine (wie z.b. Unity) drin ist und was genau eine Engine von einer anderen unterscheidet
    -auf dem simpelsten Basis-Level mal 3d Sachen erzeugen mit selbst-geschriebenem Code (wobei ich für die simpelsten, einzelnen 3d Objekte natürlich schon Tutorials gefunden habe), um ein Gefühl dafür zu kriegen wie viel Arbeit was ist
    (vielleicht bleibe ich ja auch einfach bei 2d und erzeuge eine isometrische Welt oder Pseudo-3d)

    Mir gehts darum einen Überblick zu gewinnen.
    Gothicforum ist offline

  8. #8 Zitieren
    Provinzheld Avatar von Cheesecake
    Registriert seit
    Feb 2012
    Beiträge
    266
    Ich muss ganz ehrlich sagen, dass es keinen wirklich einfachen Weg gibt, in diesem ganzen Themenfeld Fuß zu fassen. Man quält sich da halt irgendwie durch und wenn man sich dabei nicht zu sehr frustrieren lässt und auch damit leben kann, dass man vieles für den Moment nicht versteht, dann erreicht man vielleicht irgendwann den Punkt, wo man effektiv in dem Bereich arbeiten kann. Ich arbeite selbst an einer Uni und muss immer wieder mit ansehen, wie die Studierende sich für ihre Projekte in Unreal oder Unity einarbeiten und es ist einfach immer schwierig und kostet Zeit. Es läuft aber immer auf das typische Learning by Doing heraus und statt sich lange Gedanken zu machen, wie man in das Thema einsteigt, sollte man sich einfach ein kleines Ziel setzen und versuchen dieses zu erreichen. Dabei geht man entweder den Low-Level-Weg und beschäftigt sich grundlegender mit Computergrafik oder man geht den High-Level-Weg und nimmt sich eine einsteigerfreundliche Engine wie Unity oder Unreal und versucht einfach, kleinere Spiele oder so etwas umzusetzen und dann quasi "unterwegs" ein besseres Verständnis über die Engines zu erlangen. Alternativ kann man sich auch eine reine Grafikengine nehmen.
    Es gibt in dem Thema auch nicht so viele schöne Bücher für Einsteiger, da das meiste über Konferenzen, Paper, Tutorials und Blogeinträge verbreitet wird und da wird dann eben oft davon ausgegangen, dass man entsprechendes Grundwissen schon hat. Man sollte zumindest lineare Algebra und etwas Programmierung beherrschen, vorzugsweise in einer Sprache wie C++.
    Wenn man ganz grundlegend lernen will, wie die Dreiecke auf dem Bildschirm landen, gibt es einmal die rein mathematische Seite (Model/View/Projection Matrices, homogene Koordinaten und den Grundaufbau von Meshes) und den programmiertechnischen Teil der Grafikpipeline, wie man ihn in OpenGL, DirectX oder was auch immer umsetzten würde. Hierzu ist vielleicht das Buch Real-Time Rendering von Tomas Akenine-Möller zu empfehlen, da es einen guten Überblick verschafft aber wenn man den Kram wirklich grundlegend verstehen will, kann man auch ein Tutorial für OpenGL oder DirectX durcharbeiten. Damit ist man zwar weit von richtiger Spieleprogrammierung entfernt aber wenn man ein paar simple Dinge wie Phong-Shading, Shadow Mapping, Deferred Shading, SSAO usw. mal selbst umgesetzt hat, sieht der Rest auch gleich nicht mehr so gruselig aus. Das ist zumindest der Weg, den ich damals gegangen bin aber ich bin auch eher so ein Bastlertyp, der gerne Bits und Bytes hin und herschiebt und das hat mich auch extrem viel Zeit gekostet. Man nimmt zuerst Beispielcode, der ein rotes Dreick erzeugt und macht dann ein Viereck daraus. Als nächstes lässt man das Viereck vielleicht auf dem Bildschirm umherwandern oder man baut ein eine simple Kamerasteuerung. Dann packt man vielleicht eine Textur drauf und implementiert eine einfache Beleuchtung mit direktionalem Licht. Als nächstes kommt dann vielleicht Normal Mapping oder was auch immer. So kann man sich dann schrittweise an komplexere Probleme wagen. Ich hatte damals immer mal hier reingeschaut aber kann jetzt auch nicht sagen, ob ich das heute noch empfehlen würde: https://www.rastertek.com/tutdx11.html Man muss es für ein grundlegendes Verständnis ja auch nicht übertreiben aber es gibt eben nichts, was einem ein besseres Verständnis liefert außer es selbst mal umgesetzt zu haben. Ich muss nämlich auch ganz deutlich sagen, dass Grafikprogrammierung ein extrem weites und komplexes Feld ist und bis man wirklich von sich behaupten kann, darin auch nur halbwegs kompetent zu sein, vergehen schon eher Jahre aber so tief muss man auch nicht unbedingt in die Materie einsteigen.
    Wenn einem das alles zu krass ist, sollte man stattdessen einfach direkt mit einer fertigen Engine arbeiten und ich weiß auch, dass dieser Weg für viele Leute wesentlich befriedigender ist als das Herumspielen mit Grafik-APIs. Auf der anderes Seite muss man auch nicht wissen, wie Physically-based Rendering oder Occlusion Culling jetzt im Detail funktionieren, um mit Engines arbeiten zu können, solange man versteht, was grundsätzlich dahintersteckt aber das kann man sich auch schrittweise aneignen, während man kleinere Projekte umsetzt und über die Konzepte stolpert. Wie gesagt, ich kenne das so von unseren Studierenden, dass man sich da ohne Vorwissen eben einfach durchkämpfen muss, während man eine konkrete Aufgabe erfüllen will. Man lernt dabei eigentlich automatisch etwas darüber, wie Engines intern funktionieren und verschiedene Engines sind da im Wesentlichen auch immer sehr ähnlich. Wenn man ein bisschen Erfahrung gesammelt hat und mehr über die inneren Abläuft einer Engine lernen möchte, kann man sich dann z.B. auch mal ein paar Talks der GDC oder so anschauen, wo Spieleprogrammierer ihre Arbeit erklären. Typische Buzzwords, die man im Zusammenhang mit Engines oft hört, sind z.B. Game Loop, Entity Component System, Task-based Parallelism, Data-oriented Design (Array of Structs vs Structs of Arrays usw.) und wahrscheinlich noch ein paar mehr, die mir gerade nicht einfallen. Um das richtig zu verstehen, hilft es aber auch wieder, wenn man sich sehr gut mit Programmierung und insbesondere auch GPU-Programmierung auskennt, da das bei Engines alles irgendwo ineinander übergeht.

    So ganz allgemein muss man sich auch damit abfinden, dass man in absehbarer Zeit das Gefühl nicht loswird, dass man keine Ahnung hat und den Großteil nicht versteht. Ich verdiene mit dem Kram mein Geld und ein Kollege und ich haben eine eigene Engine für Augmented Reality geschrieben, die alles Mögliche von Global Illumination und PBR bis hin zu Kameratracking und voxelbasierter 3D-Rekonstruktion kann und wir kommen uns trotzdem oft wie totale Anfänger vor, weil es so unglaublich viele Inhalte gibt, für die wir bisher einfach keine Zeit hatten.
    Cheesecake ist offline

  9. #9 Zitieren
    Legende Avatar von jabu
    Registriert seit
    Jul 2011
    Beiträge
    7.328
    Grob meine Historie (Sprachen, die hier nichts nützen, sowie Exkurse zu Grafik unter DOS (Mode 13h ), klammere ich aus, es ist auch nicht alles chronologisch hundertprozentig korrekt, da sonst die Übersicht verlorenginge):

    Zuerst lernte ich C, zunächst mit Konsolenprogrammen und dann mit dem nackten Windows-API, also mit Message-Loop, Window-Callbacks, Child-Windows usw., was mich schon einige Jahre beschäftigte, bis ich einigermaßen sicher programmieren konnte. Ich beschäftigte mich überwiegend mit Low-Level-Kram, weil ich alles verstehen wollte, darunter auch Bitmanipulation, Implementierung von Ringpuffern (z.B. für hochperformante Stream-Server), Port-Ansteuerung (ging damals noch direkt, ohne Treiber) usw.

    Etwas Assembler (insbes. mit MASM, NASM, später auch Yasm) war auch dabei, und zwar Assembler mit dem Windows-API, was aus heutiger Sicht exotisch erscheinen mag. Linker und Ressourcencompiler mussten extra bedacht werden. Dieser eher harte Weg half dabei, zu verstehen, wie ein Windows-PE-File aufgebaut ist und was der Loader des Betriebssystems beim Anwendungsstart vollzieht. Und er half dabei, die Ausgaben eines Debuggers besser zu verstehen. Einige Nächte mit ziemlich anstrengendem und aufschlussreichem Reverseengineering mussten durchlitten werden.

    Nun interessierte mich doch mal 3D-Grafik, wozu ich überhaupt erst mal an einen Compiler kommen musste, der mir erlaubte, gegen die DirectX-Libs von Microsoft zu linken. Zunächst ging das nur mit modifizierten Libs, zuerst für den Borland-Compiler ("BCC") und später auch für MinGW (und das ohne die Hilfe einer IDE, also brav die Flags zu verstehen gelernt). An Microsoft war wegen der Kosten erst mal nicht zu denken, doch später kam Abhilfe.

    Es ging erst mal, wie bei Cheesecake beschrieben, um Grundlegendes, z.B. vom Darstellen eines untexturierten Dreiecks bis zum rotierenden Würfel, wobei meistens erst nachträglich texturiert und beleuchtet wurde, weil das für mich noch ziemlich kompliziert aussah. Später kamen umfangreiche Tutorials zu inzwischen veralteten DirectX-Versionen hinzu, z.B. bis zum Rendern eines kompletten Levels. Das motivierte mich zum Ausbau zu einer kompletten Windows-Anwendung, mit Splash-Screen, Settings, diversen Initialisierungen und Re-Initialisierungen (windowed/resize/fullscreen, alles sauber implementiert), Maus-, Tastatur- und Joystick-Steuerung (sauberes Reaquirieren, kein Crash beim Stöpseln während des Spielens) mit DirectPlay (inzwischen veraltet) etc.

    Nebenher musste ich mir C++ beibringen, da DirectX mit C eine Qual war und fast überall, wo ich nachschlagen musste, C++ verwendet wurde. Mein C++ sah erst einmal noch fast wie C aus. Aber das verbesserte sich, als ich mir diverse Open-Source-Projekte ansah (darunter z.B. auch AssaultCube und OGRE) und nebenher auch etwas Literatur, Tutorials und den C++-Standard durchging und mir Talks aus der C++-Community ansah.

    Ich überarbeitete und erweiterte den Code von ArxFatalis für meine Zwecke, was ein Sprung ins kalte Wasser war. Dabei ging es z.B. um das Fixen des defekten Timings, sonstiges Bugfixing, Performanceoptimierung, Herausschmeißen unnötigen Codes, zusätzliche Menüpunkte, Restrukturierung etc. Da die Engine kein Hardware-T&L kann, also ziemlich viel in Software macht, war der Lerneffekt notgedrungenerweise groß. Ich kann das aber nicht als Einstieg empfehlen, da diese Engine so veraltet ist, dass man sie inzwischen als atypisch ansehen kann. Das liegt nicht nur daran, dass sie DirectX7 und daher nur eine Fixed-Function-Pipeline (Shader-Support gab es noch nicht) verwendet. Vielmehr wollte ich skizzieren, wie mir der Sprung ins kalte Wasser genützt hat. Die verkorkste Anwendungsarchitektur war sehr lehrreich, auch viele andere abschreckende Beispiele (und einige wenige gute).

    Mit Shadern hatte ich erst intensiv zu tun, als Risen 2 bei mir nicht genügend FPS brachte. Also musste ich notgedrungen Kompatibilität zu meiner schwachen GPU herstellen, was aber wegen des bereits kompilierten HLSL-Codes ein schwieriges Unterfangen war.

    Ich hatte meistens eher schwache Hardware, was mich insbesondere zu Performanceoptimierung motivierte, was lehrreich war.

    Ich beschäftigte mich später auch mit Unity (Scripting mit C#). Aber ich würde eher Unreal empfehlen, weil das weniger von einer Blackbox hat und flexibler ist. Trotzdem sollte es nicht schaden, sich auch mal Unity angesehen zu haben.

    @Cheesecake
    In deinem Beitrag finde ich mich gut wieder, also z.B. wie ich damals angefangen habe (wobei mein überschaubares Wissen noch überwiegend aus der Zeit der Fixed-Function-Pipeline stammt, z.B. mit DirectX7).

    PS
    Hauptsache, man fängt irgendwo an und zieht eine Sache durch. Es ist nicht nötig und wohl auch kaum möglich, auf allen Gebieten versiert zu sein. Viel wichtiger sollte sein, sich selber helfen zu lernen, sodass (die größtenteils nie schließbaren) Wissenslücken nicht mehr viel ausmachen. Das zu schaffen, war auch bei mir ein langer, aber lohnender, Prozess. Mein Gedächtnis kommt mir inzwischen wie ein einziges Sieb vor. Das ist einerseits frustrierend, aber die Ergebnisse sind trotzdem besser als damals, weil etwas anderes gelernt wurde, nämlich Methodenkompetenz. Darin steckt die eigentliche Power. Aber Methodenkompetenz lernt man nicht, indem man sich hinsetzt, um Methodenkompetenz zu lernen. Es bedarf dazu schon realer Anforderungen. Deswegen kann ich empfehlen, den Sprung ins kalte Wasser zu wagen und eine Engine zu kompilieren, zu analysieren und zu modifizieren. Die Seite des Workflows sollte auch nicht fehlen, also einfach mal gängige Editoren ausprobieren. Wenn du gleich alles auf einmal haben willst, könntest du dir den Quelltext von Unreal angucken. Wenn ich noch Zeit für solche Sachen hätte, so wäre das heutzutage mein Weg. Nichts ist aufschlussreicher als realer Quelltext, da man dort auch die Zusammenhänge und einen insgesamt funktionierenden Weg sieht. Für reines Rendering und als Startpunkt dürfte wohl z.B. OGRE genügen.
    jabu ist offline Geändert von jabu (05.07.2021 um 18:02 Uhr)

  10. #10 Zitieren
    Veteran
    Registriert seit
    Jun 2012
    Beiträge
    629
    Danke sehr für die ausführlichen Antworten.
    Das ist sehr interessant, die Entwicklungsgeschichte von (scheinbaren) "Veteranen" zu lesen!

    Zitat Zitat von Cheesecake Beitrag anzeigen
    z.B. auch mal ein paar Talks der GDC oder so anschauen, wo Spieleprogrammierer ihre Arbeit erklären. Typische Buzzwords, die man im Zusammenhang mit Engines oft hört, sind z.B. Game Loop, Entity Component System, Task-based Parallelism, Data-oriented Design (Array of Structs vs Structs of Arrays usw.) und wahrscheinlich noch ein paar mehr
    Das ist, glaube ich, das Beste: einfach ein paar Buzzwords. Und über das ein oder andere davon stolpere ich wahrscheinlich eh bald.

    Zitat Zitat von Cheesecake Beitrag anzeigen
    So ganz allgemein muss man sich auch damit abfinden, dass man in absehbarer Zeit das Gefühl nicht loswird, dass man keine Ahnung hat und den Großteil nicht versteht. Ich verdiene mit dem Kram mein Geld und ein Kollege und ich haben eine eigene Engine für Augmented Reality geschrieben, die alles Mögliche von Global Illumination und PBR bis hin zu Kameratracking und voxelbasierter 3D-Rekonstruktion kann und wir kommen uns trotzdem oft wie totale Anfänger vor
    Ich kann total nachvollziehen, wie das ist. Das ist ja bei jedem Themengebiet so: man kann immer endlos in die Breite und auch endlos in die Tiefe gehend jedes Themengebiet angucken, jahrelang dran studieren und lernen und trotzdem gibt es immer Leute, die Dinge wissen, die man nicht weiß.
    Weiß ich jetzt nicht, ob ich das beruhigend oder beunruhigend finden soll, dass das "Profis" auch immer wieder so geht.

    Zitat Zitat von jabu Beitrag anzeigen
    PS
    Hauptsache, man fängt irgendwo an und zieht eine Sache durch. Es ist nicht nötig und wohl auch kaum möglich, auf allen Gebieten versiert zu sein. Viel wichtiger sollte sein, sich selber helfen zu lernen, sodass (die größtenteils nie schließbaren) Wissenslücken nicht mehr viel ausmachen.
    Ja, ich habe mir jetzt erstmal vorgenommen, diesen Monat an meinen kleinen Spiel-Projekten weiter zu arbeiten.
    Dabei mache ich immer mal ein Youtube-Video, wenn ich etwas "Relevantes" geschafft habe.
    Hat jetzt noch nichts mit Engines oder 3d zu tun.

    Heute habe ich mir Isometrische Maps angeschaut und den ganzen Tag daran rumgedoktort, wie ich die Mausposition in die Isometrische Position umrechne.
    Da hatte ich meine erste Ladung Matrizen-Rechnung.

    Spät Abends hatte ich meinen Durchbruch und es hat alles hingehauen.
    Jetzt könnte ich erstmal ein Spiel wie damals Age of Empires programmieren.
    Das mache ich glaub ich auch, und dabei werde ich bestimmt in die nächsten Problemchen rennen und dann wieder ein Themegebiet finden.
    Gothicforum ist offline Geändert von Gothicforum (13.07.2021 um 00:04 Uhr)

  11. #11 Zitieren
    Veteran
    Registriert seit
    Jun 2012
    Beiträge
    629
    Was sind denn Programmiersprachen/Tools/Themengebiete, die man sich angucken muss, um eine 3d Welt wie Gothic1 zu erzeugen?

    Die Grafik von Gothic 1 ist 20 Jahre alt und sollte daher nicht soo komplex/schwierig sein, oder? Dennoch ist die Grafik für ein Spiel vollkommen okay (um eine glaubhafte Spielwelt zu erzeugen, in die man sich vertiefen kann).
    Gothicforum ist offline

  12. #12 Zitieren

    Batmanistrator
    Avatar von Thoronador
    Registriert seit
    Jul 2005
    Ort
    Morrowind, Vvardenfell-Distrikt
    Beiträge
    20.403
    Zitat Zitat von Gothicforum Beitrag anzeigen
    Was sind denn Programmiersprachen/Tools/Themengebiete, die man sich angucken muss, um eine 3d Welt wie Gothic1 zu erzeugen?

    Die Grafik von Gothic 1 ist 20 Jahre alt und sollte daher nicht soo komplex/schwierig sein, oder?
    Die grundlegenden Themengebiete für 3D-Grafik sind die gleichen, egal ob das Spiel 20 Jahre oder 20 Tage alt ist. Sprich: Ein Grundverständnis von Vektoren, Matrizen, linearer Algebra, UV-Mapping braucht man da in jedem Fall.
    Sehr vereinfacht gesagt unterscheidet sich die 3D-Grafik in älteren Spielen im Gegensatz zu denen in neueren Spielen "nur" im Detailgrad. Das heißt also weniger Polygone pro Modell, geringer aufgelöste Texturen und weniger Animationsframes. Und weniger Krimskrams wie HDR, Anti-Aliasing und so weiter, aber das braucht man für den Anfang erst einmal nicht.
    Thoronador ist offline

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •