Monio

Dokładnie tak jest. Czytam ostatnio "Code Complete", biblie o projektowaniu oprogramowania. Gość tam pokazuje świetne statystyki jak zmiana designu programu w danym momencie wpływa na koszta projektu. Zmiana elementarnych założeń w architekturze programu (to z czym mamy teraz do czynienia) może być nawet 100 razy droższa w implementacji niż wprowadzenie ich na samym początku projektu. Dalai o nikogo nic nie pytał. Błagania userów o podstawowe funkcje miał w dupie komentując "fajnie by było kiedyś to zrobić". Feedback i propozycje zlewał od momentu wrzucenia okrojonego kodu do mastera (wrzucił więc kasa w kieszeni). Krótko- gość jest partaczem który szkodzi rozwojowi blendera. Dużo lepiej by było jakby Bake powstał wiele miesięcy później, pisany przez innego gościa niż jak teraz, kiedy kodu się tak po prostu nie wypieprzy tylko trzeba go po nim poprawiać. Końcowo ten dobrze zaprojektowany bake rozpoczęty później pochłonąłby mniej kasy i szybciej stałby się funkcjonalny niż to co nam serwuje Dalai. Elementarne podstawy prowadzenia projektów dostępne w książce za 20 dolców. Nie do końca wiem o których ludziach piszesz ale sprostuje że jeśli o mnie to ja Dalai jeszcze nie przesyłałem tego mojego proposala. Jest jeszcze w trakcie tworzenia. To o czym mowa jednak było adresowane od pierwszych test-buildów i gość z tym nic nie zrobił więc faktycznie marnuje czas testerów. Nawet nie zdajesz sobie sprawy jak bardzo. Jego własny wątek na BlenderArtist, Bugtracker, IRC. Ludzie punktowali spieprzone podstawy a gość dalej gra swoją melodie. Pytali się wielokrotnie czy, kiedy i jak załatwi istniejące problemy i gość to zlewał. NA BA już nie wchodzi bo tam się "niemiło zrobiło" i jedyne gdzie odpowiada to Bugtracker, bo musi bo inni developerzy patrzą. Jednak nie zgłosisz tam taska "naprawcie spier*olony workflow" bo to nie błąd w kodzie tylko design... Zużycie pamięci i chore czasy bakeu to też design a nie błąd w kodzie, przecież działa, rajt? n-pigeon - Na razie będę tylko zgłaszał rzeczy na trackerze. Umrę z frustracji jak nie dokończę tego proposala o bake menagement. Wole go dokończyć i mieć w dupie co z nim zrobią. Jeszcze parę tygodni stukania w klawiaturę i będzie gotowy. Ikkiz jak zawsze nie zwodzi w bronieniu czegokolwiek co wyszło spod skrzydeł devsów blendera. Klikać, robić i się nie wychylać żeby przypadkiem nie zobaczyć że dałoby się lepiej. Takich userów nam właśnie trzeba- pokornych owieczek. :)

Oficjalna powtórka z prezentacji pixologic. Samo mięcho.

