Skocz do zawartości

Bake Management Proposal - Proszę o feedback.


Monio

Rekomendowane odpowiedzi

Pewnie wielu z was już wie że od kilku miesięcy zajmuje się propozycją przeprojektowania systemu bakeu tekstur w blenderze. Projekt jest już na finiszu, mam skrypt pythona który udaje jak mógłby wyglądać nowy interface oraz spisaną część teoretyczną w której omówiłem problemy wynikające z obecnego rozwiązania i metody ich naprawienia. Dwa tysiące linni kodu i kilka tłustych stron maszynopisu. ;) To co obecnie robię to opis samego interfaceu czyli za co odpowiadają poszczególne panele i do czego służą guziki. To co trzeba będzie zrobić w późniejszej kolejności to sekcja z pytaniami czyli FAQ.

 

I tutaj muszę się zgłosić do was o pomoc. :) Starałem się projektować ten interface tak żeby był w miarę możliwości przejrzysty i nie wymagający wyjaśniania. Łatwo jednak stracić ogląd na takie aspekty jeśli przez pół roku się coś samemu projektuje.

Zrobimy tak- Umieszczę tutaj minimum informacji z mojego proposala które wyjaśnią kluczowe rzeczy i pozostawię wam resztę jako zagadkę. Pobawcie się tymi guzikami, uwzględnijcie nazwy opcji, układ, zależności pomiędzy różnymi opcjami. Zależy mi na tym żeby pojawiło się tutaj wiele pytań na które będę mógł umieścić w FAQu żeby proposal był jasny dla każdego. Pytajcie o wszystko co jest dla was niejasne.

 

DOWNLOAD:

https://www.dropbox.com/s/dgnjoch8b4cax0t/GUI_MOCKUP.zip

Po ściągnięciu i odpakowaniu zipa odpal blendera i wciśnij CTR+ALT+U żeby uruchomić User Preferences. Włącz zakładkę addons, kliknij na "Instal From File" i wybierz plik GUI_MOCKUP.py z miejsca w którym go rozpakowałeś. Teraz wpisz "mockup" w wyszukiwarce z lewej i uruchom addon "BAKE MANAGEMENT GUI MOCKUP". Następnie przeczytaj 3 poniższe cytaty z mojego proposalu.

 

4v88q6Z.png

Interface bez włączonych dodatkowych opcji.

http://i.imgur.com/4v88q6Z.png

 

- Batch bake czyli Bake joby.

System powinien mieć możliwość ustalenia kolejki bakeowania w taki sposób żeby wszystkie joby mogły mieć swoje własne ustawienia. Do dyspozycji użytkownika powinniśmy dać możliwość kopiowania bake joba ze wszystkimi jego ustawieniami oraz przenoszenia wybranych ustawię pomiędzy jobami. To umożliwi artystom prace nad wieloma assetami w jednym pliku blend lub tworzeniu wielu wersji jednego assetu poprzez skopiowanie go i zmienienie ustawień joba. Dzięki przenoszeniu ustawień użytkownik może je wykorzystać do wypalenia tekstur na różnych assetach co korzystnie wpłynie na spójność grafiki.

 

- Definiowanie które obiekty maja się wypalać czyli Bake Targets i Bake Sources.

Upraszczając- Bake Targets to lista obiektów lowpoly a Bake Sources to lista siatek hipoly.

Obiekty wykorzystywane do bakeu powinny mieć swoje miejsce w interface w formie list obiektów oraz przypisanych do nich ustawień bakeowania. Oczywiście listy te powinny być zapisywane w pliku blend. Raz zdefiniowane listy można edytować dodając lub odejmując z nich obiekty ze sceny oraz modyfikując ich ustawienia.

Uściślając- Targety i Source są przypisane do pojedynczego Bake Joba. Pojedyńczy Target lub Source to item w liscie który zawiera w sobie link do obiektu lub grupy obiektów ze sceny oraz własne ustawienia dotyczące bakeu.

