Blender 2.64

[adek]

Fundacja Blender wspólnie z internetową społecznością developerów ogłosiła nowe wydanie programu Blender oznaczonego numerkiem 2.64.

 

Szczegóły w informacji napisane przez n-pigeona:

http://www.max3d.pl/news.php?id=2597

[smiler]

Jakby wypuścili to wcześniej, to by prześcignęli Adobe After Effects w kwestii rozmywania masek. :)

[deshu]

A jakby wypuścili jeszcze wcześniej, to by wyprzedzili każdy inny program w tej kwestii!

[smiler]

Bez sarkazmu proszę :) Akurat rozmywanie wybranej części maski w AE pojawiło się w CS6 czyli dopiero co.

[natas]

To się nazywa dokładny news ,dzięki .Jest coś podobnego do v-ray-owego Guess vertical shift ?

[deshu]

:) Nie mogłem się powstrzymać.

[Sunedge]

Nic z tego nie rozumiem, ale jakos tak milo sie czyta, ze blenderek tyle potrafi :)

Edit: Wracam do 2.63 - 2.64 nie dziala ^^

Edytowane 4 Październik 2012 przez Sunedge

[Lucas]

@Natas, w ustawieniach kamery są parametry shift X i Y, więc coś takiego jak gues shift chyba nie jest potrzebne:) (oczywiście o ile dany renderer to obsługuje, Cycles akurat tak, VRay faktycznie nie)

[deshu]

@Natas, w ustawieniach kamery są parametry shift X i Y, więc coś takiego jak gues shift chyba nie jest potrzebne:) (oczywiście o ile dany renderer to obsługuje, Cycles akurat tak, VRay faktycznie nie)

 

Co masz na myśli?

[n-pigeon]

@Sunedge

 

Co się stało? :D

 

@Lucas

 

Chyba nie o to chodziło, tego shifta używa się kiedy chcesz, by kamera miała inną pozycję origina mając przesunięcie obiektywu, taki edit dla kamery.

Tamta funkcja auto shift, zdaje się, ma ustawić kamerę tak, by nie spoglądała w górę albo w dół, jednocześnie obejmując ten sam obszar co wcześniej.

Edytowane 4 Październik 2012 przez n-pigeon

[Lucas]

Co masz na myśli?

 

Z tego co pamiętam, wspomniany Guess vertical shift służy do korekcji trzeciego zbiegu kamery i mam na myśli to, że taka korekcja już od dawna była możliwa właśnie poprzez dopasowanie Y shift w ustawieniach kamery.

[Sunedge]

@n-pigeon

Otwieram File i nie moge wybrac dysku, jak klikam na przycisk Pulpit (albo moje dokumety) zeby otworzyc tez nic sie nie dzieje. Tzn, dzieje sie - po chwili dostaje komunikat: Stacja nie jest gotowa, Exception Processing Message c00000a3 Parameters (tu grupa 25 znakow cyferkowo-literkowych) i do wyboru Anuluj, Ponow probe, Kontynuj. Wersja 2.63 dziala bez problemow.

[n-pigeon]

@Sunedge

 

Używałeś wcześniej buildów Trunka z GA.org? Tamte działały? Jeśli tamte działały to może być błąd budującego, a jeśli nie testowałeś to może masz jakiego buga którego będzie trzeba zgłosić, u mnie tego błędu nie ma.

 

Jaki system i jaka architektura?

[mallow]

Wow, ale Cycles przyśpieszył. Dzięki Render Tiles mam czasy renderingu nawet do 2 razy krótsze względem Blendera 2.63. Aż takiego przyśpieszenia się nie spodziewałem :)

[Sjon]

Zawsze podziwiałem blendera.... teraz podziwiam jeszcze bardziej.

[ikkiz]

oj, żebym tak był wstanie przyswajać ficzery w tempie ich powstawania ...

[Papa Pio]

Niech no tylko skończę obecną fuchę i się przesiadam... w prawdzie połowy z tego co przeczytałem nie kumam, ale to co kumam cieszy mnie niezmiernie :D...

[n-pigeon]

@Sunedge

 

A spróbuj opcji File > Load Factory Settings i zdaj relacje czy pomogło :)

 

@mallow

 

Ja mam scenki z 500-600% przyspieszeniem ^^ do tego dochodzi jeszcze optymalizacja i multithreding BVH, też bardzo przyspieszył, też z 5cio krotnie. :)

