Czemu ludzie się tego nie uczą...

[Kroopson]

Hej.

 

Od dłuższego czasu poszukujemy ludzi na stanowisko Pipeline TD i zastanawia mnie czemu generalnie jest aż taka posucha.

W porównaniu z tym tematem znalezienie programisty np Java do backendu webserwisów to pikuś.

Regularnie dostaję propozycje pracy z całego świata - UK, Chin, Kanady, Niemiec co znaczy że tam też brakuje na tyle że chcą ściągać ludzi z drugiego końca świata (pozdrowienia dla rodzimej ekipy TD w Weta ;) ). Ja rozumiem że jak ktoś jest artystą to ciężko jest zostać artystą/programistą ale bez przesady; aż tak trudne to to nie jest, a warunki zatrudnienia o klasę lepsze niż dla "zwykłego artysty".

 

Po co to piszę - po to że może któremuś z młodszych kolegów zapali się lampka że jest do wypełnienia całkiem ciekawa nisza na rynku z praktycznie zerową konkurencją, a po kilku latach jak się komuś znudzi pisanie narzędzi to może pracować już dalej jako "regularny programista".

 

Mówiąc krótko... Y U NO LEARN?! :)

[jaras]

może nie umio?

[polka dot]

może dla Ciebie się zapali lampka, że skoro Ciebie ktoś nauczył, że warto się uczyć, to teraz czas nauczyć tego młodych?

[Hris]

A co "cza" umieć żeby być na stanowisku Pipeline TD powiedzmy w wersji alpha-junior-beginner ? W sensie żeby rozpocząć?

[olaf]

aż tak trudne to to nie jest, a warunki zatrudnienia o klasę lepsze niż dla "zwykłego artysty".

 

Programowanie jest cholernie trudne. W wielu software housach pracują ludzie, którzy zostają developerami i zarabiaja na tytule, kryjąc się w cieniu innych. Poziom jest tragicznie niski, szybko się wypalają albo są ciągle przesuwani do innych zespołów. Bycie dobrym programistą jest cholernie rzadkie.

 

Egzotyczne stanowiska wymagają ekspozycji - nie możesz polegac na 15 kolegach z zespołu z których ktoś rozwiąże Twój problem.

Programowanie to jedna z tych rzeczy, które wymagają nadprzeciętnej inteligencji, a ta jest bardzo unikatowym assetem. Ludzie nie idą na samotne stanowiska, bo jest spory strach, że wyjdzie na jaw ich brak kompetencji.

Jeżeli stworzycie wokół TD aure fajnej relaksującej pracy, ludzie przyjdą chętnie. 95% to będą zwykłe miernoty (podobnie jak w software housach) ale przyjdą ;)

[Sayja]

Programowanie jest wciąż prostsze od pracy artystycznej :)

Mam wrażenie, że zwyczajnie mało jest osób znających takie środowiska, albo nie są zainteresowani pracą u kogoś. Jestem też w stanie zrozumieć, że ich marzeniem nie jest pipeline i jeśli się rozwijają to nie są ukierunkowani na niszę. Programiści mają teraz morze możliwości, a Pipeline TD to tylko wysepka, który wymaga naprawdę rzadkiego połączenia paru zainteresowań.

[olaf]

Programowanie jest wciąż prostsze od pracy artystycznej :)

To interesujące. Możesz rozwinąć?

[Kroopson]

A co "cza" umieć żeby być na stanowisku Pipeline TD powiedzmy w wersji alpha-junior-beginner ? W sensie żeby rozpocząć?

 

"Klasyczna" ścieżka jest taka że ktoś dużo animuje/modeluje i musi wykonywać dużo powtarzalnych czynności. Jedni będą klikać (i jest to ok), inni są "kreatywnie leniwi" i szukają sobie sposobu na ułatwienie sobie życia. Zaczyna się od kopiowania outputu z historii komend w Maya, później pierwsze funkcje, pierwsze klasy i narzędzia GUI. W końcu człowiek więcej programuje niż modeluje/animuje, zaczyna się zabierać za tematy typu automatyzacja zarządzania plikami, cache'owanie animacji, procesowanie plików, renderfarmy.

 

Druga ścieżka to riggerzy. W dzisiejszym świecie rigger który nie programuje to nie rigger a granica między pipeline TD a riggerem jest baaardzo rozmyta.

 

Trzecia ścieżka (jedna z kluczowych osób w moim zespole tak właśnie weszła w temat) to wejście prosto z poziomu programisty pythona, baz danych i webdevu. Dla takich ludzi taka praca jest dość egzotyczna bo mamy bardzo różnorodne tematy (poza VFX/Gamedevem rzadko się chyba zdarza żeby ktoś pisał jednocześnie full stack webserwisy, narzędzia w Qt, pluginy do Maya i konfigurował serwery na linuxie).

 

Co trzeba umieć żeby zacząć? Trzeba umieć programować w pythonie na takim poziomie żeby być w stanie napisać samodzielnie jakieś narzędzia do modelowania, zapisywania plików, jakiś pose library albo narzędzia do rigowania.

Warto znać podstawy linuxa nawet w gamedevie bo masę automatyzacji robi się na serwerach linuxowych.

No i trzeba być przygotowanym na ciągłą naukę i warunki pracy znacznie bardziej "hardkorowe" niż np w software house'ach. Tu nie ma biur na 50 piętrze w centrum, korpo lunch'ów i swag'u. Za to jest ciekawie i dość atrakcyjnie finansowo (może nie w porównaniu do programistów w banku ale nie jest źle).

 

 

Widzę że mój post wzbudził trochę fermentu ;) Dobrze - o to chodziło ;)

