SYmek

Wrzucam, bo rzecz raczej rzadka, żeby nie powiedzieć wyjątkowa. Ukazało się właśnie pierwsze w dziejach wprowadzenie do natywnego renderera Houdniego, czyli Mantry (wer. 9.5): http://www.digitaltutors.com/store/home.php?cat=116 Po DT nie można się spodziewać specjalnej głębi, ale wygląda to na kompletne omówienie podstawowej funkcjonalności Mantry. pozdr., skk. PS Dla niezorientowanych: Mantra jest hybrydowym (reyes, raytrace, pathtrace, volumetric) rendererem z programowalnym enginem i nielimitowanym (czytaj darmowym) renderingiem sieciowym.

Piotrek dobrze prawi. Paralelizm symulacji fizycznych spędza sen z oczu wszystkich developerów zajmujących się tym tematem. Nie na rynku ani jednej (znanej mi) aplikacji do symulacji, która byłaby w pełni wielowątkowa. Algorytmy GPU to inna (choć kto wie, czy nie bardziej obiecująca) kategoria. Z definicji rozwijane są do rozbijania na wiele potoków, bo bez tego byłyby beznadziejnie wolne. Ale zrobić engine do gier, który zawiera milion ograniczeń znanych tylko developerom gry, a aplikacje do symulacji, która ma radzić sobie ze wszystkimi przypadkami to inna historia jest. Większość, jeśli nie wszystkie, dema dostępne na sieci działające w realtime są oparte na fizyce cząsteczek, która jest ABC w świecie symulacji, a potem stają na głowie, żeby to jakoś działało ;)

Węszę tu problem z incremental update, który nie przenosi transformacji do następnych klatek. Trzeba to wyłączyć na próbę...

Na polskiej wsi mówią na taki przypadek, że Ci się "lejce poje...ły" ;) Nie masz tu niczego do trackowania, bo ruch kamery pochodzi z 3d a nie z ujęcia kamerowego. Twoim zadaniem jest przenieść ten ruch na nieruchome zdjęcie, czyli przerenderować je jako tło w programie 3d (tudzież w kompozytorze jeśli uda Ci się przenieść kamerę do niego). Green screen jest również zbędny, bo dysponujesz maską dla swojej piłki, więc niczego nie musisz kluczować...

chłopak się zapalił: http://helmer2.sfe.se/ http://helmer3.sfe.se/ tylko czekać helmer4,5,6,7....

Sprzedałem w pakiecie cały toolset ;)

Z tego, co wiem, to można za 500$ - ale to chyba nie jest normalna cana ;). Jeśli idzie o animację postaci, trudno Ci będzie znaleźć coś lepszego od Mai, która zresztą świetnie nadaje się również do modelowania, podobnie jak Modo czy LW

Maya, Modo, LightWave, Cinema, Houdini. A do pomocy Photoshop, After Effect, Shake, Nuke, PFTrack i parę innych. Czyli nie jest źle.

http://www.maxon.net/pages/products/new/r11/ar/cineman_e.html

Wygląda na to, że 2009 to dobry numerek dla Mai. Assety, szybkie cząsteczki SPH i nowy mental ray. Kawał solidnej roboty.

Wtrącę od siebie a propos tzw. Open Source, jako alternatywy dla korporacji, bo mam wrażenie, że tu jest małe nieporozumienie. Open Source, poza szczytnymi ideami, w które większość Was, zdaje się, nie wierzy, ma także wymiar czysto ekonomiczny. Nie chodzi o zbawianie świata czy dobre uczynki, tylko o inny model ekonomii. Profity, które czerpią korporacje, nie biorą się ze sprzedaży produktów, tylko z kontrolowania dostępu do wiedzy i zasobów. Odpowiednie ustawienie się na rynku sprawia, że korporacja zarabia coraz więcej na tych samych usługach przy coraz niższych kosztach. Może to robić, ponieważ kontroluje rynek i kreuje potrzeby swoich klientów. W ciągu ostatnich kilkunastu lat czołowe korporacje na świecie powiększyły swoje aktywa wielokrotnie, ale ludzie tworzący dobra przez nie sprzedawane (czytaj tutaj: programiści i naukowcy piszący algorytmy) zarabiają wciąż tyle samo albo mniej. Także produkty wciąż kosztują tyle samo. Rozwarstwienie między zarobkami kadry zarządzającej a pracownikami merytorycznymi i robotnikami pogłębia się z roku na rok. Duża firma to jest bezgłowa hydra zaprogramowana na to, żeby robić ludzi w chu... , a najzabawniejsze, że nikt za tym nie stoi. Jest to tylko suma pazerności managerów wszystkich szczebli. W Open Source chodzi o to, żeby uprawiać biznes bez korporacji. Programiści Open Source zarabiają normalne pieniądze oferując usługi związane z technologiami, które udostępniają. Bo technologia niewiele jest warta bez ludzi, którzy się na niej znają. Zarabiają tyle samo albo więcej, mają swobodę wyboru, a produkt jest tańszy, bo nie obciążony dodatkowymi kosztami. Open Source może zrobić coś, na co w normalnym modelu biznesu może sobie pozwolić tylko duża firma, jak choćby opracowanie i promowania standardów. Open Source to nie marzenia idealistów, tylko poważna propozycja biznesowa, która ludziom wytwarzającym dobra pozwala normalnie pracować, bez konieczności pracy w korporacjach. sorki za offtop. skk.

