Skoti

Nie znormalizował i normalizacja nie robi tego co Divide+Add (polecam nie dzielić przez 2, a mnożyć przez 0.5... jest to trochę szybsze). Normalizacja zmienia długość wektora na wartość 1... czyli przykładowo (-1, 0, 0) to jest już znormalizowany wektor, bo jego długość wynosi 1. Jednak jeśli chcemy zapisać wartości XYZ normalnej do obrazu to tu jest problem, bo te zazwyczaj nie obsługują liczb ujemnych. Dlatego już znormalizowaną normalną (taką jak kompozytor daje jako normal) musimy skompresować z zakresu -1 do 1 (takie są skrajne wartości każdego z elementów w znormalizowanym wektorze) tak, aby każdy element składowy (x,y,z) miały wartości od 0 do 1 aby można było je zapisać do tekstury/obrazu (w shaderach dokładnie to samo się robi, zapisując normalne, chyba, że piszemy dla sprzętu obsługującego tekstury ze znakiem). Co do zmian kolorów to po prostu zależy od tego jak sobie ustawimy tangent (które U czy V wynikowej tekstury jest tangent, a które binormal) - większość programów definiuje to tak jak zrobił to Monio.

Do tej pory nie, bo nie było dobrych narzędzi edycyjnych, ale już 2 lata temu na Siggraph 2011 Nvidia pokazywała jak to zrobić w realtime na GPU https://developer.nvidia.com/siggraph-2011 zaraz później AMD wydała "AMD Leo Demo", które korzysta z PTex i wykorzystuje nowe rozwiązanie AMD Partially resident textures (PRT) do tego http://developer.amd.com/resources/documentation-articles/samples-demos/gpu-demos/amd-radeon-hd-7900-series-graphics-real-time-demos/ a w tym roku Nvidia pokazała jak zrobić to optymalniej, jednak bez tak specyficznych rozwiązań https://developer.nvidia.com/sites/default/files/akamai/gamedev/docs/Borderless%20Ptex.pdf ... chociaż ze względu na to, że rozszerzenie OpenGL do PRT od AMD stało się normą ARB i jest dostępne w sterownikach Nvidii OpenGL 4.4 dla kart od serii Fermi (wszystkie z tesselacją) http://www.opengl.org/registry/specs/ARB/sparse_texture.txt, a ta funkcjonalność weszła do DirectX 11.2 (Direct3D Tiled Resources) więc można wykorzystać rozwiązanie AMD, bo już specyficznym one-vendor nie jest. PTex to zwykłe kwadratowe tekstury - po prostu ich dużo (dlatego korzysta się z tablic tekstur lub sparse texture - zależy od implementacji - w drugiej opcji textury jeśli ich nie widać nie muszą być nawet w pamięci GPU), a UV w wersji GPU generuje się w shaderach Domain/Evaluation (nazwa inna zależnie od DX czy GL).

@Creator: Dlaczego to ma być niby realtime GI? Lub ogólniej... dlaczego ktokolwiek tu zakłada tak nielogiczną rzecz jak wykorzystanie silnika gier = rendering realtime? Rendering gier musi być realtime, ale rendering filmów na takim silniku nie musi się tak odbywać i można z wysoka jakością zrobić rendering z GI tracingiem Voxeli (chociaż to robią już realtime silniki gier ;p)... można też w silniku rasteryzującym (gier) użyć Point-Based Global Illumination tak jak robi to na CPU ILM czy Pixar (co więcej właśnie Pixar przeniosło to do swojego podglądu realtime (w niskiej jakości, bo to podgląd - jakość można podbić, kiedy liczy się jakość), a ILM pewnie właśnie chce przenieść i o tym mówi). Caustykę i dokładniejsze miękkie cienie też da się pogodzić z silnikiem gier... co najśmieszniejsze najcięższym do pogodzenia jest rzecz naturalnie prosta dla raytracerów czyli fizycznie poprawne odbicia od obiektów i bardzo problematyczne odbicia obiektu w sobie samym. Śmieszy mnie trochę podawanie Pixara przez niektórych jako firmy która woli raytracing. Ich RenderMan faktycznie masę rzeczy robi raytracingiem (podobnie jak gry od lat - nawet proste relief mapping/parallax occlusion mapping/cone step mapping... polegają właśnie na raytracingu, już nie mówiąc właśnie o raytracingu voxeli w obecnych silnikach). Pixarowy RenderMan do renderer hybrydowy - robi część rasteryzacją (jak OpenGL/DirectX), a część raytracing (gry robią to w shaderach albo w CUDA/OpenCL). Pixar sposobem renderowania (podobnie jak ILM) przypomina właśnie silniki gier (tylko, że nie ogranicza tak mocno jakości, ilości sampli w próbkowaniu raytracingu... no właśnie w tym sęk, że silniki gier też tego nie robią najczęściej, a jedynie do gier dostosowuje się tak rendering, aby działało realtime - do renderingu filmów nie trzeba się tak ograniczać na tym samym silniku) - zaletą RenderMana w stosunku do innych silników jest to, że skutecznie on oszukuje i nie ma w nim mowy o poprawności fizycznej (sama idea GI opartego o chmurę punktów przeczy zupełnie poprawności fizycznej - za to jest dobrym oszustwem o super wydajności).

