Monio

W sumie. To tak jak ludzie robili podgląd jeszcze przez tym image texture. ;) Kopia sceny byłaby najbardziej humanitarnym rozwiązaniem jakie można zrobić na teraz. Dałoby się tam generować unikatowe materiały w zależności jaka texa ma być podpięta do obiektu lub obiektów. Po nowym bakeu wycinamy wszystkie materiały, dodajemy nowe obiekty jeśli trzeba, przypisujemy wszystkie materiały i mapki od początku żeby nie było żadnych konfliktów. Jednak iteracyjność takiego podejścia jest średnia. Goście pisali że docelowo chcą załatwić podgląd wypalania tak że tekstura updateuje się na bieżąco w image editorze i texture preview. Czyli będzie można zobaczyć jak mapki się sukcesywnie odszumiają lub dodają się nowe tilesy. Jakby dało się zobaczyć to gotowym materiale ze wszystkimi mapami na raz byłoby idealnie. Patent z kopią sceny zawre jako rozwiązanie tymczasowe zanim zabiorą się za Bake Preview. Thx.

Azbesty- Przeczytaj uważnie parę moich poprzednich postów. To co proponujesz nie zadziała. Musiałbyś dodawać wiele image nodów do jednego materiału (jeden na każdy wypalony obiekt). Wybranie image noda to edycja materiału. Jeśli masz kilka obiektów z takim samym materiałem to możesz wybrać tylko jedną image node i poprawnie będzie ci się rysował jeden z obiektów a reszta będzie rysowana niepoprawnie za pomocą właśnie tej samej wybranej texy. Żeby materiały rysowały się poprawnie na wszystkich obiektach musiałbyś zrobić twarde kopie wszystkich materiałów dla każdego obiektu i dopiero tam powstawiać image nody. Czyli zrobić sobie siekę ze sceny.

Teraz patrzę że to by uniemożliwiło bake w internalu. Znaczy możliwość by była ale bake zawsze kończyłby się rozwaleniem wszystkich materiałów na scenie. Nie przejdzie. Te texy muszą być jakoś wyświetlane niezależnie od danych materiałów. Przykładowo jak teraz dzieje się z Matcapami które nie są materiałem tylko trybem wyświetlania. Dodam ten tą zakładkę z opcjami podglądu w panelu Bakeu po prostu. Wybieramy targeta z listy i w dodatkowej zakładce są wszystkie jego linki do tekstur oraz tryb wyświetlania.

Tan skrypt musiałby również zapisywać kopie wszystkich cyclesowych materiałów z których bakowaliśmy, razem z przypisaniem ich do odpowiednich faceów na siatkach. Potem zmieniać renderer na Internal. Ponowne jego kliknięciem musi zamieniać materiały na oryginały z cyclesa i zapisać do obiektów kopie materiałów do podglądu i zamienić renderer na cyclesa. Również paskudny hack jak mój ale to jest jakaś alternatywa. Pytanie jak sobie poradzić z sytuacją gdy ktoś zacznie modyfikować te podglądowe materiały albo ponownie odpali bake (który też będzie w internalu przecież), albo zmieni silnik na Cyclesa.

Tak ale wtedy tracisz te materiały więc nie wybejkujesz ich ponownie. To też nie rozwiązuje to sprawy poprawnego wyświetlania tego co wypaliłeś (pojedyncze pasy na flat shade). Fuuuuck.

