n-pigeon

@Lucas Hmm nie mam pojęcia czym jest Null shader, ale w Cycles jest shader o nazwie Holdout, generalnie tworzy po prostu transparentą dziurę w renderze, może dało by się to jakoś połączyć z warstwami, tak by robiło wyrwę z jednej warstwy do drugiej? To tylko moje gdybanie nigdy czegoś takiego nie próbowałem.

Niewiele da się zrobić, użyj Polish Brush.

Nie ma :) To jest piękno sculptu, można się zaorać czyszcząc i smoothując artefakty :)

@ikkiz Dlatego też je cenzurujemy :)

Obrazki standardowo mielą mózg. No i te kropelki ;) Standardowe Omenowe cząsteczkowe FXy, zawsze miło je zobaczyć :D Jedyna uwaga to roślinność głównie liście, warto było, by je trochę zaokrąglić, dodać im więcej organiki, by nie było tak widoczne, że to tex na płaskim plane. Trochę liquify filter - czy jak to się nazywa w szopie - może trochę mocniej je podmalować pędzlem, ale to jedyne co mnie kłuje, reszta wymiata :)

A se postne co mi tam :D Tweeter Tona: Fragmentem "we are waiting for them to support us!" nie należy się przejmować to żart :) Jest jak pisałem Alembic jest w planach tylko czeka na swoją kolej.

to taka pRo-mocja, dodatkowe "r" gratis do każdego posta

No właśnie chciałem pisać, że to alexx600 xD. Ja niestety nie potestuje, nie mam maxa :D, ale śledzę co się z tym dzieje, bo może się kiedyś przydać.

Heh fajny filmik z Mesh Cache Modif i tworzeniem tłumu xD

Nie tylko w Maxie i jest to podstawowe założenie używania point cache'y. Oświetleniowcy nie ruszają plików używanych przez animatorów. Kości itp. muszą przeliczać deformacje w locie, czyli obciąża to maszynę (CPU) i wpływa na szybkość aktualizacji klatek, dodatkowo zwiększa zużycie ramu, co jest uciążliwe przy renderowaniu. Point cache streamuje gotowe pozycje punktów z dysku w wydajny sposób i dlatego oświetleniowcy i renderer są szczęśliwi :) (no chyba że crunchują...). Mookie, no ty raczej o tym wiesz, ale pisze tak do ogółu którego interesuje czym jest ten point cache i do czego jest. Jeśli ktoś chce dowiedzieć się trochę więcej o technicznej stronie point cache'y i o Alembic polecam to video, prezentacja pracowników SPI i ILM którzy stworzyli Alembic: http://www.youtube.com/watch?v=I__MeR8jsFk

@mookie Miodzio! Nawet trzeba, jeśli jest to animacja obiektu, to point cache tego nie chwyci. Animuje to jedynie same vertexy w ich własnym układzie, przesuwasz pivot obiektu, przesuwasz animowany obiekt razem z animacją. Jeśli oczywiście postać jest jako całość przemieszczana przez kość "master/root" pod którą są podpięte inne kości to to również będzie uznane za "deformacje" i MCM będzie animował to przemieszczanie się "aktora", ale cały układ dalej możemy przesunąć jako obiekt w dowolne miejsce, bez psucia animacji. Super sprawa przy niektórych animacjach tłumu ;) No FBX i Collada mają trochę inne use-case niż point cache'e, takie formaty służą by w kilku programach edytować w miarę niedestruktywnie assety i aktorów, a point cache ma ułatwić dalszą pracę/obróbkę _sceny_ z gotową animacją/symulacją aktorów. Alembic na bank zagości w Blenderze, to ile można dzięki niemu odchudzić point cache'e na pewno będzie kusić ;) Tylko ten modyfikator został zrobiony przez jakiegoś programistę zatrudnionego przez studio które używa Blendera, nie został od razu zaimplementowany ponieważ wyżej wspomniane studio używało pc2 i mdd. Alembic to fajna technologia i OpenSource. Moim zdaniem Alembic powinien być pełnoprawnym członkiem w Blenderze i być używany przez defaultowy Blenderowy pipeline. Wielu koderów ma podobne zdanie więc prawdopodonie tak się stanie, ale jeszcze mnożą pomysły jak wykorzystać w przyłości Alembic, w tym jako format tymczasowych cache dla Blenderowych symulacji. Niestety to też powód czemu to zajmie trochę więcej czasu, _dobry design_, ale myślę, że w samym modyfikatorze ujrzymy support dla Alembic wcześniej.