[Hris]

Kroopson - dziękuję za tak super szczegółowy opis 3 scieżek dojścia. Tak sobie myślę że no faktycznie jednak sporo pracy jest przy tym Pipeline TD...szczególnie że pewnie musisz znać ze 2-3 języki (python to rozumiem totalna podstawa, potem pewnie C++ i javascript też pewnie bo jakieś webowe aplikacje do obsługi czegoś z przeglądarek też trza ogarniać...). Jak tak teraz myślę że muszę co roku jakiegoś nowego softu się uczyć (choćby jego podstaw) żeby być nie "do przodu" a tylko na bieżąco z tym co w CG community się dzieję to chyba jest trochę podobnie do tego Pipeline TD (choć mniej tak zwanego "kreatywnego lenistwa" - ja nie wymyślam narzędzi, tylko kombinuje jak z 10-15 softów które mam skorzystać by się nie naklikać w jedym skoro w drugim ta opcja już jest albo jest skrypt do tego softu który to obsłuży).

Niemniej w branży gdzie ja siedzę (wizki architektoniczne i trochę produktowej) niby zastój...ale to pozory. Kiedyś pracowałem w Cinema 4D (8 lat), potem Sketchup (od 2006 roku) i 3ds Max i Vray i tak od 12 lat pojawił się Corona Renderer, w Vray'u 3.6 pozmieniali samplowanie (DOF wychodzi tragiczny jak się pracuje po staremu na lokalnych samplach), pojawił się Marvelous Designer (jeszcze nie kupiłem, póki co oglądam tutki wieczorami) Substance Designer i Substance Painter (już kupione i się uczę), po drodze okazało się że czasem nie idzie zyć bez Sculptu więc albo blender (podstawy już mam, bo z Cinema 4D i 3ds Maxa sporo w blendku jest podobieństw) albo Zbrush (też kupiony i się uczę)... wiadomo Photoshopy i Illustratory są ok, ale weszło Affinity Photo i Designer - też trza było choćby podstawy ogarnąć, masowe zmiany zdjęć w XNView - niby prosty soft, ale bez klikania się nie da- też trza umieć, ostatnio pojawił się B2M Substance , potem gdzieś po drodze ForestPack'a trza było ogarnąć i RailClone'a w wersji Lite...od 10 lat dłubię rośliny ręcznie ale pojawiły się narzędzia takie jak GrowfX - chociaż podstawy trza znać, więc znam...ale pojawił się ATree3D - szybszy i prostszy - też opanowałem. Potem ATile3D - znowu trza było się nauczyć skryptu...Potem po drodze After Effects i Edius bo co się wyrenderuje w klatkach to trzeba poskładać a co nagrane kamerą trza pomontować...Nie wspomnę że od 3 lat rządzi fotogrametria i zanim pojawił się Agisoft czy Zephyr to składałem fotogrametrię przy pomocy 3 softów darmowych ale wszystkie trza było znowu opanować...No i ostatni hit - teraz Unreal Engine, już wersja 4.2 - nie wiem kiedy to ogarnę, a klienci czekają na to by każdy dostarczał coś interaktywengo...I jeszcze udźwiękawiam swoje animacje - znam Samplitude, Orion Synapse 8.6, Jeskola Buzz Machines, Audacity, Adobe Encoder'a i parę innych softów do robienia muzy...O fotografii i lightroomie (tudzież Rawtherapie) nawet nie chce mi się pisać, bo to podstawa działania przy zdjęciach...

No i teraz się zastanawiam czego będę musiał się uczyć w ciągu dalszych lat żeby nadążać...Pewnie w Pipeline TD jest podobnie, tylko jeszcze intensywniej :)

[deshu]

"Klasyczna" ścieżka jest taka że ktoś dużo animuje/modeluje i musi wykonywać dużo powtarzalnych czynności. Jedni będą klikać (i jest to ok), inni są "kreatywnie leniwi" i szukają sobie sposobu na ułatwienie sobie życia.

 

O, to to ja! :-P

 

Co trzeba umieć żeby zacząć? Trzeba umieć programować w pythonie na takim poziomie żeby być w stanie napisać samodzielnie jakieś narzędzia do modelowania, zapisywania plików, jakiś pose library albo narzędzia do rigowania.

 

Rozumiem, że piszesz o osobie której wy poszukujecie? No bo nie wydaje mi się, żeby python jest aż taki uniwersalny jeśli chodzi o branże wizualną.

 

Z ciekawości, o jakim środowisku programowania mówisz? Np w przypadku narzędzi do modelowania?

 

 

A odpowiadając na twoje pytanie - to proste czemu jest tak mało specjalistów. Rzecz jest wybitnie interdyscyplinarna, zatem wymaga tysięcy dupogodzin po pracy, w domu. Większość ludzi dzieli życie na cześć komputerową, i niekomputerową, i nie są w stanie się tak poświecić.

Pisze trochę o sobie, bo jestem fanem automatyzacji i napisałem gromadkę prostych narzędzi na potrzeby firmy w której pracuje (product design / archviz), i wiem jak bardzo trudno zebrać się żeby np: upublicznić swoje narzędzia

[Kroopson]

Rozumiem, że piszesz o osobie której wy poszukujecie? No bo nie wydaje mi się, żeby python jest aż taki uniwersalny jeśli chodzi o branże wizualną.

 

Z ciekawości, o jakim środowisku programowania mówisz? Np w przypadku narzędzi do modelowania?

 

np w Maya, Maxie, Blenderze itp.

