Skoti

B-mesh jest pisany zgodnie z zaleceniami i wzorcami projektowymi jak 20 lat temu (tak samo jak najstarsze elementy blendera) i nic tu się nie poprawiło. Są jedynie dwa moduły które się wyróżniają olewaniem starego stylu pisania: Game Engine i Cycles (twórca Bullet Erwin Coumans (on rozpoczynał projekt Blender Game Engine w 2000 roku), jak i Brecht van Lommel nie przejmowali się tym jaki blender jest i postanowili zrobić projekty nowocześnie) - cała reszta projektów jest pisana w sposób jaki była by pisana 20 lat temu (w tym bmesh). Co do Erwina Coumansa to żałował on tego, że BGE jest na GPL i przez tą licencje uznał, że nie ma co go rozwijać (i zrobił inny silniczek do prototypowania gier czyli gamekit na licencji BSD), a Brecht napisał Cycles na licencji BSD, a nie GPL (kod Cycles żyje własnym życiem jako osobny projekt na dobrej licencji). Wygląda na to, że jeszcze długo nie będzie GL4... według roadmapy teraz chcą zrobić tylko OpenGL 2.1 jako minimum, znakiem zapytania jest w 2.8x napisanie obsługi GL3 w viewporcie, a GL4 nie jest nawet uwzględniony w Blender 3.0, który ma być przepisywany cały.

Blendera lubię od strony użytkownika, bo tu jest super. Od strony kodu i licencji to jest sieczka. Kod core blendera do przepisania praktycznie od zera z C do C++ jest planowany na 3.0 i może wtedy po refraktoryzacji api będzie się przyjemnie dla blendera pisać. Jednak dalej pozostanie kwestia wirusologicznej licencji. Ta strata czasu już by pozostała - jest ona robiona w czasie rozluźnienia od programowania podczas przeglądu internetowej prasy. Zaangażowanie się w blendera nie wyparłoby tego czasu, ale czas na inne rzeczy. A wiesz, że ostatnio się zastanawiałem czy blenderowi nie zrobić konkurencji. Bo od strony kodu łatwiej byłoby do mojego edytora (modyfikatory już mam typu OpenSubDiv od jakiegoś czasu, czy narzędzia do animacji kości, ale brak edycji siatki) dodać narzędzia modelarskie niż naprawiać blendera, który w 20sto letnim kodzie ma śmietnik ciężki do naprawienia.

Termin implementacja ma znaczenie powszechne. Jednak my w tym konkretnym wypadku mówimy nie tyle nawet o informatyce, a o programowaniu. Implementacja w tym wypadku jako wdrożenie projektu poprzez zaprogramowanie go (implementację zaprojektowanych algorytmów i struktur danych) jest stosunkowo jednoznaczne, a wykorzystanie api gotowej implementacji OpenVDP znacznie mniej do tego sformułowania pasuje. Jednak jeśli już mówisz o naukach prawnych to jest bardzo dobra analogia. Implementacją prawa zajmują się politycy tworząc to prawo. Wykorzystaniem tego prawa już prawnicy odwołując się do tego prawa (API).

