Skocz do zawartości

Rekomendowane odpowiedzi

Napisano

@Monio dobra rzecz, tylko że u mnie scena testowa nie działa prawidłowo na bulidzie, który został udostępniony. U was jest ok?

Napisano

Dodaje shirnkwrapa do lowpoly od razu z ustawionym targetem z obiektu hipoly. Potem jak klikasz update to go zatwierdza i dodaje następnego z takimi samymi ustawieniami. Banał ale zaoszczędza masę pieprzenia się przy retopo czyli ciągłego zatwierdzania i setupowania shrinkwrapa co każdą większą edycje siatki low.

Napisano (edytowane)

http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.72/Painting

 

soc-2013-paint w masterze. Właśnie ściągam. Testowaliście już?

 

edit: ok... co stalo sie z viewportem? Mam dodane te niby "warstwy" gdzie mam alfe oraz normalke i po 2 godzinach testów nie udało mi sie nigdzie ustawić żeby wpływały na wygląd modelu podczas malowania.

 

edit2: Nie śledzilem tego projektu wcześniej. Po jakiego wała gość to nazwal Layerami... Już się napaliłem i takie rozczarowanie. To nie ma nic wspólnego z warstwami, to są po prostu material textures identyczne jak w properties. Kolejna niespójność w interface.

 

Jak na razie jestem zawiedziony. Pare fajnych tooli i 100 dodatkowych problemów z obsługą. Podstawowe bugi pozostały, nadal paint nie radzi sobie z seamami. Wygenerowane tekstury się nie zapisują w pliku blend, zapisać je można tylko przez image editor. Funkcje jak fill są poukrywane, trzeba sobie zrobić nowy pędzel i szukać w menusach żeby go odpalić. A już jak się go stworzy i odpali opcje gradient to nie da się jej wyłączyć, trzeba kasować pędzel i tworzyć go od nowa. Checkboxy do cullingu paintu nie działają jak checkbox tylko toggle bo nadpisują kolejno swoje ustawienia. Tylko tyle udało mi się znaleźć po 2 godzinach.

Edytowane przez Monio
Napisano

W tym dziale plusy są pewne za narzekanie na cycles baking!!!

 

też ci dałem plusy, nie będę się z koniem kopał.

 

Jak nie było bejku wcale, to nikt nie narzekał. Ogólnie to było lepiej. Nikt nie miał horrorów, ani koszmarów.

Napisano

Zaczyna się... Na bake w internalu ludzie narzekali ZAWSZE. Jak nie było bakeu w cyclesie to również narzekała masa osób. Wszyscy nie mogli się doczekać aż wreszcie nastąpi dzień kiedy ktoś zabierze się za bake w cyclesie. I nastąpił wiele miesięcy temu tylko że nadal te narzędzie jest strasznie niedopracowane.

Z postawą taką jak twoja można zanegować potrzebę dopracowywania czegokolwiek. Wracasz do 2.49 bo tam "przecież da się" modelować, renderować, riggować i nawet cały film animowany zrobić? W maya 2014 dało się mapować i wiele osób nie narzekało. Tylko że było to wyłącznie osoby które nie znały pluginów lub innych softów w którym mapuje się łatwiej i 10 razy szybciej. To jest sposób myślenia mieszkańca Koreii Północnej który wychwala swój kraj tylko dlatego że nie ma pojęcia co dzieje się za jego granicami. Twój argument jest inwalidą.

 

Nie wiem ile spędziłeś na testach bakeu ale szczerze wątpię że tyle co ja. Podzielę się kawałkiem mojego proposalu w którym wypunktowałem limitacje i utrudnienia obecnego bakeu. Wszystkie rzeczy które opisuje mogłyby być rozwiązane już dawno temu gdyby posiedzieli nad designem dodatkowe 2 tygodnie (na przestrzeni 9 miesięcy w których zajmują się ta sprawą) i słuchali się ludzi którzy dawali im feedback. Może to ci przemówi jak źle jest zaprojektowane to co obecnie masz w blenderze 2.71

 

