Blender - NEWS oraz dyskusje

[Nezumi]

Czyli rozumiem, że spamowanie odnośnikami do bardziej skomplikowanych funkcji w kilku miejscach softu sprawi, że będą prostsze do ogarnięcia? Ciekawa teoria...

Nie, zwyczajnie rzeczy trudniejsze zwykle wymagaja wiecej pomocy, ludzie znajacy opcje prostsze moga nie znac tych bardziej zaawansowanych. Ciekawa teoria, czy tez moze oczywistosc?

 

 

Jeśli coś nie ma jasno zdefiniowanej dolnej i górnej wartości, to nie należy stosować paska, który z samej natury te wartości posiada. Zamiast tego należy stosować pole liczbowe. Zresztą, w wielu miejscach Blender tak właśnie robi (np. przy ograniczeniu globalnej liczby subsurfa, czy też w procentowym zmniejszeniu rozdzielczości renderu do testów). Szkoda tylko, że nie jest to spójne i czasami paski odpowiadają możliwym do wprowadzenia wartościom (tam, gdzie jasno zdefiniowane minimum i maximum - pasek; tam, gdzie brak zdefiniowanego minimum i maksimum - liczba), a czasem nie.

Jesli czasem cos jest a czasem nie to faktycznie powinno sie to ujednolicic.

 

 

To, że coś jest TRUDNE do zauważenia =/= temu, że jest NIEMOŻLIWE do zauważenia. Tyle, że w dobrym UI powinno być ŁATWE do zauważenia, czyż nie?

Zgoda choc wiele zalezy od uzytkownika. Na ten przyklad Tobie podobno przychodzi z trudem klikanie na zakladki z ktorym ja nie mam najmniejszego problemu. Zawsze sie znajdzie taka baletnica co to jej rabek u spodnicy przeszkadza a wtedy nawet najlepsze (najwieksze? :D )UI nie ma szans...

 

 

"Semi-randomness based on brownian equasion" - tym sposobem owszem, nawiązujesz do ruchów Browna, ale jednocześnie dajesz użytkownikowi sygnał, że wprowadzenie tych ruchów spowoduje dodanie efektu przypominającego pseudo-losowość.

Nice try - chcesz sie zalozyc, ze ktos kto nie wie co to jest "brownian", wciaz nie bedzie mial pojecia o czym mowisz? Skoro nie wiedza podobno co to "normal"... :D

 

 

Typowa postawa Blender-fanatyka, wybacz. To, że mam Blenderowi jako takiemu, jego rozwojowi i postawie jego twórców wiele do zarzucenia nie oznacza, że nie cenię tego softu czy wkładu developerów. Sorry, świat nie jest tylko czarny i biały, odcienie szarości również istnieją. To, że coś krytykuję, nawet mocno, nie oznacza, że nie widzę w tym czymś wielu jasnych stron.

 

Stwierdzenie "Tak czytam ten update i zastanawiam się, czy w ogóle zostanie jakiś content na 2.72, skoro większośc przesuwają na 2.73 wzwyż..." nie jest krytyka. Jest sugestia wiecznie niezadowolonego z poczynan devow uzytkownika, sugerujacego ze wydadza bezsensowna wersje w ktorej zmieni sie tylko numerek. Nie wiem czy wiesz, ale "meeting notes" nie tlumaczy sie na "zapowiedz nowych opcji w wersji nastepnej".

 

Jeszcze slowo komentarza na temat "Takich ambitnych i ogarniętych pomysłów jak przedstawił Monio jest na pewno wiele z tym że każdy robi to w innym celu, a bardzo łatwo można kogoś zniechęcić pasywną postawą."

 

Pomyslow, to ludzie maja w cholere. Problem jest w tymkto ma je zrealizowac.

[Tenebrael]

Jeszcze slowo komentarza na temat "Takich ambitnych i ogarniętych pomysłów jak przedstawił Monio jest na pewno wiele z tym że każdy robi to w innym celu, a bardzo łatwo można kogoś zniechęcić pasywną postawą."

Pomyslow, to ludzie maja w cholere. Problem jest w tymkto ma je zrealizowac.

 

Chwila, ale czemu to cytujesz w odpowiedzi na mojego posta, skoro nie ja to napisałem?

 

EDIT: A co do wersji 2.72. Ale moje pytanie było jak najbardziej serio - wychodzi na to, że większość co bardziej znaczących zmian przesunięta została na kolejną wersję. Zastanawia mnie więc, co zostanie do wprowadzenia w tej konkretnej, 2.72.

 

