Skocz do zawartości

Blender - NEWS oraz dyskusje


n-pigeon

Rekomendowane odpowiedzi

Sam nie pamiętam czy to już było: "new contours"

i jeszcze Visualize distances bwtween objects

[video=youtube_share;LHKIJ-oFMU0]

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

To proximity jest super przydatnym modyfikatorem. W pracy tego używam żeby spłaszczać teren po którym będzie poruszać się postać w grze. To co jest czerwone shrinkrwrapuje się do kuli która ma wielkość taką jak fizyka (2d) w grze.

 

13G6cj6.png

Odnośnik do komentarza
Udostępnij na innych stronach

Dzisiaj poszukując metod na proceduralną generacje modeli do naszej gry popłynałem i pobawiłem się w Mike Pan'a. Gość przez ostatni miesiąc robił obrazki wykorzystując tylko defaultowego cubea i pomocnicze obiekty nie będące meshami, wszystko z masą modyfikatorów.

Ja w swojej scence wykorzystałem wyłącznie zwykłe Plane'y. :)

 

HjTdMej.jpg

 

Pliczek do pobrania tutaj: https://www.dropbox.com/s/o2kdhl2xoygcjuu/Planes.blend

Odnośnik do komentarza
Udostępnij na innych stronach

@Monio, fajne, wygląda jak z rendermana :) Jak zoptymalizują wolumetrykę w cyclesie to razem z OSL będzie można podobne kształty wyciągnąć w dobrym czasie tyle, że w shaderze.

Odnośnik do komentarza
Udostępnij na innych stronach

Umiesz coś bardziej w temacie OSLa? Będę za kilka miesięcy potrzebował shaderowych wymiataczy do ogarnięcia sprytnych nodów pod bake (i w ogóle pod proceduralne teksturowanie). Plan jest taki żeby uzyskać efekty podobne dotych z dDo czy Substance Designera czyli zarysowania na krawędziach, brud w zagłębieniach, kurz osadzony względem normalki modelu i tym podobne sprawy.

 

Będziemy musieli przekonać devów żeby Cycles najpierw dostał kalkulowanie AO, Cavity i Curvature z geometrii, outputy w formie Value i Color. Jeśli tak się stanie to będzie narzędzie bliskie ideału. Nie trzeba w ogóle będzie robić wstępnych bakeów żadnych mapek jak właśnie AO, Cavity, Object normal, Bent normal czy inne. Większość tych rzeczy po prostu już jest w samych nodach cyclesa. Czyli żadnego pre-bake-crapu, jak render-preview będzie już zadowalająco wyglądał to wduszasz bake i za kilka minut masz na dysku gotowe mapki lecące prosto do silnika. :)

Odnośnik do komentarza
Udostępnij na innych stronach

@Monio, niestety na tę chwilę nie mam wystarczającej wiedzy jeśli chodzi o OSL, choć temat jest bardzo interesujący i trochę dziwne, że szerzej niewykorzystany jak dotąd w blenderze (no chyba, że w teorii: w ramach blender sushi było dość dużo fajnych publikacji w temacie i stronka dingto też jest przydatna) - projekt gooseberry mógłby to zmienić, bo małe czy średnie studio znalazłoby odpowiednich magików, żeby wykorzystać potencjał OSL.

 

Mam tego pdf-a https://github.com/imageworks/OpenShadingLanguage/raw/master/src/doc/osl-languagespec.pdf ze specyfikacją od parunastu miesięcy na dysku, ale ciągle brak czasu, żeby to ogarnąć. Kiedyś przez chwilę bawiłem się blenderem w tandemie z RIB Mosaic i Aqsisem i 3Delightem eksperymentując z proceduralnymi shaderami, ale na gruncie rendermana blender nie wyszedł poza fazę projektu i to się już nie zmieni (przyczyna leży bardziej po stronie braku zainteresowania niż ograniczeń technicznych). OSL to potęga; cycles ma możliwość tworzenia materiałów "per node", to jest już najwyższa liga, więc jedyne ograniczenie to wyobraźnia i przetarcie szlaku przez jakieś studio poważniejsze. Trzeba będzie poczytać tę specyfikację OSL i może w ramach ćwiczenia na dobry początek przetłumaczyć jakiś kod RSL na blenderowy OSL ;)

 

