Blender - NEWS oraz dyskusje

[n-pigeon]

Na razie to niech oni skończą port, nie ma co im zawracać głowy. Potem pomyśli się o proposalach.

 

Zadaniem użytkowników, na tą chwile, jest jedynie testować i zgłaszać bugi. :)

 

 

- Brecht van Lommel: Cycles layers/passes.

 

\o/

[mandragora]

http://www.blendernation.com/2011/12/20/shadertools/ małe info o shaderkach

[n-pigeon]

W BMesh branch, Campbell dodał opcję by zapisać siatkę w starym formacie, dzięki czemu można otworzyć go w starszych wersjach Blendera i BMeshu.

To była ważna pozycja w TODO, jest z czego się cieszyć, bmesh jest o skok bliżej ;P

 

poprawka jest od rev. 42904

[rice]

http://blenderartists.org/forum/showthread.php?240751-Request-for-modifier-icon&p=2014906&viewfull=1#post2014906

 

pewnie pare osob sie ucieszy ;]

[mandragora]

wreszcie mamy ciecie ścianek poza głównym planem (bmesh)

jedna z wielu koncepcji, nawet ciekawa, choć ta od hype wcale zła nie jest

 

 

i wersja od hype

 

 

Informacja od Brecht-a

 

Hi all,

 

There's been some discussion about what the focus of Cycles should be,

let me try to clarify. Cycles is supposed to be a render engine for

individuals / small studios, aimed primarily at rendering animations.

This goal is what I evaluate priorities of features by.

 

For the next few months, my main priorities are:

* Render layers, passes, full sample, compositing layer, ..

* Performance improvements / noise reduction for typical two bounce

animation scenes

* Some smaller things for completeness (blender integration stuff,

ramps, multi GPU, ..)

 

After that, we should get to some more exciting features, which ones

are a bit unclear, but this will be influenced by Mango. Volume

rendering and motion blur seem like good candidates, but we'll see.

Performance work will be ongoing during Mango of course, and I see

that quite broadly, it's about low level performance tuning, better

algorithms and better user control.

 

Beyond that, this is roughly what I'd like to see added over the next 2 years:

http://wiki.blender.org/index.php/Dev:2.6/Source/Render/Cycles/ToDo

 

There are some things obviously missing that people would like to see

added. Bidirectional path tracing, photon mapping, MLT and similar

algorithm are not a priority for me, since I do not believe they are

the main possible performance improvements for animation frames.

Shading language support, resumable rendering , is another one that I

do not think should get very high priority.

 

Lastly, GPU rendering can be somewhat of a bottleneck to development.

It seems that with older cards and current OpenCL support in the

drivers, we'd have to considerably complicate the code to get Cycles

working fully, to the point where it would be too hard to add new

features. This also means we're dependent on improving driver

implementations or language features. I'll keep track of this, but

also can't justify spending too much time on this, to try to work

around issues with every possible card / driver combination.

 

Thanks,

Brecht.

Edytowane 29 Grudzień 2011 przez mandragora

[n-pigeon]

@mandragora

 

Świetne newsy dzięki za ifno :)

 

wersja hype jest fajna, ale powinien ją zrobić w mniejszej wersji P:

 

W Trunku mamy już render layers, ponoć do 2.62 mają dojść również podstawowe passy.

[mandragora]

Remesh trafił do Trunk-a i chyba ostateczna wersja ikonki oraz Wiki z wyjaśnieniem.

 

[n-pigeon]

NO! Właśnie dostałem najlepszy prezent świąteczny :3 co z tego że spóźniony ^^

Jest też wpis na blogu developerskim code.blender.org/index.php/2011/12/remesh-modifier/

 

Doszedł również Object Tracking:

 

Commit by nazgul :: r43007

 

Object tracking integration This commits merges object tracking implementation from tomato branch. Summarized changes from branch:

 

- Added list of objects to be tracked. Default there's only one object called "Camera" which is used for solving camera motion. Other objects can be added and each of them will have it;s own list of tracks. Only one object can be used for camera solving at this moment.

 

- Added new constraint called "Object Tracking" which makes oriented object be moving in the save way as solved object motion. - Scene orientation tools can be used for orienting object to bundles. - Object has got scale to define "depth" in camera space.

 

