Blender - NEWS oraz dyskusje

[mookie]

Żeby nie być źle zrozumianym - to jest animacja, która nie wybija się na tle konkurencji, ale jej nie ustępuje. Po prostu oglądając ją nie myśli się, co to za studio ją zrobiło, bo mogło je zrobić każde studio. Jakościowo ten blenderowy short ma poziom innych shortów, które obejrzysz, uśmiechniesz się i zapomnisz. Ale obejrzysz do końca i nie będziesz marudził na jakość animacji i renderu.

 

 

PS Dodam tylko, że świetnie poprowadzona jest kamera, reżysersko jest to bardzo dobra robota.

Edytowane 17 Maj 2017 przez mookie

[olaf]

absolutnie sie zgadzam, dobrze to ujales. Dobrzy scenarzysci, projekcje probne i marketing to pewnie wszystko czego by taka animacja potrzebowala z zewnatrz, by byc w pierwszej lidze.

[mielnicki]

am am am.. AMD właśnie wypuściło GPU które ma 16 giga pamięci. i 15-18 tflopów. Oraz może używać M2 jako dodatkowej pamięci. CZyli ogólnie możesz mieć 1 tera vram. ;) a cycles działa w pełni na openCL co śmieszniej openCL renderuje dużo lepiej niż cuda.

Potwierdzone info z tą pamięcią m2 ? potrzebna będzie implementacja w blenderze przez developerów czy hardwarowo ma się to dziać? gdzie to można kupić?

[Maciek Jutrzenka]

http://wccftech.com/amd-radeon-vega-frontier-edition-radeon-pro-vega-ssg-detailed/

[Skoti]

Oraz może używać M2 jako dodatkowej pamięci. CZyli ogólnie możesz mieć 1 tera vram. ;)

Nie VRAM tylko 16GB masz VRAM i możesz dodać SSD jako pamięć SWAP. Jest to świetna wiadomość do wielu dziedzin obliczeń, ale nie renderingu (jeśli komuś włączył się swap dysku na SSD podczas renderingu na CPU to wie, że jeśli nie chce czekać 100 lat na wyrenderowanie to lepiej wyłączyć i odchudzić scenę, aby się w ramie mieściła - a tak jest przy małym wyścigu o zasób 4x rdzeni, a nie 4k rdzeni (miałbyś szczęście jeśli gpu renderowałoby tylko 8tysięcy razy wolniej - znaczy się, jeden rdzeń by pobierał powoli dane i zwolnił tylko 2x działanie przez to względem VRAMu, a 4095 rdzeni by czekało, aż zwolni dostęp do dysku ;p)). Czytaj świetna sprawa dla aplikacji liczących ekstremalnie dużo, wymagających dostępu do big data, ale czytających je rzadko.

 

a cycles działa w pełni na openCL co śmieszniej openCL renderuje dużo lepiej niż cuda.

Nie działa w pełni na OpenCL - nie ma bardzo, bardzo wielu rzeczy... przez co renderuje dużo szybciej (ale dużo gorszej jakości) niż w CUDA. To jeszcze pokłosie kart AMD których sterowniki próbowały nadrobić braki w konstrukcji i optymalizowały kod ekstremalnie - gdy kernel stawał się odrobinę bardziej skomplikowany to wywalał się sterownik karty graficznej i przez AMD zaprzestano bardzo wcześnie rozwój wersji OpenCL (na poziomie który nie wywalał sterowników AMD - nie było problemu na Nvidii i Intelu, aby prace kontynuować, ale intel się nie liczy, a po co robić OpenCL który działa tylko na Nvidii gdy jest CUDA?). Dalej efekty tego okresu w kartach AMD mamy w oprogramowaniu i mimo że w Cycles jest już lepiej dalej brakuje wielu rzeczy z wersji C++/CUDA(prawdopodobnie nie tylko w cycles , ale obecnie nie jestem na bieżąco czy dalej VRay RT wykrywa kartę czy Nvidia czy AMD i ustawia gorszej jakości kernele na AMD, aby nie wywalały sterownika, czy już z tego zrezygnowali z nastaniem nowej architektury).