Python jest super uniwersalny pod warunkiem że nie chodzi o operacje realtime'owe i króluje w VFX'ach. W gamedevie jest jeszcze wciąż nieco egzotyczny ale szturmem zdobywa sobie miejsce. Ogólnie rzecz biorąc pipeline'y assetowe w grach są mniej więcej na takim etapie jak VFX'owe około roku 2009.

[drakul]

Hris, chyba używasz za wielu programów, i dlatego masz problem z nauką "ciągle" to nowych.

ja nie widze potrzeby znac az tylu zeby robic te rzeczy a siedze w podobnym segmencie.

[deshu]

np w Maya, Maxie, Blenderze itp.

Python jest super uniwersalny pod warunkiem że nie chodzi o operacje realtime'owe i króluje w VFX'ach.

 

 

Spoko, dobrze to słyszeć, bo dla mnie python jest absolutnie genialny, szczególnie w kontekście szybkiego osiągania efektów.

 

Ok, do tematu. Mówiąc że szukacie Pipeline TD, masz na myśli szefa działu opracowującego pipeline, czy szeregowca, który będzie tworzył jakieś pojedyńcze narzędzia które szef składa w całość?

[Hris]

Hris, chyba używasz za wielu programów, i dlatego masz problem z nauką "ciągle" to nowych.

ja nie widze potrzeby znac az tylu zeby robic te rzeczy a siedze w podobnym segmencie.

Co Ci mogę mądrego powiedzieć...:( niewiele. Tak właśnie się czasem czuję jak idę spać, że za dużo softu...Ale może też dlatego nigdy nie byłem bezrobotny (choć wiem że to spora cena bo ciągle w kompie siedzę). Ale tak samo chyba jest w tym Pipeline TD - tam też muszą albo pisać nowe narzędzia, albo usprawniać stare, ale patrzeć czy czegoś się nie da obejść innym językiem czy też jakąś inną biblioteką czy innym algorytmem. Dla przykładu u mnie codziennośc wygląda tak:

1. Affinity photo - robię sporo zdjęc i muszę ściągąć z nich mgłę, a w firmie mamy Photoshopa CS6 - nie umie takich bajerów

2. Blender - robię symulacje wody do fontann (potrzebne mi statyczne ujęcia wody, zatrzymanych fontann), czasem sculpt w terenie jakimś plus świetny importer plików OSM (open street map),

3. After Effects - w nakręcone ujęcia wstawiam czasem pliki dwg (stabilizuję kamerę a potem tracking i plik dwg ładnie się trzyma np. elewacji budynku, taki bajer, lub jakieś opisy wyskakują z za budynku), składam też całe animacje w tym sofcie,

4. Sketchup - nie znam lepszego softu do modelowania na podstawie plików DWG (szczególnie jak dwg nie są wyczyszczone), plus ponad 20 skrytpów które pomagają stawiać budynki

5. Growfx i ATree3D - często muszę u nas w pracowni robić dziwne drzewa, po prostu takie które istnieją dokładnie na danym miejscu

6. Railclone oraz ATiles3D - tworzenie patternów (Dachów, płotów)

7. Photoshop i Illustrator - tu chyba nie ma co komentować...po prostu codzienność

8. Autocad - tu czyszczę i przygotowuję często to czego architekci nie mają czasu mi przygotować...czyli żeby wogóle dało się wczytać DWG do 3ds maxa lub Sketchup'a

9. Substance Paitner - cudo - niby do gamedev'u, ale ławkę czy fontannę, czasem rzeźbę jakąś wolę w tym pomalować

10. Substance Designer - mam sporo gotowych materiałów do niego, ale czasem trzeba coś zmienić pod siebie w materiale

11. ZBrush - tutaj stawiam dopiero pierwsze kroki (chcę rzeźbić pnie drzew, skały, potem może hardsurface ale to dla siebie w klimatach sci-fi)

12. 3ds Max - tez bez komentowania...tu wszystko ląduje przed renderem:) wiele rzeczy też tu modeluję, uvmapping, etc.

13. Vray - do renderów animacji

13. Corona - do renderów statycznych

14. Lumion - jak mam tylko 3-4 godziny to w tym robię prezentację, inaczej się nie da:)

15. Zephyr (wcześniej Meshlab) - czasem przenoszę np. rzeźby kościelne albo kawałek budowy do 3D by potem to połączyć z aktualnym modelem w projekcie

16. O sofcie Audio nie piszę, w tym roku tylko ze 2 razy tworzyłem muzę do jakiejś prezentacji...

17. Marvelous - w firmie nikt nie ma czasu nadążać za moimi potrzebami odnośnie kanap, sof, foteli, krzeseł, firan etc. - chciałbym sam je robić, a z ręki robienie zagnieceń zamiata mnie czasowo, modeli też nikt mi tu nie kupi...Marvelous Designer by mi pomógł i to mocno...ale póki co nie...

18. ForestPackPro - bez tego lasy i parki plus trawniki bym ręcznie dziergał w wizkach...nie da się bez tego żyć...

...19....20....21...Mogę dalej wymieniać bo jeszcze mam w robocie Recapa do chmur punktów, FreeCad'a do czytania STL'i najnoawszych i inne programy.

I teraz strzelam że w Pipeline TD też musisz korzystać z takiej ilości narzędzi że łeb zrywa...

[olaf]

Jeżeli ktoś ma dobre learning curve, to czemu nie. Teraz nauka softu to może tydzień intensywnej nauki/praktyki.

Jeśli dodatkowo znajdzie sposób, by monetyzować jak najwięcej z nich na raz, to może spać spokojnie (i wygodnie).

[Hris]