To oczywiste. Złożone zadanie wymaga większej ilości pracy do jego wykonania. Po 5 minutowym tutorialu "jak wymodelować kubek w blenderze" prawdopodobnie nie będziesz w stanie modelować złożonej postaci z dziesiątkami detali i topologią pod animacje. ----------------------------------------- Dobra. Mam do was wszystkich pytanie. W TYM poście pisałem jak spaprana jest obecna architektura wypalania. Wypalanie per materiał a nie obiekt, dodawanie nody z obrazkiem do materiału, również w celu podglądu texy i inne koszmary. Komplikacje które z tego wynikają są na tyle ogromne że mogą udupić cały bake na zawsze... Problem jest taki że to co wypalamy z założenia nie jest tym samym materiałem z którego wypalamy. Cała idea wypalania polega na tym żeby z wielu matriałów o rożnych właściwościach uzyskać jeden zestaw tekstur który pomoże odwzorować te materiały za pomocą zupełnie innego materiału już w silniku. Wcześniej skupiałem się głównie na bakeu "Selected to Active" gdzie każdy target może mieć swój unikalny materiał i niczemu to nie szkodzi. Problem pojawia się czy Direct bake gdzie obiekt ma wiele materiałów i nie chcemy żeby po bakeu te materiały zostały nadpisane na unikalne (do dopiero byłby koszmar). W ogóle wymóg modyfikowania materiału przed bakiem i modyfikowanie go po nim nie powinien mieć nigdy miejsca! W moim podejściu wypalanie oczywiście będzie odbywało się per obiekt, czyli tak jak wszędzie. Wypalając obiekt z wieloma materiałami tekstura wygenerowana z tego obiektu zawiera informacje ze wszystkich jego materiałów. Czyli wygląda tak jak to teraz przy wypalaniu przez "Selected to Active". Mogę dodać opcje dzięki której każdy materiał będzie wypalony do osobnej texy ale oczywiście będzie się to odbywało per obiekt per materiał a nie per materiał per obiekt. Problem dodawania pustego obrazka do materiału również u mnie nie występuje bo on jest generowany w locie na podstawie tego co user podaje w outpucie, nie musi być w nodach materiału. Zupełnie już zrezygnowałem z dodawania tych nodów nawet jako dodatek w celach podglądu bo przy wypalaniu wielu obiektów za pomocą jednego materiału shader network byłby zasrany niepotrzebnymi image nodami, po jednej na każdy wypalany obiekt. Z uwagi na to że wybierając image node jako aktywną edytuje się materiał na wszystkich obiektach do których jest przypisany podgląd nie miałby najmniejszego sensu, wybierając jeden obrazek dla danego obiektu ten obrazek będzie również wyświetlał się na innych obiektach. Czyli to co mamy u mnie: 1. Materiały są w dokładnie takim stanie jak były przed Bakiem. Żadnych śmieciowych nodów. 2. Jedna tekstura na obiekt (lub grupę obiektów z dopasowanymi UV) która zawiera wszystkie materiały. Czyli dokładnie to co leci do silnika gier albo zewnętrzego renderera gdzie obrazki podpinamy do ubershadera. 3. Po skończonym bakeu mamy wszystkie potrzebne nam teksturki z dobrymi nazwami na dysku. Lub jak ktoś chce w pliku blend w celu ich spakowania. Sedno problemu to sposób wyświetlania wypalonych modeli. Obecny texture preview nie daje w ogóle całościowego poglądu jak będzie wyglądał asset w silniku. To co możemy tam zobaczyć to pojedyncze tekstury wyświetlana w formie flat shade. Nie da się wyświetlić diffuse i speculara oświetlonych realtimowo przez lampę. Podgląd normalmapy w ogóle nie ma najmniejszego sensu bo ta również wyświetla się jako kolorowa texa flatshade a nie jako efekt normalmapy. Na dzień dzisiejszy jeśli chciałbym poprawnie wyświetlić cały model musiałbym zmienić renderer na Blender internal, skasować materiały z obiektów i przypisać im nowe z wypalonymi teksturami. Destrukcja do potęgi. Ewentualnie kopia sceny z linkowanymi obiektami, ustawiony blender internal i unikatowe materiały z wypalonymi texami. Również masakra. Mój pomysł jak to załatwić. Trochę pokraczny ale na razie nie widzę innego wyjścia z tego bagna. 1. Dodatkowy tryb wyświetlania viewportu "Bake Preview" który jest tylko podglądem tego co wypalimy a nie odwzorowaniem materiału. 2. W panelu properties -> Object jest dodatkowa zakładka która nazywa się "Bake Preview data" 3. W zakładce można wybrać jeden z kilu modeli wyświetlania (shader): a. Specular based (passy: diff, spec, spec roughness, normal) b. Metallicity based (passy: albedo, roughness, metallicity, normal) c. Combined Lighting (passy: combined) 4. Po wybraniu odpowiedniego modelu pojawiają się pola w których możemy dodać nasze tekstury (prawie nigdy nie będziemy tego robić sami) ---- 5. W zakładce Bake Output możemy zdefiniować jaki model wyświetlania ma zostać przypisany do obiektów. 6. Wypalone tekstury są automatycznie przypisywane obiektów z których wypalaliśmy. 7. Odpalamy wyświetlanie "Bake Preview". Modele renderuja się za pomocą wybranych przez nas wbudowanych shaderów za pomoca tekstur które wybejkowalismy. Everybody are happy. Myślicie że coś takiego w ogóle przejdzie? Ma ktoś pomysł jak to mniej koślawo rozwiązać bez hardkorowego zmieniania bebechów cyclesa i blendera?