Rozwiązanie takie ma wiele zalet. User nie musi przeskakiwać po rożnych panelach properties żeby zmienić ustawienia bakeowania obiektu, wszystkie te ustawienia znajdują się w Bake properties. Jeden obiekt może być wielokrotnie wykorzystany w rożnych Bake Jobach jako Target lub Source i w każdym z nich może posiadać zupełnie różne ustawienia.

Warto dodać w tym miejscu że raz dodany do Targetów lub Sourców obiekt nie powinien móc być dodany ponownie do tego samego Joba bo może to tworzyć problemy z wypalaniem.

 

Mockup który stworzyłem pomoże zrozumieć innym sposób działania nowego bakeu, zobaczyć zależności pomiędzy rożnymi opcjami. Skrypt instaluje się jako addon, potem wszystkie elementy interfaceu są widoczne w Scene Properties. To oczywiście tymczasowe miejsce bo nie można na chwilę obecna tworzyć nowych menu w Properties za pomocą pythona. Gdy bake zacznie być implementowany powinien dostać własne okno w Properties. Gdy zainstalujesz addon i go uruchomisz zamknij wszystkie zakładki należące do panelu Scene i przenieś je na dół. Żeby mockup działał poprawnie musisz miedz zaznaczony jakiś obiekt z siatką!

 

Musze w tym miejscu dodać czym nie jest ten addon:

- Kod który napisałem nie służy w żaden sposób do uruchamiania bakeu. Powstał tylko dla celów poglądowych i jako miejsce dla moich testów. Nie ma funkcji praktycznej tylko informacyjną.

- Przerobienie tego kodu na działający addon do bakeu nie jest możliwe bo propozycje które zawarłem w moim proposalu wymagają zmian w kodzie bakeu oraz api żeby system działał jak należy.

- Nie jestem programistą i nie mam dużego doświadczenia w pythonie. Wiele elementów tego gui nie działa tak jak powinna działać w zaimplementowanym finalnie bakeu. Starałem się najprostszymi możliwymi metodami przedstawić mój pomysł.

- Ikony powinny zostać zmienione. Musimy przygotować zestaw ikon dla nowych elementów blendera takich jak joby, source, targety. Sam bake powinien dostać dedykowaną ikone która wyświetli się w zakładce w properties.

 

Co działa inaczej niż powinno:

- Na chwile obecną listy jobs, source i target wyświetlają rzeczy z render layers i danych siatki zaznaczonego obiektu. Dlatego żeby pobawić się z tym interfacem musisz mieć zaznaczony obiekt. Nie potrafię jeszcze sam tworzyć takich list więc napisałem odwołanie do tych istniejących w blenderze. ;) Oczywiście docelowo w tych listach powinny znajdować się zupełnie nowe typy danych zgodne ze strukturą którą opisałem w jednym z wcześniejszych działów.

- Opcje widoczne w interface są przypisane globalnie a powinny być przypisane do nowych typow danych. W prawdziwym bakeu gdy wybierzesz z listy danego joba, sourcea lub targeta interface pokażą ci opcje które są przypisane tylko do niego. Tak samo jak to ma miejsce z innymi miejscami w blenderze gdzie występują listy.

 

Słowem podsumowania- Nie traktuj tego skryptu jako wierne odwzorowanie tego jak powinien działać finalny bake. Zwróć uwagę na opcje które zawarłem, zobacz jak rozplanowałem układ interfaceu. Pobaw się opcjami i zobacz jakie są pomiędzy nimi zależności. Zwróć uwagę jak zmienia się interface gdy wybierasz pomiędzy trybami bakeu Direct a From Source, zobacz jakie opcje ma wypalanie na teksturę a jakie na vertex color. Popatrz co znajduje się w wyskakujących menu gdy klikniesz na ikony z zębatkami przy listach obiektów. etc. Milej zabawy! :)

 

Dzięki za uwagę. :)

 

Włączona większość dodatkowych opcji oraz pokazane menusy które wyświetlają się pod ikonami z zębatkami.