Oczywiście mówię o renderingu na CPU.

[deshu]

Z tego co pamiętam, wspomniany Guess vertical shift służy do korekcji trzeciego zbiegu kamery i mam na myśli to, że taka korekcja już od dawna była możliwa właśnie poprzez dopasowanie Y shift w ustawieniach kamery.

 

Bardziej chodziło mi o to, czego vray nie obsługuje:)

[mallow]

@n-pigeon: Powaga? No to super :-) Czas podłubać w końcu przy jakiejś wizce. No i muszę sprawdzić jak się Cycles sprawdzi w animacji. Jakoś po tym wydaniu Tears of Steel wydaje mi się jeszcze fajniejszym projektem, jak dzięki temu mamy tyle nowości i przyśpieszonego Cyclesa, hehe

[n-pigeon]

@mallow

No i git :) powodzenia. Jeszcze nie testowałem nie-progresywnego integratora, znaczy bawiłem się i działa tak jak w wszystkich unbiasach, czyli powoli :)

Niby ma ułatwić tworzenie odszumionych renderów, ale nie jestem pewien czy progresywny renderer z chorą liczbą sampli nie wyrenderuje szybciej bez szumu :D

Znaczy ja jestem w userbase progresywnego, uwielbiam ten leciutki szum i łatwość pracy z nim, więc moje sample zazwyczaj znajdują się w przedziale 500-1k w zależności od wagi shaderów w scenie. No i nie-prog jest trudniejszy w optymalizacji i trzeba użerać się z AA :/

 

Tak tylko daje znać by uważać i samemu przetestować. ToS raczej był renderowany na progresywnym, znaczy tak myślę, szum i tak musieliby dodać do renderów, ponieważ łączyli go z materiałem zdjęciowym, ale nie wiem jak to przebiegało dokładnie, a nie mam teraz jak się dokopać.

 

@Papa Pio i reszta

 

Mam niestety ciężkie pióro i jeśli czegoś nie zrozumieliście to mogę wytłumaczyć.

[Nanoman]

No i dzięki tiles rendering na GPU nie zamula całego komputera więc można w tym czasie robić jednocześnie coś innego :)

[mapsi-fixi]

ma ktoś problem z cyclesem ? Spłaszcza mi wyrenderowany obraz, tzn aspect jest zły, kombinuje juz godzinę i nic :/

 

[Papa Pio]

@n-pigeon

Spoko - po prostu niektóre hasła brzmią jeszcze dla mnie dość obco... ale i na nie przyjdzie czas..

[mallow]

@n-pigeon: Jak Ci się udało uzyskać takie przyśpieszenia renderingu? Zrobiłem kilka nowych testów i niestety nie jest już tak fajnie. 2.64 jest szybszy, ale niewiele. Co więcej, jeśli ustawi się render tiles na 1x1 (czyli podobnie jak w 2.63a, bo tam nie było tiles'ów), to render time rośnie względem 2.63a :-/

 

2.63a no tiles: 01:14.97

2.64 1x1 tiles: 02:19.87

2.64 8x8 tiles: 01:11.64

2.64 8x8 tiles use spatial splits: 01:14.84

 

Spróbuję jeszcze z tą sceną testową:

http://blenderartists.org/forum/showthread.php?239480-2-61-Cycles-render-benchmark

Może ktoś też porównać?

[floo]

Wersja Video:

[krzysioo]

Tak tutaj cukrzycie, a u mnie jakiś dramat jest. Z tymi kafelkami (które imo z czysto użytkowego punktu widzenia są do bani) render na CUDA wydłużył się o jakieś 7%. Jak ustawię kafla na cały ekran (1x1) to wydłuża się prawie trzykrotnie! (Może jest jakiś elegancki sposób żeby przywrócić stary, niekaflowy render?) Podobny spadek wydajności zanotowałem też podczas renderingu w viewporcie. Testowałem też pod openCL. O ile w 2.63a działało to ok25% wolniej niż CUDA ale przewidywalnie, o tyle tu albo wyrzuca mi błąd albo renderuje jakieś schizowe kolorki. Trochę jeszcze z tym powalczę, ale obawiam się że narazie powrócę do do poprzedniej wersji :/

[Lucas]

Wychodzi na to, że teraz nad jednym kafelkiem może pracować tylko jeden rdzeń/wątek - stąd te gorsze czasy. Pewnym rozwiązaniem jest ustawienie takiej liczby kafelków ile ma się wątków procesora, minus jest taki, że zawsze będzie to i tak wolniejsze niż duża liczba kafelków.

Szybciej może i jest - nie chciało mi się sprawdzać z poprzednią wersją:). Ale ja jakoś jednak wolałem stary tryb - ustawiałem liczbę sampli z dużym zapasem, odpalałem rendering i kładłem się spać albo wychodziłem z domu, jak po przebudzeniu się / powrocie stwierdzałem, że obraz wygląda już ok to przerywałem i zapisywałem - teraz już trzeba czekać praktycznie do samego końca.