Jeśli dobrze Cię zrozumiałem o co chodzi to wystarczy odznaczyć obiekt (lub ogólnie wyjść z edit mode do obiect mode i może zostać zaznaczony) w widoku 3d.

@ikkiz: Od kiedy usunąłem tam konto, bo działo się bardzo źle z zarządzaniem strony i poziom spadał dramatycznie, zaglądam tam co jakiś czas i jedyne co widzę, to jeszcze niższy poziom. Ogólnie jak tylko wchodzę tam to od razu odrzuca ignorancja w temacie blendera, osób piszących na tym forum (poza nielicznymi wyjątkami, jednak oni zazwyczaj są i na tym forum).

Viewport 2.0 jest też w Mayce zwykłej - 2.0 to jest aktualizacja major o której była mowa (zasługująca na miano nowego numerka), a aktualizacje minor były robione z wersji na wersję.

A jesteś pewien, że MEL jest obsługiwany. Autodesk zaprzecza. SDK ma być ponoć wydane w niedługim czasie dla pluginów firm trzecich - pytam bo może była jakaś informacja "ograniczenie i tak będzie", lub "ograniczenie dotyczy tylko FBX" (ofc tylko FBX dotyczy również Collady, która w Maya LT jest obsługiwana jako nakładka na eksporter FBX).

Ograniczenie nie jest przy imporcie, a przy eksporcie. Wczytać model HP z sculptu możesz, wypalasz normalmapki, displace mapki, a eksportujesz do silnika tylko model 15-20k poly (resztę załatwiasz teselacją w oparciu o te mapki). W Majce LT możesz mieć na scenie miliony poly, ale eksportować musisz po modelu max 25k poly (przynajmniej przy FBX - przy innych nie wiadomo), a nie całą scenę. PS. To ograniczenie jest tak dobrane, aby nie uderzało w twórców gier, a w grafików, chcący użyć wersji LT do grafiki, wizualizacji... - dlatego jest pozbawiona renderera poza bakeowaniem, oraz ogranicza eksport na takim poziomie, żeby w rendererach standalone nie wykorzystać tego.

Właśnie - nie interesowałem się tym bardzo, ale jest to ograniczenie też dla własnych pluginów? Nie, że 25k na model to mało - postacie u mnie się mieszczą spokojnie w wersji na PC (i raczej nikt gęstszej siatki na PC nie robi, bo od tego jest teselacja, aby zagęściła tylko tam gdzie potrzeba), a najwięcej poly idzie na nie, a scenę z modeli ustawiasz w edytorze silnika, a nie w mayi.

Minor update we wszystkich tych softach jest co wydanie, a większe (major) przepisanie raz na kilka lat. W blenderze jest tak, że przez dziesięciolecie nic się nie działo, a później dostał minor update, aktualizujący do technologii z 2003r... wypas. Ponoć siedzisz w gamedev, a nie słyszałeś o debuggerach GPU? API dla eksporterów w Maxie jest do dupy, wsparcie dla programistów też (pytania do oficjalnego płatnego wsparcia potrafią siedzieć bez odpowiedzi latami). Jednak dużą zaletą jest to, że jest ono stabilne (poza dodaniem możliwości nie zmieniło się ono od czasów kiedy w nazwie nie było Autodesk, a było Discreet i napisany kod w Game Export Interface wtedy bardzo prawdopodobne, że skompilowałby się na najnowsze wersje (bo wyciąganie siatki, materiałów, normalnych itp się nie zmieniło w tym API)). Wydałem gry (zamknięte licencje). Co do tego, że nie słyszałeś o takich osobach to wejdź na strony poświęcone Gamedev i zobacz developerów Indie. Takie podejście to trochę silnikologia stosowana, ale sporo osób tak robi, chcąc mieć jak największą kontrolę nad tym co robi. O wydawaniu tooli nie myślę, bo to za dużo zachodu z supportem.

