Skocz do zawartości

Blender - NEWS oraz dyskusje


n-pigeon

Rekomendowane odpowiedzi

Zdecydowanie najlepszy demoreel Blendera ze wszystkich, które były kiedykolwiek prezentowane, troszeczkę nierówny (być może niektóre słabsze klipy warto było zastąpić nieco starszymi?), rozumiem jednak, że przygotowanie takiego materiału nastręczało pewnych trudności (pewnie jak co roku presja czasu, konieczność posiadania filmów w wysokiej rozdzielczości, kwestie autorskie). Tak czy siak widać tu potencjał programu, który w rękach sprawnego grafika potrafi wygenerować solidny produkt. Czekam na redesign strony Blendera, aby takie zestawienia mogły tam "wisieć" na stałe.

Odnośnik do komentarza
Udostępnij na innych stronach

E tammm niesamowite to jest to! Nowy tool do retopologi :>

Pozamiatane wiem że modo ostatnio chwaliło się czymś podobnym

Polecam przeskoczyć do 5:15

 

[video=youtube_share;r9wnPyxrltE]

 

Nooo, swietnie wyglada. Warto wspomniec ze to platny plugin w chwili obecnej za $31.50 (cena finalnie wzrosnie o 10% jesli sie nie myle). Sam kod jest dostepny na licencji GPL, ale placac wspomaga sie tworcow.

Odnośnik do komentarza
Udostępnij na innych stronach

Finalnie to cena tych tooli do retopologi to będzie taka jak blendera bo chcą je dodać to trunka jak już będą wystarczająco dopieszczone.

 

Sporo zmian związanych z cyklem wydawniczym blendka:

 

Hi all,

 

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

 

1) Planning for next release

 

- New release scheduling proposal has been accepted. This means we will do as follows:

 

a) Test build from svn trunk, after "BCon4" has been called.

b) An official Release Candidate from a 2.69 release branch

(including release number, splash, etc).

c) The real release from this branch, after 1-2 weeks of testing and applying fixes.

 

If needed, a 2nd RC can be done from this branch as well.

 

We expect that by upgrading the RC to be a "real" release (has nice new splash!) the attention for trying and testing it will increase much compared previous RC builds.

 

- Release planning:

 

BCon2: Aug 11 (add branches to svn, targets are defined)

BCon3: Sept 01 (testing and fixing period)

BCon4: Sept 17 (provide test build, fixing only)

BCon5: Sept 29 (svn frozen, RC a few days after)

 

- Sergey Sharybin is working on planar tracker with Keir Mierle, expects it to be ready for upcoming release.

 

- Thomas Dinges' GSoC work will be ready for release too:

http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.69/Cycles

 

- Cycles: Stuart Broadfoot wants to remove the hair from the experimental feature set (move to official supported), update the interface for it.

 

- Question for Dalai Felinto: is Multiview going to be target?

 

2) Google Summer of Code

 

- Two projects didn't pass the midterm: Ines Almeida (Improved Debugging and Profiling) and Walid Shouman (Mesh data transfer).

 

- Antonis Ryakiotakis published a cool video of his progress:

 

3) Other projects and news:

 

- Thanks to Blender Development Fund contributions and donations, we can extend the Blender Foundation support team with Lukas Toenne, based on a 6 month agreement. Lukas will help doing his share of bug fixing and maintenance, especially for nodes and compositor. When time allows, he then can also pick up work on new particle system.

 

- Also Sergey Sharybin will be hired by the Dev Fund for support work after his GSoC period ends (sept 1st). Campbell, Brecht and myself will be sticking around as well - paid partially via BF, mostly via Blender Institute (e-shop) income.

 

- Meeting shortly discussed how to organize compositor feedback and use cases better. Jeroen Bakker will be available more during next period, or can work with Lukas to handle issue.

 

Thanks,

 

-Ton-

Odnośnik do komentarza
Udostępnij na innych stronach

Nezumi - Bardzo polecam nauczyć się pythona i blender api. To nie jest takie trudne! :) Proste zmiany interfaceu da się robić już pierwszego dnia nauki a jak nauczysz sie podstaw programowania w pythonie to zaoszczędzisz masę czasu robiąc sobie makra i proste skrypty pod siebie.