[mallow]

@Lucas: Chyba masz rację. Jak renderuję na 2-rdzeniowym CPU, to przy tiles 1x1 mam czasy około 2 razy dłuższe niż przy 2.63a. Sprawdziłem też obciążenie procesora - niższe przy renderingu na 2.64 na 1x1 tiles. Zgłosiłem to na bug trackera z propozycją zmiany - dodania opcji wyłączenia tiles - wtedy nad całym obrazkiem pracowałby cały procesor. Czekam na odpowiedź.

[n-pigeon]

@mallow

Różnica się waha w zależności od sceny, shaderów, maszyny, 2 scenki lecą mi ok 5x szybciej, reszta ok 2x szybciej, bvh też miało na to wpływ.

 

Dobry pomysł z przywróceniem starej metody, może się przydać na przyszłość, zapodaj link do trackera to się podpiszę. :)

 

Dobrze jest zgłaszać regresję, często spadki są wywołane drobiazgami w kodzie, trudnymi do wyłapania bez odpowiednich scen.

 

No chyba, że to sekundowe sprawy, procki czasem mają czkawkę i może być różnica ok 5s.

[mallow]

http://projects.blender.org/tracker/index.php?func=detail&aid=32782&group_id=9&atid=498

 

Nie, to nie kwestia sekund. Render time jest u mnie dłuższy dwukrotnie. Lucas chyba ma rację z tymi rdzeniami. Mam dual core. Renderowałem 1x1 tiles na CPU. Swego rodzaju rozwiązaniem jest pomysł Lucasa, żeby ustawić tyle tiles ile się ma rdzeni. Wtedy mamy niby starą metodę. Puściłem 2x1 tiles i render time był już podobny. Tylko póki co znalazłem jedną wadę tej metody. Jak tiles jest wyższe niż 1x1, to ilość sampli się nie update'uje w pasku z render info. Podobnie z aktualnym czasem renderu, jest update tylko po wyrenderowaniu nowego kafelka. Czyli renderując z tiles=ilość rdzeni mamy podobne czasy co poprzednio, ale nie wiemy ile aktualnie jest sampli wyrenderowanych i ile się obrazek już renderuje.

[n-pigeon]

Ta scena z samochodem u mnie:

2.63 - 4:47 min

2.64 - 3:14 min

 

Mam intel i7 8 wątków (4 rdzenie dwu wątkowe), chyba coś nie współgra z twoją konfiguracją sprzętową.

Trzeba współpracować z Brechtem i resztą zgłaszać regresje i uwagi, to coś się zawsze wyklaruje :) Dopisze się do twojego wątku.

[Lucas]

Też mam i7 ale tak jak Mallow pisał - na 1x1 jest dużo wolniej bo nie pracują wszystkie wątki (niby wszystkie wykresy w menadżerze zadań cośtam pokazują, ale obciążenie sumaryczne jest na poziomie 12-13% czyli akurat 1/8).

Ustawienie liczby tilesów zgodnie z liczbą wątków ma jeszcze jedną wadę - przy nierównomiernym, że tak powiem, nasyceniu szczegółów w docelowym obrazie, dochodzi do sytuacji, kiedy obszary zawierające prawie samo tło renderują się natychmiast ale wątki procesora, które to liczyły nie są już przydzielane do pozostałych tilesów.

 

Ja zobaczyłem na szybko jeszcze jeden problem, ciekaw jestem czy to tylko u mnie:). Jeśli wyświetlam viewport w trybie innym niż wireframe, są problemy z wybieraniem przez RBM - zaznacza się zawsze obiekt znajdujący się za klikniętym obiektem. Już zgłosiłem to ale ciekaw jestem, czy nie jest to bardziej związane z konfiguracją i systemem.

