Monio

Po prostu trzeba zmienić przyzwyczajenia. Nowy układ tabów jest logiczniejszy i lepiej rozplanowany. Chwila i nie będziecie pamiętać że kiedyś to było inaczej rozłożone.

http://www.dalaifelinto.com/?p=990 Bake w cyclesie już supportuje OSLa!!! Drugi taki silnik na świecie który to obsługuje przy czym pierwszego nie da się już kupić (autodesk beast). Potęga! http://lists.blender.org/pipermail/bf-cycles/2014-February/001762.html Cycles po woli staje się dojrzałym rendererem. :)

Sorry że temat się rozmył ale zupełnie nie mam czasu. Do czerwca muszę zrobić zupełnie nowe folio i nie zapowiada się żebym wcześniej się za to zabrał. :( Jakiś tydzień po napisaniu tamtego wątku ogarnąłem się jak bardzo źle oszacowałem ilość roboty. Kod który mam napisany działa ale w określonych, mi znanych sytuacjach. Żeby dostosować to do osób które nie znają bebechów zetki i sposobu działania mojego skryptu będę musiał poświęcić n-razy więcej roboty. Na pewno dam ci znać jak już będę miał jakąś betę. :)

Taby pozostaną ale jak chcesz to możesz mieć otwarte wszystkie. Wystarczy że je przypniesz klikając z shiftem na nazwę panelu (Tą poziomą nie na tabie [swoją drogą ciekawa rzecz do zaproponowania devom]).

Legomir- Po to że jest łatwiejszy i ma dużo większe możliwości. nCloth jest spoko do zanimowania flagi albo sukni ale zrobienie w nim złożonego kostiumu który się nie rozsypie w symulacji jest nierealne/ niebotycznie trudne. Mówię o ciuchach typu kurtka puchowa z materiałami rożnego typu, suwakami, kieszeniami, z kapturem zaciskanym sznurkiem.... W marvelousie nie operujesz na polygonach (których gęstość dodatkowo wpływa na symulacje) tylko na wektorowych wykrojach. Dużo łatwiejsza edycja i można zmieniać wykroje w realtime co jest w majce niemożliwe. Luki Luki - Można znaleźć takie wykroje na sieci w parę minut. Jak ktoś poważnie zabiera się za ciuchy to powinien trochę temat kojarzyć. Nie ważne czy je będzie rzeźbił w zecie czy symulował w marvelousie, dobrze wiedzieć gdzie przebiegają szwy. MariushO- Jeśli ufać ludkom którzy już to wdrożyli do pipelineu to wychodzi że setup podstawowych rzeczy jest n-dziesiąt razy szybszy niż w zwykłych pakietach 3d. Wydajność symulacji też niespotykana w żadnym innym sofcie. Tak przeliczając na realny czas roboty to porównujemy minuty z godzinami. ;)

Nie ma czegoś takiego na standardzie ale jest pewien patent żeby to obejść. Importowanie obj na subtoola z identycznym vertex orderem tylko zmienia położenie vertów i dodatkowo automatycznie przenosi informacje z subdivów. Testowane na obiektach które nie mają subdivów: 1. Kopiujesz toola przez clone all i kasujesz wszystkie inne subtoole których nie chcesz łączyć. Nazwijmy ten obiekt "klonem". 2. Wszystkie subtoole w "klonie" muszą mieć tą samą ilość layerów. 3. Ustawiasz siłę layerów na 0 i klikasz merge visible. Robi co nowy obiekt, nazwijmy go "baza". 4. Teraz ustawiasz w "klonie" poszczególne layery subtooli na 1 i ponownie robisz merge visible. Powtarzasz dla każdej grupy layerów. Nazwijmy te obiekty "targetami". 5. Eksportujesz wszystkie "targety" jako obj. 6. W "bazie" tworzysz tyle layerów ile masz "targetów". 7. Odpalasz w "bazie" edycje danego layera i importujesz obj z odpowiednim "targetem". Jeśli vertex order się zgadza to deformacja warstwy zostanie dostosowana a bazowy kształt pozostanie taki jak był. Powtarzasz dla każdej grypy layerów. Na obiektach z subdivami nie próbowałem. Musiałbyś jakoś pobawić się w reconstruct subdiv ale nie daje gwarancji że to wypali bo prawdopodobnie zrobi siekę z vertex orderem.

