Blender - NEWS oraz dyskusje

[Monio]

Nezumi- User preferences > System > Region overlap (pod window draw method). Super się to prezentuje, jeszcze się animują przy włączaniu. :D

 

n-pigeon- Dziękóweczka.

[ikkiz]

dyntopo i workfow...

Ja próbowałem i tak doszedłem do wniosku, że by trzeba w 2 etapach sculptować:

 

1 dyntopo i forma z grubsza bez wchodzenia w low frequency detail

1a retopo, ale tak, żeby siatka i topologia była na gotowo już do UV i rigowania

1b multires

1c może shrink wrap nowej siatki na sculpt.

2 finalny sculpt z l.f. detail

2a wypalanie normalek, czy co tam jeszcze trzeba

 

Nie wiem, czy to praktyczne do robienia człowieków, bo każdy ludź to ma podobną topologie i szybciej base mesh stosować

Ale potwory, drzewa, inna organika, to jak najbardziej, zwłaszcza jak i tak się dopiero wymyśla formę.

[floo]

Bulid z Cycles Material Preview

http://builder.blender.org/download/

[Monio]

blenderartists.org/forum/showthread.php?279074-Blender-Development-Fund/

 

Dobry temat. Ale smutny. Jakieś kilkaset tysięcy użytkowników programu a ludzi którzy dorzucają jakiś grosz na rozwój programu niecałe 270 osób... Jeden dobrej klasy grafik za granicą wyciągnie te 2800 euro miesięcznie. Oczywiście są jeszcze dvd czy kasa z pojedyńczych przelewów ale tak czy inaczej to są grosze.

Jak to u was wygląda. Dorzucacie się? Ja 5 eurosów miesięcznie daje i kupiłem 3 dvd (w tym blenderelle która jest tragiczna ;) ).

[Nezumi]

Monio, wydaje mi sie, ze to kazdego prywatna sprawa jak to "u niego wyglada". Bez obrazy ale takie publiczne spowiedzi maja zerowa wartosc. Kazdy moze napisac "no, jaaaa to nawet wiecej daje!". Warto oczywiscie podnosic ten temat, zachecac do datkow i uswiadamiac jak malo srodkow wplywa od uzytkownikow. Jednak pytanie kazdej osoby z osobna uwazam za zarowno bezcelowe jak i nieeleganckie. Mamy sie na forum wywnetrzac ile i na co i dlaczego tylko tyle a jeszcze moze przepraszac, ze nie wiecej? Dajmy spokoj lepiej temu tematowi - kto chce da a kto nie chce to trudno.

 

Te setki tysiecy to sa sciagniecia - diabli wiedza ile osob jest aktywnych zawodowo, ile osob zarabia na blenderze i tak dalej.

 

(A swoja droga - kto narzeka na powolny rozwoj Blendera??? Przeciez rozwija sie bardzo ok, plany na najblizsza przyszlosc sa jasno okreslane i realizowane w miare sprawnie.. Nie kumam..)

Edytowane 10 Luty 2013 przez Nezumi

[Monio]

Łe? Nie przechwalam się tylko z ciekawości pytam. Przecież nikogo nie zmuszam do odpowiedzi, kto chce ten powie.

 

Rozwój blendera leci bardzo spoko dlatego do obecna ekipa ładuje w to dużo serca. Dobrze by było żeby kasy starczyło na tyle żeby fundacja mogła niektórych zatrudnić na stałe i za godną kasę. Blender na dzień dzisiejszy jest super ale do roboty nadal jest bardzo dużo. Nie mówię o nowych super ficzerach tylko dosyć podstawowych rzeczach jak Dependency graph i viewport które będą wzięte na warsztat w tym roku.

[Nezumi]

Spoko, nie mowie ze sie chwalisz. Pytasz w taki sposob - "ja wspomagam Blendera, a wy?". No a wiekszosc z nas NIE. Skad to wiem? Ano stad, ze NA CALYM SWIECIE 267 osob zadeklarowalo regularne wplaty. To o co tu pytac? ;)

 

Fajnie ze podales linka bo to rozwaze.

Maja jednak racje tam na forum - jesli przychodzi do kasy to trzeba sie rozliczac dokladnie i transparentnie prezentujac dokumentacje a nie jakies "W tym miesiacu zaplacimy Luckowi za 20 godzin i jak cos zostanie to dla Mietka bedzie na przyszly miesiac", bo to niepowaznie wyglada. Chocby i tylko z powodow formalnych.

[szczuro]

a ja nie wpłacam i póki co nie rozważam ;P jest tyle innych sposobów żeby wspomóc blendera, że nie czuję potrzeby.

[Monio]

Przede wszystkim robić dobre rzeczy i pokazywać że się da. :)

 

--------------

 

 

Zabrałem się za sculpt i dyntopo. Daleko temu do wygody i kontroli zbrusza, to fakt. Standardowy pędzel jest zupełnie do bani i to chyba dla tego moje wcześniejsze próby ogarnięcia sculptu kończyły się po kwadransie. Natomiast za pomocą clay strips i flatten da się już całkiem wygodnie rzeźbić. W temacie stabilności i jakości siatek Dyntopo pół roku temu a teraz to jak niebo a ziemia. Bardzo mocno czekam na możliwość wstawiania własnym matcapów bo wybór obecnych jest kiepski.