- All tools which works with list of tracks or reconstruction data now gets that lists from active editing object.

 

- All objects and their tracking data are available via python api. - Improvements in witness cameras workflow,

Edytowane 31 Grudzień 2011 przez n-pigeon

[mandragora]

Dla posiadaczy nowszych kart graficznych możliwość przetestowania OpenCL dla kompozytora

Download Win32 build

Download Win64 build

[Gość Chrupek3D]

teraz tylko niech popracują nad integracją Illuminate Labs (Beast) i będzie gitara ;)

[BartekSkorupa]

Najlepsze jak do tej pory tutoriale na temat trakowania kamery, które znalazłem to te, których autorem jest Sebastian Koenig - publikowane na blendercookie.com

On je nagrywał w początkowej fazie rozwoju tego narzędzia, więc czasami może się zdarzyć, że niektóre rzeczy działają troszkę inaczej.

Zdecydowałem się zebrać tę wiedzę do kupy i nagrać krótką seryjkę tutoriali na ten temat.

Pierwsza część, to wprowadzenie, druga - parę technicznych szczegółów. Zamierzam również nagrać trzecią o trakowaniu obiektów.

Dodatkowo - osobne video na temat problemów, jakie mogą się przytrafić w związku ze zniekształceniami obiektywu:

 

http://cg.bartekskorupa.com/camera-tracking-tutorial/

http://cg.bartekskorupa.com/camera-tracking-tutorial-2/

http://cg.bartekskorupa.com/camera-tracking-tutorial-3-objects/

http://cg.bartekskorupa.com/camera-tracking-lens-distortion-issue/

 

Być może komuś się przyda.

Edytowane 5 Styczeń 2012 przez BartekSkorupa
dodany link do trzeciej części

[n-pigeon]

Dzięki Bartek dobra rzecz :)

 

Mamy specjalny wątek w tym dziale, gdzie można zapodać linki do tutków dla Blendera, tam nie zaginą. ;)

 

http://www.max3d.pl/forum/showthread.php?t=79262

[mandragora]

w bmesh mamy już cięcie po linii pion/poziom i pod kątem 45 stopnii

[mookie]

Uff, ta funkcjonalność bmeshowego noża rodzi się w bólach.

[n-pigeon]

Raczej w czasie :) z bevelem jest podobnie, nie oczekiwałbym cudów w pierwszym wydaniu ;]

[mookie]

n-pigeon - ja właśnie w tym sensie. Jednego nie rozumiem - wszyscy zapowiadali, jakie to teraz będzie łatwe i przyjemne pisanie narzędzi modelarskich do Blendera. Niestety praca nad samym knifem i bevelem idzie jak krew z nosa; jeśli rezultatem bmesha nie będzie zachowywanie uv-ałki przy różnych operacjach na bryle to naprawdę nie wiem, czy cały projekt był wart tyle czasu deweloperów (jeden z nich powiedział nawet, że jeśli nie uda im się sfinalizować przedsięwzięcia w najbliższym czasie, to będzie to dowodem marności całej inicjatywy i zmarnowaniem czasu tak ich, jak i społeczności).

[n-pigeon]

Oni jeszcze nie pracują nad narzędziami, na razie wyłapują bugi, jedyne nowe narzędzia jakie dojdą to knife i bevel, wiec je chociaż trochę poprawiają, by nie było śmiechu na sali, na pewno nie będzie to ich finalna odsłona, zaliczą jeszcze kilka.

 

Po za tym to że pisanie narzędzi będzie teraz łatwiejsze (a czasem po prostu możliwe) nie znaczy, że nie kosztuje to czasu i pracy : | bmesh, to nie magiczna różdżka... knife już teraz jest lepszy niż stary.

 

Co do UVki, jak ma zachować UVki? Może co najwyżej edytować je razem z meshem, co robi, choć jest na razie zbugowane. Rozwala się tylko przy edycji seamów jak użyjesz narzędzia tworzące nowe facy z niczego np. bevela, ale nie wiem czy to bug czy nie da się tego uniknąć, knife działa, tak samo jak inne narzędzia modyfikujące edge i verty.

 

 

Gdzie i kto tak pisał, proszę o link. BMesh został przyjęty przez zespół jako target 2.63 prawdopodobnie będzie jedynym targetem tego wydania. Cała uwaga skupi się na bmeshu.

 

