Monio

Oczywiście zrówna się do tej słabszej. Jak umieszczasz scenę w ramie wszystkich kart to ta najsłabsza sobie go nie wyczaruje. ;) Mówimy o sytuacji gdy będziesz korzystał z obu na raz bo przecież możesz niektóre rzeczy renderowac na pojedynczej, mocniejszej karcie. Instancje obiektów to ALT+D, edytując jeden zmieniasz wszystkie, jak ładujesz je do renderu to ładujesz tylko jeden obiekt (mniej więcej, każda instancja dodaję coś do objętości sceny.) Twarda kopia obiektu to SHIFT+D, czyli jak skopujesz to on staje się niezależny.

Mi chodzi o filmik który zainteresuje ludzi blenderem. W Release notes blenderowcy mogą znaleźć to co ich interesuje. Tylko to jest dokumentacja a nie promocja. Każda duża firma robi takie realase notes do swoich softów ale to właśnie filmiki i dobry marketing go sprzedają.

Jeśli potrzebujesz rzeczy które teraz działają na CPU a nie działają na grafie to wybierz raczej mocarne CPU. Po odejściu Brechta nie prędko przeniosą wszystko na GPU. SLI nie działa w cyclesie. Każda karta jest traktowana jako osobny akcelerator ze swoją własna pamięcią w której musi się zmieścić scena. Co do kart 6 giga. Musisz zwrócić uwagę na architekturę takiej karty. Większość z nich to tak zwane kanapki czyli 2 identyczne karty połączone czymś w rodzaju mostka SLI na sterydach. Na pudle masz napisane 6 giga ramu ale tak na prawdę to jest 2 razy po 3 giga, czyli jeden akcelerator ma dla siebie nadal tylko 3 giga pamięci. Taki titan chyba na prawde ma 6 giga pamięci ale już titan Z to kanaplka więc dostajesz 2 razy po 6 giga. Co do wyboru karty to ci nie poradzę, nie wiem jak to teraz wygląda z price performance. Za to zwróć uwagę na jedną rzecz. Może być tak że opłaci ci się wydać kase na jednego kolosa zamiast 2 kart dlatego że będziesz mógł dużo szybciej pracować, zmniejszy ci się czas robienia preview renderów. Natomiast jeśli masz już wypracowane jakieś swoje ustawienia i materiały to pewnie bardziej opłacą ci się 2 karty i oszczędność czasu na final-renderach. Tym bardziej do renderowania animacji. Poza szybkością renderu na klatkę masz jeszcze taki czynnik że karty kolosy się mocniej grzeją więc szybciej ci padnie. Tak czy inaczej zacznij od tego jakie sceny będziesz robił i ile ramu ci na nie trzeba. Szybkość odszumiania będzie lepsza lub gorsza ale to mozliwość wyrenderowania czegoś złożonego w ramach ilości RAM jest tutaj czynnikiem decydującym. Może być tak że jak uwzględnisz instancing obiektów jak roślinność to starczy ci karta 2 giga. Zrób sobie jakieś testy na twoich scenach kopiując (również robiąc instancje) obiekty do tego momentu aż urżniesz twoją obecną kartę, wtedy ci wyjdzie ile razy więcej ramu potrzebujesz żeby uzyskać to co chcesz. No i jeszcze bierz poprawkę że jak będziesz renderował nocami duże stilki czy klatki animacji to te karty się usmażą za 2-3 lata i będziesz zmuszony kupić nowe. Poprawka, będziesz CHCIAŁ kupić nowe nawet jak tamte będą jeszcze działać. To leci tak do przodu że bóg wie jaką te cuda będą miały wydajność. ;) Nie sadzę że taki Titan Z za 10 kafli to dobra inwestycja na sprzęt na 2 lata. ;)

