alex3d

Szykuje się pełen metraż z udziałem Blender Animation Studios :) w kooperacji z firmą Fu Works. Film ma opowiadać o przygodach znanego z komiksów Agenta 327 i ma mieć charakter komercyjny. Strona projektu: http://agent327.com/

 

The animation studio of Blender Institute and film production company Fu Works will make a feature length animation movie based on the renowned “Agent 327″ Comic series by Martin Lodewijk. This was announced on the 23rd of April during the presentation of the 20th album of Agent 237, “De Daddy Vinci Code”.

 

 

http://www.blendernation.com/2015/04/23/the-blender-foundation-announces-a-feature-length-film-project-agent-327/

TubeTool addon:

 

https://github.com/zeffii/TubeTool

 

 

i kolejne narzędzie w ramach addona Miratools

 

@Monio, bardzo dobra wiadomość, wreszcie Dalai się zreflektował. Coś wiadomo w kwestii podglądu?

To co niedźwiadki lubią najbardziej :)

 

 

Kawał roboty, materiały i detale rozwalają, nie ma co pisać, można tylko patrzeć i podziwiać :)

@ Akierek, albo ja mam jednak za wolny net albo Twoje obrazki "png" są z deka przyciężkie (26 mb per photo :) ?) Problemem jest oświetlenie sceny i kadrowanie.

 

Semiproceduralna sosna w 5 min...

 

 

@deshu coś w tym stylu jak mówisz, tzn. nie jest to stricte scattering, ale ma dać taki efekt, tyle że obliczenia są w formie symulacji, żeby uniknąć przenikania geometrii. Kwestia nazewnictwa, co soft to trochę pojęcia nabierają innego znaczenia, ale przypisanie materiałów z konkretnym shaderem w blenderze można zrobić losowo dla poszczególnych obiektów, a i sam shader dzięki paru nodom może być taki, że tworzy praktycznie nieskończoną liczbę wariacji.

 

Słowo shader mnie zmyliło:)

Heh:), no pewnie jacyś magicy od rendermana w Pixarze daliby radę zrobić to w 100% w shaderze z dobrym displacementem, ale obliczeniowo na odcinku 0,5 km nie wiem czy byłoby to bardziej wydajne niż instancje + możliwość artystycznej/ręcznej korekty dzięki temu, że jest to full 3D. Natomiast w samym blenderze można by to zrobić w 100% w shaderze w OSL.

Mógłbyś powiedzieć coś więcej?

 

@deshu w swoim czasie rozkminiałem temat "kocich łbów" przy jednym z projektów (status wip, który mam nadzieje niedługo ukończyć), gdzie potrzebowałem kilkaset metrów XIX-wiecznej drogi wyłożonej kamieniami i temat nie dawał mi spokoju :) Jest kilka metod - displacement, sculpt, jakiś moduł w stylu tileable, particle system albo addon Cell Fracture (coś jak voronoi pattern w houdinim) ale z różnych względów żadna z nich mi się nie sprawdzała szczególnie pod kątem jakości/realizmu i czasu pracy, poza tym zależało mi na pełnym 3D i wydajności przy renderowaniu, więc opracowałem swoją.

 

W sumie pisanie o tym zajmuje więcej czasu niż samo wykonie :) Takie paręset metrów ulicy przy niewielkim oskryptowaniu (nie jest to konieczne) można zrobić w blenderze w paredziesiąt minut. Upraszczając, idea jest taka, że system cząsteczek dobiera losowo kamienie (z palety 300-500 sztuk), które nastepnie są poddane symulacji w wyniku czego są ułożone tak jakby to zrobił brukarz (dobra losowość, brak przenikania geometrii, możliwość ustawienia odległości między kamieniami). Powiedzmy, że na 25 metrów drogi przypada 25 tys. instancji, czyli parę milionów trisów. Druga kwestia to losowość materiałów i cycles jest tutaj naprawdę bogaty w opcje niezależnie czy budujemy shader proceduralny czy jest on oparty o uv-ki/mapy (m.in. node object info), nie wchodząć w szczegóły atrybut pointiness to coś w stylu dirty mapy tylko nie potrzeba UV-ki, w związku z czym nie trzeba tego bejkować, chociaż można :), jednocześnie zastępuje "dirty vertex" (vertex painting) i przyspiesza wiele kwestii.

 