@Gandalf244442 Nie ten wątek, chodziło Ci o Szybkie odpowiedzi na proste pytania ;P @Idaho Nope @floo Jeśli ten skrypt, też aktualizuje pozycje vertexów, a nie tylko ładuje pliki do klatek, to się pokrywają z Mesh-cache modifer, ale MCM będzie wydajniejszy i używa prawdziwych formatów point cache'a, które mają mniejsze rozmiary niż OBJ i prawdopodobnie szybszy odczyt. No i zawsze łatwiej operować jednym plikiem. Ten skrypt działczy z modyfikatorami? Jak do wspieranych formatów dojdzie jeszcze Alembic to już w ogóle będzie miodzio :)

@mookie, aha szkoda, ja robiłem tylko prosty test, działało, ale byłem ciekaw jak tam się to ma z czymś cięższym. Hmm, albo użyłeś nieaktualnego cache'a albo któryś exporter/importer zmienił Ci kolejność vertów. Edit: heh zauważyłem, że taka sama informacja jest wyświetlana, jeśli się nie ustawi PC2 zamiast MDD w modyfikatorze. Tak :) Tak, trzeba odpalić scenę z assetami bez animacji deformacji, mesh-cache modifier będzie aktualizował pozycję vertexów dla każdej klatki. Idea polega na tym, by podczas prac nad oświetleniem i renderingiem procek nie był obciążany obliczeniami deformacji siatki: kości, modyfikatory, shape keys, symulacje itd :) Modyfikator po prostu ładuje pozycje z cache'a w wydajny sposób. Pozycje vertexów są w Local Space i nadpisują całkowicie oryginalne pozycje. Obiekty w scenie muszą mieć swoje stare animacje, zmiany pozycji, rotacji i skalowania, cache modyfikuje jedynie vertexy - deformacje. No właśnie też jestem ciekaw, sam .pc2 to raczej nie problem, tylko wyexportowanie assetu z jednego progamu do drugiego tak by porządek vertexów nie został naruszony.

@mookie Testowałeś nowy Mesh-chache modif?

Matcapy w Trunku! :) http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.66/Usability#Matcap_in_3D_viewport

Wzrośnie ogólnie wydajność, w sculpcie pewnie też. Tylko wydajność sculptu nie zależy aż tak bardzo od renderowania poly... jeśli ktoś nie używa eksponatu muzealnego to viewport sculptu spokojnie wyrenderuje miliony poly z tak prostym shadingiem jakiego używa Solid Mode. Wydajność sculptu tkwi w transformowaniu samych vertexów, a więc zależy głównie jak wydajny jest multires modifier i brush engine, a nie sam view port. Oznacza to, że jeśli masz nową kartę, a sculpt działa wolno przy pędzelkowaniu, to wąskim gardłem są obliczenia CPU nie GPU. Blender przed translacją vertexów za pomocą brusha, wykrywa które vertexy będą brały udział w translacji tak by nie odświeżać całego mesha tylko jego fragment, potem dopiero są te vertexy transformowane do nowej pozycji i to trwa najdłużej, im gęstsza siatka tym więcej trzeba przeliczyć. Potem nowe pozycje tych wybranych vertexów są wysyłane do karty graficznej, by je ponownie wyrenderować. Przyspieszenie view portu sprawi, że obracanie i poruszanie się po scenach gdzie jest dużo poly będzie płynniejsze, podobnie animacja (recode Deps Graphu też przyspieszy renderowanie animacji) oraz Edit Mode który musi rysować znacznie więcej niż Sculpt Mode, ale wątpię by pędzelkowanie zyskało dużego busta w porównaniu do tego ile zyskają inne tryby, ale nie wiem jak bardzo wzrośnie wydajność, tego się dowiemy kiedy ukończą projekt. PS Dependency Graph również przyspieszy Blendera w różnych miejscach w tym viewport, też warto śledzić co się dzieje.

