Skoti

Wskaźnik animacji nie można olać, bo jeśli silnik wczytał to jako plik z animacją to może mieć to znaczny wpływ - w najlepszym wypadku dorzucił do renderingu dane w wielkości tego co zajmują pozycje + normalne + uv (indexy i wagi dla kości jeśli w silniku jest ograniczenie dla grafików - max 4x kości wpływające na wierzchołek)... w gorszym przypadku uznał to za animacje morph, zamiast szkieletową i aktualizuje wierzchołki i przesyła całą siatkę co klatkę (wymuszenie VBO w trybie strumienia). Nie znam tego silnika, i dziwne to ograniczenie (może takie tylko w wersji free?), ale nie powinno mieć ono wpływu na rodzaj VBO. Nie powiem Ci też po której stronie leży wina, bo nie znam silnika, ani tego co zrobiłeś (jednak sądząc po dziwnych różnicach na screenach, obstawiałbym winę użytkownika). Tu jestem w szoku, bo pokazałeś, że nie masz pojęcia albo czym są hard-edge, albo czym jest AA (anti-aliasing)... jedno z drugim nie ma zupełnie nic wspólnego a problem aliasingu dotyczy renderingu zarówno soft jak i hard (a nawet grafiki 2d). Anti-aliasing to metody (nie tylko w grafice, ale też np. dźwięku i innych dziedzinach), które pozwalają radzić sobie z niskim próbkowaniem sygnału analogowego (np. ilość próbek na sekundę w dźwięku (analogową falę dzwiękową trzeba przedstawiać za pomocą próbek - w tej chwili miała fala wartość x, a 1/200 sec później miała wartość y (co się działo pomiędzy nie ma nikt pojęcia)), czy ilość pikseli na ekranie (piksele to zbiór prostokątów za pomocą których trzeba przedstawić dane, które niekoniecznie do pikseli pasują - bo np. pół piksela powinno być białe, a pół czarne (jednak w miejscu próbkowania było czarne i cały prostokąt jest czarny))). W grafice komputerowej jest problem z tym, że piksel może być jednokolorowy i powstają schody próbkowania: AA jest po to, żeby wyeliminować te schody (poprzez np. renderowanie do 4x większego obrazu i skalowanie w dół (supersampling - dzięki temu na faktyczny jeden piksel jest 4 próbki), lub renderowane jest z wielokrotnym próbkowaniem (piksel przechowuje wartości kilku/kilkunastu próbek, i później jest to uśredniane (MSAA))). Poza tym, że nie ma to wielkiego sensu poza zmniejszeniem wydajności (znacznie więcej trójkątów (ściana z 2 tri robi się ścianą z 18 tri)) to spoko pomysł ;p

Działa prawie wszystkim użytkownikom w miarę nowych wersji przeglądarek Safari, Chrome czy Firefox (Opera jest tylko testowa wersja) - prawie, bo użytkownicy Firefox pod linuksem którzy nie mają kart nvidii mogą narzekać (Mozilla nie ma doświadczenia w pisaniu w OpenGL i nie zna specyfiki niektórych sterowników jak Amd czy Intel (z tego powodu pod windowsem nie korzysta z OpenGL, tylko z DirectX), ale te osoby zawsze mogą się przerzucić na Chrome jeśli są mozillą zawiedzeni). Microsoft nie robi tu nic złego - tu liczą się zyski. Musi promować swoje Api, bo promowanie otwartego standardu, to dla firmy straty (łatwiejsze przenoszenie na systemy konkurencyjne, mogłoby zupełnie odmienić sytuację rynkową, tym bardziej, że producenci jak Nvidia, AMD czy Intel ostatnio bardzo wspierają konkurencję i coraz bardziej od MS się odwracają). Sytuacja jest krępująca dla samego MS, bo np. w mobilnym systemie aż prosi się, żeby MS promował OpenGL, żeby łatwiej można było portować z iOS i Android... ale ta decyzja, oznaczałaby straty, i zyski dla konkurencji jak Sony (w konsolach stosuje OpenGL ES) czy Apple, a zmniejsza znaczenie DirectX i platform go wykorzystujących (xbox/windows). Ciężko winić tu ich za niechęć do konkurencji dla DX, bo DX jest tak naprawdę największym atutem tej firmy.