W sumie wrzucam to tak na prawdę z innego powodu, coś co mnie zmiotło z powierzchni ziemi. Przecież można sobie przed sculptem ustawić studio jak trzeba i potem renderować to co chwila w cyclesie. :D

Mój setup to 3 lampy z plejnów strackowane do empty na środku. Wszystko do kupy sparentowane do drugiego emptiego który się kręci dokoła osi Z dzięki czemu jak odpalam render to sobie timelinem kręcę całym światłem.

Niestety przed renderem trzeba odświeżyć model wchodząc i wychodząc z editmode. To by było mistrzostwo świata jakby dało się scupltować mając cały czas odpalony render. :D

Tak czy to mnie już definitywnie ugruntowało w potrzebie zakupu mocarnej grafy. Za chwile premiera nvidia Titan i mam nadzieje że inne karty potanieją. Albo uzbieram kasę i sprowadzę sobie tego Titana.

[Idaho]

Monio, podziel się studiem ;P

A tak przy okazji jak Ci się udało tak ładnie wygładzić ? Po wyłączeniu już dynatopo to po prostu jest niewykonalne przy jakimś tam zagęszczeniu siatki. Muszę spróbować workflow ikkiza ale termin mnie goni i śpię po 3-4 h na dobę i na razie nie mam czasu. Jeśli to nie tajemnica jak wygląda twój ? Zbieram tips & tricks na jakąś wolną chwilę żeby przysiąść i szybciutko coś zrobić a nie męczyć kilka-naście godzin zanim dojdę co i jak;).

Pozdrawiam

Edytowane 10 Luty 2013 przez Idaho

[n-pigeon]

Bardzo ciekawy DM:

 

Hi all,

 

Here's notes from today's meeting in irc.freenode.net #blendercoders:

 

1) Upcoming 2.66 release

 

- Main release showstopper is problems with Cycles GPU rendering for 32 bits systems. Brecht van Lommel and Sergey Sharybin will work on this the next few days.

 

- Bug tracker has enough issues to keep fixing, but no (other) showstoppers are there. Assuming the Cycles topic gets handled, we'll call for a Release Candidate on wednesday.

 

- Next sunday meeting we'll review the results of the RC release and decide on an actual release day.

 

2) Other projects, targets for 2.67

 

- Freestyle: no news... but still possible.

 

- Ton Roosendaal will work on a nice C implementation (+ Py access) for Pie menus.

 

- Brecht: Current Cycles roadmap: SSS, 'Ubershader', Displacement, Volumes, and then Baking.

 

- Stuart Broadfoot will work on Cycles hair closure and a minimum pixel width.

 

- Proposals are being reviewed for Rigid Body Constraints editing and visualization.

 

- Sergey will work on tools for more automatic motion tracking.

 

- Antonis Riakiotakis: will further work on texture paint:

http://wiki.blender.org/index.php/User:Psy-Fi/Texture_Paint

 

- Campbell Barton now has a 3d printer, he already works with Dolf Veenvliet on good tools to help 3D print designers.

 

- Ton will work on cleanup of .blend file read/write flagging. This should enable 'template files' for example (like having multiple startups).

 

-Ton-

 

Nareszcie widzę Baking na ToDo Cyclesa \o/! Jednak mam nadzieje, Displacement i ubershader wyjdą w trakcie tworzenia SSS, a nie po :B

[Monio]

Baking! Modły zostały wysłuchane. :D Reszta rzeczy też jest świetna.

 

Monio, podziel się studiem ;P

Proszę. Sculpta przejechałem decimation ale reszta rzeczy jest na miejscu.

Z objaśnieniem workflowu będziesz musiał poczekać bo sam go sobie jeszcze wyrabiam. Jeszcze nie ogarnąłem sculpt tools addon a widzę że wymiatacze ochoczo z niego korzystają. Jak zrobię jeszcze ze 2 takie miśki to nagram jakiś timelaps z czymś większym i na początku objaśnię co i jak jak ustawiać. Też mam teraz średnio z czasem.

 

Z takich szybkich tipsów na teraz. Sprawa wygląda tak że najważniejsze jest przełączanie opcji w samym sculpcie i wyświetlaniu. Trzeba bardzo pilnować suwaka detail size w zależności z jaką partią modelu pracujemy. Działam tak że clay strips robię formę dodając geometrie bez opcji colapse edge a potem dopiero wygładzam i redukuje siatkę flatenem z włączonym colapse. Siłą pędzla i curve operuje bardzo często. Te drugie to na razie trochę pain in the ass, bede musiał sobie zrobić własny preset ze zdefioniowanymi krzywymi. Obadaj jak działa ta kłódeczka przy sile pędzla, daje zupełnie inne efekty- włączona do detali i wyłączona do szybkiego dodawania masy. Jak zaczyna ci zamulać sculpt to wchodzisz i wychodzisz z edit mode.

 

