Jump to content
Kroopson

Czemu ludzie się tego nie uczą...

Recommended Posts

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?! :)

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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ą ;)

Share this post


Link to post
Share on other sites

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ń.

Share this post


Link to post
Share on other sites
Programowanie jest wciąż prostsze od pracy artystycznej :)

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

Share this post


Link to post
Share on other sites
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 ;)

Share this post


Link to post
Share on other sites

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 :)

Share this post


Link to post
Share on other sites
"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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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ść?

Share this post


Link to post
Share on other sites
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...

Share this post


Link to post
Share on other sites

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).

Share this post


Link to post
Share on other sites

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ą.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

“ 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.

Share this post


Link to post
Share on other sites
“ 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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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ąć.

Share this post


Link to post
Share on other sites

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ę.

Share this post


Link to post
Share on other sites

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ć.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...

Important Information

We are using cookies. Read about our Privacy Policy