Przepraszam za tamte offtopic'i bo sporo się rozpisałem...ale zagłębie się z czystej ciekawości dokładniej w to Pipeline TD - kto się tym zajmuje, co dokładnie robi, jakie narzędzia powstają, może gdzieś są jakieś portfolia takich ludzi co robili różne tool'e i się tym chwalą.

[Kroopson]

Ok, do tematu. Mówiąc że szukacie Pipeline TD, masz na myśli szefa działu opracowującego pipeline, czy szeregowca, który będzie tworzył jakieś pojedyńcze narzędzia które szef składa w całość?

 

Szeregowca ;) developmentem pipeline'u kieruję ja a nad sobą mam jeszcze dyrektora.

 

 

Jeśli chodzi o to co robią pipeline'owcy. Oto przyklady:

http://pyblish.com/pyblish-starter/

 

 

Tu kilka przykładów moich rzeczy z czasów kiedy implementowaliśmy Shotguna w Platige Image (lata 2013-2014):

https://vimeo.com/119321423

[Marvin]

“ Y U NO LEARN?! :)”

 

Może dlatego, że nie wydaje się to ciekawe?

Chyba po coś wybraliśmy grafikę 3d i animację :). Jakby moja praca polegała głównie na kodowaniu i czytaniu bibliotek to bym zmienił branżę na bardziej elastyczną (IT jest mega chłonne).

Do tego materiały do nauki zupełnie zniechęcają. No i strasznie ubogie możliwości w projektowaniu ładnego UI.

[Kroopson]

“ Y U NO LEARN?! :)”

 

Może dlatego, że nie wydaje się to ciekawe?

Chyba po coś wybraliśmy grafikę 3d i animację :). Jakby moja praca polegała głównie na kodowaniu i czytaniu bibliotek to bym zmienił branżę na bardziej elastyczną (IT jest mega chłonne).

Do tego materiały do nauki zupełnie zniechęcają. No i strasznie ubogie możliwości w projektowaniu ładnego UI.

 

Napisał Marvin - Maya TD :)

Jasne - mogą Cię nie interesować narzędzia do zapisywania plików, ale kiedyś np miałem taki case że pisałem tool do wspomagania symulacji ubrań w Platige. Nazywał się ShmaTex i robił mniej więcej to:

 

Ładował cache animacji dla ujęcia dla postaci które miały być symulowane (alembic).

Obliczał centrum geometrii dla wszystkich klatek animacji, tworzył locator który podążał za tym centrum.

Tworzył locator który miał animację dokładnie odwrotną względem początkowej pozycji ale mnożoną przez jakąś liczbę między 0 a 1.

0 oznaczała że wogóle się nie animował, .5 animował się ale o połowę mniej, 1 w pełni się animował odwrotnie do pierwszego locatora.

Wtedy tworzył się cluster na geometrii, który przypinał się do tego locatora drugiego który był przeciwieństwem ruchu pierwszego.

Dawało to taki efekt że postać jeśli np w alembic'u szła do przodu to po użyciu tego narzędzia stała w miejscu i machała kończynami albo szła 30% wolniej albo szła z pełną prędkością.

To bardzo pomagało w symulacji ubrań bo np jak trzeba było symulować pelerynę czarownika na latającym smoku to smok latał 100km/h i nCloth przy tym durniał kompletnie.

Tool pozwalał też zapisać scenę z aktualnymi ustawieniami nCloth'a, puścić symulację na renderfarmie i dalej lokalnie sobie zmieniać ustawienia.

Renderfarma wypuszczała preview i upload'owała to preview do Shotguna dzięki czemu zamiast czekać 30m na wynik symulacji lokalnej można było kilka wariantów naraz sprawdzać i wybrać najlepszy.

 

I teraz powiedz Marvin ile tym skryptom do robienia DNA które masz w demo brakuje do tego typu rzeczy ;) Jakbyś zamiast sam animować to DNA musiał dać ludkom "skrypt do robienia DNA bo mamy 150 ujęć z DNA".

 

Tutaj nie ma jasnej granicy.

Praca "tech artystów" i pipeline'owców w wielu obszarach się pokrywa.

[Marvin]

Może za mało precyzyjnie opisałem.

Z mojej perspektywy to wygląda tak, że mogę pisać toolsy ale nie widziałbym się jako osoba, która przez cały czas robi tylko to.

Jakoś mam większą motywację pisząc coś co sam użyję, coś co ułatwi mi pracę i jednocześnie pozwoli brać aktywny udział w tworzeniu ujęć :)

Etap projektowania jest super, fajnie się robi prototypy itp. Natomiast wdrażanie tego na produkcję to już nie moja para kaloszy.

[Sayja]

Myślę, że każdy tu mówi o innej wizji TD. Zgodzę się z Marvinem - artystyczne aspekty, development tooli jest bardzo interesujący, ale tylko na poziomie prowizorki i prototypu. Wdrażanie tego na produkcje i "czyszczenie" to już (dla mnie) żmudny nudny task.

 

~Hris - myślę, że to zbyt dalekie porównanie. Z softami jest trochę tak, że każdy następny wchodzi szybciej, a ostatecznie uczymy się interfejsu a nie narzędzia. Btw. trochę długa ta lista, myślę, że spokojnie można kilka punktów pominąć :)

 

To interesujące. Możesz rozwinąć?

 