Będę postulował o material_id pass dzięki któremu bedzie sie dało zalatwic takie rzeczy bez odpalania nodów. Potrzeba jeszcze wiele czasu aż z tego bake bedzie sie dalo korzystać. ;)

Sprawdziłem i chyba jedyne ustawienia jakie były inne to smooth angle w wyłączonym auto smooth normals, zmiania nic nie dała. Podmieniłem data jednego działającego planea na mesha z bugiem i wyrednerowało się okej. Znaczy oba wyrednerowały się ok. Potem zmieniłem ponownie na oryginalny mesh i znowu czarny plane. Wysyłaj. Działo się trochę ze skalowaniem meshy przy bakeu. To może być powiązane imho.

Pierwszy przykład również z również by zadziałał. Tylko że w takim wypadku wszystko na scenie miałoby tekstury o tej samej rozdzielczości, nie ważne czy to długopis, biurko czy ściana pomieszczenia. Jak robisz jeden konkretny asset to ta metoda sprawdzi się doskonale w takiej formie jak napisałem. Zrobienie czegoś tak złożonego jak bake całej sceny wymaga wszędzie dużo więcej pracy ale nadal da się u mnie to załatwić kilkunastoma klikami. Wszystko załatwiasz w jednym meni u widoku 3d. Powiedzmy że już zaznaczyłeś jakoś wszystkie obiekty do wypalenia (coś co i tak musisz robić w obu metodach). Teraz jak policzę to wychodzi mi dokładnie 12 kliknięć (wliczając kliknięcia w menu i kolejne jako wybranie z nich opcji) oraz wpisanie jednej wartości liczbowej w wielkości tekstury. W tym wszystkim jest zawarte dodanie wszystkich obiektów do bakeu, przypisanie im żeby renderowały combined pass na drugim kanale UV i żeby wielkość map każdego obiektu była dostosowana do jego wielkości w scenie. No i odpalenie bakeu również wliczyłem. Dużo kliknięć? Dla porównania żeby to zrobić obecnie (wliczając zapis pliku który u mnie dzieje się z automatu). Potrzebujesz do tego 3dview, properties, node editora i image editora. Musisz zrobić twardą kopie każdego materiału na wszystkich obiektach, dla każdego wygenerować teksturę o dokładnie ustalonej wielkości w image editorze i dodać ją do nodów. Następnie wypalasz wszystko razem i potem zapisujesz każdy obrazek z osobna. Kilkadziesiąt kliknięć na każdy materiał w każdym obiekcie. Pomijam nawet takie uniedogodnienia jak celowanie z wielkościami tekstur na oko i rozpieprzone materiały przez robienie twardych kopi na każdy obiekt. Przy takiej scenie jak pokazał Floo na tamtym gifie wychodzi ci setki razy więcej kroków niż w mojej metodzie... Duuuuużo kliknięć.

Floo - Niedawno sobie uświadomiłem jedna tragiczną sprawe zwiazana z podglądem tekstur i musze to jeszcze jakoś rozwiazac. Ten bake jest tak absurdalny ze wypalasz mapki nie per obiekt tyko per material na obecnie wypalanym obiekcie... To oznacza ze obecnie jak dodasz image node do materialu ktory jest na kilku obiektach i je wypalasz kolejno to kazdy nastepny obiekt bedzie ci nadpisywal texe w twoim image node... W moim proposalu ten problem nie wystepuje bo bake musi dzialac per obiekt lub grupa obiektow (dlatego tez napisanie zwyklego addona odpada, tu muszą sie odbyc zmiany u podstaw). Prawdziwym problemem jest teraz wyswietlanie wypalonych tekstur na modelach. Selekcja image node dziala per materiał więc nawet jesli umieszcze w każdym materiale kilka image nodow dla każdego targetu to wybierając jedną tekstura bedzie się zmieniala na pozostalych obiektach. Caly ten patent z image node do wybierania obracka to jest chora sprawa i uwstecznienie.