Na chwile obecną (data) wypalanie tekstur za pomocą silnika Cycles posiada wiele dużych limitacji oraz jest dużo trudniejsze niż być powinno. Kilka podstawowych wad obecnego rozwiązania to:

 

- Brak zapisu w pliku blend które obiekty mają być wypalone.

Obecnie ustalenie które obiekty mają być wypalane odbywa się przez selekcje tych obiektów we viewporcie. Jest to bardzo uciążliwe i może prowadzić do wielu błędów gdy użytkownik omyłkowo nie zaznaczy jakiegoś obiektu (najczęściej mało widocznego) lub zaznaczy je w złej kolejności.

 

- Brak Batch bake oraz brak możliwości wypalania wielu obiektów na raz.

Nie ma możliwości wypalenia w blenderze wielu obiektów lowpoly na raz. Modele trzeba wypalać kolejno ręcznie co może prowadzi do zwielokrotnienia nakładu pracy która mogłaby być wykonana tylko raz.

 

- Bake opiera się zawsze na ustawieniach sceny.

Wypalenie nowego obiektu na scenie często wymaga zmienienia wielu ustawień sceny oraz bakeowania. Obecnie da się to zrobić tylko przez napisanie istniejących ustawień sceny. To prowadzi do sytuacji że w jeden plik blend może służyć tylko do wypalania jednego assetu, co jest bardzo niewygodne i zwiększa potrzebną ilość pracy.

 

- Brak wypalania wielu map jednocześnie.

Żeby wypalić kilka tekstur dla jednego obiektu użytkownik musi wielokrotnie wykonywać te same czynności.

 

- Brak automatycznego zapisu tekstur.

Jeśli wypalisz swoje tekstury, zapiszesz plik blendera i uruchomisz go ponownie zobaczysz ze wszystkie twoje tekstury zostaly skasowane. Obecnie każda wypalona tekstura musi być zapisywana manualnie przez usera. W przypadku gdy ktoś pracuje z dużym projektem, gdzie chce wypalić na raz wiele zestawów tekstur dla rożnych obiektów, powoduje to sytuacje w której musi ręcznie zapisywać nawet kilkadziesiąt.

 

Cały zestaw ograniczeń i utrudnień jest spowodowany przez obecny system definiowania na jaką teksturę wypala się obiekt. Obecnie żeby wypalić teksturę za pomocą cyclesa konieczne jest umieszczenie niepodłączonej image nody w shader tree materialu. Problemy które to implikuje to:

 

- Niepotrzebnie skomplikowane tworzenie nowych tekstur na które wypalany jest obiekt oraz definiowanie właściwości tych tekstur (wielkość, format pliku).

Obecnie żeby dodac teksture user musi wykonać szereg operacji które powinny być wykonane automatycznie przez program w oparciu o dane które user podał w interface bakeu. Ponowne wypalenie tekstury w innej rozdzielczości sprowadza się do generowania nowego obrazka.

 

- Zmiany właściwości tekstur typu generated w blenderze kasują z nich rezultaty wypalania.

Jeśli user będzie chciał sprawdzić jak wygląda jego wypalona tekstura w innej przestrzeni koloru (sRGB, Linear, Non-Color...) to rezultat bake zostanie bezpowrotnie skasowany bez ostrzeżenia. Ten problem dotyczy wszystkich zastosowań tekstur Generated, nie tylko w wypadku bakeu.

 

- Brak możliwości korzystania w tego samego materiału na wielu obiektach.

Żeby wypalić wiele obiektów które korzystają z tego samego materiału user musi stworzyć twarde kopie tego materialu i w każdej dodać inna image node. Może też podmieniać obrazek w image nodzie za każdym razem przez wypaleniem kolejnych obiektów. Sytuacja ta prowadzi co bałaganu w bibliotece materiałów lub/i zwielokrotnienia nakładu pracy.

 

- Brak możliwości korzystania z linkowanych materiałów.

 

