Wielkie zadania w rozwoju Blendera

Dalai Felinto, który jest teraz głową i „szefem” wszystkich deweloperów w Blender Institute, napisał ostatnio list, w którym zwraca uwagę na wielkie zdania, przed którymi stoi zespół tworzący Blendera, i wymienił je w swoim poście na stronie https://code.blender.org/2020/01/2020-blender-big-projects/. Dodane parę dni później: Pablo Vasquez w swoim wideo przesyłanym na żywo także dyskutuje te projekty, oprócz wielu innych rzeczy – warto obejrzeć choćby przez ten ładunek pozytywnej energii, która Mu towarzyszy: Poniżej umieszczam listę tych zadań. Dodałem do nich od razu opis i link razem z odpowiednim numerem zadania w systemie zarządzającym projektami). Gdy klikniesz w sam tytuł, przejdziesz do dokumentacji Blendera wyjaśniającej jak działa dany mechanizm.

Multires

Multires    T73317 „Wielo-rozdzielczość” – tak chyba bym to przetłumaczył. Chodzi tu o to, że taka możliwość dotyka rzeźbiarzy oraz animatorów. Możliwe powinno stać się dopracowanie i „wypolerowanie” tego fragmentu, ponieważ dzięki niemu można będzie rzeźbić na wielu poziomach szczegółowości (co teraz jest ograniczone), będzie też można prowadzić animacje obiektów w niskiej rozdzielczości, mimo, że będą wyrzeźbione w wysokiej rozdzielczości. Multires pamięta poszczególne warstwy deformacji na obiekcie i można się między nimi przełączać. A przynajmniej tak miałoby być gdyby dopracowano ten fragment Blendera.

Library Overrides

Library overrides T73318 Chodzi o „nadpisywanie bibliotek”. Ten system pozwala dołączać do pliku BLEND inne pliki, a potem w razie potrzeby niektóre własności z dołączonych modeli lub animacji „nadpisać”, ale tak, że aktualizacja źródłowych plików nadal wprowadza zmiany w tych miejscach, których nie „nadpisaliśmy”. Możliwe byłoby wtedy animowanie takich samych postaci w różny sposób. Jest to kluczowe dla animatorów i niezbędne przy wielkich projektach, które mogą wymagać współdziałania dziesiątek lub setek plików BLEND. Dodatkowo w tym planie uwzględniona jest możliwość tworzenia całych scen z „rekwizytów” dołączanych z innych plików, ale zmienionych lokalnie. Wtedy usunięty zostanie stary system tworzenia „proxy” dla armatur.

Particles nodes

