ZFX + Developia

Hallo Leute

Folgendes Problem:
Aktuell convertiere ich alle meine Assets (models, texturen, sounds usw) mit einer eigenen Content Pipeline zu einem Engine internen Format
Leider ändert sich das Format im aktuellem Entwicklungsstand der Engine noch hin und wieder.
Jetzt will ich aber an verschiedenen Rechnern an meiner Engine arbeiten und dafür nicht immer meine Testassets neu importieren müssen, sondern nur 1x und dann hochladen, und optimalerweise beim checkout des engine codes gleich mit ausgecheckt bekommen.

Bisher war ich git-lfs auf github ganz gut aufgestellt. Allerdings komme ich jetzt in Konflikt mit der 1GB Storage Grenze.

Git selber hosten fehlt mir die Zeit und die Muse, ein eigener Webspace mit zippen und upload/download scheint mir recht umständlich.

Wie macht ihr das denn so eure assets zu versionieren/teilen?

Nun, das wird dir nicht gefallen, aber ich habe einen Raspberry PI mit Seafile (vergleichbar zu Dropbox, GDrive, OwnCloud etc...) und Git. Ersteres für generelle Synchronisation zwischen all meinen Geräten, zweiteres für Dinge wo ich Versionshistorie haben will. Ich habe da eine stromsparende 200 GB Speicherkarte drin, für ein bisschen mehr Stromkosten pro Monat kann man aber natürlich auch beliebig externe Festplatten anschließen und hat dann so viele TB, wie man möchte. Und das alles privat und ohne dass man irgendwelchen (US-) Firmen vertrauen müsste. Sind im Dauerbetrieb Größenordnungsmäßig 2€ Strom pro Monat. Allerdings muss man die Einrichtung als Hobby betreiben, wenn man Serveradministrieren hasst, ist das vermutlich ein schlechter Deal. Läuft bei mir seit längerem recht stabil, ab und zu sind mal Kleinigkeiten, major Updates können auch schonmal ein Wochenende Arbeit sein.

Aber es gibt natürlich auch kommerzielle Anbieter. Seafile hat glaube ich auch end-to-end Encryption so dass du dem Serverbetreiber ggf. nicht so viel vertrauen musst.

https://www.seafile.com/en/partner/

Hab da mal schnell durchgeklickt, luckycloud z.B. bietet 50GB Speicher für 4.8€ im Monat an, was ok, aber vlt. nicht großartig ist. Für Owncloud und alle anderen Lösungen wird es ja auch diverse kommerzielle Anbieter geben, da kann man sich ja mal durchklicken und gucken, was einem gefällt.

Ich check das immer mit ein. Also die Rohdaten, in nem separaten Verzeichnis oder sogar Repository. Das Git dazu hostet mein Ex-Zwillingsbruder auf seinem NAS, da haben wir viele Terabyte. Ist für Dich jetzt natürlich nicht die Lösung. Aber wie Du selbst sagtest, braucht man doch auch die Rohdaten immer mal wieder.

Da Du ja nach meinem Wissen allein arbeitest, könntest Du ja wirklich einfach alles in einen Ordner auf irgendnem Webspace rsyncen. Nen VServer mit paar hundert GB kriegst Du für ~12€ pro Monat, und nach dem "ich will diese Linux-Distro" ist das Einrichten eines SSH/SCP-Zugangs eine Frage von Minuten.

Schrompf hat geschrieben: ↑14.10.2024, 21:40mein Ex-Zwillingsbruder

Jetzt muss ich doch mal nachfragen, da du ihn so oft erwähnst und er ja offensichtlich nicht gestorben ist und ihr euch auch nicht verzofft habt: Wie wird man von einem Zwillingsbruder zu einem Ex-Zwillingsbruder?

Insider-Joke, hab ich schon oft wiederholt. Sowohl er als auch ich haben bei der Heirat jeweils den Namen der Frau angenommen. Also sind wir jetzt offensichtlich nicht mehr miteinander verwandt. Ist doch ganz klar.