http://i.imgur.com/zKDEige.png

zKDEige.png

 

 

Edit1: Dodałem parę opisów i obrazki

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

  • Odpowiedzi 19
  • Created
  • Ostatniej odpowiedzi

Top Posters In This Topic

boshe ależ tych opcji napierdzieliłeś ;P jakby ktos z devów sie za to wziął to byłoby cudownie, daj link do wątku blenderartist to bedziemy tam spamować i podbijac temat ;)

 

do map sizes mogles porobic guziczki oprócz wpisywania wielkosci tekstury, takie mini presety 512/1024 itd.

Odnośnik do komentarza
Udostępnij na innych stronach

boshe ależ tych opcji napierdzieliłeś

Potraktuje to jako pytanie które już wcześniej spisałem. ;D

 

Q: Wydaje mi się że twoje rozwiązanie jest zbyt skomplikowane. Obecny bake zawiera tylko kilka buttonów i działa. Jest prosty. Dlaczego twoje rozwiązanie zawiera tak wiele paneli i opcji?

 

A: Obecne rozwiązanie niestety nie jest proste tylko prymitywne. Od dawna wiele osób narzekało że wypalanie w blenderze posiada wiele podstawowych braków. Mój bake menagement zawiera dużo opcji jednak jeśli porównasz go do profesjonalnych (fully-featured) programów do bakeu, takich jak xNormal, to zauważysz że nie ma tych opcji za dużo. Próba upraszczania tego narzędzia będzie równała się z wycinaniem kolejnych funkcji które są potrzebne w codziennej pracy osoby która zajmuje się bakiem.

 

daj link do wątku blenderartist to bedziemy tam spamować i podbijac temat ;)
To dopiero jak dokończę proposal. Chce uniknąć przedstawiania czegoś niedokończonego albo sutuacji gdzie jakiś domorosły klepacz pythona przerobi to w addon o niepełnej funkcjonalności. Trzeba zmian w samym kodzie bakeu i api. Nie ma jeszcze żadnej optymalizacji związanej z wypalaniem wielu lowpoly czy wielu passów. Bardzo łatwo by było ustawić bake który będzie trwał 20 razy dłużej niż powinien.

 

Rozważę te presety wielkości. Początkowo suwak size w Square map miał ustawiać power of two ale nie umiałem tego wtedy zakodzić i odpuściłem. Tak by było lepiej? Żadko spotyka się mapki np 3k a jak user będzie chciał to ustawi taką wybierjąc opcje Exact size.

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

CgBartosz- W pierwszym poście wrzuciłem na dole 2 obrazki. Jednak polecam się pobawić jak będziesz miał dostęp do blendka, cały myk to zależności pomiędzy opcjami.

 

Dzięki za feedback. Jak ktoś zgadnie o co biega z tą kropką przy guzikach "Show xyz Options" to stawiam mu browara. ;P Jeszcze nie za wiele wyjaśniał bo zależy mi na pytaniach. Jakoś pod koniec przyszłego tygodnia umieszczę tutaj cały proposal po polsku.

Odnośnik do komentarza
Udostępnij na innych stronach

Hmm. Zastanawiam sie czy nie zadajecie pytań dlatego ze przegiąłem z komplikacją wszystkiego i nie wiecie w ogole o co biega czy dlatego ze wszystko jest tak jasne. Pls, możecie sie do tego ustosunkowac? Przyjmijcie sobie jakis scenariusz bakeu i zobaczcie czy wiecie jak go ustawić w takim interface.

Moze coś takiego, jak ustawilibyscie krok po kroku taki bake:

A. Macie jakiś zestaw hipoly. 3 lowpoly z czego 2 maja byc wypalone na jedna texe 2k a jeden obiekt ma miec osobna texe 512.

B. Macie material ladnego metalu i zniszczonego metalu. Korzystacie z direct bake. Jak w najmniejszej liczbie krokow wypalic asset w 2 wersjach?

 

----------------

