ZFX + Developia

Hallo zusammen

nach langer Zeit arbeite ich auch mal wieder intensiv an einem Projekt (gibt hoffentlich bald Bilder in der Projektvorstellung)

Bisher habe ich immer alles was ich so hatte auf github versioniert.
Da meine Contentdateien, insbesondere die Cubemaps for PBR/IBL, neuerdings teilweise deutlich über das 100MB Filesize Limit von Github hinausgehen wollte ich mal Fragen wie/wo ihr denn so grossen Content versioniert.


Zippen und jedesmal beim auschecken entpacken finde ich keine Option, genausowenig wie die Cubemaps jedes mal aus den einzelnen Seiten neu zu backen ;)

git lfs ist bekannt, aber vielleicht gibt es ja noch andere tolle Möglichkeiten

Erstmal: sehr cool, dass Du wieder an was baust.

Dann: kniffliges Problem. Zippen bringt Dir ja auch nix, weil Git selbst ja auch schon bei der Übertragung zippt. Aber ich vermute, die GitHub-Dateigrößengrenze bezieht sich auf die entpackte Datei.

Subversion soll laut diverser Berichte besser mit Binärdateien umgehen können. Trifft aber wahrscheinlich auf ne Geschmacksfrage und ist mit ner bestehenden History im Git auch nachträglich nicht mehr zu ändern.

Binär irgendwo ablegen und ein curl ins Makefile?
Sub-Repositoy mit nur den Daten woanders?
Eigenen VServer mieten und selbst hosten? Wenn Du bissl Bock auf Konfigurieren hast, kannst Du auch auf meinem einziehen, habe da noch etwa 150GB Platz.

Haha, den Plan hatte ich auch mal. Ich wollte am Anfang Git auf meinem Server installieren, und das BFA Repo da hosten. Alter was haben wir rumgeflucht :D

Und dann gehts ja nach Git erst richtig los. Denn die ganzen Sachen die Github erst bequem machen brauchst du ja auch noch. Wir haben es dann gesteckt.

Das mit der Dateigrösse ist schwierig. Die Git Hoster haben für Lau alle ihre Limits. Die wollen ja auch an was verdienen.

Wäre es denn eine Idee die Cubemaps anders zu komprimieren? Sind die denn überhaupt komprimiert? In welchem Format sind die denn grade? Oder eventuell mit der Auflösung runter zu gehen? Um eben doch unter den 100 Mb zu bleiben?

Das Filelimit bezieht sich auf die ungepackte Datei vor dem hochladen leider…

VServer hätte ich selber, bisher hab ich die Arbeit mir da git oder perforce (für so große Dateien evtl die bessere alternative) immer gescheut.
Bei GitHub kann man nicht mal mit einem Bezahlaccount mehr als 100MB pro file....

Die sind aktuell so zwischen 200 und 300 MB Groß, für die Radiance und Irradiance Maps könnte man evtl noch weiter runter gehen, bei der Skyboxmap sollte es eher in die andere Richtung gehen also statt 4k 8k pro Seite….

Kurzfristig kann man mit niedrigerer Auflösung und Texturekompression sicher noch was raushohlen aber Dauerlösung ist das aus meiner Sicht keine, da der Content eher wächst als schrumpft….
Spätestens wenn ich aber mal aus irgendeinem Grund die Rohdaten (photoshop) daten mit versionieren möchte stoße ich hier auch wieder auf das Problem.

Vermutlich wird es darauf rauslaufen eine Testszene bei den Quelldaten zu haben und die Daten für das fertige Spiel woanders zu hosten.
So ein Plain git oder perforce Server kann ja nicht so schwer zum einrichten sein.

Wenn noch jemand eine schlaue Idee hat trotzdem immer her damit.

VServer hätte ich selber, bisher hab ich die Arbeit mir da git oder perforce (für so große Dateien evtl die bessere alternative) immer gescheut.
Bei GitHub kann man nicht mal mit einem Bezahlaccount mehr als 100MB pro file....

Ich halte es nicht für sinnvoll, so große Dateien überhaupt in git einzuchecken. Jede Änderung an einer Datei (sei es auch nur ein Pixel) macht das Repo um 100 MB größer, welche bei einem erneuten auschecken mit runtergeladen werden. Wenn du also 10 Änderungen machst, ist dein Repo schon über 1 GB groß.

Für Content finde ich die "klassische" Versionierung mit Datei + Ordner (Datei.old), wo dann einfach die Datei mit fortlaufender Versionsnummer gespeichert ist. Diesen Ordner kann man dann irgendwo zentral ablegen (File Share auf einem Server), um die Datensicherung und Versionshistorie zu gewähren, aber wenn man das Repo auscheckt, sollte man nur die neueste Version der Datei erhalten

Grüße
Felix

Also ich habe git auf einem raspberry laufen, mit tortoiseGit als Client habe ich da ehrlich gesagt nie ein Frontend auf dem Server vermisst - Repositories anlegen ist 1 Befehl und da ich hauptsächlich alleine daran arbeite, brauche ich die ganze Benutzerverwaltung überhaupt nicht.
Tatsächlich habe ich zwei Repositories, ein schlankes das im Wesentlichen nur Code enthält und eins für Binaries+Assets. Allerdings commite ich letzteres nicht so häufig, da git mit großen Binärdateien halt doof ist.