Vielen Dank euch schonmal für die Antworten.
Ich seh schon wenn es vernünftig sein soll führt kein weg an selber machen vorbei...

Matthias Gubisch hat geschrieben: ↑14.10.2024, 11:21 Hallo Leute

Folgendes Problem:
Aktuell convertiere ich alle meine Assets (models, texturen, sounds usw) mit einer eigenen Content Pipeline zu einem Engine internen Format
Leider ändert sich das Format im aktuellem Entwicklungsstand der Engine noch hin und wieder.
Jetzt will ich aber an verschiedenen Rechnern an meiner Engine arbeiten und dafür nicht immer meine Testassets neu importieren müssen, sondern nur 1x und dann hochladen, und optimalerweise beim checkout des engine codes gleich mit ausgecheckt bekommen.

Bisher war ich git-lfs auf github ganz gut aufgestellt. Allerdings komme ich jetzt in Konflikt mit der 1GB Storage Grenze.

Git selber hosten fehlt mir die Zeit und die Muse, ein eigener Webspace mit zippen und upload/download scheint mir recht umständlich.

Wie macht ihr das denn so eure assets zu versionieren/teilen?

Ich habe in Git nur Code. Assets liegen auf einem getrennten Server zentral und die Stats / Werte / Configs / Whatever / Verknüpfungs- und Metadaten zu den Assets in einer Datenbank

Generell wird ja empfohlen, immer nur die Ausgangsdaten in die Versionsverwaltung zu packen, also nicht die daraus erzeugten Dateien. Deine Compiler-Ausgaben (.exe, .dll, .obj, Debug-Symbole) packst du da ja auch nicht rein, oder? Alles, was du per Knopfdruck lokal erzeugen kannst, gehört für mich nicht in die Versionsverwaltung. Das bläht alles nur unnötig auf.

Was du aber machen kannst, ist den jeweils letzten Stand dieser erzeugten Dateien ohne Versionsverwaltung auf ein Netzlaufwerk zu legen.

Ja ich weis dass man normal nur die Rohdaten einchecket, aber leider kann ich meine Testdaten "noch" nicht einfach per Knopfdruck erzeugen da ich noch kein CLI für meinen content converter habe sondern nur eine GUI, deshalb ist hier noch viel Handarbeit nötig.
Deshalb wollte ich die Testszene gerne mit einchecken, auch um bei verschiedenen SourceStänden immer valide Testdaten zu haben.

Die Rohdaten sind aber zum einen noch größer als die konvertierten Assets, und zum anderen ändern sich die quasi nie solange keine neuen Elemente zur Testscene dazukommen. Deshalb liegen die aktuell einfach auf einem Webserver und in meinem Sourceverzeichnis liegt ein script zum download der selbigen.

Aktuell (seit die Scene zu groß für Github ist...) ist der Workflow wenn sich das Engine Format geändert hat:
1. Script zum download der Rohdaten aufrufen.
2. Editor starten, alles neu (von Hand) importieren (weil es noch kein CLI gibt, aber auch ansonsten ist es nervig bei jedem Wechsel alles neu zu erzeugen)
3. Benutzen

Step 2 ist der der mich stört. Vor allem wenn ich zwischen branches/source Versionen hin und her wechsel müsste ich jedes mal die Daten neu konvertieren. Deshalb hatte ich die bisher eingecheckt, jetzt wird das aber zu groß für Github und deshalb bin ich jetzt auf der Suche nach anderen Lösungen.

Aber vielleicht setzte ich dann doch Git auf meinem Webserver auf (oder doch gleich Perforce...)

Unabhängig davon hab ich neulich auf Twitter den Take gelesen, dass man doch auch generierten Code einchecken sollte. Die Poster*in meinte, dass es die Debug-Hölle wäre, wenn man z.B. durch ein lokales Update ne neue Protobuf-Version benutzt und obwohl alles Byte für Byte dem Stand im Git entspricht, plötzlich irgendwas sich anders verhält als vorher. Du kannst quasi nie wieder den vorherigen Zustand herstellen und es sieht auch noch so aus, als wäre gar nix verändert. Fand ich eine spannende Ansicht.