Reasumując, mamy dzięsiątki, setki metrów ulicy z 400 kamieniami w formie instancji. O ile geometria 400 kamieni z racji instancji się powtarza (chociaż są pod różnym kątem, poobracane, zanurzone do połowy w nierównym gruncie itd. itd.; zresztą w rzeczywistości ilość niepowtarzalnych kształtów realnych kamieni też zamyka się w niewielkiej liczbie) to materiał można tak dopracować, że spośród setek instancji w zasadzie nie będzie identycznego kamienia. W blenderze jest kilka typów intancji, ten typ o którym mowa, daje możliwość zmian w materiale/shaderze. Jeśli chodzi o wydajność to render kocich łbów bez otoczenia wypada tak, że przykładowo 25 m ulicy zajmuje 500 mb na GPU, kolejne 5 metrów to dwa mega więcej, kolejne 5m to znów jakieś 2 mega :) itd. itd. Przy displacemencie, jeżeli mamy uniknąć powtórzeń to czym dłuższa ulica tym więcej geometrii, w przypadku instancji paredziesiąt milionów trisów nie robi różnicy, oprócz tego przyrostu paru mega.

 

Również Dzięki :) Bardzo fajny wykład. Respekt, szczególnie zaimponowało mi się, że niekoniecznie szedłeś mainstreamem tylko miałeś własny wybór narzędzi (Messiah, FPrime itd.) dzięki którym osiągnąłeś pożądany efekt artystyczny i techniczny, poza tym podejście człowieka renesansu, modelowanie, teksturowanie, riggowanie...etc. no i fakt, że większość tych filmów udało Ci się zrobić w krótkim odcinku czasowym. Pozdrawiam

@wjaworski to już 6 lat :)? Hehe latka lecą :), ale jak już człowiek raz przesiąknie ergonomią blendera to nie można go wyeliminowac ze swojego workflow :) Pozdr :)

Grubo :) Po raz kolejny szacunek za niesamowitą, obszerną publikację i promocję blendera. Pozycja obowiązkowa dla osób zaczynających przygodę z blenderem . W języku angielskim jest spora ilość literatury dotyczącej blendera i parę dobrych książek o animacji, ale żadna nie opisuje w tak kompleksowy sposób podstaw tego softu od modelowania po ostateczny render.

Ciekawy trend i ciekawe jak rynek się ukształtuje. Pomysł nie jest nowy, w zasadzie jedyne kryterium to jakość realtime-u, bo pomijając jakość to równie dobrze taki spacer można było zrobić 20 lat temu w jakimś banalnym programie typu ArCon :) Pytanie jak takie rozwiązanie ma się np. do Lumiona:

patrząc z punktu widzenia klienta i realizmu jakiego oczekuje/ile zapłaci i z punktu widzenia wizkowca i jego czasu pracy.

Test shadera z instancjami i artybutem pointness (cycles;blender 2.74):

 

Skoro już o takich sprawach mowa to jakby w odpowiedzi kierunek na 2-3 lata dla systemu animacji w blenderze: http://code.blender.org/index.php/2015/03/animation-system-roadmap-2015-edition/ Blender, przy jego wszystkich cnotach to przede wszystkim soft do animacji, więc fajnie, że chcą*ugryźć temat.

 

Buildy testowe Blendera 2.74:

http://download.blender.org/release/Blender2.74/

http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.74

Kawał warsztatu, obejrzałem całość, bardzo interesujące przemyślenia zarówno co do samorozwoju i stawiania celów w grafice 3D jak i co do samej specyfiki pracy animatora. Czym spowodowane jest tak duże opóźnienie (rok?) w udostępnieniu nagrania z wywiadu, autoryzacja etc.?