W tym roku ma pojawić się nowy silnik viewportu, nie wiadomo ile zajmie jego skończenie, więc na razie trzeba brać to na chłodno ;) Nie przejmowałbym się psioczeniem na OGL 3 i 4, OGL to nie DX :) Jest kompatybilny sam z sobą wstecz ;) Jak Jason sam tłumaczył, silnik będzie wykorzystywał głównie funkcje OGL 1.1 minus funkcje uznane za przestarzałe i tyle, to jest Core OGL, wszystkie dodatkowe nowsze funkcje to rozszerzenia które mogą być po prostu nieaktywne jeśli użytkownik ma za starą kartę, ale Blender będzie działczył tak czy inaczej. Głównym zadaniem nowego Core Viewportu jest po prostu modernizacja i ujednolicenie kodu, który obecnie używa wielu przestarzałych funkcji i jest rozrzucony po całym Blenderze. Chodzi głównie o to, by łatwiej było ten silnik konserwować oraz rozszerzać, dopiero następnym krokiem jest dodanie ficzersów/efektów (FX), które mogą spokojnie korzystać z nowszych funkcji OGL. PS Dla zdrowia psychicznego nie czytaj postów FreeMind'a :P

tutaj nie ma offtopów dopóki chodzi o blendera lub cg ;P

Nope, Jason Wilkins od swojego tegorocznego GSoC nad nim pracuje, w tą niedziele trochę dyskutowali o tym projekcie z Tonem. Prawdopodobnie zostanie finalizowany razem z recodem Dependency Graphu, tyle wiem :D A więc wiadomo tylko tyle, że chodzi o rok 2013 :D

@Monio Nie, zupełnie nie o to chdzi. Flat i smooth shading raczej będzie działać. Chodziło mi o to, że obecnie Solid mode może wyświetlać jedynie używając vertex shadingu (gauraud), a mi się marzy opcja z pixel shadingiem (fragment/phong shading), w smooth mode przejścia gradientów miedzy vertexami były by dzięki temu gładsze :/ no nic muszę chyba poczekać na przepisany view port. Co do .obj nie mam pojęcia :B

Obsługa MDD... pff, pfffffff, jak ty żeś to napisał, powinno być: Mesh-cache modifier w Trunk! Obsługuje formaty MDD i PC2! Jeja! \o/ wiki: http://wiki.blender.org/index.php/Doc:2.6/Manual/Modifiers/Deform/Mesh_Cache To baaaaardzo ważna i przydatna rzecz :D teraz tylko czekać na obsługę Alembic :) Blender wzbogacił się właśnie kolejną ważną "production feature" ;) Do tego Ton pokazał sneek-peek matcapów, ale kurna czy ja tam widze gauraud shading? Mam nadzieje, że tylko mi się wydaje bo będę zawiedziony...