Zastanawia mnie ciągle sprawa (micropoly)displacementu i cyclesa jako path tracera od strony technicznej. Ciekawe na ile cycles będzie w stanie dokonać obliczeń w samym shaderze (o ile w ogóle) i jak to się ma np. do Octane i jak oni sobie z tym poradzili?

Odnośnik do komentarza
Udostępnij na innych stronach

Może nie przypisałeś do odpowiedniego developera lub projektu. Podeślesz adres?

 

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

http://mont29.wordpress.com/2014/05/11/fbx-7-4-updates-ii/

Eksport animacji szkieletowej z nowego eksportera FBX działa. Nie za miesiąc, nie za rok. Teraz. :)

Co lepsze. Goście z Epica dopilnują żeby wszystko działało na tip-top w ciągu następnych tygodni.

Bardzo cię przepraszamy Chrupku. Ludzie z Valve, Unity Technologies i Epica byli głupsi od ciebie i dali się wkręcić w bajki o blenderze i naprawili obsługę tego cudownego, do głębi open-sourceowego formatu. :( Twój argument jest inwalidą. Musisz sobie teraz wymyślić coś nowego.

 

Note that in addition to Unity, which greatly supported FBX export work with their donation to the Blender Foundation, people from Unreal Engine also started showing some interest for Blender FBX support lately – gamedev community is very active on this topic

 

http://www.twitch.tv/unrealengine/c/4174458

Odnośnik do komentarza
Udostępnij na innych stronach

Gość Chrupek3D

No i ja się bardzo cieszę, niech jeszcze zrobią ładne retopo, jak w Coacie, outlinera i grupy jak w Mayce... to go sobie nawet kupie :-)

Odnośnik do komentarza
Udostępnij na innych stronach

Reanimator- Dodałem Campblela do tasku. Mont działa w trochę innych rejonach. Ogólnie zawsze warto dodać Campbela bo teraz to on głównie odpowiada za rozwiązywanie regresji i bugów. Zobaczymy.

Odnośnik do komentarza
Udostępnij na innych stronach

I Campbell lubi naprawiać bugi, tak mówił w podcascie Andrew Price'a :) Andrew się dziwił, bo założył, że to wkurzające, a tu się okazuje, że Campbell lubi, sprawia mu satysfakcję i dobrze się bawi. Ja się odprężam przy retopo i rozkładaniu UV, to kogoś mogą bawić bugi.

Odnośnik do komentarza
Udostępnij na innych stronach

Boli mnie ten "workflow" bakeu strasznie. Kamień w bucie. Na szczęście na mailing liście Dalai pisał ze po prostu czekają na jakieś sensowne proposale od userów jak to ma działać.

Tylko się niepotrzebnie uczepili tego podglądu w Textured view za pomoca wybrania noda z obrazkiem. Jakby render preview nie pokazywał co jak będzie wyglądać. Jeden mały plus kosztem szybkości i wygody korzystania z całego systemu.

 

 

6rtEOAj.jpg

 

Większość faktycznego designu już za mną. Musze dograć jeszcze kilka spraw z UI i tym głupim podglądem. Potem mockup blenderowego interfaceu i pisze to na wiki.

 

Zasada jest taka że będą 2 główne tryby wypalania. Tryb "Simple" podobny do obecnego bakeu gdzie wypalamy jedną mapkę na raz przez selected to acvite, tyle że z możliwością zapisu do pliku od razu. Drugi tryb, ten normalny, to "Advanced". Po przełączeniu na niego w properties pojawia się dodatkowy panel podobny do Render Layers. W nim ustawiamy Bake joby które mają swoje własne ustawienia bakeu, przypisaną do nich listę obiektów hipoly i lowpoly oraz oczywiście listę mapek które ma wygenerować bake i opcje outputu gdzie mają się zapisać te mapki.

 

