SYmek

:)

Myślę, że nie. Nie tyle chodzi o liczbę licencji (przecież komputer zdalny też mógłby mieć swoją licencję apprentice), ile o mechaniczne wyłączenie funkcji związanych z siecią. Ale mogę się mylić, sprawdź ;). -> http://odforce.net/wiki/index.php/MantraRemoteRendering pozdr., skk (swoją drogą dzisiaj liczyłem tym sposobem futerko na 40 rdzeniach :) )

Cos* milego dla freakow od efektow ze szczegolna atencja dla GPU. Nvidia Conference Page Piatek z ILM * - Blisko godzinne video. Ciekawe a momentami zabawne - calkiem odwrotnie, niz programowanie dla cuda :P

Zboczeniec!

Nie chce mi sie rozpisywac, ale wiadomosc bardzo ciekawa*: http://www.fxguide.com/article570.html * - szczegolnie w konktekscie renderowania na gpu, cudy etc, o ktorych ostatnio tak glosno.

Ta technologia ma znikome zastosowanie w branży graficznej. Jej cana wynika z targetu, czyli dużych firm zajmujących się projektowaniem i designem, którym wystarczy mało elastyczny system renderujący serwujący obraz przez internet swoim klientom. Być może Porchse będzie pokazywać nowy model samochodu komuś z zarządu ;). Cena nie wynika w ogóle z jakości technologii, jest bardziej wypadkową innowacyjności i użyteczności a przede wszystkim (!) ilości kopii, które mamy nadzieje sprzedać. Chryste, przecież wysoka cena wyraźnie świadczy o tym, że sama nVidia nie ma złudzeń co do swojego rozwiązania. Nie chce mi się wchodzić w szczegóły, rozumiem fascynację tjvikinga nową technologią, tyle że sam w nią nie wierzę. Uważam, że programowanie na platformę GPU mija się z celem i jest chwilową aberacją. Wbrew temu, co mówicie, nikt nie przedstawił jeszcze gotowego produktu na GPU. Wszystkie anonsy są rodzajem dawania znać o sobie w czasach przemian, a nie komercyjną propozycją. Mylicie propagandowy szum z ofertą handlową. Nie przedstawił, bo oczekuje na udoskonalenie cudy (C++!!!), oraz kontr-propozycję konkurencji. Widzicie Vraya i iraya na cuda i wydaje Wam się to dowód na to, że da się, tymczasem jest wręcz przeciwnie. Ograniczenia tych produktów świadczą o tym, że się nie da, przynajmniej nie w tym momencie... Można zrobić zabawkę z zafixowanym zestawem funkcji (iray to pathtracer w istocie najprostszy z algorytmów) a nie kompletne środowisko, które trzeba by zaprogramować w koszmarnych warunkach. Polecam październikowy numer Communications z artykułem "View of parallel computing" analizującym szczegółowo w istocie dość trudną sytuację branży softwarowej, która nie nadążyła za zmianami hardware'u i oczekiwaniami ludzi. Obawiam się, że wygra platforma uniwersalna i prosta w zastosowaniu, która równie dobrze obsłuży wielopotokowo bazę danych co renderer. Zaimplementować pathtracer na gpu to pestka (istnieją 100-linijkowe implementacje oraz gotowe rozwiązania od nvidii) w porównaniu ze wszystkim tym, co firmy posiadające park sprzętowy w istocie na nim robią. Symulacje, konwersje, obsługa baz danych etc etc. Za tym idzie wiedza i masa technologii poza samym śledzeniem promieni. Oczywiście, że ludzie nie wiedzą, co dalej będzie, kiedy Intel przedstawi swoją propozycję i jakie będę jej szczegóły, więc chcą się zabezpieczyć. Zapewniam jednak, że programiści, jeśli tylko będą mogli wybrać, wybiorą łatwiejsze rozwiązanie, a jest nim cpu, a nie sięganie prawą ręką do lewej kieszeni przez ucho igielne pci-express ;). Przecież zarówno Intel jak i nVidia to wiedzą, stąd spokój pierwszego i kosmiczne ceny drugiego, który wie, że ma wciąż słaby produkt, który może zainteresować wąskie grono klientów ze specyficznymi wymaganiami. Jak sami widzicie, przyszłość to kwestia wiary a nie faktów ;)

