Skocz do zawartości

Rekomendowane odpowiedzi

Napisano (edytowane)

Eee... moze dlatego, ze nia ma masz tylu narzedzi do modelowania na volumach i paru innych rzeczy nie mowic o tym ze blender nie jest demonem proceduralizmu, a implementacje w Houdinim robil w sumie sam dreamworks?

 

Dostaniesz fajne szybkie volumy ale nie dostaniesz tego wszystkiego oprocz volumow co sklada sie na calosc narzedzia.

Edytowane przez legomir
Napisano (edytowane)

Hooooooolyyyyyyyyyyyyyyy.................... MESHER!!!

 

iso_both_wip.jpg

 

Przeglądałem materiał Disneya o tym jaki ma patent na śnieg (www.youtube.com/watch?v=4HpaB-kHMBo) i przypomniał mi się molecular addon i blog pyroevila (mam zajawkę i chciałem zobaczyć jego testy SPH, bardzo fajne symulacje ma na blogu) - no i niespodzianka. Wykrakane, my tu gadu gadu o houdinim (swoją drogą śmiga na linuxie jak malina) i OpenVDB, a pyroevil rozpoczął prace nad mesherem w blenderze :)))))) Z tego co pisze to ma być taki przejściowy mesher, żeby podciągnać skilla w kodowaniu i żeby do czasu OpenVDB jednak blender miał to narzędzie :) Gdyby 3Dcoat nie przejęło wtedy farstharego to by się działo w temacie :) - uważnie śledziłem jak implementował SPH. Fajnie, że się pojawił nowy zdolny dev :), oby tym razem BF się postarała lepiej. Wygląda na to, że będzie miał dobrą wydajność, bo te dwie próby mesherów jeden a'la metaball i drugi oparty poniekąd na OpenVDB i dll nie działały jak trzeba - pierwszy niewydajny, drugi z defektem memory leak.

 

Symulacja oceanu z shaderem cyclesowym - 100% w blenderze, marzenia się spełniają (o ile będzie można coś więcej zrobić niż te gluty na testowym obrazku) :)

 

http://pyroevil.com/2014/10/22/work-in-progress-isosurface-addon-mesher/

Sergey, też nie próżnuje

 

PS słyszeliście, że blender jest wpisany do UNESCO - Collection of Digital Resources for Teaching and Learning :) ?

Edytowane przez alex3d
Napisano

@dzięki rice, Ton w roli wróżki :), pewnie i tak połowy planów nie zrealizują na czas, ale co tam :) Nie miałem czasu tych prelekcji posłuchać w tym roku, jakieś plany co do cyclesa?

Napisano

Dzisiejsza rozmowa na z BF-Cycles. Może za rok coś się ruszy z Cyclesem na OpenCLu. Ludziki z CUDA też na tym zyskają.

 

I work for AMD, and we have been thinking about working in the OpenCL kernel (read: have started working on it). It is, I presume, a well-known fact that the OpenCL implementation has "issues" on AMD.

 

Our current approach is to split up the OpenCL kernel into multiple (smaller) kernels, in order to get better utilization of the GPU. I've had brief discussions with Martijn, Brecht and Ton, and they all seem eager to finally "fix" (for a lack of a better term) OpenCL, which is a good sign.

 

Technical details have not been discussed yet, but an open forum like bf-cycles is a better place for that.

 

As a starter point of discussion, I'd like to comment about the main motivation of the kernel split. As it is well known, the AMD OpenCL implementation has some problems compiling the current OpenCL kernel. This has been mainly attributed to the length of the kernel, and problems with register allocation. Although the above is correct, those causes fail to address the main issue, which is the fact that a huge kernel (like cycles) that is a straight-forward port of CPU code, does have a lot of code divergence. Code divergence causes a lot of workitems go idle during kernel execution, which is not a good thing.

 