Wyświetlanie w wiewporcie to koniecznie matcapy, niestety obecne tak jak mówiłem są do luftu, tylko 4 są jakoś sensowne. Czekamy na opcje dodawania własnych. Na testach które robiłem wychodzi że matcap przy gęstym modelu potrafią przyśpieszyć viewport nawet 7-krotnie! Światła ustawione żeby wyświetlały się jako Wire, razem z opcją Only render nie widać ich w ogóle podczas rzeźbienia i nie rozpraszają uwagi. Podłoże przydaje się w renderze ale może przeszkadzać w sculpcie. Dlatego dół wycięty i Backface culling żeby od spodu obiekt był niewidoczny i można było dół sculpta rzeźbić. :)

 

Render trzeba ustawić na odpowiednio małą ilość sampli i odbić. Jak kto lubi, chodzi o podgląd oświetlenia a nie final render. Przed renderowaniem trzeba updatować bryłkę wskakując na chwile do edit mode. Wduszam (shift + b) żeby ustawić wycinek viewportu który ma się renderować, (shift + alt + b) żeby wyłączyć renderowanie regionu. Do odpalenia cyclesa ustawiłem sobie własny skrót. Robie kombosa (tab / tab / shift + alt + z) i po 3 sekundach mam zajebisty renderek z GI. Potem (z /z) i z powrotem jestem w sculpcie. :)

Cheers.

[n-pigeon]

Jak zwalnia to klikamy przycisk Optimize, a nie jakieś tam edit modey :P

[Idaho]

Monio, serdecznie dziękuję. Widzę że to jednak trzeba trochę dłużej posiedzieć. Czekam z niecierpliwością na tutek. Dzięki jeszcze raz.

Pozdrawiam

[Monio]

Jak zwalnia to klikamy przycisk Optimize, a nie jakieś tam edit modey :P

Miałem nadzieje że tak to będzie działać ale pomaga tylko połowicznie. Trochę szybciej się po tym sculptuje ale nadal to nie jest taka poprawa jak odpalenie edit mode. Przetestuj sam. Druga sprawa że bryła nie odświeża się w renderze a uwierz że mając taką możliwość chce się to odpalać co 2 minuty. :D

 

Idacho- Ja jeszcze poczekam na własne matcapy. Dobry matcap naprawdę diametralnie zmienia sposób pracy z bryłą. Pojawią się buildy z tą opcją to znowu pobawię się blenderowym sculptem i nagram tutka. :)

[Coyote]

@monio co do matcapów to jest taki sposób na około żeby zrobić screen materiału z zetki albo narysować swój w photoshopie i potem wpiąć go go jako teksturę z mapowaniem po normalnej :)

ja tak sobie często fejkuje fresnela (białe tło czarne kółko i mieszanie na add)

[n-pigeon]

Tą metodę używaliśmy wcześniej, mapować texa za pomocą wektora normalnych, ale nowe zintegrowane matcapy są wygodniejsze i wydajniejsze.

 

Możliwość dodawania własnych obrazków jako matcapy zapowiedzieli na następną wersje, choć mi obecna kolekcja odpowiada, ma wszystko czego potrzebuje.

 

@Monio

 

Jakie matcapy byś dodał, zarzucisz linkiem?

[ikkiz]

SSS, 'Ubershader', Displacement, Volumes, and then Baking.

koncert życzeń normalnie - ja to już będzie, to już nie wiem czego więcej bym mógł chcieć.

[Monio]

wpiąć go go jako teksturę z mapowaniem po normalnej

Wiem i stosowałem ale wydajność w vievporcie jest wtedy słabsza niż przy standardowym materiale a przy nowych matach tak jak pisałem- nawet 7 krotnie wydajniejszy viewport.

 

n-pigeon- Chociażby te które posyłałem Tonowi. Klik. Używam ich w zecie teraz i spisują się dobrze. Numerki 1, 2, 4 i 5 teoretycznie niewiele się różnią ale tylko jak się patrzy na kulkę. Przy sculpcie zmieniają odbiór bryły.

 

ikkiz- OSLa i wydajnych włosów na GPU. ;)

[Nezumi]

Co do matcapow to te wszystkie chromowe kulki jak dla mnie maja zerowa wartosc - ani to sie nie nadaje do rzezbienia ani do prezentacji bo nic nie widac. Chyba ze ktos silver surfer'a chce zrobic albo T1000...

Te ktore pokazal Monio sa swietne i do rzezbienia i do prezentacji (przynajmniej wygladaja na takie). No, ale nie ma co narzekac - bedzie w koncu opcja dodawania swoich wiec ok.

[Monio]

Nezumi prosił więc wrzucam moje matcapy w wersji zbrushowej. Klik. Wszystkie nieźle komponują się z wax modifier. Cheers.

Edytowane 11 Luty 2013 przez Monio

[Nezumi]

Wielkie dzieki! Swietnie sie prezentuja.

 

(Musisz rozdać trochę punktów innym użytkownikom zanim będzie można przyznać punkty Monio. Eeee...)

[n-pigeon]

Moim zdaniem różnorodność defaultowego setu jest dobra, ja tam znalazłem use-cases dla kilku o których nigdy bym nie pomyślał, że mogą mi się do czegoś przydać :) (w tym połyskliwe i chromeballe).

 

