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? :)

@Bilay: Odpiszę Ci jutro, bo dzisiaj zdążyłem odpisać tylko legomirowi (poniżej). Przepraszam :) @Monio: Racja. Co ciekawe (i może Cię to zainteresuje) - nasz Flowbox pozwala Tobie na definiowanie bloczków przetwarzających dowolne dane - możesz na przykład stworzyć bloczki, które przetwarzają 3D albo tworzą proceduralne opisy tekstur. Co jeszcze ciekawsze - możesz takie bloczki wraz z naszym środowiskiem "obrandować" i dystrybuować jako Twoją platformę do proceduralnego tworzenia leveli do gier - pozwalając Twoim użytkownikom na wizualne ich tworzenie. My właśnie w ten sposób tworzymy Flowboxa FX - to są bloczki pozwalajjące na przetwarzanie i kompozycję obrazu, bazujące na naszej platformie Flowbox. :) @M@Ti: Dzięki :) Też się cieszymy! @szawel: Flowbox będzie działał na wszystkich platformach - linuxie, macu i windowsie. "...zamkniętą wersję alfa..." oznacza, że nie wszystkie osoby, które się zapiszą zostaną przyjęte do grona alpha testerów - grono to zamierzamy powiększać aż do wydania produktu w wersji 1.0. Odpowiadając na pytanie poboczne - tak, nasze narzędzie będzie produktem komercyjnym. @legomir: Hej :) W dużym skrócie: Luna (nasz język) posiada o wiele większe możliwości, daje Ci większą kontrolę, o wiele łatwiejszy sposób wyrażania myśli i często dużo większą szybkość niż VEX czy ICE. A teraz, żeby wyjaśnić moje powyższe słowa, musimy zajrzeć pod maskę :) Problemy istniejących systemów nodowych Wraz ze wzrostem ilości node'ów, przepływ wykonywany jest coraz wolniej Jesteśmy bardzo mocno ograniczeni możliwościami takich bloczków - często musimy głowić się i wykorzystywać pewne bloczki "naokoło", wykorzystując bloczki nieprzeznaczone do tego konkretnego zastosowania. Nie jesteśmy w stanie w pełni wykorzystywać naszego hardware'u - z wielu CPU / GPU potrafią korzystać tylko te narzędzia, które zostały specjalnie do tego przygotowane - sam natomiast, tworząc przepływy bloczkowe, nie możesz oczekiwać tego, że będą one wykorzystywały CPU / GPU wydajnie. Istniejące systemy nodowe skupione są na pewnym rodzaju danych - jeżeli chciałbyś dla przykładu komponować obrazy 2D w ICE, musiałbyś napisać odpowiednie bloczki w C++ albo poczekać aż Autodesk to zrobi (chyba że ICE ma już wsparcie dla 2D) - w każdym razie sam łatwo tego nie zrobisz. Zarys działania istniejących systemów nodowych (np. ICE) Postaram się pokazać Ci trochę głębsze spojrzenie na cały temat, ale będzie to wymagało nieco bardziej technicznego spojrzenia. Luna (nasz język) nie posiada schedulera node'ów - mechanizmu spotykanego w większości bloczkowych rozwiązań, który opisuje w jaki sposób wykonują się nody. Taki sheduler najpierw każe wykonać pierwszy node, potem drugi, kolejny (etc) przesyłając pomiędzy nimi dane. Podejście to sprawdza się przy niewielkiej ilości bloczków, ale przy większych scenach szybko pokazuje swoje wady. Dlatego też w praktycznie wszystkich rozwiązaniach dostępne są bloczki napisane w pewnych niskopoziomowych językach (jak C++), a oprogramowanie pozwala nam używać ich w celu opisu pewnych wysokopoziomowych operacji. To jest też powodem tego, że nie możemy np. w Houdinim "wejść do środka" nodu "blur" lub nodu opisującego symulacje rigid body. To wszystko niesie za sobą wyżej wymienione konsekwencje - spowolnienie działania przy dużych networkach, często utrudnioną pracę, dalekie od optymalnego wykorzystanie mocy sprzętu (CPU, GPU). A co z VEX? Vex jest bardzo specyficznym rozwiązaniem, więc opiszę go osobno. W VEX'ie jesteś w stanie opisywać pewne ograniczone przepływy (np. w kontekscie SOP'ów możesz używać Vexa w VOP'ach tylko do przetwarzania atrybutów punktów bez kontekstu - czyli bez uwzględnienia sąsiadów tego punktu). Oczywiście pewne proste operacje można "fakować" używając node'ów do obsługi chmury punktów - ale w tym momencie staje się to wszystko ciężkie w użyciu, a sam ten opis jest już bardzo skomplikowany. VEX'a nie możesz używać również do przetwarzania dowolnych danych - jak geometria, dźwięk, obraz 2D, symulacje - możesz używać go w ściśle okreslonych miejscach. To co zrobisz w Vexie zamieniane jest na coś C++ podobnego, a następnie kompilowane i uruchamiane. Vex może być uruchomiony na wątkach, bo jest dozwolony właśnie w takich kontekstach - jak np. przetwarzanie atrybutów każdego punktu geometrii. Takie rozwiązanie co prawda pozwala na uzyskanie szybkiego kodu (często szybszego niż analogiczny działający na bloczkach ICE), ale możliwości wykorzystania VEX'a są (jak już wspomniałem) są bardzo ograniczone. Poza tym nie ma co liczyć na automatyczną równoległość na GPU / CPU czy dostęp do standardowych struktur programistycznych (skoro pytasz o VEXa to jesteś blisko programowania) - takich jak tablice, mapy czy choćby funkcje lub lambdy. Kilka słów o nodach w Houdinim Poza tym, że w niektórych miejscach możemy używać VEX'a - problem pozostaje ten sam - jeżeli stworzymy wiele node'ów, network działa coraz wolniej. Bloczki są bardzo ograniczone, a o automatycznej ich równoległości na CPU i GPU możemy tylko pomarzyć. A więc co z tą Luną? (bloczkowym językiem Flowboxa) Bardzo ważna dla nas jest łatwość pracy użytkownika. Nie chcemy aby kiedykolwiek czuł sie ograniczony przez nasze narzędzie albo by musiał szukać jakiś obejść, wynikających z ograniczeń bloczków - co ma miejsce w codziennej pracy takiego przykładowego Houdiniowca. Sama Luna to ogromne przedsięwzięcie. Nasze nody kompilowane są przez nasz kompilator do szybkiego kodu maszynowego. Innymi słowy - nasze narzędzie analizuje w jaki sposób przepływają dane, optymalizuje przepływ, wyszukuje miejsc możliwych do zrównoleglenia na CPU i GPU i robi to wszystko przeźroczyście dla użytkownika. W wyniku, dostajesz dostęp do standardowych narzędzi - znanych z innych softów, ale masz pewność, że nie ważne ile bloczków połączysz, z Twojego sprzętu zostanie wyciśnięte więcej mocy (i co ważniejsze - mamy tutaj duże pole do popisu i wyniki będą się poprawiały wraz z ulepszaniem naszego narzędzia, co nie jest łatwe a czasem nawet możliwe w rozwiązaniach takich ja Houdini, czy XSI). Innymi ciekawymi cechami jest to, że możesz używając naszych node'ów opisywać programy wykonywalne - czyli takie "exeki", które możesz potem komuś dać i które nie wymagają Flowboxa do uruchomienia i działania. Dla mnie natomiast najważniejszą cechą jest to, że ze względu na tą architekturę Luny, możliwe jest przetwarzananie 2D, 3D, dźwięku, analiza obrazu i tak na prawdę, sam możesz zdecydować jakie jeszcze dane będziesz przetwarzał w wizualny (lub tekstowy) sposób. My obecnie koncentrujemy się nad działką 2D (czytaj kompozycją i przetwarzaniem obrazu) Reasumując Mam nadzieję, że odpowiedziałem Ci na pytanie, przedstawiając zarys tego jak to działa od środka. Jeżeli masz dalsze pytania, z chęcią na nie odpowiem. Każdemu, kto zastanawia się nad tym jak nasz projet działa pod maską i jakie korzyści niesie, polecam zapoznanie się z wątkiem na cgsociety. Opisałem tam również, czemu idea kompilowania node'ów do czegoś takiego jak C++ jest po prostu zła (jak to dla przykładu robi VEX) :) : http://forums.cgsociety.org/showthread.php?f=59&t=1132960&page=1&pp=15 Jeżeli macie dalsze pytania, z chęcią na nie odpowiem! :)