Piszę z perspektywy kogoś kto kiedyś z programowania (webowego, okres przedandroidowy) przesiadł się do artu. Mam ciągłe wrażenie, że organiczność problemów artystycznych wymaga dużo większego trudu i nakładu pracy. Programowanie zawsze sprowadzało się dla mnie do problemów logicznych, a te jak wiemy, łatwiej jednoznacznie zidentyfikować i naprawić. Ale przez ten wątek zwróciłem też uwagę na tą subtelną różnicę iż doświadczenie artystyczne gdzieś tam na końcu learning curve się wypłaszcza, a technologie idą sobie do przodu. I tak po 10-letnim urlopie artysta będzie w domu, a programista nie będzie wiedział od czego zacząć.

[Kroopson]

Odbiegnę trochę od tematu ale nie zgodzę się że programowanie sprowadza się do problemów logicznych. To jest punkt widzenia osoby która podchodzi do zagadnienia na zasadzie "muszę napisać funkcję a, w trakcie pisania okazało się że potrzebuję funkcji b, potem funkcji c" itd. To tak jakby powiedzieć że tworzenie concept artu sprowadza się do problemu właściwego prowadzenia pociągnięć pędzla.

Jeżeli zaczynasz projektować złożone systemy to niestety jest to taka dziedzina której nie każdy ogarnie, podobnie jak nie każdy kto potrafi wiernie odwzorować ołówkiem martwą naturę będzie w stanie być kreatywnym artystą.

Inżynieria oprogramowania to zagadnienie holistyczne i często wchodzi tu czynnik intuicji twórcy. Patrzysz na jakiś kod/system/narzędzie i gdzieś w sobie czujesz czy to jest "ładnie albo nieładnie". Można powiedzieć że tak jak do obrazu tak i do kodu trzeba "mieć oko". Są oczywiście pewne ściśle określone wzorce ale tak samo i w pracy artystycznej masz np złotą proporcję, zasady kompozycji itp.

 

Taka anegdota:

Jak miałem 20 lat to wybrałem kierunek studiów: wychowanie fizyczne. Kilku moich kolegów z osiedla skończyło w tym samym czasie studia informatyczne, jeden nawet dostał wyróżnienie za jakość pracy magisterskiej. Ilu z nich pracuje jako programiści? Zero. Najbliżej jest facet który uczy w technikum informatyki, reszta po zaliczeniu ostatnich egzaminów zajęła się czymś kompletnie innym pomimo tego że zdawali egzaminy np z podstaw programowania w assemblerze, C++, robili skomplikowane projekty "na zaliczenie". Tak samo jak w sztuce potrzebna tutaj jest jakaś "Boża iskra", nie wystarczy odhaczać sobie kolejne skille tak samo jak nie wystarczy wyćwiczyć szrafunek żeby już tworzyć sztukę.

[Hris]

Kroopson ma rację wedłgu mnie - to nie tylko sposób logicznego myślenia, to nie rzemiosło...Ba! Nawet rzemiosło można przekuć w sztukę - jeden podkuje konia tak że podkowa będzie wyglądać jak buty przebrane z biedronki na promocji, a inny zrobi to tak że koń będzie się czuł jak w air-nike'ach i wszystkim we wsi będzie się żyło lepiej...taka dygresja :) A nieco poważniej. Pamiętam jak pisałem na Amidze w 1994 roku pierwszą swoją grę, miałem niecałe 15 lat, ciągnęło mnie do demo-sceny, ale assembler był dla mnie za trudny. Więć używałem AMOS'a. I co chwila stawałem na głowie żeby obejść "ładnie jakiś" problem. Przykład - byłem głęboko zafascynowany grą Elite Dangerous, i chciałem mieć ogromne ilości planet do których mógłbym "latać" i tam handlować. Trza to gdzieś było trzymać (tablice produktów, cen, nazw planet, ludzi, statków, zmiennych losowych etc). No i jak zaczynałem grę to tworzyłem najpierw "słowniki" w plikach tekstowych z których były pobierane te rzeczy i mixowane ze sobą, ale dyskietka rzęziła oc chwilę... Problem się robił wtedy jak co chwilę z dyskietki doczytywał lub zapisywał to mój kod i gra haczyła się jak leciałeś z jednej bazy do drugiej bo coś z dyskietki musiałem doczytać...dopiero potem nauczyłem się żeby to "kisić" wszystko w pamięci w tablicach, ale znowu pojawił się problem bo amiga (mój model) miała 2 MB pamięci i po wczytaniu sprite'ów, muzyki, teł, zaczynało brakować miejsca w Ramie :( Więc zacząłem szukać sposobów by grę podzielić na strefy, i jednak użytkownika zmusić się do poruszania w tej strefie która jest wczytana w Ram'ie, dopiero gdy chciał ją opuścić to pojawiał się komunikat że będzie "skok hiperświetlny" i trza poczekać aż statek wyhamuje po nim, grała muzyczka i się doczytywała reszta kosmosu...Dziś wiem że trzeba było wszystko zrobić wtedy w Basic'u gdyż AMOS był nakładką na Basic'a, kompilator był powoly jak żółw, i sam AMOS zżerał ponad 25% pamięci po starcie.

