SSD Preisentwicklung

hustbaer

computertrolls schrieb:

hustbaer schrieb:

computertrolls schrieb:

Den Großteil an Daten dürften heutzutage Texturen und Sounddateien ausmachen, die könnte man aber alle problemlos komprimieren. Schade dass das bei Ark scheinbar nicht gemacht wird.

Auch unkomprimierte Texturen und Sounddateien sind mit verlustfreien, generischen Algorithmen quasi nicht komprimierbar.

Das halte ich für ein Gerücht.

Nimm mal ein beliebiges unkomprimiertes Foto und speichere es als PNG Datei ab.
Anschließend vergleiche die beiden Dateigrößen, die PNG Datei wird zwar nicht die Ergebnisse einer verlustbehafteten Kompression, wie das klassische JPG erreichen, aber trotzdem mehr als genug die Datei komprimieren.

Was meinst du warum ich generische Algorithmen geschrieben habe? Weil File-System Compression eben generische Algorithmen verwenden. Und es ging schliesslich um File-System Compression.
PNG dagegen ist spezifisch für Bilddaten.

computertrolls schrieb:

Außerdem habe ich in meinem Posting darüber hinaus nicht einmal die verlustlose Komprimierung gemeint, sondern die verlustbehaftete, die noch stärker komprimiert. S3TC und die dafür üblichen Dateiformate dürften dir sicher bekannt sein.

Ist schon lustig wenn man jemandem erklären muss wovon er eigentlich gesprochen hat...

* Dravere hat geschrieben dass man mit NTFS Compression bei ARK gut 50% rausholen kann.
* Du wolltest daraus den Schluss ziehen dass ARK "so gut wie keinerlei Kompression bei den Dateiformaten" verwendet, und hast dann weiter angemerkt dass der Grossteil der Daten Texturen und Soundfiles sind und man die "problemlos komprimieren" könnte.

Das heisst du unterstellst ARK dass es "so gut wie keine" Kompression für Texturen und Soundfiles verwendet, und begründest diese Understellung mit dem Umstand dass NTFS Compression die Daten von ARK auf etwa 50% komprimieren kann. Was bedeuten würde dass NTFS Compression Texturen und Soundfiles gut komprimieren kann. (Natürlich verlustfrei, da File-System Kompression ja wohl völlig transparent, d.h. auch bitgenau=verlustfrei arbeiten muss.)

Das ist allerdings völliger Unsinn, und ich habe versucht dir zu erklären warum.

hustbaer schrieb:

Das heisst du unterstellst ARK dass es "so gut wie keine" Kompression für Texturen und Soundfiles verwendet, und begründest diese Understellung mit dem Umstand dass NTFS Compression die Daten von ARK auf etwa 50% komprimieren kann.

Dann erkläre doch du mal, wo die 50 % herkommen sollen.
Die EXE ist es bestimmt nicht und ich glaube nicht, dass 3d Geometriedaten oder XML Dateien bei Ark so viele GB benötigen, dass damit am Ende eine Einsparung von 50 % rauskommt.
Es können nur Texturen und Sounddateien sein, weil das bei einem Spiel für gewöhnlich der dickste Platzfresser ist.
Von Videos mal abgesehen, aber die hat heute eh kaum noch ein modernes 3d Spiel.

Wenn du jetzt die 50 % an sich ankreidest, ich habe das nicht geprüft, ich vertraue hier den Daten von Dravere und das seine Aussage hier stimmt.

hustbaer

Ist mir doch Schnuppe wo die 50% herkommen. Ich wollte dir nur zeigen dass die "Logik" die du hier angewendet hast vollkommen krumm ist.

Dravere

computertrolls schrieb:

Dann erkläre doch du mal, wo die 50 % herkommen sollen.

Prüf es doch mal kurz nach, statt wilde Vermutungen und Behauptungen aufzustellen. Entweder durch Rechtsklick der Ordner und dem finden der grössten Ordner im Spiel oder zum Beispiel mit einem Tool wie WinDirStat.

Was ich so las, sind es anscheinend vor allem die Kartendaten, welche unglaublich gross und unkomprimiert rumliegen. Was somit auf Geometriedaten oder ähnliches zurückschliessen lassen würde. Aber statt dem nachzugehen, schliesst du es einfach aus? Ich habe ARK derzeit nicht installiert und kann es daher nicht selber prüfen.

Also gut:

/ARK $ du -sm *
144     _CommonRedist
247     Engine
4       PackageInfo.bin
115652  ShooterGame
2       Tools
1       version.txt

$ cd ShooterGame/
$ du -sm *
1       AssetRegistry.bin
687     Binaries
2       Config
48015   Content
760     Saved
66191   SeekFreeContent
1       ShooterGame.uproject

$ cd SeekFreeContent
$ du -sm *
28724   Maps
33482   Mods
3986    PrimalEarth

$ cd ..
$ cd content
$ du -sm *
1       Cookinfo.bin
47      Effects
1356    EndGame
8       ExampleContent
15      FirePack
109     GunImpacts
696     Localization
3708    Maps
12288   Mods
26      Mountains
351     Movies
5       Ocean
53      Ogg
96      OldAssets
23176   PrimalEarth
514     ReflectionCaptures
1       Repros
5495    ScorchedEarth
2       Splash
6       SplatterDecals
32      steampunk_pack
36      Ultimate_Rocks
7       WoodenPropPack

Die Maps sind in der Tat groß, allerdings kann da alles mögliche drin verpackt sein, auch Texturen.

UnrealEdit habe ich nicht installiert und werde ich auch nicht installieren um jetzt nachzuschauen. Mal abgesehen davon, dass ich nicht weiß, ob man den noch einfach so downloaden kann. Das letzte mal als ich mit UnrealEd gearbeitet habe ist schon > 19 Jahre her.