Nie deprecjonuję jego pracy, a uważam ją za ważniejszą dla blendera niż marnowanie czasu na projektowanie własnego rozwiązania. Jednak nie zamierzam przekłamywać ile pracy wymaga jedno, a ile drugie (praca Kevina jest ważniejsza, a przy okazji w porównaniu banalnie prosta). Co do reszty to mocno przesadzasz. Nie potrzeba najmniejszego pojęcia. Przykładowo każdy dzieciak potrafi wykorzystać API Bullet i dodać jego obsługę do swojego silniczka, nawet gdy nie ma najmniejszego pojęcia o fizyce i nie potrzebuje tego, ani ogarniać myśli Erwina Coumansa czyli ikony silników fizycznych (Havok/Bullet). OpenVDB ma bardzo proste API i ogólnie implementacja polega na wydaniu odpowiednich poleceń. Tak w skrócie kod Kevina polega na wywołaniu funkcji zrób grida, dodaj voxele (cząsteczki), zrób z tego siatkę, zastosuj filtr (każdy ma ofc odpowiednie parametry, ale to jakie parametry mają być jest pozostawiane grafikowi, który musi te parametry ustawić) i nie musi mieć nawet pojęcia jak to się dzieje - to już robi OpenVDB, a wiedza jak to robi nie jest niezbędna (jest potrzebna mniej niż grafikowi, który później używa). Nie byłbym sobą, gdybym nie poprawił rażące mnie stwierdzenie "implementacja jest łatwiejsza niż pisanie czegoś swojego". Implementacja też pisanie czegoś swojego (wręcz głównie ;p). Już prędzej "napisanie wsparcia dla API gotowej implementacji (w tym wypadku OpenVDB) jest łatwiejsze niż zaprojektowanie i zaimplementowanie własnego rozwiązania."

OpenVDB to bardzo obszerna biblioteka, ale nie ma z nią Kevin nic wspólnego. To co on zrobił to było stosunkowo proste - OpenVDB to obszerna biblioteka, ale z bardzo prostym i dobrze udokumentowanym API. Jednak źle mnie zrozumiałeś... to bardzo dobrze, że wybrał łatwą drogę prowadzącą do najlepszego efektu i rozwoju tej części blendera zupełnie niezależnie (poprawki w OpenVDB poprawiają blendera, bez wkładu ludzi pracujących dla BF). Tak właśnie powinno się robić (czytaj pracować mądrze, a nie ciężko, jak w wypadku "Cube surfer" - wykonano tu wielokrotnie więcej pracy, a ta praca jest jedynie stratą czasu).

Wolę jednak uściślić to co piszesz. Cube surfer to kawał roboty, a Kevin Dietrich nie wiele miał do zrobienia. Z cube surfer było masę roboty i złych założeń jak pisanie w powolnym pythonie, pisanie wszystko od zera (oni nie korzystają z OpenVDB) i efekt nie jest najlepszy. Kevin zrobił odwrotnie. Zamiast wykonywać kawał roboty wykorzystał gotowy kod (i to OpenVDB zawdzięczamy wydajność i możliwości, a nie Kevinowi), i tylko podpiął pod Blendera już gotowy napisany przez pracowników Dreamworksa kod. Podsumowując "kawał dobrej roboty" tu nie za bardzo pasuje, bo mamy tu do czynienia z dobrą robotą, ale bardzo małą w myśl zasady pracuj mądrze nie ciężko (cube surfer to kawał roboty... tylko, że niezbyt mądrej ;p). PS. Martwi mnie jednak rozwój OpenVDB przez Dreamworks... po zamknięciu Dreamworks.

Nikt nie mówi, że zrezygnują. Będą wspierać oba. Tylko nie zaistnieje sytuacja jak z Collada, bo Pixar ma standardową dobrą implementacje (tak jak Alembic), więc jego wsparcie jest proste.

USD nie jest dostępny w żadnym sofcie, bo przeprowadzają testy (m.in. z autodeskiem), czy nie ma buggów (od początku współpracują z Pixarem ludzie z ILM). Wypuszczą go raczej szybko, a API już jest dostępne (już można pisać). Autodesk nie będzie tępił, a sam jest zainteresowany jednym uniwersalnym formatem i wie, że fbx nim nie jest. Co do Collady to chciałem zapytać się, czy znasz jeden program obsługujący go poprawnie? No właśnie - blender do dziś nie potrafi poprawnie tych plików czytać. Problemem Collady jest to, że tego formatu praktycznie nie da się poprawnie wspierać! Osoby korzystające z Alembica to bardzo mały ułamek. Ja nie widzę sensu tego formatu, poza animatorem, który chce robić w innym programie. Do niczego innego za bardzo się nie nadaje, jest to format stratny, usuwane są dane przy eksporcie, których nie możesz przywrócić. Przyjął się, ale akurat wśród użytkowników blendera, to akurat zapewne większości zupełnie on zwisa. USD nie ma tych wad, idealne wsparcie dla Alembic dostajesz gratis, a wyjdzie zapewne przed Alembic w blenderze (czytaj zanim wejdzie do kodu blendera trzeba będzie myśleć o usunięciu tego kodu) i to od razu ze wsparciem w praktycznie wszystkich programach (główni twórcy softu 3d sdk już mają).