Viewporty w Maxie, Mayi czy Zbrushu są aktualizowane co wersję i wykorzystują aktualne możliwości kart za pomocą OpenGL 3.x + rozszerzenia z 4.x (nowoczesny instancing, transform feedback, buffer obiekty na wszystko (tekstury (TBO), uniformy (UBO), atrybuty (VBO), framebuffer (fbo)...), a nie tylko vierzchołki VBO z OpenGL 1.5 jak w blenderze) lub Dx11 (Max/Maya pod Windows). Z tego co wiem niektóre programy robią nawet już picking (sprawdzanie co kliknąłeś w viewporcie i zaznaczanie tego) za pomocą DxCompute, OpenCL przez co edycia siatki przy milionach poly jest możliwa stosunkowo wydajnie. Blender do pickingu używa rzeczy, które ze starości wyleciały już z OpenGL i nie są jego częścią. Z rozmów z core team w wielu miejscach (od prywatnych maili po irc). Wiedzą o części bolączek, o innych dowiadują się od osób takich jak ja, ale niezależnie od tego plany mają nie dalekosiężne, a raczej sklecić rozwiązanie na kolanie to się ludzie zamkną, zanim zrozumieją, że to nawet nie dotyka problemu i nic to nie zmienia. Nigdzie nie mówiłem, że pisałem pluginy (ich w bienderze pisać się nie da), skryptów też nie piszę do blendera (bo zmienne api jest wystarczająco odrzucające). Kodu poprawek nie udostępnię z 2ch powodów: - nie udostępnię nic na wirusologicznej licencji GPL. - kodu (samo jądro blendera) który naprawiam nie powinno się nawet naprawiać, a powinno się wyrzucić do kosza i napisać od nowa - to jest kod tak napisany, że po prostu jego rozwijanie jest jakimś okrutnym żartem. Cycles jest teraz dobrze pisany, kilka innych modułów też, ale wszystko to stoi na glinianych nogach, bo w samym programie jest po prostu śmietnik, a nie kod (kod źle zaprojektowany naście lat temu, w którym nawarstwiły się poprawki poprawek do poprawek i już się tego na dobrą sprawę rozwijać nie da i najbardziej humanitarnie nie jest podtrzymywać go w mękach, a zrobić eutanazję). Nie do końca - do modelowania wolę Blendera od Maya czy Maxa (ale przez resztę jego wad naprawdę często myślę, czy nie skopiować konceptu modelowania do swojego edytora) - jednak zastanawiam się nad uzupełnieniem workflow wersją Mayi dla developerów gier czyli Autodesk Maya LT.

Problem w tym, że Ton i kilku innych mają skila, aby robić coś więcej, a wolą się opierdzielać przy pierdołach. Milion particli powinno się przeliczyć w ułamku sekundy - wystarczy wywalić obecny system fizyczny, a podpiąć Bullet z liczeniem w OpenCL, Viewport zamula, bo jest tragicznie napisany, a większość rzeczy wymagających obliczeń powinna być przenoszona do liczenia w OpenCL - to powinno się już przepisywać rok/dwa temu, a nawet nie widać perspektywy 5-10 lat, aby ktoś się zabrał za przeprojektowanie blendera. Już od jakiegoś czasu blender mnie denerwuje swoim rozwojem wszystkiego co niepotrzebne w core team, rozwój ważnych rzeczy idzie do GSoC gdzie niekompetentne osoby piszą kod, którego później nie da się wykorzystać/nie powinno się wykorzystać i zastanawiam się czy nie dopisać sobie narzędzi do modelowania (bo unwrapping mam bardzo podobny do blenderowego zaimplementowany już) i animacji i wyrzucić blendera zupełnie z workflow, bo lata mijają, a niewiele idzie ten soft do przodu.