Co do list hipoly i lowpoly. Dokładniej mówiąc ustalamy coś co nazwałem Bake Sources oraz Bake Targets. Oba z nich to wpisy na liście które składają się z nazwy (tej która jes w okienku listy), link do obiektu lub blenderowej grupy obiektów (Dalai chciał to mieć) z których lub na które bakeujemy. Dodatkowo te source/targety posiadają własne ustawienia takie jak Cage, material override czy kanał UV na który bakeujemy. Obiekty do bejku będzie można ustawić ręcznie przez okienko wyboru mesha (takie jak modyfikatorach) lub łatwiej- za pomoca guzika który automatycznie doda wybrane obiekty jako source/targety i ustawi ich nazwy według nazw obiektów (to będzie do dodawania obiektów, grupy niestety bedzie trzeba dodać z łapy, ale sa już grupami więc nie bedzie ich raczej 100).

W menu obok UIListy oczywiście będą opcje związane ze zmianami nazw żeby mieć wszystko czytelnie poukładane i nie musieć ponownie dodawać obiektów (np target name from object, object name from target). Dodatkowo kopiowanie ustawień pomiędzy innymi sourcami/targetami w liście (wszystkie poza linkowanym obiektem i custom cagem) żeby łatwo dało się zamienić material override na 50 obiektach na raz.

 

Chcesz wypalić 30 assetów na raz z czego 5 z nich to kopie z podmienionym materiałem? Dwie minuty poszperaniach w ustawieniach bake jobów, kopia kilku i podmiana material override paroma klikami. Potem wduszasz bake i gotowe. :) Szybsze, lepsze i bardziej solidne rozwiązanie niz batch w xNormalu. Łatwiejsze do ustawienia niż reimport meshy i rebake w Substance designerze. :)

 

------edit---------

Co do nazw mapek. Nazwa jest konstruowana tak: "bake_job_name + bake_target_name + map_sufix". W outpucie ustala się ścieżkę do folderu więc można bakeować od razu do plików gry mapki nazwane np. Character1_head_normal. Sufiksy mapek bedzie mozna zmieniać w kazdym bake jobie jesli chcemy mieć np "_n" zamiast "_normal".

Razem z blenderowym systemem library i linkowaniem obiektów z innych plików blend będzie się dało mieć jeden master file którym można wybejkować na raz wszystkie assety w grze. Odpalając jedną komendą z command linea. :)

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

Ale jaki przydatny. Proste macro. Ale blender dzięki takim prostym, szybkim opcjom jest właśnie zajebisty. W niektórych softach żeby coś wymodelować potrzebujesz 2 razy więcej kroków. ;)

Odnośnik do komentarza
Udostępnij na innych stronach

Monio! Zawrzyj jeszcze w swoim proposalu renderowanie mapek w mniejszej rozdzielczości, coś jak jest przy renderze, żeby można było wybejczyć mapkę ileś procent docelowej/docelowych, bo patrz - jak chcesz włączyć bejk i iść na rower, to dobrze by było, żeby nie było niespodzianek jak wrócisz - nie? A jak by tak najpierw wypalić komplet mapek do assetu w 25% 8 razy szybciej niż finalnie, to można by je obejrzeć, wtedy ustawić 100% i iść pedałować ... ;)

 

edit -----

masz tam na mapach scale on bake, tylko z pytajnikami. o to chodziło, bo jeśli tak, to warto imho.

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

Monio! Zawrzyj jeszcze w swoim proposalu renderowanie mapek w mniejszej rozdzielczości, coś jak jest przy renderze, żeby można było wybejczyć mapkę ileś procent docelowej/docelowych, bo patrz - jak chcesz włączyć bejk i iść na rower, to dobrze by było, żeby nie było niespodzianek jak wrócisz - nie? A jak by tak najpierw wypalić komplet mapek do assetu w 25% 8 razy szybciej niż finalnie, to można by je obejrzeć, wtedy ustawić 100% i iść pedałować ... ;)

edit -----

masz tam na mapach scale on bake, tylko z pytajnikami. o to chodziło, bo jeśli tak, to warto imho.

Dzięki za sugestie. Dodam to. Również dodam Sample override do sterowania ilością sampli na bake joba. To samo co jest w Render Layers. Przyda się do podglądu poprawności bakeowania dużych mapek z GI bo to zawsze będzie się renderowało najdłużej.

To "Scale on bake" to opcja która skaluje wszystkie obiekty przed bakeowaniem. W niektórych rendererach przeskalowanie obiektów w górę pomaga przy artefaktach na mapach. Jednak chyba na razie to pominę bo proposal i tak już wystarczająco spuchł a nie mogę zawalić informacjami ludzi którzy to będą czytali.

 