@Monio: Nie do końca jest tak. OpenImageIO to żaden standard (to zwykły studencki projekt GSoC) - to po prostu biblioteka do ładowania plików jak JPG/PNG/OpenEXR... i nie jest akurat ważne, czy z niego korzysta czy z innego rozwijanego rozwiązania jak FreeImage (różnice niewielkie - ten czyta RAWy, ten czyta tekstury w formatach IFF/Zfile). Wśród programów 3d z OpenImageIO chyba tylko blender z niego korzysta, więc taki z niego "standard" ;]. Bullet na CPU... ciężko mówić o tym, że blender go wspiera. Do wykrywania kolizji? Nie wykorzystuje. Do symulacji ciuchów? No też nie. Do Softbody? Kiedyś tak (2.4)... teraz nie. Do symulacji fluidów/dymu... no i znowu nie (dla przykładu w Houdini wszędzie tak). Bullet wykorzystuje się w blenderze tylko do brył sztywnych i gameengine (tu softbody dalej wykorzystuje bullet). Widzę, że zaczynają stosować standardy co bardo cieszy, jednak smuci to, że idzie im to strasznie powoli i po prostu wymieniają rzeczy, które już są napisane (na które już zmarnowali czas), a i obecnie jest marnowany czas (przykładowo alembic). Przykładowo na wsparcie w Cycles formatu blenderowej wolumetryki stracono czas (który powinno się poświęcić na napisanie wsparcia dla OpenVDP (od 2012 roku od Dreamworks) lub konkurencyjnego Field3D (od 2010 roku i też twórcy z Sony dostali technicznego oskara w tym roku)), robi się teraz po latach wsparcie dla Alembic, podczas gdy jest to bardzo ograniczony bakeowany format od Sony, który praktycznie niczego nie załatwia, a nawet nie myśli się o edytowalnym pośrednim formacie jak Pixarowy USD (Universal Scene Description), który jest faktycznie potrzebny użytkownikom (bo nie oszukujmy się, że FBX jest dobrym standardem)... i co więcej wsparcie dla Alembic dostaje się gratis (Alembic jest pluginem do USD, dlatego nie ma wielkiego sensu pisanie dla niego wsparcia, gdy można je mieć z automatu) - tu IMO byłoby mądrzej zająć się czymś innym lub wykorzystać dokumentacje API, aby przygotować się do wsparcia dla SDK, gdy Pixar go wyda, wsparcie dla bullet dla wszystkiego (czytaj, aby fizyka ze sobą współpracowała, a nie jedna symulacja przeszkadzała innej) nawet w planach nie jest. Ogólnie jest lepiej, bo już nie jest tak, że standardy swoje, blender swoje, ale dalej dobrze nie jest.

Od lat mam marzenie, że zaczną wykorzystywać branżowe standardy, zamiast pisać sami wszystko. Ogólnie chętnie bym zobaczył połączenie Bullet (teraz już z liczeniem na GPU, symulacje cząsteczkowe itp.) z OpenVDB (cząsteczki wypluwane przez Bullet wrzucane jako input do OpenVDB). Czyli połączenie tak jak w Houdini czy w narzędziach Pixara/Dreamworksa. BTW. wiedzieliście o tym, że w tym roku twórca silnika Bullet (Erwin Coumans) i twórcy OpenVDB dostali techniczne Oskary za zasługi dla branży filmowej? http://www.oscars.org/news/21-scientific-and-technical-achievements-be-honored-academy-awardsr