Wykradanie screenshota jest możliwe tylko w implementacji mozilli pod Windowsem (która jest dosyć specyficzna, bo WebGL, nie jest realizowany przez sterowniki OpenGL czy OpenGL ES, na których się opiera, a na DirectX) i nie jest to problem WebGL, a Mozilli i ich implementacji. Konkluzja jest trafna, tylko odnosi się również do flash czy silverlight. Z pewnością, bo pewne jest, że do tego czasu HTML5 nie powstanie (teraz mamy tylko wstępne szkice specyfikacji, która wiadomo, że nie pojawi się w tym dziesięcioleciu), a WebGL działa na HTML5 Canvas, więc ciężko, żeby była gotowa przed nim. Autodesk z tego co wiem (http://www.khronos.org/members/contributors) nie jest członkiem Khronos Group i nie ma żadnego prawa głosu, nie współtworzy specyfikacji, ani nawet nie ma do niej wcześniejszego dostępu. Dodatkowo Autodesku nie interesuje się WebGL czy OpenGL ES, a raczej inne specyfikacje jak OpenGL (renderer w 3ds Max, Maya, Softimage...), OpenCL (do uniwersalnego obliczania danych) czy nawet Collada (format do wymiany danych między aplikacjami), a WebGL interesuje ich tak bardzo jak OpenSL ES (Api dźwięku dla m.in. telefonów komórkowych), czyli mogłoby dla nich nie istnieć. W3C nie ma nic do powiedzenia - oni robią HTML5, a WebGL jest zupełnie odrębnym tworem korzystającym z HTML5 Canvas. Sam WebGL jest kształtowany przez Google, Apple, Mozilla, Opera, Nvidia, Amd, Intel (czyli wszyscy Ci, których interes leży po przeciwnej stronie bieguna w stosunku do interesu Microsoftu (dla którego standardy, są złem, bo tylko promowanie czegoś Microsoft-only pozwala zachować i zwiększać udziały w rynku (jeśli strony będą używały silverlight 3d to ludzie będą kupować telefony/tablety z produktami Microsoftu, bo nie będzie wyjścia - jeśli WebGL to urządzenia z Androidem czy iOS mają duży plus))).

@ola-f: nie pleć bzdur - Microsoft robi FUD, bo WebGL mu nie na rękę i jednocześnie wprowadza swoje rozwiązanie (Silverlight 3D z dokładnie tym samym problemem bezpieczeństwa - ten sam problem dotyczy 3D w Adobe Flash). //Ogólnie głównym problemem jest to, że niedobre strony internetowe mogą Ci zawiesić komputer, bo mają niskopoziomowy dostęp do sprzętu (tak jak w nowym Silverlight tylko tam przez DirectX), i np. za dużo operacji na GPU (shadery) mogą zawiesić kompa - najśmieszniejsze jest to, że np. Mozilla która ma największe kłopoty z bezpieczeństwem WebGL... to wrapper na DirectX (pod windowsem). A i problem nie leży w błędzie konstrukcyjnym WebGL, ale nieprzystosowaniu sterowników kart graficznych do problemów z sieci i dotyczy się to każdego 3D znanego z internetu (również przez stare jak świat aplety Java wykorzystujące OpenGL (JOGL)). PS. jeśli zachwycacie się wydajnością to nie ma za bardzo czym - taka jest bo tam nie ma siatki - są tylko proste prymitywy, którym liczy się łatwo przecięcia z promieniem i to jest ich bardzo mało (w wypadku dużej ilości siatki, wydajność spadnie bardzo znacząco). BTW. czas wysypu takich sieciowych rendererów będzie za jakiś czas dopiero (jak w przeglądarkach będzie się pojawiać WebCL, a nie WebGL ;p).

Dziwne są różnice w tym porównaniu (animacje, ilość vbo, rozdzielczość), ale najdziwniejsze jest wykorzystanie pamięci karty graficznej (VRAM - Video RAM), bo są to za niskie wartości i ledwo pokrywają wielkość tekstur - oznacza to, że nie masz statycznego VBO z danymi na karcie, tylko przesyłane są co klatkę (co tłumaczy niską wydajność (bez żadnych shaderów postprocess jest to śmieszna wydajność), oraz duże różnice w wydajności (tak to są duże, bo nie powinno być żadnej różnicy)). Co do ogromnego wpływu na naturalny wygląd to zrób ściany budynku bez hard edge to zobaczysz jak nienaturalne są softedge - ogólnie radzę po prostu używać takich normalnych jakie pasują modelowi, a nie przejmować się wielkością zajmowaną w pamięci (bo różnicy w wydajności nie ma).

Będzie się rysował 2x dłużej (2-sided to po prostu 2 osobne wielokąty, rysowane przez kartę zamiast jednego). Dla karty graficznej i silników nie istnieje coś takiego jak otwarta bryła czy zamknięta - są po prostu trójkąty, a jak one są poskładane to już nie jest ważne. Praktycznie nieistotne, nawet ze względu na zajmowaną pamięć (a na to praktycznie jedynie ma wpływ), bo siatka zajmuje względnie mało pamięci. Załóżmy, bardzo pesymistyczny skrajny przypadek - na scenie masz 1 milion tri przy założeniu, że nie masz, żadnego powtażalnego obiektu (instancingu brak), każdy tri ma 3 wierzchołki, gdzie żaden wierzchołek się nie pokrywa z innym, więc każdy wierzchołek zajmuje po 32 bajty (3x norm, 3x pos, 2x uv pomnorzone przez 4 bajty na liczbę zmiennoprzecinkową) co daje nam 91 MB na siatkę, przy ekstremalnych warunkach (czyli cała siatka na całą scenę, bez instancingu, przy bardzo pesymistycznych założeniach - tyle co kilka tekstur (bo na karcie nie mają rozmiaru jak JPG, bo są trzymane bez kompresji (tak jak w BMP)), i dużo mniej niż zjedzą same efekty postprocess). A spokojnie możesz założyć, że z 10% sceny to instancing, a kolejne 50% wierzchołków będzie jednak zaoszczędzone, bo będą miały takie same wartości, to ostatecznie siatka będzie zajmować śmiesznie mało miejsca. Jest ich mało, bo są problematyczne - problemem jest sortowanie obiektów (im więcej tym dłużej się je sortuje i tym gorsza wydajność), problemem jest renderowanie półprzezroczystych obiektów gdzie widać ścianki obiektu przez inne ścianki tego samego obiektu (bo każdy trójkąt musi być posortowany - w przeciwnym wypadku zrobi się sieczka - stosuje się tu dual depth peeling (wolne), czy weighted average (szybki, ale niezbyt fajny, wizualnie bo nie jesteś w stanie, określić co jest przed/za)), a na końcu problemem jest chęć wykorzystania wielu świateł w oświetleniu scen (deferred shading czyli liczenie oświetlenia postprocess - dlatego nie można obliczyć oświetlenia obiektów widzianych przez przezroczyste obiekty, bo nie ma dla nich danych (pozycji, normalnych, itp, a są tylko dla powierzchni obiektu przezroczystego)). Przezroczystych obiektów w grach jest mało, bo jest z nimi wiele kłopotów i wystrzega się ich jak ognia ;p.

@Gordy: projekt który podałeś, podobnie jak http://www.nvidia.com/object/optix.html to projekty przeznaczone nie dla grafików, a dla programistów (aby wykorzystali ich biblioteki w programach, bo one wymuszą na grafikach kupienie ich sprzętu do renderingu)... jednak mało którego programistę te biblioteki obchodzą, bo poza dobrym PR i prezentacjach na klastrach ze sprzętem hiend, nic nie wprowadzają nowego (poza tym, że są ubogie w featury i po ich dodaniu, nie będzie wcale szybszy od obecnych na rynku rozwiązań).

Myślę, ze kazdy grafik robiacy modele do gamedev wie, ze nie sa wazne poly/wierzcholki jakie mu pokazuje max, tylko to co dostaje karta, a ta przy rasteryzacji przetwarza n poly po 3 wierzcholki - co najwyzej mozna zaoszczedzic na przesyle danych (przy statychnych vbo w praktyce zyskujesz czas ladowania modeli tylko) i wysylać mniej wiercholków, jesli na kilku face wierzcholek ma takie same normalne, uv, pozycje... ale to nie zmienia tego, ze karta bedzie przetwarzać n triangle i 3*n vertexow - po prostu zaleznie od tego na ilu poly bedziesz mial dokladnie takie same wiercholki, tyle zaoszczedzisz na przesyle.

Vertex Buffer Objects (VBO) są w OpenGL Core od 1.5 (2003 - już jako nie rozszerzenie, a część specyfikacji) - rozszerzeniem VBO było, ale przed OpenGL 1.5. Teraz VBO to dalej świetne rozwiązanie (chociażby (pomijając względy wydajnościowe) ze względu na powszechność i dostępność od telefonów z OpenGL ES 1.0, 1.1, 2.0 przez OpenGL 1.5+ na PC, po WebGL w grafice 3d w przeglądarkach), dopóki bindless graphics nie będzie tylko rozszerzeniem jednego producenta, ale nowinką to tego nazwać nie można. Co do wersji 3.0 to od tej wersji w specyfikacji mamy VAO (w OpenGL 2.1 jest jako rozszerzenie), a w OpenGL 3.1 mamy UBO (jako rozszerzenie od 2.1). W 3.x też jeszcze jedna fajna rzecz doszła - wywalenie wszystkiego co nie jest związane z VBO (bezpośrednie dostarczanie wierzchołków, czy displacelisty) co ujednoliciło trochę tą sprawę (zostało tylko VA, które jest wykorzystywane przy VBO, które znowu jest wykorzystywane przy VAO... ;p). To już zależy od tego na jakiej karcie testowałeś i od tego jak displayliste optymalizowały sterowniki - w najgorszym wypadku powinny być tak wolne jak VA (dynamiczne VBO). W teorii tak, w praktyce dynamiczne VBO działają tak samo wolno jak VA (przez dynamiczne mówię o streamach, bo nie widzę wielkiego zastosowania dla VBO dynamicznych (czyli aktualizowanych raz na N klatek, a nie co klatkę (stosuje się jeszcze, chociaż jest to rzadkość np. do systemów cząsteczkowych) lub statyczne z animacja szkieletową). Ogólnie dziś mało kto robi VBO dynamiczne lub stream, bo po co tracić czas CPU i przesyłać dane skoro, na karcie graficznej będzie szybciej i nie trzeba przesyłać prawie nic.

Sorry, że odkopuję po kilkunastu dniach, ale dopiero teraz zobaczyłem wątek i chciałem kilka rzeczy sprostować. Ilość wierzchołków i poligonów jest ściśle od siebie zależna i bez sensu jest pisać jako osobne rzeczy, ilość drawcalli jest ważna (tym bardziej w Dx który na ich ilość jest szczególnie uczulony, ze względu na duże narzuty funkcji) i zależy równie bardzo od grafika jak i programisty, jednak fillrate niewiele ma tu do powiedzenia - nawet jeśli mamy olbrzymie ilości geometrii i są one wrzucane wszystkie do GPU jako double side, to i tak powycina je test głębokości, więc fillrate nie będzie zagrożony - fillrate powinien przejmować się raczej programista, bo tu problemem są już piksele, a nie wierzchołki, więc rozdzielczość, AA, shadery postprocess czy nawet shadowmapping - sam model nie ma wielkiego znaczenia dla fillrate. Nie ładnie używać terminów OpenGL (VBO) przy mówiąc do programisty DirectX (tam po prostu jest VB) ;p. Poza tym nie do końca tak łatwo możesz sobie połączyć wszystko, bo jeśli siatka jest w osobnych obiektach to zapewne i tekstur jest kilka - więc musisz dodatkowo dodać kolejne atrybuty dla siatki z indeksami i przesyłać do GPU tablice tekstur, co też nie jest takie proste na sprzęcie Dx9, bo np. w OpenGL Texture arrays pojawiły się w wersji 3.0 na sprzęcie Dx10+. Dodatkowo to z tym morzeniem przez macierz transformacji, żeby coś ukryć jest trochę bez sensu - lepiej po prostu wtedy rozwalić rysowanie na 2 drawcalle za pomocą glDrawRangeElements. Po pierwsze dynamiczne VBO to zło - robi Ci z VBO zwykłe stare VA, i co klatkę musiałbyś mapować dane, modyfikować i przesyłać do karty tonę wierzchołków. Dla trawy lepiej przesyłać punkty, robić bilbordy w GS, a animacje obliczać na GPU z np. wektora wiatru + tekstury szumu lub w jakiś inny sposób (jak np. w Fifa gdzie jest po prostu robione kika shelli boiska w GS i powstaje ładny shader futra udający trawe ;p)... dla całej reszty animacja szkieletowa na GPU. VBO nowe? Przecierz to jest staroć. W standardzie OpenGL 1.5 od 2003 roku, a wcześniej jeszcze jako rozszerzenie funkcjonowały. W tej chwili masz nowości w postacji VAO (tablica z kilkoma VBO rysowana jednym drawcallem (ale jeszcze sterowniki są słabe i jest dzięki temu spadek wydajności zamiast wzrostu)), UBO czy Bindless Graphics od Nvidii (tylko u nich puki co jako rozszerzenie OpenGL http://developer.nvidia.com/content/bindless-graphics). Nie wiem co w tym trudnego przed VBO - wrzucić wszystko do jednej tablicy/listy wyświetlania i zrobić jeden Draw Call (VA działają jak VBO dynamiczne, a listy wyświetlania są szybsze)? Ja wiem, że można nie lubić przesyłać danych na kartę graficzną, ale żeby tak od razu zabijać procesor ;p? Przy dużej liczbie animowanych obiektów to zabije procesor (bo przemnorzenie milionów wierzchołków przez macierze (każdy przez kilka macierzy) to dla procka nie jest sekunda roboty ;p). W dzisiejszych grach animacja szkieletowa jest robiona na CPU, ale przemnażanie siatki odbywa się już na GPU. Po prostu dodajesz do siatki dwa nowe atrybuty vec4 i jeden to 4x kości wpływające na wierzchołek, drugi to wagi dla tych kości. Macierze transformacji kości obliczasz na CPU dla danej klatki (i masz np. kilkanaście macierzy 4x4 lub 3x3 jeśli chcesz mieć tylko rotacje) - te macierze przesyłasz jako Uniform do karty graficznej, a przemarzaniem wierzchołków przez kości zajmujesz się już w VS (ofc cała siatka jest przesyłana raz bo wystarczy statyczne VBO, bo siatka zmienia się dopiero na karcie, a nie na CPU). Nie - chodzi o wywołanie metody rysującej w Api (np DirectX/OpenGL), która przygotowuje dane i przesyła do command buffora - DrawCalle zabijają procek, bo funkcje rysujące mają spory narzut w Dx (w OpenGL jest znacznie mniejszy narzut, w Dx9 jest większy, ale dopuszczalny, w Dx10 tak im się rozrosły funkcje, że ilość DrawCalli dla tego Api jest kluczowa, a w Dx11 starają się naprawić problem z Dx10 i jest możliwość wielowątkowego przetwarzania drawcalli i dostarczania do command buffora (przez co jest mniej wrażliwy na DC, bo podczas gdy jeden rdzeń czeka na powrót do kodu z DC, inny już robi kolejnego DC)). Pętle nic tu nie zmieniają - w draw callach chodzi o czas jaki procesor spędzi w metodzie Draw, a spędzi go mniej jeśli wykona się tylko raz, niż jeśli w pętli po kolei wykonasz np. 40x razy. Metoda Draw którą ty wykonujesz na obiekcie to tylko interface, a ile jest podczas wywołania takiej metody faktycznych DrawCalli dowiesz się tylko czytając implementacji klasy (bo z Twoich słów wynika, że używasz jakiejś gotowej implementacji FBX dla .NET i nie masz bezpośredniego wpływu na DC) Sprzęt mobilny wcale nie jest taki zły i wiele procków mobilnych pozwala na rendering około 40 milionów polygonów na sekundę (co przy FPS 30 daje 1.3 MPoly na klatkę co jest niezłym osiągnięciem) - ofc jeśli się optymalnie wykorzysta sprzęt i nie będzie się nadużywać DrawCalli (co nawet przy dużych staraniach nie jest łatwe). Największy wpływ na mobilne gpu mają operację na teksturach - przez co za wielu efektów postprocess (DoF/HDR/SSAO/Deferred shading/AA/MB/... i innych, które zabiją fillrate) nie użyjesz.

Wszystko co da się zrobić na kostkach można wypalić na animacje i klucze w IPO. Tu da się zrobić wszystko na kostkach, ale po szczegóły udaj się tak jak napisał Szczuro na troman.pl. Cały silnik fizyki Bullet łatwiej kontrolować z poziomu pythona i można go precyzyjniej ustawiać, jednak chyba nie ma sensu skoro masz sensor Collision i actuator Visibility (więcej tu nie potrzebujesz ;p).

Mogę się zapytać jaki jest ten laptop? Od 4 lat nawet GPU Intela obsługują OpenGL 2.x (problematyczne są GPU na netbooki - na windowsie mają stery tylko OpenGL 1.5, a na Linuksie OpenGL 2.0). PS. Użyj Firefox 4 (używa on Dx9 do WebGL (tłumaczy WebGL na Dx pod Windowsem (ze względu właśnie na sterowniki Intela, i niektóre błędy w sterach OpenGL AMD - pod Linuksem za to WebGL ograniczają do kart Nvidii, a innych olewa dopóki nie poprawią sterów))).

Miło z ich strony (jednak to nie załatwia sprawy innych urządzeń (a sam iPad w tamtym roku zagarnął 10% rynku mobilnego (laptopy/netbooki/tablety), więc ciężko dziś olać przy tworzeniu stron urządzenia które, z zerowego udziału szturmem zdobywają rynek, a są w bardzo dużym stopniu przeznaczone, do przeglądania internetu)). To podchwytliwe pytanie? Unity w założeniu jest silnikiem gier, ale jeśli chcesz mieć gdzieś to zapisane to cytuję stronę http://unity3d.com/unity/ "Unity 3 is a game development tool that has been designed to let you focus on creating amazing games" OFC da się go wykorzystać w innych celach (jak inne silniki gier, w bardzo różnych zastosowaniach, nawet milotarnych), ale to nie zmienia, że celem jego powstania i rozwoju jest tworzenie gier. Zależy co chcesz przedstawić - samochody/telefony itd na stronach producentów będą za niedługo wykorzystywać silniki WebGL (bo tam ważne jest, żeby wszystko działało). Ourbricks to nie jest puki co coś do przedstawiania modeli dla klientów końcowych (do pokazania siatki na forum się nadaje), ale silniki renderujące za niedługo powstaną renderujące dobrą jakość. Do zrobienia stron musisz ściągnąć SDK (silnik i toole), do uruchomienia musisz ściągnąć silnik który jest elementem pluginu (unity web player) - tak jak w wypadku gry quake live (z tym ze tu plugin to cała gra razem z assetami, a tylko rendering zamiast do okna jest podpięty do obiektu w przeglądarce). Ogólnie pluginy robi się do takich rzeczy w ten sposób, że silnik kompiluje się do biblioteki współdzielonej (takie dll/so), i dodaje się funkcje API zdefiniowane przez przeglądarkę (i dostajemy silnik w pluginie). Jeśli nie chcesz instalować dodatkowych pluginów, to trzeba silnik napisać w JS - ewentualnie część w przyszłości w języku kerneli OpenCL (język zbliżony do C, jednak w tak jak shadery OpenGL jest on kompilowany przy uruchomieniu przez sterowniki (stery nvidii skompilują pod kartę nvidii, a stery intela pod procek intela)) które może działać na CPU (niezależnie od architektury czyli ARM/PPC/x86 - razem z wykorzystaniem wektorowych rozszerzeń jak NEON/SPU/SSE), GPU (nie ważne czy AMD, Nvidia czy Intel) i wielu innych urządzeniach (możliwe teoretycznie jest na kartach dźwiękowych z DSP)). Będzie to za niedługo możliwe dzięki, bo przygotowywany jest WebCL.

Modele low-poly bo takie mieli to wrzucili, grafik tu nie widzi ani przez chwilę kodu - to nie jest coś do tworzenia gier czy tego typu zadań - po prostu do pokazania w sieci modelu (robisz upload modelu i możesz pokazać np. na Max3D). Co do samego WebGL to żaden grafik nie będzie w nim pisał - w przyszłości powstaną silniki 3D (możliwe, że nawet Unity będzie miał wersję na WebGL (bo większość shaderów w OpenGL ES 2.0 (używany w WebGL, a w Unity na np. tabletach/telefonach Apple czy z Androidem (na obie platformy jest Unity (podobnie jak UE3))), i tu nie jest problem (problemem jest ofc przeniesienie wszystkiego poza grafiką, i przepisywać z C++ używanego wszędzie do JS))). Na Outbricks nie ma pewnie dostępu do oświetlenia (bo nie kwalifikuje się to do prosta prezentacja), ale jeśli będą chcieli zrobić w przyszłości coś więcej to nie ma problemu, tylko muszą lepsze shadery napisać (zrobić Deferred Shading i tyle). Co do unity3d web player to ma on olbrzymią wadę - działa na ograniczonej ilości konfiguracji - działa tylko i wyłącznie na Windows i MacOS, wymagając ściągnięcia i zainstalowania silnika (nie działa na Linuksie, czy bardzo popularnych ostatnio do przeglądania internetu tabletach i telefonach (Apple i Google zapowiadają wsparcie dla WebGL w tych urządzeniach)), więc w wielu zastosowaniach odpada (dlatego chcą powiększyć zasięg eksportując do flasha (czyli Linux + tablety/telefony z Androidem - dla produktów Apple które są bardzo popularne, 3d na stronach będzie tylko za pomocą WebGL i silników w nim napisanych (Apple nie pozwala instalować pluginów))). Nie wiem po co się tak rozpisujesz - od zwykły silnik gier, na wiele platform.

W niektórych zadaniach jest trudniej wykorzystać GPU, w innych znacznie łatwiej (chociażby liniowe algorytmy, gdzie trzeba wykonywać wiele razy te same obliczenia (np. łamanie haseł aż nieprzyzwoicie dobrze się pisze na GPU ;p)). OFC to jest inny sprzęt i kod jest trochę inny, ale akurat w wypadku fluidów i innych takich obliczeń kod na GPU wcale nie jest bardziej skomplikowany (jedynie trochę inaczej skonstruowany). Tak - RBD to najtrudniejsza sprawa dla GPU z fizyki, i PhysX też akcelerował do niedawna wszystko poza Rigid Body (do niedawna bo już mają wydajny GPU Rigid Body w PhysX i był już on wykorzystany w Batman: Arkham Asylum). Nie wiem czy wykorzystanie algorytmu pisanego specjalnie dla CPU z SSE, AltiVec, SPE to stawanie na rzęsach i wykorzystywanego przez renderery liczące na CPU jak i programy graficzne (np. blender 2.5 poza rendererem, korzysta z tej struktury m.in przy sculpcie). To jest po prostu wybranie najlepszego algorytmu do architektury GPU (która z SIMD takimi jak SSE/SPU/AltiVec ma bardzo wiele wspólnego) i osobiście nie widzę tu stawania na rzęsach (w wypadku CPU szybszą alternatywą jest np. Kd-Tree, które nie nadaje się do dynamicznych scen bo trzeba przebudowywać drzewo co klatkę (BVH jak coś się rusza to po prostu powiększysz tylko bound volume i jest (a co ileś tam klatek można sobie pozwolić na optymalizacje drzewa - nie przebudowę tylko optymalizacje - przerzucić jeden obiekt do innej gałęzi i reszty nie ruszać)... do fizyki QBVH po prostu jest najlepszym wyborem niezależnie czy to procek czy karta graficzna)).

Kto tu kogo nie czyta: Liczenie na GPU jest super dla SoftBody, Fluidów..., a z bryłami sztywnymi jest największy problem - jednak już kilka lat temu wydanie w Bullet wykrywania kolizji w CUDA pokazało, że zrobili to na GPU stabilniej i wydajniej niż na CPU (a od tego czasu GPU sporo przyspieszyły). PS. QBVH nie jest drzewem binarnym (na co sama nazwa wskazuje). Ta tylko wtedy nie mówimy o integracji silnika fizyki (tak jak w wypadku właśnie Momentum), ale o jego modyfikacji, bo bez zmian w silniku (tak jak tu, blenderze, cinema, dynamica...) robiąc tylko integrację komunikując się z implementacją silnika za pomocą jego API symulacja jest zawsze taka sama. Nie liczy się liniowa wydajność (chociaż nie wiem czy do końca rozumiem co chcesz przez to powiedzieć - chodzi Ci o złożoność?) - liczy się jak najmniejsza złożoność algorytmu i właśnie najlepiej aby nie była liniowa - liniowy czas (lepszy tylko od wykładniczego czasu) to słaby algorytm dużo fajniejsze są w czasie logarytmicznym lub stałym (podobno fajne SB w o złożoności O(1) jest Fast Lattice Shape Matching ale się nim nie interesowałem głębiej i nie wiem czy ten czas podawany przez nich jest faktycznym czasem czy czasem w specyficznych warunkach).

Karty graficzne są przystosowane do obliczeń wektorów 4x elementowych i macierzy 4x4 elementowych (w praktyce tylko tym się zajmują - operacjami na wektorach pozycji, normalnej, tangent, binormal, padania światła, kamery, koloru... i macierzy 4x4 transformacji, projekcji, widoku, tekstur, kości...). OFC to nie jest to gwarantem, bo w wypadku jeśli będziemy mieli pesymistyczny kod z obliczaniem wektorów to np. z 1536 rdzeni 6970 będzie działało 96 (w wypadku obliczeń na pojedynczych liczbach w pesymistycznym wypadku będzie to jednak tylko 24) - na GeForce GTX 580 z 512 rdzeni w pesymistycznym wypadku będzie działać w obliczeniach na wektorach 4x elementowych 128 rdzeni (w wypadku danych niewektorowych pesymistyczny wypadek dla tej karty to 32 rdzenie) - lepsze wyniki niż AMD mimo mniejszej całkowitej liczby rdzeni zapewnia sobie mniejszymi SIMD i Dual Warp w nich. Co do gwiazdki to od tego są właśnie struktury danych jak QBVH (Q od quad, bo zarówno 4x jest optymalnym rozwiązaniem dla kart graficznych i SSE/SPE), które jest np. wykorzystywane przy renderingu na GPU (np. Octane) - pozwala na organizację danych, dzięki której wiesz co jest blisko, a co daleko obiektu, a nie musisz sprawdzać wielu ze sobą, więc taka cząsteczka oddalona o 5m nie będzie nawet sprawdzana, bo będzie za daleko w drzewie akceleracyjnym. Nie przyglądałem się algorytmom w branchu Bullet OpenCL, ale nazwa Hier3dGridBroadphase sugeruje, że używają właśnie BVH w jakiejś odmianie. Nie porównuję ODE/XSI z ODE/Houdini - tylko ODE/Houdini z ODE ;]. Ode zachowa się tak samo w każdej aplikacji, chyba, że to nie jest czysty ODE, a zmodyfikowany kod tylko pod daną aplikację (jednak wtedy nie ma mowy o integracji z silnikiem X, a o integracji z silnikiem Y opartym o X). Co do solvera to podaj link, to jak będę miał trochę wolnego czasu to chętnie zobaczę. "tak samo szybki lub wolny, bez względu na to, czy liczymy go na CPU czy GPU, czy liczy gęstą siatkę czy rzadką" Napisałeś to, a jest odwrotnie - Algorytm nie jest tak samo szybki dla różnych danych - algorytm dla jednych danych jest najszybszy, a dla innych może być najwolniejszym algorytmem - Chyba, że pisząc to miałeś na myśli to co napisałem, ale niezbyt jasno to przekazałeś. Co w jednych zastosowaniach jest wadą w innych jest zaletą - algorytmy dokładniejsze są zaletą w filmach gdzie nie za wiele jest SB i można się pobawić jakością symulacji - w wypadku kiedy mamy na scenie za dużo SB, aby mówić o rozsądnym czasie liczenia za pomocą dokładniejszych algorytmów, prosta symulacja w Bullet okazuje się świetnym rozwiązaniem i wystarczająco realistycznym. To tak jak z renderami MLT - wszyscy wiemy, że jakość symulacji oświetlenia świetna, ale nikt by ich nie użył do animacji ;].

Akurat fizyka jest już z założenia przystosowana do obliczeń na GPU (bo z założenia działa na wektorach (czyli tak jak SSE w x86 czy SPU w PS3) i danych które idealnie pasują pod obliczenia równoległe). Ofc trzeba zrobić nowe wykrywanie kolizji które będzie jeszcze lepiej działać na GPU (w tej chwili Bullet ma 2x opcje różnych struktur i algorytmów wykrywania kolizji), a kod już po przepisaniu do OpenCL będzie ten sam dla CPU jak i GPU (intel i amd mają własne implementację OpenCL wykorzystujące SSE, a IBM ma implementację wykorzystującą SPE w Cell (odpowiednik SSE), czy ARM wykorzystujące NEON) - jedna implementacja załatwi już wtedy wszystkie możliwe urządzenia i platformy (liczy się tylko czy coś może liczyć). OFC zajmie to jeszcze trochę czasu (już od końca 2008 roku zaczynali i pewnie najwcześniej wydania pod koniec roku można się spodziewać), i nawet po wydaniu mogą być problemy z tym co dla CPU najłatwiejsze czyli z bryłami sztywnymi, ale idzie to w dobrym kierunku W Houdinim przy tych samych ustawieniach i identycznej scenie jak w ODE wynik symulacji jest zupełnie inny (ODE jest silnikiem deterministycznym i w tych samych warunkach dokładnie zawsze taki sam efekt jest uzyskiwany) - czyli jest inna fizyka brył sztywnych niż w ODE, a z czystego ODE zostało tylko wykrywanie kolizji - tu nie trzeba widzieć kodu, bo to widać po efektach. Wręcz przeciwnie - o ile algorytm może być bardzo szybki dla małej ilości danych, może być najwolniejszy dla dużej ilości danych (jeden wykonuje się w czasie 16*n, a drugi n^2 to dla danych od 1 do 4 algorytm drugi będzie szybszy, a dla większych danych pierwszy) - złożoność algorytmu wyznacza się dla n dążącego do nieskończoności, ale praktycznie zawsze dla małych danych wydajność wygląda inaczej. Podobnie jest z CPU/GPU - algorytm który nie można rozdzielić na wątki działa zawsze lepiej na CPU, algorytm który rozdziela się na wątki i każdy wątek robi to samo na innych danych działa lepiej na GPU, a algorytmy które są pomiędzy tym to zależy - algorytm nigdy nie jest tak samo szybki/wolny dla różnych warunków. Wiem, jednak opinia o stabilności danego silnika często bierze się nie z faktycznego stanu tylko z tego, czy ktoś potrafił wykorzystać silnik czy nie (bo można przedstawić, że silnik z założenia niestabilny jest stabilny jak ktoś go zna, jak i to, że Havok/PhysX/Bullet są niestabilne)... dlatego napisałem, że bywa niestabilny, bo opinii o stabilności animacji fizycznej nie powinno się kształtować w oparciu o filmiki promujące silnik (bo na nich będzie zawsze silnik stabilny, nawet jeśli w praktyce, jest to bardzo trudne do uzyskania).

Nie wiem jak wygląda do z Syflex, ale w wypadku ODE to mylisz silnik fizyki, a wykorzystanie części do budowania własnego - ODE to tylko silnik brył sztywnych, a w Houdinim nawet tego nie wykorzystali (jedyne co użyli z tego co pamiętam to detekcji kolizji, a całą fizyką zajmuje się już ich silnik). Nie ruszali nic przy detekcji kolizji (sam bullet ma w sobie z tego co pamiętam 5 algorytmów (nawet więcej wliczając te bardziej egzotyczne jak detekcja kolizji przez CUDA) do wyboru tu i tu tylko sobie wybrali jeden), ani przy 2012 nie ruszali nic przy fizyce brył sztywnych (tam fizyka praktycznie w całości się na tym opierała), a dodali swoje własne relacje między obiektami - bo Bullet tu ma tylko najpopularniejsze zawiasy, suwaki, połączenia czy 6Dof, a tu potrzebowali czegoś więcej (czegoś co im by pewnie nie zapewnił żaden silnik out of box, a tu mieli dostęp do źródeł i łatwą możliwość dodania). Gdyby babcia miała wąsy... - mowa o tym algorytmie który był użyty. Ten algorytm nie bez powodu został przygotowany pod gry - w czasie dodawania wsparcia dla softbody twórca tego silnika pracował dla sony i DevKit konsoli Sony Playstation 3. Jasne jest, że im bardziej realistyczne algorytmy tym więcej czasu zajmuje obliczanie (gdyby chcieć zrobić fizykę SB realistyczną to najszybsze komputery swiata przez lata liczyłyby prostą scenę, ale nie o realistyczność tu chodzi, a o realizm/wydajność - a tu Bullet nie ma czego się wstydzić (przy gęstszej siatce, bo wtedy efekt wygląda lepiej niż przy tak rzadkiej, mimo, że o realizmie dalej nie można mówić)). Bullet jak i PhysX czy Havok bywa niestabilny - np. w wypadku bardzo rzadkiej siatki dużej siatki kolidującej z małą (np. jak zrobisz podłogę o 1km2 powierzchni złożoną z 1x quad lub 2x tri i postać gdzie kolidują jej stopy w normalnych rozmiarach, to przy poruszaniu się będzie widoczna niestabilność - rozwiązanie to gęstsza siatka podłogi, lub uznanie jej jako płaszczyznę i taki kształt zamiast siatki dać do obliczeń).

To nie jest nowa wersja silnika - to jest ten sam silnik który jest w Cinema 4D, LightWave 3D czy Blender standardowo, a w produkcjach Hollywoodzkich wykorzystywany przez m.in. Sony (np. 2012, Hancock), Disney (Bolt), Dreamworks (Megamind, Shrek 4), jak i filmach produkowanych przez innych (Sherlock Holmes). Disney jest autorem darmowych pluginów do Maya czy 3ds http://code.google.com/p/dynamica/ Implementacja fizyki wszędzie jest ta sama - różni się integracja, która daje do czegoś dostęp lub nie - jeśli daje to praktycznie takie same efekty uzyskasz wszędzie (mogą być minimalne różnicę polegające na innych ustawieniach domyślnych materiałów czy marginesu, ale przeważnie da się to ustawić ręcznie). Przeważnie różnicę wynikają raczej z różnicy wiedzy i umiejętności osób robiących demka. Nic dziwnego, że działa w RT bo tu nie ma za wiele do liczenia (siatki liczone do softbody są liczone dla rzadkich siatek, a później jest ona zagęszczana już po fizyce co widać na tych filmikach). Naprawdę szybka i wydajna fizyka dla ciał miękkich, ciuchów, deformowanych obiektów, fracturingu, fluidów będzie dopiero przy liczeniu na GPU z nadchodzącą wersją 3.0 silnika Bullet i liczenia w OpenCL (może liczyć na CPU ale i GPU niezależnie czy to GPU jest nvidii, amd czy intela). Teraz twórca Bullet pracuje dla AMD i AMD już zapowiedziało plugin do Maya wykorzystujący wersję OpenCL http://www.amd.com/us/press-releases/Pages/amd-plug-in-maya-gd-conf-2011mar02.aspx

"Niemal" jest tu trochę na wyrost - po pierwsze byłoby to znacznie wolniejsze ze względu na deferred shading (wiele świateł w takim demie wydajnie tylko tak da się uzyskać), a Dx9 ma ograniczenie ilości Multiple Render Target równą 4 co raczej nie wystarcza - więc zamiast raz renderować na raz w jednym shaderze do np. 6x tekstur i korzystać ze wspólnych obliczeń, w dx9 musisz renderować całą scenę 2x - 4 tekstury i później 2 tekstury na raz. Tu od Dx10 i OpenGL na zgodnych z Dx10 kartach można się pobawić, ale w Dx9 wydajność Ci spada. Takiego golema nie uzyskałbyś w Dx9 bo nie ma tam tesselacji jak w Dx11 i OpenGL 4. Symulacje dymu (np. papieros), fluidów, zniszczeń co prawda są możliwe w Dx9, ale za sprawą zewnętrznych API jak OpenCL czy CUDA (tu CUDA i wykorzystane PhysX), ale wydajność która do tych symulacji jest potrzebna wymaga bardzo mocnych kart. Co z tego, że da się zrobić tak samo wyglądający efekt w Dx9 skoro wydajność kart do takiego efektu wymagałaby kart które wyjdą za dwie generacje. Próbując uzyskać wydajność w Dx9 taką jak Dx11 uzyskałbyś zauważalnie gorszy efekt. Tu konsole nie ograniczają lecz wydajność (od zawsze - pamiętam jeszcze jak za czasów GeForce 2/3 pojawiały się dema programistów z efektami które były możliwe do zastosowania w grach dopiero przy GeForce 4/FX/6k i dopiero wtedy były w demach pokazywanych graczom, a nie wśród programistów - tak samo jest teraz... dziś są robione demka, które w grach wykorzystać będzie można dopiero za n lat).

@wenus525: XNA to tylko framework - bardziej zasadne byłoby porównanie .NET do Dalvik (bo XNA to framework działający w maszynie wirtualnej .NET), ale też nie widzę sensu takiego porównania, bo o ile w WP7 wymagane jest pisanie w .NET i XNA, aby można było łatwo pisać gry wieloplatformowe (Xbox Live Indie Games, Windows i WP7 uruchomią te same gry, bo nie są natywne tylko zajmuje się tym maszyna wirtualna), to Android nie wymaga korzystania z Dalvik - jest Android NDK do pisania natywnych programów w C++ (i zarówno Unreal Engine 3 jak i Unity wykorzystują to).

@regnar: nie obsługuje on siatki w uniwersalnych formatach tylko całą scenę ma zapisaną w lxs tworzonym przez eksportery/pluginy do programów http://www.luxrender.net/en_GB/plugins

A ja po raz kolejny zapytam czy naprawdę nie widzisz śmieszności tego co piszesz? Jak można w ogóle porównywać BGE na rynku silników do Blendera na rynku grafiki 3d? - Blender to potężne narzędzie nie ustępujące komercyjnym rozwiązaniom (w niektórych aspektach lepszy, w innych gorszy - po prostu równorzędny konkurent pod względem funkcjonalności) vs BGE, który ma 1/50 tego co powinien mieć silnik gier (49/50 musisz zrobić sam), a to co ma zrobione jest klasy komercyjnych silników 10 lat wstecz. - Blender jest darmowy, a 3ds/maya itd. nie kosztują mało, a oba mogą być do tych samych celów stosowane (niekomercyjnie i komercyjnie). BGE jest darmowy... ale w przeciwieństwie do rynku graficznego silniki też są darmowe jak UDK/Unity do tych samych zastosowań co BGE możesz użyć (niekomercyjne), a do reszty zastosowań jak komercyjne gry mimo, że nie są już darmowe i tak są dużo lepsze (bo bge wcale tu nie ma) Przekładając jednak na blendera to czy uważasz, że jeśli blender miałby małą część (bardzo małą część) możliwości takie jak inne programy 10 lat temu, a 3ds/maya/... byłyby za darmo do tych samych zastosowań (w tym wypadku zarówno komercyjnych jak i niekomercyjnych), to czy znalazłbyś jakikolwiek sens w rozwijaniu softu który przez tyle lat nie ruszył z miejsca, a masz darmowe odpowiedniki o lata świetlne przed nim? Zapewne, nawet byś o blenderze w takiej sytuacji nie usłyszał, ale byłbyś pewnie za zaniechaniem projektu i stworzeniem czegoś od zera (bo coś co tyle stało w bez ruchu, ciężko rozwijać i lepiej wszystko wyrzucić i zrobić od zera według nowoczesnych zasad i norm nowy projekt) lub nie chciałbyś rozwoju żadnego takiego programu, bo po co jak nikt tego nie będzie używał mając darmowe świetne rozwiązania, których przez kolejne 10 lat by nie dogonił. A tym bardziej byś go nie lubił, jeśli byłby częścią do programu którego używasz (jak, np. Gimp, OpenOffice Writer, Amarok, Winamp czy równie nie pasujących jak BGE do Blendera) spowalniając jego rozwój. Do takich zastosowań jak BGE, silniki komercyjne... są niekomercyjne i są nawet względem licencyjnym lepszą alternatywą, nie mówiąc o możliwościach. Taa to fajny przykład, bo to GUI powstaje od 9 miesięcy i dalej praktycznie nic nie potrafi (jedyne widgety to związane z tekstem, i obrazki - żadnych przycisków, check/radio boxów etc (już nie mówię o okienkach itd)). Jest to bardzo ciekawe, bo znam programistów amatorów, którzy od zera napisali gui w weekend z większością widgetów potrzebnych - bez scrollbarów i okienek - (jeśli napisanie gui tak idzie "szybko", to silnik może byłby zdatny do użytku za kilkaset lat ;]). Nie - brak sensu tworzą zerowe możliwości BGE i konkurencja która też za darmo jest lata świetlne przed nim.

Wolałbym jednak, żebyś skomentował, czy widzisz sens w tym, że stworzył grę w bge poświęcając na to nieporównywalnie więcej czasu, na stworzenie gui, wszystkich shaderów etc, skoro wszystko miałby out of box w takim udk (gdzie mógłby znaleźć wydawce, a nie liczyć na dotacje, bo gier bge nie można normalnie sprzedawać (tzn możesz, ale gra jest też na licencji GPL i po kilku dniach byłaby legalnie za darmo do ściągnięcia)).