Z kolei takie przesuwanie jest kolejną dziwną praktyką u devów Blendera. Jasne, rozumiem, że jakaś funkcja może się okazać trudniejsza do zaimplementowania, więc trzeba ją będzie opóźnić, tu pełna zgoda. Ale bywa tak, że pewne funkcje są zapowiadane na kilka kolejnych wersji pod rząd i wciąż przesuwane. Po co to zapowiadają, skoro znają już skalę skomplikowania danego elementu i raczej wiedzą, że i tak się na kolejną wersję nie wyrobią? przykłady? Choćby nieszczęsny Ubershader, którego zapowiedź widziałem chyba w 3 czy 4 wersjach Blendera, by nagle, zamiast zostać wprowadzony, zniknął tajemniczo z listy. Teraz to samo dzieje się z Pie Menus. Wprawdzie nie jest to jakieś wielce szkodliwe dla samego Blendera (wcale nie jest, tak na prawdę) ale jednak ze strony twórców jest to nieco niepoważne. Sprawia wrażenie, jakby devsi albo nie mieli pojęcia o zarządzaniu projektem i z miesiąca na miesiąc łudzili się, że jakaś dobra wróżka przyjdzie i zrobi 3/4 roboty za nich (i się wyrobią), albo sztucznie wrzucali takie rzeczy jako targety do kolejnych wersji, by sprawiać wrażenie, że kolejna edycja będzie "na bogato". Albo po prostu robią to odruchowo i jest to tylko nieco dziwny nawyk, nie wiem.

Edytowane 14 Lipiec 2014 przez Tenebrael

[ikkiz]

Czarny PR, tylko to tutaj robisz. Masz 33 posty, w pierwszym pisałeś o metodach wycięcia dziury w walcu, a reszta, to podjazdówka na to jak *** jest Blender. To na prawdę wygląda, jak byś po to założył konto, bo swoich prac nie pokazujesz, innych nie komentujesz, nie zadajesz, ani nie odpowiadasz na techniczne pytania, ani o innych softach czy newsach słowem nie piszesz.

 

Jeki jest powód, że tyle wysiłku wkładasz i kilobajtów liter produkujesz, na temat złego i źle rozwijanego w twoim mniemaniu programu?

 

Jakich to podstawowych features mu brakuje? (dalej nie odpowiedziałeś)

 

czytałeś kiedyś release notes? na przykład dla 2.71 wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.71

 

Release_Notes/2.70

Release_Notes/2.69

Release_Notes/2.68

Release_Notes/2.67

 

Większość tego, co tam jest wyszczególnione zostało kiedyś przesunięte na późniejszą wersję - widać nie da się inaczej. Wersje wychodzą często, a rozwój jest przejrzysty. Jak jakiś temat pojawia się na developer meeting, to znaczy po porstu, że coś się w temacie dzieje, a nie że zaraz będzie gotowe. Nic nie jest trzymane w tajemnicy do chwili aż będzie gotowe.

 

Do innych, którzy są tutaj przypadkiem i nie mają wyrobionego zdania: poczytajcie sobie co się dzieje z wersji na wersję w tych changelogach i porównajcie z postępami prac nad kolejnymi wersjami innych pakietów do 3d. (są tylko changelogi, bo w firmach opracowywane features są tajemnicą do przemiery) Będzie sobie można wyrobić zdanie na temat tempa rozwoju na obiektywnych faktach, a nie na zdaniu kogoś, kto prawie na pewno jest tu żeby szkodzić i siać FUD

[Nezumi]

Tenebrael - powinienem wstawic tam linie odzdzielajaca - skoro nie Ty napisales to oczywiste ze sie do Ciebie nie odnosi. Nie chcialem mnozyc postow jeden pod drugim.

 

Co do wersji - napisalem juz, ze zdaje sie zlepodchodzisz do idei "meeting notes". To nie sa zadne "zapowiedzi". To jest zwyczajnie relacja z cotygodniowego spotkania pozwalajaca Ci zorientowac sie co sie w dewelopingu dzieje. Nie traktuj tego jako "release notes". To samo dzieje sie w Autodesku zapewne tylko ze tam nie mamy pojecia co sie przesuwa, dlaczego i tak dalej. Nie ma w tym nic niepowaznego - to jest wlasnie fajne w Blenderze i innych otwartych softach jak Krita ze wiesz co sie dzieje, masz informacje rowniez o tym jak cos sie nie uda, cos sie przesunie i tak dalej. W przypadku innych softow myslisz ze to nie ma miejsca? Wez takiego ZBrusha na przyklad - nie wiemy nad czym pracuje Pixologic - ale myslisz ze te kolejne wersje R1, R2, R3 itd nie sa efektem tego ze sie z czyms nie wyrobili? Zaloze sie, ze sa, tylko nie mamy stalych informacji na temat tego co sie dzieje. Zwyczajnie nie traktuj meeting notes jako zapowiedzi tego co bedzie w nastepnej wersji na 100%.