Aaaw yiss! Dzięki za te drumbasy, moja playlisa na dzisiaj. :) Niestety się nie doczekamy filmów z taką muzą, za ciężka i niezjadliwa dla większości odbiorców więc żaden producent by nie zaryzykował. W grach podobnie, aż się prosi żeby w strzelankach za podkład robił dobry industrial jak za czasów quake a nie jakieś bezpółciowa symfonika robiona wiecznie na tych samych samplach.

Skoti- A kojarzysz która wersja openGLa jest wymagana jako minimum żeby z pełną wydajnością na hardware robić teselacje meshy opensubdiv? Nie żadną emulacje na procku tylko taką teselacje jak to robi majka albo mud na DX. OSD to jest game changer i dobrze by było podnieść temat w społeczności żeby przekonać koderów do tych rozwiązań. Jeśli jeszcze sam pixar ich jeszcze wystarczająco nie przekonał. ;) Kogoś kiedyś do tego zatrudnią. Może poczekamy jeszcze trochę ale nie ma wątpliwości że do tego dojdzie. Jeszcze 3 lata temu core team był o połowę mniejszy niż obecnie więc postęp idzie wykładniczo. :)

Pewnie gdzieś druga połowa marca lub nawet na początku kwietnia. To trochę zależy jak sprawnie przejdą testy wersji RC która ma się ukazać drugiego marca. Skoti- Ile lat dzieli grafiki które wspierały OGLa w wersji 3.0 a 3.1? Mozę jak mówisz że to mogłoby przynieść taką różnicę to dałoby się przekonać BF do takiego kroku. Co do rozwoju viewportu, po prostu nie ma nikogo kto chciałby się tym na poważnie zająć i stad ta stagnacja. Jest jeden studenciak który od 3 lat męczy się z tematem na GSoC ale jest za słaby żeby samemu zrobić cały viewport. Na szczęście core team co raz częściej podnosi temat, jest szansa że za jakiś czas się wkurzą i z kopyta się za to zabiorą (oby bez błędów decyzyjnych wynikających z pośpiechu).

W 2.7x prawie żadne. Przepisany został dependency graph, dzięki czemu obiekty animują się z wykorzystaniem całego procka a nie tylko jednego rdzenia, w pełnej okazałości to będzie dostępne w 2.73 pewnie. Jadnak to nie psuje kompatybilności. Może być jakiś mały problem przez ujednolicenie przeliczania rotacji obiektów, niektóre zaawansowane rigi mogą działać przez to inaczej ale to jest margines. Archaiczne karty grafiki mogą mieć problemy bo oficjalnie przeszliśmy na nowszą (nadal bardzo starą) wersje openGLa. Tylko że to jest w sumie na papierze, nie widziałem żeby ktoś robił coś konkretnego z viewportem czy rysowaniem UI. NA razie tylko zmienili w prerefencjach VBO na domyślnie włączone, jednak blender i tak testuje czy twoja karta grafiki może z tego korzystać (pewnie może bo to standard od ponad 10 lat, każdy obecnie produkowany telefon to obsługuje). http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.70 Duże zmiany mogą być przez Gooseberry. Niektóre rzeczy będą radykalnie przepisywane ale nie będą implementowane w 2.7 tylko w równolegle rozwijanym 2.8. On będzie takim poligonem doświadczalnym na którym będą testowane zmiany które mogą dużo popsuć. Bankowo nowy viewport, jakiś ogarnięty asset menagment, nowe silniki symulacji. Będzie gruuuubo. :) http://code.blender.org/index.php/2013/12/plans-for-2014-2015/ http://gooseberry.blender.org/open-source-targets/