All das liegt darüber hinaus aber noch in einer seafile-Cloud und das ist auch die Lösung die ich vorschlagen wollte. Der Unterschied ist letztendlich, dass die Cloud nur eine begrenzte Geschichte hat (z.B. 1 Monat), große Binärdateien die man nicht mehr braucht dafür aber eben nicht dauerhaft Speicher verbrauchen. Im Wesentlichen ist die Idee also, dass ich die alten Versionen überhaupt nicht mehr interessant finde und die Geschichte nur benutze, falls mal aus versehen etwas editiert wurde, was zurückgesetzt werden soll oder so. Assets die ich nicht mehr benutze lösche ich dann in der Regel auch nicht sondern verschiebe sie in einen "unused" Ordner. Eine klassische Geschichte gibt es für Assets somit nicht, aber das ist irgendwie ok so.

Was ich aber durchaus mache, ist immer wenn irgendein signifikanter Entwicklungsstand erreicht wurde, die aktuelle Version komplett zu archivieren. Das ist in erster Linie nostalgisches Interesse, manchmal ist es einfach nett die Entstehungsgeschichte nachvollziehen zu können. Genau dafür ist das oben erwähnte Binär-Repository auch eigentlich gedacht. Aber man kann natürlich genausogut für jede Version eine nummerierte Zip erstellen, weil ich hier eh keine der üblichen Funktionen mehr benutze (z.B. diffs zwischen verschiedenen Versionen angucken).

bintray.com wird oft genutzt zum Aufbewahren von Builds. Ist soweit ich weiss gratis für OSS.
Die scheinen aber auch git lfs zu supporten:
https://www.jfrog.com/confluence/displa ... positories

Vielen dank fuer die vielen Tips und Hinweise

Werd den Code zusammen mit einer entsprechend kleinen Testszene auf GitHub lassen, und den Rest erstmal nur per FTP auf meinem V-Server parken.
Dazu ein Skript dass das ganze per rsync synchronisiert. Damit hoffe ich das Problem fuers erste mal erschlagen zu koennen.

Das Filelimit bezieht sich auf die ungepackte Datei vor dem hochladen leider…

Ich glaube da haben wir uns missverstanden. Ich meine nicht gepackt. Ich meine ein komprimiertes File Format. Am Grausamsten wäre natürlich Jpg wegen den Fragmenten. Aber auch PNG kann eine gute Kompression bieten.

Nein ich hab dich schon verstanden, die Antwort bezog sich auf die Frage von Schrompf ob zippen was bringt, weil GitHub beim hochladen das ja sowieso macht.

Die Cubemap fuer den Background erzeugt aus 4k Texturen ist aktuell als .dds mit BC3 gespeichert und hat knapp 200MB
Hier kann ich aber mit der Aufloesung nicht mehr weiter runter gehen, da soll es wie gesagt eher in die andere Richtung gehen.
Die Cubemaps fuer die Beleuchtung hab ich jezt mit etwas rumspielen auf ca. 90MB runter (zumindest fuer meinen Testhintergrund), ist aber auch eher knapp am Limit.

Deshalb leider keine langfristige Loesung. Mich wundert ehrlich gesagt dass es da anscheinend nix vernuenftiges gibt…

PS: Sorry fuer die Schreibweise aber ich habe hier gerade keine deutsche Tastatur zur Hand...

Also git ist mit Weboberfläche auf einem Linuxsystem nicht schwer zu installieren und braucht nur mäßig Konfiguration + einen apache als Webserver.
Das sieht dann so aus: https://git.hts-software.de/cgit.cgi/.

Wegen der repo größe ... git kann nur die aktuelle Version herunterladen. Man muss nicht die ganze Historie kopieren wenn man nur die aktuelle braucht. Als Entwickler hat man so die Historie lokal.

Matthias Gubisch hat geschrieben: ↑30.04.2019, 10:37 Mich wundert ehrlich gesagt dass es da anscheinend nix vernuenftiges gibt…

Doch gibt es: Git LFS

Habs dir ja schon weiter oben geschrieben dass Du z. B. bintray verwendet kannst als LFS Repo.

Wir verwenden btw Nexus von sonatype.

Schrompf hat geschrieben: ↑26.04.2019, 13:44 Erstmal: sehr cool, dass Du wieder an was baust.

Das geht jetzt zwar arg am Thema vorbei, aber wo es gerade um Leute von damals geht: Es gab früher mal dieses 2D Strategiespiel im C&C Stil von irgendeiner deutschen Gruppe. Ich glaube es hieß "Die verbotene Welt" oder so und das Team dahinter "Sechster Sinn" oder irgendwie so. Die Webseite war größtenteils grau mit ein wenig rot und im Wesentlichen so, wie damals Webseiten eben aussahen :D
Ich hatte mich vor längere Zeit mal gefragt, was wohl daraus geworden ist (es schien schon ziemlich weit zu sein), konnte dann im Netz aber nichts mehr dazu finden. Weiß jemand noch wer und was das war?

Keine Ahnung vom Spiel aber der Name sagte mir was, habe gerade die ehemalige Seite gefunden - scheint aber relativ tot zu sein.
http://sechsta-sinn.com oder http://sechsta-sinn.de
Facebook und Twitter haben 2013 den letzten Eintrag - ich schätze Real-Life™ hat mal wieder zugeschlagen :-P

Jaaaa, genau das war es. Ich glaube ich musste bei "Matthias Gubisch" daran denken, aber die Typ aus deren Team hieß wohl "Matthias Gall". Tjo, schade, das Video das es davon gibt sah so gut aus :)