Jednak moje ulubione to szary wosk z światłem od góry - super jako podstawka lubię ciemne materiały przy modelowaniu, a światło z góry, miękkość i dobra siła speca pozwalają dobrze czuć bryłę, biała miękka - do sprawdzania siły detalu na mocno diffusowym materiale, i czarna z back lightem oraz toon spotem z prawej - super do obczajania siły detalu przy fresnel lub rim light.

Moim zdaniem wadą zestawu nie jest to co tam wsadzili tylko, że mało :D

 

@Monio thx przydadzą się na pewno. :)

 

PS

OSL na GPU to raczej ToDo dla OSL nie Cycles :P

[Skoti]

PS

OSL na GPU to raczej ToDo dla OSL nie Cycles :P

Nie do końca - OSL to otwarta specyfikacja i przykładowa implementacja. W implementacji nie mają zamiaru wprowadzać wsparcia dla GPU i innego sprzętu niż jest dziś obsługiwany, a zbywają jedynie tym, że jeśli ktoś chce to sobie napisze warstwę pośrednią tłumaczącą kod (co w sumie nie jest wielkim problemem). Więc jeśli blender chce korzystać z OSL i tłumaczyć to na OpenCL to jest to dla nich ToDo - tylko nie do końca jest tu sens... ba większy sens ma wywalić OSL i oprzeć całkowicie o OpenCL.

[Nezumi]

Moim zdaniem wadą zestawu nie jest to co tam wsadzili tylko, że mało :D

Najwieksza wada jak dla mnie jest to ze masek nie widac z wlaczona matcapa.

[n-pigeon]

@Skoti

 

Z tą warstwą pośrednią to nie wiedziałem :O

 

większy sens ma wywalić OSL i oprzeć całkowicie o OpenCL.

 

Tego nie rozumiem, domyślam się, że chodzi Ci o to by zamiast wykorzystywać implementacje OSL jako core, to lepiej napisać własną implementacje dla OSL w OCL? To już raczej grubsza sprawa, a tylko Brecht miałby kompetencje do takiego zadania, a to już za dużo roboty dla jednego człowieka.

 

Zdaje się, że na razie i tak większego sensu w opieraniu Cycles na OCL nie ma, więc jeśli już Blenderowcy w własnym zakresie postanowią wspierać OSL dla GPU, to wykorzystają warstwę pośrednią o której piszesz.

 

Choć ja zdecydowanie wolałbym, by czas poświęcony OSL przeznaczyć na rozwój nowych nodów, ale to już moje osobiste widzi mi się. :P

 

 

@Nezumi

 

To albo bug, albo przyszłe ToDo :) zgłaszałeś to? Coś odpisali?

[Monio]

Skoti dobrze mówi. Spectral Pixel na przykład bazuje na OSLu i potrafi to renderować na GPU. Miło jakby jakiś zdolniacha zabrał się za podobną technologie w blenderze żeby utrzymać kompatybilność cpugpu.

Tylko błagam... PO dispie, SSS, wolumetryce i bejkowaniu. :P

 

Masek z matcapami po prostu nie ma. Duża niedogodność. Nie znalazłem nic co by mówiło że ktoś się tym zajmuje. Jak wyjdzie pełny 2.66 to na pewno ludzie zaczną się tego domagać i ktoś to wprowadzi. Można w międzyczasie już trochę szumu zrobić.

Edytowane 11 Luty 2013 przez Monio

[Nezumi]

Nie, nie zglaszalem bo obecnie zglaszam co moge do Krity. Generalnie myslalem ze to ja nie wiem gdzie sie je wlacza na poczatku - moim wieczorem oficjalnie zglosze i zobaczymy. Niektore rzeczy rozumiem, ze trzeba zglaszac ale to wydaje mi sie podstawowa funkcjonalnoscia... Zglosze tak czy owak.

A na SSS tez czekam. Bedzie miodzio.

[Idaho]

Nie jestem za bardzo na bieżąco ale czy będzie możliwość wypalania AO dla floating objects w cycles ? W internalu o ile pamiętam się nie da. BTW Czekam na xNormal pod linucha :P

[Monio]

Całe wypalanie czegokolwiek w cyclesie będzie dopiero za kilka miesięcy. Jednak na dobre rezultaty z floating geometry chyba nie ma co liczyć bo cycles opiera się o odbijanie się promieni więc wypali ci to tak jakby obiekt faktycznie był ponad powierzchnią. Można by ewentualnie te cienie uciąć za pomocą noda ShadowRay ale nadal pozostaje problem z odbijaniem się promieni od spodu obiektu.

 

Pytanie do n-pigeona. Czym tak na prawdę będzie ten Ubershader? Jaka będzie różnica w porównaniu do kilku nodów połączonych mixshaderem?

[Skoti]

Tego nie rozumiem, domyślam się, że chodzi Ci o to by zamiast wykorzystywać implementacje OSL jako core, to lepiej napisać własną implementacje dla OSL w OCL? To już raczej grubsza sprawa, a tylko Brecht miałby kompetencje do takiego zadania, a to już za dużo roboty dla jednego człowieka.