Fajnie ale ja bym raczej stwierdził ze to źle że te filmiki nie są oficjalnymi rzeczami od BF. Gość jest koderem blendera i robi te filmiki świetnie ale powinni się z nim ugadać żeby robił oficjalne wideo dla każdego wydania. Gośc robi te filmiki bardzo dobrę ale jak ludzie jak widzą wielgachne logo "Plasmasolution" jako główny motyw to raczej nie będą traktowali tego jako oficjalne materiały promocyjne. Niech da to logo gdzieś pod koniec filmu i się ładnie przedstawi ale niech te filmiki będą na jutubowym kanale BF z logo BF jako główny motyw. Niech Ton wysupła trochę kasy na robote tego gościa. Soft to nie tylko kod! Wystarczyłby jeden skrócony filmik (2 minuty) z ogólnym przeglądem nowości i reszta w takiej formie jak jest, czyli dłuższe. Nie na default cube tylko na jakiś ładnych modelach, np z poprzednich projektów open movie. Każda firma robiąca softy graficzne kładzie nacisk na takie prezentacje bo słowa nie opiszą sposobu działania narzędzi graficznych. Nie raz tłumaczyłem znajomym nie związanym z grafą dlaczego się jaram dynameshem w zecie, niewielu skumało ideę. Wystarczyłoby im pokazać ten filmik:

Chcesz żeby to było widoczne w blenderze czy w silniku? Jak to pierwsze to : object properties -> normal panel -> double sided. Mozesz tez skorzystac z modyfikatora solidify, zatwierdzić go i potem zaznaczyć rownolegle loopy nowo powstalego face loopa pomiedzy dwiema warstwami i użyć opcji colapse edges. Dzięki temu uzyskasz geometrie z 2 stron i mozesz zmapowac na spodnią częsc liscia inna texe. Jak to ma byc w silniku to takie rzeczu ustawia sie w materiale juz w silniku.

Lumpenstuck- Nigdzie nie pisalem że będzie to zaraz gotowe, napisałem "w przeciągu roku". Druga sprawa że juz teraz cycles bake pozwala na wiele rzeczy niemożliwych w SD wiec bynajmniej nie jest tak że nie ma nic. Nie wypalisz żadnych świateł, environmentu ani global illumination w SD. Nie zmapujesz texy według wygenerowanych koordynatów ani z projektora. Nie stworzysz tekstury 3D której parametrami bedziesz sterowal vertex paintem, wektorami normalnymi czy inną teksturą 3D. Wszystkie te rzeczy zrobisz już teraz w bakeu w cyclesie, tylko po prostu renderujesz pojedyńczo każdą mapkę dla każdego obiektu z osobna. I tym problemem wlasnie sie teraz zajmuje, żeby w przyszłości dalo się to wypalić jednym klikiem.

No taa. Bo software robi się tylko pisząc kod. Na co komu reaserch, design, UI/UX. ;)

Rzeczy związane z bakiem w blendku wessały cały moj wolny czas. Pewnie niektórzy pamiętają jak pare miechów temu pisalem o filmiku promocyjnym blendka na siggraph ale niestety nie mogłem znaleźć na to czasu bo development bakeu już lecial do przodu. W sumie to teraz blender jest trochę w rozsypce po 2.70 i mają wiele rzeczy do poprawienia wieć może to nie jest dobry czas na docieranie do prosów. Może za rok jak doczekamy sie nowego viewportu, menagementu assetów, poprawionej fizyki i jeszcze silniejszego cyclesa to będzie silniejsze uderzenie. Tyle projektów i tak niewiele czasu. Wiecie gdzie mozna się tanio sklonować? ;D

Idaho- Akurat robilem kawałek interfaceu jak czytalem tamtego posta więc postanowiłem się podzielić moimi przemyśleniami. Na razie jestem w trakcie przeprowadzki wiec sprawa stoi w miejscu ale za 2 dni zabieram sie za to ponownie. Jak będę mial coś do pokazania to nie omieszkam sie podzielić. To co robie teraz to drugi z trzech proposali, Pierwszy był swego rodzaju wstępem ale niedligo będzie juz trochę outdated. Trzeci natomiast najprawdopodobniej zamieni się w akcje crowdfundingową bo będzie trzeba zatrudnić kilku wymiataczy OSLa żeby zrobić dobra bazę efektow, tekstur 3D i dwa ubershadery. Mam juz 2 gosci na celowniku którzy temo podołają. :) Potem jeśli uda się zebrac odpowiednią ilość kasy to te efekty zostaną przekonwertowane na natywne nody cyclesa. Tutaj wychodzi piękno tego silnika bo konwersja z OSLa jest banalna dlatego że cycles jest wzorowany na architekturze OSLa. Bake managementowi moze uda się zawitać juz w 2.72, na tą trzecią część trzeba bedzie poczekać pewnie ze 2 wydania.