Narzekania są na interface XSI, Lightwave, Maya, 3ds Max, Modo, Hudini... nie ma softu, żeby soft się początkującemu spodobał. Kombajn do grafiki 3D to nie jest paint, który dziecko potrafi obsługiwać tylko oprogramowanie, które jest stosunkowo skomplikowane w obsłudze i poza znajomością teorii grafiki (a przez jej brak też obwinia się UI) ważne jest, aby poznać program i jego rozwiązania (uruchom każdy inny program z wymienionych i również będziesz czuł się bardzo nieswojo i nie spodoba Ci się interface - nie dlatego, że te programy mają zły interface tylko dlatego, że każdy do niego podchodzi inaczej).

Wiem. Jednak nie użytkownicy BA zajmują się implementacją, a implementacja takiego UI jak pokazane zajmuje i tak sporo czasu, a jest to obecnie bezsensowne IMO postępowanie, bo są znacznie bardziej potrzebne jest nie marnowanie czasu na pierdoły tylko poprawki tam gdzie jest to faktycznie potrzebne.

Rozumiem, że uważasz iż wygląd jest ważniejszy niż rozwój silnika renderującego, przebudowa podstaw Blendera, przebudowa viewportu, dodanie i poprawienie narzędzi aby wydajniej się pracowało, poprawa w systemie animacji, poprawa w wypiekaniu danych, wyrzucenie obecnej prawie-fizyki i podpięcie bulleta i tony innych rzeczy, które są do roboty na już? Jeśli jednak uważasz, że najpierw powinno się poprawić kod który przeszkadza w rozwoju blendera i poprawić działanie programu, aby można było wydajniej pracować zanim pobawi się w aktualizację wyglądu to zapewne też uważasz, że na obecnym etapie jest to marnowanie czasu. Już dziś Blender ma najładniejszy interface ze wszystkich programów na rynku, ale nie to jest powodem dla którego korzysta się z danego programu. Fajnie by było gdyby wyglądem zajęliby się kiedy nie ma już nic innego do roboty, a nie dlatego, że wszystko inne wymaga więcej pracy, więc po raz kolejny na przestrzeni kilku lat wymieniają wygląd widgetów, bo to łatwe miłe i przyjemne, a masy krzykną WOW, podczas gdy program stoi w miejscu... w 2.69 masz mieć nowe kilka możliwości UI (hura), zaraz zmienią znowu widgety (hura), tu słychać o jeszcze nowych pomysłach na zmianę widgetów (hura), a program w najważniejszych kwestiach stoi w miejscu (...).

Ja stosuje do wszystkiego Blendera, a wady naprawiam własnymi łatkami, trickami i własnym bipathtracerem do wypiekania GI. Co sugeruję? Mieszany workflow jaki stosuje większość developerów studiów. Modelowanie + UV często jest robione w blenderze, ale dalej Blender ma już same wady i przenosi się jako OBJ do Maya/XSI gdzie się animuje, wypieka tekstury, do którego pisze się stabilne eksportery, jak i stabilne narzędzia dla projektantów... (dla blendera stabilnych narzędzi jako pluginy czy skrypty zrobić nie sposób ze względu na zmiany api). Nie kupiję w maxie pracowałem kilkanaście lat temu, a od lat używam Blendera. Problem w tym, że API w maxie czy w mayi zmienia się w praktyce raz na kilka lat i często albo po prostu działa, albo wystarczy rekompilować (3ds max ma 3DXI czyli 3ds Max Data eXchange Interface/Game Export Interface, który może i nie jest perfekcyjny, ale działa od lat i napisany z nim plugin działa z wieloma wersjami 3ds Max - to jego duża zaleta). Coś takiego jak eksporter dla silnika musi być stabilne i napisane raz na 4-5 lat, a nie raz na kilka miesięcy wszystko się sypie i trzeba naprawiać. Nikt nie potraktuje poważnie programu z tak zmiennym API. Zmiany w API powinny zachodzić nie częściej niż raz na 2-3 lata. Problemem Blendera jest to, że jego API nie jest przemyślane i zamiast dobrze zaprojektować raz na lata zmienia się w zależności od widzimisię kogoś. Przy wielu zaletach blendera jego największą wadą jest to, że rozwija się na zasadzie huraaaa! a później wszystko wyrzucamy, bo jednak wcześniej nie przemyśleliśmy tego co robimy i robiliśmy tylko dla robienia. Nie wiem jak ty, ale ja co kilka miesięcy nie mam zamiaru zabierać się za robienie tego samego co już zrobiłem, dlatego jedyna słuszna droga z blenderem to napisać sobie konwerter obj/collada/fbx i traktować blendera tylko jako dostarczyciela siatki ewentualnie animacji. Bezsensowne marnowanie czasu na zmianę w wyglądzie, która tak naprawdę nikogo nie interesuje. Pytasz to odpowiadam. Jaj nie urywa, ale w stosunku do blendera dostarcza masę "automatów". Nie jest to, żaden atut jakościowy, ale w wielu przypadkach przyśpiesza pracę.