Nie mam do Ciebie pretencji, tylko tłumacze jak rzeczywiście to działa. Nie jest tak jak mówisz, masz prawo tego nie wiedzieć, ale ja wiem i dlatego opowiadam jak to wygląda od kuchni. ;) Nikt nie twierdzi, że punkt widzenia użytkownika nie jest istotny, ja tego nie mówiłem. Stwierdziłem jedynie fakt, że użytkownik gówno wie, wie tylko to co chce, developer ma świadomość wielu rzeczy których użytkownik nawet nie rozumie, a użytkownik wie czego oczekuje. Rozwijanie projektu takiego jak Blender polega na współpracy tych grup, co jest czynione. Gdyby developerzy rozwijali Blendera tak jak użytkownicy sobie tego życzą, to by wszystko się rozchodziło o świecidełka i ładne funkcje, a przecież w poprzednim poście to krytykowałeś. Wszystkie stare problemy z czasem znikną, pojawią się na ich miejsce nowe. :) Jako użytkownicy możemy jedynie raportować błędy, a jeśli coś przykrywa kurz to co jakiś czas grzecznie odkopać ;) zapytać jaki jest tego status i trele morele. Devy mają tyle roboty, że nawet nie wiedzą w co ręce włożyć... ale słuchają się opinii użytkowników, powiem, że nawet więcej niż kiedyś, bo pojawiło się dużo nowych entuzjastycznych developerów i starzy mają mniej roboty przy niektórych rzeczach, i ToDo się już tak nie piętrzą jak kiedyś. Szkoda, że Gimp nie ma takiego szczęścia :D może jak opadnie kurz po GEGLu i GTK 3 :) Nie przejęzyczyłem się, to co jest robione to głównie zależy od tego co się komu chce, to jest projekt rozwijany przez pasjonatów, nie roboli którym się kazało. Niektóre rzeczy stają się z czasem tak upierdliwe, że następuje pospolite ruszenie, inne są robione ponieważ ktoś się zainteresował jakąś tematyką i chce przy niej popracować, inni robią rożne rzeczy, nawet np. naprawiają bugi, dla sportu, bo lubią urozmaiconą robotę, drobniejsze zadania. To hobby :) tak jak u Ciebie modelowanie samolotów, gdyby naglę ktoś kazał Ci modelować coś innego prawdopodobnie nie wkładał byś w to już tyle serca, tak samo działa to u devów. To ma swoje wady i zalety, zaletą jest to, że nie robią na odwal ;P nawet jak coś nie jest ukończone na takim poziomie funkcjonalnym jak np. maxowe pluginy rozwijane od jakiegoś czasu, to kod od strony projektowej i wykonania jest zrobiony jak należy, dzięki czemu można z tym działać potem dalej, np. symulacja dymu tak miała :) najpierw powstał symulator dymu, niespecjalnie bogaty, ale wykonany starannie, potem ktoś dodał dodatkowe funkcje dla ognia i jeszcze coś tam podrasował i tak będzie się to powtarzać co jakiś czas. Blender to strasznie duży projekt, to co Ci ludzie z nim robią to jest coś niebywałego. :) Powodzenia z tym knifem, by coś się ruszyło w miarę szybko ;) ja teraz wyczekuje nowego modyfikatora oraz kolizji i automerga w Bevel. :)

Właśnie o to mi chodzi oceniasz sytuacje całkowicie z perspektywy widza/użytkownika. Każdy z nas wie jakie ficzery mile by widział tu i teraz, ale koderzy nie patrzą na to z tej perspektywy, co jest użyteczne, co jest podstawowe. Oni po prostu organizują sobie prace, biorą pod uwagę swoją wiedze, doświadczenie, zainteresowanie bez których robili by na odwal, biorą pod uwagę to co robili ostatnio, nikt nie lubi monotonnej roboty. ____________________ Dla ciebie wyglądało to tak: . W rzeczywistości wyglądało to tak: Ton: Przydało by się, w końcu zająć się BMeshem, to jest bardzo duży, skomplikowany i ważny projekt może wykorzystamy to, że teraz mamy fundusze z Open Movie i możemy się tym zająć zespołowo, przynajmniej pierwszą fazę. Kto jest chętny by potem zająć się wykończeniówką? Campbell: Ja od dawna chciałem wziąć na warsztat BMesh, ale nie było czasu na tak duży projekt. Powinniśmy wykorzystać Duriana tak jak mówisz Ton, teraz albo znowu sobie poczekamy, na kolejną okazje. Ton: Ok, w końcu pójdziemy z tym projektem, EditMesh był już nie używalny, teraz będzie można w końcu porobić coś przy modelowaniu, userzy się przy okazji ucieszą. Tak to mniej więcej wyglądało, Campbell pracuje nad BMeshem do dzisiaj i to nisko poziomowe sprawy jak i ficzery. W tym roku nie będzie filmu, ma być 100% kodowanie Blendera, a pieniądze wpływają jako tako, bo Developerzy maja się zajmować jakimś magicznym Dependency Graph. Userzy nie wiedzą nawet co to jest. Projekt równie ważny, a może i ważniejszy od BMesh, ale na niego nie ma hype, bo nie są to jakieś kolorowe bevele i knify, ale jakoś Developerzy chcą się za to zabrać i to nawet bez filmu? I gdzie tu twoja teoria? Developerzy mają gdzieś hype, biorą na siebie zadania które TRZEBA wykonać, bo taka jest sytuałacja, albo CHCĄ coś zrobić to ich hobby i organizują to tak by mieć na to środki, tyle. To nie Blender służy Open Movie, tylko Open Movie służy Blenderowi. Ton na swoje utrzymanie i jednego kodera zarabia za pośrednictwem sklepu z treningowymi DVD i gadżetami. Open Movie to zastrzyk gotówki na dodatkowych 2 koderów, pracujących full-time in-house. ______________________ Nie myl Roadmap wydań, z ToDo poszczególnych developerów. Roadmap to tylko podgląd tego co się pojawi, w najbliższych wydaniach, bo dany projekt jest bliski ukończeniu, albo jest ukończony. Programiści piszą sobie sami ToDo i są tam naprawy o których nawet nie wiesz, że są potrzebne, są to z reguły mniejsze zadania, ale pracują nad nimi ciężko, na 50 commitów poprawek, przyspieszeń, napraw, przypada 1 commit jakieś super duper funkcji. To, że czegoś nie widzisz nie znaczy, że tego nie ma. Wejdź na Release Log Blendera i poczytaj w ostatnich wydaniach naprawione bugi i pomniejsze poprawki, policz sobie ile tego jest, a to nie wszystko, wiele jest pominiętych, ponieważ były commitowane w paczce np. albo zostały przeoczone przy spisywaniu. Mówienie, że wszystko kręci się wokół dużych kolorowych funkcji mogę nazwać jedynie nieprawdą wynikającą z niewiedzy. Listy wykonanych pomniejszych ToDo i projekty takie jak Deps Graph mówią same za siebie. @Ikkiz Hmm, ja bym wziął, modelik ustawił odpowiednio view port i zapisał. Napisałbym, żeby otworzyć plik z UI i bez poruszania kamery ciachać ja na rysunku, aż knife nie chwyci geo. Może tak by dało rade? Przyznaje, że raportowanie takich bugów to upierdliwa rzecz.