Splitting the kernel allows for each (sub)-kernel to have better GPU utilization, and hence better performance. As a side-effect, it decreases the size of each kernel, and makes things easier for the register allocator. So, the current problems that the AMD OpenCL implementation has will not express themselves in a split kernel. Our current thought is to have those individual kernels communicate via queues.

 

Any questions / comments / etc. about our approach is welcome, of course.

 

Appreciated,

George Kyriazis

 

Hi George, your initiative is very welcome and I welcome you to the bf-cycles list.

 

Splitting the Cycles kernel is a good idea and it will hopefully fix the problems on the AMD architecture, while improving performance for GPUs in general as well. We managed to do ?ok? in the past few years on nvidia, but we were also constantly hitting boundaries and limitations. So a more future proof and modular design is likely the way to go.

 

I am looking forward to more details, and we are available when you have questions.

 

Best regards,

Thomas Dinges

 

I think it's great to see AMD getting involved like this.

 

Splitting the kernel is certainly a challenge, the Cycles megakernel

is quite complicated, and to be honest it's been pushed further than

it should be. We've had to do lots of workarounds and tweaks so that

it runs on NVidia, and it just barely works.

 

If the kernel splitting works out, that's likely to improve Cycles GPU

rendering for everyone, not just for AMD users, but also to better

support features like SSS or volumetrics, and reduce problems with

display responsiveness. So this work is very welcome.

 

Brecht.

Napisano
http://www.blenderguru.com/podcasts/ep52-blender-disease-feature-checklist-culture/

Bake w cyclesie? Check! :D

Dobry podcast. Temat główny zaczyna się od 21 minuty i dotyczy jakości ficzerów w blenderze. Szalenie duże prawdopodobieństwo gównoburzy ale gość ma po prostu racje.

 

Jakis czas temu przesluchalem i faktycznie dobry podcast. Ale zauwaz ze nie do konca koncentruje sie jedynie na problemie z nowosciami, ale mowi o tym jak wazni sa devovie ktorzy "opiekuja sie" juz istniejacymi featuresami i namawia do dotacji.

Skrajnosci nie sa dobre w zadna ze stron - gdyby pojsc w druga strone to moznaby powiedziec "olac w ogole bake cyclesie, zajmijmy sie dopracowywaniem symulacji cieczy ktory juz jest i wymaga dopracowania". Albo cokolwiek innego co "juz jest". To tez jest swojego rodzaju utopia - przeciez Blender i tak nie moze dorownac Zbrushowi, RealFlow, Houdiniemu - wszystkim tym softom ktore sa wysoce specjalizowane. Zawsze bedzie cos w czym sa lepsze. Obojetnie gdzie postawimy poprzeczke znajdzie sie ktos dla kogo bedzie ona za nisko i ktos dla kogo bedzie az za wysoko.

Ale nie o tym chcialem - tak mi sie skojarzylo bo przegladalem sobie tutoriale jakies. A propos tego ze Blender to taki "Jack of all trades, master of none". Ludzie czasami przeginaja w druga strone z uzywaniem specjalistycznych softow bez wyraznej potrzeby. Takie zabijanie muchy przez bombardowanie miasta. Wezmy taki tutorial:

https://gumroad.com/l/Bpfsv

"We use Photoshop, Maya, Blender and Zbrush". Fajnie, tylko ze efekt ni cholery nie usprawiedliwia uzycia tego arsenalu... Sporo takich jest tutkow gdzie ktos tam modeluje postac w Zbrushu, UVki w UVLayout, potem tekstury w mieszaninie pietnastu roznych softow, bo przeciez zeby smarknac cos na teksture natychmiast potrzebny jest najnowszy Substance Painter a zeby wypelnic cos kolorem - Mari. Potem jeszcze slina skapujaca z pyska orka musi byc symulowana RealFlowem, kawalek materialu na ramieniu - NIEZBEDNY najnowszy Marvelous Designer, calosc w oparach rodem z Houdiniego. Jeszcze tylko galazka drzewa prosto ze Speedtree Cinema i lecimy z renderem w jakims najnowszym mozliwym wynalazku - najlepiej cos czego uzyto przy ostatniej Hollywoodzkiej produkcji za pierdylion dolarow.

