Jump to content
Unity Insider Forum

Maximaler Polycount pro Scene ?


freak36558

Recommended Posts

Hallo,
Nur mal zur groben Orientierung...
Gibt es grobe Richtwerte für den maximalen Polycount pro Scene ca ?
Bereits gegooglet und auf Faktoren wie 300.000 Tri´s maximal im Sichtfeld... 
Meines erachtens kommen faktoren wie Texturen / Materialien hinzu und einige andere natürlich auch noch... Physik, Partikelsysteme u.s.w.

Aktuell habe ich eine Scene mit rund 1 Mil. Tri´s ca...
16 Hallen, die sich alle zusammen ca 30 Texturen Teilen (Spec, AO u.s.w. schon in den 30 mit drin) kurzum, versuche möglichst einzelne Texturen so häufig als möglich wieder zu verwenden, das diese eben bei mehreren Objekten vorkommen...
Da allerdings noch einige Triangles hinzukommen sollen wäre meine frage in wie weit man ca gehen kann... 
Natürlich hängt es bisschen vom System ab... 

Mit einem älteren System habe ich es mal getestet (mit 75FPS recht flüssig gelaufen)
AMD X4 (4x 3,2Ghz)
R7 200 Series 
8 Gig Ram 

Habe mit einem anderen System heutige Leistungsklasse ebenfalls ca 75FPS gehabt... (Limiter?)

Da es sich um ein Messegelände handelt, kommt natürlich noch Ausstellungsmaterial in die besagten Hallen...
Meine überlegung wäre, sofern eine einzelne Scene damit überfordert ist...
Ob die möglichkeit besteht eine Open-World Scene allein für den Outdoor bereich zu machen, und jeweils einzelne Scenen für die Hallen Inhalte zu haben... Die über kurze Ladescreens beim betreten erst geladen werden.

Gesamt geplanter Polycount wird ca um 8 bis 10 Mil. liegen...

Erst einmal schonmal vielen dank für eure Ratschläge bin dann mal gespannt...

Link zu diesem Kommentar
Auf anderen Seiten teilen

Zitat

Natürlich hängt es bisschen vom System ab... 

Die Anzahl der sichtbaren Polygone die man ohne große Leistungseinbußen auf dem Bildschirm darstellen kann hängt nicht nur ein bisschen sondern sehr stark vom System ab.

Ich habe das Wort "sichtbar" deswegen unterstrichen, weil Unity (so wie so ziemlich jede andere moderne Gameengine) hauptsächlich die Polygone berechnet, die auch auf dem Bildschirm sichtbar sind, d.h. wenn wenn sich ein Objekt hinter einem anderen befindet oder außerhalb des Sichtbereiches der Camera, und somit auf dem Bildschirm nicht angezeigt wird, dann wird auch keine Rechenleistung für die Darstellung dieser Polygone verschwendet. (Bei Dingen wie physikalischen Berechnungen sieht die Sache wieder etwas anders aus). Zudem gibt es auch noch so schöne Systeme wie LOD (Level of Detail), mit denen man nochmal einiges an Grafikleistung einsparen kann. Desweiteren denke ich nicht, das es sich so sehr auf deine FPS Rate auswirkt, ob du nun 30 oder 300 Texturen verwendest. (Korrigiert mich bitte jemand wenn ich da falsch liege)

Alles in allem denke ich nicht, dass man bei der Anzahl der maximal sichtbaren Polygone einen pauschalen Wert veranschlagen kann, da es von mehreren Faktoren abhängig ist. Ich würde sagen, hier gilt wie bei so vielen Dingen: So viel wie nötig so wenig wie möglich.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Also die Anzahl der Texturen ist jetzt nicht das große Problem für die Ausgabe. Es sind die Materialien, also die Shader.
Wenn viele Objekte sich ein und das selbe Material teilen können und auch nicht unterschiedlich beleuchtet werden, kann man Leistung sparen.
Hat aber jedes Objekt ein eigenes Material, ist es egal, ob diese unterschiedlichen Materialien die gleiche Textur nutzen oder nicht.
Die Anzahl der Texturen wirkt sich aber natürlich auf den Speicher in der Grafikkarte aus. Der ist irgendwann mal voll und muss möglicherweise dann immer mit neuen Texturen refresht werden. Das würde dann auch zu Einbußen in der Framrate führen oder kurze Lags verursachen.
Je aufwendiger die Shader sind, desto höher wird die Anzahl der Drawcalls. Somit sollten entfernte Objekte auch einfacherer Shader nutzen, wenn es umsetzbar ist.

Wie unsigned schon geschrieben hat, ist immer ausschlaggebend, wieviele Polys gleichzeitig zu sehen sind. Die Szene an sich kann ruhig ein paar Mio. Polys haben, aber das was maximal auf dem Bildschirm zu sehen ist, sollte eben nicht zu hoch sein.
Ich glaube von uns kann keiner genau sagen, wieviele Polys für welche Grafikkarte noch gut sind. Das wirst du selber raus finden müssen. Und zwar mit all den Lichtern, Shadern und Filtern die du nutzen möchtest. Du musst dir natürlich dafür auch eine Zielgrafikkarte nehmen. Also auf welcher Generation soll es noch mit 60 fps in hoher Qualität laufen können.

Du hast ja den Profiler an Board und kannst recht gut überprüfen, welcher Prozess die meiste Leistung verbraucht und wann du in einen kritischen Bereich rein kommst.
Wenn du merkst, dass eine gewisse Kamerasicht mächtig Energie braucht, musst du da eben etwas optimieren.

Link zu diesem Kommentar
Auf anderen Seiten teilen

  • 2 weeks later...

mein Wald hatte vor der Optimierung 11mio polis im screen. Nachher noch 5-6.

Die Menge in der ganzen Szene macht wenig Sinn, wegen Culling und LOD. Vielleicht so 100 - 500mio. Hab versucht ein Screenshot für ne Minimap zu machen und dabei ist mir das Spiel abgestürzt. Musste das ganze aufteilen.

Läuft mit einer gtx 980 grenzwertig bei 60fps, manchmal knickts auf 45 ein. Relfektierendes Wasser war damit aber nicht mehr drin.^^

Das nur Poligone berechnet werden, die auch sichtbar sind wage ich zu bezweifeln. Wenn ich direkt vor einem Haus stehe und der Wald dahinter liegt, ändert das nichts an den fps. Möglicherweise ist es bei Terrain-Bäumen nur von der Kamera-Position abhängig?

 

Um mal eben zu testen ob eine voll besetzte Szene noch käuft, kannst du ein paar Dummy-Objekte erstellen. Gibt denen ein paar Poligone mehr als nötig. Und wenn du die später durch die richtigen Objekte ersetzen willst, kann man das ganz einfach per Skript machen, falls die Positionen bereits ungefär stimmen. Hilft auch zum testen ob die Räume groß genug sind, bzw nicht zu groß. Leere Räume wirken irgendwie erstaunlich klein.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Archiviert

Dieses Thema ist jetzt archiviert und für weitere Antworten gesperrt.

×
×
  • Neu erstellen...