Performanter - Blueprint vs. StaticMesh

  • Servus Leute,


    ich hätte da mal eine Frage an die Performance-Spezialisten unter euch.

    Verwende ich in meinem Projekt modulare Gebäude, ist es dann für die Performance besser wenn ich jedes komplette Gebäude in ein eigenes Blueprint packe, oder jedes Stockwerk in ein eigenes Blueprint oder das Gebäude "normal" im Viewport zusammensetze und dann in ein Static Mesh umwandele?

    Gibt es da überhaupt Unterschiede in der Performance? Oder evtl. andere Vor-/Nachteile die man mit der einen Version machen kann, mit der anderen aber nicht?


    Bei dem einen oder anderen AssetPack gibt es immer wieder mal vorgefertigte Blueprints (z.B. mit Häusern oder sonstigen Zusammenstellung verschiedener Einzelassets) - macht es Sinn diese zu nutzen?.


    Bin für jede Antwort offen.


    Grüße an die Community.

  • Das kann man so pauschal nicht beantworten und dass ist auch nicht in einem Satz erklärt.

    1. Es wird immer das ganze Mesh gezeichnet. Würdest du ein Haus zu einem Objekt Mergen, so wird das Haus immer komplett angezeicht oder komplett nicht angezeigt.

    2.Das Backface Culling zeichnet ja schonmal die Rückseiten eines meshes nicht.

    3.Das Camera Occusion Culling zeichnet Meshes nicht die nicht im Sichtbereich des Players ist.

    Das gibt dir schonmal einen Performance Boost wenn du es richtig einsetzt.

    4.Sieht man das Gebäude von außen könnten zb nur die Fassadenteile sichtbar sein. Auch wenn man durch ein Fenster sehen kann, ist die Frage ob man wirklich alle Möbel zeigen möchte?

    Um dann Perforance zu sparen, könntest du alle Möbel im Gebäude zu einem Objekt Mergen. Das wäre dann besser als wenn jeder Schrank als einzelner Drawcall existiert. Die Räume zu Mergen könnten auch LODs sein. Von außen sind ein Raum ein Objekt, betritt man den Raum sind es einzelne Meshes.


    Bedenke folgendes und musst auch sehen das sich diese Argumente teilweise beißen;


    1. Möglichst wenig Meshes den jedes Mesh kostet mindestens einen Drawcall (Mindestens weil zb auch die Schattenberechnung und viele andere dinge Drawcalls kosten.

    2.Nun könntest du ja sagen dann Merge ich das ganze Level zu einem Mesh, dann hab ich ja nur noch ein Drawcall.

    Ja das ist ist zwar richtig (wenn man die anderen Faktoren außeracht lässt) Aber dafür funktioniert wie oben beschreiben das Culling nicht mehr.

    3. Große Meshes brauchen sehr viel Speicher. Wenn du nur große Meshes hast, wird dein Spiel nachher 500gb groß :)

    Auch wenn einige glauben, das durch die UE5 der Polycount keine Rolle mehr spielt, sag ich dir, dass man auch in Zukunft nicht verschwenderisch sein wird. (Was den Polycount angeht)


    4.Ich würde an deiner Stelle eher auf das Culling setzen, Alles was du zusammen Mergen kannst wie beispielsweise ein Schrank kannst du zusammen Mergen. Es macht keinen Sinn das ein Schrank aus einzelnen Bretter Meshes wo jedes Brett als separates Mesh existiert.

    Ein Gebäude würde ich aus Modularen Wandteilen bauen. zb: Hausecke, Wand, Wand mit Loch für Fenster, Wand mit Loch für Tür,

    Die Fenster und Türen würde ich auch extra Mesh machen. So kannst du beispielweiseweise auch verschiedene Fenster einbauen.

    Wenn du außerhalb vom Haus bist, ist das Haus komplett leer. Du kannst Einrichtungen als ein Mesh anzeigen. Ich würde nicht alle Einrichtungen zusammen mergen den sonst hast du wieder das Problem: Wenn ein Raum von außen gesehen wird, müssen alle anderen auch gezeichnet bzw berechnet werden.

    Sobald du zb das Haus betrittst, könntest du alle merge Räume ausblenden (Könnte ein Sublevel sein) und tust die Einrichtungen als einzel Meshes einblenden (könnte auch ein Sublevel sein. Das Culling blendet dann alle Meshes aus, die in dem Moment nicht vom Player gesehen werden.

  • ja ein bp bietet denk ich schon mehr möglichkeiten. da hast bei den details dann die meshes aufgelistet, die könnt man dann eben auch austauschen und nicht nur elements bei den materials, müsst halt nur die selbe größe haben.^^ wenn nicht alles physik hat, oder so, könnts auch sinnvoll sein.


    das gemergedte kann in unreal ja nicht wieder auseinander genommen werden und hat quasi einen ganz neuen eintrag im content, das bp verwendet nur die vorhandenen.


    wär vl auch fraglich, ob es besser geht, wenn man in einem bp mehrere meshes oder gemergedte meshes unterbringt, man kann ja ein bp auch die form ändern lassen. ich nehme an, das gibt es damit auch wieder etwas gespart wird.


    wenn du noch länger damit beschäftigt bist, kannst dir was ersparen indemst bps für die stockwerke anlegst und teile von ihnen so austauschst.


    viel glück!

  • Erst mal kyodai , Feal  Sleepy :

    vielen Dank für die Informationen.


    Sleepy Danke für die sehr ausführliche Antwort. Man muß diese ganze Culling-Geschichten eigentlich für jedes einzelne Objekt extra machen oder werden Backface Culling und Camera Occusion Culling automatisch durch die Engine gemacht?


    Wenn ich möchte, dass aus einer gewissen Entfernung nur die Fassade des Gebäudes berechnet wird und noch nicht die Inneneinrichtung, dann müsste ich ja für jedes Objekt innerhalb des Gebäudes eine Culling-Entfernung festlegen -Richtig (bzw. eine, wenn die Inneneinrichtung komplett als StaticMesh vorliegt)?


    Das mit den Sublevels hört sich plausibel an, aber auch erst mal richtig schwierig.

    Über Sublevels hab ich mich noch nicht eingelesen. Wenn ich aber durch eine offene Tür schon in den Raum reinsehen kann, dann müsste er ja schon geladen werden... Das mit dem switchen zwischen Sublevel als gemerged Raum und dem als einzelne Meshes hab ich - denke ich mal - verstanden. Doch wie geht das? Ich müsste der Engine ja dann sage: "Sobald der Spieler in einer Nähe von XXX Units ist, entlade das gemergede Sublevel und lade das Sublevel mit den einzelnen Meshes (um die ganzen Cullings überhaupt nutzen zu können) - hab ich das so richtig verstanden? Muss ich mich erst mal einlesen...


    Man könnte also sagen, dass relativ kleine Objekte, welche aus mehreren Teilen bestehen (Schuppen, Verkaufsstände mit Inhalt, Bretterhaufen (o.ä.), Heuballen, Fässer usw.) als Static Meshes umgewandelt bzw. zusammengefasst werden sollten (1 Drawcall, die ganzen Cullings), ganze Häuser jedoch in Einzelteilen, getrennt von der Inneneinrichtung inkl. Boden/Decke gebaut werden sollten.


    Ein Gebäude im BP wird ja - wenn ich es richtig verstanden habe - genau wie ein StaticMesh behandelt was die DrawCalls angeht. In diesem Falle gäbe es ja keine Verbesserung.


    Danke erst mal für die Antworten.

    Da hab ich erst mal ein paar Stichworte, an denen ich mich ausprobieren kann.

  • Sleepy Danke für die sehr ausführliche Antwort. Man muß diese ganze Culling-Geschichten eigentlich für jedes einzelne Objekt extra machen oder werden Backface Culling und Camera Occusion Culling automatisch durch die Engine gemacht?

    Beim Backface Culling steuerst du dass im 3D Programm über Normals. Du kennst das Problem vielleicht wenn die Normals eines 3D Meshes falsch rum sind und ein Mesh teilweise durchsichtig ist. Durchsichtig sind sie, weil die Rückseite nicht gezeichnet wird. Beim Foliage zb brauchst du deswegen ein Twoside Shader der beide Seiten des Blatts zeichnet.

    Das Camera Occlusion Culling ist standardmäßig an man kann es aber auch in den Settings ausschalten. Dieses Culling macht die Engine komplett automatisch ohne das man etwas einstellen muss.

    Wenn ich möchte, dass aus einer gewissen Entfernung nur die Fassade des Gebäudes berechnet wird und noch nicht die Inneneinrichtung, dann müsste ich ja für jedes Objekt innerhalb des Gebäudes eine Culling-Entfernung festlegen -Richtig (bzw. eine, wenn die Inneneinrichtung komplett als StaticMesh vorliegt)?

    Achtung hier nichts durcheinander bringen. Das Occlusion Culling funktioniert NICHT über die Distanz. Dafür gibt es das Distance Culling das findest du bei den Actors/Volumes und heißt korrekt Cull Distance Volume. Hier kannst du tatsächlich einstellen ab welcher Entfernung zum Player ausgeblendet bzw eingeblendet werden soll.

    Occlusion Culling blendet alles aus was nicht im Sichtbereit (im Frustum) des Players liegt. Es zeichnet aber immer ganze Meshes.

    Das mit den Sublevels hört sich plausibel an, aber auch erst mal richtig schwierig.

    Über Sublevels hab ich mich noch nicht eingelesen. Wenn ich aber durch eine offene Tür schon in den Raum reinsehen kann, dann müsste er ja schon geladen werden... Das mit dem switchen zwischen Sublevel als gemerged Raum und dem als einzelne Meshes hab ich - denke ich mal - verstanden. Doch wie geht das? Ich müsste der Engine ja dann sage: "Sobald der Spieler in einer Nähe von XXX Units ist, entlade das gemergede Sublevel und lade das Sublevel mit den einzelnen Meshes (um die ganzen Cullings überhaupt nutzen zu können) - hab ich das so richtig verstanden? Muss ich mich erst mal einlesen...

    Sublevels könntest du zb so einsetzen. Wenn du das Spiel startest, wird nur das Menü geladen. Das Menü ist das Root Level.

    Nun kannst du im Menü zwischen zwei Landschaften wählen, jede Landschaft ist ein Sublevel. Solange du dich im Menü aufhälst und dein Name etc eingibst, werden im Hintergrund bereits beide Levels geladen. Sobald du auf Start drückst, geht es direkt los ohne große Ladezeiten.

    Du könntest auch Inneneinrichtung als Sublevel laden. Aber du machst ja nicht aus jedes inneneinrichtung eines gebäudes ein Sublevel. Das macht mehr Sinn wenn du zb in die Nähe eines Dungeon kommst.

    Das schöne bei Sublevel ist das man eben ein ganzes Level vorladen kann um es dann flott zu starten (ohne große Ladezeiten)


    Man könnte also sagen, dass relativ kleine Objekte, welche aus mehreren Teilen bestehen (Schuppen, Verkaufsstände mit Inhalt, Bretterhaufen (o.ä.), Heuballen, Fässer usw.) als Static Meshes umgewandelt bzw. zusammengefasst werden sollten (1 Drawcall, die ganzen Cullings), ganze Häuser jedoch in Einzelteilen, getrennt von der Inneneinrichtung inkl. Boden/Decke gebaut werden sollten.

    Ja möglichst wenig Meshes bedeuten weniger Drawcalls aber zu große Meshes sind auch wieder schlecht für die Performance. Das zusammenfassen muss sinnvoll sein. Aber zb ein Verkaufsstand mit Waren würde ich aus einem Mesh machen weil der Spieler entweder den Verkaufsstand sieht oder nichts davon sieht. Das ist besser als jede Vase die es dort zu kaufen gibt, als extra Mesh zu machen.


    Ein Gebäude im BP wird ja - wenn ich es richtig verstanden habe - genau wie ein StaticMesh behandelt was die DrawCalls angeht. In diesem Falle gäbe es ja keine Verbesserung.

    Blueprints müssen berechnet werden.

    Ein Drawcalls kosten alles was auf dem Monitor gezeigt werden soll. Ein Drawcall ist quasi ein Brief mit Informationen der von der CPU zur GPU gesendet wird, mit dem Hinweis: "Hey zeichne das mal" Mehr Objekt sind gleich mehr Briefe zum Lesen. Tust du mehre Meshes zusammanfassen, sind es zwar weniger Briefe dafür ist der Brief dann aber etwas größer. (Lieber weniger Briefe und dafür größere Briefe)

    Baken ist für die Performance immer besser als wenn dein Licht in Rechtzeit berechnet werden muss. Baken kannst du keine Meshes die erst später durch Blueprints eingeblendet werden. Die Meshes sind dann immer moveable und das Licht muss erst in Echtzeit berechnet werden.

    Baken ist immer besser was die performance angeht.


    Das kommt immer auf den Anwendungsfall an was jetzt besser ist.

  • also ich muss ehrlich sagen, dass ich nicht glaube, dass es die professionellste herangehensweise wäre alle gebäudeteile so zu bearbeiten, dass sie von hinten nicht sichtbar sind. das wär ja eine heidenarbeit und die immer auszutauschen würde ja auch ganz schön was kosten. ich bezweifle, dass leveldesigner so arbeoiten.


    dass ein bp im bezug auf ein gebäude das selbe wie ein mesh ist, würde wahrscheinlich voraussetzen, dass man aus einem germegedten mesh ein bp gemacht hast. dann würde die veränderung zu einem bp quasi wieder leistung kosten. du müsstest überlegen ob du jeden der wenigen gebäudeteile oder die vielen verschiedenen zusammensetzungen im content browser eingetragen haben willst. größere module immer wieder zu verwenden würde sich bestimmt lohnen.


    außerdem wird es eine schwierige frage sein, wie sehr es sinn macht die inneneinrichtungen zu instanzieren wenn in jedem gebäude ein paar gleiche objekte vorkommen.


    wenn du die kleinen gegenstände, wie im schuppen und bei verkaufsständen nicht einzeln brauchst, solltest du sie mergen.


    du könntest dir außerdem überlegen ob du eher im level oder bei der camera ansetzt, dieses video über Distance based Texture Scale Blending hab ich schon ein paar mal hier gepostet:


    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.

  • ich bezweifle, dass leveldesigner so arbeoiten.

    Ich auch nicht, sie machen es direkt richtig und nicht erst falsch ^^


    du könntest dir außerdem überlegen ob du eher im level oder bei der camera ansetzt, dieses video über Distance based Texture Scale Blending hab ich schon ein paar mal hier gepostet:

    Egal was du am Material änderst, es bleibt nur das Material...

    Wenn du ein Objekt per Material immer kleiner machst, bleibt die Position des Meshes trotzdem die gleiche und somit wird es auch berechnet.


    Am klügsten ist es, mit LODs zu arbeiten und ab ner bestimmten Distanz dann durchs "culling" ausblenden.

    Es gibt ne "MaxDrawDistance" und ne "MinDrawDistance".


    Wenn die Räume vorher schon ersellt werden und nicht erst vom Spieler, kann man auch das ganze per Texturen faken, wie in diesem Video bei 2:00

    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.

  • ja danke, das video schau ich mir demnächst gern an. zu meinem letzten post muss ich anmerken, dass ich das nur als ein beispiel gebracht hab, für eine ersparnis die von der player cam und nicht dem leveldesign ausgeht.


    außerdem hab ich angenommen, das würde auch schwer ins gewicht fallen. ich hatte ja vor einigen monaten von problemen mit dem texture streaming pool berichtet, alle texturen waren immer wieder komplett verwaschen.


    dann hab ich mir chivalry 2 gekauft, is ja mit unreal gemacht. das war doch eher ein fehler, ein paar tage spielt mans gern aber dann wirds fad. ich hab mir dann grundsätzlich auch gedacht, es könne kein so hoher aufwand gewesen sein, das zu programmieren. außerdem funktioniert da die punktetafel nicht, das demotiviert so richtig.


    auf jeden fall hat man in diesem spiel auch andauernd probleme mit dem texture streaming pool, sogar in den videosequenzen am anfang der mageren drei multiplayer level, taucht bei jedem ansehen dieser fehler auf. ich bin mir sicher, bei den videos hätte man es noch so bearbeiten können, dass alles gut ausschaut. aber wegen dem problem während des spiels mach ich mir auch sorgen wegen meinem eigenen projekt.


    ich mein, wenn sie nicht einmal die videos nachbearbeitet haben, werden sie auch nicht alle möglichkeiten für die spielzeit ausgenutzt haben, aber so unkompliziert wird es dann halt auch nicht sein.


    ich hab mich dann entschieden das leveldesign großflächiger zu machen und auch an den orten wo gekämpft wird weniger meshes zu verwenden.


    das sag ich auch um wieder zurück zum thema zu kommen. tatsächlich hab ich mir das kurz nach dem absetzen des letzten posts noch gedacht und will nicht nur mein abschweifen kaschieren.^^ ein größeres level verglichen mit meshes die sich weiter auseinander befinden, wirkt sich natürlich positiv auf die performance aus.