Skocz do zawartości

Rekomendowane odpowiedzi

Napisano

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

Gość Chrupek3D
Napisano

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

Napisano

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.

Napisano

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.

Napisano

Ja uwielbiam rozkładać UV w blendku. Zajmuje mi to długo ale potem mam zajebistą satysfakcje z zaoszczędzenia każdego texela. :)

Napisano (edytowane)

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
Napisano

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

Napisano (edytowane)

akurat to nie jest powodem do dumy, wiekszość softów też są makra i prostsze narzędzia do ich tworzenia :P

Edytowane przez szczuro
Napisano (edytowane)

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

Gość Chrupek3D
Napisano

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 :-\

Napisano

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.

Napisano

ż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ą :>

Napisano

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

Napisano

Bardzo chętnie zobaczyłbym jakąś teksturę wykonaną taką metodą. Nie oblanego królika, ale autentyczne zacieki, rdzę, przybrudzenia. I to na leciutkiej siatce.

Napisano

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.

Napisano

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.

Napisano

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.

Napisano

Jego odpowiedz na mój proposal:

 

I think we will most likely first release Cycles Baking with the "traditional" pass types since this will already benefit some people. After that we see how to extend this for custom cases. I'm interested in PBR or whatever makes us future-proof, and could use some reference material for that too.

 

Więc tak ale daleka droga do tego jeszcze. Najpierw bugi i UI trzeba naprawić.

Napisano

Ja na przykład jestem tym som pipolem, który już benefituje, Ale ciśnij z proposalem, bo jak wiesz co jest potrzebne, to dla czego by mieli nie zrobić kiedyś/wkrótce.

Napisano

Ikkiz - Tak zrobię. Wszystko w swoim czasie. Najpierw megagement bakeu.

 

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

http://exploreblender.com/

 

Bardzo fajne dvd się zapowiada. Ja ostatnio nauczyłem się podstaw driverów i jaram się jak pochodnia. Na pewno kupię ten tutek.

Napisano
Hi all,

 

Here are the notes from today's 1600 CEST meeting in irc.freenode.net, #blendercoders.

 

1) Blender 2.71 release planning

 

- Test build was released yesterday, another one should be made mid next week.

A first release candidate build could then be announced after next week's meeting.

 

- Ton Roosendaal still has to establish a splash committee. Will be known in few days.

 

- Bug tracker still has too many open issues...

 

- Bastien Montagne points at huge and old list of patches that wait for reviews. Ton suggests to do a massive amnesty for patches after the release, provided the submitter is enthusiast and capable to be involved as part of a module team - responsible for maintaining his/her work and fixing bugs.

 

2) Google Summer of Code

 

- Not every student has submitted the weekly report. The Nurbs coder Jonathan deWerd (nick jjoonathan) reported he will do soon.

 

- All students (and mentors) should now work on refreshing and reconfirming their proposals for work. Get connected with the module teams and artist stakeholders too. If in doubt, just always involve the GSoC admins Campbell Barton or Ton Roosendaal.

 

3) Other projects

 

- Ton will post a report about the last week meetings in BI with developers.

 

- OpenSubdiv: Apple OSX refuses to mix OpenGL 4 with older OpenGL functions (= all of Blender). That means we cannot release GPU-based OpenSubdiv for Macs soon, but this is still under investigation. For Linux and Windows this isn't a problem.

 

- OpenSubdiv code now has runtime opencl/cuda detection (so it also links dynamically).

 

Thanks,

 

-Ton-

http://lists.blender.org/pipermail/bf-committers/2014-May/043615.html

 

Ciekawe co to za lista pathy.

Szybki gugiel i okazuje się że na makach OSD działa wyłącznie na CPU, we wszystkich programach w których go zaimplementowali. Są jakieś problemy z driverami od apple. Workstacja 21 wieku. Lol.

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