Puenta jest taka że jak już myślałem ze opanowałem jedną rzecz i że wygląda to dobrze, to pojawiał się zaraz inny problem, i musiałem robić syf w kodzie żeby coś obejść albo dogenerować, zapętlić czy jakimiś dziwnymi warunkami wymusić soft by nie dopuszczał użytkownika do dziwnych działań...Na końcu dostałem taki pakiet syfu w kodzie, że sam nie wiedziałem co gdzie jest :( Artystą i wirtuozem kodu nie byłem:(

Dziś tak samo w wizkach - rzucam teksturę na ławkę i jest ławka z drewna...ale można pójść dalej, rozłozyć UVMapy, odpalić Substance Paintera i tam dalej grzebać, wypalić tekstury i będzie i do wizek i do gamedevu jak poly się dobrze policzy:) Z kodem też wydaje mi się że tak można, robisz raz i zapominasz czyli rzemiosło, albo robisz tak że jak trzeba będzie rozbudować, dodać, przenieść kod, to się to da - czyli jednak artyzm i wirtuozerja jakaś musi być.

[deshu]

Dzięki za przykłady Kroopson.

 

Dla mnie to zajebista satysfakcja - robienie narzędzi. Odnalazłbym się na takim stanowisku.

Przy czym pewnie byłby to dla mnie degrad jeśli chodzi o pensje, bo to prawdopodobnie równałoby się z powrotem do juniorstwa.

[Sebazx6r]

Jak się widzi wymagania na ogłoszeniach to się odechciewa. Zacznijmy od wytresowania HR ,ze junior to nie jest osoba ktora umi wszystko, a nie od razu Maya API. Ja tam sobie proste stuffy w maya mel/python pisze lub robie setup'y bo powtarzalnych rzeczy robić nie lubie.

[olaf]

Taka myśl mnie naszła, że zamiast szukać w niszach, lepiej spotykać ludzi na piwie i uczyć się jak mieć z nimi dobre relacje i nauczyć się czytać feedback ludzi.

Praca managera albo dyrektora jest znacznie lepiej płatna niż dłubanie w niszowych skryptach.

[Nezumi]

Troche nawiazal do tego Marvin i teraz olaf. Odpowiedz w moim przypadku jest mega prosta - jestem artysta bo lubie :D Bo nic innego mnie nie cieszy. Zwariowalbym jakbym mial calymi dniami robic cos czego nie lubie. Ze kasa jest? To super. Jakby kasa byla jedynym czynnikiem sprawiajacym ze jest sie szczesliwym to dawno bym rzucil grafike, bo jest masa lepiej platnych prac.

Poza tym zeby byc w czyms na prawde dobrym potrzeba czegos wiecej niz po prostu mechanicznie sie tego nauczyc. Jak wymeczysz na sile znajomosc powiedzmy Pythona to i tak nie bedziesz tak dobry jak ktos kto lubi to robic. Jako ze tego nie lubisz bedzie cie kosztowalo mase pracy nauczenie sie tego a i tak koniec koncow zostaniesz miernota. Bo programowanie to w koncu nie tylko nauka komend - to specyficzny sposob myslenia, rozwiazywania problemow. Tak jak nie bedziesz dobrym rzezbiarzem poznajac funkcje ZBrusha tak samo nie bedziesz dobrym programista jedynie dlatego ze "sie nauczyles programowac". A ze malo jest ludzi ktorzy potrafia polaczyc pasje do sztuki nazwijmy to organicznej/wizualnej z pasja do kodowania..? To sie raczej nie zmeni. Z cala pewnoscia nikt nie zostanie swietnym programista tyko dlatego ze "latwiej znalezc prace i dobrze placa" :D

[Sebazx6r]

Troche nawiazal do tego Marvin i teraz olaf. Odpowiedz w moim przypadku jest mega prosta - jestem artysta bo lubie :D

 

Ja akurat jedno i drugie lubie. Zwariowalbym jednak jakbym mial robic jedno i to samo non stop...

[deshu]

No mi od jakiegoś czasu nic nie daje tak dużej satysfakcji jak 3d+programowanie jednocześnie. Houdini wzywa!:P

[Sebazx6r]

Hudego jeszcze nie liznalem ;/...

[Nezumi]

Ja akurat jedno i drugie lubie. Zwariowalbym jednak jakbym mial robic jedno i to samo non stop...

 

No to super. Gratulacje! Teraz potrzebujemy KONIECZNIE 12 osob ktore napisza "ja tez!" "i ja tez!". :D

Tyle ze wciaz bedziecie w mniejszosci. Jakbyscie nie byli to by nie bylo tak trudno znalezc kogos takiego, prawda?

 

A co do Hudego to akurat mnie tez korci sprobowac bo pododawali mase na prawde fajnych rzeczy no i zdaje sie jest wersja gratis wiec nic nie stoi na przeszkodzie.

[olaf]

jestem artysta bo lubie :D Bo nic innego mnie nie cieszy

Masz dużo racji Nezumi i wcale nie jest to zła droga. Mam dwa przykłady:

 

1. ostatnio zatrudnialiśmy pixel-artist freelancerów na kontraktach na pełen etat w przedziale 20-35usd/h. Zarobki Hudiniego i Copperfielda nieco bledną.

 

2. Jeden z artystów nie mógł dostać roli supervisora, bo zbyt wiele pracy managerskiej go zwyczajnie męczyło, gdyż kocha tworzyć. Bez tego jest konfliktowy i niezbyt miły. Pomijam fakt, że zarabia znacznie lepiej robiąc to co kocha niż każdy programista w PL, który poszedł za kasą i teraz zarabia jakieś śmieszne 8-10k na rękę.

[michalo]

Hej Olaf, to jakaś prowokacja z tym 8-10k? Czy to jest po prostu wg ciebie niski zarobek dla programisty, na etacie?

Wiadomo, że to mało pod względem wartości, ale raczej sporo, jeśli chodzi o wysokość zarobków w PL.

 

Mój kuzyn też tak gada, ale to dla tego, że już kilka lat pracuje za granicą. Ty z tego, co pamiętam też działasz na zachodzie - za zachodnie ;)

Także łatwo stracić trop tego, jak jest w PL.

[olaf]

