Jump to content

Kroopson

Members
  • Content Count

    1,293
  • Joined

  • Last visited

  • Days Won

    6

Kroopson last won the day on January 27 2017

Kroopson had the most liked content!

Community Reputation

337 Excellent

4 Followers

About Kroopson

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. No dobra - w razie gdyby ktoś jeszcze miał taki problem: Przyczyną tego błędu jest Perforce, a dokładniej to P4V. Problem polegał na tym że Perforce dodaje się domyślnie do ścieżki systemowej (zmienna środowiskowa PATH) i zawiera w swoim katalogu biblioteki Qt5 np Qt5Core.dll, Qt5Gui.dll, Qt5Widgets.dll, ale nie ma Qt5Qml.dll do której QtXml.pyd z instalacji 3dsMax'a jest zlinkowany. Po usunięciu Perforce'a ze ścieżki systemowej wszystko zaczyna działać. Ot - kolejny dzień z życia w pipeline'ach :)
  2. Hej - czy używa ktoś może windowsa 10 i 3dsMax'a 2018? Mam taki problem na windowsie 10 kiedy próbuję odpalić komendę w script editorze (python): from PySide2 import QtXml dostaję błąd: Traceback (most recent call last): File "", line 1, in ImportError: DLL load failed: The specified procedure could not be found. Dzieje mi się tak dopiero przy drugim i kolejnym uruchomieniu maxa, przy pierwszym działa (to jakieś kuzorium normalnie)
  3. Bake -> Bake to scene and delete, tylko musisz sobie klip zaznaczyć.
  4. 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ę.
  5. 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.
  6. 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
  7. 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.
  8. "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 ;)
  9. 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?! :)
  10. Które ujęcia kto robił? Generalnie najlepszy cinematic od PI od dawna, w wielu miejscach mam zagadkę: CG czy shoot. Gratulacje z mojej strony :)
  11. Ten żółty komunikat to informacja o cyklu w czymś co się nazywa Dependency Graph. A mesh Ci się kolapsuje pewnie dlatego że głupieje HIK (pewnie właśnie przez cykl).
  12. Nasz dział prawny mówi że możemy to odliczać (żeby była jasność pracuję jako programista, nie grafik). W tej chwili jestem na B2B i mam pewne obawy czy jeśli przeszedłbym na umowę o dzieło to czy za pół roku nie ogłoszą że to była pomyłka, jednocześnie blokując możliwość pracy na B2B (or something). Jest to lekka paranoja ale w Polsce nigdy nic nie wiadomo :)
  13. Hej - w tym roku rząd podniósł limit kosztów uzyskania przychodu przy umowie o dzieło z przeniesieniem praw autorskich do jakichś 85000, co technicznie oznacza że do osiągnięcia przychodów rzędu 170 000 płacimy około 10% podatku. Coś mi tu jednak mocno "śmierdzi" i wydaje się to to zbyt piękne żeby było prawdziwe. Może ktoś ma jakieś przemyślenia na ten temat?
  14. Ładnie, bardzo ładnie... w gruncie rzeczy światowa czołówka, produkcja niczym nie odstająca od cinematic'ów innych firm. Naprawdę gratulacje.
×
×
  • Create New...

Important Information

We are using cookies. Read about our Privacy Policy