Rozumiem, żeś się wkurzył za przytyk, że takie dywagacje to dziecinada, ale taka jest prawda. Jak pracujesz zawodowo, jeszcze w firmie, to nie masz takiego ciągu do zmian (zawsze w okolicach Siggraphu ...), bo to niczemu nie służy. Jak lubisz nowości i zmiany, to powiedz, że Ci się znudziło XSI i chcesz się pobawić czymś nowym. Twoje prawo. Tyle, że nie ma to nic wspólnego z merytorycznymi argumentami typu mental ray 3.7 w Mai. Szukanie dziury w całym jest, jak sam to nazwałeś, domeną hobbystów. Zarówno XSi jak i Maya rozwijają się dobrze i równo. A, powtórzę, nowe funkcje, są niczym wobec stabilności, przewidywalności, supportu czy społeczności, jakie oferuje Ci oprogramowanie. A co do Mantry, to rzeczywiście dobry pomysł z tą stopką, dzięki, pomyślę nad tym :). No nic nie poradzę na to, że wymiata.

Przepraszam, ale to akurat jest nieporozumienie. Autodesk kupił gotowy program, z uznaną pozycją na rynku, z kompletnym toolsetem, w którym niewiele zmienił, z teamem developerów, którzy od dawna już pracowali nad technologią, która być może ujrzała światło dzienne już po transakcji. A co do zarabiania i motywacji firm softwarowych, to zarabianie zarabianiu nie równie. I nie wszystkim chodzi o to samo, więc sprowadzanie tematu firm i strategii, jakie prowadzą do zdania, że wszyscy są sobie równi, to kapitulowanie przed problemem, a nie rozwiązywanie go.

Dajcie spokój z tymi rozwodami... któryś z kolei wątek o tym, że brak tej czy innej funkcji, skłania kogoś do zmiany narzędzia. Jeśli rozwód bierze się z tak błahych powodów, to małżeństwo było niewiele warte. Programy to nie nowe bajery, tylko zaufanie, stabilny rozwój i inwestycja na przyszłość. To, że Maya długo stała w miejscu znaczy tylko tyle, że nie było czego w niej poprawiać. To, że XSI zajeło tyle czasu nadganianie w dziedzinie środowiska dla TD (które ma Maya czy Houdini), świadczy tylko o tym, że to trudna dziedzina i nie da się tego zrobić z marszu. XSI powstało jako artist friendly, a Maya jako production friendly. Jedni i drudzy nadrabiają zaległości. W pierwszym upgradzie do XSI 7.0 będzie pewnie nowy mental ray, więc jaki to powód do przesiadki? Każdy powód dobry, jak ktoś nie płaci za oprogramowanie i nie pracuje - ma masę czasu na zabawę kolejnymi programami. Mental również goni, ile wlezie. Adaptive Subdivision jest w PRManie czy Mantrze od wielu lat, podobnie jak jakość tesselingu sterowana ruchem (oczywiście tutaj to nazywa się dicing, nie tesseling), nie wspominając już o *pełnym* supporcie dla OpenEXR czy wolumetryce, w której od 9.0 taka Mantra nie nie wiele konkurenji.

Uwaga o tyle przesadzona, że 90% wszystkich newsów na max3d.pl wygląda jak artykuł sponsorowany, tylko pozazdrościć sponsorów ;)

Żadna umowa nie może naruszać prawa handlowego, w ramach którego musi się poruszać każdy podmiot uczestniczący w rynku. Autodesk będzie mówił, co mu wygodnie i walczył o swoje. Odmówi Ci pewnie supportu, ale nic więcej się nie zdarzy. Pytanie, jakie rację będą za nim stały w przypadku otwartego konfliktu? (do którego zresztą nie dojdzie, bo nie pozwie Cię przecież do sądu za kupienie licencji!).

Przesadzacie! Już mówię: z poligonami chodzi o to, że trzeba je najpierw policzyć, żeby działały shadery. To proste. pozdr., skk.

Boziu, ilu się programistów znalazło, a zwykle słychać było utyskiwania "ja nie chcę programować, chcę tworzyć, jestem artystą!" ;)

Myślałem, że pytanie dotyczy czegoś innego. Brightness/Contrast nie jest filtrem. Filtr to efekt, który przy obliczaniu wartości piksela bierze pod uwagę wartości pikseli obok. A wtedy maskowanie efektu polega na czymś innym, niż klasyczna maska dla manipulacji koloru czy transformacji. Jeśli pytanie dotyczyło po prostu masek, to patrz post wyżej, jeśli chodziło o maskowanie filtrów (tudzież transformacji per pixel zwanych deformacją), to sprawa jest bardziej skomplikowana.