Nie, bo nikt nie ma czasu napisać shaderów odpowiadających tym materiałom (zaimplementowanie shaderów Cycles w GLSL). Ale ofc jest to wykonalne, nawet z OpenGL 1.x i shaderami ASM, a samo ograniczenie się do 2.1 tu niczego nie poprawi.

Niestety OpenGL 2.1 większych możliwości nie ma. To o czym mówisz to nie możliwości OpenGL, a po prostu rzecz do zrobienia przez pracowników BF. Problem w tym, że właśnie obsługa dużej ilości różnych API od staroci z 2.1 po nowoczesne API sprawi, że tego czasu nie będzie na nic takiego (ba nawet na nowoczesne api zapewne braknie pary). PS. Po co ci MatCapy gdy możesz sobie sam je zrobić z materiałami blendera i cieniowaniem viewportu ustawionym na GLSL? (załącznik) To nie działa tak, że jest to ograniczenie... to jest strata czasu. To, że minimum będą wspierać 2.1, nie oznacza, że nie mogą sprawdzić czy karta obsługuje nowsze i tamte wspierać inaczej. Problem polega na tym, że praktycznie wszystko trzeba pisać kilka razy. Co zyskiwane jest w nowych wersjach? 3.0: - szybki rendering do tekstury (przez ograniczenie się do 2.1 jako minumum muszą sprawdzać czy jest FBO obsługiwane i jeśli nie to robić inaczej), - Texture Array - tablice tekstur, które powodują, że blender nie musi bindować tekstur na każdy obiekt osobno, a są trzymane w tablicy, co zmniejsza narzut na CPU... niestety w wypadku 2.1 trzeba wspierać bindowanie per object - Transform Feedback - obliczenia na siatce na GPU, które przez CPU są odczytywane. Daje to olbrzymie przyspieszenie przykładowo przy modyfikatorach - zamiast się męczyć na CPU z modyfikacją siatki, znacznie lepszą opcją jest zrobienie tego na GPU przez Transform Feedback... ofc tylko ze względu na to, że ograniczenie jest do 2.1 trzeba kod tych modyfikatorów powielać... jeśli jest TF to wykorzystać kod na GPU, jeśli nie to liczyć powoli na CPU. 3.1: - Instancing (i tak - obecnie blender obywa się bez niego! Tylko softowo instancing jest po stronie CPU, ale na GPU już rysuje wszystko osobno). - Uniform Buffer Object - coś jak VBO, tylko dla uniformów (zmienne przekazywane do shaderów). Pozwala zmniejszyć ilość bindowania i nie trzeba danych przesyłać - odpowiednie dane dla obiektu już są na GPU tylko się wskazuje gdzie. 3.3 - occlusion query - odpytywanie GPU czy obiekt jest zasłonięty i jest sens go rysować - instanced arrays pomagają lepiej wykorzystać instancing Podsumowując tu wszędzie zyskujesz wydajność*i możliwość napisania tylko raz, a nie wiele razy. To wszystko to tak naprawdę podniesienie tylko o jeden szczebelek, bo wszystkie karty Nvidii (od serii 8k z 2006r) czy AMD (2k z 2007r.), które wspierają 3.0 wspierają i 3.3 (wystarczy zaktualizować sterownik). Czas zaoszczędzony zarówno na wydajności jak i na pracy nad wspieraniem wielu ścieżek renderingu można wykorzystać na pracę nad lepszymi możliwościami (bo jest kiedy i jest jak, bo wydajność programu pozwala na dołożenie trochę do niego). Seria 4.x przynosi już zupełnie kosmos w wypadku OpenGL (w tym typowo dla programów jak Blender z viewport_array - czyli przykładowo 4x okienka (viewporty) z siatką widzimy i za jednym przetwarzaniem wierzchołków renderujemy do wszystkich 4rech, zamiast 4x przetwarzać wierzchołki dla każdego z osobna), ale to powinno być już jako alternatywna ścieżka, a jako minimum 3.3. Ofc opisałem tylko część z rzeczy dodanych w kolejnych wersjach (w tym nie opisałem bardzo ważnej i dużej aktualizacji 3.2 (z geometry sharedami, które pozwoli na więcej włosów/cząsteczek w takim samym czasie)), aby tylko tak na szybko pokazać ile mnij roboty byłoby ograniczając się do 3.3.

