Skoti

No pewnie, że nikt profesjonalny tak nie robi (podałem tą możliwość, bo tu o profesjonaliźmie nie ma mowy) - profesjonaliści po prostu kupili by tą tania licencje i dołączyli zamkniętą binarkę do silnika. Możliwe, że Lua znali najlepiej (jednak skoro tak to powinni sobie zdawać sprawę z jego wad i nawet nie myśleć o nim), z CPythonem podobnie jak z innymi znanymi mi implementacjami (poza cpythonem mam doświadczenie z jak i z BoostPython) mają kiepskie api wymagające dużo zachodu do prostych rzeczy. GDScript jest "wystarczający" - powiedziałbym nawet, że każdy z tych języków jest wystarczający, ale tu nie o wystarczaniu, a o wygodzie i wydajności (mówię o wydajności pracy ofc, a nie o szybkości działania, bo tu to dokonywali wyborów wręcz tragicznych, ale to jest mało znaczące). PS. C# zdecydowanie nie jest przezemnie ukochany, a nawet w mojej czołówce, ale to dobry język (znacznie lepszy niż reszta, którą próbowali), jednak chciałem się czegoś dowiedzieć... to ile lat oni ten silnik tworzyli? Czyżby ponad 13 lat (.NET 1.0 z C# wydany został 13 lat temu).

@Monio: Moje zdanie jest takie, że Metal umrze podobnie jak Mantle śmiercią naturalną zaraz po wyjściu OpenGL Next, bo stracą całkowicie sens istnienia (no chyba, że zawarzą względy marketingowe, typu oni mają standard ogólny, a my mamy super hiper własny). PowerVR nie miał żadnych problemów ze swoją kompresją tekstur PVRTC, a to Apple miało. Wszystkie gry i aplikacje wykorzystujące GLES2 wykorzystują PVRTC, więc nie mogą wybrać innych GPU (bo wszystko by przestało działać) - Apple promując PVRTC sprawiło, że jest zmuszone do produktów PowerVR. Apple jednak miałoby problem z tlumaczeniem fanom dlaczego ich produkt nie dostarcza najfajniejszych możliwości które ma konkurencja jak przykładowo Google z Android Extension Pack czyli: - Teselacja, - SSBO obsługiwane przez shadery fragmentów, - Draw Indirect (sztoda, że nie multi draw indirect, bo by rządził ;p). - ASTC najlepsza istniejąca kompresja tekstur, - większe możliwości przy MRT. To czego nie potrafią PowerVR potrafią Tegra K1, Adreno 4xx, Mali 800 pod Androidem. Produkty Apple z GPU bez tych możliwości, które są na Androidzie wyglądały by blado i świetnie tu rolę zasłony dymnej robi Metal - fajne API, jednak o słabych możliwościach. Niestety nie mam dostępu do Khronos. Informację zbieram od znajomych pracujących zarówno dla producentów sprzetu, jak i silników gier, którzy mają wgląd w Khronos. Ale także z tweetów twórców narzędzi dla OpenGL (przykładowo miesiąc temu jeden z takich, którzy mają wgląd do prac w Khronos, pisał, że wersja OpenGL Next jego narzędzia jest gotowa, ale z wydaniem czeka na oficjalną prezentacje standardu, więc wcale bym się nie zdziwił gdyby przynajmniej wersja prowizoryczna była wydana już w okolicach GDC).

GLES 2 to jest prehistoria (aby pokazać jaka, powiem tylko, że nie obsługuje nawet MRT - które jest w OpenGL 2 i Dx9). Jeśli celują w rynek mobilny, to powinni wspierać Metal (API na nowe iOSy), i GLES3.1 z AEP na Androida - przecież jeśli ktoś będzie chciał użyć tego silnika to zanim stworzy grę to GLES2 na połowie sprzętu może być już nawet nie obsługiwane... ba mogą nawet pełny OpenGL (Tegra K1 i Android) wspierać ze wszystkimi dobrodziejstwami nowoczesnego API. OpenGL Next rozwija się bardzo dynamicznie i bliżej to kwestia roku (już ze sterownikami, które w przeciwieństwie do OpenGL będą łatwe do napisania). Ofc obecnie OpenGL powinien spełnić pełnię potrzeb, a już szczególnie z nowinkami z początku miesiąca - nic wydajniej w nowym OpenGL nie będzie, a jedynie będzie czystym api bez kompatybilności wstecznej i z IR, przez co sterowniki nie będą potrzebowały kompilatorów. Skoro podałeś już wpis na blogu Grahama Sellers o AZDO (Graham Selers z AMD to jedna z 2ch osób pracujących nad API OpenGL Next (drugą jest Jeff Bolz z Nvidii - ofc nad całością OpenGL Next pracują inni jak Bill Licea-Kane z Qualcomm, który pracuje nad językiem shaderów i IR, oraz Tom Olson, który zarządza pracami) i autor najciekawszych nowinek w API graficznych od lat) to dodam jeszcze linki do prezentacji o których pisze (slajdy z konta pracownika Nvidii Cassa Everitta, bo to w sumie były prezentacje prowadzone przez Nvidię, ale brali w nich udział też pracownicy AMD/Intel)