Po co? Takie "PRO" na sile. To tak dla przeciwwagi ;)

Napisano

Jedni patrzą na features jako na argumenty, którymi będą się bić na forach, inni patrzą na to, przez pryzmat swoich potrzeb i możliwości.

Napisano

Jako całość nie ale ma sporo ficzerow ktorych brak w cyclesie albo są w powijakach. Bardziej zaawansowane parametry w proceduralnych teksturach. Shadow catcher z dowolnego materiału bardzo potrzebny w compositingu. Duzo wydajniejszy i stabilniejszy baking. W cyclesie do dzis brak defaultowego uber shadera (czego nie potrafie zrozumieć).

Napisano
W cyclesie do dzis brak defaultowego uber shadera (czego nie potrafie zrozumieć).
Jako, że nigdy nie czułem potrzeby posiadania defaultowego uber shadera w cycles (skonstruowałem sobie parę własnych presetów) chciałbym spytać Cię dlaczego uważasz to za coś koniecznego? Czy troszczysz się o początkujących użytkowników, czy też z Twojego punktu widzenia jest to ważne?

Pytanie zadaję jak najbardziej poważnie.

Napisano

Mowa o początkujących userach oraz zaawansowanych którzy chcą szybko ustawić coś prostego.

Oboje wiemy co to jest fresnel i jak za jego pomocą miksować glossy z diffusem. To jest "banał" który rozpoczyna pracę nad shaderem w 90% przypadków. Więc skoro jest to coś tak powszechnego to jak dla mnie taki preset powinien być wbudowany od razu w blenderze, nawet jako zwykła nodegrupa która można sobie rozbebeszyć przez Alt+G w celu późniejszego manualnego edytowania.

 

Wyznaje zasadę że jeśli da się zautomatyzować prostą i często wykonywaną czynność to powinno się zautomatyzować. ;)

Napisano

a z tym ubershaderem to tylko o to chodzi, żeby był taki jak preset/grupa? Nie miało tam być czegoś w rodzaju energy conseration, albo czegoś podobnego?

 

Pytam bo serio nie wiem, a to by była różnica. Gdyby było w nim coś specjalnego, co trudno zrobić samemu, to hell yeah!, czemu go jeszcze nie ma!? Ale z drugiej strony, to mi się nawet nigdy nie chciało zapisywać presetu do ponownego użycia, jakoś tak robię bezmyślenie zawsze od początku, więc taki preset to mi na nic szczerze.

Napisano

Jestem również zdania, że należy korzystać z presetów. To po prostu ułatwia. Z drugiej strony nie przeszkadza mi, że blender takowych nie ma. Mam potrzebę korzystania z presetów, więc je sobie sam stworzyłem. Są moje, więc są szyte na miarę.

Oczywiście problem jest taki, że trzeba włożyć trochę wysiłku w ich stworzenie, w to, żeby były elementem startowego blenda itp. Jest to uciążliwe, zgadzam się.

Blender generalnie nie ma presetów do niczego, stąd pewnie też nie ma ubershadera. Istnienie ubershadera pewnie by mi nie przeszkadzało, ale jego brak również nie powoduje u mnie drgawek. Chciałem się jedynie podzielić moim skromnym zdaniem.

Napisano

ym. no i właśnie przeczytałem dlaczego wszystkie renderyz cycles są plastikowe... Bo jak ktoś pisze że się robi diffiuse mix glossy.. i jako mix fresnel to nie dziwota... wpierw polecam ogarnąć co i jak a potem pisać. Niema ubershadera z jednego bardzo wielkiego konkretnego powodu. amianowicie tego jak jest zrobiony shadeing w cycles. to po prostu nie miało by sensu i logiki.

Napisano (edytowane)