OpenGL 2.1 wprowadził tak na dobrą sprawę tylko GLSL 1.2 i względem starszych OpenGL niż 1.5 gwarantuje VBO (1.5 gwarantuje, a 2.1 dziedziczy to). Blender od początku obsługi GLSL obsługuje wersje 1.2 (od jakiegoś czasu GE obsługuje 1.3 jeśli dostępne). To oznacza jedynie to, że będzie można wywalić kod dla kart bez shaderów (wykorzystujący multitexturing jeszcze na fixed pipeline), i daje możliwość wyrzucenia kodu dla kart nie obsługujących VBO (do teraz VBO było opcjonalne, a jeśli nie było to był kod, dla zabytkowych kart z początku lat 90 ;p). OpenGL 2.1 ogólnie nic nie dodaje do tego co blender obsługiwał... po prostu odejmuje konieczność dbania o karty starsze (IMHO stanowczo za nisko ten limit minimum ustanowiony, bo 2.1 już dziś praktycznie nie istnieje).

Z czego pewnie 5% użytkownicy MacOS ze sprzętem obsługującym nowe wersje (tylko blender pokazuje tam 2.1, bo taki tworzy kontekst... gdy blender stworzy kontekst 3.3 to będzie działać i taki zobaczysz), a 3-4% to osoby po prostu, ze starymi sterownikami (do sprzętu wspierającego 3.3), bo nie mieli takiej potrzeby - gdy będzie trzeba to zainstalują. Jaki skok? Wersji 2.1 Blender używa od lat. Teraz po prostu postanowili wywalić kod dla starszych wersji - nie jest to żaden skok, a po prostu oczyszczenie kodu ze staroci.

GT210 kosztuje około 100zł... bardzo drogo. Nieporównywalnie lepszą opcją jest GeForce GT610 - czyli OpenGL 4.5, nowa wersja CUDA i wyższa wydajność, a takie GPU za 140zł już kupisz (na amazonie kartę OpenGL 4.5 można kupić za 40 dolarów - to ciężko nazwać zaporową ceną, dla kogoś chcącego zajmować się grafiką 3D).

Jakby nie było... w takim SF teraz żyjemy ;p. Przykładowo "Powrót do przyszłości", który przenosil widza do 2015 roku pokazywał takie cuda jak wideokonferencje (skype/hangout i masa innych), rozpoznawanie twarzy i głosu (jest i wykorzystywane od odblokowania telefonu twarzą, po policję ścigającą osoby, które zobaczyły kamery monitoringu w wypadku twarzy, a głos to Siri/Google Now itp.), okulary VR (od Google Glass, po Oculus czy okularki od Sony/Samsung), Multiscreening (no ba), tablety. Tak naprawdę to co w tym filmie się nie sprawdziło to... latające samochody (istnieją, ale nie ma ich w sklepach - już w 2017 ma wyjść do detalicznej sprzedaży kilka latających motorów (na bazie konstrukcji quadcopterów (dronów))), i latające deskorolki (testowane ). Czyli tak naprawdę nie za bardzo się pomylili (a wielu jeszcze bardziej rewolucyjnych nowinek które obecnie sa powszechne lub za horyzontem - chociażby street view (takie coś było nawet niewyobrażalne) czy samochody od Google jeżdżące bez kierowcy, czy prężnie rozwijające się hologramy, które niektóre sklepy w japonii czy usa wykorzystują jako reklamę w 3D). Gdyby człowiek z lat 80 przeniusł się do dzisiejszego czasu to czułby się jak w SF... dla nas to norma, bo w tych czasach żyjemy (dziś gdy chce na kanapie coś wyszukać w google to po prostu mówię do telefonu i mi odpowiada - kompletne SF jeszcze niedawno).