Jasne, że LGPL pozwala na zrobienie zamkniętej aplikacji mobilnej (zarówno w iOS jak i Android). Problemem jedynie jest to, że to systemy w które użytkownik nie bardzo może ingerować więc trzeba zrobić sztuczkę i możliwość podmienienia libki (wystarczy dać możliwość wczytania własnego libmono.so przykładowo z karty pamięci - w credits na koncu wystarczy umieścić info w jakim katalogu taki plik ma być) i licencja jest spełniona (LGPL nie zabrania nawet linkowania statycznego, a jedynie nakazuje umożliwić użytkownikowi zmienić na własną wersję kod tej libki). Ofc nie każdy chce się bawić, a licencja Xamarin nie jest aż tak droga, aby jej nie kupić (kupić musi jedynie producent silnika i może reszcie udostępniać ten zamknięty libek jako część produktu silnika). Czyli jeszcze wiele lat nie planują C# ;p. Ofc C# przy tych językach które próbowali to niebo, a ziemia. AngelScript jest nie tyle ulubieńcem, co jest jest najfajniejszy z języków skryptowych niezależnych od silnika. Ale nie mam nic przeciwko UnrealScript, językowi z idTechów (teraz zwany super-script czyli podzbiór C++), C# (przykładowo Unity)... uważam te wybory za znacznie lepsze niż języki jak Lua (CryEngine) czy Squirrel (Valve Source). Nie dziwie się, że nikt nie marudził, bo AngelScript to język nie tak popularny (mało kto go zna) jak powyższe w zadaniach do wszystkiego (a jak wiadomo co do wszystkiego to...), a jest specyficznie tworzony przez programistę gier dla programistów gier (jak języki w Unreal Engine czy idTech) - praktycznie jedynym programem (nie grą), który możesz znać jest 3d-Coat. Z tego co czytałem to używali Lua na samym początku, później przeskoczyli na Pythona, Squirrel i dopiero stworzyli GDScript, a teraz mówisz, że zastanawiają się nad C# (słusznie ;p) - skaczą po językach nie bardzo chyba wiedząc czego chcą, zamiast usiąść na początku przedyskutować sprawę, to jakie są dostępne opcje i jeśli nie ma satysfakcjonującej zrobić własny spełniający oczekiwania (a tak robią wiele razy tą samą robotę). https://github.com/okamstudio/godot/wiki/gdscript Co do opinii to będzie ciężko, bo nie znam tego silnika. Jednak z tego co widzę to ułamek możliwości Unity, a dodatkowo kiepskie wybory jak języki skryptowe odstraszają. PS. Co do tego co piszesz później, że "Unity nie potrafi 2D" czy że się nie wybija (coraz bardziej zaczyna i o ile to kilka lat temu był po prostu tani silnik, tak teraz jest to już ścisła czołówka technologiczna) to po prostu bzdury.

Nie w pythonie (w innym przypadku powiedziałbym na szczęście, ale tu nie jestem przekonany). Twórcy silnika próbowali Lua, Python i Squirrel, ale żaden im nie podpasował i stworzyli własny język GDScript (który jako język odziedziczył wady powyższych, ale łatwo im się podpina pod silnik).

Teraz działa, ale kilka miesięcy nie czytało feedów (tylko z max3d) ani na czytniku w telefonie, ani na desktopie. Open Movie to termin mocno związany z Blenderem i tylko z ich projektami (to jest nazwa marketingowa wymyślona na potrzeby ich produkcji tak jak Retina dla Apple). Monkaa jest z gatunku open-content films (który jest starszy niż nazwa marketingowa Open Movie), ale Open Movie nie jest. Tak, ale NIE projekt tego shorta jest promowany, a tutoriale i to jako materiał do ucznia się. A jest różnica, bo promowanie tego jako tutoriala dla początkujących jest ok. Promowanie tego jako shorta nie ma miejsca. Takich produkcji mających na celu naukę było wiele. Część z nich jest tu: http://www.blender3d.org/e-shop/default_dvds.php Jednak nie mają nic wspólnego z Open Movie.