Ikkiz- Gdyby w środku była dodatkowa node grupa odpowiadająca za konserwacje energii to byłoby idealnie. Fajnie by było to podsunąć DingTo bo taki preset ma być dodany w przyszłości kiedy przejdziemy w standardzie na Cyclesa z internala.

 

Bartek- Jak uważam że blender zyskałby na takich wbudowanych presetach, nie tylko do cyclesa. Oczywiście wszystko w granicach rozsądku, nie chcemy ściągać gigabajta śmieciowych tekstur. To by była jakaś mała cegiełka która mogłaby polepszyć ogólny user-experience dla wielu ludzi.

 

Azbesty- O czym ty pierniczysz? :) To co opisałem to podstawowy shader PBR. Ubershader jest już w drodze, robi go DingTo.

Edytowane przez Monio
Napisano

A to nie jest też trochę tak, że uniwersalny shader renderowałby się znacznie wolniej? Bo w rzeczywistości to nic innego jak grupa wielu nodów zamknięta w jednym schemacie. IMO jeden z kilku materiałów, który powinien być jakoś defaultowo dostępny to proste, normalnie renderujące się szkło. Zwykły Cyclesowy Glass Shader to totalna zmylka.

Napisano

Azbesty- Jest poprawny tylko po prostu bardzo okrojony. Żeby dało się z niego zrobić coś więcej potrzeba sporo do niego dodać.

 

le_chu- Jeśli to sprowadzałoby się tylko do zrobienia node grupy to renderowałoby wolniej. Dlatego w innych rendererach ubershadery są niskopoziomowo optymalizowane.

Napisano

Jak czytam niektore wypowiedzi, to dochodze do wniosku ze czesc ludzi nie wie czym jest ubershader. Problem z blenderem jest taki, ze duza czesc osob, to ludzie ktorzy nigdy nie korzystali z niczego innego niz blender i twierdza ze wszystkie rozwiazania w blendku sa najlepsze i nic nie trzeba usprawniac. Ubershader to nie preset na konkretny material, a szybkie rozwiazanie na budowanie wlasnym materialow. Zeby w cyclesie zlozyc jakis sensowny material to i tak trzeba uzyc przynajmniej 10 "klockow" jak nie wiecej. Jak komus tak wygodniej to ok, ale czemu by nie dac mozliwosci innym uzytkownikom ktorzy lubia troche inny workflow. To tak jakby nie dac blenderow splinow, bo komus wystarcza samo poly.

Napisano

Dochodzisz do dobrych wniosków bo nie istnieje definicja ubershadera - luźne słowo z pogranicza Niemieckiego i Angielskiego które opisuje idee shadera do ogólnych zastosowań. Czy jest to niskopoziomowe rozwiązanie czy grupa klocków - opinie są chyba różne zwłaszcza patrząc na blenderowe tutoriale poruszające ten temat. Ale to czepianie się o słowa, chyba wszyscy wiedzą o co chodzi.

Napisano (edytowane)

Co do ubershadera, to pomijając korzyści i kwestie jak ten shader może być zarządzany przez GPU, to jest to po prostu wygodne rozwiązanie - regulacja suwakami wielu opcji, tak jak to ma miejsce w wielu rendererach. Jest to obok displacementu, brakująca w cyclesie podstawowa rzecz. Jak ktoś śmiga w nodach na poziomie podobnym do Bartka, to ma maksymalną kontrolę nad shaderami, więc ubershader jest wtedy pewnie jakimś uproszczeniem, ale zawsze lepiej mieć wybór.

 

Nie mogłem się oprzeć i pobawiłem się trochę buildem gooseberry branch - jest dostępny do pobrania dla linuxa 64 bit z https://builder.blender.org/download/. Color wire, DOF, AO we viewporcie, fajna sprawa. Z ograniczeń, które wyhaczyłem: w tej chwili jedyny parametr, któremu można przypisać klatkę kluczową to kolor siatki wire, więc np. DOF-a się nie zanimuje.

 

