CgBartosz

Poszlo na PM. Uzycie bardzo proste: import pymodulelib pymodulelib.load_exr("sciezka do pliku exr") Wszystkie zaleznosci powinny byc statycznie skompilowane z modulem. Dziala z pythonem 3.6.4 [MSVC v.1900 64bit (AMD 64)] Dziala ?

Hej Deshu, Mam dla Ciebie skompilowany modulik pythonowy z ta funkcja. Chcesz sprobowac ?

Zrobilem tescik w innym jezyku i bez alfy (nadal nie wiem po co filtrowac przez alfe). Tutaj ogolny czas to 10.743991487S sekund a wartosci ktore otrzymalem to : ::-214.834 -124.402 (Deshu, zgadza sie ? pewnie nie, LOL). Co ciekawe, srednia odczytu z dysku to okolo 68Mb/s co sprawia iz mysle ze skompilowalem C++ w debugu (sciagnalem bilbioteki z netu). Przebuduje je pozniej w tym tygodniu i sprawdze ponownie C++. fn main() { let start = PreciseTime::now(); let mut file = std::fs::File::open("X:/Temp/massivedesign-dd8e20/VrayZdepthCalculator_RGBA_8k.exr").unwrap(); let mut input_file = InputFile::new(&mut file).unwrap(); let (width, height) = input_file.header().data_dimensions(); println!("{} {}",width, height); let mut pixel_data = vec![0.0f32; (width*height) as usize]; { let mut fb = FrameBufferMut::new(width, height); fb.insert_channels(&[("PG.VrayDepthCalculator.B", 0.0)], &mut pixel_data); input_file.read_pixels(&mut fb).unwrap(); } let mut min_val = f32::MAX; let mut max_val = f32::MIN; for x in pixel_data.iter_mut() { let y = *x; min_val = min_val.min(y); max_val = max_val.max(y); } println!("::{:.3} {:.3}",min_val,max_val); let end = PreciseTime::now(); println!("Processing Time: {:.3}", start.to(end)); } 8192 8192 ::-214.834 -124.402 Processing Time: PT10.743991487S

Heja, Deshu, Zlozylem apke w c ale wiekszosc czasu spedza na czytaniu pliku z dysku. Czy exr jest skompresowany ? Na moim komputerze cala operacja to okolo 23 sekundy (przy odczycie ~32Mb/s) z czego 22 spedzone na czytaniu danych z dysku. Jesli w twoim wypadku cala operacja zajmuje 30 sekund to jest wolniej. Do czego uzywasz kanalu alfa, mozesz zzrezygnowac z wczytywania tego kanalu ? Moze daloby sie policzyc te wartosci wprost ze sceny iterujac po bounding boxach i wybierajac najblizszy i najodleglejszy punkt ?

Ojej, sorry, nie zauwazylem, skoncentrowalem sie na rozwiazywaniu sytuacji z wolnym pythonem. Ktos chetny do kontynuowania glownego tematu ? Moze trzeba poprostu juz zamknac ten watek ?

Tak, mase rzeczy, nie udostepniam wlasnych co prawda ale kazdy modul zgodny z ABI interpretera sie normalnie importuje. - - - Połączono posty - - - Hej Deshu, Znajdziesz jakiegos exrka z tymi atrybutami ? Chce sprawdzic czy bedzie szybciej w c++. Napewno ladowanie 8k z dysku zajmie troche czasu. Jak dlugo sie wykonuje Twoj skrypt ?

Hej Deshu, Czy te linie zwracaja liste pikseli ? Jaka rozdzielczosc maja te obrazki ? dist_list = exr.get("PG.VrayDepthCalculator.B").flatten().astype(float) alpha_list = exr.get("A", precision=pyexr.UINT).flatten().astype(float) Masz cos przeciwko aby udostepnic mi jeden z tych exrow? Nie musi byc z projektu, jedynie by representowal problem i wartosci byly na wszystkich pikselach. Dzieki

Hej Deshu, Jak to dyskwalifikuje pythona, uzywam pythona w maxie od 2005 roku bez specjalnych problemow wszystkie. Maya jest wiekszym problemem gdyz Adsk uzywa innego kompilatora niz python i trzeba budowac wszystkie biblioteki ze zrodel. W przyszlym roku aplikacje 3d (te mainstreamowe jak hudy, max, maya, itp.. Nuke chyba tez) zostana zmodernizowane i dostana pythona 3.x.Sekunda, zerkne ten skrypcik... Jeszcze nawiazujac do python 3.0 i jego featuresow ? Ktorych dokladnie features brakuje Ci w pythonie 2.7.12 a ktore ma ostatnia wersja ?

To troche tak jakbys powiedzial, ze w kontekscie wyscigow rownoleglych walec jest wolny... Tutaj zgodze sie z Toba bo jest ! Maxscript to nie tylko jezyk skryptowy, 3dsmax ma mechanizmy (Function Publishing) pozwalajace rozszerzyc funkcjonalnosc w c++. Wielokrotnie daje to wiecej mozliwosci niz wbudowane funkcje. Inne jezyki takze sa osadzone w maxscript, dla przykladu dotNet oraz ostatnio python. SDK maxa ma bardzo wiele przykladow ktore mozna szybko przerobic na wlasne potrzeby jesli mxs okazuje sie nieodpowiedni do sytuacji i staje sie ograniczeniem. https://help.autodesk.com/view/3DSMAX/2016/ENU/?guid=__files_GUID_016E96CE_F224_458D_9AC8_84C8E8403D5E_htm Przyklad funkcji maxscript w c++: #include #include def_visible_primitive(IntervalArray, "IntervalArray"); Value* IntervalArray_cf(Value **arg_list, int count) { return &ok; }

Hahaha, nie wiem czy chcesz tego sluchac, LOL. poslij e-maila na priv, cos wymyslimy.

Tak robie. Mam kilka syntezatorow zewnetrznych, nie uzuwam VSTi, jakos lubie urzadzenia z pokretlami i guziczkami. Caly projekt jest oparty na midi aby miec latwosc wymiany dzwiekow i strojenie. komponuje w ten sposob jeden ciagly set. Musi koniecznie dzialac w realtime bym mogl swobodnie manipulowac pokretla. Nagrywam to do audio i powstaje 6 sciezek. Na kazdej sciezce mam lancuch pluginow do saturacji, eq, kompresory, mozesz to nazwac "mastering/saturation chain". Nagrywanie instrumentow wraz z wlaczonymi pluginami powoduje dropouty bo komputer nie wyrabia. Przesunalem ten proces w inne miejsce i moge teraz pracowac bez tego lancucha i poprostu renderuje "preview" na innej maszynie, lub na bardzo niskim priorytecie w tle. DAW i tak nie byl w stanie wykorzystac 100% mocy obliczeniowej a jedynie 50%. Zazwyczaj przerwarzam wszystkie sciezki w ten sposob i na koniec, w kolenym projekcie dodaje jeszcze kilka lancuchow i renderuje sendy z efektami juz do jednej finalnej sciezki.

