Ich habe mir überlegt das ich das Thema hier zu posten damit es den Entwicklern leichter fällt das Spiel an die verschiedenen Pc Systeme anzupassen

Ich fange mal an:


KCS [184202] - Gamer-PC Intel i7-3770 Quadcore 4x 3,4GHz (Turbo bis
3,9GHz)
8GB DDR3-1333
1000 GB SATA3 (6gb/s) Update: Samsung SSD 840 PRO
Nvidia Geforce GTX650 2048MB GDDR5 (3DVision+DirectX11) Update: Nividia Geforce GTX 970 4096MB GDDR5 (ASUS STRIX)
22xDVD-RW
ASUS P8B75-M LX
USB3.0
5.1 Sound
Gigabit-LAN
Cardreader
500W Update: 680W
Modding-Gehäuse
Microsoft Windows 7 Home Premium 64-Bit



Update: Erstinstallation der Schicksalsklinge HD läuft Extrem flüssig+Intro yea

Core i7 Frequenz grad unbekannt
12GB RAM
GeForce GTX 480 mit 768MB
2TB HDD @ 5400rpm

Flüssig auf 1680 x 1050 (mehr schafft der Monitor nicht) in Verbindung mit der 2. höchsten Quali Stufe (Beautiful?)

Leute, so bringt dass nix. Flüssig oder nicht ist sehr subjektiv. Um da wirklich Vergleiche ziehen zu können solltet ihr die FPS mit angeben. Ausserdem die Auflösung, die Qualitätsstufe und wo ihr gemessen habt.

Objektivster Vergleich wäre eine Messung bei einheitlicher Auflösung und einheitlicher Qualitätsstufe an immer der selben Stelle im Spiel. Sonst ist ein Vergleich schwierig, bis unmöglich.

Ok

Ich wollte eigentlich ein Video mit dem Programm Fraps machen doch wenn ich es wiedergeben möchte läuft es nur so 30 sekunden und dann ist schluss kennt sich da jemand von euch aus?

[quote='Sebastian Maier','index.php?page=Thread&postID=44513#post44513']Ich wollte eigentlich ein Video mit dem Programm Fraps machen doch wenn ich es wiedergeben möchte läuft es nur so 30 sekunden und dann ist schluss kennt sich da jemand von euch aus? [/quote]Vollversion kaufen und so?

Das Problem ist ganz einfach zu Lösen ich nehme meine webcam und das Programm (FPS) und nehme alles auf und lade es hier hoch

Hier mal auf einem

i7 3770k
16GB Ram
MSI 7870 HAWK
Spiel + OS auf getrennten OCZ Vertex 3 SSDs

Was man trotz 100ms Abtatstung nicht sieht sind die Framedrops die es immer wieder gibt sobald man läuft/sich bewegt/dreht. Das Spiel läuft an sich zwar flüssig, stockt aber immer wieder kurz (friert für ganz kurze Zeit komplett ein)... lässt sich ein bisschen schlecht erklären.

