Skocz do zawartości

Blender - NEWS oraz dyskusje


n-pigeon

Rekomendowane odpowiedzi

@Monio

 

W takim razie to świetne info :) Mam nadzieję, że w przyszłości dorzuca opcję tworzenia własnych menu z pominięciem pythona, w User Preferences ustawiając z listy funkcje do wyświetlenia w menusach. Ale jak na razie to co jest musi starczyć, dobrze, że prace są zaawansowane w tej materii.

Odnośnik do komentarza
Udostępnij na innych stronach

No sory very , ale przecież co by nie marudzić blender rozwija sie jak rakieta ;) Wystarczy zlukac na ilość zmian w Modo 701 a 801 i porównać do tego co sie dzieje z blederze w podobnym przedziale czasowym. Głośne "WTF" gwarantowane

Odnośnik do komentarza
Udostępnij na innych stronach

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.

Odnośnik do komentarza
Udostępnij na innych stronach

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.

 

i właśnie tutaj jest cało sedno. ktoś tam pisał że userzy nagle zaczeli narzekać że blender się nie rozwija. Blender się rozwija dalej w takim tempie nawet i szybszym problemem jest. Jaki ficzery są wymyślane kosztem innych. I sytuacja wygląda tak że ostatnio rynek game dev. wyłożył sporą kasę na blendera i wyraził spore zainteresowanie. Fajnie że TON wywiązał się z umowy, ale samo wywiązanie się z umowy to trochę za mało, widząc że jest zainteresowanie i ogromne wsparcie powinien to ciągnąć i pokazać iż słucha rynku tymczasem Ton odbił w ficzersy, takie które nie wiem kto używa...

 

Bo... 3D stereo potrzebne jest komu?

 

game dev. nope

archwiz. nope

reklamy. yyy nope.

stille reklamowe. yyy nope.

 

za górami za lasami ktoś słyszał że ktoś robi film w 3D w blenderze. liczba użytkowników bliska 0. YES!

Odnośnik do komentarza
Udostępnij na innych stronach

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.

;)

Odnośnik do komentarza
Udostępnij na innych stronach

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.

Odnośnik do komentarza
Udostępnij na innych stronach

@floo

 

Kpisz, częściowo słusznie, ale jeśli przeanalizujesz, do czego służy soft, to wychodzi, że ma on służyć jako pomost między wyobraźnią usera a gotowym produktem. Im szybciej, prościej,. w mniejszej liczbie kroków da się ten efekt osiągnąć, tym lepiej. Z jednej strony one-click button to nie rozwiązanie nigdy, bo ogranicza Twoje możliwości. Z drugiej z kolei strony ograniczenie klików do minimum (np. poprzez pozwolenie userowi na zachowanie raz zdefiniowanych ustawień i wykorzystywania ich w kolejnych projektach bez mozolnego ustawiania) to ostateczny cel dobrze zaprojektowanego UI.

 

Stąd np. tak psioczę na to, że wciąż odwlekają wprowadzenie ubershadera, dodawanie wcześniej stworzonych w Cycles materiałów do stałej biblioteki (bez linkowania, zaśmiecania sobie dysku plikami .blend itp) czy innych podobnych opcji. Fakt, nie rozszerza to funkcjonalności softu sensu stricte, ale znacznie przyspiesza działanie w sytuacji, gdy danego schematu używasz wielokrotnie. A że tworzenie grafiki to w dużej mierze sztuka iteracji - powtarzania i odpowiedniego komponowania utartych już schematów, więc takie funkcje byłyby nieocenione. Stąd też ten cały mój rancik na obecny stan rzeczy i fakt, że tego typu usprawnienia są często spychane na dalszy plan ze względu na to, że "jedynie ułatwiają pracę, a nic nie dodają nowego". O jakości softu świadczy imho nie tylko liczba dostepnych funkcji, ale też wygoda ich stosowania.

Odnośnik do komentarza
Udostępnij na innych stronach

@Monio Translate and send. :)