Profeska. Chętnie obejrzałbym pełen metraż.

He he he... Już widzę twoją minę jak to będziesz czytał. :D Musisz odpalić nody materiału. Tam dodać Image Node której nie podłączasz do niczego. W niej wybierasz pusty obrazek o docelowej rozdzielczości texy. Pusty obrazek możesz wygenerować przez image editor ale nie polecam. Będziesz miał potem konflikty jak już zapiszesz (bo blender będzie się odwoływał od "obiektu tekstury" z linkiem do pliku który zapisałeś a nie po prostu pliku). Jak się zdecydujesz na robienie ich w blenderze to uważaj żeby potem nie zmieniać w wygenerowanej texie ani jednej rzeczy. Bez ostrzeżenia wykasuje ci wszystko co wypaliłeś i podmieni na nowo wygenerowany pusty obrazek. Po każdym bakeu musisz koniecznie ręcznie zapisać obrazek na dysku. Spoko workflow. Nie sądzisz? :D

Podkoloryzowałem trochę. To wyredneruje wszystkie obiekty z teksami o takiej samej rozdzielczości i na pierwszym kanale UV który niekoniecznie powinien być tym na którym robimy bake. Ustawienie bejkowania całej sceny nie jest tak trywialne w żadnym bakeu nie licząc tylko silników UE4 i Unity (ale tam z drugiej strony są ograniczone możliwości ustawienia czegokolwiek). Żeby to miało sens to trzeba assety poprzydzielać do bake jobów i potem dostosować rozdziałki w outpucie oraz zdefiniować na którym kanale wypalamy. Można będzie to sobie przyśpieszyć przez ficzer który zwie się u mnie "Transfer Settings Menu". Pod ikonką z zębatką w każdym panelu będą menusy (Transfer Settings Menu) z różnymi dodatkowymi operacjami. Chodzi głównie kopiowanie ustawień pomiędzy jobami, targetami czy sourcami. Ma to działać tak że przykładowo masz wybrany któryś Job to z niego będziesz kopiował konkretne ustawienia na inne Joby. Będzie to spora lista gdzie możesz zaznaczać / odznaczać poszczególne rzeczy. Może działać również z pominięciem nieaktywnych rzeczy, więc jak chcesz zachować ustawienia dla kilku, przykładowo, Targetów to odznaczasz ich ikonki renderowania, kopiujesz co trzeba i zaznaczasz je ponownie. W menusie bake jobowym również będzie opcja żeby dodał wybrane obiekty jako osobne bake joby z od razu przypisanym targetem (jeden target na każdy job) ale to nie będzie raczej najpopularniejszy workflow więc nie chciałem dodawać tej opcji do i tak opasłego interfaceu. Natomiast w panelu Targetów będzie opcja żeby rozbił bake joba z wieloma targetami na osobne joby z pojedyńczymi targetami. Wszystkie inne opcje joba w pozostają takie same. Nie jestem pewien czy ta opcja powinna być w menusach dotyczacych Jobów czy Targetów. Może nawet w obu miejscach? Czyli będą 2 drogi żeby to załatwić takie właśnie wypalanie całej sceny. Opcja A: 1. "Add objects as Bake Jobs with Targets". 2. W zakładce output ustawiasz wielkość texy Joba która według ciebie dobrze bedzie działała dla tego assetu. 3. Definiujesz w tym samym bake jobie który pass chcesz renderować. Tutaj Combined. 4. Z "Jobs Transfer Settings menu" wybierasz żeby skopiował na inne Joby wszystkie ustawienia poza listą bake targetów albo np tylko ustawienia dotyczace outputu i passów. 5. Teraz jeśli chcesz wypalać na innych kanałach UV to w każdym bake targecie każdego bake joba możesz dokładnie zdefiniować na który kanał UV chcesz wypalać (sporo klikania, niestety). 6. Teraz trik: W "Jobs Transfer Settings Menu" odpalasz opcje "Calculate output sizes by Targets geometry Area". Jak się domyślasz to zwiększy lub zmniejszy rozdziałki texów w innych jobach w zależności jaka jest w nich łączna powierzchnia geometrii ich targetów (wszystkich targetów bo job może wypalać ich wiele na raz na pojedynczej teksturze). 7. Bake Ustawianie kanału UV każdemu targetowi z osobna może by trochę uporczywe więc można to zrobić również inną metodą. Opcja B: 1. "Add objects as Targets" 2. Ustawiasz jednemu targetowi kanał UV (po nazwie lub indeksie). 3. Kopujesz przez "Targets Transfer Settings Menu" to ustawienia na inne targety. 4. Ustawiasz w Jobie wielkość mapki i pass Combined. 5. "Split Targets to separate Jobs" 6. "Calculate output sizes by Targets geometry Area" 7. Bake Po przeczytani manuala trudne to nie będzie ale łatwe niestety również. IMHO wypalanie całych scen poza silnikami gier to nie jest coś co robi się często. Pomyślę nad jakąś większą automatyzacją tego kiedyś tam ale nie jest to dla mnie duży priorytet na teraz.