Zapowiada się interesująco. Chętnie kupię wersje na Androida. Z minusów to co mi się rzuca w oczy to dosyć długie czasy przejścia pomiędzy widokami, jakoś tak przyjemniej 2 razy za długie. Weźcie pod uwagę że to point'n'clisk więc szukając rozwiązania ludzie często będą przeskakiwali pomiędzy ekranami wiele razy. Dodatkowo niektóre elementy (zębatki) bardzo odstają kolorystycznie (i jakościowo również). Byłoby super jeśli to podciągniecie to wysokiej jakości innych grafik które teraz macie. Fajny projekt. Trzymam kciuki!

Jedna z najładniejszych animacji jakie w życiu widziałem. Niesamowite co człowiek może osiągnąć przez lata ciężkiej pracy.

W temacie filmów akcji które mają fabułę bardzo polecam wszystkich X-menów. Przez lata byłem nastawiony na anty do filmów o superbohaterach bo zawiodłem się kilkoma z rzędu ale dziewczyna mnie wkręciła w serie z X-menami której wcześniej nie widziałem i bardzo mi się spodobało. X-Men First Class to świetny film. Dobrze nakreślone postaci które mają za sobą konkretne backstory (Magneto!), historia która składa się do kupy w coś wiarygodnego, oczywiście w ramach ludzików z supermocami. Nie przesadzili z niepotrzebnymi vfxami przedkładając historie nad puste efekciarstwo.

Jednocześnie was rozumiem ale to trochę nie jest tak. Myślę że developerzy blendka powinni przy wybranych nowych funkcjach dodawać jakąś ikonkę "wersja beta" bo ludzie nie rozumieją że niektóre funkcje które się pojawiają są tylko początkową fazą rozwoju. Taki jest urok całego blender - always beta. Mallow- Attribute node to jest dosyć standardowa rzecz w cyclesie. Mogliby dodać coś takiego jak piszesz ale to jest jakaś wstępna wersja renderowania smoke & flame więc chyba nie widzieli w tym potrzeby. Jak dodadzą do samego renderowania odpowiednie poprawki (nie mam pojęcia jakie) to zrobią tego noda. Azbesty- Zrobienie designu bake menagementu to kilka tygodni roboty a implementacja tego to kolejne kilka. Workflow jest spierdzielony na maksa ale to tak na prawdę nie jest teraz najważniejsza rzecz do zrobienia. Brakuje jeszcze zupełnie podstawowych funkcji bez których nawet najlepszy bake menagement nie zrobi z tego narzędzia z którego można normalnie korzystać. Pierwsze w kolejce jest wypalanie displacementu, anti-aliasing, obsługa GPU, obsługa multiresa. Nie ma jakiekolwiek modyfikowanie normalek obiektu nodami, na razie jedyne co możesz dostać to normalki z hipoly, nie działa displacement, dodawanie tekstur z normalmapą czy modyfikowanie wektorów nodami. Znajdzie się pewnie jeszcze kilka innych elementarych braków. Jeszcze maaaasa roboty. Developerzy stwierdzili że wolą udostępnić "niedojrzałą" wersje bakeu już teraz żeby ludzie mogli to potestować to co jest żeby spływał od nich feedback. Za menagement zabiorą się przy następnym wydaniu razem z naprawą tych rzeczy które wymieniłem. Prawdziwe możliwości bakeu w cyclesie poznamy najwcześniej za 2 wydania, to mogę ci zagwarantować.

Azbesty- Też miałem problemy ze sterami nvidi na laptopie. Pomogło mi zainstalowanie starszych sterowników. To jest akurat wina niedopracowanego Optimusa, użytkownicy innych softów też mają z tym problemy.

Mi też kilka razy pojawił się błąd z renderowaniem interfaceu. Mieliśmy sporo plików z jeszcze z czasów kiedy korzystaliśmy z 2.49 ale odpalaliśmy je na 2.69. Renderowały się jakieś fioletowo czarne paski, jak artefakty grafiki. Tylko że w moim przypadku to było jakby zupełnie dodatkowe windowsowe okno programu. Mogłem je wyłączyć iXem i pracować normalnie. Od kilku miechów nie widziałem tego błędu tylko że tym razem pracuje na daily buildach i tworzę w nich nowe pliki. Co do OSLa. Goście tam piszą o service packu do windy. Dodatkowo możesz zrobić update driverów grafiki bo nawet jak renderujesz na CPU to wina może leżeć po stronie renderowania interfaceu a nie samych bibliotek OSLa. Wczoraj np załatali błąd związany z grafą gdy blender się crashował gdy bardzo szybko zmieniło się połączenie nodów. Parę razy mi się to zdarzyło.