Jest masa problemów - brak stabilnego API, więc trzeba ciągle poprawiać eksportery (3dmax jest tragiczny przy pisaniu eksporterów, ale przynajmniej jak napiszesz to działa, a nie jak w blenderze działa przez kilka miesięcy), praktycznie brak możliwości wypiekania GI, dopiero co przywrócone sensowne możliwości modelowania, "nie najlepsze" na rynku możliwości animowania postaci, błędy przy wypiekaniu normalnych, wcześniej niedostępne limitowanie ilości kości wpływających na siatkę (bardzo potrzebne przy animacji szkieletowej na GPU - a wszystkie silniki w miarę nowoczesne tak robią) - obecnie jest już to w blenderze, ale jeszcze za świeże, aby studia się przestawiły. Blender nadaje się stosunkowo dobrze do gamedev (i wiesz, że sam go używam), ale zdecydowanie nie nadaje się do tego świetnie. Jeśli studio nie liczy się z kasą na soft to blender nie jest najlepszym wyborem (idealnego ofc nie ma, ale są lepsze opcje).

Edytowałem, kiedy jeszcze nie było, żadnego posta, a jak zatwierdziłem to był jeden twój i byłeś tylko ty na forum, więc uznałem, że zauważysz edit. Problemów znanych od lat jest wiele... co więcej wiele razy już naprawianych. Jednym z nich jest tragiczne wsparcie dla OpenGL i viewportu. Przez lata było to na żałosnym poziomie (dostarczanie danych do OpenGL na poziomie wersji 1.0 z 1992), wielokrotnie ktoś mówił ja to poprawię i ponosił porażkę, a ostatnio była wielka aktualizacja i niewiele z tego wyszło - tzn już nie jest OpenGL 1, ale 1.5 z 2003 roku to też nie jest nic ciekawego kiedy OpenGL 4.4 mamy na rynku i przez te lata pojawiła się masa możliwości optymalizacji. Jeśli mówimy o twórcach gier to znacznie większym problemem niż sterowanie normalnymi (i tak to robi się per texel na normalmapach) jest to, że Cycles nie potrafi wypiekać do tekstur... i mimo, że jest to problem znany od początku Cycles to mimo, tego, że jest w planach przez rok spodziewać się go nie można. Nie dlatego, że jest to cicha umowa z innymi rendererami potrafiącymi to, a dlatego, że brakuje rąk do pracy i tylko jedna osoba rozwija kod, który ma więcej braków niż gotowych rzeczy. To, że miało być to naprawione wielokrotnie przez wolontariuszy o niczym nie świadczy - wolontariusze zazwyczaj nie mają, żadnej wiedzy na temat tego co robią i mają nadzieję za darmo zdobyć doświadczenie na przyszłość i nic z takiego projektu poprawiania wyjść nie może. W praktyce wyjdzie z poprawek coś tylko wtedy kiedy ktoś z core teamu się za to zabierze, ale jest ich za mało, a rzeczy do zrobienia na już jest zbyt dużo. Cycles to projekt jednoosobowy i wszystkie prawa do niego posiada fundacja blendera więc może zmieniać licencje (i dlatego to robi puki jeszcze może, tak samo jak większość nowych rzeczy wydaje bardziej liberalnej licencji, aby uniknąć problemów z jak blenderem)... jednak dziwię się, że nie wydali na LGPL (czyli ochrona Cycles przed włączeniem do innego programu jako jego części i możliwa utrata kontroli nad jego rozwojem, ale licencja pozwala na linkowanie z kodem zamkniętym czyli do podpięcia Cycles pluginem się nadaje). Kod Blendera został wykupiony przez społeczność w celu opublikowania na GPL, a w Blenderze w przeciwieństwie do Cycles jest kod mnóstwa osób niezwiązanych z fundacją i nie ma mowy. Aby zmienić licencję Blendera muszą się zgodzić wszystkie osoby które wpłacały na konto firmy Tona (Not a Number (założona przez Tona) - wcześniej blender był rozwijany jeszcze w NeoGeo gdzie Ton był współzałożycielem i był głównym programistą blendera) aby uwolnić kod Blendera, i wszystkie osoby które dodały przez lata chociaż jedną linijkę. Dlatego o ile Cycles zmienić licencję jeszcze można (chwilę jeszcze byłby rozwijany jako GPL i też już by był problem z tym), ale licencji Blendera ruszyć się nie da.