@Tenebrael Taki tam żarcik. Z doświadczenia wiem że jak trzeba coś robić kilkanaście razy to lepiej to oskryptować. Narzędzia są konieczne dla rozwoju i służą one ludziom którzy rozumieją jak to działa.

Odnośnik do komentarza
Udostępnij na innych stronach

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.

Odnośnik do komentarza
Udostępnij na innych stronach

Azbesty, Monio - za malo nowych funkcji do game devu, rozwoj niby jest ale nie w strone w ktora by chcieli

Tenebrael - za malo pracy nad usprawnieniem juz istniejacych funcjonalnosci. Rozwoj niepotrzebnie idzie w dodawanie nowych rzeczy zamiast usprawnic to co juz jest.

 

To tylko 3 uzytkownikow i juz ta probka pokazuje ze macie sprzeczne oczekiwania co do devow. Teraz dodajmy do tego tysiace glosow innych, ktorzy tez by chcieli rozne rzeczy dodac i badz tu madry czego niby chce "community".

Wasz pomysl z darowiznami na konkretne opcje tez jest genialny tylko w teorii, w wypadku kiedy ludzie chca tego samego w zasadzie. Bo jesli zbiora sie dwie-trzy grupy i jedni dadza kase na rozwoj nowych narzedzi do game devu, drudzy na usprawnienia istniejacych narzedzi a trzeci na usprawnienia zwiazane z animacja (bo tacy tez sa mimo, ze tutaj akurat sie zgadzacie co do wyzszosci potrzeby narzedzi do tworzenia gier to to niekoniecznie jest glos WSZYSTKICH) to co, nad czym maja niby zaczac pracowac? Devow jest ograniczona ilosc, ludzie chca zeby rozwijane bylo wszystko najlepiej... Jak zaczna od gier to dwie pozostale grupy sie oburza, ze dlaczego nie zaczeli od nich skoro dali kase. I tym sposobem wiecznie beda jacys niezadowoleni.

 

Podobala mi sie tez propozycja Monia. W teorii -bum, bum, bum, cztery kliki, wszystko dziala. W praktyce - wytlumaczenie na kilkadziesiat linii tekstu.

Nie bashuje, super ze pracujesz nad tym ale rozbawilo mnie to. Troche jak obietnice wyborcze vs to, co po wyborach ;)

Odnośnik do komentarza
Udostępnij na innych stronach

@Monio to trzeba forsować na Deva. Roboty pewnie z tym całkiem sporo, a sprawę komplikuje odejście ojca od cycka. Trzeba by przeliczyć ile to może kosztować i wesprzeć fundacje na podobnej zasadzie co Valve. Może i to by się lepiej przyjęło niż osobny addon?

 

@Nezumi akurat bake to nie tylko game dev. Gdyby przedstawić to w postaci video, wirtualnie obrazując korzyści jakie za sobą to niesie, to z pewnością było by poparcie od strony community. Sukcesu nie da się przewidzieć, ale spróbować można.

Odnośnik do komentarza
Udostępnij na innych stronach

Przepraszam widziałeś może jakieś studio które robi filmy zajmuje się grubo pojętą animacją aby dofinansowała Blendera? Jak narazie to w blendera najwiecej wpakował kasy Game Dev i Arch wiz więc....

 

Valve dofinansowalo projekt Gooseberry - dofinansowalo ANIMACJE a nie gamedev tym razem.

 

Mozesz mi podac przyklad studia Arch wiz ktore dofinansowalo Blendera? Nie twierdze za tak nie jest - sam w tej chwili uzywam Blendera pod tym katem. Zwyczajnie nie przypominam sobie zadnego wiekszego studia Arch viz dofinansujacego Blendera.

 

(ten co ma inne zdanie na ten temat - mozesz mi kolego anonimowy powiedziec jakim cudem nie zgadzasz sie z FAKTAMI? :D)

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

Podobala mi sie tez propozycja Monia. W teorii -bum, bum, bum, cztery kliki, wszystko dziala. W praktyce - wytlumaczenie na kilkadziesiat linii tekstu.
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ęć.