@ikkiz Da się trzeba tylko chcieć ;) .blend, obrazki, rysunki, opis i fin da się na pewno. @Nezumi Autodesk również ma system raportowania błędów i są one naprawiane, no, znam co najmniej jedną osobę która miała naprawione zgłoszone błędy. Problem jest, jeśli użytkownicy stosują forum, by się żalić, zamiast Bug Trackerów. Innym problemem są bugi które nie tak łatwo naprawić... np. takie które wynikają z błędów projektowania programu, Blender też takie ma i co jakiś czas coś trzeba przepisać na nowo, programy Autodesk mają jeszcze gorzej ponieważ często asymilują zewnętrzne wtyczki jako nowe funkcje, code base im rośnie jest coraz bardziej nieuporządkowany, pofragmentowany itp. Aktualnie w Blenderze na recode czeka Dependency Graph (gruuuba sprawa) i view port (to samo) @mrys Czytałem twój raport, błędów jest na pewno więcej, należy je wszystkie zgłosić, razem z .blendami, kod tego typu to nie po prostu "to zrób tak", narzędzia do mesha często mają tablice przypadków np. jeśli kawałek topo wygląda tak rób to, jeśli tak rób to, jeśli jeszcze inaczej rób tamto itd. Takie przypadki trzeba stale dopisywać, błędy są różne, nie wszystkie są tym samym "knife nie rozcina poly" są różne "nie rozcina poly". Jak napiszesz o raport za dużo to nic się nie stanie. A twoje gadanie "bo duże łądne ficzery" jest bez pokrycia, BF to nie jest firma nie potrzeba im reklam. Dodatkowo jest to niesprawiedliwe w stosunku do wszystkich którzy ciężko pracują naprawiając jak najwięcej błędów. Po prostu niektóre błędy są trudne do naprawienia... Sam mam raport w trakcie dociekania jak go naprawić, już 3 miesiąc idzie, dzisiaj akurat dostałem kolejnego maila gdzie opiekun kodu dopisywał swoje notatki i ustalenia z śledztwa dlaczego ten błąd występuje.