Odnośnik do komentarza
Udostępnij na innych stronach

Monio - Programowanie (podobnie jak matematyka w jakiejkolwiek formie poza na prawde podstawowa) to dla mnie meczarnia. Znajomosc jakiegos jezyka skryptowego bez watpienia ulatwilaby mi zycie, ale uwierz mi na slowo ze to na prawde nie dla mnie. Nie byloby niemozliwe nauczenie sie tego - byloby jednak CHOLERNIE nieprzyjemne. Zwazywszy zas na ilosc problemow w jakich by mi pomoglo skorka nie warta jest wyprawki.

Odnośnik do komentarza
Udostępnij na innych stronach

Nezumi - Bardzo polecam nauczyć się pythona i blender api. To nie jest takie trudne! :) Proste zmiany interfaceu da się robić już pierwszego dnia nauki a jak nauczysz sie podstaw programowania w pythonie to zaoszczędzisz masę czasu robiąc sobie makra i proste skrypty pod siebie.

 

Monio a rzucisz moze jakimis linkami? Takimi zeby zaczac nauke chociaz bo sam przymierzalem sie do Pythona w Blenderze kilka razy, no ale poziom rozproszenia wiedzy na ten temat w roznych zakatkach sieci zdecydowanie mnie zdemotywowal :)

Odnośnik do komentarza
Udostępnij na innych stronach

I to jest fajne jak szybko potrafią nowe rzeczy dodać do open source(to ja szybko muszę je potem robić od nowa to inna sprawa...). Btw. nie wiem czy dobrze mi sie wydaje, ale czy wprowadzając ograniczenia i wyłączając progresywność nie uzyskuje się biasowego rendera? ;) Pamiętam jak swego czasu to był główny argument za nim.

 

I jeszcze tak w offtopie niedługo UeberTage(taka konferancja XSI) pokażą tam troche RedSchifta(biasowy render GPU, według tego co gadali miał być bardzo szybki)

Odnośnik do komentarza
Udostępnij na innych stronach

@legomir nie mylisz liczyby bounce'ów z liczbą sampli na piksel? Jak w zakładce light paths wybierzesz sobie preset Direct light, to masz coś jakby biasowy. Chociaż Scotty kiedyś nam to tłumaczył co literalnie znaczy biasowy i unbiasowy i trochę to zaskakujące było

Odnośnik do komentarza
Udostępnij na innych stronach

Unbiasowy z tego co się orientuje oznacza to samo co progresywny, a path tracing, photon mapping, biderectional ray tracing czy metropolis to jedynie różne technologie na to samo. Progresywny liczy odbicia tak mniej więcej w nieskończoność aczkolwiek mówię mogę się mylić jeśli skoti czy ktoś kto ma większą wiedzę chciałby doprecyzować to byłoby miło :)

 

 

Btw. bardzo szybko doczytane:

-Photon mapping to biasowa algorytm GI(opierając się na jakimś wydzie skotiego ponieważ algorytm zakłada, że foton ma jakiś promień)

-Path może być zarówno biasowy jak i unbiasowy

-BD Ray-t tak samo

 

Czyli wszystko zależy od algorytmu. Źródło: http://geometry.caltech.edu/~keenan/bias.pdf

Edytowane przez legomir
Odnośnik do komentarza
Udostępnij na innych stronach

W moim rozumieniu chodzi o liczenie GI w scenie - biased jest metodą "fizyczną", unbiased jak wspomniany Photon mapping czy Light Cache w Vrayu to metody stosujące różne "cheaty" celem wyliczenia GI. Żaden chyba silnik biased nie liczy GI w nieskończoność tylko daje możliwość ustalenia ilości odbić promieni (w Cyclesie da się określić ilość odbić GI dla materiałów diffuse, glossy itp) co potem przekłada się na jakość oświetlenia. Direct Lighting w Cyclesie to Path Tracing tylko z 1 odbiciem promienia w scenie.

 