Przy założeniu, że grafik może bez problemu działać jako freelancer gdziekolwiek chce - w Kazachstanie, Polsce, czy Szwajcarii, nie ma sensu myśleć ile to jest "dużo" w danym miejscu. Grafika wysokość zarobków w PL powinna obchodzić tak jak inflacja na Borneo.

 

Ja mieszkam za granicą, bo wybrałem miejsce, gdzie mogę się nauczyć więcej - nie obsługuje jednak firm lokalnie i nie siedzę nigdzie na etacie. Mógłbym siedzieć w PL ale nie ma to dla mnie wielkiego sensu.

 

edit: ludzie ktorych zatrudniam dla mojego klienta (jestem dla nich zdalnym managerem), mieszkające w ameryce południowej, mają jeszcze niższe koszta utrzymania niż w Polsce ale stawki mają wyższe niż polscy programiści ;)

Edytowane 17 Sierpień 2018 przez olaf

[tr3buh]

Rozumiem, że piszesz o osobie której wy poszukujecie? No bo nie wydaje mi się, żeby python jest aż taki uniwersalny jeśli chodzi o branże wizualną.

Właśnie, interesuje mnie jakie języki są najbardziej potrzebne jeżeli chodzi o branżę wizkową, nie jestem programistą ale ostatnio bardzo dużo czasu siedzę w Unrealu i w blueprintach tworząc realtimowe wizki ( unreal wiadomo - C++ ) ale chodzi mi bardziej o firmy gdzie tworzą stille/animacje, jaki język jest najbardziej potrzebny, tylko nie piszcie że maxscript

sorry za offtop

[xmass]

Właśnie, interesuje mnie jakie języki są najbardziej potrzebne jeżeli chodzi o branżę wizkową, nie jestem programistą ale ostatnio bardzo dużo czasu siedzę w Unrealu i w blueprintach tworząc realtimowe wizki ( unreal wiadomo - C++ ) ale chodzi mi bardziej o firmy gdzie tworzą stille/animacje, jaki język jest najbardziej potrzebny, tylko nie piszcie że maxscript

sorry za offtop

 

Jeżeli chodzi o branże wizkową, stille i animacje, maxscript jak najbardziej jest uzasadniony. Sam pisałem do studia toole, i piszę nadal, głównie dla siebie i pod swój workflow, maxscript jest łatwy i do powtarzalnych czynności nadaje się idealnie, i pisze tu z mojego punktu widzenia a nie z punktu widzenia mistrza kodu ;D

Wizkowe animacje nie wymagają turbo toolsetów, zazwyczaj i tak są to przeloty kamery, coś tam się animuje, foliage, samochody, jakieś pojedyńcze obiekty, a do tego nie potrzeba pisać w C czy innym języku bo maxscript to ogarnie. Stille to już inna bajka, jak studio ma swój wyrobony workflow to pod powtarzalne czynności maxscriptem ogarniesz większość w krótkim nakładzie czasu.

Mnie pasuje, może dla tego że nie chce mi się uczyć innych języków bo już jestem za stary ;P

[deshu]

Maxscript jest uzasadniony głównie z tego powodu, że archvis jedzie na maxie, a w maksie nie masz alternatyw. Jest niby wrapper maxscriptu do pythona ale cóż - więcej z nim zachodu niż pożytku. Takie mam doświadczenia.

 

Olaf zawsze wprowadzi zamęt gdy zaczyna gadać o kasie :) Cóż michalo, nie martw się, że zarabiasz za mało. Większość ludzi w 3d marzy o takich stawkach o jakich Olaf wspomniał.

[michalo]

Nie martwię się. Wiem mnej więcej jakie są zarobki, jakie perspektwy etat vs freelance dlatego zadałem takie pytanie.

[olaf]

Jasne, mnie też czasem stawki szokują.

 

Ale prowadzę teraz 20-to osobowy team po godzinach i widzę, że z punktu widzenia managementu kasa nie ma znaczenia.

Jeżeli projekt X ma budżet Xmln $ to szukasz ludzi pewnych i zaradnych. A to czy ich stawka wynosi 10/h czy 30usd/h jest drugorzędne.

 

Łatwiej dowieźć projekt z odpowiedzialnymi ludźmi, a tacy powinni się cenić, bo firmy mają kasę, by im płacić. Dlatego jeżeli kogoś nie jara programowanie i zwyczajnie chce być artystą - spoko. Tak długo jak da się z Tobą dogadać i jesteś odpowiedzialny, będziesz żył komfortowo.

 

p.s. założę się, że jeżeli tak mało jest specjalistów Pipeline TD to nawet stawka 50-100usd/h jest do osiągnięcia. Kwestia mindsetu, ostatnio jakiś grafik zaproponował 50usd/h (szwajcar), a zatrudniliśmy lepszego za 18/h (kolumbia). Gdyby jednak nie było wyjścia - a produkcja nie zatrzyma się z powodu różnicy w stawce jednej osoby - to byśmy go wzięli.

[deshu]

[...]że z punktu widzenia managementu kasa nie ma znaczenia [...]

Błagam cię :)

 

Mówisz o 20 osobach i X milionach. O 10/h i 30/h. Nie wiem jaki jest czas i ile tych milionów.

No ale niech będzie że 2mln i pół roku.

 

20*160*6*10usd = 192000

20*160*6*30usd = 576000

 

Powiesz mi, że nikt ciebie jako menadżera projektu "po godzinach" nie rozliczy z tego czy w pół roku zaoszczędziłeś ponad 350kusd z 2mln do wydania? Hłe hłe.

[olaf]

To jest idealny przykład czemu ludzie tak mało zarabiają. Patrzą na cyferki i wyciągają wnioski z liczb.