- Zaśmiecanie shader tree materiałów nodami które nie tworzą materiału.

 

- Duże prawdopodobieństwo zniszczenia biblioteki tekstur.

Jesli user omyłkowo zaznaczy niewłaściwa image node z tekstura która tworzy matetial to bake zostanie zapiany w tej teksturze niszcząc materiał.

 

Workflow z niepodłączona image noda w teorii miał umożliwić podgląd wypalonych tekstur za pomocą trybu wyświetlania Texture w viewporcie. O ile taki podgląd możne sprawdzać się podczas malowania tekstur to nie sprawdza się jako podgląd wypalania. To rozwiązanie niesie za sobą pewne ograniczenia takie jak:

 

- Możliwość wyświetlenia tylko jednej tekstury na raz.

Bake zazwyczaj służy do wypalania całych zestawów tekstur które razem składają się na końcowy wygląd materiału. Wyświetlanie pojedynczej tekstury nie daje pełnego poglądu jak będzie wyglądał materiał.

 

- Brak shadingu i poprawnego wyświetlania niektórych rodzajów tekstur.

Podczas podglądu wszystkie tekstury są wyświetlane w formie shadeless jako tekstura kolorowa. Taki podgląd możne spelniać swoje zadanie wyłącznie w przypadku tekstury typu combined. Tekstury takie jak specular czy roughness (obecnie nie dostępny do wypalania) nie dają pełnego obrazu jak model będzie wyglądał w silniku. Wyświetlanie tekstury normal w taki sposób zupełnie mija się z celem bo nie pokazuje ona poprawnego cieniowani bryły.

 

[obrazek z normalką w texture shading]

 

- Korzystanie z tego samego materiału na rożnych obiektach powoduje ich niepoprawne wyświetlanie.

Material może mieć aktywna tylko jedna image node przez co tekstura która się w niej znajduje będzie wyświetlana na wszystkich obiektach które korzystają z danego materiału. Nawet jestli user ma wiele image nodow z teksturami dla każdego obiektu to nie ma możliwości przypisania na których obiektach będą wyświetlały się dane tekstury.

 

[gif z przeskakiwaniem po image nodach pokazujący ze poprawnie wyświetla się tylko jeden obiekt w danym momencie]

 

Na rzie mam w nosie błędy stylistyczne. Docelowo cały tekst będzie napisany po angielsku. To są notatki które robię głównie w środkach komunikacji gdy jadę do/z pracy.

Napisano

Ja nie narzekałem, bo nie sądziłem, że to będzie możliwe w silniku działającym tak jak cycles. może głupi jestem, może się nie znam i mam małe wymagania, ale serio tak myślałem. Czy Luxrender wypala, czy vray wypala, a może octane, albo corona, albo indigo?

 

 

Po prostu szkoda mi było, że proceduralne tekstury są zamknięte w cycles - prędzej sobie wyobrażałem ujednolicenie tekstur internalowych i cyclesowych, żeby wypalić w internalu.

 

Aż tu nagle bach! jest! Są algorytmy, które to robią (nawet nie jest dziwne, że ja nie rozumiem jak, ale jakoś robią) A że interfejs-workflow kuleje - cóż trzeba poprawić. Ale narzekanie i drwiny się zaczęły dopiero teraz, jak nie było, to nie było i na *** to drążyć.

 

Ale jak byś mnie spytał, czy najpierw altyaliasing w bejku, czy interfejs do bejku, to chcę antyaliasing!

Napisano

Osobiście to nie narzekam, tylko dodając film zażartowałem, więc nie widzę powodów by robić obok tego niepotrzebny szum.

Przypomina mi to sprzeczanie się fachowców, co lepsze zwykły ręczny młotek, czy pneumatyczny automat?

 

Zawsze wychodzę z założenia jeżeli można coś ułatwić, to należy to zrobić, aby mieć więcej czasu na inne rzeczy.

 

Jak patrzę na graphicall.org to widzę całkiem sporo do dodania:

- pie menu

- pbr shader