wire.png

 

Gooseberry co prawda w innej formie niż to miało być pierwotnie, ale wygląda na to, że jedynym problemem blendera jest wpompowanie w niego odpowiedniej kasy, zatrudnienie na etacie paru devów więcej, cały czas korzystając z dobrodziejstwa open source i tego, że każdy koder dookoła globu może dorzucić swoją cegiełkę pro publico bono, bo ma taką zachciankę, bo jest doktorkiem na uczelni i robi sobie badania nad symulacją fal oceanicznych albo z 1000 innych powodów. Reasumując, gdyby zmienić trochę proporcje i blender miałby szerszy i stabilny core team to nie widzę możliwości, żeby nawet jakaś globalna firma nadążyła za takim tempem.

 

Dla przykładu: w teamie Solid Angle pracuje około 30 wysoko specjalizowanych osób i to jest wystarczające, żeby arnold był liderem światowym w dziedzinie rendererów. Ilu dobrej klasy programistów potrzebuje blender? Na te pytania powinien odpowiedzieć sobie Ton i znaleźć menedżera (takiego, który go nie wykiwa, skoro Ton jest wizjonerem to powinien mieć jakiegoś finansistę dobrego, choćby żonę :) ), który stworzy plan jak uzyskać odpowiednie środki, czy to przez społeczność, czy to przez sponsorów. Jak ktoś myśli racjonalnie o Open Source, to wie, że potrzeba komputera, że potrzeba czasu, środków, prądu, że nie wszystko jest darmowe w czystej postaci - każde inne myślenie to utopia. W takim wydaniu OS jest tańsze/ niegorsze niż komercha, a koszty są parę razy mniejsze. Blender/Blender Foundation wciąż nie wykorzystują swoich możliwości.

Edytowane przez alex3d
Napisano (edytowane)

xDDD Max tak nie umi bez odpowiedniej ilości pluginów ^^ jak coś to minusik nie odemnie

 

blender + luxrender render nie mojego autorstwa.

 

10369991_10204088395547424_6109413083319739355_n.jpg?oh=517d54ee980c932c3b31be4f05d5f0d3&oe=54E82069&__gda__=1424407172_bfc1e516e763b5ffc199ff8074f70653

Edytowane przez Azbesty
Napisano
Mozesz w prostych, zolnierskich slowach wyjasnic co to cudo robi? ;) Powaznie pytam. JAkis przyklad zastosowania bo niby wiem, a nie wiem...

 

1. Masz sculpt x milionów poly bez UV. I tego UV nie zrobisz bo żaden soft na ziemi tego nie udźwignie. Robisz szybkie retopo/zremesher i rozkładasz UV które potem transerujesz na hipoly. Teraz możesz już sobie spokojnie malować texe w czymkolwiek zechcesz.

 

2. Masz gęste lowpoly z UV i namalowaną texe. Robisz odchudzaną wersje jako level of detail. Transterujesz UV i model może korzystać z tej samej texy, nie muszisz nic bejkować i marnować VRAM w grze na nową texe.

 

2. Te same modele co w punkcie 2. Transferujesz sobie wagi vertów żeby niższy LoD mógł korzystać z tego samego riggu.

 

3. Masz sculpt zrobiony dyntopo (kaszaniasta siatka) z vertex paintem. Transferujesz ten vertex paint na sculpt z dobrą siatką do pozowania. (powstały przez zatwierdzenie subsurfa/multiresa + shrinkwrapa)

 

Bastien za parę dni zrobi experimental builda z tym transferem. Wrzucę link jak się pojawi na Graphicallu.

Napisano (edytowane)

Fracture-Helpers-Addon - dobra rzecz, m.in. fracture wzdłuż krzywej - ostatnio czegoś podobnego szukałem, tyle tylko, że łączyłem dynamic paint z fracture i z modyfikatorem explode (jeśli chodzi o ten drugi, to ciężko było mi wyciągnąć animację wag z dynamic painta, ale jeszcze popróbuję).

 