Azbesty- Dokładnie jak piszesz. Podsumujmy: 1. Userzy nie mogą nigdzie wybrać jaką dziedzinę chcą wspierać dotacjami. 2. Na rzeczy związane z filmami animowanymi idzie niemal cała kasa zebrana przez wszystkich userów. W tym ludzi od gameartu ale też archvizu, motion designu i wielu dziedzin innych niż filmy animowane... 3. Na rzeczy związane z gameartem idzie kasa zebrana niemal wyłącznie przez firmy typu Valve, Epic. Jak niby osoby które zajmują się gameartem mają nie narzekać na development i sposób rozdysponowywania ich kasy? -------------------------- Floo- Fajny przykład. Ale współczuje gościowi że musiał pieprzyć się z nodami dla każdego materiału i każdego obiektu z osobna... A u mnie, na defaultowych ustawieniach: 1. Zaznacz wszystko na scenie. 2. Add selected as bake targets. 3. Add pass -> Combined 4. Bake. ;)

Zapieprza ale tylko w kierunku takim jak chce tego Ton. W temacie narzędzi do gameartu rozwija się wolniej niż inne programy. Od lat brakuje podstawowych funkcji. Właśnie zmienia się generacja konsol więc ta przepaść będzie jeszcze większa.

Pewne. Wstępna wersja pie menusów jest już prawie na ukończaniu. Własne menu da się zrobić już teraz za pomocą pythona. Zagnieżdżone pie menusy mojej propozycji możliwe że pojawią się w którymś z nastepnych wydań. Te rzeczy związane z FBXem które są napisane w release notes są prawie gotowe ale jeszcze nie w masterze.

Tenebrael - Grubo przesadzasz. Już teraz w masterze jest kilka dużych usprawnień do nowej wersji a to dopiero zakończyła się pierwsza wstepna faza developingu tejże (BCON1).Poprawione shadery w cyclesie, nowy texture paint, pie menus, freestyle dla cyclesa. Usprawnienia compositora, fbx jeszcze masa bugxifów. Jak tu można pisac o braku nowego contentu. Gałąź 2.7x ma na celu głównie stabilizacje, usprawnienia architektury, dodatkowo workflowu i UI. Nawet jeśli zrobiliby wydanie które składa się wyłacznie z bugfixów i zmian niewidocznych dla userów nadal będą trzymali się ustalonego rok temu celu. Nie wiem czy zajmowałeś się kiedyś programowaniem albo miałeś z programistami do czynienia ale to NIGDY nie jest tak że możesz w pełni określić ile czasu zajmie ci zadanie niepodobne do tych które już robiłeś. Zawsze, nawet w idealnie rozwijanych programach pojawiają się nowe czynniki które trzeba uwzględnić. Jeśli mają przesuwać rzeczy na potem żeby były bardziej dopracowane to ja im kibicuje. Sam prosiłem devów żeby jeszcze nie umieszczali bakeu w 2.71 bo efekty jakie są każdy widzi. Co do rzeczy znikających z krótkoteminowego todo to się zgadzam. To jest mega słabe. Właśnie patrzę że wycieli AO color node które jest rzeczą elementarną przy tworzeniu wielu proceduranych materiałów (cały quixel i substance designer na nim się opierają). To pewnie echa odejścia Brechta, trzeba bedzie zrobić sciepe na kodera który zrobi tego noda i jeszcze Cavity node. ikkiz- Czemu oczekujesz że ktoś ma ci odpowiadać na pytania skoro sam na nie nie odpowiadasz?