alex3d- Problem z bakiem w cyclesie jest taki że zabrała się za niego osoba która kompletnie nie ma pojęcia o workflow wypalania tekstur i dodatkowo ma nikłe doświadczenie z robieniem czegokolwiek w samym cyclesie. Po ostatnim tygodniu czytania bugtrackera uświadomiłem sobie że Dalai jest zwykłym partaczem. Jeden gość na bugtrackerze pytał się skąd te chore ilości ramu potrzebne do wypalenia prostych obiektów i podesłał tam swój plik. Dalai odpowiedział że "dla niego to nic dziwnego" bo przecież gość ma 100 obiektów hipoly i podał równanie z którego wynika że każdy obiekt, nie ważne jakiej jest wielkości generuje w RAMie pustą teksturę do wyznaczania koordynatów, o wielkości docelowej texy. Czyli gość miał w ramie 100 tekstur 4096x4096. Dalai odpowiedział żeby połączył obiekty... To jest chore. Tak zaprojektowana architektura nie przeszłaby w żadnym innym programie, jest źle przemyślana u samych podstaw. Wypalanie setek obiektów nie jest niczym niezwykłym bo wystarczy że ktoś będzie chciał rozsiać particlami pierdółki typu śrubka która na docelowej texie będzie miała łącznie 100 pixeli. W designie Dalai dla takiej śrubki trzeba wygenerować nową texe która będzie miała 16777216 pixeli (4k). Druga sprawa że mimo że bake leci w formie kolejki a nie wypala wszystkie obiekty na raz to i tak wszystkie tekstury muszą być załadowane do RAMu na w tym samym czasie. Czyli ani nie zyskujemy na szybkości (mając wszystkie texy już w ramie) ani nie zyskujemy na konsumpcji RAMu (wypalając obiekty w kolejce a nie jednocześnie). Kolejna rzecz to jego złotousta rada jak poprawnie pracować z jego narzędziami czyli "Połącz obiekty"... Dalai prawdopodobnie nigdy nie robił w cyclesie żadnej rzeczy realnego zastosowania i nie zdaje sobie sprawy z metod mapowania w cyclesie. Nie wie że połączenie obiektów rozpieprza podstawowe koordynaty mapowania czyli Object oraz Generated. Czyli jak chcesz mieć radialny gradient do miksowania tekstur na każdej śrubce to szykuj się na zużycie RAMu mierzone w gigabajtach i bakę trwający godzinę (gdzie render stillki z tymi samymi obiektami będzie trwał kilka sekund). Jeszcze jedna świetna rzecz, czas bakeu nie wzrasta liniowo w stosunku do wielkości texy. Mogłoby się wydawać że bake 4k będzie trwał 4 razy tyle co bake 2k. Nie w Cyclesie. Testowałem to w boju ostatnio i wypalanie 2k trwał 2 minuty natomiast bake 4k trwał prawie 40. Inna rzecz że często ten drugi bake generował czarną teksture. Nie ma w kodzie bakeu zabezpieczeń dotyczących ramu, będzie robił obliczenia dalej mimo że już wiadomo że nie ma gdzie zapisać wyników. But there is more! W 2.72 bake będzie zużywał jeszcze więcej pamięci i będzie jeszcze wolniejszy bo Dalai nie przewidział czegoś związanego z renderingiem GPU i musiał zrobić jakieś kręte obejścia. Niestety, nie da się tego wszystkiego już zmienić. Ten jego design to podstawa kodu cycles bakeu. Jedyne co mogłoby pomóc to wypieprzenie wszystkiego do kosza i napisanie tego od podstaw, z innym podejście i razem z odpowiednią optymalizacją. Tak bardzo mi się odechciało inwestować czas w mój projekt Bake Menagement jak to w wszystko czytałem. Tym bardziej po tym jak dowiedziałem się że Dalai kompletnie olał Bake z AA który miał robić do 2.72. Palcem nie ruszył tylko zajmuje się kamerą stereo którą miał robić potem.

Da się rozłożyć uv żeby były idealnie symetryczne. Masz opcje remove UV doubles pod W w oknie unwrapu. To powinno już załatwić sprawę. Jeśli twój model jest symetryczny to polecam takie workflow: Kasujesz połowę modelu i mapujesz go tak żeby wybrane verty na osi symetrii obiektu były w koordynatach X na UV równo w połowie, to będą miejsca w których nie będziesz miał seama. Konieczne będzie pinowanie vertów i auto align, przyda się live unwrap lub ponowne rozkładanie UV za pomocą E (zupdateują się do pinów). Jak już wyrównasz do siebie to co chcesz mieć na osi symetrii musisz umiejscowić te verty na koordynatach 0.5 w osi X. W Properties zmieniasz UV cooridnate na normalized (czyli skala od 0 do 1 a nie podana w pikselach) zacznaczasz te verty i wstukujesz im ręcznie równe 0.5. Nawet jeśli po zaznaczeniu tych vertów będziesz miał tam napisane 0.5 to i tak to zrób bo w istocie to możne być p 0.499 co już jest przesunięciem o ponad jeden pixel na teksie 1k. Teraz mirror modifier po osi X, zatwierdzasz, zaznaczasz w trybie wireframe nowo powstałą polówkę modelu i mirrorujesz całe jej UV względem kursora który jest ustawiony równo na 0.5 osi X. W finale dostajesz idealnie symetryczne UV przystosowane do lustrzanego odbijania texy w edytorze 2d.