[Maciek Jutrzenka]

Co do OpenCL skoti masz na pewno aktualne dane? w ostatnich dniach troszku się pozmieniało :)

[Skoti]

Co do OpenCL skoti masz na pewno aktualne dane? w ostatnich dniach troszku się pozmieniało :)

Jeśli chodzi Ci o to co zrobione przy Gooseberry to tak aktualne dane... jeśli coś się dodatkowo zmieniło to nie.

[Maciek Jutrzenka]

od tego momentu? https://www.blendernation.com/2017/04/12/blender-cycles-opencl-now-par-cuda/

[Skoti]

od tego momentu? https://www.blendernation.com/2017/04/12/blender-cycles-opencl-now-par-cuda/

Tak i że tak przekornie powiem to zdanie "The OpenCL Split Kernel now supports nearly all features" nie do końca oddaje jak daleko to nearly jest ;). Teraz nie chodzi już o to, że na sterownikach amd nie da się zrobić wszystkiego, ale o to, że to pokłosie tragicznych starych sterowników dalej się ciągnie w tym, że nie dali rady jeszcze wszystkich zaległości nadrobić... i w tym, że obecnie co lepsze możliwości blokuje Nvidia oferując jedynie OpenCL 1.2, a wszystkie smaczki dostępne od OpenCL 2.0 czy 2.1 zachowuje dla CUDA (i są wykorzystywane w Cycles w CUDA, ale Cycles używa OpenCL jedynie w wersji 1.1).

[Monio]

Czarujesz jakieś bzdury. Jedyna rzecz której brak w wersji OpenCL w stosunku do CUDA to CMJ który nie sprawi większego problemu z przeportowaniem oraz Baking (który trzeba by było przepisać we wszystkich wersjach żeby był miał sens). Ty chyba porównujesz do wersji CPU.

[Nezumi]

Okreslenia "co lepsze mozliwosci" i "wszystkie smaczki" nie sa jakos bardziej precyzyjne od "nearly" ;) Jakies przyklady?

[Maciek Jutrzenka]

Tak i że tak przekornie powiem to zdanie "The OpenCL Split Kernel now supports nearly all features" nie do końca oddaje jak daleko to nearly jest ;). Teraz nie chodzi już o to, że na sterownikach amd nie da się zrobić wszystkiego, ale o to, że to pokłosie tragicznych starych sterowników dalej się ciągnie w tym, że nie dali rady jeszcze wszystkich zaległości nadrobić... i w tym, że obecnie co lepsze możliwości blokuje Nvidia oferując jedynie OpenCL 1.2, a wszystkie smaczki dostępne od OpenCL 2.0 czy 2.1 zachowuje dla CUDA (i są wykorzystywane w Cycles w CUDA, ale Cycles używa OpenCL jedynie w wersji 1.1).

 

Skoti kurcze weź ty mi powiedz jak to w końcu jest.. bo chyba jesteś w stanie na to odpowiedzieć...

 

będzie trochę bluzgów ale tak po prostu będzie prościej.

Więc.. niby cuda jest taka super ekstra zajebista... a gdy scena się komplikuje i tak dalej to zwalnia rendering strasznie.. oczywiście to normalne większa scena renderuje się wolniej ale mam wrażenie że.. to dzieje się progresywnie i to tak mocno że w pewnym momencie rendering na CPU jest szybszy.. na kartach AMD i openCL tego efektu niema co obrazuje ta grafika... którą dałem w tym linku wcześniej.. I teraz moje pytanie brzmi następująco... Skoro Cuda jest taka ekstra a AMD i opencl jest napisany na kolanie to jakim cudem, Cuda wypada tak źle.. to jest wina developerów blendera czy samej biblioteki/api Cuda?

[Skoti]

Jedyna rzecz której brak w wersji OpenCL w stosunku do CUDA to CMJ który nie sprawi większego problemu z przeportowaniem