Chyba że będzie poślizg z powodu który jeszcze nie jest znany, wtedy trafi do 2.64.

Edytowane 5 Styczeń 2012 przez n-pigeon

[mookie]

n-pigeon - takie słowa (a przynajmniej taki wydźwięk słów) padły z ust prowadzącego blenderowe podcasty, ostatni albo przedostatni odcinek. Co do UV-ałki - extruduj ściankę zunwrapowanego sześcianu do środka ekstrudowanej ścianki (stwórz ściankę w ściance), następnie przesuń wierzchołek tej ścianki; ngony powinny zapewnić, że UVałka będzie pięknie wyświetlana na tej ściance, a nie rozciągnięta zgodnie z przesunięciem tego wierzchołka.

 

Co do łatwości pisania nowych narzędzi - takie czytałem zapewnienia deweloperów, póki co nie widzę potwierdzenia ich w faktach, ale może to złe miłego początki.

[n-pigeon]

Pamiętam tą rozmowę, było to trochę mniej dramatyczne :) nie chodziło o to, że może im się nie udać, tylko o to, że gdyby przełożyli BMesha na dalsze wydania, to był by raban :)

 

Właśnie o tym mówiłem, narzędzia tworzące nowe ścianki mają zgrzyty, planuje to zgłosić do bugtrackera zobaczę co powiedzą. Mogłeś to zgłosić dawno temu, ja jeszcze nie miałem tego problemu.

 

BMesh nie został jeszcze wydany, nie pora na nowe narzędzia. Dowód na to, że jest łatwiej napisać narzędzie już masz, mamy bevel i nowy lepszy knife.

[mookie]

n-pigeon - nie zgłaszałem, bo nawet nie wiedziałem, że to nie działa. Wyraziłem tylko swoje nadzieje co do bmesha, na zasadzie - oby taki feature był z nim związany. Ze wstydem muszę przyznać, że straciłem zainteresowanie tym projektem po wyjeździe głównego dewelopera na konferencję (żadna relacja na ten temat nigdy chyba nie wyszła na światło dzienne, a jego blog przestał być prowadzony) i apelami jeszcze sprzed roku o testowanie czegoś, co nawet do testów się nie nadawało (zamiast bug-trackowania określiłbym to mianem feature-trackowania). Wiem, że rolą społeczności jest wyłapywanie bugów, ale sposób rozwijania tego projektu przez Howarda (tak bodajże ma na imię jego "ojciec") skutecznie mnie zniechęcił.

[n-pigeon]

Jeśli chcesz by coś działało to trzeba to przetestować, jak nie działa to zgłosić bug. Od kiedy BMesh jest targetem BF przyszła na to pora.

 

Mylisz Howarda z Joe, choć Joe też nie jest jego "ojcem", projekt zaczął zdaje się Briggs, ale nie miał czasu dalej nad nim pracować, zaprojektował i napisał core. Joe... powiedzmy, że popchnął dużo integracje bmesha, ale... on nie jest wyjątkowo solidny :D w dodatku chorowity, ale nie można ująć mu entuzjazmu :) hehe Lepiej mu wychodzi informowanie o swoich poglądach politycznych niż informowanie o bmeshu ^^'

 

Teraz nad BMeshem pracuje Campbell, Howard i Ender, solidnie, czasem dorzucą jakiś patch inni koderzy w tym Joe. BMesh jest teraz milestone'm BF więc pora na testowanie i zgłaszanie uwag i bugów, a nie na marudzenie, że nie było aktualizacji bloga :)

 

Od baaardzo dawna obserwuje commit log BMesha, od kilku miesięcy jest żywy jak nigdy :) o jego los nie trzeba się już martwić ;)

[mandragora]

Propozycja przeglądarki addonów Tu

[mookie]

Cycles obsługuje już multi GPU.

[n-pigeon]

Właśnie chciałem o tym napisać

 

http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=43238

[BartekSkorupa]

Nowy node się pojawił: "Double Edge Mask". http://wiki.blender.org/index.php/User:Xgl_asyliax

Obecnie znajduje się w zakładce "Filter", a moim i nie tylko moim zdaniem powinien być pod "Matte".

Spróbujemy uskutecznić małą krucjatę w celu przesunięcia go "na miejsce" :-)