Super. Najwyższy poziom. Fajnie że w końcu zrobili coś z targetem wyższym niż 13 lat. Jak pełen metraż będzie w takim klimacie to mnie mają. Nie mogłem znieść tych infantylnych bzdur z kung-fu pandami, nie takiego blizzarda ceniłem.

Bardzo fajny. :) Jak dla mnie gotowy sculpt pod jakąś grę mobilną. Tylko lowpoly zrobić i wypalać z oświetleniem.

Fajny ziomek. Ten pomarszczony ładniejszy. Przydałoby się tej pracy konkretne teksturowanie i lepsze światło.

Anatomia leży, design nie porywa. Skóra wygląda jak twardy plastik, błyszczy się zamiast przepuszczać światło. Nie rozumiem idei robienia tutoriali przez osoby które same potrzebują jeszcze wiele nauczyć się w danym temacie...

Miód! *****

Na początek może jednak USZY. ;) Mordka ma potencjał. Reszta ciała anatomicznie raczej słabo ale jest nieźle jak na początek rzeźbienia. Lecisz z następnym modelem. Jeśli się uczysz to celuj w realizm i pracuj z toną obrazków referencyjnych (polecam pinterest do ich wyszukiwania, google images jest do takich celów beznadziejne).

Nie wierze że da się wolniej wczytywać OBJ niż w blenderze... Zawsze ku*wiłem na ten ich importer. :o

Kolejny który chce wywalić do kosza cały interface i zastąpić go rozwiązaniem z innego programu. Nie łatwiej po prostu kupić tamten program? ;) Takie rzeczy się nie dzieją, nikt o zdrowych zmysłach nie zrobi czegoś takiego w programie który jest na rynku od ponad 20 lat. Nawet jak ADSK zabije maxa za rok czy 2 to stawiam wszystko że Excalibur będzie do niego łudząco podobny od strony obsługi. Jedyna firma o której wiem że wywaliła cały interface do kosza to Apple z ich FinalCutPro. Efektem była ogromna fala krytyki i odejście sporej cześć ich klientów do konkurencji, głównie softów sony i adobe. Ale okienka ładne, teksturkę materiału mają i guziki z gradientami. --------- Właśnie doczytałem że chodzi ci o ikonki. Nowego FinalCuta ściągnij. Ładny jest. Lol.

2013 - Tak ale z tego co wiem na razie nie ma w shaderFX wbudowanego shadera PBR wiec bedziesz musial go stworzyc od zera. To bardzo złożona sprawa. Niestety dokumentacja na stronie autodesku jest napisana pod osoby ktore wczesniej programowaly shadery wiec bedziesz musial sporo sie naczytac z innych źródeł.

http://www.cgrecord.net/2014/08/download-3ds-max-2015-extension-1.html Autodesk wypuścił własnie update Maxa dla osób z subskrybcją. W nowościach głównie: - OpenSubdiv - Alembic - ShaderFX ------------------- 3DS MAX Last Year Maya Edition. ;)

Coś powinno się zadziać w temacie bo mocniej integrują OpenMP i przesiadają się na kompilatory intela. Nie będzie to jakiś niesamowity skok ale kilka-kilkanaście procent szybciej. Zalezności w bebechach blendera to również temat na Gooseberry ale nie wiadomo na razie co z tego wyjdzie, design jest jeszcze rozgrzebany.

Zależy czy pytasz o umiejętności rzeźbiarskie czy znajomość programu. Jak to pierwsze to jestem średniakiem. To drugie natomiast na poziomie bardzo zaawansowanym + skryptowanie w ZScript na poziomie średnim.

jacenty - To w takim razie musisz zagryźć zęby i koniec. Nie zmienią UI z którego zadowolona jest większość użytkowników od średnio-zaawansowanych wzwyż. Zbrush nie ma konkurencji więc to nie jest program który musi się silić na przyciąganie nowicjuszy za wszelką cenę żeby utrzymać się na rynku.

Oh noes. Zaczyna się cytowanie zdania po zdaniu. Ewakuacja!