Floo- Chodzi ci o preset calego bake joba tylko bez sourceow i targetow? Nie planowalem tego ale bardzo latwo bedzie do tego zrobic addon jesli devsi poprawnie rozplanuja api (będę nad tym czuwal). Moze jeszcze rozważe dodanie tego w standardzie ale na razie wole to skonczyc i zaprezentować to co mam. Za 3 tygodnie zamyka sie bcon1 gdzie decyduja co ma byc w nastepnej wersji blendka.

 

N-pidgeon- Mialem takie coś w poprzednim proposalu. W passach to sie nazywa custom output. Jednak nie mam mozliwosci tego zakodzic bo musialbym ingerowac z nody a na tym sie jeszcze nie znam. Opisze to teksotwo w proposalu a jak nie starczy czasu opisze to pobierznie i potem zrobie mini proposal z dokladnym wyjasnieniem. Sprawa jest dosyc skomplikowana jak na to szerzej spojrzeć.

Odnośnik do komentarza
Udostępnij na innych stronach

Rice- Bingo. Options indicator ma służyć do powiadomienia usera czy uruchomione są jakies dodatkowe opcje. Ważne dlatego ze okno z opcjami można zwinąć zeby nie zaśmiecało interfaceu jak juz ustawimy wszystko co chcemy.

Zrobiłem wczoraj ustawianie rozmiaru texy w Square map za pomocą power of two. Ustawia sie ikonkami z plusem i minusem, pomiedzy nimi jest napisana wielkosc texy. Musze jeszcze poeksperymenowac z wyswietleniem tego, blenderowy suwak odpada. Jak dodaje zwykly tekst to guziki do okola sie paskudnie rysują, nie stykaja sie ze sobą poprawnie. Na razie mam hack ze jest tam guzik ktory nic nie robi i wielkosc texy rysuje sie w jego nazwie. Zrobie update jak przyjade do pracy.

Odnośnik do komentarza
Udostępnij na innych stronach

Monio z mojej strony, to najbardziej zależy mi na tym aby móc zapisać wszystkie ustawienia. Jeśli pracuje się w kilka osób, czy nad kilkoma rzeczami, to znacznie przyśpiesza pracę i eliminuje pomyłki.

Co do sugestii, to proponuje przestawić wszystko w formie video + soczysty opis z komentarzem. Chodź mi tutaj o to aby ogrom opcji jaki jest dostępny, nie stał się zbyt przytłaczający. Prezentacje uważam za konieczną. Nawet jeżeli zrobiłbyś ją po polsku z napisami, to naprawdę warto. Łatwiej będzie zachęcić tłumacząc kolejno co i jak.

Sam Propsal jest przemyślany i widać że wiesz co chcesz zrobić. Pozostaje mi pogratulować świetnej roboty i trzymam kciuki, aby udało się łatwo przeforsować propozycje. Jedynie czego się obawiam to, że będzie dużo gadania z drugiej strony, na zasadzie, co zmienić, dodać od siebie i energia pójdzie w piach.

To narzędzie musi być spójne i nie daj sobie narzucić zmian, bo rozleci się koncepcja, a wtedy trudniej skończyć. Tego najbardziej nie lubię w Blenderze, że na gadanie o rzeczach oczywistych traci się na tak wiele czasu.

Odnośnik do komentarza
Udostępnij na innych stronach

Odpaliłem skrypt.

Dla mnie przekopanie a raczej przeskrolowanie się przez zakładkę scene jest teraz trudne...

Proponuję zacząć od umiejscowienia bake w interface... Czemu nie dodać zakładki obok render, zakładki bake...

Skoro to tak bogaty temat to zasługuje na osobną zakładkę. Od dawna w blenderze irytuje mnie brak takiej zakładki a szukanie bake z internala w zakładce render...

 

Super ilość opcji i interakcji... imo często chcę zrobić szybki bake jednego obiektu... wtedy zaczyna mnie przerastać ilość opcji. Przydałby się jeszcze jeden poziom interakcji .. taki najprostszy... Dążyłbym do tego w ten sposób:

 