Kierunek rozwoju VFX w blenderze jest ostatnio bardzo intrygujący. Pyroevil pracuje nad mesherem dla systemu cząsteczek, jak uda się to połączyć SPH i jego molecular addonem i takimi rzeczami jak poniżej to robi się potężne narzędzie w blenderze. Woda, piasek, ogień, dym, inne struktury (piasek nasączony wodą), nie będzie rzeczy, której nie da się zrobić w blenderze na poziomie symulacji. Zresztą jeśli chodzi o piasek, to solver z molecular addona jest naprawdę dobry. Zrobienie realistycznej symulacji piasku w houdinim przy użyciu standardowych solverów, nawet tych ukrytych wcale nie jest takie proste. A zrobienie czegoś takiego (http://vimeo.com/user811710) wiąże się*już z napisaniem własnego granular solvera, który niekoniecznie ktoś*tak chętnie upubliczni jak to jest w przypadku blendera. Można narzekać, że nie ma jeszcze w blenderze tego i tamtego, ale czasem warto docenić i wykorzystać to co już jest na naprawdę profesjonalnym poziomie.

 

 

AddonFracture_helpers_path_3.png

 

Do pobrania tutaj:http://df-vfx.de/blender_downloads/

Edytowane przez alex3d
Napisano (edytowane)
Hi all,

 

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

 

1) Release status for 2.73

 

- Planning wiki page:

http://wiki.blender.org/index.php/Dev:Doc/Projects

 

- Multiview: Sergey Sharybin and Campbell Barton review monday.

Dalai Felinto should also put the code in developer.blender.org "differential".

 

- No reply yet to the review for compositor. Jeroen Bakker, could you check still?

 

- Tamito Kajiyama: Freestyle memory patch has delays, will move to next release.

 

- A lot of projects are getting late again. The general consensis is to stick to the plan though.

Multiview should really be ready to merge now, or we move it another release.

 

- Monday or tuesday we check the status again and call for an official "BCon3" (no new features, just stabilizing).

 

2) Other projects

 

- The Gooseberry team will come with a planning for migration of the branch for 2.74 or later.

 

- Antony Ryakiotakis (Viewport) and Sergey (Dependency graph) will start involving others now too, which requires more planning now as well.

 

Laters,

 

-Ton-

Zapowiada się bardzo chude wydanie. Albo rozciągną wszystko o dodatkowy miesiąc. Byleby się nie śpieszyli.

 

Za to 2.74.... Razem z rzeczami z gooseberry, Opensubdiv, sporą częścią viewportfx. Meeeeen... Niech to robią nawet do maja ale to będzie pierdolnięcie.

 

Tylko bake nadal ****. :( Brakuje jeszcze masy rzeczy ze starego internala nawet a oni już przestali to rozwijać...

-------------mod edit---------------

Uważać mi tu na bluzgi do *****.

Edytowane przez n-pigeon
Napisano

Viewport będzie miał jeszcze jedną funkcjonalność więcej, world background dla cyclesa - bardzo przydatna rzecz, której brakowało.

 

world_cycles.png

 

Ciekawa zapowiedź Roosendaala na twitterze:

A report on the progress of Viewport recode will go to the blog soon. The idea to construct a "GLSL Render Engine" is really a logical step.

Jeśli chcesz dodać odpowiedź, zaloguj się lub zarejestruj nowe konto

Jedynie zarejestrowani użytkownicy mogą komentować zawartość tej strony.

Zarejestruj nowe konto

Załóż nowe konto. To bardzo proste!

Zarejestruj się

Zaloguj się

Posiadasz już konto? Zaloguj się poniżej.

Zaloguj się
×
×
  • Dodaj nową pozycję...

Powiadomienie o plikach cookie

Wykorzystujemy cookies. Przeczytaj więcej Polityka prywatności