Nie - wywalić OSL zupełnie i o OSL zapomnieć. Zamiast OSL wykorzystać po prostu kernele OpenCL, które wcale nie gorzej (dobra odrobinę gorzej, ale jest to nieistotne przy zaletach) się do tego nadają niż OSL czy MSL. Ot zamiast shaderów zrobić include funkcji "shaderów" w OpenCL. Najlepiej zrobić w OpenCL po prostu ubershader i wykonywać go prosto z renderera w OpenCL. Z OSL to jest taka moda chwilowa IMHO i skończy się tak jak rozwijanie osobno fizyki brył sztywnych dla GE osobno ciuchów, osobno... a teraz zdano sobie sprawę, że nie tędy droga, i trzeba to co pisano przez lata wyrzucić i skorzystać z Bullet. W Cycles przynajmniej od początku wiadomo, że z OSL to droga na manowce i trzeba rozwijać zupełnie osobne renderery. OpenCL nie stał się podstawą wszystkiego, bo wyszedł Brecht z założenia, że nie jest jeszcze do tego gotowy i rozdrabnia się pisząc jednocześnie w CUDA, OpenCL i C++/OSL 3 różne renderery. Brecht ma racje bo OpenCL w wykonaniu AMD nie daje rady, a implementacje AMD/Intel na x86 zasysają jeśli chodzi o wydajność. Jednak w między czasie pojawiły się implementacje korzystające z LLVM z wydajnością bardzo dobrą (jest kompilowany normalnie jak C/C++) i już można zrobić na OpenCL implementacje dla wszystkiego (a przynajmniej CPU i Nvidii w GPU) jako jednolitą platformę - renderer w OpenCL korzystający z ubershadera w OpenCL (+ filtry kompozycji postprocess w OpenCL i jest miodzio ;]).

 

Zdaje się, że na razie i tak większego sensu w opieraniu Cycles na OCL nie ma, więc jeśli już Blenderowcy w własnym zakresie postanowią wspierać OSL dla GPU, to wykorzystają warstwę pośrednią o której piszesz.

Nie wykorzystali (bo te które istnieją są zamknięte), a napisali program/bibliotekę tłumaczącą OSL na kernel OpenCL, ale wtedy i tak nie połączysz tego z rendererem na GPU tylko obliczysz shader.... w przeciwieństwie do implementacji renderera w OpenCL

[n-pigeon]

@Idaho Monio

 

W BI da się w Cycles też będzie można, tak przynajmniej mi się wydaje. W BI zdaje się trzeba było wyłączyć Cast aproximate albo shadow... czy coś, nie pamiętam wieki temu robiłem, no i działało tylko dla Aprox AO. W Cycles będzie trzeba wyłączyć Shadow w Ray Visibility dla obiektu, ewentualnie z poziomu shadera - użyć Light Path node i Is Shadow Ray jako maski dla AO node i Transparent. Jeśli to bake samego AO to nie powinno być dodatkowej iluminacji.

 

@Monio

 

Ubershader to połączenie, Diff, Gloss i Refrakcji i kilku dodatków dla ich mieszania fresnel, absorbcja (przynajmniej mam taką nadzieje) i może coś jeszcze. Różnica będzie w prędkości, choć prawdopodobnie niewielka. Ważniejszą rzeczą ma być dodatkowy mechanizm zabezpieczający to co wysyłasz do noda, by w końcowej mieszance nie było nadwyżek energii, czyli żeby materiał nie oddawał więcej światła niż dostaje, co jest dość łatwo nieumyślnie zrobić z obecnymi nodami.

Musiałby się wypowiedzieć ktoś bardziej kompetentny ode mnie, ale są różne systemy/algorytmy odwzorowujące fizyczne mieszanie się diffuse i glossa, i ubershader będzie używać jeden z nich, by właśnie nie doszło do takich nadwyżek. W całym tym cyrku chodzi o to by shader wyglądał bardziej realistycznie.

 

Znaczy można uważać by żaden kanał RGB textury albo koloru nigdzie nie miał wartości większej niż 0.8 albo czystej czerni (która także może namieszać), ale trudno to ciągle kontrolować i czasem jest to niemożliwe bez zrobienia drzewka math nodów które za nas by to pilnowały.

 

Ostatnią kwestią jest wygoda i powszechność używania takiego shadera, praktycznie każdy realistyczny materiał musiałby go używać, każdy materiał ma diffuse, gloss i refrakcje, nawet takie które z pozoru mają tylko jeden, albo 2 komponenty - no choć przy większości i tak użyjemy głównie diff gloss albo gloss refract, ale też nie do końca bo wiele materiałów które są uznawane za bardzo przezroczyste mają trochę diffuse nie tylko gloss.

Ba, często takie shadery trzeba nawet używać warstwami mixując je z fresnelem, także będzie to dość intensywnie wykorzystywany nodzik.

 

Tutaj możesz potestować shader jednego kolesia któremu Brecht, miedzy innymi, się przyglądał:

http://vadrouillegraphique.blogspot.fr/2012/08/multilayer-physically-correct-shading.html

http://vadrouillegraphique.blogspot.fr/2012/12/enter-physically-correct-shading-world.html

http://www.octopod-studio.com/page.php?dalang=uk#|47,uk

 

 

 

@Skoti

 