Das Spiel hat aus meiner Sicht ein Streaming Problem. Bleibt man stehen hat man ein konstantes Bild (auch beim drehen), die Ruckler treten auf sobald Daten nachgeholt werden müssen. Da das Spiel sich ingesamt gerade mal 1GB Ram schnappt bin ich mir nicht sicher ob die gesamte Lokalität überhaupt in den Ram geladen wird. Was auffällig ist, ist das die CPU Last konstant relativ hoch ist (23-25%, was für 2 ausgelastete Kerne spricht (Im Taskmanager verteilt sich das Ganze auf 4 Kerne, wobei einer fast voll ausgelastet ist). Hier wird viel zu viel Arbeit auf einen Kern gepackt, das könnte auch erklären warum so viele Probleme mit der Performance haben. Ob die Craftys da was dran drehen können weiß ich allerdings nicht

Also bei mir ruckelt es etwas inThorwal ,auf Manrin allerdings ist das schon anders da stockt das Spiel regelrecht - 2 sec ,
ansonsten läuft es aber recht flüssig.

Quad Core Q6600 2,4GHz
4 GB - RAM
ATI Radeon HD 5700 -1024 MB
W7.U 64Bit
Auflösung 2048 x 1152

Die Sache mit dem "Stocken" habe ich mir heute durch Zufall angeschaut, das liegt wohl daran, dass viele Texturen auch nach dem Levelload erst "onDemand" nachgeladen werden. Und nachdem wir (unoptimierterweise) zu viele Einzeltexturen herumfliegen haben, gibt es da "Ruckler" mit bis zu 300ms.

@Friday, die Idee mit dem "mehrere Kerne auslasten" ist eine supernette, kannst aber genausoschnell auch wieder knicken - Unity läuft auf einem Kern, und damit Schluss. Und soweit mir bekannt ist, läuft keine andere Engine auf mehr als einem CPU-Kern, weil die Concurrency-Probleme und -Bugs und der Sync-Overhead mehr Verlustleistung und Entwicklungsaufwand bedeuten würden, als dadurch gewonnen wäre. Klar "könnte" man einen zweiten Kern mit dem Nachladen der Texturen beschäftigen, nachdem der Hauptkern aber trotzdem auf die Texturen warten muss, und "intelligentes Preloading" wie zB in der ID-Tech5-Engine derzeit wohl noch nicht Teil der Unity-Implementation ist (könnte auch daran liegen, dass zwischen den Lizenzen der beiden Engines etwa 250.000 US$ liegen), werde ich da einen anderen Weg drumrum finden müssen, zum Einen natürlich durch Assetoptimierung, zum Anderen aber auch durch einen "Kameraschwenk" hinter dem Ladebildschirm, damit genau diese Ruckler "verdeckt" passieren und nicht erst, wenns spannend wird respektive vom Spieler zu sehen ist.

[quote='craftyfirefox','index.php?page=Thread&postID=45433#post45433']Die Sache mit dem "Stocken" habe ich mir heute durch Zufall angeschaut, das liegt wohl daran, dass viele Texturen auch nach dem Levelload erst "onDemand" nachgeladen werden. Und nachdem wir (unoptimierterweise) zu viele Einzeltexturen herumfliegen haben, gibt es da "Ruckler" mit bis zu 300ms.

@Friday, die Idee mit dem "mehrere Kerne auslasten" ist eine supernette, kannst aber genausoschnell auch wieder knicken - Unity läuft auf einem Kern, und damit Schluss. Und soweit mir bekannt ist, läuft keine andere Engine auf mehr als einem CPU-Kern, weil die Concurrency-Probleme und -Bugs und der Sync-Overhead mehr Verlustleistung und Entwicklungsaufwand bedeuten würden, als dadurch gewonnen wäre. Klar "könnte" man einen zweiten Kern mit dem Nachladen der Texturen beschäftigen, nachdem der Hauptkern aber trotzdem auf die Texturen warten muss, und "intelligentes Preloading" wie zB in der ID-Tech5-Engine derzeit wohl noch nicht Teil der Unity-Implementation ist (könnte auch daran liegen, dass zwischen den Lizenzen der beiden Engines etwa 250.000 US$ liegen), werde ich da einen anderen Weg drumrum finden müssen, zum Einen natürlich durch Assetoptimierung, zum Anderen aber auch durch einen "Kameraschwenk" hinter dem Ladebildschirm, damit genau diese Ruckler "verdeckt" passieren und nicht erst, wenns spannend wird respektive vom Spieler zu sehen ist.[/quote]
Bei mir ist der Kern 1, 5, und 7 *Nur* 15 Prozent ausgelastet ist net viel (Spiel läuft im Hindergrund weiter)

[quote='craftyfirefox','index.php?page=Thread&postID=45433#post45433']Die Sache mit dem "Stocken" habe ich mir heute durch Zufall angeschaut, das liegt wohl daran, dass viele Texturen auch nach dem Levelload erst "onDemand" nachgeladen werden. Und nachdem wir (unoptimierterweise) zu viele Einzeltexturen herumfliegen haben, gibt es da "Ruckler" mit bis zu 300ms.

@Friday, die Idee mit dem "mehrere Kerne auslasten" ist eine supernette, kannst aber genausoschnell auch wieder knicken - Unity läuft auf einem Kern, und damit Schluss. Und soweit mir bekannt ist, läuft keine andere Engine auf mehr als einem CPU-Kern, weil die Concurrency-Probleme und -Bugs und der Sync-Overhead mehr Verlustleistung und Entwicklungsaufwand bedeuten würden, als dadurch gewonnen wäre. Klar "könnte" man einen zweiten Kern mit dem Nachladen der Texturen beschäftigen, nachdem der Hauptkern aber trotzdem auf die Texturen warten muss, und "intelligentes Preloading" wie zB in der ID-Tech5-Engine derzeit wohl noch nicht Teil der Unity-Implementation ist (könnte auch daran liegen, dass zwischen den Lizenzen der beiden Engines etwa 250.000 US$ liegen), werde ich da einen anderen Weg drumrum finden müssen, zum Einen natürlich durch Assetoptimierung, zum Anderen aber auch durch einen "Kameraschwenk" hinter dem Ladebildschirm, damit genau diese Ruckler "verdeckt" passieren und nicht erst, wenns spannend wird respektive vom Spieler zu sehen ist.[/quote]Hab ich mir fast gedacht. Passt auch gut das 300ms Fenster vom Gefühl her. Interessanterweise kann man die "Lags" nicht monitoren
Da ich aber nicht wusste/weiß was die Unity Engine kann oder nicht kann kam von mir die etwas dumme Aussage. Hätte ja sein können das man gewisse Workloads splitten kann. Das eine Engine in der Region nicht die Features einer Cryengine, idtech oder ähnlich bieten kann ist klar.
Meinst du der "unsichtbare Kameraschwenk" hilft? Wie ich feststellen konnte tritt das Problem verstärkt eigentlich nur auf wenn man sich bewegt. Wie viel Texturdaten hat Thorwal denn insgesamt?
Könnte man nicht mehr von vornherein in den Ram laden? Schicksalsklinge ist da ja seeeehr genügsam, selbst nach Stunden des spielens. Mehr wie 1,25GB hatte ich noch nicht

[quote='craftyfirefox','index.php?page=Thread&postID=45433#post45433']Die Sache mit dem "Stocken" habe ich mir heute durch Zufall angeschaut, das liegt wohl daran, dass viele Texturen auch nach dem Levelload erst "onDemand" nachgeladen werden. Und nachdem wir (unoptimierterweise) zu viele Einzeltexturen herumfliegen haben, gibt es da "Ruckler" mit bis zu 300ms.

@Friday, die Idee mit dem "mehrere Kerne auslasten" ist eine supernette, kannst aber genausoschnell auch wieder knicken - Unity läuft auf einem Kern, und damit Schluss. Und soweit mir bekannt ist, läuft keine andere Engine auf mehr als einem CPU-Kern, weil die Concurrency-Probleme und -Bugs und der Sync-Overhead mehr Verlustleistung und Entwicklungsaufwand bedeuten würden, als dadurch gewonnen wäre. Klar "könnte" man einen zweiten Kern mit dem Nachladen der Texturen beschäftigen, nachdem der Hauptkern aber trotzdem auf die Texturen warten muss, und "intelligentes Preloading" wie zB in der ID-Tech5-Engine derzeit wohl noch nicht Teil der Unity-Implementation ist (könnte auch daran liegen, dass zwischen den Lizenzen der beiden Engines etwa 250.000 US$ liegen), werde ich da einen anderen Weg drumrum finden müssen, zum Einen natürlich durch Assetoptimierung, zum Anderen aber auch durch einen "Kameraschwenk" hinter dem Ladebildschirm, damit genau diese Ruckler "verdeckt" passieren und nicht erst, wenns spannend wird respektive vom Spieler zu sehen ist.[/quote]
Wie wäre es mit einem sogenanannten HighResTexturePack?

@Friday, man könnte natürlich intelligentes Preloading im Hintergrund umsetzen, da ist aber die "production pipeline" etwas länger, weil ich der Engine trotzdem irgendwie sagen muss, was sie wann braucht. Entweder komplett manuell, oder über eine entsprechende Software, die sich den Level anschaut und bestimmt, wann man wo hinkommt, und zusätzlich noch eine Heuristik, die mir aus der Spielerbewegung heraus "errät", was als nächstes benötigt wird. Insgesamt: nicht unsere Preiskategorie.

Grundsätzlich steht ohnehin noch die Optimierung unserer Assets, vor allem und ganz speziell der Häuser und der NPCs ins Haus, wir suchen da grade nach Möglichkeiten, das gebacken zu bekommen. Allein das müsste die Ruckler um 50 - 80% reduzieren. Dann noch diesen "Kameraschwenk" dazu, und die Ruckler sollten sich innerhalb enger Grenzen bewegen. Kommt aber alles noch .

Und @Sebastian, solang wir die "Low-Res"-Texturen (was sie nicht sind, die lösen teilweise mit 2048x2048 auf) nicht im Griff haben, steht "High-Res" völlig außer Frage.

[quote='craftyfirefox','index.php?page=Thread&postID=45683#post45683']@Friday, man könnte natürlich intelligentes Preloading im Hintergrund umsetzen, da ist aber die "production pipeline" etwas länger, weil ich der Engine trotzdem irgendwie sagen muss, was sie wann braucht. Entweder komplett manuell, oder über eine entsprechende Software, die sich den Level anschaut und bestimmt, wann man wo hinkommt, und zusätzlich noch eine Heuristik, die mir aus der Spielerbewegung heraus "errät", was als nächstes benötigt wird. Insgesamt: nicht unsere Preiskategorie.

Grundsätzlich steht ohnehin noch die Optimierung unserer Assets, vor allem und ganz speziell der Häuser und der NPCs ins Haus, wir suchen da grade nach Möglichkeiten, das gebacken zu bekommen. Allein das müsste die Ruckler um 50 - 80% reduzieren. Dann noch diesen "Kameraschwenk" dazu, und die Ruckler sollten sich innerhalb enger Grenzen bewegen. Kommt aber alles noch .

Und @Sebastian, solang wir die "Low-Res"-Texturen (was sie nicht sind, die lösen teilweise mit 2048x2048 auf) nicht im Griff haben, steht "High-Res" völlig außer Frage.[/quote]Ok

[quote='Friday_13th','index.php?page=Thread&postID=45531#post45531']Wie viel Texturdaten hat Thorwal denn insgesamt?[/quote]
[quote='craftyfirefox','index.php?page=Thread&postID=45683#post45683']weil ich der Engine trotzdem irgendwie sagen muss, was sie wann braucht.[/quote]
[quote='craftyfirefox','index.php?page=Thread&postID=45683#post45683']die lösen teilweise mit 2048x2048 auf[/quote]

Dazu bleibt die Frage nach der maximalen Größe. Wenn man schlicht alles für eine Szene laden könnte dann bräuchte man kein intelligentes und dynamisches laden. Während des Stage-Loading-Screen alles in den RAM und die Ruckler sind weg. Eventuell je nach Qualitätseinstellung statt 2k*2k etwas weniger, wenn es dafür komplett geladen werden kann. Ob alles passt kann man ja vorher berechnen denn die Unity scheint ja wie an den Logfiles ersichtlich Zugang zur VRAM-Größe zu haben.

Das Problem scheint bei der Unity ja bekannt und das brute-force-preloading ein gangbarer Workaround für manche Szenarien.

Jup, der Kameraschwenk hinter dem Ladebildschirm ist schon fix eingeplant

[quote='craftyfirefox','index.php?page=Thread&postID=45835#post45835']Kameraschwenk[/quote]

Wahrscheinlich bin ich nur zu dumm um das zu verstehen, aber was genau definierst du denn als "Schwenk"? Denn die Kamera müsste ja komplett alle in der Szene verbauten Prefabs mindestens je einmal sehen.

Ahhhhh, coole Sache. Is ja mal interessant so ein bisschen das technische dahinter zu verstehen. Bin gespannt

Ja, damit wirklich *alle* Texturen geladen werden schon. Ich vermute aber stark, dass es dabei nur um die initiale Ladung der Einzeltexturen geht, sprich dass da alle 30-45° Drehung beim ersten Betreten vor allem in Thorwal gleich mal 30-40 Texturen nachgeladen werden müssen - deshalb auch das "Stottern". Wenn mal 3 oder 4 "hinterherkommen" sollte das nicht so wild sein. daher würde ich einfach mal versuchen, genau an der Ladeposition eine 360°-Drehung zu machen, dann können wir uns ja das Ergebnis mal anschauen, und Notfalls muss ich das halt bei jedem verfügbaren Wegpunkt zusätzlich auch noch machen, damit sollte so gut wie jede mögliche Position abgedeckt sein. Ich mache mir nur sorgen, dass das die Ladezeiten der einzelnen Dörfer massiv erhöhen wird, im Bereich von mehreren Sekunden länger als jetzt schon.

Da bei mir alles auf SSDs liegt geht wahrscheinlich noch halbwegs. Habs mir bei einem Kollegen mal angeschaut... das hätte ich so freiwillig nicht gespielt. Und so schlecht ist dem sein System nun wahrlich auch nicht. Stell mich gern als Testopfer zur Verfügung
Hm, werden die eigentlich jedes mal geladen und wieder verworfen? Weil das Problem bleibt bestehen, selbst wenn ich Thorwal 10 mal komplett ablaufe.