Panel Bake jobs zmieniłbym w podstawowy "bake" w nim pierwsza opcja to switcher pomiędzy "simple bake", "advance/ multiple bakes".

Albo ptaszek "multiple bakes", taki jak w modify baking pipeline.

Kiedy tryb simple, mamy szybki prosty bake, kiedy advanced, odpalony widzimy wszystkie opcje kolejkowania oraz przyciski bake all i bake selected.

 

Bardzo podoba mi się modify baking pipeline i naming convention i sposób interakcji, niemniej w opcji simple mogłoby być to wszystko nie widoczne i cała zakładka bake mieściłaby się bez scrollowania...

 

Ukłon w stronę devów którzy szukają zmniejszenia ilości scrollingu... Dodatkowo mniej zaawasowani użytkownicy nie byli by przerażeni :)

W opcji simple nie ustalałoby się kilku pasów bakeowania a wybierało jeden- domyślnie combined. A bake preview options w opcji simple byloby zbędne...

 

Kwestia czy robić na zasadzie advanced=multiple czy multiple jako dodtkowy ptaszek to juz inna kwestia i pozostawiam do przemyślenia Tobie.

 

Dodatkowo proponuję zasugerować devom by domyślnie każdy obiekt który mapujemy otrzymywał uvMap oraz bake slot pusty.. .Tak o żeby potem nie musieć wracać i nazywać wszystkiego... Chyba że mi umknęło jak to zrobić...

 

Tak ja to widzę*ale to tylko spostrzeżenia, generalnie w porównaniu do stanu obecnego i do bake tools 1.2 wypada powiedzieć SZACUN!

Odnośnik do komentarza
Udostępnij na innych stronach

Nie miałem jeszcze czasu, żeby tak na serio spojrzeć na ten proposal, ale zdecydowanie zgadzam się osobami wyżej - potrzebna jest opcja "simple bake", bo ten projekt jest niesamowicie zaawansowany - na tyle, że wymagałby nawet swojej osobnego panelu, a nie tylko zakładki w "Render".

Odnośnik do komentarza
Udostępnij na innych stronach

Przeczytajcie dokładnie trzeci cytat z mojego pierwszego posta w tym temacie. Osobne okno bakeu w properties było pierwszą rzeczą od której zacząłem design.

 

Dodatkowo przeczytajcie to:

- Nowa zakładka BAKE w properties

Jeśli uważnie przeczytałeś wstęp to wiesz już ze baking ma kluczowe znaczenie dla pewnej dużej grupy użytkowników blendera. Ponieważ w pełni funkcjonalny bake składa się na wiele opcji i rozbudowane UI oraz nie jest ścisłe powiązany z istniejącymi zakładkami w properties powinien dostać własną zakładkę. Jeśli zobaczysz moje mockupy interfaceu to zauważysz ze ilość rzeczy które w sobie zawierają jest dosyć obszerna. Jednak jeśli orientujesz się w tematyce bakeu tekstur to przyznasz mi racje ze nie ma tam niepotrzebnych dodatków o nikłym zastosowaniu. Dodatkowe opcje są ukryte w zwijanych okienkach i nie zajmują dużo miejsca. Dalsze upraszczanie tego interfaceu raczej nie wchodzi w grę bo będzie się to wiązało z wycinaniem podstawowych funkcjonalności co sprawi ze narzędzia będą niekompletne i nie będą w pełni nadawały się do pracy.

Bake korzysta z kodu renderowania jednak metodyka pracy z nim znacznie rożni się od ustawiania opcji renderu. Rozdzielając Render Properties od Bake properties uzyskami większą klarowność w obu tych zakładkach. Podobna sytuacja kiedyś spotkała Render Layers które dostały własną zakładkę, uważam że to świetny moment żeby również bake zyskał należyte miejsce w interface blendera.

 