Podstawy tego co napisałem są na liście dyskusyjnej blendera - wielu twórców pluginów z innych softów już prowadziło tam dyskusję i byli odprawiani z kwitkiem i tekstem jesteśmy za, ale licencja zabrania, jak i były dyskusje rozpoczynane przez Tona na temat tego jak by tu obejść problem i był pomysł zrobienia serwera internetowego z blendera i pluginy miały się komunikować taki interface, ale to nie jest najlepszy pomysł na komunikację (bo faktycznie nie jest, ale lepszego nie ma, ze względu na licencje). Po prostu były to tak abstrakcyjne wizje, że słowo domysł nie pasowało, a nie chciałem pisać o urojeniach.

Octane też ma z tym problem, ale wcześniej uznali, że jakoś przeboleją otwarcie części eksportera (wydali to na otwartej licencji GPL, a mało która firma się na to odważy), a komunikację Blender->Octane zrobili przez protokół internetowy TCP/IP (powolnie, względem zlinkowanego kodu jak w innych programach, ale w wypadku Blendera jedyna możliwość, aby zrobić to legalnie).

Głowa boli od tych psełdodomysłów które nie mają żadnych podstaw. ChaosGroup nie stworzył pluginu do Blendera, bo Blender nie obsługuje pluginów... nie obsługuje pluginów, bo i tak nikt by ich nie pisał (ze względu na licencje Blendera czyli GPL, która chroni blendera przed zamknięciem, ale też zabrania zupełnie mieszania z zamkniętym kodem nawet w formie pluginów). Pozostają jedynie skrypty, a te z założenia mają otwartą konstrukcję. I wracamy do punktu wyjścia - licencja Blendera wymusza otwartość, przez co jest ignorowany przez firmy komercyjne, które dzielenia się kodem nie lubią. Twórcy blendera są świadomi problemu, bo wielokrotnie była prowadzona dyskusja na liście dyskusyjnej jak tu zmienić licencje lub ją obejść (GPL jest licencją wirusologiczną - obecnie tej licencji nie da się zmienić nawet jeśli fundacja Blendera by chciała - gdyby wybrali lata temu LGPL problemu by nie było, ale GPL blokuje wszystko). Co do braków blendera w podstawowych rzeczach to jest po prostu zły rozwój programu. Programistów fundacji blendera jest dosłownie kilku i delegowani są do pracy nad Cycles, API skryptowym, a główne potrzeby (narzędzia) są olewane lub na drugim planie. Wśród "wolontariuszy" są osoby, które same wybierają sobie to czym chcą się zajmować - zazwyczaj wybierają fajerwerki... czyli efekt wow, a nie praca u podstaw z niezbędnymi, ale kulejącymi narzędziami. Podany przykład narzędzia do eksportowania normalnych jest bezsensowny. To nie jego brakuje, ale narzędzia do edycji normalnych (wtedy przy eksporterach nie trzeba by nic robić, bo same by te normalne odczytała)... ale jak zwykle ktoś napisze prosty skrypt psełdorozwiązanie które będzie działać słabo i tylko z wybranymi formatami, zamiast rozwiązać to u podstaw raz, a dobrze i mieć ten temat z głowy (jednak napisanie psełdorozwiązania jest szybsze i można liczyć na efekt wow zanim do ludzi dotrze, że to bez sensu).