Hier hat mal jemand eine eigene Map für die Unreal Engine erstellt:
https://answers.unrealengine.com/questions/140118/map-file-size-very-large.html

Folgende Grafik lässt darauf schließen, dass die lightmap für die Map bei der UT Engine einen großen Batzen ausmacht.
https://answers.unrealengine.com/storage/attachments/22547-lightmap.jpg

Eine lightmap ist in der Regel auch eine Textur.

Gruum

hustbaer schrieb:

computertrolls schrieb:

hustbaer schrieb:

computertrolls schrieb:

Den Großteil an Daten dürften heutzutage Texturen und Sounddateien ausmachen, die könnte man aber alle problemlos komprimieren. Schade dass das bei Ark scheinbar nicht gemacht wird.

Auch unkomprimierte Texturen und Sounddateien sind mit verlustfreien, generischen Algorithmen quasi nicht komprimierbar.

Das halte ich für ein Gerücht.

Nimm mal ein beliebiges unkomprimiertes Foto und speichere es als PNG Datei ab.
Anschließend vergleiche die beiden Dateigrößen, die PNG Datei wird zwar nicht die Ergebnisse einer verlustbehafteten Kompression, wie das klassische JPG erreichen, aber trotzdem mehr als genug die Datei komprimieren.

Was meinst du warum ich generische Algorithmen geschrieben habe? Weil File-System Compression eben generische Algorithmen verwenden. Und es ging schliesslich um File-System Compression.
PNG dagegen ist spezifisch für Bilddaten.

Also ich das jetzt mal getestet.
Ich habe zwei Fotos als bmp gespeichert, das eine ist scharf, das andere nicht. Beide Fotos waren vorher mit jpeg komprimiert.
Dann habe ich beide Fotos jeweils in einen komprimierten ntfs-Ordner, in ein zip-Archiev (deflate), in ein 7zip-Archiev (LZMA2:24) und in eine png-Datei gestopft.
Folgende Dateigrößen in (MB) sind raus gekommen:

bmp    ntfs   zip    7zip   png
scharf     34,8   30,7   18,6   14,0   13,8
unscharf   34,8   26,5   12,1   9,60   10,7

hustbaer

Hm, interessant. Noch interessanter wäre natürlich wie es mit Bildern aussieht die nicht vorher verlustbehaftet komprimiert waren.
Hätte ich aber trotzdem ganz anders eingeschätzt. Mein Statement, zumindest so wie es formuliert war, ist damit wohl widerlegt.

z.T. prüfen: würde ich, weil es mich interessiert, aber ich besitze ARK überhaupt nicht, und habe auch nicht vor es mir nur zu diesem Zweck zu kaufen.

computertrolls schrieb:

Eine lightmap ist in der Regel auch eine Textur.

Ich muss zugeben an Lightmaps habe ich nicht gedacht. Und dass man Lightmaps u.U. sehr gut komprimieren kann, evtl. auch mit so etwas einfachem wie dem Algorithmus den NTFS verwendet, kann ich mir noch eher vorstellen. Also eher als "normale" Texturen die typischerweise aus Fotos erstellt werden.

hustbaer schrieb:

computertrolls schrieb:

Eine lightmap ist in der Regel auch eine Textur.

Ich muss zugeben an Lightmaps habe ich nicht gedacht. Und dass man Lightmaps u.U. sehr gut komprimieren kann, evtl. auch mit so etwas einfachem wie dem Algorithmus den NTFS verwendet, kann ich mir noch eher vorstellen. Also eher als "normale" Texturen die typischerweise aus Fotos erstellt werden.

Gut, ich denke dann sind wir uns einig.

Bei normalen Texturen möchte ich aber noch anmerken, dass die im Normalfall im Gegensatz zu Fotos mit einer vollständigen Bildszene, oftmals repetitiv sind und einen bestimmten Farbton aufweisen.
Eine Textur, die bspw. eine rote Mauer aus Backsteinen darstellen soll, dürfte aus vielen Rottönen und wegen den einzelnen Backsteinen aus sich wiederholenden Elementen bestehen.
Ich kann mir gut vorstellen, dass man auch so etwas mit generellen Kompressionsalgorithmen deutlich besser komprimieren kann, als ganze Bildszenen die bspw. aus völlig unterschiedlichen Elementen (z.B. ein grüner Baum, ein rotes Haus, ein silbernes Auto, ein blauer See, ein Sonnenschirm etc.) bestehen.

Häufig hört man daher auch von Contenterstellern, dass Fotos für Texturen oftmals gar nicht so gut geeignet sind und solche Texturen daher bevorzugt mit Algorithmen und Programmen die dafür spezialisiert sind erstellt werden.
Vor allem gibt es bei solchen Mauertexturen die zwingende Anforderung, dass man sie nebeneinander legen kann, ohne das dabei ein bestimmtes Muster bezüglich der Texturkanten erkennbar wird.

computertrolls schrieb:

Ich kann mir gut vorstellen, dass man auch so etwas mit generellen Kompressionsalgorithmen deutlich besser komprimieren kann, als ganze Bildszenen die bspw. aus völlig unterschiedlichen Elementen (z.B. ein grüner Baum, ein rotes Haus, ein silbernes Auto, ein blauer See, ein Sonnenschirm etc.) bestehen.

Gehört zu den Grundlagen von Komprimierung. Ist mit das erste was man lernt wenn man sich damit befasst, gleiche Teile zusammenfassen und beschreiben was es darstellen soll. Vielleicht findest du was auf Wikipedia dazu.