Nie sprawi - TO PRAWDA, jednak wydajność mocno spadnie i o tym mówię. Obecnie sampling w wersji OpenCL jest bardzo prosty (szybciej zrobi N-sampli, ale wygląda nieporównywalnie gorzej przy tej samej ilości sampli). Correlated Multi-Jittered Sampling od Pixara czyli quasi-Monte Carlo robi olbrzymią różnicę w jakości i wydajności, dlatego teraz porównywanie wersji OpenCL bez niego z CUDA z CMJ jest po prostu niepoważne, bo przy tej samej ilości sampli na jednym masz tylko szum, a na drugim jakość produkcyjną.

 

Skoro Cuda jest taka ekstra a AMD i opencl jest napisany na kolanie to jakim cudem, Cuda wypada tak źle.. to jest wina developerów blendera czy samej biblioteki/api Cuda?

To zupełnie nie tak. Porównujesz po prostu dwa zupełne renderery. Wygląda to trochę tak jakbyś mówił, Cycles ssie, bo Blender Internal szybciej wyrenderuje - prawda, ale efekt jest zupełnie inny.

 

Co do AMD i OpenCL to AMD dobi bardzo dobre karty obecnie a i OpenCL jest obecnie wyśmienity. Problem nie w tym, że nowe karty AMD są złe czy 2.2 nie daje Ci czegoś ważnego dostępnego w CUDA, bo daje wszystko. Kompilacje offline kernelów (z możliwością znacznie dalej idących optymalizacji niż online) dzieki SPIR-V masz od OpenCL 2.1, Dynamic parallelism z CUDA masz w OpenCL 2.0, Concurrent Kernel Execution (Hyper-Q) masz w teorii od OpenCL 1.2. Tylko tak jak kilka lat temu OpenCL dobijały karty i sterowniki AMD tak teraz dobija go Nvidia i przykładowo wszystko powyżej OpenCL 1.2 nie jest wspierane przez ich sterowniki (mimo, że sterowniki OpenCL 2.x mają od lat i mam do nich dostęp, ale nie wydają publicznie), a Concurrent Kernel Execution przez nich nie jest wspierane (a przynajmniej poprawnie) przez co w programach konsumenckich zostaje używać api w wersji zupełnie nieprzystosowanej do obecnego sprzętu (specyfikacja 6-7 lat) - to nie znaczy, że OpenCL jest pisany na kolanie, o nie... to znaczy jedynie, że jego ekosystem jest bardzo podzielony i tym co dzielą wcale nie zależy na popularyzacji OpenCL'a, więc dopóki nikt Nvidii nie zmusi (a był czas gdy tak było, bo był hype na OpenCL, ale AMD go wtedy ubijało), ich polityka się nie zmieni, a co za tym idzie OpenCL będzie w plecy

[Maciek Jutrzenka]

owkeeeey czyli jak rozumiem Open CL jest bardziej zawansowane od CUDA. A Nvidia specialnie nie wspiera nowego Open CL aby ludzie używali ich CUDY? correct?

 

sprawa numer dwa.. Cycles na karcie AMD w trybie open CL to inny silnik niż na karcie Nvidi w trybie CUDA... Rozumiem. Tylko dalej nie rozumiem jednego... czego silnik cycles na nvidi... tak strasznie zwalnia gdy scena jest skomplikowana że nawet CPU jest szybsze. A na karcie AMD nie zwalnia.... nie testowałem jak bardzo różnią się rendery za pomocą diff. ale.. no jak patrzysz okiem to nie widać różnicy.

 

czyli to nie jest wina cuda? tylko developerów którzy słabo zakodowali silnik na cudzie?

[Skoti]

owkeeeey czyli jak rozumiem Open CL jest bardziej zawansowane od CUDA. A Nvidia specialnie nie wspiera nowego Open CL aby ludzie używali ich CUDY? correct?

OpenCL 2.2 jest porównywalny z CUDA... no ok SPIR-V i możliwość kompilacji C++ do niego jest naprawdę fajna, ale to nie sprawa wydajności, a odpowiedniego pośredniego języka i dostarczonych kompilatorów. Nie jest bardziej zaawansowane, ale nie ma żadnych słabości. I tak... Nvidia specjalnie nie wypuszcza sterowników do OpenCL (którego sami tworzą, a szefem standaryzacji OpenCL dalej jest wiceprezes Nvidii).

 