Tylko co wtedy z wykorzystywaniem shaderów? Czy nie utrudni (uniemożliwi) to wymiany między silnikami? No i nie tak szybko z tym ubershaderem, bo dobrze jest mieć coś ponad ten 'jedyny słuszny shader" :P Chyba, że Cię źle zrozumiałem.

Edytowane 11 Luty 2013 przez n-pigeon
błędy językowe ah błędy językowe

[Skoti]

Tylko co wtedy z wykorzystywaniem shaderów? Czy nie utrudni (uniemożliwi) to wymiany między silnikami?

A kiedy taka wymiana się odbywała? Ba ze względu na licencje nie jest możliwe zabrać kod shadera z jednego silnika do innego. OFC jeśli na tym zależy komuś to nic nie stoi na przeszkodzie stosować "import/eksport" shaderów i generować z shaderów nody/generować shadery OSL z nodów, w cycles nie korzystając z OSL, a korzystając z wewnętrznego rozwiązania opartego o OpenCL (OSL można traktować jako taki uniwersalny format pośredni dla samych nodów, a używać ich bezpośrednio w rendererze).

[n-pigeon]

Shaderami GLSL i HLSL ludziki się jakoś dzielą, ale twój pomysł z używaniem OSL jako formatu wymiany to ciekawy pomysł.

[Skoti]

Shaderami GLSL i HLSL ludziki się jakoś dzielą

Shadery z blendera są na GPL (była rozmowa kiedyś na liście dyskusyjnej, gdzie Ton nie do końca był pewien na jakiej licencji, ale miały automatycznie doklejone GPL, więc na takiej) i ktoś tam pytał czy może użyć ich shaderów (nie wiem po co, bo nic w nich ciekawego) i nie mógł przez licencje (która nie była wymagana, bo kod nie był linkowany z kodem programu w żaden sposób). Co do jednak GLSL i HLSL to nikt się nie dzieli - podaj mi shadery z Unreal Engine, Unity czy innych komercyjnych silników (podobnie jak shaderów Pixara nie widziałeś i nie zobaczysz, mimo, że masz darmowe rendermany). Mimo, że wystarczy odpalić debugger gpu i kod masz nie możesz go użyć. Dzielą się ludzie kodem shaderów tylko na otwartych licenchach jak MIT, BSD czy GPL (w tym 3cim wypadku dzielą się tylko pomiędzy osobami lubiącymi GPL).

 

Ogólnie przyjemnym konceptem byłoby API do eksportu z nodów blendera i pojawienie się eksporterów do OSL, RSL, MSL, GLSL czy sam mógłbyś łatwo dopisać eksport do przykładowo własnego binarnego formatu + zapis/odczyt z natywnego dla blendera formatu (dawno ubolewałem nad tym, że grupy nodów można robić, a nie można sobie zapisać i odczytać w innym projekcie tylko budować z klocków od zera) - ułatwiłoby to współprace z rendermanami i innymi renderami (nawet silnikami gier) - nie tylko z OSL.

Edytowane 12 Luty 2013 przez Skoti

[n-pigeon]

Mhm, no to było by to fajne rozwiązanie. Jestem tylko ciekaw czy Brecht rozważał coś podobnego, pisanie 3 silników na raz powinno go szybko zmęczyć, ale czy rozważał użycie LLVM, a było by to też z korzyścią dla użytkowników, chyba, że ma to jakieś dodatkowe minusy. No i Cycles był by od razu gotowy na czas gdy AMD w końcu dogoni resztę świata (choć coś czuje, że to nigdy nie nastąpi i Intel ich zje xD).

 

Raczej z nimi nie rozmawiałeś na ten temat, co? :) Byłbym ciekaw ich opinii o takich rozwiązaniach.

 

PS

No shaderów pixara, unity itd. to nie widziałem i się nie dziwie, a unreala to tylko screeny drzewka nodów w sumie trochę podpatrywałem.

[Skoti]

Mhm, no to było by to fajne rozwiązanie. Jestem tylko ciekaw czy Brecht rozważał coś podobnego, pisanie 3 silników na raz powinno go szybko zmęczyć, ale czy rozważał użycie LLVM, a było by to też z korzyścią dla użytkowników, chyba, że ma to jakieś dodatkowe minusy.

Myślę, że nie rozważał, ale rozważał całość w OpenCL, jednak go AMD odstraszyło ;p.

Blender obecnie korzysta pod linuksem z gcc, pod windowsem z kompilaotra microsoftu, a do OSL llvm.

LLVM to tylko maszyna wirtualna/kompilator - do tego trzeba back end - są gotowe front-endy OpenCL ogólnodostępne (a LLVM już wykorzystuje - OSL to front-end dla LLVM, OpenCL/CUDA/MSL u Nvidii czy OpenCL u Apple (głównego twórcy llvm) to front-end do LLVM - przez ostatnie kilka lat mocno się rozwijał i teraz jest mocnym konkurentem dla GCC).

[n-pigeon]

AMD go odstraszyło, a pisanie tego samego 3 razy nie :D?

 

Ok popatrzymy w którą stronę to wszystko pójdzie.

[mrys]