Odnośnik do komentarza
Udostępnij na innych stronach

Spokojnie Monio, rozbawilo mnie ze po sobie nastapily dwa opisy - jeden ultra prosty i drugi juz niekoniecznie. To wszystko, Nie staram sie wykazac ze nie masz racji czy ze to zle bedzie dzialac.

 

Wciaz jestem ciekaw z czym sie nie zgadzaja ci co minusuja moj poprzedni post :D

Odnośnik do komentarza
Udostępnij na innych stronach

jeden ultra prosty i drugi juz niekoniecznie.
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?

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

Oczywiście dodatkowy tryb wyświetlania to najlepsze rozwiązanie, ale nie wiem jak to technicznie jest do ogarnięcia.

Monio można by zrobić One button, który przełącza wszystkim obiektom materiały z cycka na Blender Internal, ale dużo z tym zachodu.

Bardzo przydatny addon:

Odnośnik do komentarza
Udostępnij na innych stronach

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.

Odnośnik do komentarza
Udostępnij na innych stronach

Materiał od cycka zablokować w Cycles lub dodać komunikat z ostrzeżeniem i odwrotnie. Nawet przez Pop Up.

Jeżeli odpali ktoś bake ma poglądowych materiałach w BI to? Niech się nauczy na błędach, zbytnio idealizujesz i skomplikujesz tworząc taką drogę.

 

SelectionSet Addon:

Odnośnik do komentarza
Udostępnij na innych stronach

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.

Odnośnik do komentarza
Udostępnij na innych stronach

ale kombinujecie :D dodało by po prostu noda image texture do każdego materiału i by go podłączyło :> do outputu. a materiał by został i potem byłby tylko switch prosty który by spowrotem podłączał... stary materiał..

Odnośnik do komentarza
Udostępnij na innych stronach

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.

Odnośnik do komentarza
Udostępnij na innych stronach

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.

Odnośnik do komentarza
Udostępnij na innych stronach

Within a week or so, the Kickstarter should be finalized, the money in our bank account and we can start opening up the surveys for the backers! We didn't reach the stretch goal that would let Sven work full-time on Krita, so the feature survey will be "Choose and Rank 12 out of 24". Dmitry is already looking into 3D transformation stuff, so let's hope that feature won't get voted out!

 

Niektórzy open sourceowcy potrafią schować swoje zachcianki w kieszeń i zrobić coś dla użytkowników ich programu. Da się? :)

Odnośnik do komentarza
Udostępnij na innych stronach

Monio - moze wyslij to Tonowi, bo (z calym szacunkiem) to wieczne wracanie do tego samego raz ze jest nudne, a dwa, ze niczego nie zmieni tutaj. Nie staram sie byc zlosliwy , po prostu mysle ze temat sie juz przejadl i wszyscy po kilkadziesiat razy wyglosilismy plomienne przemowy zaznaczajac nasze zdanie.

Krita jest innym softem, jak wiesz bardzo lubie i ten soft i cenie sobie otwartosc i zaangazowanie devow. Tez chcialbym zeby podobnie bylo z Blenderem ale nie jest. Nie widze powodu, zeby mielic ten temat w kolo Macieju. Sam wypowiedzialem sie pierdylion razy tu - moze faktycznie zrobic watek osobny do narzekan i jak nas cos sfrustruje to sobie wejdziemy do "Dlaczego Blender nie dziala" watku na przyklad i potaplamy w zolci ;)

Odnośnik do komentarza
Udostępnij na innych stronach

Monio - moze wyslij to Tonowi
Taki mam plan. Może nie Tonowi ale na BA gdzie będzie mógł to przeczytać razem z dyskusją reszty userów. Jak skończę bejkowe sprawy to postaram się tam rozkręcić dyskusje.
Odnośnik do komentarza
Udostępnij na innych stronach

No nieźle, Monio szykuj odwet ;)

 