Tylko dalej nie rozumiem jednego... czego silnik cycles na nvidi... tak strasznie zwalnia gdy scena jest skomplikowana że nawet CPU jest szybsze. A na karcie AMD nie zwalnia.... nie testowałem jak bardzo różnią się rendery za pomocą diff. ale.. no jak patrzysz okiem to nie widać różnicy.

 

czyli to nie jest wina cuda? tylko developerów którzy słabo zakodowali silnik na cudzie?

Dlatego, że nie wszystkie algorytmy są dla architektury SIMT/SIMD zabójcze, a nie mają z nim problemów arch MIMD (jak CPU). Nie bez powodu fizyka akcelerowana przez GPU w grach to dalej nie jest standard... o ile GPU sobie świetnie radzą z fizyką ciuchów, fluidów itp... to zupełnie padają przy zwykłej fizyce brył sztywnych. Tak samo tu jest. Liczenie permutacji w Correlated Multi-Jittered Sampling prowadzi do branchowania kodu przez co przykładowo jeśli masz 64 rdzeni w SIMD na karcie graficznej to w zależności od danych wejściowych działać może od 1 do 64 rdzeni (czytaj od 0 do 63 na 64 rdzenie odpoczywa i nic nie robi, bo mogą wszystkie wykonywać na raz taką samą instrukcje na innych danych, a że już tamte wyszły z brancha to muszą czekać aż inne też to zrobią, aby prace kontynuować). CPU jest tak zaprojektowane (MIMD) z prostej przyczyny - jest uniwersalne i nie zwalnia w zależności od danych wejściowych. Wersja OpenCL ma bardzo prosty sampling i nie branchuje.

 

OFC możesz sobie sprawdzić czy to wina CUDA odpalając blendera i w wersji OpenCL na karcie Nvidii (sterownik Nvidii OpenCL implementuje tak, że kompiluje kernele OpenCL online do CUDA i ogólnie tak czy tak wykonywany jest kod CUDA - tylko gorszy jakościowo, bo na kompilacje kernela nie miał kilku-kilkunastu minut (jak to jest w kompilacji offline, gdzie optymalizacja jest dogłębna), a kilka sekund ;)).

[Maciek Jutrzenka]

Am am. Czyli To że openCL jest szybkie to zasługa tego że używa gorszego samplera który jest zdecydowanie szybszy?

[Skoti]

Am am. Czyli To że openCL jest szybkie to zasługa tego że używa gorszego samplera który jest zdecydowanie szybszy?

Nie tylko... i OpenCL nie jest szybsze, tylko cycles w wersji OpenCL szybciej sampluje... co oznacza, że N sampli per pixel zrobi Ci szybciej, ale obrazek w porównywalnej jakości już wolniej, bo potrzebuje conajmniej kilkukrotnie więcej sampli na pixel aby rezultat był podobny - czyli jeśli zrobisz benchmark renderowanie N sampli to faktycznie wyjdzie szybciej, a jeśli po jakości/zaszumieniu sromotnie przegra - zależy czy mówimy o rezultacie czy cyferkach których się nie da porównać rzetelnie ;). Na CPU też renderery z samplingiem Monte Carlo czy Metropolis light transport samplują wolniej i tyle samo sampli uzyskasz dużo szybciej na weekendowych projektach studentów... tylko szum przy tej samej ilości sampli nieporównywalny - jeśli liczysz czas jako sample per pixel w danym czasie to wszystkie najlepsze renderery unbiased zasysają względem prostych hobbystycznych projeków... jeśli liczysz czas do wyrenderowania produkcyjnej jakości obrazka to już jest odwrotnie.

Edytowane 27 Maj 2017 przez Skoti

[Idaho]

Jakoś mi umknęło

Silhouette brush w blenderze, ładnie to wygląda oby tylko skończyli

https://wiki.blender.org/index.php/User:Witt/GSoC2017/Proposal

orientuje się ktoś może czy Laplacian Mesh Optimization (jest też w GSOC-u 2017) wpłynie na wierniejsze odwzorowanie alph i detalu w blenderze? Czy trzeba jednak czekać na nowy silnik ? Na dzień dzisiejszy większość ludzi pomimo że robią w blenderze detal przerzuca do zetki by uzyskać np takie pory skóry, zmarszczki itp.