- paint

- BEPUik solver

- Fracture Modifier

- Shapekey

- i inne

I gdzie tutaj magia? Ano w tym że można te wszystkie rzeczy dopracować zanim pojawią się w oficjalnym bulidzie, bo może się okazać że jak ludzie dostaną półprodukt to później przy każdej zmianie będą psocić, bo wyrobią sobie złe nawyki.

Napisano

Vray wypala, Mental wypala, BI wypala, Renderman wypala, Octane nie wypala, Arnold nie wypala. O reszcie nie wiem.

 

Narzekania, konstruktywne, zaczęły się półtora miesiąca przez tym jak wyszedł 2.71. W stosownym wątku na BA założonym przez samego Dalai.

AA to feature który pojawi się na pewno (oficjalne info) bo inicjatywa wyszła od samych developerów. Inaczej niż w przypadku interfaceu bo niektórzy z nich twierdzą że nie ma nic złego w workflow gdzie nakład pracy jest 100 razy większy niż mógłby być (średniej wielkości projekt, kilkanaście lowpoly z zestawami map).

Napisano

Co developer to inne podejście. Psy-Fi zmienił nazwę "Layers" w jego paincie na "Slots", teraz wszystko się zgadza i nikt nie będzie narzekał że layery to nie layery. :) Dodatkowo utłukł masę bugów i bardzo mocno zajmuje się poprawianiem UI w oparciu o feedback ludzi z BA i Phabricatora. Jeszcze tylko niech rozwiążą jakoś problem z kasowaniem się danych z tekstur generated i zapisem wszystkich plików na raz (zgłosiłem sugestie) i będę skakał z radości. Będzie dobrze z tym Paintem a może przy okazji trochę naprawi Baking. :)

Napisano

@Monio i oby tak dalej. Miałem podobnie z PBR, teraz działa i testuje. Zabawa z Fracture też dawała sporo przyjemności.

Oczywiście czasami człowiek się łapie na tym, że skoro to działa w bulidzie to przychodzi na myśli: "szybciej Panowie"

Pomyśleć że kiedyś uważałem BGE za bezużyteczny element, a dziś pracuje nad minigierką. ;)

Napisano (edytowane)

@rice

WY...STRZELONE w kosmos! Coś niesamowitego, fajnie że udostępnił na YT:P

Edytowane przez Idaho
Napisano (edytowane)

http://vadrouillegraphique.blogspot.co.uk/2014/07/new-versions-of-gao-and-gao2-ambient.html

 

Gość poprawił OSLowy skrypt do AO. Dodał oversampling co oznacza że będzie dawał odpowiednie rezultaty w bakeu. :)

 

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

 

http://mont29.wordpress.com/2014/08/01/custom-split-normals-first-testbuild-available/

 

Piewszy build z Custom vertex normalami. Możliwość przetransferowania normali z innego obiektu lub przez elipsoid o wymiarach bounding boxa! Kiedy to wejdzie do mastera ostatnia brakująca duża funkcja dotycząca edycji siatek znajdzie się w blenderze. Jeszcze tylko niech ktoś zrobi addon do "czesania" normali jak particli włosów to będę mógł umrzeć w spokoju.

Edytowane przez Monio
Napisano

Inaczej niż w przypadku interfaceu bo niektórzy z nich twierdzą że nie ma nic złego w workflow gdzie nakład pracy jest 100 razy większy niż mógłby być

 

Niestety mam wrażenie, że jest to ogólny problem wielu developerów Blendera, łącznie z "górą" - stawianie nie na jakość wykonania czy wygodę użycia, ale na ilość, tak jakby jakość softu mierzona była wyłącznie liczbą funkcji, jakie posiada.

 