Tak, było w tym roku na Siggpaphie, tak jak szef Epica, który zapowiedział, że następny ich engine będzie mikropoligonalny (już o tym pisałem). Ale nie w tym rzecz. Algorytm reyes to nie PRMan, tak jak iray, to nie całe środowisko, z API, shaderami, tile'owanymi teksturami, które może być dopiero poważną propozycją. Iraya nie będą sprzedawać, bo za mało jeszcze potrafi ;) Wszystko, co piszesz o prądzie i oszczędnościach byłoby znaczące, gdyby chodziło o pełnokrwisty renderer. Tymczasem mamy ograniczony prototyp za gigantyczną cenę. Kiedy będzie to pełnokrwisty renderer, będzie już stał w tłumie konkurencji, która będzie działać równie dobrze na gpu, co cpu :)

1) Reality Server istnieje od wielu lat i okazał się kompletną klapą mental images. Wbudowanie w niego iraya i cuda było bodaj jedyną szansą na odzyskanie pieniędzy włożonych w development tego potwora, który nikomu nie jest potrzebny. 2) Reality Server nie jest skierowane na rynek użytkowników prywatnych, ma bardzo specyficzne zastosowania a o iray wiadomo tyle że ma za wiele ograniczeń by być dla kogokolwiek rewolucją (vide masa technologi RT obecnych już na rynku). Mental goni tu konkurencje a nie odwrotnie. 3) Także sama CUDA jest etapem rozwoju czegoś innego i właśnie dlatego poważne firmy nie kwapią się z przenoszeniem na nią kodu do masowego użytku. Mental nie jest o lata świetle przed konkurencją, tylko jest wystarczająco zdesperowane, żeby pożenić iray (które gpu wcale nie potrzebuje), z trupem Reality Server i Cuda i stworzyć coś, co przeszłoby niezauważone, gdyby nie kampania głupot, która temu towarzyszy. Kilka innych firm mogłoby już teraz sprzedawać taki produkt, tylko nikt by tego nie kupił, bo się to po prostu nie opłaca. Komu potrzebny jest renderer wymagający do pracy sprzętu za dziesiątki tysiący euro, który ma tyle ograniczeń? To jest prototyp, który udaje dojrzały produkt. Propaganda to jedno, a rzeczywistość jak brak API, zamknięty zestaw shaderów, ograniczenia pamięci, wsparcie tylko dla C, minimalny zysk wydajności bez poważnych inwestycji sprzętowych, to drugie. Podobnie było z MetaSL, kawał g***nej technologii zapowiadanej jak rewolucja. Przynajmniej od kilku lat wszystkie poważne renderery mają wersję na Celle, które bija na głowę wydajność cpu, i nikt się na to nie rzuca. Z Tessla będzie podobnie do czasu, aż całe środowiska przeniosą się na platformę wielopotokową. To będzie zresztą czas, kiedy Intel wyda swoją odpowiedź na nVidia i znów wszyscy będą się zastanawiać, czy renderować na gpu z problematycznym dostępem do pamięci ram, czy zostać na cpu.. Minie rok, albo dwa, wszyscy przepiszą wszystko na OpenCL albo podobne ustrojstwo, Intel wyda Larrabee, nVidia wzmocni zarządzenie pamięcią umożliwiając natywne używanie C++, będziemy mieli kilka enginów chodzących porównywalnie na tej samej ilości gigaflopów niezależnych od cpu/gpu, czyli podobnie jak teraz, tylko jak zwykle szybciej. O to właśnie w tym chodzi. Mental próbuje wywrzeć wrażenie, że wyznacza jakieś standardy, a tym czasem sprawy zmieniają równocześnie dla wszystkich, wolniej niż się im wydaje, i nie sądzę, żeby byli choćby o jotę dalej od Vraya czy Rendermana (który od dawna działa na cellach a taki kod przenieść na OpenCL to już formalność). Coś mi się wydaje, że im więcej mental się ogłasza, tym mniej ma do pokazania.