Edytowane 29 Maj 2017 przez Idaho

[mandragora]

podoba mi się to i wygląda to na coś co konkretnie pomoże w pracy, brakuje tylko tworzenie dziur

[Nezumi]

Rewelka. A do dziur masz carver addon, ale jakby tu tez zintegrowali to by byla moc.

 

w zasadzie jak poczytalem to nigdzie nie jest zdefiniowane ze nie bedzie wycinania dziur - wrecz przeciwnie, wydaje mi sie ze w subtract to bedzie:

"If in subtractive mode, the stroke defines parts of the mesh which get cut out. It works like a subtractive boolean operation of the additive shape with the existing geometry"

 

Czy to nie sugeruje tez dziur?

Edytowane 29 Maj 2017 przez Nezumi

[Vaticinator]

Na code.blender.org pojawił się dzisiaj wpis na temat przyszłego viewportu: https://code.blender.org/2017/05/viewport-past-present-and-future/

[michalo]

Fajna sprawa. Bardzo mi tego brakuje a życie ze świadmością, że za paręmiechów będzie mi nie pomaga.

Tak jak z 3d manipulatorem w zetce.. Czekamy i czekamy. Dobrze, że Siggraph sie zbliża.

[Monio]

Czyli To że openCL jest szybkie to zasługa tego że używa gorszego samplera który jest zdecydowanie szybszy?

Oczywiście że nie! Benchmarki pokazują wersje na OpenCLa z samplowaniem Sobol kontra CUDA i Sobol. Jaki byłby sens odpalać w ogole benchmark jeśli ustawienia renderu byłyby inne? CMJ działa już na OpenCL tylko Mai nie wyrobiła się żeby to weszło do 2.79. Sampluje wolniej, kilka procent, tak jak w przypadku CUDA. Po prostu wymaga testów.

 

Niedługo i tak nie bedzie miało to znaczenia bo w momencie wyjscia bety 2.8 Lukas skończy sampler oparty o błekitny szum. Ten deklasuje wszystkie inne znane metody samplowania (przy niskiej ilości sampli) i dodatkowo produkuje output który będzie doskonale współgrał z denoiserem. Śmiało można zakładać zredukowanie czasu renderu prostych scen o połowę bez denoisera, n-razy z denoiserem. To rozwiazanie to jeden z głównych powodów szybkości Arnolda. :) Przy mało doswietlonych scenach CMJ może działać lepiej. Też będzie dostępny na OpenCL niedługo.

 

Czyli sprawa jest prosta, jak masz w tym momencie multum projektów do wyrenderowania to inwestujesz w Nvidie. Jak możesz poczekać do końca roku to wtedy większy sens będzie miało AMD.

Edytowane 31 Maj 2017 przez Monio

[Nezumi]

Tak jak z 3d manipulatorem w zetce.. Czekamy i czekamy. Dobrze, że Siggraph sie zbliża.

Troche offtop w temacie Blendera ale zapowiedzieli zapowiedz ;) :

 

Ja tam na gizmo nie czekam w ogole, ale rozumiem, ze niektorym to ulatwi zycie. Mnie zdecydownie bardziej jara mozliwosc wektorowego displacementu. Swoja droga szkoda, ze w Blenderze nie ma tej mozliwosci - moze kiedys.

Edytowane 31 Maj 2017 przez Nezumi

[Vaticinator]

I kolejny offtop... Blender bryluje na zapowiedzi nowych procków AMD Ryzen Threadripper

 

 

...Tak od 47 minuty z hakiem.

Render na ich scenie to 13 s. Dla porównania znalazłem, że Ryzen 7 1800X liczy to jakoś w 22s.

[Vaticinator]

Nowy filmik promujący EEVEE:

 

[Monio]

Spoko prezentacja ale ja pier****. Jak można nie ogarniać że to działa tylko na GPU. Uzyskanie takiej grafy w realtime na CPU jest zwyczajnie niemożliwe.

[Zuorion]