Jest kolosalny bo obecny bake / przyszły simple bake mają kolosalne ograniczenia. ;) Wiem że to jest sporo opcji w jednym miejscu (dlatego wymagałoby swojego własnego panelu w properties) jednak to ma być skierowane do profesjonalistów i bardziej wymagających userów. Dla mniej zaawansowanych będzie Simpe bake który będzie tylko trochę rozbudowany względem tego jak wygląda bake obecnie (dodana zakładka output). W advanced wszystkie bardziej zaawansowane rzeczy są pochowane pod chckboxami takimi jak Lighting override (gdzie można sprecyzować oświetlenie tak żeby nie było zależne od włączonych warstw i ustawień sceny). Jeśli ktoś nie ma potrzeby z nich korzystać to nie odpala checkboxa. Pośredniego rozwiązania chciałbym uniknąć bo niebardzo widzę co dałoby się wyciąć z trybu advanced żeby nadal był przydatny przy normalnej pracy. Dodatkowo robienie go byłoby dodatkową komplikacją dla mnie, dla koderów i końcowo dla osób które docelowo chcą się nauczyć bakeu assetów na poziomie produkcyjnym.

Po kilku dniach dostałem częściową odpowiedź. Nie od Dalai ale dzięki Tonowi. ;) Nie mam pojęcia dlaczego to musiało pójść przez górę a zwykli userzy byli przez Dalai zlewani przez parę miesięcy. Tymczasem obrazki z mojego proposala: Idea jest taka że jak ktoś potrzebuje bardziej zaawanswoanych opcji to (jak np bake sekwencji map albo customowa nazwa mapek w tym co pokazałem) to odpala do tego checkboxa. Jak ktoś pozna podstawy działania to wypalenie jednego assetu który ma już materiał zajmuje mniej kliknięci niż myki związane z odkrywaniem/ ukrywaniem warstw podczas selekcji obiektów przy bakeu z "selected to active". Im więcej ktoś chce wypalić rzeczy tym mniej kroków mu potrzeba żeby to zrobić w stosunku do tego co jest obecnie. No i wszystkie ustawienia zapisują się gdzie trzeba, jak ktoś specyzuje ustawienia światła to nie ma bata żeby przez omyłkowe wyłączenie warstwy coś się nie wyrenderowało tak jak tego chce.

Rice- Gruba przesada z tym niedorobionym xnormalem. Obecnie bake z cagem w cyclesie daje bardziej poprawne rezultaty niż xNormal! Co do sculptu w blendku. On jest świetny w porównaniu do innych ogólnych pakietów 3d. Ale jest słaby w porównaniu do softów wyspecjalizowanych (ZB, Mud, Coat). Ja jako osoba która zna obsługę zbrusha (nie mylić z umiejętnościami rzeźbiarskimi) na poziomie bardzo zaawansowanym nie widzę żadnego celu w przesiadce na blendera. Wiele rzeczy które są w moim standardowmym workflow pracy w zecie po prostu nie istnieją w blenderze więc dla mnie to byłby regres.