@smiler: Na naszej stronie - jest podana na samym początku newsa :) @Monio: Bardzo nas to cieszy :) Chyba właśnie dlatego cały nasz team zrezygnował z pracy zawodowej i zajął się tym projektem. Cieszy nas wizja platformy proceduralnej, która pozwala na przetwarzanie dowolnych danych (2D, 3D, dźwięku, symulacji etc) w bardzo wygodny i wydajny sposób. Rozumiem, że o takich systemach mówisz? :) @Idlero: Dziękujemy :)

@manabanana: Oczywiście na samym CPU też można pracować. Mamy obecnie wsparcie dla automatycznego rozpraszania na wiele CPU, ale nie wiem czy będzie to dostępne w Alphie. Jeżeli nie, to na pewno niedługo po jej wypuszczeniu :) @deshu: Dzięki! Czekaj na powrót kosmonauty :D

@Kramon: Flowbox FX jest skupiony na przetwarzaniu i kompozycji obrazu, a więc jest zdecydowanie bardziej 2D. Nie zmienia to jednak faktu, że przetwarzanie grafiki 2D jest przykładową funkcjonalnością, jaką można zbudować na Flowboxie. Nic nie broni Ciebie przed stworzeniem bloczków przetwarzających obiekty 3D, dźwięk, czy obliczających symulacje :) Jako pierwszy "use case" wybraliśmy właśnie grafikę 2D. Mam nadzieję, że ogólna idea jest teraz jaśniejsza? :) @deshu: Zapraszam Cię na naszą stronę internetową: www.flowbox.io - tam możesz zapisać się do wersji alpha :) Btw - nie chcemy być tylko tańszą alternatywą Nuka - chcemy dostarczyć narzędzie, które pozwoli Tobie na szybszą pracę, którą będziesz mógł lepiej dostosować do swoich potrzeb. Mówię tu zarówno o technicznych jak i nietechnicznych aspektach pracy. Dla przykładu - nasz kompilator analizuje przepływ stworzony przez Ciebie, optymalizuje go i kompiluje, przez co nawet bardzo duże sceny składające się z tysięcy nodów powinny działać szybko, niczym pisane w C++. Mówię tu również o automatycznym zrównoleglaniu przepływu pomiędzy istniejące CPU i GPU czy też możliwości rozszerzania samej platformy (o własne narzędzia) przy użyciu nodów - bez potrzeby pisania pluginów w C++ lub innym niskopoziomowym, podatnym na błędy języku.