A żeby nie było, żem hejter, to odrobina samokrytyki. Przypomina mi się taka całkiem niedawna sytuacja, gdy w robocie dostawałem pewne dane w formie pliku txt. Z plików tych musiałem wyciągnąć niektóre wpisy, aby scalić to w raport. Oczywiście, jak to ja, ręczna dłubanina mi nie odpowiadała, wolałem sobie to zautomatyzować. Jako że programista ze mnie żaden, postanowiłem użyć Excela. Chodziło o stworzenie arkusza, w którym w jednej zakładce importuję surowy tekst, z kolei druga zakładka wyszukuje odpowiednie komórki, scala, liczy, robi inne wariacje, po czym trzecia wypluwa gotowy raport. Przesiedziałem nad tym z pół dnia, kombinowałem, walczyłem. Aż wtem - JEST! Dzieło ukończone. Zacząłem testować. Pliki oczywiście rzadko były standardowe, więc musiałem je ręcznie dostosowywać do możliwości arkusza. Czasem dane wpisane były błędnie (np. z kropką zamiast przecinka). Czasem długość pewnych bloków się nie zgadzała. Finalnie, gdy policzyłem sobie, ile czasu zajmuje mi takie dostosowanie pliku txt, żeby arkusz działał jak należy, zdałem sobie sprawę, że znacznie szybciej i prościej będzie mi użyć kalkulatora i policzyć ręcznie niż stosować ten pożal się boże "program". Plik poszedł do śmieci, cały dzień (łącznie z testowaniem) w plecy.

 

Morał z tej mojej wpadki jest taki, że nie sztuka zrobić coś, co JAKOŚ działa. Sztuka zrobić coś, co działa DOBRZE. A niestety wiele funkcji w Blenderze owszem, działa, ale zaledwie "jakoś"... Przy takim podejściu developerów do funkcjonalności Blender nigdy nie wybije się poza miano zabawki głównie dla amatorów - większe firmy będą wolały zapłacić i mieć program może i drogi, ale robiący to, co chcą, w sposób przejrzysty, szybki i wygodny. A szkoda, bo imho potencjał w Blenderze jest ogromny, trochę bez sensu, że marnuje się przez pokraczne podejście do funkcjonalności i wygody użytkowania.

Napisano

Nie moge sie juz doczekac az ludzie dla odmiany zaczna narzekac znowu na nowa wersje ZBrusha, jak to w nim tez sie niewygodnie pracuje. Temat Blendera jakos mi sie juz przejadl.

Napisano

Yeah. Zrobię kiedyś tutorial "Jak nauczyć się podstaw interfaceu Zbrusha w PIE***ONE 5 SEKUND". Nawet wczoraj musiałem gościowi tłumaczyć że elementy interfaceu zetki są logicznie poukładane a floating menu jest tylko dodatkiem. Miliard ludzi narzeka że nie mogą się odnaleźć w tych buttonach, ciekawe czemu nie narzekają że w shelfie w majce też są buttony które można znaleźć również w menusach.

Napisano

Mimo, ze to przewidzialem wciaz nie moglem sie nadziwic faktem, ze ktos na ZB central na prawde oczekuje CALKOWITEJ zmiany UI :D Choc juz nikt nie "straszy", ze jak nie zmienia UI to przesiada sie na Mudboxa. Ale wciaz jest szansa za kilka dni przeczytac takie cuda znowu, mimo, ze rozwoj Mudboxa zaczyna przypominac rozwoj Silo.

Napisano

HFdmFku.png

 

Proceduralki w cyclesie to fun na maksa, robię w nim już 4 obiekt do gry. Cała texa w obrazku powyżej jest proceduralna. Zero obrazków czy vertex painta, obiekt nie żadnego UV (hipoly). Jednym suwakiem steruje się ilością segmentów, edytując rampy można wpływać na kształt segmentów, wielkość dziurek, szerokość odstępów. Na razie to sam kolor diffuse ale z tych nodów które mam szybko wysmażę inputy do glossy i bejkuje. :)

 

Będzie bosko jak zabiorą się za proceduralki. Powinni w końcu przenieść wszystkie opcje z internala. To by była potęga. :)

Napisano

jednego mi brakuje w teksturach w cycles. Bardzo prostego konceptu: noda, który dodawał by do nich rozmycie/blur.