Progresywny / nieprogresywny integrator to określenie sposobu, w jaki renderowany będzie finalny obrazek - ilość sampli jakie integrator ma wysłać na dany pixel w celu uzyskania konkretnej jakości (mniej sampli = większy noise, więcej sampli = mniejszy noise). Jest to coś generalnie niezwiązanego z tym, czy silnik jest biased czy unbiased. W Vrayu można stworzyć render całkowicie unbiasowy (2 x bruteforce) ale można też wybrać jedną z trzech metod samplowania renderingu. Przykładowo "fixed sampling" w Vrayu to na moje rozumowanie taki Cyclesowy "Progressive" z tego względu, że każdy pixel, bez względu na to czy jest to materiał diffuse, czy np tło z krajobrazem, otrzymuje zawsze tyle samo sampli. Adaptive Subdivision w Vrayu porównuje ze sobą sąsiednie pixele i jeśli stwierdza w nich zbyt duży kontrast, wysyła dodatkowe sample na pixel aby usunąć noise (metoda dosyć stara, ale gdyby pojawiła się w Cyclesie to byłoby cudownie).

 

Non-Progressive integrator (albo sampler) różni się od progresywnego tylko tym, że daje możliwość ustalenia ilości sampli na pixel, w zależności od materiału jaki się za nim kryje. Osobiście powiem, że oczekiwałem czegoś więcej :) Nie przewiduję by ta metoda dawała jakieś zdecydowane przyspieszenie przy np. renderowaniu interiorów ale pewnie sprawdzi się w innych zastosowaniach. Przykładowo, materiały z shaderem glossy mają duży noise w porównaniu z materiałami diffuse - zwiększam więc tylko ilość sampli dla glossy a pozostałe fragmenty obrazka nie powinny renderować się dłużej (jedynie te z shaderem glossy).

Odnośnik do komentarza
Udostępnij na innych stronach

News miesiąca. Valve nawiązało współpracę z BF i będzie oficjalnie polecać Blendera jako narzędzie do moddingu ich gier.

 

Hi everyone,

