Blender - NEWS oraz dyskusje

[Kramon]

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]

[Nezumi]

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.

[ikkiz]

stówa, ale chyba kupię. Bsurfaces kupowałem jak jeszcze był płatny, to i to warto wesprzeć, bo produktywność jest zaskakująca. w gamedev po prostu "must have"

[Monio]

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-

[Nezumi]

Przy okazji - co sie stalo z pie menus? Mialy byc w 2.68 zdaje sie? Jakies planowe przesuniecie czy odlozone na "niewiadomo kiedy"?

[szczuro]

Nezumi: jest w addonach ale z tego co się orientowałem konfiguracja tego pod siebie to grzebanie w skryptach

[Nezumi]

Dzieki. Grzebanie w skryptach jest niestety zdecydowanie poza moimi umiejetnosciami ;)

[Monio]

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.

[Nezumi]

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.

[le_chu]

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

[floo]

@le_chu

Tutaj można fajnie zacząć przygodę z python-em:

http://www.codecademy.com/learn

 

http://cgcookie.com/blender/category/tutorials/scripting/

 

Całkiem świeży materiał:

[le_chu]

floo - dzieki, codeacademy zaczalem juz meczyc tygodnie temu, bardzo fajna rzecz :)

 

Co do tutka z cgcookie - wlasnie czegos takiego szukalem, jak polaczyc wiedze z codeacadem i wrzucic do Blendera.

[alex3d]

Kolejny bajer od Thomasa Dingesa:

 

"Cycles: Non-Progressive integrator is now available on the GPU (CUDA, sm_20 and above) and can be tested in Trunk."

 

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

 

W takim razie zabieram się do testowania :)

[ikkiz]

dzięki alex3d

Ja sobie musiałem odświeżyć z czym się to je, i ile sampli razy ile ... i po czemu to w ogóle szybsze (już teraz na gpu) i lepsze, to może rzucę _linkiem_ z przykładami i obrazkami

[legomir]

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)

[ikkiz]

@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

[Kramon]

No bo direct lightening a photon maping czy path tracing. to jest zupełnie co innego a niżeli biased albo unbiased.

[legomir]

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 10 Sierpień 2013 przez legomir

[le_chu]

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

[Monio]

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-

[Kramon]

To jest bardzo dobra wiadomość a kolejną wiadomością jest

 

Skin shader z arnolda w blenderze!

 

http://www.blenderartists.org/forum/showthread.php?287516-Arnold-skin-shader-ported-to-Cycles

[Kramon]

Octane Render for Blender!

 

http://render.otoy.com/forum/viewtopic.php?f=7&t=34438

[Kramon]

sory za tripple posta ale znalazłem kolejną ciekawą informację a mianowocie nowy feature w blenderze 2.69

 

wpisujemy temperature światła :D

 

http://elbrujodelatribu.blogspot.cz/2013/08/blender-cycles-black-body-lights.html

[Kramon]

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/

[Monio]

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

[legomir]

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)

[deshu]

Ja bym cyclesa widział w rhino.

[_michal]

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

[legomir]

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

[Kramon]

Lux render 1.3 właśnie ujrzał światło dziennie sporo usprawnien, no i nody.

 

http://www.blenderartists.org/forum/showthread.php?304155-LuxRender-1-3RC1-Released&p=2450647#post2450647

[ikkiz]

kto używa? ręka do góry...

[Kramon]

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

[ikkiz]

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.

[Skoti]

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.

[Kramon]

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

[Skoti]

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 21 Sierpień 2013 przez Skoti

[Kramon]

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

[Skoti]

.. 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 21 Sierpień 2013 przez Skoti

[legomir]

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?

[Skoti]

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

[Monio]

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

 

WOW !!!!!!!!!!!!!! Musze to przetestować!

[Kramon]

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

[le_chu]

To jest cos ZUPELNIE innego niz hair + weight paint.

[Kramon]

To jest cos ZUPELNIE innego niz hair + weight paint.

 

tzn to co pokazał koleś na filmiku jest hair z 1 hair na face. :> Ale to ma więcej możliwości bo tam był jakieś inne jeszcze opcje.

[frmdbl]

Jeśli ktoś z was jest zainteresowany exportem "sharp edges" jako "per-vertex normals" w Blenderze,

którego implementacji podjął się Bastien Montagne

tutaj odbywa się zbiórka:

 

mont29.wordpress.com

 

Dokładne wyjaśnienie problemu i rozwiązania na stronie.

[Monio]

No i zbiórka poszła gładko. W idealnym czasie bo w firmie piszemy eksporter w którym chcieliśmy mieć taką funkcje, teraz będzie łatwiej.

[frmdbl]

Export "smoothing groups" też już działa dobrze.

 

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

[Kramon]

Export "smoothing groups" też już działa dobrze.

 

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

 

to jest świetna wiadomość trzeba będzie pretestować.

 

Ale po prostu ja was przepraszam nie odbierajcie tego jako atak czy coś ale serio no obejrzyjcie te video! Trochę beka :) Ciekawe jak bardzo mayka niszczy blendera w animacji :) bo no kiepska w blenderze jest :D

 

[Creator]

@Kramon - nie no jeśli chodzi o modelowanie to Mayka ssie, a rozkładanie UV jest jeszcze z czasów prehistorycznych.

Natomiast w animacji i tworzeniu skryptów to jeszcze Blenderowi brakuje. Blender niestety odziedziczył styl animowania po maxie. Przedewszystkim Graph Edytor przekombinowany.

Kolejna sprawa to wydajność viewportu. W blenderze wczytam obj 1,5 miliona poly i kaplica. W Mayce udało mi się 4 miliony bez problemu i jeszcze jako tako dało się to edytować.

Także nieprędko uda Ci sie przekonać doże studia animacyjne/filmowe do przejścia na Blendera ;)

Do modelowania jak najbardziej Blender jest 100x lepszy. Sam używam, w Mayce nawet nie odpalam edycji siatki, wolę się nie denerwować.

[Kramon]

ja nawet nie chce przekonywać ludzi od animacji do blendera bo po co? Niech dany soft skupi się na jednym i niech będzie w tym naprawdę dobry!. W szczególności że Animatorzy i ludzie od modelingu mogą wykonywać te czynności i tylko z nich się utrzymywać tak tzn no jest to specializacja. Tak więc pod tą specializację mogą być oddzielne softy.

 

Animowałem trochę w blenderze i naprawdę nie ogarniam tego systemu czasem zastanawiam się ale dlaczego niemożna tego zrobić po prostu w taki prosty sposób dlaczego muszę tworzyć 500 elementów tylko po to żeby przyblokować rig w jednej osi.