Mam dziwne wrażenie, że w całej tej dyskusji przyjmuje się za dogmat, że materiał MUSI być realistyczny, a poprawny fizycznie rendering to cud miód. No i że głównym zadaniem grafiki 3d są wizualizacje. Nie negując takich opinii nie uważacie, że dla części przynajmniej grafików od superrealizmu ważniejszy jest np wyraz artystyczny? I że często osiąga się go wykraczając poza sztywne ramy "poprawnych" materiałów czy oświetlania zgodnego z prawami fizyki?

 

Dla mnie idealny byłby renderer łączący możliwości realistycznego odwzorowania świata z możliwościami elastycznego manipulowania dowolnym elementem składowym materiału. Oddzielenie specular od reflection, jakie do niedawna było właściwie standardem dla silników biasowych dawało właśnie takie możliwości. Nagle wszyscy odkryli, że to to samo, i że trzeba zachować równowagę energetyczną. W Modo jest to rozwiązane bardzo fajnie - chcesz to spinasz spec i refl, nie chcesz to nie spinasz. Chcesz zachować równowage energetyczną - zaznaczasz ptaszka przy odpowiedniej pozycji, nie chcesz - nie zaznaczasz. Pełna swoboda. Mam cichą nadzieję, że Cycles pójdzie właśnie w taką stronę.

[legomir]

@mrys ja wiem tylko co sądzi n-pigeon, ale wytłumaczenie mu dlaczego ktoś lubi rendermany i ich elestyczność oraz, że renderowanie na mircropoly ma zalety względem zapisu scen w trójkątach jest nie możliwe(tak jak wytłumaczenie paru innych rzeczy, ale tak to już jest :P )

 

Oddzielenie specular od reflection, jakie do niedawna było właściwie standardem dla silników biasowych dawało właśnie takie możliwości. Nagle wszyscy odkryli, że to to samo, i że trzeba zachować równowagę energetyczną.

 

Nie odkryto teraz, ale dopiero teraz ma sie taką moc, która pozwala zwracać uwagę na takie duperele. Przedtem miało to dobrze wyglądać ot i tyle przy czym bez silnika symulującego fizycznie GI było bez sensu symulowanie całkowicie realistycznych shaderów. Zresztą moim zdaniem to po prostu moda na rynku CGI.

 

Ogólnie przyjemnym konceptem byłoby API do eksportu z nodów blendera i pojawienie się eksporterów do OSL, RSL, MSL, GLSL

 

MSL to chyba już chyba odchodzi w przeszłość, a zastąpi go chyba MDL(Material Description Langue). Nie jestem pewien czy dałoby się przekonwertować do RSL ponieważ Cycles działa na innej zasadzie chyba.

[mrys]

Nie odkryto teraz, ale dopiero teraz ma sie taką moc, która pozwala zwracać uwagę na takie duperele. Przedtem miało to dobrze wyglądać ot i tyle przy czym bez silnika symulującego fizycznie GI było bez sensu symulowanie całkowicie realistycznych shaderów. Zresztą moim zdaniem to po prostu moda na rynku CGI.

 

"Odkryto" to taki skrót myślowy - wiem, że to nie nowość. Tyle, że dla elastyczności warto byłoby mieć obie opcje, a obserwuję tendencję do koncentrowania się na zespoleniu spec i refl.

[Skoti]

AMD go odstraszyło, a pisanie tego samego 3 razy nie :D?

Co by cię bardziej odstraszyło rzecz wymagająca więcej pracy czy niemożliwa? Kod Cycles dla OpenCL jest znacznie bardziej rozbudowany niż jest to włączone w buildach, ale co z tego, że napisał, jak nie działa (błędy kompilatora AMD) i kod sobie czeka już od bardzo dawna, aż użycie go będzie możliwe (tzn jest u Nvidii czy Intela, ale nie u AMD).

 

MSL to chyba już chyba odchodzi w przeszłość, a zastąpi go chyba MDL(Material Description Langue). Nie jestem pewien czy dałoby się przekonwertować do RSL ponieważ Cycles działa na innej zasadzie chyba.

MDL to z tego co pamiętam kastrat na potrzeby iRay, bo ten nie byłby w stanie obsługiwać całego MSL, więc wątpię, aby MDL zastąpił MSL, a raczej kiedy iRay dorośnie to zmieni na MSL. RSL to opis shaderów, a to jest takie samo i nie ważne jakim rendererem jest Cycles - RSL jest stosowany w bardzo odległych od siebie rendererach.

 

Mam dziwne wrażenie, że w całej tej dyskusji przyjmuje się za dogmat, że materiał MUSI być realistyczny, a poprawny fizycznie rendering to cud miód. No i że głównym zadaniem grafiki 3d są wizualizacje. Nie negując takich opinii nie uważacie, że dla części przynajmniej grafików od superrealizmu ważniejszy jest np wyraz artystyczny? I że często osiąga się go wykraczając poza sztywne ramy "poprawnych" materiałów czy oświetlania zgodnego z prawami fizyki?

Nie czytałem całego wątku, ani nawet ostatnich stron, ale jeśli tak ktoś uważa to jest w błędzie - Cycles z założenia mial olewać fizyczną dokładność i miał być szybkim rendererem wystarczająco dobrze udającym, aby dało się go dalej używać do filmów.