A nie chodzi ci o 2.8? Bardziej prawdopodobne. Nie ma konkretnych terminów na nowy viewport, nikt z core temu się tym teraz nie zajmuje i na pewno nie pojawi się on w 2.70 ani kilku następnych wydaniach. Gooseberry i nastepny GSoC mogą coś zmienić. Techncznie to się nie znam. Wiem tylko że muli i ma problemy z alfą. ;)

Namieszałeś legomir. Nie ma czegoś takiego jak dynamiczna teselacja siatki w zbrushu. Może dopiero bedzie w 5 wersji ale to sa ploty. W zbrushu jest dynamesh który jest oparty o vokselizacje siatki i jest jednorazową operacją która robi siatkę z równej wielkości quadów. Te metody pracy bardzo mocno się od siebie różnią, jedna nie pozwala na to co druga i na odwrót. Najpierw pojawił się Sculptris którego autora zatrudniło pixologic, to również on jest odpowiedzialny za dynamesh. W międzyczasie powstawał Unlimited Clay do blendera ale nie ujrzał światła dziennego bo autora wessali goście od 3dcoata co zastkutkowało LiveClay. Obecne dyntopo w blenderze to działo Nickolasa Bishopa, autora sysemu sculptu.

le_chu- To wszystko odnosiło się do klasycznego rzeźbienia hipoly, taki był kontekst. W takich zadaniach blenderowy sculpt po prostu jest mniej użyteczny. Przy innych zadaniach ratuje dupę. Sam korzystam bardzo często z grab brusha do zwykłego modelowania organiki, jest szalenie przydatny. Ikkiz- Co do trudności mówiłem o kontroli nad pędzlem. Nie uważasz znacznie większa częstotliwość korzystania z undo może o czymś świadczyć? Dobra, niech bedzie że robie FUD blenderowemu sculptowi. Widocznie tak to musi działać jak się porównuje słabsze rozwiązania z lepszymi. ¯\_(ツ)_/¯ Przynajmniej nigdzie nie pisałem nieprawdy, tylko ty masz spinkę i nie potrafisz zaakcepotwać pewnych rzeczy. Sculpt blenderowy jest tylko- niezły. Przydaje się i można w nim zrobić ładnego konia czy nagą blondynę ale są narzędzia które go deklasują. Jak już mam robić FUD to dodam że twoje porównanie o aparatach jest nieadekwatne bo te marki można stawiać na tej samej półce, natomiast blenderowy sculpt i zbrusha dzieli zbyt duży rozdźwięk jakościowy. I nie ma się co dziwić bo to dzieło jednego niezłego programisty a nie zespołu bardzo dobrych. Widzę że nawet nie zdajesz sobie sprawy jakie narzędzia są w zbrushu i jakie są podstawowe metody pracy. Mimo to się wypowiadasz i oceniasz co wymaga więcej dyscypliny. Ja tylko raz ci zaproponowałem zbrusha byłoby ci łatwiej, szybciej i mógłbyś sobie pozwolić na więcej. Nic ni cie każe, nie oczekiwałem nawet odpowiedzi. Coś takiego samego napisałem 2 innym osobom na tym forum i z tego co pamiętam byli zadowoleni. Jak juz masz takiego nega na inne softy niż blender to mogłeś napisać że chcesz się ograniczyć tylko do niego a nie zaczynać ze zjadliwymi komentarzami na tamat mojego podejścia do ludzi. Czill out może? FYI- Blenderowy patent z shrinkwrapem i multiresem jest inspirowany podstawowym workflowem zbrusha czyli Project All. Dodatkowo blenderowe rozwiązanie nadal jest słabsze bo jest modyfikatorem działającym stale (każdy update sceny) na każdy vertex przez co jest obrzydliwie mocorzerny. W zbrushu projekcja to jednorazowa akcja która dodatkowo zapamiętuje jakie vertexy były modyfikowane od ostatniego użycia projekcji. Dzięki temu możesz dociągać siatkę i robić błyskawiczne poprawki projekcji na obiektach które całościowo mają miliony poly. Argument o skakaniu po subdivach w zbrushu wybitnie nietrafiony biorąc pod uwagę stary i znany bug blenderowego multiresa który niepoprawnie przekształca siatkę wyższych leveli gdy edytowałeś niższe. O ja niedobry hejter blendera, te matcapy które podesłałem Tonowi pewnie też obrazują mój hejt. Moje sculpty które wrzucili na AiB pewnie też specjalnie słabsze niż te które robie w zecie. ;)