Na to wygląda. Korzyści z ostatnich projektów były dość wątpliwe. Jest to jakaś strata, ale z drugiej strony tematom takim jak Viewport FX IV zrobi różnice czy będą realizowane przez GSoC? Chyba nie. Jest to sygnał i powód dla BF i blendera dla powstania planu jego długofalowego rozwoju wraz z pomysłem na finansowanie - tak jak to się odbywa w dużych koncernach, które są liderami na rynku - strategia rozwoju na lata 2015-2020. Powinny być sprecyzowane cele, które będą realizowane według ustalonego programu. Teraz jest tak, że gość pracuje nad OpenVDB w blenderze, a w zasadzie cały system cząsteczek nadaje się do wymiany. Blender posiada ogromną dynamikę w swoim rozwoju, ale niestesty efektywność wielu kierunków jest prawie żadna. Cycles rozwijany, brakuje mu displacementu; genialne addony, które po 6 m-cach przestają być aktualne itd. itp. Poza tym, to nie jest tak, że inne softy stoją w miejscu - takie bajery jak zremesher w Zbrushu, czy solvery dla symulacji piasku, tłumu w Houdinim to kolejna generacja rozwiązań w programach 3D, gdzie blender wyraźnie odstaje.

Dzięki Monio, bardziej chodziło mi o to co się dzieje przed stricte renderowaniem, tj. aktualizacja shaderów/sceny itd. i działanie na dużych scenach z bejkiem symulacji itp., ale blenderowi chyba faktycznie nie robi to aż takiej różnicy - no nic, przekonam się w przyszłym tygodniu.

Czas zmodernizować stację graficzną, jak się ma combo blender+linux do dobrej klasy dysku SSD? Jak SSD przekłada się na czasy renderowania, ładowania scen, inną wydajność (przerzucanie między warstwami) itd.?

Klasyka, motyw z psami wymiata :) :) :)

Bishop to jednak konkretny gość: https://developer.blender.org/D1092, szkoda, że jest zatrudniony tylko na potrzeby Ptex.

 

I mała ciekawostka, modyfikator "Normal Edit" https://developer.blender.org/rBf6e798946092c5d30ad0c011bd8c2920971471b2

@rice, ograniczenie VRAM to jedna kwestia, ale mnie irytuje limit ilości indywidualnych tekstur jakie może łyknąć GPU, ale tego się*już nie przeskoczy :)

@disaster, tak jak mówi Monio - błąd precyzji(https://developer.blender.org/T34094), natomiast wydawało mi się, że ta zmiana https://developer.blender.org/D819 miała m.in. ten efekt ograniczyć. Disaster, której wersji blendera używasz? GPU/CPU? Możesz wrzucić blend z tym błędem?

Instrukcja korzystania z Ptex: http://wiki.blender.org/index.php/User:Nicholasbishop/Ptex

 

Prezentacja cyclesa w Rhino:

@skoti nie da się czytać tego bełkotu, tzn. zaczynam czytanie Twoich postów i kończę na nicku.

 

Dalszy postęp Bishopa w pracy nad PTex-em:

 

Nie byłbym sobą, gdybym nie poprawił rażące mnie stwierdzenie "implementacja jest łatwiejsza niż pisanie czegoś swojego".

 

@Skoti, haha Ty tak serio:)? Jak już w tak krytycznym tonie "Wujka Dobra Rada", to lepiej brzmi (bardziej dosadnie) moim skromnym zdaniem "nie poprawił rażącego mnie stwierdzenia" albo "nie poprawił rażące mnie stwierdzenia" albo postawiłbym przecinek przed rażące :)

 

http://www.youtube.com/watch?v=E9JoOh9fBR0

 

Ok, problem w tym, że popełniasz błędy logiczne na poziomie językowym w tej dyspucie, stawiając mylne tezy i uparcie przypisując je swojemu rozmówcy, już nie mówię o jakieś bardziej wnikliwej wykładni/analizie posta.

 

Otóż przywołany termin "implementacja" ma szersze znaczenie niż to stosowane w informatyce, w naukach prawnych używamy go jako wdrożenia, wprowadzania w życie [ang. "implementation", łac. "implere"] i to miałem na myśli: "wdrożenie istniejącego rozwiązania jest łatwiejsze niż pisanie czegoś własnego". Co do reszty to przemilczę, bo szkoda mi czasu :) No to masz jeszcze jeden pretekst, żeby coś zacytować ze mnie :)

Już prędzej "napisanie wsparcia dla API gotowej implementacji (w tym wypadku OpenVDB) jest łatwiejsze niż zaprojektowanie i zaimplementowanie własnego rozwiązania."

 

To jest wspaniała rada :) Hura! :)