Plis Monio, ten ktoś nie ogarnia różnicy pomiędzy Tangent space, a Object space normal mapy. Widać, że od technicznej strony u niego nie najlepiej.

[Monio]

W ogóle przez komentarze odnośnie 2.8 trochę trące wiarę w community. Goście piszą o Eevee że nie potrzebują silnika gier w blenderze (?!). Drudzy się pytają czy to zamieni Cyclesa. Jeszcze inni narzekają że warstwy im nie działają jakby to była finalna wersja.

Ja rozumiem że nikt nie musi być na bieżąco z każdą nowinką, ale skoro już ściągają eksperymentalnego, niedokończonego builda to mogliby się chociaż trochę zorientować z czym mają do czynienia. Mam wrażenie że ludzie oczekują że kilku koderów wykona rok pracy w miesiąc, nie chce im się przeczytać ogólnodostępnych informacji ale za to są pierwsi do narzekania że Ton chce usunąć Cyclesa i zrobić z blendera silnik gier.

 

Chyba za dużo czytam BA. Duże ilości raka.

[Maciek Jutrzenka]

Monio xD? dopiero teraz to zauważyłeś, społeczność blendera ma tą wadę że chyba ma największy procent ludzi którzy nie mają bladego pojęcia o grafice 3D i są zarazem ekstremalnie głupi, nie wiem why możę za sprawą ino tego że blender jest free, no i niestety odkryli możliwość pisania na forach.. Dlatego ja od większego już czasu totalnie wycofałem się z brania udziału w tym cyrku.

[Idaho]

Czytałem komentarze pd tym filmem na YT i jak dla mnie to są zwykłe "gimby" widzą że ktoś się czymś ekscytuje ale nie rozumieją czym a bardzo chcą wziąć udział w tym całym Hype-ie, nie wykluczam też ludzi podstawionych od konkurencji ;). Obserwuję MODO, Maxa, Mayke i sorry ale najszybciej z nowinkami i ulepszeniami to jedzie blender. Te wymienione wyżej softy na starcie dostały porządne narzędzia a teraz raczej nic się tam nie dzieje natomiast blender cały czas się rozwija imho. Także trzeba wziąć pod uwagę że programy komercyjne "trochę" kosztują i tam są już ludzie konkretnie zorientowani (bo te durne pytania zadawali w szkole jak się uczyli) i kupują narzędzie do konkretnego zadania. Przy darmowym blendku natomiast jest cała masa hobbystów, nowicjuszy itp ludzi, stąd takie pytania a nie inne.

 

@Monio

Nie każdy jest zorientowany w wymaganiach. Co do GPU o ile dobrze pamiętam to ma być wspierane od openGL 3.3 więc to pójdzie prawie na wszystkim:

tak sobie myślę że jakby przeszli na vulkana to jeszcze by kopa dostało.

 

P.S. nadal czekam na usprawnienie sculptu. Mieć ten detal co w zetce ...

[Monio]

Dlatego ja od większego już czasu totalnie wycofałem się z brania udziału w tym cyrku.

Ja w też ale gdzieś trzeba szukać newsów, śledzić development blendka i addonów. Kiedyś miałem czas czytać wszystkie commity, teraz wole sprawdzić BA. Niestety przy okazji trzeba przebrnąć przez sterty bullshitu.

 

Nie każdy jest zorientowany w wymaganiach.

Co nie zmienia faktu że to akceleracja sprzętowa GPU i widać to jak na dłoni. Rozumiem że osoba zaczynająca zabawę z 3D może tego nie wiedzieć ale gość który kręci tutoriale do softu? WTF.

 

P.S. nadal czekam na usprawnienie sculptu. Mieć ten detal co w zetce ...

Też bym chciał ale to wymaga kilku składowych. Sam wydajny viewport tego nie załatwi, obracanie kamery to jeszcze nie rzeźbienie. Potrzebny byłby "przynajmniej" refactoring multiresa i mechaniki deformacji pędzlami żeby to płynnie działało.

Teraz 2 gości działa w temacie sculptu w ramach GSoC. Jeśli im się teraz uda to może kiedyś wezmą się za usprawnienie tych bebechów.