Cześć :) Jestem jedną z osób, która poczyniła Flowboxa :) Jeżeli macie pytania, z ochotą na nie odpowiem :) @Mortom: Bardzo dziękujemy za uwagę. Obecnie jesteśmy pochłonięci dopieszczaniem wersji alpha, ale w niedalekiej przyszłości zamierzamy zamieścić więcej informacji na stronie :) pozdrawiam, Wojtek

Przykro mi, ale jesteś skazany na porażkę. Kobiet nie da się zrozumieć ;)

Tylko ma zależności z dupy ... Jak już robią porzadny soft to nie mogą poświęcić jeszcze dodatkowej godziny na zrobienie pakietu .deb lub chociaż .rpm z opisem zależności aby nie robić sobie bałaganu w systemie? :/

zombie wymiata w wersji polskiej :D

-> google -.-

Hej ho, ho hej! Chciałbym Wam zaprezentować rezultaty mojej pracy nad pewnym zagadnieniem związanym z grafiką komputerową. Na samym początku postaram się zarysować do czego ta technologia może być wykorzystana. Zagadnienie dosyć mocno zahacza o L-Systemy. L-Systemy swoją nazwę zawdzięczają węgierskiemu biologowi Aristidowi Lindenmayerowi, który w 1968 roku opracował specyfikację tego języka formalnego. Miał on z założenia służyć do opisu prostych struktur wielokomórkowych i ich podziałów. Okazało się jednak, że nadaje się doskonale do opisu figur fraktalnych (których mniejsze części podobne są do kształtu całej figury), roślin i całych systemów biologicznych. Język L-systemów ewoluował przez lata i obecnie stanowi najdoskonalsze znane narzędzie pozwalające na tworzenie cyfrowych roślin, systemów biologicznych i fraktali. W matematyce mówi się, że L-Systemy są językiem pozwalającym na generowanie słów i zdań nad pewnym językiem, czyli po prostu potrafią wygenerować ciąg dowolnych znaków na podstawie zadanych reguł. Następnie znaki te interpretowane są graficznie (np. F interpretowane jest jako kreska, + jako zgięcie itp). L-Systemy wykorzystuje się przy tworzeniu cyfrowych roślin i efektów specjalnych, np. w Avatarze większość roślin generowana była przy pomocy L-Systemów, stworzenie własnych kształtów błyskawic modelu płuc, mózgu, sieci neuronów, ... w L-Systemach jest bajecznie proste. Dodatkowo dają one niesamowitą proceduralną kontrolę nad praktycznie ka żdym aspektem generowanej geometrii, więc można bardzo łatwo zrobić np. animację rosnącego pnącza, albo przygotować jedno drzewo i na jego podstawie wygenerować setki innych, przy czym każde będzie różniło się od pozostałych. L-Systemy wykorzystywane są również jako baza dla wielu pluginów, takich jak X-frog oraz Tree-generator, przy czym same dają o wiele większą kontrole, niż w tych pluginach. Więcej o L-Systemach można przeczytać w darmowej książce "The Algorithmic Beauty of Plants", w internecie, albo posłuchać jak o nich opowiadałem podczas cyklu szkoleń pierwszego Artbuzza (wiedo jest na youtubie). ------------------------------------------- Przechodząc do sedna sprawy, rok temu napisałem pracę inżynierską pod tytułem: "Lex Systemy - opracowanie wysokopoziomowego języka przetwarzającego znaki." Planowałem, że rezultaty zapostuję tutaj po kilku miesiącach od zakończenia pracy, aby mieć czas na postawienie jakiegoś bloga lub własnej strony. Rzeczywistość jednak okazała się okrutna i przez ilość pracy zawodowej oraz czasu wkładanego w projekty które prowadzę, nie znalazłem do teraz chwili na zajęcie się tą stroną i pewnie nieprędko znajdę ;) Tak więc rezultaty, które tu pokazuję mają rok, ale i tak robią dobre wrażenie, tak mi się przynajmniej wydaje :) Formalnie mówiąc, Lex Systemy są wyspecjalizowanym, wysokopoziomowym językiem przeznaczonym do przetwarzania znaków i definiowania reguł proceduralnej generacji słów nad pewnym językiem. Pozwalają one na generowanie słów dowolnego języka należącego do gramatyk klasy wyższej lub równej 1 w hierarchii Chomsky'ego. Mówiąc po ludzku - Lex Systemy pozwalają na wydajne przetwarzanie znaków, a co za tym idzie, pozwalają między innymi na generowanie L-Systemów. Obecnie na rynku istnieje kilka komercyjnych rozwiązań pozwalających na tworzenie L-Systemów (w tym jeden z najlepszych generatorów dostępny jest w pakiecie Sidefx Houdini i dlatego też z nim porównuję w dalszej części swoje rozwiązanie). Warto zauważyć, że Lex Systemy pozwalają na generowanie L-Systemów niezależnie od aplikacji! Pozwalają również na wiele innych rzeczy, nawet na pisanie złożonych algorytmów i tworzenie samodzielnych aplikacji. Jedną z najważniejszych cech Lex Systemów jest ich składnia. Przez długi czas projektowałem ten język tak, aby był prosty w użyciu, przejrzysty a zarazem bardzo funkcjonalny. W rezultacie otrzymałem język pozwalający na opis złożonych systemów (również L-Systemów) w sposób przejrzystszy i dający więcej możliwości niż wszystkie znane mi generatory L-Systemów, w tym ten wbudowany w Houdiniego. Szczególną uwagę położyłem na wyeliminowanie wszystkich niedogodności i błędów w architekturach znanych języków L-Systemów (więcej w tym temacie opowiadałem podczas moich wykładów na pierwszym ArtBuzzie, VideoDay, etc. - ze względu na to, że nie chcę tutaj się rozpisywać, jeżeli będzie taka potrzeba, zagłębię się w ten temat). Ponadto wszystkie opisy L-Systemów można łatwo przenosić do Lex Systemów. Pozwolę sobie na wtrącenie jednej technicznej uwagi - Lex Systemy pozwalają na tworzenie L-Systemów klasy szerszej niż tylko pospolite L-Systemy kontekstowe. Pozwalają one na to, by kontekst w L-Systemach był wieloznakowy, a nawet aby był on wyrażeniem regularnym! Napisałem również w C wydajny kompilator tego języka. Po przeprowadzeniu testów okazało się, że jest on ... NAPRAWDĘ wydajny :D Jest dużo szybszy niż generatory L-Systemów w Houdinim (pomiędzy testowanymi wersjami 9, 10, 11, 12 i 12.1 nie odnotowano większych różnic). Wynikowy program działał z dużo niższą obliczeniową złożonością, niż ten w Houdinim :) Testy były przeprowadzane wielokrotnie na nieobciążonej maszynie. Polegały one na obliczaniu pewnej generacji przez mój program i zapisywaniu wyniku na dysku. Analogiczne testy przeprowadziłem w Houdinim (używając Houdiniego w trybie batch (bez interfejsu graficznego) oraz Houdiniego Master (teraz FX) nie wyświetlając w viewporcie rezultatów, a jedynie każąc nodom na obliczenie się). Wiele ludzi, w tym mój recenzent, promotor, doktorzy i koledzy miło zaskoczeni moimi rezultatami sprawdzili wraz ze mną, czy wyniki naprawdę są ok. Testowaliśmy czy wynikowa geometria jest taka sama w obu przypadkach. Była :) Ok a teraz kilka faktów: Testy czasowe były przeprowadzone na stacji roboczej Dell Precision T7400 (2*3.2 GHz Xeon, 64 Gb RAM) i wynosiły: Warto zauważyć, że obliczenie generacji 22 zajęło Houdiniemu ponad godzinę, w momencie gdy Lex-Systemy obliczyły ją w zaledwie 7 sekund. inny przykład: Tutaj różnica jest jeszcze większa! ------------------------------------------- Dodatkowo napisałem 2 narzędzia - konwerter L-Systemy -> Lex-Systemy (zajmujący mniej niż 100 linijek w Pythonie, bo jak już wspomniałem, dla reguł L-Systemów języki te posiadają podobną składnię) oraz plugin do Houdiniego pozwalający na generowanie L-Systemów przy pomocy reguł standardowych oraz tych w Lex-Systemach. Wszystkie moje poprzednie prace na L-Systemach działały z nowym pluginem i pozwalały na odtwarzanie płynnie animacji parametrów L-Systemów, przy czym z oryginalnym generatorem L-Systemów z Houdiniego otrzymywałem 2-3 FPS :) Ze względu na pewne obostrzenia na uczelni, nie mogę udostępnić mojej pracy inżynierskiej, ale postaram się jakoś to załatwić - tu znowu pojawia się ból z czasem, więc jak na razie, aby nie czekać kolejnego roku, publikuję wyniki. Możliwe jednak, że dostanę pozwolenie na opublikowanie działającego programu za darmo, ale tego nie mogę obiecać. Zostałem poproszony o napisanie pracy naukowej na ten temat, więc jeżeli znajdę na to czas i ją napiszę, na pewno ją zapostuję. Na chwilę obecną, jeżeli ktoś posiada jakieś pytania lub uwagi będę szczęsliwy na nie odpowiedzieć! :D