alex3d

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

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

@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 :) To jest wspaniała rada :) Hura! :)

Spoko, czyli co do tego się obaj zgadzamy. Jasne, że implementacja jest łatwiejsza niż pisanie czegoś swojego, ale nie ma co deprecjonować pracy Dietricha, bo ogarnięcie myśli takiego łebstera jak Ken Museth, siedzącego w tym przeszło 20 lat wymaga jednak pojęcia tematu. To jest ciekawe i fajne, że deweloperzy tacy jak np. Matt Ebb, którzy mają już styczność z tą wysoką półką w branży, jednak lubią coś tam sobie napisać do blendera. Otwarty kod jednak kusi :)

@Skoti rozumiem zamysł Twojego posta, ale szkoda czasu na taką pustą dialektykę. "Kawał dobrej roboty" pasuje wyśmienicie do implementacji jaką wykonał Kevin Dietrich. To "podpięcie" wcale nie jest taką prostą sprawą jak Ci się wydaje - OpenVDB to obszerna biblioteka. Pyroevil to bardzo dobry developer i go cenię, ale napisał skrypt (jeżeli porównujemy to ze standardami w branży), którego praktyczne zastosowanie będzie bardzo ograniczone i trafi do szuflady tak jak wiele mu podobnych: Mesh from particles (metaball-based add-on) PFluid Tools (metaballs-based add-on) MSMesher (OpenVDB-based add-on) Particle Surfacer (WIP MC-based add-on) Polygonizer for particles (WIP MC-based modifier; patch for Blender 2.60 available) Można tym co najwyżej zrobić gluta takiego jak od lat za pomocą fluidów. Natomiast zainicjował temat meshera w blenderze i zrobił skuteczny pressing na innych developerów, którzy pewnie przetrą sobie szlak i później będą szukać pracy jako TD. Liczy się efekt i jakość, dobre chęci nie wystarczą. Z mojego punktu widzenia jest to przełom i otwiera blenderowi kilka opcji więcej z zakresu VFX, natomiast paradoksalnie po zaimplementowaniu OpenVDB większym ograniczeniem w symulacjach będą: blenderowy particle system i wydajność viewportu plus jeszcze parę innych kwestii.

Skompilowałem dzisiaj OpenVDB i spatchowałem "particle meshera" pod OpenSUSE. Szybki teścik przy 200K cząsteczek. "Cube surfer" się nie umywa do implementacji Kevina Dietricha - wykonał kawał dobrej roboty; kod jest szybki i forma modyfikatora daje sporo dodatkowych możliwości.