Kasa jest surowcem do realizacji planu. Jeżeli jest szansa go zrealizować, to przeznacza się adekwatne środki.

 

Co z tego, że oszczędzisz 350k jeżeli jakością skrócisz lifespan projektu o rok, a on będzie zarabiał powiedzmy 200k miesięcznie? Zmarnujesz 2mln$ netto.

[deshu]

Sam w poprzednim poście przytoczyłeś sytuacje, z której wynika że stawka godzinowa ≠ lepsza jakość.

Nie mówię o ryzykowaniu failem, tylko o szukaniu oszczędności tam, gdzie da się je znaleźć.

 

Jest choć jedna firma na świecie, która za ostateczną "realizacje planu", uważa cos innego, niż zysk?

[olaf]

szukaniu oszczędności tam, gdzie da się je znaleźć

Jasne, ale z punkty widzenia managementu kasa nie ma znaczenia. Znaczenie ma realizacja projektu. To oczywiście rozgałęzia się na takie kwestie jak budżet, pipeline, zespół itd. Ale znaczenie ma plan i jego realizacja.

 

Można zatem - dla jasności - napisać, że kasa ma drugorzędne znaczenie. Jeżeli szukasz jednak tego najważniejszego czynnika za który będziesz rozliczany, to jest nim realizacja celu.

 

Pisałem o tym w kontekście pracy artysty. Jeżeli ktoś zrozumie, że celem osoby, która płaci za jego skill jest realizacja celu, nie musi się martwić o swoje życie w komforcie, tobiąc to co kocha, tak długo jak dostarcza tą właśnie wartość.

Czyli oferuje skill + przewidywalność na której można budować pipeline i zespół. Taka osoba może żądać 5x tyle ile inni, bo jest dobrym budulcem tego co liczy się najbardziej - realizacja celu.

 

Jest choć jedna firma na świecie, która za ostateczną "realizacje planu", uważa cos innego, niż zysk?

Wiesz założyłem, że wszyscy rozumiemy takie oczywistości i rozmawiając o pieniądzach poruszamy się w tej właśnie realnej przestrzeni i nie warto poruszać tak oczywistych rzeczy ergo - mogę sobie pozwolić na napisanie, że "nie mają znaczenia", bo każdy zrozumie co mam na myśli. Myliłem się, moja wina, powinienem być precyzyjniejszy.

 

sumując: by nie było wątpliwości, że nie odleciałem. To o czym piszę, to kontrargument do propozycji uczenia się programowania. Można - sam znam chyba 5 czy 6 języków programowania - ale można równie dobrze bez tego, bo stawki programistów to nie jest jakiś tam szczyt zarobków wśród profesji.

[polka dot]

Jest choć jedna firma na świecie, która za ostateczną "realizacje planu", uważa cos innego, niż zysk?

 

są takie, jedna nawet w Warszawie (może ta jedyna?)

[deshu]

Wiesz założyłem, że wszyscy rozumiemy takie oczywistości i rozmawiając o pieniądzach poruszamy się w tej właśnie realnej przestrzeni i nie warto poruszać tak oczywistych rzeczy ergo - mogę sobie pozwolić na napisanie, że "nie mają znaczenia", bo każdy zrozumie co mam na myśli. Myliłem się, moja wina, powinienem być precyzyjniejszy.

 

A no tak. Wybacz że skoro coś napisałeś, to zrozumiałem to tak, jak zostało napisane. Cóż za nieelastyczność z mojej strony!

 

 

są takie, jedna nawet w Warszawie (może ta jedyna?)

Mówisz o tej, która realizuje kilkanaście/kilkadziesiąt produkcji reklamowych rocznie? :)

[olaf]

Cóż za nieelastyczność z mojej strony!

To nie była złośliwość z mojej strony. Wiele rzeczy gubi się przez przekaz pisany jak na przykład framing wiec to faktycznie moja wina, że zapominam o tym.

[deshu]

Spoko, w takim razie ja już zakończę złośliwości z mojej strony.

 

Generalnie zgadzam się z tobą, z tym co piszesz o specjalistach i płaceniu im. Nie możemy tylko zapominać o tym, że żeby stawiać warunki, trzeba mieć zabezpieczenie. Wielu ludzi nie tego ma i nie jest to tylko ich wina, i dlatego dają sie wykorzystywać, zaniżają ceny itd. Z resztą co ja ci będę tłumaczył, sam dobrze wiesz.

[olaf]

Zgadza się, pozycję buduje sie latami niestety/stety. Staram się tylko trąbić o tym, że sufit jest wyżej niż może się wydawać.

Kiedyś myślałem, że trzeba mieć szeroki skill, by się odnaleźć. Teraz po kilku rekrutacjach i pracy z artystami widzę, że można robić to co się kocha, trzeba tylko być solidnym w pracy i szukać alternatyw na całym świecie.

 

A stawki mnie zaszokowały. Byłem pewien, że 20k pln/mies dla grafika jest ciężko osiągalne chyba, że jest na pozycji super seniora lub dyrektora. Okazuje się, że nie. Wraz z dojrzewaniem rynku rośnie zapotrzebowanie na pasjonatów w wąskich specjalizacjach :)

[deshu]

Nie znam żadnego grafika który by tyle zarabiał.

[olaf]

To okolice 30usd/h przy pracy 8h dziennie. Robiąc nadgodziny spokojnie wyciąga się 20-25k PLN na mniejszych stawkach godzinowych. Wiem, bo tyle wyciągałem jak wykonywałem prace na wyłączność dla jednego klienta (grafika+game development+art directing). Mam teraz w teamie ludzi na wyższych stawkach - grafików. Nie muszą znać animacji, programowania itd.