Beiträge von Mirac

    Vllt kann man abschließen festhalten, dass für jemanden, der mit einer Engine ein Spiel erstellen will, es relativ(!) egal sein kann was für Shader performanter sind, ich glaube relevanter ist ob man PBR benutzen kann um sein Spiel besser aussehen zu lassen, wenn es möglich ist und man auch die Fähigkeiten hat solche Assets zu erstellen, wieso sollte man es nicht tun.


    Noch zum Thema Mobile: Natürlich bietet ein Smartphone nicht die gleiche Leistung wie eine High-End-Grafikkarte, aber sind wir mal ehrlich, auch wenn ein mobiles Endgerät Full-HD, 4K, etc. kann sind es doch meist nur Bruchteile der größe eines Monitors, viele Details gehen dann auch einfach unter und man nimmt dann halt einfach deutlich kleinere Texturen.


    Ich habe in einem früheren Post erwähnt, dass die Texturen nicht der kritische Teil bei der Performance sind, allerdings verbraucht eine 1024² Pixel große Textur in der Regel (bei 32Bit pro Pixel in RGBA) ~4 MB Speicher (ja als Datei werden diese komprimiert, aber für die Shader müssen diese pro Pixel vorliegen). Geht man nun davon aus, dass ein Material eine Color-, Normal-, Roughness-, Metallic-, und eine AO-Map verwendet, sind dies 5*4 = 20 MB und das pro Material. Damit ist der Speicher bei einem mobilen Endgerät schnell erschöpft. Also sollte man in dem Fall eher kleinere Texturen nehmen als über PBR oder kien PBR nachzudenken.

    Ich hätte auch noch mehr dazu schreiben können, allerdings muss ich zugeben, dass ich mich beim Thema PBR-Berechnung und Raytracing einfach kein Profi bin und am Ende keine Halbwahrheiten schreiben möchte und dass es einfach ein enorm komplexes Thema ist was auch nicht in 2-3 Sätzen erklärt werden kann.


    Wer sich mit dem Thema ernsthaft auseinandersetzen möchte kann ja mal nach Begriffen googlen wie:

    • Phong-Beleuchtungsmodell (nicht mit Phong-Shading verwechseln), dabei handelt es sich, wie bereits erwähnt, um ein klassisches Rendering.
    • Raytracing
    • Physically Based Rendering (wenn ich mich richtig erinner gibt es irgendwo ein Dokument über den Renderer der CryENGINE)

    Allerdings wird man schnell mit höherer Mathematik konfrontiert ;)


    EDIT: Ein kleiner Einstieg speziell für Artists:

    Externer Inhalt www.youtube.com
    Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.

    Vorweg: Eine Antwort ob PBR nun mehr Perfomance braucht oder nicht, will ich jetzt nicht geben. Ich möchte nur einen Unterschied etwas verdeutlichen.


    Was ich aus eigener Erfahrung (aus Programmierersicht) sagen kann ist, dass PBR-Berechnung im Vergleich zu "klassischen" Rendering komplexer ist. Allerdings bauen alle PBR's meines Wissens nach komplett auf Raytracing auf, während dies bei dem klassichen Rendering nicht der Fall ist.


    Wenn man einen "normalen" Raytracer mit einem für PBR vergleicht wird man eher eine Antwort treffen können, ob eins von beiden mehr Leistung braucht. Bei Blender wäre dies eine Scene die mit Cycles gerendert wird (ohne PBR-Aufbau) im Gegensatz zu einer mit PBR-Aufbau.


    Was man (meiner Meinung nach) aber festhalten kann, ist dass ein klassisches Shading-/Beleuchtungssystem (z.B. Phong) deutlich schneller ist, da diese nur wenige Rechenschritte beinhalten, während ein Raytracer deutlich umfangreicher ist.


    Ergänzung: Was am meisten Rechenleistung beim Rendering verbraucht sind nicht die Texturen (das sind einfache Texel, die in die Berechnung einfließen), sondern die Reflexionen ;)

    Leider ist bei mir im Moment wenig Zeit vorhanden um sich mit der Unreal Engine auseinanderzusetzen und die wenige Zeit, die ich noch hab, steckt im Moment in einem kleinen 2D Spiel, dass auf einer eigenen kleinen Engine basiert.


    Naja der Code für das Planungstool ist ja noch vorhanden, also es ist vllt tot aber noch nicht beerdigt :D

    Hey,
    da ich ja einer von "den Zwei" war, möchte ich an dieser Stelle mal ein paar Worte dazu sagen ;)


    Leider ist so ein Forum mit einer Menge Arbeit verbunden, die auch nach mehreren Monaten immer noch nicht ausreichend Früchte getragen hat, haben wir, nachdem einfach keine Motivation mehr da war (und zumindest bei mir auch private Veränderungen gab) das Projekt eingestellt.


    Gerade PlanIT (das Planungstool) und Artikel um die Theorie hinter der Spieleentwicklung (wenn auch noch etwas holprig) waren Projekte die ich gerne weiter verfolgt hätte.


    Hoffe jetzt ist es etwas klarer. Leider geschah es ohne Ankündigung und sehr kurzfristig, an dieser Stelle möchte ich mich noch dafür entschuldigen.


    Mfg Mirac

    Dann will ich das hier mal dalassen:


    Externer Inhalt www.youtube.com
    Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.
    ;)


    Das Spiel ist im Zuge einer Hausarbeit entstanden in der das Framework erweitert wurde, dabei lag das Hauptaugenmerk nicht auf dem Gamedesign oder Gameart sondern an der Deferrer-Shading Technik ;)

    Grob:
    2 Renderer: Forward und Deferred
    Objekte laden und rendern
    Sprites
    Font rendering
    Inputmanagment
    Simple Kollision (leider noch verbuggt)


    Und ein paar Hilfsklassen für z.B. FirstPersonSpieler

    Ich meld mich mal bei dir wenn ich Zeit hab ;) Wenn es dir aber wirklich darum geht sicj mit sowas auseinander zu setzen lass lieber die Finger von der UE4, die ist zu unfangreicj dafür

    So, sorry wenn ich mal dazwischenhaue ;)


    Von der Entwicklung einer eigenen Egnine würde ich dir wirklich abraten, ich hab selbst lange Zeit das Ziel verfolgt und kann dir sagen es ist zwar einfach und mit entsprechenden Kenntnissen innerhalb weniger Stunden ein 3D-Objekt auf dem Bildschirm darzustellen, allerdings gehört viel mehr dazu. Ich hab irgendwann schmerzhaft eingesehen dass es für eine einzelne Person zu komplex ist ;)
    Mittlerweile arbeite ich nur noch selten dran, und dann rein aus Interesse mit dem Wissen dass es niemals Produktionsreife erreichen wird.


    Wenn du allerdings es dennon versuchen willst kannst du gerne nachfragen ;)


    Auch kannst du dir gerne mal meinen Code anschauen :)


    Fazit: Um mal ein bisschen zu experimentieren oder tieferes Verständnis für die Thematik zu erhalten ist die Entwicklung einer eigenen kleinen Engine möglich. Willst du aber ein Spielerstellen solltest du auf eine bestehende zurückgreifen.


    mfg Mirac

    EDIT:
    "DX11 emulation features – for easier porting of applications between OpenGL and Direct3D.", diese Emulation hat also nichts mit dem "Können" von OpenGL zu tun, sondern dient nur der Portierung.


    Nochmal, kam evtl nicht deutlich genug rüber: OpenGL und Direct3D, haben absolut nichts mit den sichtbaren Effekten in einem Spiel zu tun, dabei handelt es sich um Shader und Ressourcen, die der Grafikkarte übergeben werden.

    Den Bericht würde ich gerne mal lesen ;)

    Zitat

    Viele Spiele gehen mehr auf DirectX, somit sage ich, diese Spiele basieren auf DirectX.

    Es mag spiele geben auf die genau das zutrifft, aber dann basiert in 95% der Fälle eher die Engine auf DirectX.
    OpenGL und Direct3D (!= DirectX) sind sehr wohl ebenbürtig (spätestens seit OpenGL4), nicht umsonst sind nach wie vor auf allen (nahezu) allen Grafikkarten beide API's implementiert. Im Gegenteil OpenGL bietet sogar gegenüber Direct3D Vorteile z.B. seine Unabhängigkeit ;)
    Direct3D ist allerdings wesentlich weiter verbreitet als OpenGL, da es ein Microsoftprodukt ist und fast alle, die am PC spielen verwenden Windows ;)


    Das mit dem Emulator hör ich hier zum ersten Mal (Quelle?)

    Wieso sollen manche Effekte nicht übertragen werden können? Direct3D macht nicht viel mehr als Shader und Ressourcen an die Grafikkarte zu übermitteln, der Weg wird anders sein und evtl das Ergebnis sich unterscheiden, aber im Prinzip ist es möglich