[Monio]

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?

[Tenebrael]

@Monio

 

Spoko, jeśli jest tam sporo bardziej "zakulisowych" rzeczy i bugfixów, to dla mnie jest jak najbardziej ok :) A te Pie Menus i FBX to już pewne, czy wciąż w fazie planów? Pytam, bo takie coś może drastycznie przyspieszyć pracę w sofcie, mocno na to czekam już od dłuższego czasu. Mam nadzieję, że PM zrobią naprawdę dobrze od strony użytkowej. Idealna byłaby możliwość tworzenia (w prosty sposób, nie przez skryptowanie) customowego menu kołowego (takiego, jak proponowałeś niedawno) - mogłoby to praktycznie zastąpić konieczność korzystania z Toolboxa czy dodatkowych skrótów klawiszowych - sądzę jednak, że to na tyle skomplikowana rzecz, że raczej nie trafi do pierwotnej wersji, może kiedyś?

[Monio]

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]

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

[floo]

@Tenebrael sprawdzałeś to cudo?

[Tenebrael]

@floo

 

O, dokładnie o to mi chodziło! Dzięki wielkie za podlinkowanie :)

[Grzessko]

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

[Monio]

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.

[Azbesty]

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!

[floo]

@Azbesty Stawiam że 3d stereo jest na potrzeby gooseberry i shortów jakie za tym idą.

 

Fajny przykład z bake, nie tylko dla game devu:

[Monio]

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.

;)

[Azbesty]

1. Zaznacz wszystko na scenie.

2. Add selected as bake targets.

3. Add pass -> Combined

4. Bake.

 

ohhh gdy ten dzień nadejdzie to nie wiem. chyba zapłacę osobistym przelewem osobie która to uczyniła możliwe.

[floo]

@Monio Podeślij swój pomysł do GURU. Opisz ładnie i ciekawe co ci odpisze? On uwielbia One click button. :D

[Monio]

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.

[Tenebrael]

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

[floo]

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

[Monio]

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.

[Nezumi]

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

[Azbesty]

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

[floo]

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

[Nezumi]

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 14 Lipiec 2014 przez Nezumi

[Monio]

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

[Nezumi]

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

[Azbesty]

jak coś to nie odemnie :D niech się ujawni ta osoba :D hahah

[Nezumi]

Luzik, jestem po prostu ciekawy czy jakis frustrat tak bez sensu, byle kliknac czy ma jakies argumenty. Wyglada na to ze nie ma :D

[Ajgor]

Wiecie co? Weźcie się może za blendera, a skończcie z marudzeniem, co? Nie szkoda Wam czasu?

[floo]

Nowe narzędzie do retopo?

[video=youtube_share;ZTyzZkLrJXY]

[Monio]

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 15 Lipiec 2014 przez Monio

[floo]

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:

[Monio]

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.

[floo]

No to trzeba zrobić One Button + skrypt przypisujący materiał oraz sloty do wszystkich tekstur: diff, spec, norm ect. W sumie to wcale nie jest takie trudne, tylko pracochłonny skrypt.

 

Prosty Exporter obiektów do Unity:

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

[Monio]

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.

[floo]

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:

[Monio]

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.

[Azbesty]

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

[Monio]

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.

[Azbesty]

ah fakt nie pomyślałem o tym

 

najlepszym wyjściem będzie chyba po prostu kopia sceny :D

albo wskazanie outputa. i on tam tworzy nowego blenda z przypisanymi materiałami itp..

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

[Monio]

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

[Nezumi]

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

[Monio]

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.

[alex3d]

OpenSubdiv obsługuje normal mapping w blenderze http://www.pasteall.org/pic/show.php?id=74096

 

Cycles Bake: pasek postępu podczas bejkowania https://developer.blender.org/D656

[Monio]

http://blenderartists.org/forum/showthread.php?343515-Addon-BakeTool-1-0-Preview

Mój konkurent ;)

Niezły przyśpieszacz ale nadal ograniczone.

[floo]

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

[Idaho]

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.

[floo]

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