Nie onetowe teorie spisku, tylko prośba o zwykłą przyzwoitość. News to news, czyli informacja, reklama to reklama, czyli propaganda. Jak się te dwie rzeczy miesza wychodzi manipulacja. Oczywiście, że nic wielkiego się nie dzieje. To była grzeczna sugestia, a co dyrekcja ośrodka z tym zrobi, ich sprawa.

Nie o to chodzi, to jest news (choć zdaje się sprzed dobrych dwóch tygodni), ale wypadałoby go sformatować jak news, a nie bez skrępowania wkleić notkę prasową producenta/dystrybutora - najwyraźniej na zamówienie. O co chodzi? Że jak to internet, to nie trzeba być wiarygodnym? Zgadza się i dlatego taki dział powinien istnieć.

Nie ma tu gdzieś działu "Promocje, ogłoszenia płatne i linki sponsorowane"?

Tak, ale ta większość przed nami ma premierę wcześniejszą o... tydzień. Rażąca niesprawiedliwość i semicki spisek!

To świetny soft dla designerów, ale nie motion designerów.

To akurat nie ma nic wspólnego z regionem świata... Bywają filmy, które ukazują się w Polsce w tym samym czasie, co w Stanach... jest kalendarz premier, jest dostępna ilość ekranów, weekendów do zagospodarowania i prosta arytmetyka, która z kraju na kraj ma swoje zmienne. Wypuszczą Avatar za wcześnie i pójdą z torbami. Aczkolwiek po prawdzie na przykład "Odlot" ukazał się chyba za późno, hype opadł... Były jakieś wstrząsające premiery w czerwcu?

Nie zrozumielismy sie. Wskazniki byly przykladem na to, ze funkcje jezykow generujace trudnosci albo nawet zawile, bywaja niezastapione. Podobnie sprawa ma sie z elestycznoscia Pythona. Jest bardzo pomocna. Ludzie, ktorzy tworzyli Pythona slusznie zauwazyli, ze w wiekszosci przypadkow to wlasciwie od Ciebie zalezy czy uzywsz typow dynamicznych. I w praktyce tak wlasnie jest. Doswiadczony programista nie zmienia typow zmiennych nawet jesli jezyk mu na to pozwala. To samo mozna powiedziec o funkcjach chronionych i wielu innych magicznych cechach jezykow dla "prawdziwych programistow". Python - czyli jezyk skryptowy - powinien byc elastyczny i latwy w pisaniu, wiec czynienie mu z tego zarzutu jest conajmniej nietrafione. Slabe, dynamiczne typowanie i wciecia, spelniaja swoja role: pisze sie w nim szybko i przyjemnie. A ze nie nadaje sie do pisania obslugi promow kosmicznych... coz. Do argumentu z ignorancji, ktorego naduzywasz, nie bede sie odnosil, szkoda slow. Z latwoscia mozesz sobie sam wymienic dziesiatki powaznych projektow, stworzonych dla programistow i naukowcow (nie grafikow), przez doswiadczonych programistow, liczacych wiele milionow linii kodu, w ktorych z powodzeniem uzywa sie Pythona, zaczynajac od platformy Google, przez pipeliny duzych studiow czy chocby Numpy, Cortex, Zope, Django etc etc etc. A ze jego cechy predystynuja go raczej do tworzenia uzytecznych skryptow niz ciezkich aplikacji rozumiemy z zalozenia. Dlatego uzywa sie go do skrytowania aplikacji 3d, a nie ich pisania. Kazdy jezyk ma swoje "udziwnienia mogace tworzyc bledy". Jednym z nich jest szalony wymog, zeby kod napisal czlowiek, ktory jak wiadomo jest omylny.