Niebezpieczne będzie zawsze - wszystko podpięte do internetu da się złamać i to się nie zmieni. Nie bez powodu co poważniejsze firmy mają sieci wewnętrzne bez dostępu do internetu. Serwisy chmurowe poza tym, że sprawiają, że oddajesz zewnętrznej firmie tajne dane (dla firm nie do zaakceptowania) to jeszcze narażasz się w sposób okropnie łatwy dla atakującego (atakując jeden cel (serwis chmurowy), zyskuje dane na raz wielu osób i firm... dlatego serwisy chmurowe tak szybko padają (i to niezależnie czy dropbox, sony, asus czy innej firmy), bo są atrakcyjnym łupem).

O ile chmura przy graniu ma jaką przyszłość (nie, że jakąś wielką, bo lagi obecnie uniemożliwiają sensowne granie i przed wprowadzeniem światłowodów do domów raczej się to nie zmieni, a obraz, który widzisz jest mocno zniekształcony (kodowany stratnie)). Jednak chmura nie ma przyszłości na stanowiskach produkcyjnych, w firmach itp. Już w wypadku obliczeń co większe firmy z mody chmurowej się wycofują, bo to jest po prostu niebezpieczne i kiepskie rozwiązanie.

Przyznam, że uruchomiłem blendera kilka lat temu na tablecie i działało to całkiem dobrze (do podstawowej pracy i wysłania renderingu w chmurę można by się pobawić) - ofc do sensownej obsługi wymagało to podpięcia klawiatury i myszki. Rynek zmierza w kierunku urządzeń modułowych jak wspomniany przez Ciebie padfon. Obecnie masz tam tak: Masz smartfon, gdy potrzebujesz tabletu wkładasz telefon do obudowy i masz tablet (z dodatkową baterią). Gdy potrzebujesz netbooka (coś napisać na klawiaturze czy chcesz obsługę gładzika) to podpinasz klawiaturę (z dodatkową baterią). W przyszłości zapewne takie rozwiązania będą ustandaryzowane i do tabletowej obudowy firmy X będziesz mógł podłączyć telefon firmy Y. Ja przyszłość tego rynku widzę w ten sposób, że masz smartfona - swój osobisty komputer... który możesz podłączyć do ekranu (przykładowo 13 cali) i mieć tablet (z dodatkową baterią i dodatkowym procesorem, dodającym mocy) do prezentacji klientowi (imo wygodniejsza forma prezentacji niż na laptopie), a jak wrócisz do pracy to po prostu podpinasz telefon do 25 calowego ekranu z myszką i klawiaturą (i dodatkowym prockiem (lub miejscem na moduł procesora jak w projekcie Ara od Google - czyli zwykły monitor 2x usb, a procek dopinasz sobie sam)), aby popracować i masz iMac'a. Masz wtedy w jednym urządzeniu wszystkie urządzenia jakich potrzebujesz w smartfonie, wszystkie twoje dane (podpinasz w hotelu pod ekran smartfon i masz stanowisko pracy i swój komputer/swoje dane). Tak wygląda kierunek rynku (od modułowych telefonów jak projekt Ara, gdzie podzespoły wybierasz sam i wpinasz jak w PC, po modułowe urządzenia jak Padfone, które rozszerzają możliwości sprzętu podstawowego do możliwości zupełnie innej klasy sprzętu) i mnie się on podoba. Ofc to nie jest osiągalne wcześniej niż w następnej dekadzie, ale taka ewolucja sprzętu mobilnego.