Natychmiast mówisz? Próby wyduszenia od Dalai roadmapy dotyczącej bakeu trwają już od jakiś 2 miesięcy (wtedy kiedy jego kod pojawił się w masterze). Pytało wiele osób, nie tylko ja. Na początku pisał że nie ma żadnej oficjalnej roadmapy, potem już tylko ignorował wszystkich. Zadałem mu pytanie wprost przez PM na BA i od już prawie 4 dni nie odpisuje. Mamy inną definicje słowa "natychmiast". Nigdzie nie napisałem że nie podoba mi się cały obecny development blendera, jest wiele świetnych projektów które się teraz dzieją i którym kibicuje. Ja tylko odniosłem się do tego co dotyczy mnie czyli bakeu. Nie masz pełnego obrazu jak wyglądało finansowanie przez Valve i jakie były plany dotyczące bakeu. Dalai oraz Campbell miały być osobami które przeprowadzą pełny refaktoring bakeu w blenderze (cycles potem internal oraz inne kompatybilne z blenderem renderery obsługujące bake). Kontrakt z Valve miał być tego początkiem i jak widzisz na chwile obecna nie wywiązali się nawet z części obietnic. Nie naprawili workflowu w internalu, cycles bake jest niedokończony, o innych rendererach nie ma mowy. Ale to mnie nie boli. Wiem że do tego po prostu potrzeba więcej czasu. To co mnie boli to to że na dzień dzisiejszy nie ma żadnych planów i ustaleń co, kiedy i czy w ogóle będzie jeszcze z bakiem robione. Na narzekania testerów sam Dalai odpowiadał kilkukrotnie że czekają na konkretny i całościowy proposal jak miałby wyglądać workflow i wszystko od strony UI. Więc zabrałem się za to. Przez ostatnie kilka miesięcy poświęciłem grubo ponad 200 godzin pracy na rzeczy związane z bakeowaniem. Pierwszy proposal od paru miesięcy na wiki blendera, drugi który teraz kończę, mam za sobą większą część testów i notatek do trzeciego który dopiero jest w planach. Moje propozycje to nie jest wishlista bajerów które niewiadomo jak zaimplementować, jak to do tej pory pisali testerzy na BA. Opierałem się na istniejącej architekturze blendera, musiałem poznać wiele zakamarków o których większość userów nigdy nie miało pojęcia, nauczyłem się pythona i pisania GUI żeby dać developerom od razu gotowe rozwiązania. Musiałem poznać workflowy kilku innych softów oraz 2 niespójne ze sobą workflowy bakeu w blenderze (cycles vs internal). To była i będzie jeszcze masa roboty. Jeśli goście mi napiszą "Teraz przez x miesięcy Dalai będzie zajmował się czymś innym a potem wraca do bakeu i będzie robił to to i tamto" to ja będę w pełni ukontentowany. Skończę oba nowe proposale i będę uczestniczył w testowaniu gdy / jeśli będą implementowane. Natomiast jeśli moja kolejna próba dowiedzenia się na czym to wszystko stoi sczeźnie na niczym to ja się wycofuje bo po prostu nie widzę sensu poświęcać kolejnych 100+ godzin pracy na coś co prawdopodobnie nigdy nie powstanie dlatego że developerzy nie uważają tego za potrzebne. Zdecydowałbyś się przez kilka miesięcy poświecić każdą chwilę wolnego czasu na coś co pójdzie do kosza?

Od 2 dni próbuje się skontaktować z Dalai żeby się określił w temacie Bakeu, cokolwiek. Gość mnie zupełnie ignoruje, nic nie odpisuje a był na BA w tym czasie, pisał na mailing listach i w dokumencie o kamerze stereo. Jutro napiszę na listach funboard, gamedev i commiters i jak nie uzyskam przez tydzień odpowiedzi to kładę laskę na to wszystko. Zmarnowałem wystarczająco dużo czasu. Jak devsi twierdzą że poradzą sobie sami ze wszystkim bez udziału community to niech tak robią.

Dla kogoś kto ma niskie wymagania i brak porównania to możne tak wyglądać. Na szczęście niewiedza nie jest argumentem.

https://docs.google.com/document/d/1bX_69zbZ9KJCozmiQMD-FSwvMXyJEqChSlSRLiUU0As/edit?hl=pl&forcehl=1#heading=h.pvbmks2phm2h Wali mnie jak będzie wyglądała ta kamera stereo w blenderze. Pewne jest to że cały development Bakeu ze strony Dalai będzie zastopowany na 6 do 8 miesięcy... Spieprzony do granic możliwości workflow. Brak podstawowych passów jak heightmap, metallicity. Niepoprawne wypalanie większości nodów OSL, Brak AA, brak wypalania na GPU, fatalna wydajność i niestabilność, brak updateu tektury w widoku 2d, niedziałający pasek postępu. Niech ktokolwiek mi teraz napisze jak to blender jest świetnie rozwijany. FUUUUUCK!

http://www.blendernation.com/2014/07/11/blender-sighting-evolve/ Blender jako tool do 3Dprintu figurek z Evolve. :)