Ikkiz- Jakbyś nie miał tak niezdrowego podejścia do blendera to byś nie uważał że robie FUD. Czy ilustratorzy którzy piszą "tusz nie wybacza" albo "akwarela uczy pokory" robią FUD tym mediom czy mówią że trzeba do nich odpowiednio podejść? Złe pociągnięcie pędzla w blenderze może wiele popsuć i trzeba to robić dokładniej, uważniej. Z innej strony, czy Brecht albo Ton jak pisza że viewport blendera jest archaiczny i niewydajny to robią FUD? Odpowiedziałem ci na twoją pm tylko memem bo nie widzę sensu żeby polemizować z takim niedorzecznym bełkotem. Zapal jakiegoś skręta z melisy i wyluzuj. Podpisuje się pod tym co mówi Chrupek.

Nie dotrwałbym do końca gdyby nie to że chciałem zjeść trochę chrupków i nie utłuścić klawiatury. Mogli to w 2 minuty zmieścić. Modele, Particle, symulacje, włosy, shadery zajebiste. Tylko gdzieś się podziała reżyseria i scenariusz. ;) Muzyka i dźwięki oderwane od całości. Kamera z łapy tragiczna. Pod względem "wow factoru" jeden ze słabszych cimematiców jakie widziałem.

floo- Wiem i bardzo propsuje. Dobra robota. :) ikkiz- Nigdy nie robiłem żadnego FUDa blenderowi. Jeśli pisze że sculpt w blenderze jest słaby to robię to w odniesieniu do zbrusha czy innych softów. Bo obiektywnie blender jest słabszy w rzeźbieniu niż zbrush czy inne płatne softy rozwijane od kilkunastu lat. I dziwiłbym się gdyby było inaczej skoro pixologic czy autodesk mają do developingu zespół profesjonalnych programistów. Pytanie czemu tak cię to boli. Jest wiele miejsc w których blender jest dobry, są też miejsca w których jest zwyczajnie słaby. Lepiej jest mówić o tym co wymaga jeszcze pracy bo developerzy, nowi czy obecni w końcu kiedyś poprawią te rzeczy. http://cgcookie.com/blender/2012/08/18/how-to-be-a-positive-member-of-the-blender-community/ A tą żałosną PMkę która mi wysłałeś sobie wydrukuje i powieszę w kiblu. Serio tak cie to zabolało?

Tak i to bardzo. Johnatan gadał z Campbelem żeby dodać to do blendera jako dodatkowy tryb edycji obiektu, oddzielny od Editmode. Jadnak to nadal jest ręczna retopologia sprawa innego kalibru niż autoretopo. Vertex color super się przyda jak cycles dostanie w pełni funkcjoinalny bake. Wtedy będzie można mieszać sobie materiały jak w tym blendzie który podesłał ikkiz i to potem wypalać na texe wszelakie noisy, fraktale, rampy, bumpy i co sobie wymarzymy. :) Solidna dotacja blendera jest tutaj: http://www.blender.org/foundation/development-fund/