WTF??? Jak ci działają gry? Nie masz w nich żadnych artefaktów? Zrób jakieś testy hardwareu, ram, proc, grafa. Reinstalka systemu może coś poradzi. Mam taki sam procek jak ty i u mnie OSL działa okej. Azbesty- W 2.70 było bardzo dużo wewnętrznych zmian, nie będących featuresami ale usprawniającymi ogólnie większość rzeczy (dependency graph). Po takich dużych rzeczach można z pewnością spodziewać się bugów, nawet w tych rzeczach które wcześniej działały, dlatego że teraz za ich działanie odpowiada kompletnie inny kod. Ja zawsze pełne wersje traktuje jako beta i czekam na wersje A. Ludzie nie chcą zgłaszać bugów i takie są efekty. Sam się winię za to bo mam teraz czas na testowanie i raportowanie. Trzeba się pogodzić że jeszcze przez parę miechów z 2.7x będzie bajzel. Na jesień jak pojawi się ViewportFX to też będzie niezły bajzel przez 2 następne pełne wydania. My w firmie działamy teraz na 2.69 bo wersje 2.70 i 2.71 wywalają nasz addon level designowy.

Masę bugów to naprawili. Nowe funkcje zawsze po wydaniu miały swoje bugi które są poprawiane jedną lub kilka wersji potem.

Ten specjalista siedzi już od dawna w Instytucie Blendera. Nazywa się Sergey Sharybin i to on teraz będzie główną osobą odpowiedzialną za rozwój Cyclesa. Obecnie Brecht dogłębnie wdraża go w architekturę swojego renderera. Gość podobnie jak Brecht ma głowę na karku i podejmował się już ogromnych projektów nie mniej skomplikowanych od Cyclesa. Na pewno nie ma takiej wiedzy w temacie pathtracerów ale nie widze przeszkód żeby w ciągu kilku(nastu) miesięcy stał się godnym następcą Brechta. Jest jeszcze kilku innych gości którzy non-stop pracują nad nowymi featuresami cyclesa i ciągle się doskonalą. Development zwolni, to fakt ale nie ma co snuć czarnych scenariuszy. Będzie dobrze. ;)

Cycles standalone istnieje tylko jak na razie jest oparty o API w C++. Cycles jest na wolnej licencji Apache co oznacza że można go sobie połączyć z dowolnym programem, nawet modyfikować i sprzedawać. Pierwszą firmą która się na coś takiego zdecydowała jest Rhinoceros, zatrudnili jednego programistę powiązanego z blenderem i za jakiś czas Cycles będzie w Rhino głównym rendererem. Może kiedyś ktoś napisze plugin do majki który zintegruje ją z Cyclesem, ten renderer ma taki potencjał że obstawiam że to tylko kwestia czasu. Podcast Anderw Pricea w którym przeprowadził wywiad z Brechtem już po pojawieniu się tej informacji: http://www.blenderguru.com/podcasts/brecht-leaves-blender/

Houdini Engine pod Unity nie obsługuje wypalania tekstur. Pod majkę tak ale nie w unity. Nadal pozostaje kwestia że zespół będzie zdany tylko na to co jeden czy dwóch gości zrobi w hudym. Reszta nie będzie miała możliwości rozszenia funkcji digital assetu. Oczywiście można zrobić taki asset który będzie się nadawał do wszystkiego co przekładałoby się na przepisanie większości funkcji substance designera na zajebiście złożony asset houdiniego. Szczerze wątpię że roboczogodziny osoby która potrafiłaby to zrobić byłyby mniej kosztowne niż kupienie po 20 licencji wszystkich softów Allegorithmic, paczki z 1500 substancjami i jeszcze kilku licencji Qiuxela.