I work for Valve (http://www.valvesoftware.com/company/). We would like to make our digital distribution platform Steam (www.steampowered.com) one of the places where you can download Blender. The long-term goal would be to make it easier for people to build their own mods for PC games with Blender and share these mods with other gamers.

So I was wondering if there are any Blender users on this list who are interested in PC games and could see themselves working on an integration between Blender and PC games that offer official modding support such as DOTA 2.

 

Long story:

Valve is a company that is built on modding. The original Half-Life was built on a modified version of the Quake engine. All our major games since then started out as mods which we found cool, hired the people who built them and released them as major game titles. This is true for Counter-Strike, the original Team Fortress, Day of Defeat and DOTA 2 (Portal was not technically a mod but a student project - but you see the pattern).

Similarly, one of the most successful features of our Steam platform is the Steam Workshop (http://steamcommunity.com/workshop/), which is an interface for users to share, discover and install mods for their games. Essentially, you can publish your mod there and other gamers can bring your mod into their games with a single mouse click.

This is something that we think would be a cool feature for Blender to tap into. Like modeling a sword in Blender, pushing a button and having it available to all users of Skyrim. But we bet there are more creative ideas out there than this one.

What we are currently looking at is offering a completely vanilla version of Blender as a free download on Steam that is completely the same as that offered on other websites. We'd hope that this will get enough of our users exposed to and interested in Blender so they will be inclined to work on Blender plugins that would talk to Steam's backend services such as Workshop.

If you think you might be interested in being part of that, we'd be happy to hear from you!

Best,

Jan-Peter

 

Hi all,

 

To put this in perspective - I've been in contact with JP and others from Valve (they added a donation system, to mark a percentage of sales going to Blender Foundation).

 

Valve was very interested to find other ways to support Blender, and I suggested them to more activily involve users of their platform in a stakeholder role. That could be by adding forums there, maintaining todo or issue lists, inviting people to contribute to Blender (C or with add-ons).

 

Game modding is a popular 3d activity online, and Blender for sure has a big following there. Their requirements probably won't differ much from game artists in studios either - it's all about getting the tools well defined and functional, and ensure I/O is as smooth as possible.

 

JP's suggestion for platform integration I cannot judge really... nor how much it would be a priority or how it can be delivered license-compitable. I'll leave that to the experts here.

 

-Ton-

Odnośnik do komentarza
Udostępnij na innych stronach

Cycles coraz liżej jako external engine

 

As of today the Cycles source code license has been changed from GNU GPL to the Apache License version 2.0. This is a permissive license that allows Cycles to be linked and used with any program, including commercial software and in-house software at studios.

http://code.blender.org/index.php/2013/08/cycles-render-engine-released-with-permissive-license/

Odnośnik do komentarza
Udostępnij na innych stronach

W Maxie może nie do końca, ale w Mayce to miałoby, by sens jako render w vievporcie(Vr 3.0, furryBall, iRay)

 

Dlaczego w maksie nie do końca? Dla samej liczby uzytkowników warto. No chyba, że tu chodzi o względy religijne (wszyscy nienawidzą maksa ;) ).

Odnośnik do komentarza
Udostępnij na innych stronach

przymierzałem się do luxa kilka razy jak pies do jeża, czyli chyba jakoś źle, bo jak po godzinie renderowania dostawałem małpę w kolorowe kropki (ten noise, to nie jest taki noise jak w cycles) to to trochę zniechęcające. To nie prowokacja, żeby się czepić, poważnie się pytam, bo nie znam nikogo, a to dziwne, bo czytając listę ficzerów, to zdaje się być na prawdę wszystko-mający dojrzały silnik.

Odnośnik do komentarza
Udostępnij na innych stronach

To nie prowokacja, żeby się czepić, poważnie się pytam, bo nie znam nikogo, a to dziwne, bo czytając listę ficzerów, to zdaje się być na prawdę wszystko-mający dojrzały silnik.

Zaletą Luxa jest chyba jedynie tylko to, że rozwój jest wspierany przez AMD i jako nieliczny silnik działa z ich niedopracowanym kompilatorem OpenCL. Pewnie wspomniane wyżej kilka osób to nieszczęśliwi posiadacze kart AMD, którzy nie mają praktycznie wyjścia chcąc renderować na GPU.

Odnośnik do komentarza
Udostępnij na innych stronach

lux ma parę opcji którymi nawet Vray niemoże się pochwalić. więc to nie dokońca tak jak mówicie..

VRay to zupełnie inny typ renderingu - duże uproszczenia, ale szybki czas renderingu. To, że lux ma fajne featur'y nie oznacza, że jest to soft nadający się do poważnej pracy. Mitsuba też ma fajne możliwości, ale co z tego jak nadaje się do testów featurów, ale nie do poważnej pracy. To nie ilość punktów pod "features" jest ważna, a jakość i wydajność implementacji tych potrzebnych w praktyce. Przykładowo taki Cycles teoretycznie możliwości ma mizerne, ale w praktyce jest dużo lepszym silnikiem niż LuxRender (który teoretycznie potrafi dużo więcej, ale podstawowe rzeczy robi dużo gorzej i wolniej, przez co nie nadaje się do niczego, poza wykonywaniem testów możliwości (lub przy ekstremalnie cierpliwych osobach do stila renderowanego kilka dni)).

Edytowane przez Skoti
Odnośnik do komentarza
Udostępnij na innych stronach

Lux render miał oddzielny projekt zwany SLG smallluxGPU. problemem było to że tak naprawdę ciągle był w fazie beta musiałeś umieć niemal pisać shader w kodzie żeby go używać itp.. miał jedną podstawową zaletę. Był to rendering CPU+GPU lub GPU. A to daje takie rezultaty

 

http://www.blenderartists.org/forum/showthread.php?297740-aston-martin-vanquish-2013

 

10-20 minut. owszem cycles Vray i inne wyrenderują to szybciej. ale fakt faktem jest. Istnieje wersja luxrendera która jest użyteczna i nie renderuje parę dni. Do dzisiaj była ona zarezerowawana dla maniaków. Ale z wyjściem wersji 1.3 powstał converter i zostałą ona wbudowana w 1.3. Tak więc lux wraca do gry..

attachment.php?attachmentid=244589&d=1373044259

Odnośnik do komentarza
Udostępnij na innych stronach

.. miał jedną podstawową zaletę. Był to rendering CPU+GPU lub GPU.

Chciałeś powiedzieć jedną podstawową wadę? Połączenie renderingu CPU+GPU ma sens tylko i wyłącznie w APU i SoC, gdzie CPU i GPU współdzielą pamięć, ale na takim GPU zapewne renderować i tak nie będziesz. Renderując na CPU+GPU przy dyskretnym GPU uzyskasz gorszy rezultat niż renderując na samym GPU (gdzie procek jest zajęty mocno przerzucaniem danych na kontekst GPU i kopiując dane z pamięci CPU do GPU i w drugą stronę). Sam pomysł wykorzystania algorytmów, które da się zastosować na CPU i GPU jest największym błędem Luxa, przez co ani na CPU dobrze nie działa kod OpenCL (słabe kompilatory w sterownikach), ani na GPU (niepasujące do architektury GPU algorytmy). Wszystkie renderery oparte o OpenCL czyli Vray czy IndigoRT mogą bez problemu pracować w trybie CPU+GPU, ale twórcy tych rendererów specjalnie zablokowali tą opcję (bo przy dyskretnych GPU, a tylko takie się używa do GPGPU działa to na niekorzyść wydajności).

 

Lux render miał oddzielny projekt zwany SLG smallluxGPU.

LuxRender miał oddzielny projekt SmallLuxGPU czyli super prosty pathtracer, oparty na SmallptGPU, ale to dawne dzieje. Później projekt przerobiono na LuxRays i to on jest w LuxRender, ale ze SLG nie ma wiele wspólnego, bo zupełnie inaczej renderuje - ma dużo większe możliwości, ale jest też co najmniej kilkadziesiąt razy wolniejszy.

Edytowane przez Skoti
Odnośnik do komentarza
Udostępnij na innych stronach

Wszystkie renderery oparte o OpenCL czyli Vray czy IndigoRT mogą bez problemu pracować w trybie CPU+GPU, ale twórcy tych rendererów specjalnie zablokowali tą opcję (bo przy dyskretnych GPU, a tylko takie się używa do GPGPU działa to na niekorzyść wydajności).

 

Takie pytanie, bo może źle zrozumiałem, ale na prezentacji na temat GPU w Vr, Vlad tłumaczył coś o tym, że RT jest szybki ponieważ pewne rzeczy są robione na CPU, a reszta GPU i było jeszcze coś o zapisywaniu w każdym razie czy to nie jest coś w rodzaju CPU+GPU?

Odnośnik do komentarza
Udostępnij na innych stronach

Takie pytanie, bo może źle zrozumiałem, ale na prezentacji na temat GPU w Vr, Vlad tłumaczył coś o tym, że RT jest szybki ponieważ pewne rzeczy są robione na CPU, a reszta GPU i było jeszcze coś o zapisywaniu w każdym razie czy to nie jest coś w rodzaju CPU+GPU?

W rendererach GPU praktycznie zawsze jest tak, że część robi CPU (to co szybciej robi się na CPU), a część na GPU (to co szybciej na GPU). W wypadku LuxRender CPU i GPU robią dokładnie to samo (ten sam kod jest wykonywany na CPU i GPU, tylko dla innych fragmentów ekranu) - czyli zamiast się podzielić rozsądnie pracą co kto ma robić, to jest wepchane wszystko na wszystko i nie działa dobrze ani na CPU, ani na GPU (po prostu w LuxRender skorzystali z tego, że raz napisany kod OpenCL działa na wszystkim i można odpalić nawet na karcie dźwiękowej obliczenia, zapominając o olbrzymich różnicach architektury i konieczności pisania zupełnie innego kodu na CPU i GPU).

Odnośnik do komentarza
Udostępnij na innych stronach

Ale to juz jest w blenderze tylko pod inna postacia wchodzisz w czasteczki hair ustawiasz ilosc hair per face na 1 ustawiasz ilosc hai tyle ile jest faceow ustawiasz zeby zamiast hair byl obiekt i juz :)

 

Aweightami mozesz pomalowac gdzie male gdzie duze.

 

Ale fainie ze ktos zrobil oddzielnego addona apropo tego i na nodach :)

Odnośnik do komentarza
Udostępnij na innych stronach

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