[mallow]

@n-pigeon: Domyślam się, że ten czas z 2.64 to z tiles 8x8? Spróbuj dla porównania 1x1.

[krzysioo]

Mi akurat chodzi o (czasami bardzo duży) spadek wydajności przy renderowaniu na GPU (CUDA). Dotychczas GTS450 renderował mi do 7x szybciej niż Athlon X4 640, więc nie myślę z tego rezygnować. Przy ustawieniu 16x16 było wolniej niż 8x8. Zaciekawia mnie jeszcze jedno. Jak odpalam rendering jedynie na CPU, to renderuje mi naraz o jeden kafel więcej niż mam ustawionych wątków.

 

Szybciej może i jest - nie chciało mi się sprawdzać z poprzednią wersją:). Ale ja jakoś jednak wolałem stary tryb - ustawiałem liczbę sampli z dużym zapasem, odpalałem rendering i kładłem się spać albo wychodziłem z domu, jak po przebudzeniu się / powrocie stwierdzałem, że obraz wygląda już ok to przerywałem i zapisywałem - teraz już trzeba czekać praktycznie do samego końca.

Otóż to. A o ile łatwiej testować.

[BLADE]

a ja nie nrzekam. przyrost predkosci jest. choćby dla bvh.

[n-pigeon]

@mallow Lucas

 

Tak już wcześniej o tym wiedziałem, dlatego dopisałem się do raportu mallow'a że miło by było móc renderować po staremu np. kiedy ustawi się master sample na 0 (renderuje tak długo aż przerwiemy).

 

@krzysioo

 

U mnie dalej GPU (GTX570) jest szybsze od CPU działa prawie tak samo jak 2.63.

GPU szkodzą tile ;) ustaw 1x1 to będzie po staremu, więcej niż 1x1 używaj tylko dla CPU wtedy będzie speed-up.

 

 

Sergey odpisał, problem jest znany, przyczyna również. Pozostaje czekać.

[krzysioo]

@n-pigeon

Ale właśnie o to chodzi, że jak ustawie na 1x1, to wydajność GPU spada mi niemal trzykrotnie, o czym napisałem w poprzednim poście.

[n-pigeon]

GPU? Hmm a to dziwne, u mnie jest ok.

[adrian2608]

A ja mam taki problem, że na 1X1 tile mi nie renderuje. Wywala się sterownik z karty (Nvidia). Karta to nie jest potwór prędkości (430GT), ale wcześniej nie było takich problemow. Spotkał się ktoś też z takimi problemami?

Dokładnie to 430GT 2048MB. Aha scena to BMW-MikePan, ta benchmarkowa.

[mallow]

Sergey Sharybin odpisał mi na maila, że on albo Brecht van Lommel zajmą się wkrótce problemem z szybkością cyclesa pod 2.64. Jeśli macie jakieś problemy poza tymi, które opisywałem w moim zgłoszeniu na Bug Trackerze, to warto je teraz zgłosić.

Dla przypomnienia link do mojego zgłoszenia:

http://projects.blender.org/tracker/?func=detail&atid=498&aid=32782&group_id=9

[deshu]

Wczoraj tilesy mi się mega przydały. Renderowałem sekunde animacji w 720p. Ustawiłem 3x3, i podczas renderowania komp w ogolę nie zamulał - mogłem śmiało pisać i testować flasha.

 

Za to podczas tej wczorajszej zabawy, zauważyłem, że jest jakiś błąd z 'zapychaniem', co mniej więcej 7-8 klatek, komp zaczynał mulić na maksa, a cycles zwalniał wielokrotnie. Restart blendera rozwiązywał problem.

 

Podczas tych slow downów, GPU-Z pokazywało mi, że Memory Controller Load spadło do 0-1%. Poza zwiechą było na ok 90-95%.

 

P.s. renderowałem na Cudzie.

[mallow]

Dzieje się tak za każdym razem? Zgłoś na bug trackera z instrukcją jak odtworzyć błąd.

[deshu]

Tak, za każdym razem. Za bugtrackera zabiorę się za parę chwil. Wrzucę link, jakby ktoś miał tak samo.

 

http://projects.blender.org/tracker/index.php?func=detail&aid=32805&group_id=9&atid=498

Edytowane 7 Październik 2012 przez deshu