No chyba nie do końca ;). Pożytek z SSE będzie żaden, jeśli dane, które poślemy do enginu nie będą uporządkowane (lineup). To jest wymóg SIMD, aby mógł je załadować równolegle do rejestrów i wykonać jednocześnie tę samą operację. Jak sądzę, to jest właśnie powód, dla którego SIMD jest poręczny w grafice, tablice (na przykład raster) doskonale spełniają powyższy wymóg. Podobnie działa wielopotokowy engine GPU. A skoro kilka elementów kolekcji można obrabiać jednocześnie (dowolnych elementów) to znaczy, że samą kolekcję również można podzielić i obrabiać jednocześnie w kilku wątkach. Ergo związek SIMD z wielowątkowością... :) pozdr., skk.

To, co nazywasz "jakby maską" jest maską ;) i o ile filtr jest do tego przystosowany, można maskować jego efekty. Nie warto tego robić w klasyczny sposób (czyli maskując fragment obrazka), bo mieszasz w ten sposób obrazek przefiltrowany z nieprzefiltrowanym, zamiast kontrolować maską siłę filtra. Niestety nie mam teraz Fusion przed oczami, ale w Shake, Nuke, czy Halo są specjalne wersje filtrów przystosowane do tego, żeby je maskować... czyli kontrolować ich siłę maską. W Fusion też takie powinny być.

Jeśli tak, to z pośpiechu ;) To oczywiście nie jest to samo. Wykorzystanie SSE nie oznacza wielowątkowości, ale czyni ją łatwą do wykonania. Albo inaczej, jeśli zadanie nadaje się dla SSE, to prawie na pewno łatwo je paralelizować.

hmm... chyba wziąłeś do siebie coś, co miało innego adresata, zresztą bliżej nieokreślonego. Powiedziałem tylko, że taki moduł jak ICE nie jest General Purpose Script Editor, którym można automatyzować czy modyfikować dowolne parametry sceny (typu: stwórz torus, przesuń w prawo, nadaj mu materiał, zdeformuj, a potem skopiuj x1000). Bardziej przypomina shader, niby kawałek kodu, ale wykonywany w bardzo specyficznym kontekście, właśnie w pętli i na homogenicznych elementach kolekcji, inaczej nici z SIMD. Zresztą wiesz, o czym mówię ;) pozdr., skk.

W Transformers nie było jednego sposobu przemiany robotów. W każdej scenie transformacji była ona projektowania od podstaw pod ujęcie... nie ma lekko.

Wszystko zależy od przypadku. To nie jest Afx czy Max, które są w miarę spójnymi środowiskami (mniej więcej). Houdini to jest system operacyjny, a nie pojedynczy program. Największym kłopotem Houdiniego jest to, że GUI działa w jednym wątku. Większość operatorów działa zatem w jednym wątku. Ale VOPS (Vex tak naprawdę) to jest język programowania, który z definicji działa na dowolnej ilości wątków. Tak działa SIMD. Wyjątkiem są operacje na Point Cloudach, które źle działają w wątkach (dzielony dostęp/zapis do pliku, ciężka sprawa). W ich przypadku czasem trzeba wyłączyć wielowątkowość. DOPs są generalnie wielowątkowe, ale w tym przypadku to nie oznacza liniowego przyrostu, a raczej minimalny. Każdy mikro solver na własny sposób stara się dzielić pracę na wątki. Na przykład detekcja kolizji w cloth solverze jest wielowątkowa, ale pozostałe mikro solvery w Cloth solverze już nie... i tak dalej. Mantra jest wielowątkowa prawie w całości (np. generowanie shadow map chyba nie jest), ale to wcale nie znaczy, że należy używać max dostępnych rdzeni w każdym przypadku. I to wcale nie jest przypadłość Mantry. Generalnie czasami lepiej jest liczyć na mniejszej ilości wątków. Kłopot Mantrze w tym temacie czynią głównie instancje. Trzeba robić testy i liczyć sekundy... innej drogi nie ma. To jest takie gdybanie, trudno powiedzieć. Na pewno w XSI, nawet bez ICE można zrobić piękną roślinność. Jeśli chodzi o cuda ptakuna, to kluczem do sukcesu nie są LSystemy czy VOPsy, tylko renderowanie. Najmocniejszą stroną Houdiniego, zaraz po fizyce, jest sposób w jaki Mantra wpięta jest w ten program. Przecież tych kwiatów w ogóle nie ma. Ptakun ich nie modeluje. Powstają w rendererze, za pomocą shaderów i atrybutów rendertime primitives, podobnie jak PRMan liczy włosy. Dlatego może ich być miliony. Na koniec: o ile rozumiem, o co biega w ICE, to nie jest to po prostu wizualny język skryptowania, jak niektórzy tutaj sądzą. ICE nie wykonuje poleceń w takim sensie jak Python czy JScript. ICE *modyfikuje* atrybuty na geometrii, którą mu podasz. Z definicji działa jak loop, iterując po elementach obiektu, czy będą to particle, czy skin. pozdro.