Można by było wtedy wziąć cokolwiek, nawet bitmapę i odjąć ją od swojej rozmytej kopii i dostać coś jakby kontur.

W sumie to jeszcze by się dilate i erode przydało... Ale nawet sam blur by wystarczył, bo bym sobie go mógł rampami poprawić dostając dilate i erode.

Wie ktoś o jakichś planach filtrowania tekstur wewnątrz cyclesa?

Napisano

Nie widziałem żadnych działań w tym temacie. Również mi brakuje takiej nody a to przecież banał do zrobienia. To co można zrobić teraz to blur wektorów ale potrzeba do tego masy sampli żeby się odszumiło i obstawiam że musi działać tragicznie z normalkami i bumpami.

 

gOA1PX2.jpg

 

http://www.pasteall.org/blend/30850

Napisano

Do dzieła. Masz moj miecz. Uwzglednij takie rzeczy jak blurowanie tilowanych tekstur, blur kierunkowy i wektory uv. To doda fajne możliwości, bedzie sie dalo rozmazać texy proceduralkami. Fajnie by bylo jakby dalo sie blurowac obrazki enviro tak zeby boki texy sie przenikaly ale gora i dół już nie.

Napisano

Nie będzie Pie menusów w podstawowym blenderze... Będzie wbudowany addon wyłączony w standardzie, bo Tonowi się nie podoba że trzeba przytrzymać przycisk... Sam addon będzie miał tylko 3 małe menusy które nadpiszą istniejące menu a resztę za developerów maja załatwić goście od pisania pythonowych addonów. Skacze ku**a z radości. Oficjalnym sloganem Blendera powinno zostać "Zmarnowany potencjał".

Napisano
No i za chwile sie zacznie znowu ta sama dyskusja.... :)

 

a to dobrze się składa, właśnie wróciłem z urlopu, a tutaj zapowiada się nowa seria komentarzy...

czekam aż dołączą fani teorii spiskowych.

Napisano

@Monio

Zastanawiam się czy Ton przypadkiem nie przechodzi jakiegoś kryzysu. Tak jakby go zaczęła przerażać/przerastać zbytnia popularność blendera. Stąd może wynikać delikatne sabotowanie - może to za mocne słowo ale na pewno próba lekkiego spowolnienia. Wcześniej ogarniał wszystko bo działało to na zasadzie św. Mikołaja i Gwiazdki. Nikt nie czekał na jakiś konkretny feature przez co devi nie byli naciskani a tu nagle booom i jest coś nowego, no i apetyt wzrósł a ludzie na potęgę wołają o konkrety. Jak wolisz pracować gdy masz wolną rękę czy gdy grupa osób z pretensjami domaga się konkretnych rozwiązań. Ton może zauważył że to już nie jest taka zabawa jak wtedy gdy bawił się w św. Mikołaja.

Napisano

Czy ktoś z kolegów aktywnie śledzących rozwój może powiedzieć czy dzieje się coś w kwestii kanału Alpha dla VertexPaint? Od czasu do czasu doskwiera mi brak tej funkcjonalności i ciekaw jestem czy są jakieś widoki na poprawę.

Napisano

Dzięki za odpowiedzi. Generalnie chciałem się dowiedzieć czy są widoki na wygodny workflow w tej kwestii, łącznie z podglądem efektu w viewporcie. Skrypt na forum Unity widziałem, jest to coś podobnego do metody z filmu floo, ale moim zdaniem użyteczność tych rozwiązań jest na strasznie niskim poziomie. Wygodniej jest mi malować po meshach bezpośrednio w Unity. Szczerze mówiąc nie rozumiem podejścia twórców do tego tematu... Taka, wydawałoby się, podstawowa rzecz :]

Napisano

@arev niestety Game Art jest mocno zaniedbywany przez community. Podstawowe rzeczy leżą i czekają na lepsze czasy.Teraz coś ruszyło z FBX, PBR oraz wypalaniem w Cycles, ale apetyt rośnie w miarę jedzenia.

 

