Ta sekcja pozwala Ci zobaczyć wszystkie wiadomości wysłane przez tego użytkownika. Zwróć uwagę, że możesz widzieć tylko wiadomości wysłane w działach do których masz aktualnie dostęp.
Osobiście jestem bardzo niepocieszony tą informacją. Jak to pierwszy raz przeczytałem, to aż zamarłem, społeczność też nie wydaje się być specjalnie zadowolona. Najbardziej boli mnie kwestia licencji. Substance Painter to był chyba jedyny program, który w moim odczuciu oferował adekwatny do ceny zestaw narzędzi. Ba, nawet oferował więcej niż można się było w tej cenie spodziewać, a dochodziły przecież jeszcze zniżki lojalnościowe. Przede wszystkim licencję można było kupić wieczystą, ze wsparciem technicznym na rok - według mnie uczciwy układ tak dla firmy, jak i użytkownika. Chcesz nowych funkcji po roku użytkowania - wykup nową wersję. Nie chcesz, nie potrzebujesz ich - w porządku, korzystaj z poprzedniej wersji jak długo chcesz, w końcu za nią zapłaciłeś, nikomu nic do tego. Ludki z Adobe co prawda na razie zarzekają się, że nie będą ingerować w te kwestie, ale pogadamy za 2-3 lata. Absolutnie im nie wierzę. Zresztą chyba już nawet zdążyli zapowiedzieć jakiś "atrakcyjny model subskrypcji", obok wieczystych licencji. Wcześniej czy później jestem święcie przekonany, że zostanie sama opcja subskrypcji. I to mnie boli.
Też na razie odpuszczam 2.8. Pobieram co jakiś czas nowe wersje i śledzę postęp, żeby być na bieżąco, ale do niczego konkretnego na razie nie używam. Oprócz Shrinkwrapa mam jeszcze problem z SSS w Eevee. Na ilu komputerach nie sprawdzałem, to wszędzie działało, ale jak na złość na jednym jedynym - na moim - choćbym nie wiem co robił, to SSS w Eevee nie działa. Obiekt robi się czarny i kicha. Aktualnie korzystam z 2.79.5, czyli 2.79 z kilkoma dodatkami z 2.8. Jak na razie sprawdza się super. Pewnie przy nim zostanę do którejś z kolei wersji 2.8, gdy będzie się dało już na spokojnie z niej korzystać. Finalna animacja początkowo miała być renderowana w Eevee, ale gdy trochę się tym silnikiem pobawiłem, to jednak stwierdziłem, że zostaję przy Cyclesie. Realtime to jednak realtime - mimo, że imponujący, to jednak nie to samo co prawdziwy Ray Tracing. Tak więc finalna animacja zdecydowanie będzie renderowana w Cycku. Ale nie ma tego złego, bo wiem, że Eevee też się przyda - do próbnych renderów będzie idealny, bo robi super robotę. Efekt jest wystarczająco zbliżony do Cyclesa, by można było sobie wiarygodnie zwizualizować efekt końcowy i ewentualnie wyłapać błędy.
Hmm... może to przez ten widok en face. Choć pewnie tryb wyświetlania Texture z viewportu też na to wpływa. Zresztą, to jeszcze nic - jak testowałem fizykę włosów z ukrytymi rzęsami i brwiami w widoku Material, to dopiero dziwnie wyglądało. Naprawdę, niesamowite jak bardzo brak rzęs potrafi wpłynąć na wygląd twarzy postaci. Też jestem ciekawy jakby to wyglądało z soczewką na oku, ale na to przyjdzie jeszcze czas. Może jakieś poglądowe rendery będę sobie w Eevee robił, ale najpierw muszę sobie poradzić z materiałem włosów w tym silniku. Zobaczymy, przy robieniu finalnej animacji na pewno się przyda. W ogóle - tylko ja tak mam, że w Blenderze 2.8 modyfikator Shrinkwrap jest mocno skopany? Działać niby działa, ale zmiana jakichkolwiek parametrów albo w ogóle nic nie daje, albo działa w jakiś dziwny, losowy sposób. Wiem, że to wciąż beta, ale nie widziałem by ktoś na to narzekał.
Dzięki. Cóż, całość jest tylko i wyłącznie mojego autorstwa. Gdyby się uprzeć, to można by co najwyżej wskazać jakieś źródła inspiracji, ale te raczej wpływają na moją motywację do pracy niż na tematykę/mini scenariusz samej animacji. Więc tak, sam to wymyślam. Zastanawiam się tylko, czy może by nie poszukać kogoś do pomocy przy dźwięku, bo sam się na tym kompletnie nie znam. Fajnie by było też mieć kogoś do podłożenia głosu pod postać, bo zawsze to daje trochę więcej możliwości, gdy postać może mówić. Ale to już takie moje raczej marzenie
Prawda jest taka, że też na początku myślałem, że to jest kwestia tych dwóch parametrów. Sęk w tym, że nawet po ustawieniu ich na maksymalne możliwe wartości problem wciąż występuje. Wypalać też próbowałem, ale opóźnienie i tak zostawało. Bardzo prawdopodobne jest, że opóźnienie wynika z hierarchii obiektów i zdaje sobie z tego sprawę. Sęk w tym, że nie bardzo jest to jak obejść. Docelowo kolczyk będzie musiał być sparentowany do kości, nie do mesha. Pojedyncza kość nie może mieć fizyki Rigid Body, nie może też być wybrana jako cel dla Rigid Body Constraint (jedynie cały szkielet). Stąd konieczność podpięcia najpierw jednego obiektu, na którym będzie "zawieszony" kolczyk, a potem drugiego, który będzie sobie dyndał. No i się tworzy łańcuch obiektów, który nie bardzo jest jak skrócić.
Cytuj
Warto zaznaczyć, że constraintsy zawsze są trochę gumowate, co ujawnia się szczególnie przy gwałtownych ruchach.
Szczerze mówiąc trochę kicha w takim razie.
Tak czy siak, jeśli chodzi o kolczyk, udało mi się jako-tako rozwiązać problem. Działa to mniej więcej tak: cała hierarchia podpiętych obiektów zostaje jak była. Czyli mamy jeden obiekt robiący za cel dla Rigid Body Constraint (w tym wypadku Torus.001), i drugi - dyndający sobie i symulujący właściwą fizykę (Torus.002). Oprócz tego dochodzi dodatkowa kość, do której podpięty jest docelowy mesh kolczyka. Kość ma modyfikator IK, a jako cel ustawiony obiekt Torus.002. Symulacja dalej działa z opóźnieniem, ale wizualnie wszystko wygląda tak, jak powinno. Nawet jeśli przy szybkim ruchu głową obiekt Rigid Body wyleci poza swój zakres ruchu, to kość wizualnie sterująca kolczykiem wciąż będzie na swoim miejscu, jedynie obracając się w kierunku docelowego obiektu. Mam nadzieję, że w miarę wiadomo o co mi chodzi.
To jednak tyczy się tylko symulacji Rigid Body, w której obiekt jedynie się obraca. Potrzebuję jeszcze jakiegoś rozwiązania dla obiektu, który ma też pewną swobodę w przesuwaniu się. Zobaczymy, może uda mi się coś wykombinować i w tym przypadku.
No więc problem mam taki, że gdy używam Rigid Body Constraint do symulacji dyndającego obiektu, całość działa z pewnym opóźnieniem. W tym przypadku mam głowę z kolczykiem w uchu. Wyraźnie widać, że kolczyk nie nadąża za ruchem głowy i w niektórych klatkach w ogóle jest oderwany od całości. Ktoś, coś?
Ok, czas na małą aktualizację. Mimika prawie skończona, więc postanowiłem wyrenderować kilka próbnych ujęć na buźkę. Jak to zwykle bywa, dopiero "w praniu", podczas ustawiania poszczególnych min wyszło mi kilka rzeczy do poprawy w mimice. Tak, że czeka mnie jeszcze kilka poprawek, ale mniej więcej już widać jak to wszystko wygląda i działa. Reszta ciała jeszcze nie jest do końca zrigowana, ale gdy już będzie, to oczywiście też zrobię kilka próbnych renderów z jakimiś pozami. Od ostatniego razu popracowałem też trochę nad światłem i wydaje mi się, że teraz prezentuje się to lepiej.
W moim przypadku to są akurat pojedyncze miejsca na teksturze, które świecą. Choć w razie potrzeby wiadomo - zawsze można by to było rozdzielić, żeby materiał emission mieć osobno. Ale to i tak nic z tego, bo po ID materiału czy obiektu również nie udawało mi się wyciągnąć żadnych informacji jeśli obiekt znajdował się za szkłem. No nic, wygląda na to, że jedyny sensowny sposób to ponowne wyrenderowanie obrazka z widocznym samym emiterem. Poeksperymentuję trochę, może uda mi się osiągnąć rozsądny czas renderowania jakąś właśnie mniejszą liczbą sampli, przyciętą rozdziałką itd. W każdym razie dzięki za pomoc.
Działać niby działa, ale niestety wciąż nie rozwiązuje problemu. Sęk w tym, że nie chcę (i nawet nie za bardzo mogę) bazować na podstawowym renderze - musi to być jakaś maska zawierająca informacje tylko i wyłącznie o elementach z materiałem emitującym światło. To dlatego, że na docelowym renderze emitowane światło nie jest zbyt silne, w dodatku jest blado czerwone, a na scenie znajdują się też elementy białe, a więc de facto ich kolor jest nawet jaśniejszy niż tych elementów, które faktycznie świecą. To po pierwsze, a po drugie docelowy render to animacja, więc w zasadzie w różnych klatkach zakresy jasności, najjaśniejszy, najciemniejszy obiekt mogą być różne. Dlatego tym ColorRampem też nie bardzo mogę zdziałać, potrzeba czegoś bardziej uniwersalnego. Sporo wczoraj szukałem w google i okazuje się, że chyba nie bardzo da się cokolwiek z tym fantem zrobić. Dla blendera jeśli coś jest zasłonięte szkłem, to jest traktowane jakby było niewidoczne. Zniekształcony refrakcją obraz to dla renderera tylko powyginany zbitek pikseli - nie da się z tego wyciągnąć informacji skąd dany piksel pochodzi. Trochę kicha. Jedyne co udało mi się wymyślić, to by wyłączyć wszystkie źródła światła, być może też ustawić wszystkim materiałom czarny kolor, a jedynie materiały emission zostawić tak jak były. W ten sposób otrzymałbym czarny render, na którym widoczne są jedynie materiały emission, nawet zniekształcone refrakcją - czyli dokładnie tak, jak potrzebuję. Sęk w tym, że biorąc pod uwagę, że docelowo ma to być animacja, to renderowanie osobno drugi raz każdej klatki może być z lekka kłopotliwe.
Hmm... no faktycznie działa. Z tym, że tylko jeśli ta duża kostka ma Transparent BSDF - gdy zmieni się na Glass BSDF, to obiekt w środku znowu znika na warstwie Emission. Sprawdziłem czy nie jest to kwestia refrakcji, ale nawet przy parametrze IOR ustawionym na 1.0 problem wciąż występuje. Choć podejrzewam, że dla renderera nie liczy wartość tego parametru a sama jego obecność.
No więc jest taka sprawa, że chciałem dodać efekt glare tylko do elementów na scenie, których materiały emitują światło. No więc w zakładce Passes włączyłem Emission, wyrenderowałem i w postprocesach próbuję dodać efekt glare do warstwy Emit. Ku mojemu zdziwieniu - zupełnie nic to nie dało. Spróbowałem więc podpiąć pod Viewera samą warstwę Emit i okazuje się, że jest całkowicie pusta. Zrobiłem testową scenę i okazuje się, że jeśli materiał emitujący światło jest zasłonięty przezroczystym obiektem (np. szkłem), to na warstwie emission jest on niewidoczny. Ktoś ma pomysł jak to obejść?
Pokaż wiadomości
Blenderownia RSS - Forum