Kramon jest teraz zajęty flamewarem więc ja odpiszę. 1. Nie jako matcap blenderowy. Możesz nadać zwykłe materiały GLSL z matcapem ale to jest słabo wydajne. Kiedyś dojdzie taka opcja ale na razie nie ma na to priorytetu. Ton, Brecht i Campbell chcą żeby przez takimi pierdółkami ktoś się zabrał za przepisanie viewportu od nowa. 2. Polypaint w zbrushu to nic innego jak vertex paint w innych softach. Nie maluje się per poly tylko na vertach. Tak to sobie nazwali. Czyli istnieje ale jest strasznie biedne i nie obsługuje multiresa przez co nie ma to zastosowania w teksturowaniu. 3. Nie. Nie będzie przed przepisaniem viewportu. 4. Nie da się. Pozostaje ta stara metoda z GLSLem. 5. Zależy gdzie i jak to chcesz renderować. Weź pod uwagę że Cycles nie ma jeszcze microdisplacementu. 6. Nie ma. Sculpt to teraz osierocony kod. Antony Riakiotakis się czasem nim zajmuje przy okazji zmian w texture paintingu. Za bugfixy odpowiada cały team. To też dotyczy wydajności viewportu, już teraz sculpt hackuje normalny viewport żeby mieć troszkę lepsza wydajność ale więcej się z tego nie wyciśnie. 7. Nie widziałem żeby ktokolwiek z core teamu się tym zajmował ale podobno ktoś inny pracuje nad tym od jakiegoś czasu. Gość jednak nie kodował jeszcze nic do blendera więc to wielka niewiadoma. Biorąc pod uwag stopień zaawansowania autoretopo można przypuszczać że nie zawita do do blendka jeszcze przez długie miesiące/lata.

Ja też. Tylko do takiego modo to się nie ma co czepiać bo jest bardzo sprawnym i bogatym softem. Ten mesh fusion działa tak a nie inaczej i zapowiada się na bardzo przydatne narzędzie którego konkurencja jeszcze nie ma. Magiczna autrotetopologia o którą prosisz to jak na razie super świeża sprawa w softach, nawet najlepsze rozwiązania na rynku nadal pozostawiają wiele do życzenia i mają problemy z generowaniem sensowych siatek. To nie jest tak że tym ludziom się nie chce, to nie działa tak że obsypujesz programistę kasą i ci zrobi one-button autoretopologie w dowolnym sofcie. Jeszcze nie istnieją sprawdzone algorytmy do generowania takich siatek, ludzie z branży nadal tego szukają od lat. Co innego jakby to były jakieś podstawowe narzędzia które są od lat w programach konkurencji. Wtedy zasadne jest oczekiwać od developerów żeby je zaimplementowali w sofcie za który się płaci.

Cycles będzie miał bake w ciągu paru tygodni. :) Poce się na samą myśl połączenia tego z zbrushem i substance painterem. http://dalaifelinto.com/ftp/bake-monkey.jpg Jakby ktoś był zainterezowany designem tego od strony user interface to niech da mi znać. Sorry za oftop ale się jaram.

Fajne. Za drugim razem jeszcze fajniejsze. :)

pxl666 - Czyli Mesh fusion nie jest taki spoko dlatego że może ktoś kiedyś napisze coś podobnego w blenderze? Ja wysiadam.

I co z tego? Sam Opensubdiv nie zrobi ci tego co ten potrafi ten plugin. Teselacja siatek a proceduralne booleany to są zupełnie inne rzeczy.

Legomir- Pokaż screeny a nie fantazjujesz. Nie pierwszy raz piszesz o featuresach mayi których nie ma / może kiedyś będą / są ale inne / są ale nie działają w połowie tak dobrze. Kilka miesięcy temu Kramon robił coś podobnego w kwestii blendera i dostawał tutaj za to młóckę na 100 postów.

JohnDV- Ja psioczę za praktyki monopolistyczne których wynikiem jest opóźnianie rozwoju softwareu, mniejsza różnorodność na rynku, większe koszta dla użytkowników. Co do workflow w jednym programie to bym nie powiedział że maxowi jest do tego blisko, raczej wymagany byłby zestaw programów od autodesku: mudbox, composite, motion builder.