Możliwość tworzenia to troszkę zbyt mało, gdy integracja z silnikami wypada przeciętnie. Promocja w tym kierunku z pewnością pomogła by społeczności w uzyskaniu większej liczby doświadczonych twórców, co przekłada się na popularność softu oraz jego bezpośredni rozwój. Tyle że jak wiadomo liczy się czas i nikt dziś nie chce słyszeć o problemach. Lepiej zapłacić i liczyć na to że resztą rzeczy można sobie poradzić.

Napisano

@arev, floo

 

Blender Institute powinno w końcu ruszyć zadek z Game Artem, a nie ciągle te filmy i filmy :/ Teraz jest na to większa szansa, bo pojawił się całkiem do rzeczy Open Sourceowy silnik Godot Engine, ale Ton mi nie wygląda na gracza...

 

@Monio

 

Choć chętnie ponarzekałbym na ostatnie ogólnie rozumiane podejście Tona, to z Pie Menusami nie jest tak źle.

Dalej są napisane low levelowo i są teraz integralną częścią Blendera. Addon o którym mowa to tylko kolekcja menusów, która z czasem pewnie będzie rosła. Przykładowo ja, prawdopodobnie nie będę ich używać :D

Wole napisać własną kolekcje pod moje workflow, a tworzenie nowych placków jest mega proste :) (no jeśli znasz już trochę Python API Blendera...).

 

Tak czy inaczej, PIE MENUS TO POTĘGA! Najlepszy ficzer od czasów bmesh i cycles.

 

Co mnie osobiście mega boli i czego kompletnie nie rozumiem to, dlaczego AO node zniknął z listy nowych funkcji do zrobienia! Był na niej przez 3 wersje odkładany, a teraz kompletnie zniknął! :mad: WTF DingTo.

Napisano

@n-pigeon wyjdzie na to że się upieram, ale wszystko opiera się o promocje. Podam taki przykład gry: I Will Escape

[video=youtube_share;P1BEtANSl50]

[video=youtube_share;Ey0CuG4LD7Y]

 

trafiła obecnie na Steam GreenLight! Nie jest to jakaś hiper produkcja, ale pokazuje że można wiele się nauczyć. Wiadomo że każdy silnik jest inny, ale proces tworzenia bardzo zbliżony. Możliwe że moc przerobowa fundacji gdzieś się kończy. Mnie najbardziej ciekawi, to jak długo trwa dodawanie elementów takich jak PBR do oficjalnej wersji. Nie zawsze wszystko można przecież obejść tworząc addon, choć mogę się w tej kwestii mylić.

Napisano

Wracając do bake w cyclesie. W tym tygodniu męczyłem tematykę semi-proceduralnego generowania obiektów w blenderze Zastanawia mnie, że bake tej samej geometrii w formie jednego obiektu a w formie kilkuset obiektów to zupełnie inna historia - czas bejkowania wydłuża się o x razy, gdzie x=ilość obiektów, tak jakby za każdym razem liczył sample od początku. Pytanie na ile to specyfika kodu napisanego przez Dfelinto, a na ile specyfika architektury cyclesa. Dfelinto wspomniał, że w przeciwieństwie do BI, nie będzie możliwości realtimowego poglądu bejkowania, mimo, że dodał pasek postępu itd.Paradoskalnie przy bejku wielu obiektów pogląd mapy w oknie UV uaktualnia się*per object :), ciekawe czy faktycznie nie mogłoby odbywać*się per face? Przy tych wszystkich możliwościach tworzenia nieskończonej ilości shaderów w cyclesie plus OSL, bake ma potencjał.

 

Ktoś korzystał już z addona baketool, jakieś opinie?

 

To co cieszy mnie najbardziej w zbliżającym się B 2.72 to fakt, że wylądują tam fajne bajery z GSOC2013 dla texture painting i sculptu http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.72/Painting

MaskPressure.png

 

Curve_stroke_gsoc2013.png

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