Monio

Mam dokładnie tak samo. Z jednej strony restrykcyjne GPL mnie boli ale z drugiej nie widzę innej licencji dla blendera. Łatwo sobie wyobrazić co by się stało z blendkiem gdyby był na nie-restrykcyjnej licencji jak biblioteki takie jak OpenSubdiv. Każdy większy ficzer byłby wchłaniany przez konkurencyjne softy chwilę po wypuszczeniu kodu zostawiając tym samym blendera jako całość w tyle. Krótko mówiąc, blender bez GPLa stałby się martwą biblioteką. Jednak jestem dobrej myśli. Co raz więcej projektów wspierających pipeline i nowe otwarte standardy. OSL, OpenVDB, Alembic, OpenSubdiv, potem pewnie PTEX. Przepisany viewport z tym GLSL render mode to perfekcyjne narzędzie dla gamedevu, jak dobrze to dograją to będzie to oznaczało możliwość wykorzystywania shaderów prosto z gry a taką funkcje jak na razie miała tylko i wyłącznie majka. Wszystko na dobrej drodze, potrzeba tylko 2 rzeczy- cierpliwości i 5 eurosów miesięcznie na development fund. ;) Jedyny mankament nie do rozwiązania to ten paskudny babol zwany FBX. Tutaj blender będzie zawsze miał pod górkę ile by się nie starali. Tragedia że ten format się tak przyjął. O jakości tego shitu może świadczyć fakt że samemu Unity Tech przez wiele lat nie udało się wydusić pełnej kompatybilności, pomimo korzystania z FBX SDK... Modle się żeby powstał wreszcie jakiś sensowny otwarty format wymiany danych i żeby to inne firmy wymusiły korzystanie z niego w softach ADSK a nie na odwrót. Na razie to jest narzędzie do pomiatania wszystkimi softami spoza stajni Autodesku.

Wszystko to kwestia do czego porównujemy. Z Coroną przegrywa ale jak to porównasz z mentalrayem gdzie ustawisz AO, GI, SSSa i kaustyki robiąc z niego pathtracera to wyjdzie ci że ten cycles jednak nadal jest całkiem wydajny. Jak Trona Legacy (ostatni mentalowy feature-film) wyrenderowali na mentalu to nie wiem czemu szybszy cycles nie miałby sobie poradzić z reklamą do TV. ;)

Kawałki nowego viewportu będą już w 2.73 ale na takie prawdziwe przewietrzenie wszystkiego będzie trzeba poczekać ze 2 wydania. Pół roku przy pomyślnych wiatrach. Natomiast Alembic... Przy tej ilości roboty którą ma Lucas to strzelam że to będzie gotowe/ realnie używalne nie wcześniej niż w drugiej połowie przyszłego roku. On nadal pracuje nad ficzerami czysto symulacyjnymi do pilota gooseberry, cash to sprawa drugiego priorytetu a eksport/import to już w ogóle dalszy plan (w temacie pilota gooseberry oczywiście). BTW. Mogliby wreszcie się przed sobą przyznać że cykl wydawniczy blendka to nie jest 2 miesiące. Nigdy nie było. ;) Ale jak dla mnie lepiej później niż na wariata tak jak z bejkiem. ------------------ http://code.blender.org/index.php/2014/09/viewport-project-targets-current-state-of-the-code/

Chudziutko ale za to 2.74 będzie epicki i doszlifowany. :)

Szumi na maksa. To dlatego że objęli strategie kompletnie odwrotną do solid angle. Czyli najpierw chcą żeby ten renderer był kompletny pod względem ficzerów, również na GPU i dopiero potem będą to stopniowo optymalizować. W Arnoldzie jak jakiś ficzer się pojawiał to siedzieli nad nim tak długo aż był piekielnie dopracowany, jednak przez wiele lat brakowało tam podstawowych rzeczy. Teraz to minione czasy. Druga sprawa to CPU / GPU. To nadal jest rzecz unikatowa wśród rendererów. Cycles to jedyny renderer gdzie wybierasz czy liczysz na CPU lub GPU. Są rendrery GPU only, są hybrydy które liczą na obu na raz (Arion, to musi być dopiero bottelneck :P ), jest VrayRT który jednych rzeczy nie ma a inne fejkuje. Nadal z rendererów produkcyjnych tylko Cycles oferuje ten sam zestaw funkcji na innym hardware (pomijam oczywiście OSLa i drobne optymalizacje pod konkretne instrukcje). Te kompromisy ograniczają wydajność zarówno na CPU jak i na grafikach ale w zamian dostajesz elastyczność.