[HubertP]

Ciekaw jestem czy eevee, jakby sie okazało, że działa jakoś niebywale cudowne, mogło by być podłączone pod inne softy 3d. :P

[HubertP]

https://www.blendernation.com/2016/05/23/add-capsule-one-click-batch-fbx-exports/

 

Taka ciekawostka przydatna. Jak by ktoś potrzebował walczyć z fbx'ami.

[Idaho]

Fajną rzecz znalazłem przydatną do renderingu jakby ktoś potrzebował

[Monio]

Dobra rzecz. Napisałem sobie kiedyś coś podobnego (OBJ i FBX) i od tamtego czasu wszystko tym eksportuje.

[Idaho]

Nowy feature (przynajmniej dla mnie ;) ) Extra rzecz.

Tak to się robi w MAXie

a tak to się teraz robi w blenderze

https://www.youtube.com/watch?v=JSxaEjtXI7Y

[Ajgor]

Nowy raczej nie jest, bo filmik ma już prawie rok. Ale fakt, że ciekawy :)

[Idaho]

Nowy raczej nie jest, bo filmik ma już prawie rok. Ale fakt, że ciekawy :)

Nie chodziło mi o filmik a o feature surface deformer modifier. Ten filmik od Arrimusa3d oglądałem właśnie ok roku temu i szukałem odpowiednika w blenderze. O ile dobrze pamiętam to tego modifiera w 2.77 nie ma i nie było (mam go cały czas zainstalowanego). Ale w którym momencie się pojawił też nie potrafię określić. Zresztą zastanawiam się ile jeszcze rzeczy nie znam bo nie widziałem ich praktycznego zastosowania na YT. Oglądam Arrimusa3d by podpatrzyć techniki jakie stosuje i czy da się to powtórzyć w blenderze. Ma świetne filmiki o retopologii. Polecam to i jego give awaye co ileś tam subów.

[Monio]

Jarałem się bym modyfikatorem właśnie dlatego że można robić takie rzeczy ale zapomniałem że można już z niego korzystać. :P Dzięki za info, idealnie się sprawdzi w moim obecnym projekcie.

[Maciek Jutrzenka]

mega elegancko że to weszło już officialnie. aczkolwiek ja osobiście dalej czekam na VDB.

[Idaho]

Nawet nie pomyślałem że można to tak wykorzystać. Obłędnie wyszło.

[Ajgor]

Heh... W trzeciej wojnie światowej będą walczyć ludzie w plastikowych zbrojach rodem z gier RPG :) Które w dodatku sami sobie zrobią w domu.

[Zuorion]

Chyba nikt tego tu nie postował:

Improvements to the Cloth Simulator

 

 

https://code.blender.org/2017/06/improvements-to-the-cloth-simulator/

Edytowane 17 Czerwiec 2017 przez Zuorion

[Monio]

Ludki z facebooka się jarają to tu też wrzucę.

Napisałem sobie makrosy do retopologii. Wypalanie Shrinkwrapa w dowolnym trybie (leci pod hotkey), snapowanie vertów do płaszczyzny symetrii i Wrap Relax czyli shrinkwrap i smooth w pętli. Podzielę się jak skończę obecny projekt i będę miał czas na posprzątanie kodu. Czyli po 7 lipca.

 

 

 

1. Baza z topologią. 2. Shrinkwrap na sculpcie, minuta dociągania vertów, kilka loopów. 3. Wrap Relax i 2 minuty dociągania vertów

[Nezumi]

Z jakiejs przyczyny nie dziala mi przycisk "dzieki", wiec manualnie - DZIEKI :) Pomysl w swojej prostocie wymiata i jak widac dziala. Super sprawa.

[natas]

Robi wrażenie

[Idaho]

Go, go Monio !

[michalo]

Z kąd taką fajną bazę wziąłeś ? ;)

 

Wygląda bardzo smerfnie.

[alex3d]

Monio fajne, jak się podzielisz to widzę, że oprócz sculptu może mi to przyspieszyć robienie drzew, gdzie zwykły shrinkwrap wymaga trochę korekt ;)