Jump to content
n-pigeon

Blender - NEWS oraz dyskusje

Recommended Posts

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).

Share this post


Link to post
Share on other sites

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-

Share this post


Link to post
Share on other sites

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/

Share this post


Link to post
Share on other sites

Cycles w majce i maxie. :) Wymiana materiałów pomiędzy softami + OSL. Najs. Ciekawe jak to się przełoży na support cycusia.

Share this post


Link to post
Share on other sites

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)

Share this post


Link to post
Share on other sites
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 ;) ).

Share this post


Link to post
Share on other sites

Bo w maxie nie można zrobić tego w view(Vlad od VR mówił o tym na jakiejś prezentacji, ta część API jest zamknięta chyba), a wiele z fajniejszych opcji, które opisywali tutaj wiązała sie z renderowaniem viewporcie

Share this post


Link to post
Share on other sites
kto używa? ręka do góry...

 

ja osobiście znam 4 osoby które używają zawodowo.

 

Sam się osobiście zastanawiam, teraz gdy są nody, i jest sporo szybszy wydaje się ciekawą opcją.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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)).

Edited by Skoti

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
.. 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.

Edited by Skoti

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites

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 :)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...

Important Information

We are using cookies. Read about our Privacy Policy