[le_chu]

Nie czytałem całego wątku, ani nawet ostatnich stron, ale jeśli tak ktoś uważa to jest w błędzie - Cycles z założenia mial olewać fizyczną dokładność i miał być szybkim rendererem wystarczająco dobrze udającym, aby dało się go dalej używać do filmów.

 

Dlatego ja w jednej ze swoich wypowiedzi wyrazilem zdziwienie ze nadal nie ma rozdzielenia spec od refl :) Wydawalo mi sie to logicznym rozwiazaniem widzac to jak dziala Cycles. Moze ktos bardziej aktywny w spolecznosci anglojezycznej jest w stanie skrobnac jakiegos maila do Brechta?

[mrys]

Nie czytałem całego wątku, ani nawet ostatnich stron, ale jeśli tak ktoś uważa to jest w błędzie - Cycles z założenia mial olewać fizyczną dokładność i miał być szybkim rendererem wystarczająco dobrze udającym, aby dało się go dalej używać do filmów.

 

Zauważ, że odniosłem się raczej do dyskusji niż do Cyclesa samego w sobie. A w dyskusji problem rozdzielania bądź nie spec i refl tudzież tego, co koszerne i dobre dla renderera zajmował sporo miejsca :)

[n-pigeon]

@Skoti

 

Rozmawialiśmy o użyciu samego OpenCL jako pojedynczego core, który obsługiwałby zarówno GPU jak i CPU, sam to opisywałeś, a i tak użytkownicy AMD musieli by używać trybu tylko dla CPU.

To to co opisywałeś jest możliwe, czy niemożliwe bo już się pogubiłem ^^'

 

@mrys, le_chu

 

Mowa była o odwzorowywaniu fizycznych materiałów na potrzeby realistycznych renderów, a potem wyjaśnialiśmy, dlaczego nie istnieją prawdziwe materiały mające właściwości tradycyjnego Specularity i jak uzyskać takie odbicia, jakie było widać na tej ilustracji z obrazem.

Za jakiś czas prawdopodobnie ujrzymy Phong i Diffuse Ramp w Cycles (jest na ToDO list) i wtenczas jeśli ktoś będzie chciał, by jego render wyglądał "plastikowo", albo "CG", to będzie mógł ich używać, tak samo będzie z nieużywaniem ubershadera, Cycles ma dawać bardzo dużo wolności.

Ja sam czekam na Phong Ramp, przyda się do obiektów w tle.

[Skoti]

Rozmawialiśmy o użyciu samego OpenCL jako pojedynczego core, który obsługiwałby zarówno GPU jak i CPU, sam to opisywałeś, a i tak użytkownicy AMD musieli by używać trybu tylko dla CPU.

To to co opisywałeś jest możliwe, czy niemożliwe bo już się pogubiłem ^^'

Tak tylko odstraszyło to wcześniej kiedy nie było dobrych implementacji na CPU (a implementacja AMD dla CPU też ssie ;p).

 

Za jakiś czas prawdopodobnie ujrzymy Phong i Diffuse Ramp w Cycles (jest na ToDO list) i wtenczas jeśli ktoś będzie chciał, by jego render wyglądał "plastikowo"...

Phong jest fajny do plastiku, ale do innych rzeczy wolałbyś użyć Ashikhmin-Shirley, Ward, Cook-Torrance. Nie trywializuj odrębnego specular do plastikowego Phonga.

Edytowane 13 Luty 2013 przez Skoti

[le_chu]

Za jakiś czas prawdopodobnie ujrzymy Phong i Diffuse Ramp w Cycles (jest na ToDO list) i wtenczas jeśli ktoś będzie chciał, by jego render wyglądał "plastikowo", albo "CG", to będzie mógł ich używać

 

Tak dla uscislenia, tu nie chodzi tylko o uzyskanie stylistyki CG czy plastikowej. Wiele shaderow idzie bardzo szybko ustawic w ten sposob, nie tracac nic na fotorealizmie (a jedynie na teoretycznej fizycznosci).

[n-pigeon]

@Skoti

 

E tam, wszystkie speculare z bliska wyglądają plastikowo :P Choć przydało by się to prawda.

Edytowane 13 Luty 2013 przez n-pigeon

[Skoti]

@Skoti

 

E tam, wszystkie speculare z bliska wyglądają plastikowo :P Choć przydało by się to prawda.

Wszystkie? Beckmann (ostatnio robiłem implementacje w GLSL i działa nieźle na mobilkach nawet) czy GGX stosowane obecnie w Cycles też? Beckmann jest stary jak świat i opiera się na nim Cook-Torrance, a GGX to kolejna praca Torrance'a i kilku innych gości. To co Ci się podoba to nie tyle, że nie ma spec (bo jest), a to, ze łatwo się go ustawia (wystarczy glossiness materiału i tyle), a efekt który Ci się podoba, to zaleta głównie pathtracer vs raytracer.

 

BTW. Właśnie sprawdziłem kod blendera i z tych przytoczonych wcześniej Ashikhmin-Shirley i Ward już są (pod Velvet i Anisotropic).

[n-pigeon]

Mowa o rampach (reagujących jedynie na direct light) nie o prawdziwym refl :P