T73324 Nody do kontroli cząstek! To jest coś, na co wszyscy czekamy. Jeżeli pamiętacie, parę lat temu już pokazywałem pewne próby, które Lukas podejmował, aby napisać taki system. Teraz w Blender Institute jest zatrudniony deweloper, który wymyślił i napisał Animation Nodes (Jackques Lucke TW, FB, https://github.com/JacquesLucke/animation_nodes), zatem możliwe, że będzie tutaj spory rozwój. Nadzieja w tym projekcie jest taka, że system cząstek będzie można swobodnie rozwijać podobnie jak system materiałów w Blenderze (bo liczba nodów może być po prostu ogromna), i że pojawią się cząstki generowane przez inne cząstki, oraz wiele innych możliwości. Dalai podpowiada – że można będzie robić efekty postarzania się sceny, rosę spływającą z liści, fajerwerki i różne generatywnie tworzone efekty.

Nowy rodzaj obiektu „objętość”

T73201 Objętości i renderowanie wolumetryczne domaga się wsparcia i powinien powstać nowy blok danych w Blenderze, obsługujący objętości (tzw. z ang. data-block). Dzięki temu Blender będzie w stanie przetwarzać i renderować objętości zgodnie ze standardem OpenVDB, którego pełna implementacja nie jest łatwym zadaniem. Wsparcie dla OpenVDB pomoże pracować z obecnymi rozwiązaniami w Blenderze (np. z modyfikatoremi generującymi płyny, w tym dym), umożliwi importowanie do Blendera symulacji wolumetrycznych wykonanych w innych programach i pozwoli pracować z geometrią generowaną wolumetrycznie. Będzie to fragment jeszcze większego projektu nazywanego przez deweloperów „everything nodes”, czyli „wszystko w nodach”, do realizacji którego Blender ustawicznie zmierza od paru lat.

Nowy rodzaj obiektu: włosy

T68981 Ten projekt nie ma jeszcze planów na rozwój. Pierwszym krokiem będzie zastąpienie włosów robionych z cząstek na ich własny obiekt i odtworzenie całej funkcjonalności, którą mamy obecnie. Dzięki temu włosy będzie można generować za pomocą nodów, a co potem – to się dopiero zobaczy. Jest to jeden z dalszych projektów bez jakiegoś szczegółowego zarysu prac, wiadomo jednak, że aby działał, potrzebne jest wcześniej zrobienie cząstek opartych o nody.

Szybsze odtwarzanie animacji

Dalai napisał „Animators should be able to work in an interactive and real-time environment„, co przetłumaczyłbym jako „Animatorzy powinni móc pracować w interaktywnym środowisku działającym w czasie rzeczywistym”, co potem wyjaśnia nieco szerzej. Pisze, że chlebem powszednim animatora jest praca w Viewporcie, a zatem szybkość odtwarzanej animacji powinna po prostu zależeć od szybkości ustawionej w animacji, liczonej w klatkach na sekundę. Dlatego Viewport powinien być tak zoptymalizowany, aby działał jak najszybciej. Planowane są zmiany, dzięki którym zwiększy się wydajność animacji i renderowania, pojawi się cache animacji, krzywe ruchu będą się aktualizowały w locie, itp. Wiemy jak jest teraz – spróbujcie zrobić symulację z pięcioma tysiącami obiektów zderzających się ze sobą; wtedy można zatęsknić za szybkim wyświetlaniem sceny 🙂 Obecność kilku postaci ze skomplikowanym rigiem także potrafi mocno obliczeniowo obciążyć Blendera, a Viewport do tego dokłada swoje własne narzuty. Jest to moim zdaniem bardzo ważny projekt, i bardzo potrzebny dla każdego, kto tworzy bardziej skomplikowane sceny (lub np. modeluje w setkach tysięcy wierzchołków). Dorzuciłbym tu od siebie, że przydałoby się także przyspieszyć Blendera w sytuacji, gdy musi on tworzyć lub usuwać nowe obiekty (spróbujcie skopiować 10 tysięcy klocków lub nawet je tylko przesunąć, albo wyrzeźbić bryłę z dwoma milionami wierzchołków i potem włączcie Tryb Edycji… do czasów Blendera 2.83 – Blender mówi – „żegnam”)… Ale już o tych szczegółach Dalai nie napisał, pozostaje mieć nadzieję, że tam także pojawią się optymalizacje.

Edycja sceny w Trybie Obiektowym

T73359 Ten cel trochę się wiąże z wydajnością na którą narzekałem w punkcie poprzednim. Chodzi o to, że Blender od wersji 2.80 inaczej zarządza sceną i złożoność operacji które robi jest tak wielka, że znacznie wzrosły koszty Undo i powrotu do poprzedniego stanu sceny. Odczuli to boleśnie artyści, którzy pracowali nad filmem Spring, możecie też przeczytać o tym na forum Blender Artists, lub na Blender Devtalk.   Dlatego zaimplementowano zoptymalizowane pod względem bloków danych globalne undo, a to dało początek temu projektowi. Planowane są obecnie dalsze rozszerzenia, w których wykonane zostaną optymalizacje undo w ciężkich scenach, także w pracy w Trybie Pozy w ciężkich scenach i podczas duplikowania obiektów w ciężkich scenach.

Szybkie edytowanie wysokorozdzielczych meshy

T73360 Wiemy, że w zasadzie nie ma górnego limitu skomplikowania obiektów innego niż pamięć i wydajność komputerów. W przypadku Blendera celem jest powrót do wydajności z wersji 2.7x w przypadku modelowania bardzo skomplikowanej i bogatej w dane geometrii, czyli głównie w przypadku rzeźbienia i pracy z modelami hi-poly. Jak na razie ten projekt jest w powijakach i dopiero dyskutowane jest jak do tego podejść, ale ogólny kierunek nakreślono jako „edycja wysokorozdzielczych meshy bez modyfikatorów powinna być możliwa z dobrą wydajnością”.

Alembic / USD

T73363 Zapewne słyszeliście tę dziwną nazwę, przypominającą nieco czasy alchemików ze średniowiecza. Chodzi o standard wymiany danych opracowany przez Industrial Light and Magick oraz Sony Pictures Imageworks (a więc – przez dwie wiodące wytwórnie związane ze świetnymi efektami specjalnymi). Alembic jako format wymiany danych umożliwia zapisanie geometrii w postaci wyliczonej (w terminologii Blenderowej – „wybejkowanej”) i wymianę danych pomiędzy wieloma programami (na Wiki jest ich lista). USD to jest nie tylko dolar amerykański, ale także Universal Scene Description – format wynaleziony przez Pixar do wymiany danych graficznych pomiędzy scenami 3d. Jak się pewnie domyślacie, tego typu wsparcie otwiera i łączy Blendera z całym przemysłowym światem efektów specjalnych, wielkich superprodukcji i wspaniałych możliwości. Dalai podkreśla, że cały świat obecnie zmierza w kierunku unifikacji i rozwiązań Open Source, a Blender jest tutaj doskonałą platformą, w której spotkać się mogą tego typu rozwiązania. Planowane jest dalsze wsparcie (które w Blenderze istnieje od wersji 2.78), w tym możliwość eksportowania Custom properties, możliwość importowania dowolnych danych, a w temacie USD możliwość eksportu animacji szkieletowych oraz importer USD.

Podstawy zarządcy rekwizytów

T73366 Tak przetłumaczyłem znane pojęcie „asset manager”. Prawda, że nie wiadomo o co chodzi? W tym przypadku prace zmierzają do stworzenia narzędzia do obsługi plików w których przechowywane są „rekwizyty”, czyli części funkcjonalne z których korzystamy. Mogą to być obrazki, materiały, tekstury, nody, animacje, armatury, rigi, skrypty, modele, i cokolwiek tylko jest reprezentowane przez blok danych. Sprawne zarządzanie takim zestawem obiektów wymaga odpowiednio przemyślanego podejścia, i sprawy poprawiają się z roku na rok. Dalai umieścił na stronie ze swoimi postami małą animację pokazującą co byłoby możliwe, a chodzi tutaj o takie funkcje, jak możliwość zarządzania i przeglądania danych, i o platformę dla każdego umożliwiającą napisanie swojego własnego narzędzia do zarządzania danymi przechowywanymi w Blenderze. Muszą one umożliwiać sposób na zapis, przeglądanie i ładowanie tworzonych przez użytkowników treści (takich jak pozy, obiekty prymitywne, materiały, itp…) do użycia jako punkt startowy na początku pracy; muszą także posiadać sposób na zarządzanie połączeniami pomiędzy wieloma plikami, takimi jak filmy z dołączonymi bohaterami, sceny i właśnie – rekwizyty, które do scen są dodawane, a oryginalnie przechowywane są w innych plikach. Moim zdaniem, wobec złożoności i bogactwa rzeczy, które Blender przechowuje w swoich plikach, nie jest to ani łatwe zadanie, ani jasno określone. Debata na ten temat zaczynała się już w latach moich pierwszych wizyt w Blender Institute, pięć czy sześć lat temu, gdy deweloperzy dyskutowali między sobą, i z Tonem, co powinno być zachowane w pustym pliku BLEND. Zobaczcie sami 🙂
przykład GUI asset managera
Przykład GUI asset managera
  Na koniec, jakby tego było, pojawia się lista jeszcze innych projektów, które gdzieś tam z tyłu głowy deweloperzy muszą mieć – Dalai wymienia tutaj całą listę: Vulkan, AR/VR, LANPR, Greasepencil, Custom keymaps, Retopology, Compositor, Sculpting, Texture painting, Cycles, EEVEE improvements. Pewnie jest ich więcej. Wszystkie powyżej opisane projekty wpisane zostały do kluczowych dla rozwoju Blendera i będą realizowane równolegle przez osobne lub łączone grupy programistów. Cały post możecie przeczytać w wersji oryginalnej tutaj:

2020 – Blender Big Projects: https://code.blender.org/2020/01/2020-blender-big-projects/

 

A co Ty o tym myślisz?

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *