danilo2

Hej! Własnie zauwazylem ze nikt nie rozreklamowal podcastu na max3d.pl. Mikolaj Valencia, founder Flowboxa, opowiada o podejsciu Flowboxa i multi-user workflow: :)

Ja Ci dam Nuka ze zmienioną skórką! :D Flowbox od poczatku ma zupełnie inną architekturę. Nuke i inne "nodowe" softy są graficznymi nakładkami na biblioteki (np. pisane w C++) - Flowbox bazuje na naszym własnym języku programowania - Lunie, posiadającym podwójną reprezentację - wizualno - tekstową. Innymi słowy - nody we Flowboxie nie są nakładką, są równoważną tekstowi reprezentacją języka programowania. W rezultacie: 1) Flowbox nie ogranicza się do kompozycji - używając nodów możesz zbudować dowolną aplikację - w tym nawet gry do przeglądarki (potrafimy kompilować się do JavaScriptu nawet). 2) Grafy we Flowboxie są optymalizowane po połączeniu tak jak normalny program, przez co uzyskujesz dużo lepszą wydajność niż przy zwykłych "graficznych nakładkach". 3) Luna daje użytkownikom pełen asortyment funkcjonalności dostępnych obecnie tylko dla programistów, w przejrzystej, wizualnej formie. Dzięki temu jest możliwe zbudowanie dużo bardziej zaawansowanych funkcjonalności prosto. Chcę tylko podkreślić, że różnimy się od innych rozwiązań nie interfacem, a tym co mamy pod spodem - co bezpośrednio rzutuje na wydajność, łatwość pracy i możliwości. Dużo więcej informacji i dyskusji o Flowboxie znajdziesz tutaj: http://max3d.pl/news/6183/flowbox-fx-narzedzie-do-przetwarzania-i-kompozycji-obrazow Jeżeli będziesz miał inne pytania, z chęcią na nie odpowiem :)

Krakowska firma CODDEE rozpoczyna pracę nad grą / symulatorem rzeczywistości uwzględniającym zaawansowane zagadnienia fizyczne. Planujemy zintegrować symulator z urządzeniami ze świata VR lub AR, takimi jak Oculust Rift czu Microsoft Holo Lens. Dokładne informacje dotyczące projektu podamy osobom zainteresowanym współpracą. Poszukujemy osób na następujące stanowiska: Graphic designer: Modeling (przygotowywanie assetów) Graphic designer: Texturing (przygotowywanie tekstur) Graphic tools: Houdini / Houdini Engine (przygotowywanie proceduralnych narzędzi automatyzujących pracę) Game developer: UE4 (tworzenie blueprintów i logiki gry) Developer: C++ (tworzenie narzędzi związanych z logiką gry / programowanie UE4) Oferujemy atrakcyjne zarobki (adekwatne do umiejętności) oraz możliwość pracy w młodym, dynamicznym zespole przy interesującym projekcie :) Jeżeli jesteś zainteresowany, napisz kilka zdań o sobie na maila: [email protected]

Monio - nie do końca - qt quick ma swój język który bazuje na tym paskudnym javascripcie. Anyway, natron nie używa qtquicka - to tak tylko jako ciekawostka :)

tmdag - Albercie, nie mówiłem stricte o języku, bardziej o Twoich pomysłach :) Odezwę się po Świętach :) deshu - wyrażenie to oznacza, że kompilator naszego języka zna typy wszystkich wyrażeń podczas procesu kompilacji i ma gwarancje że typy te nie ulegną zmianie w czasie wykonania programu. Pozwala to na: 1) zwiększenie bezpieczeństwa danego programu - wiemy że nigdy w runtimie nie dostaniemy błędu związanego z nieoczekiwanymi typami / wartościami które nie posiadają pewnych pól lub nie poleci nigdy jakikolwiek "null-exception" (Luna nie ma wartości null) 2) Lepsze optymalizacje danych funkcji - skoro znamy typy oraz ich układ w pamięci podczas pisania programu, możemy cały plik wykonywalny lepiej zoptymalizować + (jak wyżej już pisałem) automatycznie zrównoleglać obliczenia Więcej: http://pl.wikipedia.org/wiki/Typowanie_statyczne , http://en.wikipedia.org/wiki/Type_system#Static_type-checking Dodatkowo - Luna nie wspiera i nigdy nie będzie wspierała dziedziczenia. Jest to decyzja świadoma i celowo tak zaprojektowaliśmy język. Tylko bez obaw tutaj :) W językach takich jak C++ lub np. Python nie możemy wyobrazić sobie pisania programów bez dziedziczenia - taki design języka, nie ma innych mechanizmów. Bez dziedziczenia musielibyśmy pisać strasznie dużo boilerplatu i wszystko byłoby słabo utrzymywalne. Luna jednak, tak jak więszkość nowoczesnych języków programowania (np. Google Go), nie wspiera dziedziczenia i dostarcza innych, bezpieczniejszych mechanizmów, które pozwalają na tworzenie w prosty sposób nawet bardzo złożonych struktur danych, które dodatkowo są dużo bezpieczniejsze (jak już wpsominałem - brak wartości null, brak potrzeby rzutowania wartości etc). Znów wchodząc w szczegóły - Luna wspiera pełne algebraiczne typy danych oraz type mixiny. Rotomonks - Racja! Wybacz, przeoczyłem to najważniejsze pytanie. Tak jak mówi Azbesty - współpracujemy z niektórymi firmami + freelancerami i oni już testują Flowboxa. Dodatkowo chcemy wypuścić publiczną wersję beta gdzieś w okolicach marca / kwietnia (natomiast jeśli chcesz możemy odłożyć to do kolejnego grudnia by był prezentem na Boże Narodzenie! :D) Ryneczek dla nodów jest zintegrowany w aplikacji - możesz kliknąć na zakładkę toolset i po prostu zainstalować to co chcesz. Jest możliwość uploadowania zarówno zamkniętych, jak i otwartych narzędzi :) Dodatkowo - co do V8 i takich tam - czuję że niedługo JavaScript stanie się asemblerem przeglądarkowym i (mam nadzieję) nikt ne będzie pisał bezpośrednio w niej dużych aplikacji. Prawdziwy software wymaga lepszego (bezpieczniejszego) języka - co nie zmiania faktu,*że JS (lub ASMJS) jest idealnym wieloplatformowym asemblerkiem :) Hmm, nie wiem czy wpsominałem, ale Luna jest językiem wieloplatformowym, w takim sensie, że możliwa jest jej kompilacja nie tylko do kodu maszynowego ale również innych platform - obecnie pracujemy własnie nad JS, ale w przyszlosci powinno pojawic sie wsparcie dla Pythona, C++ i Javy. Oznacza to że w Lunie bedzie mozna złożyc z bloczków (lub napisac w kodzie) komponent dla systemu pisanego w innym języku + mamy już testy działającej Luny w przeglądarce :) Monio - dziekujemy bardzo za miłe słowa! :) Zrobimy co w naszej mocy by nie zabić tego produktu - nie po to poświęcamy już kilka lat z naszego życia :) Co do nodów - można je udostepniać / sprzedawać - jako narzędzia otwarte lub zamknięte. Co do zabezpieczeń otwartych nodów - przyznam się że nie myślałem o tym jeszcze - i tak, jest to bardzo ciężki temat. Bardzo chętnie porozmawiam z Tobą o tym - wyślesz mi proszę na pw swój adres mailowy ? :) olaf - dziękujemy bardzo! :)

Rotomonks - dziękujemy! :) (dziękując zazwyczaj mówię per "my", ponieważ to zasługa całego teamu) Ja wiem że język skryptowy dla wielu osób nie jest już obelgą - dla mnie jest. I może zabrzmię tu okrutnie, ale JavaScript nie zasługuje nawet na miano języka :) Już tłumaczę - i nie chodzi mi tu tylko o wydajność. Jasne że języki "interpretowane" doczekały się swoich JIT kompilatorów i optymizatorów, przez co ich wydajność wzrosła, choć nie jest i nigdy nie będzie zbliżona do np. takiego kodu pisanego w C++. Możemy optymalizować programy analizując dane pojawiające się w czasie ich wykonania (JIT-optymizery), ale wciąż optymizacje te bazują na o wiele mniejszej ilości danych dostarczonych kompilatorowi niż w sytuacji gdy język sam o to zadba. I tu dochodzimy do drugiego punktu - czyli system typów. Języki takie jak Python czy Ruby nie dostarczają użytkownikowi mechanizmów kontroli typów. Z drugiej strony C++ czy przegadana Java robią to za mocno i w rezultacie przyjemniej pisze się w Pythonie, ale gdy aplikacja rośnie, to ilość błędów i czasu potrzebnego na debugowanie / pisanie testów (które dodatkowo skutecznie utrudniają refaktoryzację takich tworów jak języki dynamicznie typowane) gwałtownie rośnie. Luna jest językiem statycznie typowanym z pełnym type inferencerem, którego reprezentacja tekstowa jest podobna do Pythona / Rubego. Oznacza to, że każde wyrażenie, każdą funkcję możemy otypować explicite, a jesli tego nie zrobimy, nasz kompilator zrobi to za nas. Dzięki temu mamy język który jest bezpieczny, statycznie typowany i bardzo mocno optymalizowany (też korzystamy z LLVM'a!). W rezultacie (co przekłada się również na postać wizualną) - Luna pozwala na pisanie wydajnych programów, których poprawność sprawdzana jest w czasie kompilacji. Ponadto nasz kompilator pomaga w pisaniu takich programów (np. podświetlają się te porty nodów do których jest sens podpiąć obecne dane). Ciekawostką może być fakt, że Luna potrafi analizować przepływające dane, sprawdzać w których miejscach występuje komunikacja ze światem zewnętrznym, oraz automatycznie zrównoleglać operacje na wiele CPU i GPU! A! I Luna nie ma nic wspólnego z Lu'ą poza trzema literkami :) Dla osób które lubią techniczne słówka, Luna jest czysto funkcyjnym, obiektowym*, leniwym, szczerym, statycznie typowanym, generalnego przeznaczenia językiem programowania z pełną inferencją typów. *-w Lunie występują obiekty, ale ich stan jest niemutowalny (nie oznacza to, że nie można zmieniać ich wartości). Przepraszam za lekko techniczne zabarwienie tej wypowiedzi, ale chciałem jakkolwiek uzasadnić to co mówię :) Mam nadzieję że odpowiedziałem na pytanie, w razie pojawienia się kolejnych, z chęcią odpowiem! :)

Hej ho! :) Ja tu tylko chciałbym zaznaczyć jedną rzecz - Luna (nasz język programowania) nie jest językiem skryptowym - to jest jedna z ważniejszych różnic. My kompilujemy Lunę do kodu maszynowego działającego z prędkością porównywalną do kodu pisanego w C++. Dzięki temu nasze nody mogą być tak otwarte bez strat wydajności :) tmdag - dziękujemy :) Albercie, to co mówisz o samym języku jest bardzo ciekawe. Też o tym myślimy od pewnego czasu. Z chęcią porozmawiałbym z Tobą (jeżeli będziesz chciał) więcej na ten temat :) Rotomonks - dziękujemy za kibicowanie! Robimy wszystko by było dokładnie tak jak piszesz (może poza "buńczucznymi zapowiedziami" :) ) Korzystając z okazji - wesołych Świąt! :)

Hej ho! Poszukujemy pilnie icon designera! Chodzi o stworzenie ikonek wektorowych, tak by dobrze rasteryzowały się na 16x16 px, 32 x 32 i 64 x 64 px - czyli wersji mało szczegółowych oraz takich z większą ilością szczegółów. Za 2 tygodnie jedziemy z Flowboxem na Siggraph do Chin - do tego czasu chcialibyśmy stworzyć ok 20 ikonek. Docelowo można zakładać że bedzie ich 100 - 150. Czekam na kontakt i dalsze pytania :) [email protected] Pozdrawiam serdecznie, Wojtek

@alexx600: Oczywiście studenci są mile widziani podczas alpha testów. Po prostu zaznacz odpowiedź "inne" i wpisz, że jesteś studentem :) @Obywatel: Dzięki Michale! :)

@Kramon: Tak, jak mówi olaf: mówimy o wsparciu CUDA i OpenCL. @Olaf: Wypuszczenie Alphy jest kwestią tygodni, finalnego produtu oczywiście trochę dłuższą. @Piotrek, @Obywatel: Obywatel Michał ma racje :) Napisałem to nawet kilka postów wcześniej :D Btw. skoro Wings jest napisany w Erlangu to pewnie da się używać erlanga do pisania skryptów wewnątrz? :)

Proponuję zamknąć offtopik i zweryfikować postawione w nim tezy za proponowane 60 lat :D Na uwagi i pytania dotyczące Flowboxa, o ile takie się pojawią, nadal z chęcią odpowiem :)

@Kramon: Testy za kilka tygodni :) Robimy co możemy :) @piotrek: Bardzo mnie to cieszy. Python nie jest w żadnym wypadku funkcyjny - to, że reklamują go w taki sposób, że możesz w nim pisać funkcyjnie jak się postarasz, czyli masz funkcje będące obiektami pierwszego rzędu lub możesz używać mapowania funkcji na iterowalne obiekty, to jest to fajny feature, ale nie ma to za dużo wspólnego z pełną funkcyjnością :) Co do batalii, to tak jak napisałem, bardzo dużo czasu poświęciliśmy na to, by Luna była prosta w użyciu, zrozumiała i szybka. Jak na razie ludzie, którzy korzystają z Luny i piszą w niej bibliotekę standardową, mówią że takiego języka jeszcze nie widzieli i nie jest on cięższy od Pythona - ale o tym porozmawiamy jak wyjdzie alpha :) @deshu, @olaf: Jest mnóstwo leniwych programistów i mnóstwo leniwych grafików :) @Kramon: Nie mogę się z Tobą zgodzić. Zależnie od zastosowania, można powiedzieć, że informatyka to też wykorzystanie kilku gotowych elementów, które należy połączyć i ... gotowe. Jest to prawda w niektórych zastosowaniach i tak samo jest z grafiką. Gdyby jednak tak było, to programy nodowe (Nuke, Houdini, poniekąd Maya) nie miałyby sensu - wszyscy używaliby AE i 3ds maxa :)

@SYmek: To jest bardzo dobre pytanie :) Pytasz typowo o język tekstowy, warto natomiast pamiętać, że reprezentacja graficzna rządzi się swoimi prawami i jak na razie nie znam żadnego rozwiązania, które pozwalałoby graficznie reprezentować przepływy funkcyjne. Erlang ma zastosowanie w telekomunikacji przede wszystkim dlatego, że został opracowany właśnie do tego zastosowania (firma Ericsson). Jak chodzi o erlanga to obsługuje on świetnie wątki, ale wciąż jest to język uruchamiany na maszynie wirtualnej erlanga => nie nadaje się do wydajnych obliczeń (chyba, że kluczowe elementy napiszesz w C++). Oczywiście istnieją języki funkcyjne, które nie działają na maszynach wirtualnych. Problem z nimi był i wciąż jest inny - ich składnia i sposób kodowania wydają się dziwne i nienaturalne. Dołożyliśmy wszelkich starań aby Luna - zarówno tekstowa, jak i graficzna, nie miały tego problemu. Ale to już pozostawiamy do oceny w Alphie :) @deshu, @Kramon, @Monio: Działa to tak jak mówi Monio :) Jeżeli masz obrazek i go blurujesz, to tak na prawdę robisz konwolucję tego obrazka przez pewną macierz - mówiąc po polsku - mnożysz 2 macierze i sumujesz pewne elementy. A więc możemy łatwo powiedzieć, które pixele są potrzebne do produkcji innych pixeli. Znając tą informację i informacje z innych bloczków, można stwierdzić jakie elementy można pominąć. Przykład - mamy nieskończoną tablicę liczb [1,2,3,4,5,6,7,8,..] i mamy bloczek, który dla każdego elementu zwraca wartość jego zsumowaną z kolejną wartością, czyli [1+2,2+3,3+4,4+5,5+6,..], czyli [3,5,7,9,11,..] - jeżeli teraz położysz bloczek "wypisz 5 pierwszych elementów", to z tej nieskończonej tablicy liczb zostanie pobranych 6 elementów - bez żadnego przestawiania operacji :) (tak, Luna wspiera nieskończone tablice i ogólnie nieskończone struktury danych :)) @olaf: Cieszę się, pamiętaj jednak, że Alpha to nie jest finalny produkt i na pewno nie będzie nadawała się do zastosowań produkcyjnych, ani nie będzie miała funkcjonalności porównywalnych np. do Nuke :)

@olaf: Zapraszam do zapisania się do Alphy :) Dokumentacje i podstawowe tutoriale mamy, ale udostępnimy je dopiero w Alphie. @legomir: Nie ma za co - postaram się następnym razem więcej spać i dokładniej opisać rzeczy (jak celnie zauważył w niektórych przypadkach Szymon :) ) @Szymek: Hej Szymku! Dziękujemy bardzo! Porównanie Luny do scyzoryka w kontekscie VEX'a i ICE'a jest bardzo fajne! Muszę to zapamiętać :) Masz Szymku absolutną rację! Moja wypowiedź powyżej była niekompletna i mogła wprowadzać w błąd. Wynika to trochę z faktu, że przez ostatnie dni bardzo mało sypiam ale postaram się takie tematy tłumaczyć dokładniej. VEX jest typowym procesorem SIMD - ja wiem, że może przetwarzać dźwięk, obrazy, voxele etc. Dużym problemem z VEX'em natomiast jest to, że jest on językiem imperatywnym. Oznacza to (to tłumaczenie nie jest skierowane do Ciebie Szymku), że pisząc w Vexie piszemy krok po kroku instrukcje które mają być nałożone na dane. (To tak jak w C++, Javie, Pythonie, Rubym, JavaScripcie i wszystkich innych językach imperatywnych). Luna jest językiem funkcyjnym (podobnie jak Erlang, Haskell czy Scala) - oznacza to, że my piszemy co chcemy uzyskać, niekoniecznie w jaki sposób. Mimo, że podejścia wydają się podobne, w Lunie i Flowboxie nie występuje bardzo wiele problemów występujących w ICE lub Vexie. Mówię tu między innymi o "side effectsach" (czyli efektach ubocznych - termin informatyczny, nie mylić z producentem Houdiniego), globalnym stanie danych etc (można więcej poczytać tutaj: http://en.wikipedia.org/wiki/Functional_programming). Co takie podejście niesie za sobą? Luna nie tylko jest doskonałym procesorem SIMD! Nie musimy zastanawiać się nawet jakie dane ktoś chce przetwarzać - możemy z łatwością wykrywać przepływy, które można zrównoleglić i jesteśmy w stanie dostarczyć wielu funkcjonalności, których nie będzie w stanie dostarczyć ani VEX ani ICE dopoki nie przepiszą wszystkiego od nowa - mówię tu zarówno o bardzo fajnym zarządzaniu pamięcią (mamy w wielu miejscach praktycnzie statyczny garbage collector - dane są niszczone dokładnie w miesjcu, w którym przestają być potrzebne, Luna jest językiem "lazy", co oznacza, że nie oblicza zbędnie danych - jeżeli każemy jej zblurować obrazek, a potem wyciąć tylko dolny lewy róg, to tylko ten róg zostanie zblurowany (oczywscie na GPU) etc). Reasumując - stworzyliśmy nasze bloczki i tekstową wersję Luny bazując na bardzo mocnych przemyśleniach dotyczących architektury istniejących aplikacji i jak dla mnie największą siłą Luny jest to, że daje ona zupełnie nowe możliwości optymalizacji, niż jest to obecnie możliwe. Nie wierzę, by Vex bez zmian architektonicznych mógł być "automatycznie" i w każdym przypadku tłumaczony na GPU, tak jak nie istnieje możliwość tłumaczenia C++, Pythona, Javy i innych języków imperatywnych. Oczywiście Side Effects będzie w to wkładał kase i dorabiał pewne ograniczone możliwości - np. dla każdego punktu geometrii, lub kazdego voxela, lub każdego pixela etc - ale w ogólności nie dostarczy takich rozwiązań jak Luna, dopóki nie napiszą tego od 0. Już Bifrost jest o wiele bliższy bardziej ogólnego rozwiązania, ale wciąż - ich idea robienia z bloczków jednego dużego grafu i jego kompilacji jest słaba - szczerze mówiąc jest to idea jaką Flowbox miał 1,5 roku temu - gdy rozmawialiśmy o Lunie z Tobą Szymku wtedy w Krakowie o ile dobrze pamiętam :) Racja, oni przeszli, jak się nie mylę, na LLVM'a i JIT. LLVM dostarcza im pewnych optymalizacji + dodatkowo możliwość wsparcia OpenCl'a w fancy way (jak opisałem powyżej). Nie zmienia to jednak faktu, że dopóki nie zmienią podejścia imperatywnego na funkcyjne (też opisane wyżej) będą mieli zupełnie inne problemy niż my. Będą mieli problem choćby w zrównolegleniu kodu wywołującego funkcje (!) - analiza zależności między funkcjami jest niemożliwa (jeszcze nikomu się tego nie udało zrobić) - mówiąc prościej - nie jesteśmy w stanie np. w C++ przeanalizować czy wywołując funkcje nie zmienia ona pewnych globalnych danych w programie, które mogą wpływać na wyniki działania innych funkcji, a co za tym idzie nie wiemy czy tą część kodu da się zrównoleglić, bo nie wiemy jak powinna wyglądać komunikacja między wątkami na takiej przykładowej CUDA'ie. Oczywiście mogą ograniczyć VEX'a i zrobić z niego prościutki imperatywny język z bardzo ograniczonym dostępem do pamięci i trochę poprawić sytuację na tym polu, ale w tym momencie nie ma co porównywać drewnianego scyzoryka do takiego samego, tylko z metalu :) Bardzo mocno nad tym pracujemy! :) Dziękuję Szymku za ważne uwagi! :)

@legomir: Nasza Luna ma 2 równoważne reprezentacje - wizualną i tekstową - oznacza to, że możesz przełączyć się między kodem a językiem wizualnym w dowolnym momencie pracy (edytując kod - edytujesz nody, edytując nody, edytuje się kod). Jeżeli chcesz, możesz również nody pisać w C++ lub innych wspieranych językach, ale nigdy nie jest to wymagane. Dzięki za info od Houdiniego - fajnie, że to dodali akurat tą konkretną możliwość, co nie zmienia wyglądu całej sprawy. Fabric Engine - służy do tworzenia wydajnych aplikacji w Pythonie i JavaScripcie. Ich logiczny system nodów znowu podlega pod sheduler a ich język KL jest mega prymitywny. Celują w zupełnie inną działkę niż my. Houdini Engine - to już prędzej. Natomiast Houdini (tak jak i Houdini Engine) bazuje na tym samym "silniku node'ów", który opisywałem powyżej. Poza wadami, które wymieniłem - Houdini celuje w przetwarzanie grafiki 3D i symulacje (2D też mają po drodze). Natomiast w każdej z tych działek - jeżeli chcesz zrobić coś bardziej zaawansowanego, szybko dochodzisz do ściany, ponieważ dostępne nody nie pozwalają Ci na nic więcej. Bifrost - o nim dokładniej napisałem na cgsociety: http://forums.cgsociety.org/showpost.php?p=7695786&postcount=17 Z chęcią odpowiem na dalsze pytania na ten temat :) Flowbox, tak jak i każdy produkt na świecie ma konkurencję - do tej konkurencji możemy zaliczyć każdy system nodowy przetwarzający dane. Mówię tu o Houdinim, Max MSP, ICE, Fabric Engine, XSI, TouchDesignerze, vvvv, etc - przykłady można mnożyć. Chcemy dostarczyć rozwiązanie, które będzie działalo lepiej, dawało większą swobodę i szybkość pracy, a przy okazji będzie o wiele bardziej otwarte, niż pozostałe. Chcemy, abyś na naszych nodach był w stanie w prosty sposób stworzyć przepływy modyfikujące np. dźwięk, w momencie gdy my dźwięku nawet nie wspieramy :) Czy udało mi się wytłumaczyć Tobie naszą ideę lepiej? :)