Ich hatte ja schon geschrieben, dass ich eh alles kritiklos pushe, Rohdaten wie Daten. Das einzige Projekt, was da ob den Datenmengen nennenswert als Beispiel dienen könnte, waren die Splitterwelten. Und da hatten wir halt alles gepusht, und es war eine große Erleichterung, wenn Du einer Grafikerin einfach nen Subversion-Zugang geben konntest und sie hat nur pullen müssen, um alles live laufbereit auf die Platte zu kriegen. Selbst Executables und manche Spielstände.

Da Du ja aber Einzelkrieger bist, muss Dich das glaube ich nicht interessieren. Da tut's auch einfach ein Zip auf irgendnem Webspace. Hast Du ja auch schon. Machst Du Deinen Import noch skriptfähig und packst alle nötigen Konfigparams dazu aus der GUI in eine JSON und Du bist eigentlich startklar.

Schrompf hat geschrieben: ↑Gestern, 11:40 Unabhängig davon hab ich neulich auf Twitter den Take gelesen, dass man doch auch generierten Code einchecken sollte. Die Poster*in meinte, dass es die Debug-Hölle wäre, wenn man z.B. durch ein lokales Update ne neue Protobuf-Version benutzt und obwohl alles Byte für Byte dem Stand im Git entspricht, plötzlich irgendwas sich anders verhält als vorher. Du kannst quasi nie wieder den vorherigen Zustand herstellen und es sieht auch noch so aus, als wäre gar nix verändert. Fand ich eine spannende Ansicht.

Das war Casey Muratori IIRC. Er mag in großen Teilen Recht haben; da ich aber selber schon mit 65 GiB großen Git-Repos gearbeitet habe (und das ist heute nichtmal die Größe eines Spiele-Patches!) kann ich sagen, dass einen die Performance da schon enorm ausbremst. Ich checke meine Compiler mit ein; dann habe ich völlig reproduzierbare Builds mit nur ~150 MiB Overhead. Bei den Assets hilft das aber wohl nicht weiter.

Ich bin eigentlich mit der Seafile / git Kombination sehr zufrieden (wobei man Seafile entsprechend durch andere Software ersetzen könnte): Der Asset-Order wird einfach auf allen Geräten immer direkt synchronisiert. Dauert bei sehr großen Updates manchmal ein paar Minuten (dann halt kurz im Web surfen oder EMails checken), aber ab dann verhält sich alles, als hätte ich es auf diesem Rechner gemacht. Genau 0 zusätzliche Logik.

Ich habe auch ein git-Repo für Assets, aber das ist dafür gedacht, alle paar Wochen / Monate den aktuellen Zwischenstand zu dokumentieren. Da ist dann entsprechend auch die exe drin, quasi ein direkt lauffähiger, historischer Build.

Einzige Ausnahme ist btw. der Build-Ordner von C++. Ich verwende CMake und die Projektdateien und Zwischenkompilate sind explizit ausgenommen, weil ich auf unterschiedlichen Rechnern die Bibliotheken in unterschiedlichen Verzeichnissen installiert habe. Das verhindert so Probleme, und bedeutet in der Praxis, dass halt ab und an mal CMake neu läuft und das Projekt neu kompilliert wird.

Am wichtigsten bei der automatischen Synchronisation via Seafile ist mir, dass ich nicht daran denken muss. Vergisst man das händische Synchronisieren einmal, fängt man ruck zuck damit an, an einer neuen Version Änderungen vorzunehmen, und Assets kann man in der Regel nicht mergen, wie man das bei Code kann. Im schlimmsten Falle merkt man, dass man vergessen hat die Änderungen am anderen PC hochzuladen, und kommt dann ggf. erstmal gar nicht dran.