Miałem mniej czasu wolnego, a że RSS na max3d nie działał to nawet nie wpadałem na szybko, bo temat mnie zainteresował w czytniku newsów ;p.

@Adek: warto poprawić newsa, bo nie jest to Open Movie, nie jest finansowany przez fundację blendera, a jest to animacja robiona przez 3 osoby i podpieli się pod chmurę blendera, bo chcą tam zarobić tam na płytce treningowej z tą animacją. Fundacja i instytut blendera zajmuje się faktycznie kolejnym Open Movie... jednak jest to projekt Gooseberry (http://gooseberry.blender.org/) i z Monkaa nie ma nic wspólnego.

Może chodzić o inne shadery na twarzy (jak shadery oczu), a może nawet przy współpracy z Nvidią wykorzystali FaceWorks do dynamicznej animacji mimiki twarzy na podstawie danych z USC. Nie wiem czy tak było, ale jest ogólnie wiele rzeczy, które mogły się przyczynić do napisania osobno i twarzy i skóry.

Zależy jak to rozumiesz. Model, ustawienia shadera to robota grafika... jednak to jak ten shader działa, jaki zaimplementowany jest SSS itp... i jak te ustawienia grafika wpływają na wygląd materiału to już zasługa programistów silnika.

Z Colladą niestety nie jest lepiej mimo, że jest dobra dokumentacja - ten format jest tak uniwersalny (na dodatek dowolnie rozszerzalny), że wspieranie go dobrze w import/export graniczy z cudem. W wypadku Collady też są problemy z eksportem z blendera... a to jeden z najlepszych eksporterów (Autodesk ze swoim eksporterem Collada, który przechodzi wcześniej przez eksporter FBX jest gorszy niż eksporter FBX blendera (pliki są zupełnie niezgodne ze standardem)). Co do licencji FBX to nie do końca jest tak, że nie można używać kodu w otwartym oprogramowaniu bo można. Problemem jest to, że twórca programu musi wymagać od każdego użytkownika rejestracji na stronie autodesku (i jeśli ktoś się nie zarejestruje to twórca programu łamie licencje)... czytaj jest równie nieprzyjemna dla zamkniętych i otwartych programów. Ogólnie autodesk wspiera dobrze tylko Autodesk FBX (Collada i inne u nich to żałosne implementacje nie mające ze standardami nic wspólnego), bo to ich format i zrobili wszystko, aby konkurencja sama musiała pisać swoje wsparcie, które bez dokumentacji (ba nawet jeśli by była to nieistotne by było implementowanie według dokumentacji, bo inne implementację muszą naśladować nawet błędy w implementacji autodesku, aby uznawane były za dobre implementacje) jest bardzo trudne.

Soft świetny jest nie dzięki studencikom, a opłacanym programistom z core team, a szkoda, że przez licencje są to jedyni profesjonaliści na jakich blender może liczyć.

Ci którzy inwestowali tam w nadmuchane baloniki raczej teraz są pod mostem - dobrze żyje się tylko tym pompującym baloniki. @ikkiz: od czasu tamtych postów dużo rozmawiałem z core team i w brew zapowiedziom, eye candy o których mówiono dalej nie wyszły, a mocno pracowano nad podstawami (ba nawet zaczęto ponownie myśleć o przepisaniu podstawowych algorytmów jak sampling). Cycles przez ten rok przeszedł zupełną metamorfozę podejścia. Bardzo wątpię by Reanimator zastanawiał się przez viewport czy warto uczyć się blendera. Blender to świetny program i to, że nie ma szybkich perspektyw na poprawę viewportu tego nie zmiania. Idiotyczne jednak jest słodzenie jaki to jest super i bez wad. Blender ma wady i to w niektórych aspektach spore i nie należy tego przykrywać dobrą miną do złej gry. Jednak podobne wady ma też konkurencja (tylko w innych miejscach) i nie wiem dlaczego ktoś miałby do niej przechodzić. Ja do blendera przechodziłem z 3ds studio lata temu, bo ten miał znacznie więcej wad. Mieszanie blendera z otwartym oprogramowaniem jest trochę błędne. Blender teraz jest na GPL, ale przez pierwsze 7 lat rozwijał się jako zamknięty program (moje pierwsze starcia z nim były jeszcze gdy był to zamknięty projekt) i był już dobrze rozwinięty i sławny (był wykorzystywany w komercyjnych reklamach) zanim był na GPL (dokładniej został od firmy Tona wykupiony przez społeczność). Patrząc jednak poza unikalnego blendera, którego zawdzięczamy wykupieniu programu zamkniętego mamy: - Krita (dużo bardziej liberalna LGPL) vs GIMP (GPL), - OpenOffice (Apache 2 - czyli BSD-like) czy LibreOffice (LGPL + BSD-like dla nowych rzeczy) vs Gnome Office (GPL) - Eclipse (BSD-like) czy NetBeans vs Code::blocks - Firefox (licencja mozilli BSD-like) i Chromium (BSD) vs Konqueror (GPL) i Epiphany (GPL) - Clang z LLVM (BSD-like) vs GCC (GPL) Blender poza samym Linuksem to praktycznie jedyne przykłady udanych GPL... w tym, że Blender to program zamknięty wykupiony, który cierpi od lat przez wybraną licencję, ale alternatyw nie ma więc się rozwija (jak dawno temu GIMP siłą*rozpędu gdy nie miał konkurencji żadnej). Blender ofc teraz ma trochę wolontariuszy, ale w praktyce najwięcej i tak robi kilka osób w core team. Przykro sprawdzają się słowa twórcy silnika Bullet (który współpracuje przy kilku projektach w blenderze), że profesjonalni programiści omijają GPL dalekim łukiem. Już pomijając to, że biblioteki to też finalne produkty sprzedawane komercyjnie (przykładowo masz Havok (zamknięty, komercyjny) vs Bullet (BSD-like)), ale ok, rozwijać mogą to tylko osoby korzystające w swoich produktach, zapominając o konkurencji, to w całej reszcie mylisz się całkowicie. Nie opłaca się odseparowywać projektu i utrzymywać swojej gałęzi długo - to jest bardzo drogie i każda zmiana w kodzie otwartym wymusza na firmie merge i utrzymywanie swojej wersji co jest bezsensowne. Firmy zainteresowane są utrzymywaniem wspólnego kodu w jak najlepszym stanie, a sprzedawać pluginy. Świetnym przykładem jest tu projekt Eclipse. Otwarty kod na literalnej licencji fundacji Eclipse do którego kod mimo masy wolontariuszy piszą Intel, Google, Nvidia, Nokia, Adobe... i praktycznie wszyscy inni wielcy. Mimo, że Eclipse jest sam w sobie produktem pełnym i jest konkurentem dla rozwiązań większości z firm go współtworzących jest też podstawą pod Apache OpenOffice (który dostał kod IBM Symfony oparty o Eclipse), produktów IBM, produktów Adobe (Adobe Flex Builder), komercyjnych produktów RedHata... każda z firm korzysta, nikomu nie opłaca się utrzymywać branchy, każdy wrzuca do wspólnego projektu swój kod i wspólny kod rozwija się wielokrotnie szybciej niż gdyby zamknąć się na firmy i wybrać GPL. Blender jest idealnym przykładem programu, który skorzystałby na liberalnej licencji przynajmniej takiej jak LGPL niesamowicie (do wolontariuszy i core team, dołączyliby programiści pluginów, poważne firmy graficzne z własnymi programistami itp). Bardzo naiwne podejście - liberalne licencje nie pozwalają nikomu jakoś "rozseparować" - tzn każdy może rozwijać oddzielnie, ale utrzymywanie takiego kodu jest drogie, ale kod dalej zostaje w domenie publiczej do wspólnego rozwijania. Ofc Autodesk mógłby zabrać część lub całość i wydać swoją wersję lub dodać do 3dmaxa odpowiedni kod. Ofc niewiele to zmienia, bo jak chce dodać kawałek blendera do swojego programu to nikt im nie zabroni bo kodu nie widać i nie udowodnisz im tego (a jeśli zmienią troszkę ten kod - a muszą przystosować do swojej architektury programu - to nikt się nie pozna nawet jak kod zobaczy). Jednak merge codzienne kodu rozwijanego w ramach blendera byłyby zbyt kosztowne, a stały fork rozszedłby się zupełnie i byłby po 2ch latach zupełnie innym programem (niekoniecznie lepszym). Autodesk jeśli zdecydowałby się na fork blendera prawdopodobnie co kilka miesięcy/rok wrzucałby poprawki do kodu blendera - miałby może nowości swoje o rok wcześniej, ale blender zyskiwałby prace wykonaną przez autodesk (ten co rok dostawałby to co w tym roku otwarty blender dostał, a otwarty blender dostałby to co w danym roku miał Autodesk i nie opłaca się im już utrzymywać osobnej gałęzi). Sytuacja każdy korzysta jest lepsza od Autodesk robi swoje, Blender robi swoje i bez współpracy oba rozwijają się wolniej. Użytkowników otwartej wersji byłoby zapewne podobnie jak teraz albo więcej (ze względu na płatne pluginy powiększające możliwości), ale programistów otwartej wersji byłoby kilkukrotnie więcej (wszyscy obecni + wolontariusze, którzy od GPL uciekają z krzykiem (a wśród programistów jest ich większość) + programiści opłacani przez firmy).

Możesz podać szczegóły bo tego nie pamiętam (lub nie pamiętam kontekstu)? Mówisz o kontekście, że pisanie OSL nie ma wielkiego sensu na dłuższą metę i zostanie zastąpiony gdy tylko OpenCL będzie dobrze zaimplementowany? Jeśli tak, to właśnie z tego co Ton i Brecht mówił zabierają się za wersję OpenCL i przepisują, bo najnowsze sterowniki beta AMD sobie radzą, a nadchodzący SPIR i OpenCL 2 pozwolą wreszcie wywalić OSL i CUDA i zastąpić jednolitym kodem na wszystkie architektury. Co do samego Cycles od strony programistycznej przyczepić się nie bardzo można (odpowiednia liberalna licencja, kod nowoczesny w C++, architektura przemyślana) - Cycles jest akurat w kodzie i licencji przeciwieństwem reszty blendera (GPL + kod w C + architektura wielu rzeczy sięga poczatków blendera (w tym viewportu)). Nie, ale kiedyś do mnie napisał w technicznej sprawie (zdaje się OpenCL), bo ktoś pamiętający mnie z blenderowni mu polecił, że tam nie ma nikogo już kto by miał wiedzę w tym temacie. Blender miał szczęście do GSoC, bo kilka projektów przez te lata było udanych (wielokrotnie więcej nieudanych)... jednak wiele innych projektów uczestniczących w GSoC jeszcze, żadnego kodu GSoC nie przyjeły (bo nie spełniał norm jakościowych). Blender ma to szczecie, że jest efektownym programem, a efektowne projekty są częściej kończone, bo przynoszą masę satysfakcji twórcy. Viewport jest projektem zupełnie innego typu - tu trzeba włożyć masę pracy, by osiągnąć taki efekt jaki był na początku (projekt nie jest na efektowność, a efektywność) - ciężka praca u podstaw bez uwielbienia tłumów (projekty jak dynamic paint mogą być napisane nieefektywnie, powolne, od strony programistycznej słabo, ale są uważane za super bo są efektowne). Rozumiem, że masz jakiekolwiek pluginy w blenderze? Ups nawet nie masz API dla pluginów, bo nie ma to sensu przez licencje. Api masz skryptów, a firmy produkujące pluginy skrypty mają gdzieś, bo te z natury mają otwarty kod, a nie każdy chce się dzielić. Chętnych programistów nie masz. Projekty na licencjach liberalnych mają wielokrotnie więcej chętnych osób i firm do współpracy niż projekty na GPL, dlatego, że wspierając GPL nie dostają nic w zamian (użytkownicy tak, ale nie programiści - ci muszą nawet czasami bać się o swój kod, aby nie zostać za niego pozwani (w ekstremalnych przypadkach)), a wspierając te na liberalnych licencjach. No jasne, że nie - viewport będzie kiedy będzie. Jednak huraoptymizmowi należy przedstawić racjonalność, bo pompowanie balonika oczekiwań z którego nic nie będzie może tylko zaszkodzić, a na pewno nie pomoże.

Ma sens, ale ma niską skuteczność. I nie mówię o blenderze tylko o wszystkich projektach biorących udział. Nie jest to nic dziwnego, a taka jest formuła - studenci bez żadnego doświadczenia i z mierną wiedzą biorą się za projekty, które ich przerastają, ale nawet jeśli 1/20 tylko podoła to już warto. W GSoC nie może brać udziału zawodowiec w wolnym czasie, a muszą studenci amatorzy (taki wymóg od google) i głównym celem GSoC nie jest poprawa oprogramowania open source, a aktywizacja studentów, aby to oni się przy projekcie nauczyli czegoś, a nie tyle dokonali czegoś dla projektu i wykrycie tego ułamka, który jest wart zatrudnienia w Google. Na viewport nie da się nie narzekać tym bardziej, jeśli masz wiedzę jak powinno być a jak jest. Blendera używam, bo poza viewportem jest to świetny soft. Widoki na przyszłość są, ale nie należy ich upatrywać w Wilkinsie, a mniej napiętych czasach dla core team (gorsze niż viewport do dupy, byłoby przecież pozostawienie dla niego rozwoju Cycles przez Brechta). Przez nią nie masz pluginów w blenderze (bo licencja zabrania linkowania do zamkniętego softu, więc o zamkniętych pluginach zapomnij), i programiści niechętnie chcą pomagać (gdyby licencja była BSD-like to inna sprawa - tu programiści i całe firmy przychodzą z masą kodu bez obaw).

Tak teraz też niby jest. Niby, bo jest tylko podstawa i nic więcej. Zrozumiałem, jednak po prostu wiem, że tak jest i teraz, a jaki jest kraniec możliwości każdy wie. OpenGL ma 2x profile - profil kompatybilności i profil rdzenny. Profil kompatybilności pozwala Ci mieszać naprawdę archaiczny kod z najnowszym. Nic nie stoi na przeszkodzie wykryć czy karta obsługuje tessellację czy transform feedback i obsłużyć... tylko to, że nikt tego nie zrobił To, żaden myk, ani idea. Nie będzie też w niczym łatwiej niż teraz dodać funkcje z OGLa 4, bo dla OpenGL jest naturalne. Nie ma sensu tego stopować. Nie ma nikogo kto by się tym kodem zaopiekował, więc niech próbuje - może nie wszystko pójdzie do kosza. Chociaż w programie graficznym 3D nie wyobrażam sobie sensowności bawienia się z dziwnymi implementacjami pickingu (dosyć podstawowej rzeczy - bo algorytmu, który decyduje co zaznaczyć w viewporcie), zamiast naturalnie użyć occlusion queries (to dopiero od OpenGL ES 3.0). Ograniczanie się do OpenGL ES 2.0 to tak trochę jak uwiązywanie się do kompatybilności z OpenGL 2.0 (ten w wielu aspektach daje większe możliwości niż ES2 (to bardziej poziom obciętego mocno OpenGL 1.5-2.0 (w tym obciętego z elementów ważnych dla wydajności jak MRT) z elementami 3.x niemającymi jednak znaczenia dla wydajności)), ale może się pozbędzie z kodu części fixed pipeline (dobrze, że wyleci, ale z punktu widzenia wydajności nie ma to, żadnego znaczenia, bo mało co ograniczało (no może fixed pipeline double sided lighting), a w wykorzystywaniu nowoczesnych API nie przeszkadza zupełnie). Z kilkoma członkami core team mailuję i oni dobrze znają sytuację z viewportem (podobnie jak wiedzą jakim ciężarem jest licencja blendera dla projektu). Viewport kiedyś ruszy (ja obstawiam, że wtedy kiedy Brecht będzie mógł odstawić Cycles i będzie miał czas na viewport), ale nie za sprawą GSoC. Niestety - marnujących GSoC jest pod dostatkiem i nie mam pojęcia co radziłbyś zamiast (mało który z tych projektów ma sens - GSoC działa w środowisku otwartego oprogramowania tak, że Google płaci, to niech studenciaki coś robią, a może jeden na 10 projektów przyniesie jakikolwiek efekt). @Azbesty/Kramon: Ja rozumiem, że cię wkurza to, że rozwiewam wątpliwości marzących o szybkim viewporcie, ale takie są fakty. Jak jednak tu mówiłem już nie mam zamiaru wspierać blendera kodem, ze względu na to, że ma wirusologiczną licencję która dla programistów moim zdaniem jest mocno krzywdząca.

@up: jeśli dobrze pamiętam to za każdym razem wynikiem miał być nowoczesny, wydajny viewport, a nie zrobiono nic (nawet aby przygotować pod taki... może dlatego, że bmesh od początku jest pod taki przygotowany i wystarczy go napisać). Nie wiem o jaki mail na liście dyskusyjnej mówisz, ale jeśli o ten, że jego zdaniem trzeba wywalić wszystko co zostało wyrzucone z OpenGL wraz z 3.x to się zgadzam (powinno to być zrobione jakieś 5 lat temu), ale co do jego zdania na temat tego, że nowy viewport powinien się ograniczać do tego co ma OpenGL ES 2 - co oznacza dokładnie tyle co: - brak sprzętowego instancingu (OpenGL 3.1 i OpenGL ES 3), - brak tesselacji (OpenGL 4.0 i w OpenGL ES jeszcze nie ma wsparcia), - brak renderowania pośredniego (OpenGL 4.0 (multidraw w 4.3) i OpenGL ES 3.1), - brak shaderów obliczeniowych (4.1 i 3.1), - brak transform feedback (3.0 w GL i 3.0 w GLES), ofc nie mówię o bardzo skromnych możliwościach tekstur itp. Ten nowy "viewport" będzie oznaczał rysowanie przez VBO (niczego nowszego w dostarczaniu siatki nie obsługuje), 1x rendertarget (MRT dostępne są dopiero od GLES 3) i działanie blendera na moim telefonie z 2009 roku (pomijam ofc to, że od roku mam telefon, obsługujący OpenGL ES 3, a do wydania tego viewportu prawdopodobnie i ten będzie stary, bo już jest 3.1 potrafiący dużo więcej). Już samo założenie ograniczania się do OpenGL ES 2 (który już nawet na telefonach w nowym oprogramowaniu nie żyje) pokazuje jak nowocześnie będzie (jest ofc możliwość wykorzystania rozszerzeń, aby przez kolejne 5 lat robić to samo w GSoC, ale teraz tez można było i nic z tego nie wynika, że można jak nie ma kto). Ogólnie czytając od czasu do czasu jego posty zastanawiam się kiedy ktoś mu przerwie, zanim blender, będzie działał kilka razy wolniej (bo to, że chce wymienić picking którego już w OpenGL nie ma od lat, to ok, ale można to zrobić tak źle, że będziemy żałować tego, że wywalono stary ;p).

Zaskoczyło, że wspomniał o tym. Nie coś tam grzebią, a grzebie studencik, i nie legenda bo kod jest dostępny... tylko szkoda go komentować, bo ten kod jest żałosny i dosłownie nie przynosi żadnych poprawek. Jason Wilkins w 2012 i w 2013 brał udział w GSoC i nie zrobił dosłownie nic. 2 lata pracy, a efekt w postaci http://git.blender.org/gitweb/gitweb.cgi/blender.git/shortlog/refs/heads/soc-2013-viewport_fx to poziom taki jaki był (co zresztą zapewne wiesz, bo 2 lata pracy są obecnie w blenderze (głównej gałęzi) od miesiąca i raczej poprawy nie widzisz). Wilkins chce i w 2014 roku w GSoC być, ale na efekty nie licz, bo chyba bardziej tu się liczy wpis do życiorysu niż zrobienie czegokolwiek.

Nie tyle zniknie (zniknie marka, ale nie bank) co zmieni nazwę (Alior i T-Mobile mają stworzyć nową markę, ale konta i bank pozostanie). Ja mam konto w Alior bank i sync (firmowe i prywatne), a informacja o współpracy z T-Mobile odnogi wirtualnej mnie nie zaniepokoił (zobaczymy jak będzie dalej, ale rzecznik Alior Banku zapowiada, że nic na gorsze zmienić się nie powinno).

[ot]Jakie masz to angielskie konto? Ja mam w Lloyds i HSBC - tam wszystko trwa wieki (poza przelewami w ramach tego samego banku) - tydzień księgują, jak zablokujesz (prześlesz kasę na konto oszczędnościowe) to trwa kilka dni, aż prześlą (i rachunek się wyczyści z obciążeń (bez możliwości cofnięcia, jeśli zrobiłeś to przez przypadek...)). Słyszałem wcześniej o tym, że w bankowości anglia jest zacofana i że anglicy wolą pisać czeki i iść do banku (oraz czekać tydzień na realizację) niż przelewać... dopiero od kilku lat od kiedy mam konto w UK wiem dlaczego, więc jeśli masz info o lepszym banku to skorzystam i jak polecę odwiedzić wyspę to zmienię ;p. Co do polskich banków to polecam Aliora (niezależnie czy bank czy sync), bo najlepiej z polskich banków mi odpowiadają (księgowanie praktycznie od razu po sesji elixir (chyba, że ktoś przesyła natychmiastowy to w kilka sekund zaksięgowane z innego banku), przelewy natychmiastowe (coś o czym mój bank w UK nawet nie słyszał)). Jeśli masz konto w polsce w przykładowo PKO to w sumie się nie dziwie dlaczego tak źle oceniasz (oni faktycznie działają tak jak znane mi banki w UK, czyli jakby zatrzymały się w poprzednim wieku)[/ot]

Potrzebna jest teselacja + transform feedback (o tym mówiłem wcześniej ;p). GL_ARB_tessellation_shader (ten z OpenGL 4.x http://www.opengl.org/registry/specs/ARB/tessellation_shader.txt) ma minimalne wymagania od kontekstu OpenGL 3.2 i GLSL 1.5 (czyli ten powiązany z OpenGL 3.2), ale jak testowałem kilka lat temu swoje tesselatory to niektóre sterowniki ujawniały rozszerzenie od kontekstu 3.3 (jak robiłem kontekst 3.2 sterowniki mówiły, że nie obsługują ;p). W wypadku teselacji i tak kod na CPU powinien zostać (aby liczyć softowo, jeśli GPU nie potrafi na zasadzie na jakiej było VA lub VBO w zależności od karty).

Wersje OpenGL 3.0 i 3.1 powstały w przeciągu pół*roku i nie znam GPU zgodnego z OpenGL 3.0 a niezgodnego z OpenGL 3.1 (sprzętowo powinny być zgodne z 3.3, ale przykładowo Intel nie ma zaktualizowanych sterowników do SandyBridge). OpenGL daje w 3.1 dużo więcej możliwości i nowocześniejsze narzędzia (przykładowo TBO, UBO, sprzętowy instancing), ale to o czym mówię to rozszerzenie. Czyli podstawa 3.1 jako minimum (chociaż 3.3 byłoby lepsze, bo wtedy jako rozszerzenie jest teselacja, która w wielu miejscach by się przydała i inne rzeczy ;p) i jeśli jest rozszerzenie zamiast instancingu, multidraw indirect (tak jak jest to obecnie z VBO - jesli nie ma to renderowanie VA, a jeśli jest to VBO). Zgadza się, ale nikt kto potrafi to zrobić dobrze, raczej się nie będzie brał do kodu. Pomijając to, że powinni kogoś zatrudnić do zrobienia tego, to byłaby to poważna operacja i prawdopodobnie bez zmian w bmeshu i ogólnie strukturach przechowywania danych w blenderze (które do wymagań GPU nie są zupełnie dostosowane), będzie ciężko cokolwiek dobrze tu zrobić (przez to dalej nikt z core temu się tym zająć nie będzie chciał, bo na odpierdziel robić może student, a na poważnie to jest za duże zadanie (w końcu viewport to jedna z najważniejszych rzeczy w programie)).

W blenderze 2.7x ma być porzucona wsteczna kompatybilność ze starszymi wersjami OpenGL niż 2.1, co nie znaczy jeszcze, że zostanie przepisany viewport (można po prostu wyrzucić kod wsparcia dla starszych który jest na wypadek, jeśli jakiegoś rozszerzenia by nie było). Ogólnie w 2.1 nic więcej niż obecnie jest nie osiągną. W 2.8 możliwe (ze znakiem zapytania), że zajmą się viewportem i zaktualizują renderer do OpenGL 3.0... z tym, że w OpenGL 3.1 niewiele jest rzeczy które mogą sytuacje poprawić (nawet głupiego instancingu jeszcze nie ma, bo ten jest od 3.1). Jedyny plus z OpenGL 3.0 to transform feedback (modyfikacja siatki w shaderach i zapisywanie danych do bufforów, zamiast liczenie na CPU), ale znając rozwój blenderowego viewportu nie ma co marzyć o wykorzystaniu tego. Prawdziwy skok wydajności przyniosłoby GL_ARB_multi_draw_indirect (aby go użyć trzeba minimum OpenGL 3.1 i obsługi rozszerzenia GL_ARB_draw_indirect), jednak w blenderowym viewporcie trzeba poczekać jeszcze chyba dekadę, aż już się tak zestarzeje, ze uznają, że można użyć, bo już od dekady nikt już nie będzie słyszał o kartach na których może nie działać (tak jak teraz ostrzega się, przed zerwaniem ze wsteczną kompatybilnością, bo chcą użyć OpenGL 2.1... którego obsługują karty GeForce FX z 2003 roku). http://code.blender.org/index.php/2013/06/blender-roadmap-2-7-2-8-and-beyond/ Akurat to nic dziwnego - pod Windowsem wspierany jest OpenGL 1.1 (o ile mnie pamięć nie myli) i o wszystko co nowsze musisz się implementacji zapytać czy jest wspierane (implementacja Windowsa pyta się sterownika) i jeśli tak to pobierasz bezpośrednie adresy funkcji w sterowniku od producenta karty. VBO jednak są w OpenGL od wersji 1.5 (2003 rok) standardem, a to, że telefon obsługuje to normalne - prawie każdy obecnie telefon obsługuje OpenGL ES 2.0 (ba nowe obsługują OpenGL ES 3), a tam wymagana jest obsługa VBO (a nawet urządzenia OpenGL ES 1.x miały wsparcie dla VBO).

LuxRender też jest na GPL, przez co blender może dowolnie brać jego kod (bo groźba zarażenia się GPL tu nie występuje - blender już posiada tego wirusa).

Nie wystarczy pozmieniać nazwy zmiennych czy inaczej zrobić wcięcia. Trzeba wyrzucić stary kod i napisać jakby nigdy nie istniał (poza fragmentami na które fundacja blendera ma prawa autorskie (ale tu pewny nie jestem czy przypadkiem ten kod, który był efektem publicznej zbiórki kasy, na rzecz wypuszczenia kodu GPL mogą zmienić, czy wszyscy współwłaściciele (osoby które wpłaciły kasę) muszą się zgodzić)). Ogólnie sytuacja wygląda tak, że aby się pozbyć GPL należało by wyjąć kod Cycles, a resztę pisać od zera.