Komputery nie wymarły i nie wymrą (jak jak superkomputery nie wymarły po wejściu PC). Jednak komputery potocznie nazywane PC nie są już tym, co oznacza ta nazwa. Dziś komputerem osobistym jest smartfon i tablet (a ich łączna sprzedaż to kilkukrotność sprzedaży PC) i taka jest prawda. Komputery stacjonarne/mocne laptopy to obecnie nie komputery osobiste, a stacje robocze (workstations), które służą do pracy, a nie jako komputer osobisty. Jak najbardziej można to podsumować jako wymarcie komputerów PC i one zajeły dziś miejsce stacji roboczych (używanych przez grafików i programistów, gdy PC były jak smartfony/tablety... za słabe do profesjonalnych zastosowań). Rynek osobisty to dziś urządzenia mobilne... które z czasem podobnie jak PC kiedyś, przejmą rolę mocniejszych braci (jako urządzenia modułowe - podpinasz tablet/telefon pod dock roboczy i obsługujesz program klawiaturą i myszką), ale to przyjdzie później (dziś mamy czas przejściowy jak wtedy gdy graficy pracujący na Irixie wykorzystującym przodka OpenGL czyli IrisGL, na swoich 64 bitowych procesorach na początku lat 90 śmiali się z PC, że to zabawki dla dzieci i nie nadają się do poważnej pracy). OFC co ciekawe, zwalanie winy za nie wykorzystywanie nowych API na mobilki to jest śmieszne gdy Tegra K1 i Tegra X1 obsługują OpenGL 4.5 z dużą nawiązką, PowerVR 7XT obsługuje OpenGL 4.4, a Adreno 400 (Snapdragony), Mali 600+ (Samsung Exynos) wspierają SSBO (zapomnij w blenderze - tu "nowość" bo używają UBO z OpenGL 3.x), compute shadery, tesselację, geometry shadery... Ofc stare tablety czy smartfony nie obsługują, ale na nich odpalenie blendera to jakiś żart (ze względu na stare, powolne CPU).

Pokazuje kiepsko (w praktyce jest znacznie więcej obsługujących nowe wersje) - głosują tam na OpenGL 2.1 osoby korzystające z MacOS X z obsługą OpenGL 4.x... bo blender pokazuje im 2.1 (sterowniki na Macu pokazują nie wersję jaką mogą obsługiwać, a taką jako kontekst jest stwrzony, a blender robi kontekst zgodny z 2.1). Głosy na 3.0, 3.1 czy 3.2 to od osób które nie aktualizują sterowników (nielicząc starsze GPU Intela, których raczej do blendera nikt nie ośmielił by się użyć wszystkie karty które obsługują OpenGL 3.0 dostały aktualizacje sterowników do 3.3). Czyli tak napradę jest jeszcze większa przewaga 3.3+... co jednak przeraża to to, że opisują tam użytkownicy, że korzystają z Mesy (otwarte sterowniki pod Linuksa, gdy nie zainstaluje się sterowników od producenta kart)... przecież blender już obecnie na sterownikach mesy nie działa (latające czarne artefakty i masa błędów), a ludzie używają mesy? Tego sobie nawet w koszmarach nie wyobrażałem (tym bardziej, że na kartach, do których są dobre sterowniki i jest obsługa OpenGL 4.4 i częściowo 4.5).