Realtimowych shaderów a nie proceduralnych. Miksowanie tekstur pixel shaderem niewiele ma wspólnego z generowaniem proceduralnym. W teksturowaniu możliwości ShaderFX kończą się tam gdzie zaczyna się podstawowy workflow w Cyclesie- czyli trójwymiarowe tekstury, te standardowe i te robione OSLem. Co do Houdiniego. Ja o nim nie zapominam, w istocie śnie o nim po nocach. ;) Wiem że dałoby się w nim zrobić wszystko to o czym tutaj piszemy i doskonalone zdaje sobie sprawę dlaczego ten soft nie jest do tego popularnie wykorzystywany. Czynniki są dwa- cena i najbardziej hardcoreowa krzywa nauki jaką oferuja programy 3d. Taki przykład, powiedzmy że masz średnia firmę gamedevową i masz do obsadzenia 10 stanowisk dla stukaczy assetów. Teraz masz do wyboru: A- wydać 5 tysięcy dolarów na 10 licencji SD lub Quixela i zatrudnić gości którzy potrafią zbrusha, PSa i jakiś pakiet 3d. B - Wydać 20 tysięcy dolców na 10 licencji Houdiniego i zatrudnić o wiele wiele bardziej kosztownych gości którzy potrafą to co powyżej + Houdiniego.

Najpierw było porównanie Quixel vs Substance Designer. Potem dopiero dołączył Cycles Bake. Faktycznie takie porównanie tu pada ale chyba jesteś przewrażliwiony bo nadal dyskusja dotyczy tematu robienia teksturek metodami proceduralnymi. Co jest złego w porównywaniu konkurencyjnych softów?

Byłbym wdzięczny jakbyś mi pomógł nagrać taki filmik. Wtedy to ja postawie ci piwo. :) Jakby ktoś się zastanawiał o co biega z tym OSLem- Pełna nazwa to Open Shading Language, jest to język shaderów offline stworzony przez Sony Imageworks. Korzysta z niego obecnie Arnold (wersja od sony), Vray i Cycles który był tworzony w bardzo mocno w oparciu o OSLa. Pare przykładów co można w nim uzyskać: Do wyrenderowania tych obrazków nie została użyta żadna tekstura, cała magia tkwi w samym shaderze, suwakami można zmieniać parametry efektu. To powinno łatwo zobrazować jak niesamowitym narzędziem do wypalania tekstur jest Cycles, a raczej będzie gdy zostaną załatwwione sprawy związane z workflowem i dodadzą shadery działające podobnie jak te z silników realtime.

Plan jest taki że jak skończę tego addona (dokładniej to plik który podmienia się w miejsce interfaceu scene properties) to nagram z niego masę gifów w dodatkowymi adnotacjami i spiszę proposal na wiki blendera. Tam umieszczę link do pobrania addona żeby ludzie mogli sobie poklikać i sprawdzić możliwe opcje i zależności. O filmiku jeszcze nie myślałem ale to by była również bardzo spoko sprawa. Mój angielski w mowie niestety kuleje więc musiałbym poprosić kogoś o pomoc. Anyone? :) Substance Painter oczywiście będzie świetnym dodatkiem do bakeu w cyclesie. Będzie można nim malować maski do wykorzystania w mix-shaderach.

Offtop: Działam. Na razie skończyłem design i jestem na finiszu addona który symuluje działanie nowego interfacue bakeu. 1200 linni kodu który nie robi zupełnie nic. :P Mam nadzieje że ten proposal przejdzie gładko. Jeśli tak się stanie to by znaczyło że blender bedzie pierwszym pakietem DCC który umożliwi batch bake bez potrzeby skryptowania. Lepiej, będzie możliwość ustawienia kolejki bakeowania w taki sposób że kolejne render joby będą korzystały z danych wygenerowanych przez poprzednie. Bake chain. Czyli w pierwszym bake jobie wypalasz np AO, normal i jakąś proceduralną maskę a w następnym jobie używasz ich do miksowania shaderów z dodatkowa pomocą nodów OSL. Jak chcesz potraktować inny asset takim samym wypalaniem to wystarczy że skopujesz sobie bake joba (lub bake joby w przypadku łancucha), podmienisz meshe i zachowasz resztę ustawień taką samą. Dosyć podobne zachowanie do Substancea z taką tylko różnicą że nie musisz pierniczyć się z pisaniem XMLa tylko ustawiasz wszystko od razu w blendku i wciskasz jeden button. Jak dojdzie distributed rendering do Cyclesa to będziesz miał możliwość wypalenia wszystkich assetów gry jednym kliknięciem. :)