Tesle w wersjach pełny kepler (K20 i K20X) są fajne, bo mają HyperQ, co pozwala na spore zwiększenie wydajności... nietety nie w tej chwili, bo Cycles tego nie obsługuje. Najwydajniejszym GPU Nvidii jest obecnie Quadro K6000 (w przeciwieństwie do Tesli jednak nie ma HyperQ). Jednak w wydajność/cena najlepsze są GeForce z pełnymi Keplerami (Titan i 780 - pełne keplery poza brakiem HyperQ, który jest tylko w teslach) - taki Titan ma wydajność K20X, a 780 ma wydajność marginalnie niższą niż*K20 (Titan dodatkowo jest tak samo wydajny w podwójnej precyzji co Tesla (780 jest dużo słabszy), ale akurat w renderingu podwójnej precyzji się nie wykorzystuje więc to żadna różnica)... ważne, żeby to były pełne keplery czyli takie z CUDA 3.5, a nie z 3.0, bo ta różnica to Dynamic parallelism czyli bardzo ważna rzecz dla wydajności, łatwości pisania rendererów (rekurencja której wszystkim brakowało) i dla przyszłości, bo przykładowo do wsparcia OpenCL 2.0 wymagane jest wsparcie Dynamic parallelism. GeForce z Keplerami innymi niż Titan i 780 można olać i już lepiej kupić Fermi jak 580.

Jeśli zadasz konkretne pytanie to jak najbardziej... ale chyba lepszym miejscem będzie PM.

Z tego co wiem to UE4 posiada implementację https://research.nvidia.com/sites/default/files/publications/GIVoxels-pg2011-authors.pdf OFC w wielu grach na konsolach będzie wyłączone, a i pewnie na PC nie we wszystkich grach będzie ten efekt dostępny (zależy od targetu), ale w silniku jest to zaimplementowane. Co do GI w Realtime to jest jeszcze SSDO, którego wydajność jest tylko niewiele niższa niż SSAO, ale jakość efektu (podobnie jak SSAO vs AO) pozostawia wiele do życzenia http://www.mpi-inf.mpg.de/~ritschel/Papers/SSDO.pdf. Jednak właśnie ze względu na wydajność jest też zaimplementowany przykładowo w CryEngine3 obok Light Propagation Volume (jako GI dla konsol i słabszego sprzętu). Chciałeś chyba napisać adaptatywną (słowo aktywna jest tu śmieszne), a nie ma w takiej nic bardziej prawdziwego od statycznej. Praktycznie w każdej grze DX11 jeśli masz tessellację to masz adaptywną względem odległości siatki od kamery (nawet te najstarsze gry DX11 jak Alien vs Predator - tak samo jak na podanym przez Ciebie filmiku). Tym się właśnie różni DX11/OpenGL4 od OpenGL 1.x. Tessellacja sprzętowa jest z nami od 2001 roku od kart Radeon 8500 jako rozszerzenie do OpenGL 1.4. Niewiele gier z TruForm korzystało właśnie dlatego, że nie było mowy o wpływie na poziom tessellacji już po Vertex Shaderze (tessellacja była robiona przed VS i nie mogło się obliczyć odległości trójkąta od kamery i nie można było ingerować w tessellacje poza definiowaniem z programu (nie shadera) poziomu tessellacji). DX10/GL4 własnie tym się różnią, że tessellacja jest po VS i przed GS i można nią sterować z poziomu shadera (dzięki czemu adaptywna tessellacja jest naturalna i nikt się nie chwali jej implementacją - ja ją napisałem w swoim silniku w godzinę).

W rendererach GPU praktycznie zawsze jest tak, że część robi CPU (to co szybciej robi się na CPU), a część na GPU (to co szybciej na GPU). W wypadku LuxRender CPU i GPU robią dokładnie to samo (ten sam kod jest wykonywany na CPU i GPU, tylko dla innych fragmentów ekranu) - czyli zamiast się podzielić rozsądnie pracą co kto ma robić, to jest wepchane wszystko na wszystko i nie działa dobrze ani na CPU, ani na GPU (po prostu w LuxRender skorzystali z tego, że raz napisany kod OpenCL działa na wszystkim i można odpalić nawet na karcie dźwiękowej obliczenia, zapominając o olbrzymich różnicach architektury i konieczności pisania zupełnie innego kodu na CPU i GPU).