Edytowane 11 Styczeń 2012 przez BartekSkorupa
Poprawka w linku

[mandragora]

http://lists.blender.org/pipermail/bf-blender-cvs/2012-January/042492.html nareszcie zmiana długości nazw z 21 znaków do 64

Cycles Roadmap

Edytowane 11 Styczeń 2012 przez mandragora

[szczuro]

tylko do 64 ;| nie jest to dużo więcej

[mandragora]

to i tak lepsze niż nic, myślałem że nigdy tego nie zmienią. Coś sie tam zawsze napisze, nie to co teraz. Wydaje mi się, że najlepiej będzie jak zrobią nieograniczoną ilość. Jakiś czas temu był urzytkownik który strasznie bolał nad tak małą ilością znaków, może jeszcze się doczekamy

[szczuro]

niekoniecznie niezlicznoną, ale 256 już zaspokajałoby raczej wiekszość potrzeb. ale masz racje zawsze to troche wiecej :)

[Gość Chrupek3D]

tutorial do Octane po niemieckiemu:

http://blenderdiplom.com/index.php/de/tutorials/item/76-octane-pitfalls

[Gość Chrupek3D]

tutorial do Cycles:

http://www.youtube.com/watch?v=2Erguve6s-U

[olaf]

uhh 44minuty ale czuje ze rzucę okiem na to dokładnie, bo sie zapowiada jakaś pracka w 3D. Blender robi na mnie z wejściem wersji 2.6 coraz większe wrażenie.

[Gość Chrupek3D]

u mnie tez szykuje sie jakaś pracka "poważniejsza", dlatego 'niestety' Maya i MR robią na mnie coraz większe wrażenie.

[n-pigeon]

Na forum Blender Artsist pojawił się wątek z pomysłem by znaleźć developera, który zgodził by się pracować przy Cycles, za dotacje od społeczności. Mike Farnsworth autor rendera RenderSpud pracownik Tippett Studio, zainteresował się propozycją i już napisał pierwszy patch dla Cycles.

 

http://morecycles.blogspot.com/2012/01/environment-importance-sampling.html

 

Environment Importance Sampling, dzięki niemu, oświetlenie wykorzystujące bardziej złożone (nie czysty kolor) oświetlenie otoczenia, będą generowały znacznie mniej szumu.

 

Trzeba podkreślić, że nie nastawia się na duży zysk z dotacji, chce pracować przy Cycles w wolnych chwilach dla przyjemności, dotacje są dla jego żony, by nie miała mu za złe, że za dużo koduje. Dlatego w linkach do dotacji nie ma określonego limitu.

Ma też pozwolenie swojego pracodawcy Tippett Studio, które jest zainteresowane wykorzystaniem Blendera i Cycles do pre-wizualizacji.

 

Trzeba przyznać że różnica w szumie jest duża :)

 

 

link do wątku http://blenderartists.org/forum/showthread.php?238834-Bidirectional-Path-Tracing-and-other-speed-improvements-on-Cycles

[mookie]

Są już buildy!

 

http://graphicall.org/799 (Windows)

http://graphicall.org/798 (linux)

[pxl666]

hm czy to dziala z sunsky czy tylko env light?

[pxl666]

hm niewiem czy dobra obralem metodologie ale nie widze roznicy

 

WITH IS

 

[ATTACH=CONFIG]84038[/ATTACH]

 

NO IS

 

[ATTACH=CONFIG]84039[/ATTACH]

[n-pigeon]

@mooki

 

dzięki

 

@pxl666

Działa z sky texture, hdri i każdą zróżnicowaną teksturą na envy, taką która ma elementy dające więcej i mniej światła. U ciebie nie ma różnicy bo to co wpada do środka nie dość, że jest małe to jeszcze to jednolity kolor, ten otwór wpuszcza za mały fragment nieba. W takim przypadku nie ważne czy jest IS czy randomowy sampling wszystko jest równie ważne, wiec nie ma hierarchi, która mogła by pokazać która próbka jest ważniejsza.

[szczuro]

pxl666: ten fix pomaga przy outdor, nie indor

[Nezumi]

u mnie tez szykuje sie jakaś pracka "poważniejsza", dlatego 'niestety' Maya i MR robią na mnie coraz większe wrażenie.

 