Animki renderowane w cyclesie, przez oba makeing offy mają na górnej belce wybrany renderer cycles i nawet pokazują swój setup materiałów na tym kolibrze. SSS to jest od bardzo dawna i doczekał się w międzyczasie wielu usprawnień ale nadal potrzebuje sporo czasu na odszumienie. Jedyne czego tak na prawdę brakuje temu rendererowi to micro-displacement. Dalej to już tylko optymalizacja i usprawnienia casheowe.

Cycles. Nie trolluj.

Dokładnie. Z moich źródeł face to face wynika ze w polskim gamedevie to trzeci lub nawet drugi soft pod względem popularności.

W drugim materiały mogłyby być trochę bardziej dopracowanie ale ogólnie to poziom mistrzowski.

Programowanie pod CPU i GPU to 2 osobne światy. Renderer na oba na raz to zlepek bottlenecków który jest bardzo trudno rozwiązać. Robienie wsparcia na GPU mogłoby im zwyczajnie zaszkodzić. Niech najpierw dopracują to na procki i zarobią kasę na poźniejsze działania.

To jest najwieķszy bullshit jaki czytałem w tym miesiącu. Żadna normalna firma gamedevowa/cg nie przyjełaby takiego modelu bo to co proponujesz to jest gwałt na wydajności i materiał nie nadający się do dalszej obróbki. Znasz w ogóle takie pojęcie jak mipmapa czy vertex count? Może to dla ciebie nowum ale każdy seam zwieksza dwukrotnie ilość verteksów edgea, tak samo jak edgesplit. Tak funkcjonują karty graficzne, tego się nie da przeskoczyć. Dobre seamy mogą zwiekszyć ilość vertów mesha o kilka procent, nie chce wiedzieć ile generują twoje modele.

Azbesty- Szalenie pomocna rada... Excommunicator- Corona Pathn to ścieżka do folderu gdzie masz zainstalowaną coronę albo pliku .exe Corony w tym folderze.

Symetrycznie rozłozone uv ma jedno zajebiście praktyczne zastosowanie. Mozesz w edytorze 2d odbijać sobie po tej osy symetrii teksture lub jej fragmenty. Szczególnie cenne przy walce z seamami. Oczywiście że nie. Mozesz zrobic jeden materiał gdzie bedziesz miał kilka tekstur i będą one przydzielane wedle osobnych kanałów uv i ostrej maski z vertex color. Kolory vertów w blenderze są per face więc nie muszą mieć płynnego przejścia, mogą działać identycznie jak przydzielanie materiałów per face. Testowałem do bólu i działa perfekcyjnie. Jak nie chcesz sie bawić w robienie masek to możesz zrobić materiał w ktorym jest node grupa. Mozesz mieć i 100 takich materiałów, jesli bedziesz edytował wnętrze grupy to wszystko ci sie zupdatuje.

Troche tam namieszałeś. ;) Jakbyś odchudził siatkę tego kołnierza żeby miała 16 edge'y w obwodzie to mogłbyś zrobić inset na kwadracie 4x4 faceów i siatki by się czysto połączyły. Przy turbosmooth te 16 krawędzi spokojnie ci wystarczy zeby zachować bryłę. Jak to dla ciebie za mało to w takim razie kwadrat faceów 6x6 i 24 krawedzi w obwodzie kołnierza.

Ten ambient mi nie leży w ogóle. Jest na diffuse czy jako osobna mapka? Gość wygląda jakby wrócił z szychty w kopalni. ;) Skórzane elementy bardzo fajnie wyszły (poza ambientem na butach). W czym malowane?

Spokojnie możesz spinować szwy na ustach i je przymknąć. Zyskasz sporo pixeli na ustach które mają zazwyczaj sporo detalu. Będziesz miał minimalne stretche ale jak to leci pod subdiv/multires to problem zniknie. Podobnie z oczami. Niektórzy goście skalują te dziury do do zera w pionie i malują w tym miejscu na texie poziomą krechę jednolitego koloru żeby się dobrze zapętliło. Rozważ mapowanie dłoni. Takie które zrobiłeś jest trochę wygodniejsze w malowaniu ale daje duże stretche i różnice w texel ratio. Jakbyś ciachnął seama przez wszystkie palce i zostawił tylko łączenie od czubka małego palca do nadgarstka to detal będzie równiejszy, stretche minimalne. A malowanie w blenderze jest koks więc raczej nie będziesz miał problemów. No i ciachnij piny na osi symetri twarzy bo moje OCD płacze. ;)