Ciekawe stwierdzenie zupełnie nieadekwatne do zbrusha. Niby jakie cechy UI ograniczają rozwój tego programu? Podaj jedną. Jeśli poznasz podstawy to interface zetki zacznie dla ciebie być intuicyjny. Znieść tego biadolenia nie mogę więc nie widzę sensu dalej się spierać o coś co dla mnie jest oczywiste. Mam za to propozycje. Napisz czego nie rozumiesz, co jest dla ciebie niejasne i ci to dokładnie wytłumaczę. Masz do wykorzystania 3 pytania. Serio.

Heheheheheee. Uśmiałem się nieźle. Ogromna cześć gamedevu stoi na zbrushu. Jest wykorzystywany w większości dużych gier na konsole i pecety, również w wielu grach mobilnych (a będzie go tam jeszcze więcej bo sprzęt rozwija się błyskawicznie). No tak, gierki... Przemysł bogatszy od całego filmowego... W którym też korzystają ze zbrusha na potęgę! ;) Jak ktoś będzie się oglądał tylko na to jakie jest zapotrzebowanie lokalnego rynku to skończy klejąc w gimpie banery dla chińskich budek. Rzeźbić, ćwiczyć, nie pier**lić!

Legomir- Nie znam dokładnie możliwości Bifrosta. Myślałem że będzie on konkurencją dla Hudego i ICE na każdym polu a nie tylko w symulacjach wody i dymu. To tym bardziej działa na niekorzyść ADSK.

Oczywiście. W cyclesie w menu tekstur masz node gradient w ktorej wybierasz taki który cie interesuje. Zeby go dobrze ustawic musisz podpiąć node texture coordinate oraz mapping i zmienić lokacje i skale.

ADSK pewnie liczył że klienci których wyrolował przesiądą się na majkę z jej hi-endowym "dokończymy Bifrosta za 3 lata". Przeliczą się sromotnie. Do boju SESI! :)

Gotham- Kompletnie nie rozumiem o co ci chodzi. :P https://i.imgur.com/BYBdnen.png Serratus- Interface dowolnego programu można lubić bądź nie lubić. Można chcieć żeby dane rzeczy były w innym miejscu, w innej kolejności, w okienkach albo w jakiś menusach. Ja to rozumiem. Mi samemu nie podoba się interface maxa ale nie twierdze że jest źle zaprojektowany, po prostu wole inne rozwiązania. Dyskusja zaczyna się gdy ktoś mówi jak to program A lub B ma źle zaprojektowany interface, nie dlatego że ten faktycznie jest źle zaprojektowany, tylko dlatego że nie przypomina programu C lub D. Ja pisałem to o modo i raczej trafiłem. Poza modelowaniem pixologic jawnie rzuciło się na skopiowanie funkcjonalności Replikatorów które są bardzo chętnie wykorzystywane przez konceptciarzy, render w keyshocie też dopełnia całość. Osobiście się ciesze bo miałem spore parcie na modo i teraz mi przechodzi. ;) Mam nadzieje że Foundry podniesie tą rękawicę i zrobi coś super ze sculptem w modo. Tak dla zdrowej konkurencji.

Może użyłem zbyt mocnych słów. Przepraszam. Na pewno nigdzie nie pisałem ze jesteś głupi, leniwy ani nic o twojej znajomości zbrusha. Chodziło mi o podejście do uczenia się innych softów na którym według mnie po prostu tracisz niepotrzebnie energie. To że docelowo potrafisz osiągnąć w nich zaawansowany poziom (w co nie wątpię patrząc na twoje prace) to inna bajka. Ja jako osoba która dla której zbrush był pierwszym poważnym podejściem do nauki 3D po prostu nie zauważam tych "katastrof" o których piszą starzy użytkownicy innych softów. To że narzędzia działają inaczej jest dla mnie oczywiste bo sam soft jest kompletnie inny u samych podstaw. I nie widzę w tym żadnej wady bo te ich odmienne koncepty zawsze czemuś służą, dobrze się sprawdzają i są ze sobą spójne. Sprawa wyglądałaby inaczej gdyby zbrush był zwykłym pakietem 3D z takimi samymi opcjami jak max. Ale nie jest i z założenia nigdy nie miał nim być. Wystarczy sobie przyjąć przed pierwszym odpaleniem programu żeby nie przenosić swoich przyzwyczajeń. Wtedy zamiast rozczarowań że wszystko nie działa tak jak w innym programie następują pozytywne zaskoczenia że niektóre rzeczy działają podobnie.