Dla niewtajemniczonych: Prędzej czy później każdy użytkownik programu komputerowego trafi na sytuację gdy jakaś jego część nie funkcjonuje jak powinna. Błędy w działaniu wynikające z nieumyślnego błędu programisty są naturalną i nieuniknioną częścią tworzenia oprogramowania. Tego typu problemy w oprogramowaniu są nazywane z angielska "Bug". Jak poinformować Developerów Blendera o błędzie w ich programie? Jest to bardzo proste, wystarczy wejść do Menu Głównego > Help > Report a Bug Otworzy to w naszej domyślnej przeglądarce internetowej stronę gdzie można przeglądać i zgłaszać błędy w Blenderze. Dlaczego warto wysyłać raporty błędów? Większość Developerów Blendera nie jest jego aktywnymi użytkownikami, a wiele błędów w ich kodzie, ujawnia się dopiero po tym jak dana funkcja zostanie użyta w odpowiedniej konfiguracji. Bez pomocy użytkownika próżno liczyć na to, że błąd zostanie dostrzeżony przez twórców oprogramowania. Najlepiej wziąć sprawy w swoje ręce i upewnić się, że odpowiednie osoby dowiedzą się o problemie, właśnie za pomocą "Bug Report". Jak napisać poprawny raport błędu? Najpierw trzeba założyć konto w systemie raportowania Blendera, radzę podać poprawny i używany adres e-mail, ponieważ raporty które złożymy będą pod ten e-mail automatycznie podpinane. Jeśli Developer będzie chciał się z nami skontaktować, by poznać dodatkowe informacje o błędzie, albo poinformować nas o tym, że został on naprawiony lub na jakim etapie naprawy się znajduje, system automatycznie wyśle nam zawiadomienie do skrzynki pocztowej, a wiec jest to ważny krok. Mając konto wciskamy Submit New, jeśli nie możesz znaleźć linku użyj CTRL + F. Oczywiście raporty piszemy w języku angielskim, jednak nie musi to być angielski na wysokim poziomie, ani nie trzeba używać skomplikowanych konstrukcji zdań, ma być prosto i czytelnie. Zawsze można poprosić na forum, np. naszym o pomoc w zredagowaniu takiego raportu. Najlepiej zacząć od podania wersji Blendera w której natrafiliśmy na problem, oraz źródło z którego posiadamy naszą kopie, jeśli źródłem jest GraphicAll.rog, Build Bot, albo wersja z SVN warto dodać nr. "rewizji", który jest wyświetlany obok wersji Blendera w prawym górnym rogu "Splash Screena" zaczyna się od literki "r". Przykładowo: Blender 2.66 Build Bot r53768. Następnie podajemy nasz system operacyjny, np. Ubuntu 12.10 64-bit. Kolejnym krokiem jest opisanie - najlepiej wypunktowane na liście - kroków potrzebnych do odtworzenia błędu. Przykładowo: Otwórz załączony plik .blend. Usuń obiekt Demon_666. Blender natychmiast się wyłącza. Raport dobrze jest zakończyć opisem oczekiwanego działania programu i tego co się dzieje zamiast niego, ale czasem jest to oczywiste i wtedy ten krok możemy pominąć. BARDZO DOBRĄ PRAKTYKĄ JEST ZAŁĄCZENIE PRZYKŁADOWEGO PLIKU BLENDERA! To samo tyczy się zrzutów ekranu demonstrujących problem. Nie trzeba używać żadnego hostingu, system raportowania może przyjmować pliki .blend i obrazki w "Attach Files" prosto z naszego dysku. Jeśli jest to projekt komercyjny, spreparuj scenę tak by demonstrowała problem bez treści które nie powinny być ujawnione, albo stwórz nową scenę z tym samym błędem na przykładowych obiektach. Jeśli uważasz że: "a po co będę raportował, ten błąd jest oczywisty, na pewno ktoś go zgłosi", TO JESTEŚ W BŁĘDZIE! Wszyscy tak myślą i dlatego są w błędzie ;) Nie ma wstydu w zgłoszeniu błędu który już został zgłoszony, ale dobrze jest zawsze przed rozpoczęciem pisania raportu sprawdzić na liście zgłoszonych raportów, czy nasz problem nie został przypadkiem już przez kogoś opisany. Czasem jest to trudne do zweryfikowania i wtedy najlepiej śmiało napisać nowe zgłoszenie.