Należysz to tego specjalnego typu ludzi, którzy silne strony Pythona uważają za słabości. Można też tak, ale z opinii, która jawnie przeczy doświadczeniu milionów, nie zrobisz wiarygodnego stanowiska. Ot, po prostu dziwactwo, choć trzeba przyznać, że pojawiając się od czasu do czasu na forach. Wszystko o czym piszesz to specyfika większości języków dynamicznych, które albo komuś podchodzą albo nie i nie bardzo jest o czym rozmawiać. To że słabe typowanie zachęca do błędów jest obiegową opinią ludzi wychowanych na na językach statycznych. Opinią równie znaczącą jak to, że wcięcia są trudniejsze do opanowania od nawiasów... Zresztą, w tej kategorii wskaźniki biją wszelką konkurencję i jakoś nikt się tym nie przejmuje. Oczywiście, siłą Pythona jest jego prostota, ale nie dlatego zyskał pozycję w branży. Zyskał, bo dzięki cechom, które Ty uważasz za wady, stał się językiem bardzo popularnym, co w konsekwencji doprowadziło do powstania masy modułów, na czym z kolei zależy ludziom decydującym się na Pythona jako język skryptowy w ich aplikacji. Bo z definicji ma działać jako klej do łączenia jej z innymi technologiami. Python ma oczywiście swoje wady, jest wolny, ciężki, i ma problemy z wątkami. Luę znacznie łatwiej jest osadzić w aplikacji. Najwyraźniej jednak zalety (te, które uważasz za wady), przesądzają sprawę. Ja się ciszę, choć przyznam, że ustawicznie kombinuję jakby tu podrasować Pythona ironem, albo ctypem ;) pozdr., skk.

Hmm, w czym przyjemniej się pisze?

Znów ktoś inny wykonał robotę za Autodesk. Brawo Blur.

Koledze chodzi o program, który będzie łączył z filmem efekty 3d przed ich wyrenderowaniem, jakie to nowoczesne! To tak jak jogurt z przyszłorocznymi truskawkami.

Tam są trzy kropki, przyjrzyj się dokładniej.

Czy się o komuś podoba, czy nie, XPx64 jest standardem w studiach windowsowych. Vista nigdy tego doświadczyła (i pewnie nie doświadczy, jeśli obietnice Windows7 są choćby w części prawdziwe). Przestarzały czy nie, mniejsza o to, ale pracują na nim tysiące profesjonalistów w każdym studio i nie zmieni się to do czasu SP1 dla Win7 (co najmniej).

Nawet jeśli ziarno prawdy w tym jest (reżyseria pozostaje nieodmiennie najsłabszym elementem filmów PI&Bagińskiego), to tonem swojej uwagi skazujesz ją na towarzyski lincz. Szkoda, bo można by było porozmawiać poważnie, a nie obrażać się nawzajem... Choćby o tym, na ile T.B. jest nadal sobą, a na ile produktem wykreowanym przez swą firmę (i bezkrytycznie przyjmowanym przez odbiorców z bagażem polskich kompleksów na karku). Kawałka o kończeniu elitarnych studiów szkoda komentować, bo to jawny fałsz.

no wlasnie, te wszystkie tech-dema na gpu, ktorych ostatnio tyle, swiadcza tylko o tym, ze nadchodzi kres gpu. Wszystkie implementacje CUDA zakladaja przesiadkle na OpenCL i dlatego nikt nie traktuje ich jak produkt, tylko jako zajawke nowej technologii. To jest okres przejsciowy w oczekiwaniu na cpu o podobnych mozliwosciach wektorowych. Zreszta OpenCL pozwala nie zastanawiac sie nad tym, co zwyciezly i zajac sie algorytmami, a nie platforma hardwarowa. To, co widzimy to prawdziwy kres renderowania DX/OpenGL na gpu. Epic na Siggraphie zapowiedzial, ze nastepny engine bedzie juz czysto softwareowy (a co zabawniejsze mikropoligonalny)... z pewnoscia ida zmiany, ale nie zupelnie takie, jak sie wydaje ;)

Napisałem dawno temu taki skrypt dla mplaya. Jest tam funkcja, która daje radę z większością formatów, poza klatkami floating point, coś jak: def padding(file, return_full_name=True): # find padding rule and applies it pic_dir = os.path.dirname(file) base, ext = os.path.splitext(os.path.basename(file)) list_base = list(base).reverse() count = 0 for letter in list_base: if letter.isdigit(): count += 1 else: break # generate new name: if return_full_name: if count != 0: if count == 1: base = base[0:-count] + "$F" else: base = base[0:-count] + "$F" + str(count) file = os.path.join(pic_dir, base + ext) else: if count != 0: base = base[0:-count] file = os.path.join(pic_dir, base) return file Całość znajduje się tutaj. pozdro, skk. (mplay otworzy w zakładkach kilka sekwencji jednocześnie, jeśli znajdzie je w katalogu/podkatalogach).

farsa. -----