Zgadzam się z wami ze ten interface jest bardzo obszerny ale niestety nie widzę już możliwości upraszczania go bez wycinania podstawowych funkcjonalności. Wypalanie wielu tekstur na raz to absolutny standard. Nawet jak teksturowanie ma się odbywać w innym programie to i tak potrzebna jest normalka + AO. Wypalanie wielu lowpoly to obecnie tez sprawa konieczna bo obiekty w nowych grach często korzystając z wielu meshy.

 

U mnie działa to tak ze jeden Job to renderowanie jednego lub wielu lowpoly do wielu tekstur o danych rozmiarach lub jednej połączonej texy o tych wymiarach gdy uruchomimy opcje Combined Maps w Modify Baking Pipeline. Jeśli chcemy wypalić kilka lowpoly o rożnych rozmiarach tekstur to korzystamy z wielu Jobow w których zmieniamy wielkość texy w outpucie. Oczwiscie możemy dwoma klikami zrobić kopie Joba żeby wszystko się zgadzało i wtedy wykasować / wyłączyć widoczność wybranych Targetow w danych Jobach.

To wszystko jest bazowane na xNormalu tylko że zamiast manualnej roboty ze zmienianiem rozdziałki jest to u mnie zautomatyzowane za pomocą Jobów.

Postarajcie się porównywać mój bake właśnie do xNormala a nie do starego blenderowego bakeu który był bardzo ograniczony i wymagał piekielnie dużo manualnej roboty.

Weźcie pod uwagę że docelowo bake w blenderze będzie bardziej zaawansowany niż sam xNormal. Będzie mógł służyć do (proceduralnego) teksturowania, stąd właśnie w paru miejscach są opcje związane z materiałami i UV z których po prostu nie ma szans rezygnować w imię łatwiejszej obsługi.

To co zrobiłem żeby było łatwiej/ czytelniej to ukrycie wszystkich zaawansowanych opcji w zwijanych oknach. Trudno mi jeszcze bardziej ukrywać rzeczy bo to co zostało to imho podstawy.

 

---------------

Na początku planowałem żeby podzielić bake na tryb simple i advanced ale pomysł odpadł z kilku przyczyn. Po pierwsze wymagało to zrobienia 2 niezależnych systemów bakeu i 2 innych api. Będąc w simple nie dałoby się odwołać do rzeczy które są w advanced i na odwrót. Druga sprawa to to ze całościowo system nie zyskałby na czytelnosci, userzy mogliby pogubić się po co są te 2 tryby i dlaczego ze soba nie współpracują.

Prawdopodobnie ludzie prosiliby żeby dodawać do simple opcje z advanced i upraszczać samo advanced żeby bardziej przypominał simple.

Można teoretycznie by to rozwiązać ze simple jest nakładka na advanced ale tutaj kolejny problem. Przejście z simple do advanced dawałoby takie same rezultaty w bakeu ale w druga stronę już kompletnie nie. Jak wytłumaczyć userowi dlaczego jego obiekty renderuja sie źle jeśli przeskoczył na chwile do simple żeby coś przetestować?

 

Jak developerzy zabiorą się za pisanie nowego API to będę w stanie w ciągu paru dni napisać addon który bedzie symulował działanie starego bakeu. To będzie coś w stylu tej nakładki na advanced tylko że bez robienia dodatkowego zamieszania w podstawowych narzędziach i z dodanym sprawdzaniem poprawności ustawień poza wiedzą usera.

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

Wygląda nieźle, wszystko co bym chciał żeby było jest, nawet parę rzeczy o których na razie można tylko marzyć jak od razu bakowanie map albedo, spec itd. Swoją drogą jak to akurat ma działać? Robisz materiał w cycles na hp używając nodów i potem bakując automatycznie tworzy te mapy? Czy ktoś się zabrał za coś takiego już, żeby było to w ogóle możliwe?

 

Co do samego interfejsu to nie wydaje mi się że można go za bardzo uprościć. Jak chcesz easy mode to patrzysz tylko na targets, sources i output, dużo prościej być nie może bez ograniczania możliwości.

Odnośnik do komentarza
Udostępnij na innych stronach