Warto pamiętać o tym żeby "pole" czyli verteks od którego odchodzi 5 (lub więcej) krawędzi był na możliwie najbardziej płaskiej powierzchni a nie przy samym zagięciu łączącym bryły. Poprawi to cieniowanie modelu, będzie też potrzebne przy dobrych deformacjach animowanych siatek. W twoim wypadku ten inset może być o zrobiony na powierzchni o wiele większej niż średnica tej rurki którą będziesz łączył, np możesz zrobić go z krawatu 4 x 4 facey.

Inset i potem bridge do ustawionego cylindra.

Nie ma. Za to możesz sobie poprzestawiać wszystko gdzie chcesz. ;) UI team chce coś takiego wprowadzić ale nie ma co liczyć że się im uda. W blenderze interface to skrypty pythona. Przestawianie elementów wiązałoby się z przepisywaniem w locie plików pythona uwzględniając jego składnie, logikę zagnieżdżeń elementów, algorytmami które będą wiedziały gdzie umieścić przekierowanie kontekstu operacji, innymi które wyczyszczą te przekierowania (umiejscowione w rożnych miejscach kodu) gdy przeniesiemy guzik gdzieś indziej. Krótko mówiąc AI ala Skynet piszący w blender API. ;)

Wygląda lepiej... Rok po premierze oryginału i na kompie który kosztuje 2 razy tyle co PS4. Emejzing. ;)

To nie tak. GoZ to SDK i format pliku (.goz) podobny do ZTL tylko że w wersji okrojonej. Możesz dzięki temu wyciągnąć z zetki do twojego softu pewną ograniczoną ilość informacji modelu. Z tego ci się orientuje nie ma tam fibermesha, micromesha, matcapów i wielu innych danych. Czyli komunikacja z keyshotem to mogą być mechanizmy takie jak w GoZ ale to jest wersja GoZ napisana specjalnie pod ten jeden soft, bo on to wszystko obsługuje. Albo po prostu keyshot ładuje całego ZTLa. mellodeque- Nie wiem czemu miał służyć twój komentarz ale cieszę się z tobą. :D

Excommunicator- Jak skonczysz studia to za możliwość korzystania z maxa bedziesz musiał płacić 6 tysięcy złotych rocznie. To jest ten myk z "darmowym" maksem. Weź to pod uwagę. Do wizualizacji obate programy spiszą się doskonale. Max wypada na chwile obecną trochę lepiej bo ma więcej pluginów i gotowych modeli do kupienia. Jednak ostatnimi czasy ilość takich rzeczy w blenderze wzrasta bardzo mocno więc w przyszłości to się zrówna. Blender to najszybciej rozwijający i popularyzujący się program 3d więc będzie tylko lepiej. :) Niezaleznie od wyboru głownego softu polecam ci sie zainteresować zewnetrznymi rendererami- Vray, Corona. Dadza ci lepsze rezultaty i czasy renderu niż archaiczny mentalray i dosyć wolny cycles.

Na pewno to nie jest GOZ bo przenosi też instancje, fibermesha, dodatkowe dane o siatce, macapy nawet. Pewnie to format pośredni na bazie plików ZTL.

To na pewno nie jest CAD i modelowanie inżynieryjne. Nie wklepiesz sobie skali obiektu ani nie ustawisz że jakaś ścianka ma być przesunięta dokładnie o daną ilość jednostek. Do tego zbrush nie służy. Za to możliwość zmierzenia czegoś do dziesiętnej części milimetra gdy przyjmujesz jednostkę metrową to aż nadto do rzeczy do jakich nadaje się zbrush. Przy rekonstrukcjach twarzy w medycynie sądowej (tak, wykorzystują do tego skany 3d i zbrusha :) ) to ci w pełni wystarczy.

Nezumi- Pewnie że sie da. Transpose line może służyć jako miarka, wszystko jest w ustawieniach. Pracując w taki sposób będziesz odnosił sie do nieokreślonej skali globalnej ale jak raz ustawisz skalę transpose według jakiejś znanej ci miary, np głowy ktora ma wysokość 17 cm, to potem bedziesz mógł sobie przeskalować oko zeby miało dokładnie 27milimetrów. http://docs.pixologic.com/user-guide/3d-modeling/modeling-basics/transpose/transpose-units/ Jeśli natomiast potrzebujesz zeby twój model miał jakieś realne rozmiary w skali globalnej to prawdopodobnie jest to rownoznaczne ze bedziesz go importował w jakimś zewnetrznym programie. Tam już możesz sobie precyzyjnie wszystko na raz przeskalować. Transpose line to trudna bestia ale to naprawdę jest gizmo na sterydach ktore pozwala na wiecej niż te znane z klasycznych softow 3d. :)