Dzieki Kroopson za temat. Moja odpowiedz chce zaadresowac do Hris'a poniewaz znalazlem ciekawa analogie pasujaca do mojego obecnego profilu zawodowego (pipeline td) i zainteresowania produkcja muzyki elektronicznej. Na przykladzie drogi przez ktora przeszedlem celem usprawnienia pipeline'u stworzonego na wlasne potrzeby tworzenia muzyki, sprobuje zobrazowac jak wyglada praca nad prostym projektem podobnym do projektow automatyzacji zadan w production pipeline. Problem: Skladam set audio trwajacy okolo 30 minut na starym rzechu laptopie z Core2 Q9300 2.5Ghz, 16Gb ramu i win7. DAW (Digital Audio Workstation) zaczyna rzezic przy 400 barach z 30 zewnetrzymi instrumentami. Nie moge nic zrobic w takiej konfiguracji gdyz dzwiek sie zwyczajnie wiesza losowo na kilka sekund co kilka sekund. Bardzo prawdopodobne ze przyczyna jest opoznienie w tranferze midi i synchronizacji sampli audio z i do kilku fizycznych interumentow/efektow . Moglbym kupic laptop i audio interfejs za 2000 dolarow ale to tylko hobby wiec nie wydaje. Ponadto lubie pisac software i rozwiazywac problemy. W wypadku nadmiaru gotowki, zapewne kupilbym nowy komputer. Celem jest opracowanie plynnego srodowiska pracy oraz przetworzenie 6 sciezek audio, okolo 30-60 minut kazda, za pomoca pluginow VST bez przeciazania aplikacji DAW jednoczesnie unikajac monotonnego eksportowania ustawien pojedynczych pluginow i trzymania konfiguracji w jednym miejscu (plik projektu DAW). Process: Sprawdzam czy DAW ma jakis API czy SDK w jakimkolwiek jezyku, jezyk jest bez znaczenia, jesli ma w jezyku ktorego nie znam, naucze sie uzywac kolejnego. Nie ma nic. Jedyne API dostepne sluzy do tworzenia presetow z mapowaniem kontrollerow midi wiec odpada. Zaczynam grzebac w tych skryptach pytonowych czy nie ma tam jakiejs funkcji ktora pozwoli mi wywolac wewnetrzne komendy aby przetworzyc projekt w trybie wsadowym. Nic nie znajduje wiec sprawdzam linie komend lecz i tutaj kompletne zero. Moge jedynie polecic aplikacji aby otworzyla projekt. To troche malo. Obserwuje co robi aplikacja, jakich wywolan systemowych uzywa by dzialac, troche tego jest ale nic przydatnego. Szukam w sieci czy ktos juz tego nie zrobil. Znajduje jakis programik OS zdolny przetworzyc audio za pomoca pluginow VST w trybie wsadowym. Programik zostal napisany w C (nie c++). Testuje, cos dziala, cos nie dziala ale jest open source, w razie czego moge naprawic. Udaje mi sie skonfigurowac przetworzenie pliku audio za pomoca darmowego pluginu, Fantastycznie, zakladam ze bedzie dzialac. Wracam do projektu w daw. W projekcie mam 30 instrumentow i okolo 6 finalnych sciezek audio. Na kazdej z 6 sciezek + master bus Masa jakichs pluginow EQ, saturacji, kompresorow, maximizerow, reverbow, delay, itp.... niektore mono, inne stereo, itp... 30-40 instancji kilku pluginow w roznych konfiguracjach, kazdy ma okolo 10-20 parametrow. Hmm... Jak to przeniesc do tego programiku wsadowego ktory znalazlem ? Kazdorazowy reczny eksport z pewnoscia sprawi iz szybko zmienie hobby na hodowle rybek, wiec odpada. Nie ma api, nie ma sdk... Czy daw zapisuje pliki w formacie ascii ? Otoz nie, jakies binarki, ogladam te binarki ale jakos znajomo wygladaja, ogladam dalej, przypomina skompresowany plik !! Rozpakowuje zipa i moim oczom ukazuje sie przepiekny XML, jedyne 600 000 linii, czytam... Ok, sporo uzytecznych informacji, ladne struktury danych, teoretycznie mozna wygenerowac taki plik automatycznie lub przerobic na wzorce i zbudowac modularny genrator w przyszlosci. Teraz moge z tego wyeksportowac presety do aplikcji wsadowej. Tu i uwdzie znajduje bloby (binary large object, dane w postaci binarnej). Zapisuje bloby bezposrednio, binarnie do plikow. Porownuje z recznie wyeksportowanym presetem i wyglada podobnie jednak dane sie roznia i zadna aplikacja nie chce uznac tego czegos za poprawny plik z presetem. Studiuje format pliku presetow stosowanych w branzy audio i format pluginow VST, ok, brakuje naglowkow. W xml'u jest masa danych dla pluginu, z tych pojedynczych wartosci, skladam naglowek, wpisuje do pliku i zaraz za tym wpisuje tego bloba z xml'a, nadal nie dziala. Okazuje sie ze architektura pluginow VST sprawia iz brakuje mi waznej informacji o wersji formatu presetu uzywanego przez dany plugin. Plugin "wie" jak wczytac wlasny plik presetu i wyeksportowac lecz nie manifestuje tej informacji. Eksportuje preset z kazdego typu pluginow uzywanych w moim projekcie, czytam krzaczki w notepadzie aby sklasyfikowac typ presetu, wpisuje tablice wyszukan na twardo w kodzie (zanim znajde lepsza metode). Teraz moge wczytac presety do aplikacji wsadowej, pieknie. Skladam baze danych w postaci normalnej, kilka tabel aby moc zapisywac kolekcje, wersje i przelozyc to na scieki na dysku. OK, mam api bazy danych w pythonie, moge tworzyc folderki z numerkami wersji automatycznie. Dzieki temu kazda nowa wersja ma swoje miejsce. Na szczescie DAW przechowuje relatywne sciezki do sampli audio. Dodaje detekcje i kopiuje wszystkie pliki wave do wersjonowanej struktury w celu zachowania historii. Ponad to, dodaje eksport presetow jako wersjonowane pliki oraz pliki wsadowe z komendami celem manualnego przetwarzania poszczegolnych kanalow w razie problemow lub lokalnych zmian. Miele projekt z DAW aplikacja wsadowa, nic nie dziala. Aplikacja nie moze znalezc pluginow mimo iz wszystko ustawione jak dokumentacja sugeruje. Znajduje odwolania do sciezek pluginow w xml'u, dodaje, nadal nic. Zagladam do debuggera i okazuje sie ze brakuje slashy na koncach sciezek (ani slowa o tym w dokumentacji), super, dodaje slashe. Teraz aplikacja moze przetwarzac tylko 8 pluginow jednorazowo, zmieniam kod na 256 i kompiluje ponownie. Okazuje sie ze pluginy ktorych uzywam sa dwoch roznych typow, vst is shell-vst. Moj kod nie obsluguje shell-vst, dodaje odpowiednie nazwy w komendzie wsadowej pod tymczasowym switchem testuje, dziala. Nie lubie switcha, dodaje listing typow i nazw pluginow do aplikacji wsadowej, parsuje output z lini komend i buduje liste odwolan dynamicznie. Dziala pieknie. Aplikacja przetwarza sciezke za sciezka, troche wolno, 30 minut * 6 sciezek + master. Dodaje szybko przetwazanie rownolegle w pythonie i ograniczam ilosc do liczby procesorow w maszynie (4 w tym wypadku) na niskim priorytecie abym mogl nadal komputera uzywac w trakcie przetwazania. Wszystko pieknie smiga ale biblioteka nie odzyskuje wolnych watkow z puli i czeka az wszystkie skoncza, troche slabo. Szukam w sieci, wyglada jak ograniczenie bliblioteki pythona. Znalazlem bug report gdzie ktos opisal problem i bez zglebiania tematu odkladam to na pozniej. Jest szybciej i moge pracowac w DAW, co prawda nie brzmi tak pieknie jak po przetworzeniu ale przyblizenie jest dosc dobre. Teraz czas na master bus. sciagam sox (darmowy program do obrobki audio) i konfiguruje aby skleil przetworzone sciezki w jeden plik i przepuszczam ten plik ta sama metoda jak wszystkie inne kanaly z ta tylko roznica, ze informacja o pluginach pochodzi z galezi master bus z xml'a zamiast z odpowiednio nazwanych sciezek. Zapomnialem wczesniej dodac, aby znalezc odpowiednie kanaly w xml'u zastosowalem konwencje nazywania kanalow, cos jak "*AudIN" (audio in). W tym momencie, aby przetowrzyc nowa werje setu, musze wywolac pythonowy skrypt ze sciezka do natywnego pliku DAW, to za duzo. Dodaje programik sledzacy zmiany w folderze i gdy kopiuje tam plik, caly proces startuje automatycznie. Nadal za malo gdyz otwieranie folderu z plikiem i double click w celu odsluchania to stanowczo za duzo pracy. Dodaj kilka funckji generujacych nowy projekt dla DAW z wpietymi oryginalnymi i przetworzonymi plikami audio i kopie wylaczonych pluginow z oryginalnego projektu aby moc A|B porownac efekty. W ten sposob nie mam referencji do instrumentow i projekt jest o 80% lzejszy wiec da sie jako tako odsluchac brzmienie zmian w ustawieniach pluginow. Zmieniam ustawienia, zapisuje do folderu, przepuszczam przez pipe i otwieram nowy projekt, i tak w kolo macieju. Programowanie narzedzi do generalnego pipeline w produkcji vfx czy animacji tak naprawde nie rozni sie wiele od opisanego procesu. Zazwyczaj, efektem koncowym tej calej akrobatyki, jest system sluzacy jako wartstwa abstrakcji miedzy uzytkownikiem i poszczegolnymi systemami dramatycznie skracajaca czas treningu i efektywnosc artysty. Idealnie, ten sam interfejs do wszystkich programow pozwalajacy na wykorzystanie najsilniejszych stron kazdego z nich w najkrotszym mozliwym czasie. Dokladnie tak samo jak interfejs maya jest warstwa do podsystemow animacyjnych, modelowania czy efektow. Mam nadzieje ze ten opis przybliza nieco process automatyzacji i obrazuje fakt iz praca pipeline td jest dosc interesujaca dla osob ktore lubia rozwiazywac zlozone problemy i dobrze radza sobie z frustracja w sytuacjach wygladajacych na "bez wyjscia". Wyjscie z sytuacji zawsze sie znajdzie, niekoniecznie takie samo jak oryginalnie zalozone lecz cel uswieca srodki. Wedlug mnie jest to bardzo ciekawa praca, szczegolnie ostatnio kiedy jest tyle parcia na realtime i coraz czesciej potrzebna jest automatyzacja zadan w silnikach takich jak unreal czy unity i ogolnie granica miedzy silnikami i aplikacjami dcc powoli sie zaczyna rozmywac. Dlaczego ludzie sie tego nie ucza ? Malo kto wie na czym polega praca pipeline td ?

Hej, Jesli ktos jednak powaznie mysli o pracy jako pipeline TD i kodzi w maya od min 8 lat, zapraszam na priv.

Takie bledy zazwyczaj powoduje naruszenie dostepu czyli jakas czesc programu probuje pracowac poza strona procesu. Stack trace nie powie dokladnie dlaczego sie to dzieje. Byc moze wskaze modul powodujacy problem. Debugowanie tego rodzaju bledow moze byc dosc frustrujace. Jako ostatnia deska ratunku pozostaje metoda dziel i zwyciezaj. LOL, czyli manualne przeszukiwanie sceny poprzez binarne usuwanie jej zawartosci. Mam nadzieje, ze wiesz co mam na mysli.

Sciagnij symbole od autodesku i otworz tego dumpa w jakims debugerze to Ci powie skad bledy. Mozesz tez wkleic stack trace tutaj.