Monio pamiętaj żeby tak samo wytłumaczyć to na BA czy gdzie tam się z dev i userami będziesz kontaktował. Już na samym początku podejrzewam że część ludzi podniesie larum że za skomplikowane że chcą to wszytko co oferujesz ale za "magicznym" naciśnięciem jednego przycisku. Grunt żeby dobrze to argumentować i wyjaśniać, tłumaczyć - jedyny sposób żeby to przeszło.

Kibicuję i trzymam kciuki.

Odnośnik do komentarza
Udostępnij na innych stronach

Hej. Nie wyrobiłem się z moim personalnym deadlinem. Początkiem bcon1 wersji 2.73. To oznacza że będę musiał zastopować robotę nad tym proposalem na kolejne 4 tygodnie na rzecz robienia mojego folio.

 

Ostatnio na blogu gooseberry pojawiło się info o priorytetach projektów w blenderze. Developerzy będą musieli radykalnie spiąć tyłki przy dwóch nastepnych wydaniach i prawdopodobnie nie będa mieli czasu na tak duże poprawki przy bakeu. Nowy deadline na mój proposal to 30 listopada. Do tego czasu opublikuje skończony proposal na blender wiki i rozpocznę dyskusję. Nie zależy mi żeby te zmiany pojawiły się ekspresowo w masterze, zalezy mi żeby zostały wykonane prawidłowo i bez półśrodków.

 

Wziąłem wasze opinie pod uwagę i pozmieniałem trochę rzeczy. Interface jest teraz troszeczkę odchudzony, bardziej klarowny. Najważniejsze ustawienia bakeu znajdują się teraz w panelu bake jobs. Te ustawienia są nadrzędne i modyfikują workflow oraz wygląd pozostałych paneli, dlatego lepiej żeby user mógł je określić od razu a nie szukać w różnych panelach.

Trybu simple nie bedzie. Wycinanie podstawowych rzeczy lub tworzenie 2 niezależnych systemów to zła droga. Pozostawiam takie "przyśpieszacze" skrypterom. Przykładowo gościowi od BakeToola, żeby mógł zachować obecny (czyli również ograniczony) zestaw ficzerów swojego addona.

 

Zrobiłem sporą zmianę designową w workflow. Teraz pojedynczy Bake Job będzie miał możliwość wypalania tekstur o rożnych rozmiarach dla każdego lowpoly z osobna. Nie wiem dlaczego wcześniej ukryłem opcje Combined Maps w dodatkowych ustawieniach, to definiuje bardzo dużą część workflow. To była zła decyzja. ;) Przeniosłem ją do głównych ustawień Bake Joba. Teraz gdy będziemy z niej korzystać wielkość tekstury ustawia się w panelu Output. Gdy wybierzemy opcje Separate maps ustawimy wielkość tekstur w panelu Target, dla każdego lowpoly z osobna.

 

Teraz wygląda to tak:

7e8N6qr.png

 

Nowa wesja mockupu GUI do pobrania tutaj:

https://www.dropbox.com/s/dgnjoch8b4cax0t/GUI_MOCKUP.zip

 

Przetestujcie i powiedzcie czy jest lepiej.

 

Miniukov- Wypalanie metallicity pokazałem jako przykład. Sam menagement nie zapewni takiej możliwości. Potrzebny by był ubershader w cyclesie który ma w sobie zmienną metallicity. Będę to kiedyś proponował ale na razie nie mam czasu.

 

Idaho- Pewnie że wszystko pisze. Mój proposal nie sam skrypt w pythonie, jego główna cześć to wiele około 25 stron dokumentacji technicznej. Starałem się żeby to było skondensowane jak się da. Na razie tłumaczenie 15% z tego co jest zajęło mi i mojej dziewczynie ponad 5 godzin. Po przetłumaczeniu jeszcze parę dni roboty z formatowaniem w wiki i przygotowywaniem ilustracji. Taka jest skala tego projektu.

Edytowane przez Monio
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