Myślę, że ograniczenie się do OpenGL 4.3 jako minimum byłoby rozsądne. Ogólnie, kto dziś korzysta w grafice z GPU starszego niż Fermi (pełna obsługa OpenGL 4.5), HD5k (pełna obsługa OpenGL 4.4 i ważniejsza połowa 4.5), czy nawet Intel z Haswelli (wcześniejsze i tak do niczego się nie nadają, a te obsługują OpenGL 4.3 w pełni). Jeśli ktoś ma starsze GPU to nawet low endy w cenie 100-200zł przy nowym API powinien dać im większą wydajność. OpenGL 4.3 daje wszystko co potrzeba w standardzie, a bardzo młode dodatki (GCN/Kepler/Maxwell+) są dostępne łatwo jako rozszerzenia do kontekstu 4.3. Nie oszukujmy się, że wymaganie 5-cioletniej karty graficznej od grafika było dużym wymaganiem. Drugą sprawą jest to, czy obecnie nie lepiej jest przeczekać i zrobić wersji legacy dla starych kart z obecnej, a dla nowych napisać już w OpenGL Next (który powinien mieć wymagania podobne do powyżej podanych). Nie pozwoli może to przyspieszyć wydajności viewportu względem OpenGL 4.3 + rozszerzenia, ale przynajmniej na kolejne lata nie będzie wymówki, że się nie da, bo wszystko co nowe wymaga przepisania całości, bo to zupełnie nowe API.

Wątpiłem, bo w BF nie lubią warunkowego renderingu i ciągną w dół. Te wszystkie wymienione przez Ciebie backendy to gotowe backendy napisane przez Pixara (myślałem, że ich nie udostępnią w blenderze). Żadna magia. ViewportFX dalej nie potrafi zrobić kontekstu OpenGL 4.x (az specjalnie sprawdzilem w repo - to też tłumaczy dlaczego nie ma gotowego, napisanego przez pixara backendu w powyższym filmiku), więc o tesselacji, compute shaderach czy wydajnym rysowaniu zapomnij... przynajmniej w tej chwili. Obecnie w BF cieszą się, że ograniczenie się do OpenGL 2.1 pozwoli im zmniejszyć warunkowość kodu (obsługiwanie kart bez VBO, które ma naście lat i kart bez GLSL 1.2 (czyli kart starszych niż 2005 z tego co pamiętam)). Nie myślą puki co komplikować sobie życia wspierając karty z tego dziesięciolecia.

Niestety OpenSubdiv zapewne nie zadziałą na pełnej swojej wydajności z GLSL Compute (wymagany kontekst OpenGL 4.0), a wykorzystają Transform Feedback dostępny w GeForce 8k z 2006 roku. Dalej to prehistoria, ale już i tak lepiej niż obecnie (no ok, mogą jeszcze użyć CUDA/OpenCL, ale wątpię, skoro się ograniczają do GL2.1).

@NV: W webDev ogólnie jest słaby wybór. Tu popularne masz języki takie jak PHP i Python/Perl/Ruby ze względu na to, że łatwo o serwer ze wsparciem dla tych języków. Ja osobiście wybrałbym JSP lub ewentualnie ASP.NET... jednak o serwer z obsługą serwletów Javy (np. Tomcat) lub kodu zarządzanego .NET (windowsowe serwery z obsługą ASP.NET (nie mylić z ASP, bez net (rozszerzenie asp, a nie aspx))) jest znacznie trudniej i pewnie gdybym był zmuszony do wyboru mocno bym rozważył za i przeciw - przy stronie dla siebie poszukałbym serwera z JSP... przy kodzie na sprzedaż dla innych celowałbym w PHP/Python/Ruby ze względu na to, że praktycznie na każdym serwerze będzie działać, a to duża zaleta w tym przypadku, co powoduje, że opłaca się męczyć z tymi językami. Z JSP i ASP.NET jest trochę jak z pisaniem programu dla PowerPC. O ile ten program jest dla Ciebie (lub pod zamówienie specjalne) i masz PowerPC (serwer JSP) to wszystko ok... ale jeżli celujesz w sprzedaż ogólną, a nie na zamówienie to x86 (języki dostępne praktycznie wszędzie przez prodte moduły czy zwykłe CGI) jest znacznie zyskowniejszym i większym rynkiem ;p.