Git: praca z modelami i teksturami

Git: praca z modelami i teksturami
chalwa
  • Rejestracja:około 7 lat
  • Ostatnio:ponad rok
  • Postów:109
0

Pracuje na codzień z kodem repozytoriach git. Ostatnio bawię się trochę grafiką. Szukam informacji jak się sprawuje git do wersjonowania projektów graficznych. Macie jakieś doświadczenie z tym?

Zastanawiam się jak będzie z rozmiarem repozytorium i szybkością działania repozytorium lokalnego, czy są jakieś triki, żeby czyścić stare commity?

obscurity
  • Rejestracja:około 6 lat
  • Ostatnio:około 3 godziny
2

"A car won't take your job, another horse driving a car will." - Horse influencer, 1910
flowCRANE
Moderator Delphi/Pascal
  • Rejestracja:ponad 13 lat
  • Ostatnio:około 4 godziny
  • Lokalizacja:Tuchów
  • Postów:12175
3
chalwa napisał(a):

Szukam informacji jak się sprawuje git do wersjonowania projektów graficznych.

Zwróć uwagę nie na to jakiego typu pliki chcesz wrzucić do repozytorium, a na to, jakie korzyści będziesz z tego mieć. A korzyści są bardzo przyjemne i dokładnie takie same jak w przypadku plików z kodem źródłowym. Masz doświadczenie w tym temacie, więc sam doskonale wiesz co można zrobić w systemie wersjonowania.


Porzykład z powietrza — masz w grze kupę ilonek np. do menusów, które chcesz wymienić na nowy zestaw. Robisz nowy branch, eksperymentujesz, szukasz najlepszego zestawu i konfiguracji, nie ruszając głównej gałęzi. Jesteś zadowolony z osiągniętych efektów to merge'ujesz gałęzie, a jeśli nie, to ubijasz gałąź i wracasz do tego co miałeś.

Jak byś to zrobił mając grafiki poza repo?


Pracuję nad własną, arcade'ową, docelowo komercyjną grą z gatunku action/adventure w stylu retro (pixel art), programując silnik i powłokę gry od zupełnych podstaw, przy użyciu Free Pascala i SDL3. Więcej informacji znajdziesz na moim mikroblogu.
edytowany 3x, ostatnio: flowCRANE
Zobacz pozostałe 6 komentarzy
flowCRANE
Jeśli dwaj graficy pracują jednocześnie nad jednym plikiem na dwóch branchach, to problem nie leży w Gicie, a w zarządzaniu. Bo dokładnie to samo mogę powiedzieć o modyfikowaniu jednego modułu z kodem źródłowym, gdzie jeden deweloper modyfikuje górę pliku, a drugi dół. Tak więc argument z czapy.
obscurity
akurat to że dwóch developerów modyfikuje różne części tego samego pliku źródłowego i trzeba to mergować zdarza się przy niemal każdym releasie, ciężko żeby każdy miał przydzielony swój moduł skoro cały team zajmuje się jednym modułem. Twierdzisz że nigdy nie miałeś merge conflictów a jeśli są to oznacza błąd w zarządzaniu?
flowCRANE
Dokładnie to samo mogę powiedzieć o wieloosobowej pracy nad zasobami graficznymi — tyle że w przypadku grafik żadnych konfliktów nie będzie, bo to nie kod źródłowy. Widzisz problem tam gdzie go nie ma, chyba tylko po, aby się dla zasady przyczepić.
obscurity
hę? powiedziałem że mergowanie plików graficznych nie ma sensu i że się to nigdy nie zdarza. Ty się przyczepiłeś twierdząc że to samo można powiedzieć o plikach źródłowych. Nie zgadzam się - mergowanie plików źródłowych jest normalną praktyką
flowCRANE
No to spoko — wszystko wyjaśnione.
Spine
  • Rejestracja:około 22 lata
  • Ostatnio:minuta
  • Postów:6693
3

Ja wszystko wrzucam normalnie do githuba.
Ale w projekcie są małe pliki. Nie ma większych niż 10MB.

Git-LFS nie ufam. Nie dość, że sensowne użytkowanie jest płatne, to jeszcze pod spodem projekt jest dzielony na dwie usługi.

Do dużych projektów w Unity 3D zalecają wersjonowanie w:

  • Plastic SCM,
  • Perforce.

Niestety obydwa rozwiązania są płatne.


🕹️⌨️🖥️🖱️🎮
edytowany 1x, ostatnio: Spine
obscurity
ja włączyłem do unity na githubie i sobie chwalę - repo przyspieszyło wielokrotnie i nie zaużyłem minusów, 10MB to już jest duży plik, zresztą limit to 50MB
Spine
10MB to strzeliłem. Tak jak teraz patrzę, to nie przekraczają 2MB ;)
obscurity
no u mnie też, co nie zmienia tego że jest ich sporo i zwłaszcza pierwotny upload był na tyle wolny że zdecydowałem że muszę poszukać rozwiązania
piotrpo
  • Rejestracja:ponad 7 lat
  • Ostatnio:20 dni
  • Postów:3277
0

@Spine: Jeżeli to jest ten sam perforce, z którym miałem do czynienia lata temu, to najgorszemu wrogowi nie życzę... Ale faktycznie miał niezłą funkcję, która może się dobrze sprawdzić w przypadku plików binarnych, czy ogólnie takich, gdzie merge jest niemożliwy czyli "blokowanie".

Jeżeli pracujesz sam nad tymi grafikami, to może wystarczy włączenie historii plików w Windows?

chalwa
  • Rejestracja:około 7 lat
  • Ostatnio:ponad rok
  • Postów:109
0

Żeby trochę rozjaśnić to chodzi mi głównie o modele w blenderze (~5k tris), tekstury quixel mixer (1024x1024), GIMP, pliki .png .obj .dds. Do projektów w unity może kiedyś wrócę, ale nie w najbliższym czasie. Nie zamierzam walczyć z konfliktami, raczej nie będę tych plików z nikim dzielić.

Ostatni projekt nad którym siedziałem cały zajął 30MB z kopiami _1, _2, _gotowe ;)

edytowany 1x, ostatnio: chalwa

Zarejestruj się i dołącz do największej społeczności programistów w Polsce.

Otrzymaj wsparcie, dziel się wiedzą i rozwijaj swoje umiejętności z najlepszymi.