Na mnie cena pakietu Maya robi wrazenie :D A znajac efekty pracy bardzo wielu ludzi (w tym mnie :D) jakis czas temu doszedlem do wniosku ze Blender nie tylko wystarczy ale na dodatek oferuje wiecej niz potrzebujemy. A wraz z postepujacym procesem starzenia jakos mi glupio jechac na piracie.

I nie pisze tego po to by grzmiec z ambony bo swiety nie jestem - po prostu mysle sobie ze czasami nie trzeba strzelac z armaty do komara.

[mookie]

To już tak z rozpędu dodam, że w trunku mamy już nowe lepsze booleany.

 

http://lists.blender.org/pipermail/bf-blender-cvs/2012-January/042631.html

[n-pigeon]

o kurcze już dodali?! super, idealne wyczucie, świetny dodatek do remesha.

[pxl666]

pxl666: ten fix pomaga przy outdor, nie indor

 

niestety nie bardzo http://www.pasteall.org/pic/show.php?id=24502

[Nezumi]

To pomaga w koncu czy nie :D Nie powiem zebym na renderze widzial jakas mega roznice.

[szczuro]

niestety nie bardzo

a czego się spodziewasz od jednego małego fixa? 2 razy lepszego renderu przy 30 samplach ?

wg mnie tam przy wejściu jest ciut lepiej, a każde takie ciut przy większej ilości sampli jest na plus ;)

[pxl666]

wyglada na to ze ow algorytm jest malo przydatny lub malo wydajny...ja widze ze przy bezposrednim oswietleniu w cycles szum znika szybko

problem jest przy odbiciu wielokrotnym a tu IS nie pomaga

 

szczuro - importance sampling dla pathtracera to nie jest maly fix, ponadto te buildy maja tez MLT - proste bo proste ale jednak -- a spodziewalem sie nie tylko ja ale rowniez autor patcha jest zaskoczony slaba wydajnoscia

[szczuro]

przy założeniu że robił to po godzinach, zaczął 28-gru, bawił się w sylwestra, skończył 02 stycznia, potem debugował. To raczej dużo czasu mu to nie zajęło.

Napisanie algorytmu, który wykrywa jaśniejsze punkty na envMapie i podłączenie tego do algorytmu samplowania to wg mnie nie za wiele, dlatego nazywam to fixem i nie oczekuje od tego jakichś mega czystych renderów, ba nawet nie ściągnąłem builda :P ale może źle rozumiem ideę i rozmiary tego patha

ps. dobrze, że postujesz też te testy w wątku na blenderArtist, gdzie autor patha może je zobaczyć.

Edytowane 17 Styczeń 2012 przez szczuro

[n-pigeon]

30 sampli xD hmm z taką małą ilością sampli to się nie dziwie, że prawie nic nie widać. IS sprawdziło 30 sampli, a co jeśli sprawdzi 200 albo 1000? Jakość i efektowność IS dla enviro będzie rosła w górę.

To jest pierwszy przyspieszający patch z długiej listy nowych funkcji oraz optymalizacji. Nie oczekuj cudów na patyku, renderera nie piszę się przez sylwestra :D

 

Jakie MLT??

 

 

@szczuro, dobrze to nazwałeś, jest to IS i MIS jedynie dla enviro, światła i BSDFy już mają IS i MIS. Pierwszy kod dla Cycles, w ramach nauki jego code base.

Edytowane 17 Styczeń 2012 przez n-pigeon

[pxl666]

przecierz chodzi o roznice a nie o wyczyszczony render - nie musze go dluzej smazyc

storm_st napisal jakies proste, testowe mlt - jest w buildach z volume (jest tam tez cashowanie BVH do pliku)

 

po prawdzie to tam gdzie swiatlo pada bezposrednio to cycles sobie swietnie radzi i nie tylko ja wiazalem duze nadzieje z jakimkolwiek "uinteligentnieniem" kodu cycles - noi jak juz pisalem - sam autor sie dziwi jak niewiele pomaga jego patch

[mookie]

Ponieważ nigdy dość dobrych wiadomości - do trunka dostała się właśnie gałąź Onion, a więc usprawnienia związane z UV (i o ile dobrze pamiętam Weight Paint). Na dniach bardzo chętnie się tym pobawię.