Swoją drogą to coś czuje że wkrótce może nastąpić wysyp płatnych addonów, mimo to nie cieszą się one wielkim zainteresowaniem jak na możliwości jakie mają.

Odnośnik do komentarza
Udostępnij na innych stronach

No nieźle, Monio szykuj odwet ;)

 

Swoją drogą to coś czuje że wkrótce może nastąpić wysyp płatnych addonów, mimo to nie cieszą się one wielkim zainteresowaniem jak na możliwości jakie mają.

W takiej sytuacji należy znaleźć rozwiązanie pośrednie. Takim mogłoby być np wykupienie/zrzuta przez społeczność na naprawdę świetne/niezbędne/nowatorskie rozwiązania i włączenie ich do kodu. Nie uśmiecha mi się płacenie 100$ za addon. Do tej pory to było super że pewnie rzeczy rozwiązywane było przez community za darmo. Rozumiem że twórca kodu chce zarobić, jest to naturalne, tylko że grupa docelowa Blendera jest inna niż takiego maxa czy mayki są to przeważnie nowicjusze, wiem zmienia się to, ale zbyt powoli. Spodobał mi się komentarz jakiegoś twórcy addonu który stwierdził że pomimo wysokich aspiracji ma zamiar dać rozsądną cenę. I takich oby było jak najwięcej.

Odnośnik do komentarza
Udostępnij na innych stronach

@Idaho Oczywiście, napisałem to w żartobliwym kontekście, tylko czy strony będą wstanie się dogadać?

Co do ceny, to faktycznie może dojść do sytuacji w której wykupienie kilku addonów do Blendera = cena komercyjnego programu.

Osobiście jestem bardziej zwolennikiem ustalenia kwoty za którą uwalnia się skrypt, bo lepiej wpływa to na rozwój samego Blendera.

Odnośnik do komentarza
Udostępnij na innych stronach

Co do ceny, to faktycznie może dojść do sytuacji w której wykupienie kilku addonów do Blendera = cena komercyjnego programu.

 

Pod warunkiem ze ten soft bedzie kosztowal z $300 (bo ceny add-onow to zwykle kolo $15 a najdrozsze jakie widzialem podchodzily pod $35-$40).

 

A potem do tego komercyjnego softu bedziesz musial dokupic pluginy :D

Odnośnik do komentarza
Udostępnij na innych stronach

Nie widze zupelnie nic zlego w platnych addonach. Jak ktoś za 200 dolcow zrobi jakiś zajebiście zaawansowany addon który zrobi idealne auto-retopo to go kupię od razu bo wiem że mi się zwróci. Jeśli za ceną idzie jakość to wszystko jest ok.

Odnośnik do komentarza
Udostępnij na innych stronach

Czekaj Monio - w newsach pokazujesz B-surfaces, o którym parę postów temu się zasatanawialiśmy, czy działa, czy się popsuł?

W dodatku gość go używa z taką biegłością, że szybciej by można zrobić vertex by vertex. Potem jest użyty contour tools od cgcookie. a na koniec jest ręczne łatanie.

Coś przegapiłem?

Bo mi wygląda na używanie dodatków na siłę w sytuacji, gdy szybciej by było poklikać z controlem i snapowaniem po modelu żeby zrobić edge, a potem dodatkiem F2 "wyeFować" ściany.

Odnośnik do komentarza
Udostępnij na innych stronach

Przegapiłeś to że filmik nie jest o Bsurfaces ani Conturs tylko o Iceking's Tool.

 

Zapomniałem podać linka do tematu. Teraz się poprawię:

http://www.blenderartists.org/forum/showthread.php?343641-Iceking-s-Tools

 

 

 

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

REALTIME PBR W VIEWPORCIE BLENDERA

 

uHSyXso.png

r1Ld7Bn.png

 

Czillout. To nie jest viewportFX tylko eksperyment jednego gościa. To by idealnie rozwiązało sprawę podglądu wybejkowanych tekstur. Hah...

 

http://blenderartists.org/forum/showthread.php?343278-GLSL-PBR-Shader-for-viewport

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