Gadałem dzisiaj z kumplem z pracy i unaocznił mi problem mapek o różnych rozdzielczościach i formatach. Chodzi głównie o normalki i heightmapy które muszą mieć inną głębie bitów. Wpadliśmy na pomysł że poszczególne passy tekstur będą miały możliwość ustawienia własnych opcji outputu, jako dodatek odpalany checkboxem oczywiście. Czyli ustawiasz rozdzielczość, margin, format pliku ect. dla większości wypalanych mapek w Bake Job Output Settings. Potem jak stwierdzasz że potrzebujesz normalki z rozdziałce zmniejszonej o połowę (bardzo częsty zabieg) i z innym formatem pliku więc w ustawianiach tego passu klikasz checkboxa "Override Output settings" i tam możesz ustalić wymienione opcje specjalnie dla tylko tej mapki. Na gotowym interface to będzie wyglądało klarownie.

 

Kurka. Jak tak dalej pójdzie to blenderowcy będą grupą grafików z najlepsza kondycją. Tylko ustawiają guziczki, wciskają button i od razu lecą na rower. ;D

Odnośnik do komentarza
Udostępnij na innych stronach

Gość Chrupek3D

możecie wspomnieć o opcji "move" w sculpcie, temu kto jest za nią odpowiedzialny. Dzisiaj troche naskrobałem konceptów i o ile sculptuje się bardzo spoko to opcja "move" jest koszmarna. Właściwie w swoich sculptach sporo przesuwam, dbając o krzywizny, ale tym czymś to można tylko krzywde zrobić sobie i obiektowi :-\

Odnośnik do komentarza
Udostępnij na innych stronach

Przydałby się normalny move. ;) Tutaj niestety chodzi design całego silnika pędzli. Te blenderowe krzywe są od czapy, to powinno się załatwiać jednym suwakiem a prawdziwa krzywa to powinno być coś czego niemal wcale się nie dotyka, tylko przy zaawansowanych opcjach pędzli.

 

Wyciągam popcorn i ogadam filmik o opensubdiv. Hell yeah.

Odnośnik do komentarza
Udostępnij na innych stronach

że ja na to wcześniej nie wpadłem. i tak np całą scenę możesz zalać z góry... i potem użyć tego jako maski.. między zwykłym materiałem i o dużym specularze.. i masz scene w deszczu gotową :>

Odnośnik do komentarza
Udostępnij na innych stronach

No bez przesady z tym dynamic paintem. Takie rozwiązanie nie ma nawet 1/10 tej interaktywności i możliwości co substance painer. To jakby nazwać sculpt w maya z tymi trzema pędzelkami konkurentem zbrusha. ;)

Odnośnik do komentarza
Udostępnij na innych stronach

Ja też.

Dodatkowo- Substance Painter kalkuluje fizykę particli uwzględniając normal mapę obiektów. Czyli zacieki tworzą się na krawędziach normalki a nie polygonów. Nie do zrobienia w blenderze.

Odnośnik do komentarza
Udostępnij na innych stronach

była ostatnio jakaś optymalizaja viewportu? Coś mi się zdaje, że model, który już lagował, dziś obracam bez większych zacięć. I to nie opensubdiv, nawet nie mam subsurfów na tym.

Odnośnik do komentarza
Udostępnij na innych stronach

Bardzo ładne ale niestety nieużyteczne w grach.

Robiłem ostatnio testy, nie da się uzyskać w cyclecie takich efektów jak daje marmoset. Nie ma szans. To znaczy że w render preview będzie widoczne coś innego niż na modelu w silniku. I tutaj nie chodzi o moją nieumiejętność układania nodów ale elementarnie inne działanie podstawowych shaderów. :(

 

Przy PBR precyzja jest szalenie ważna, nie robi się rzeczy na oko tylko korzysta z tabelek z właściwościami materiałów. Wypalanie lowpoly pod mobile bardzo spoko ale do UE4 czy Unity5 texy się tym poprawnie nie zrobi. Bez odpowiedniego dedykowanego shadera taka zabawa mija się z celem.

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