Skoti

@Marvin: Do czego Ci n-gony? Jeśli potrzebujesz wypełnić wielokąt powyżej 4 wierzchołków to alt+f, a jeśli chcesz po prostu ukryć wygląd siatki w wielokącie, to make f-gon. Nie wiem czy optymistycznie, bo wiesz, że jeśli tak to przewiduję operację na otwartym sercu (bmesh do 2.6 jak najwcześniej, a użytkownicy będą przymusowymi beta testerami ;p).

Podaj link do tych oficjalnych danych, bo o ile 1.2 mld dysków sprzedano przez 2 lata (wszystkich, zarówno małych jak i dużych, na serwery, jak i do netbooków, zarówno 3 calowe jak i 2.5 i 1.8), to wątpliwa jest średnia 500GB (sam w tych latach kupiłem 3x dyski o pojemności 1GB, ale mowa o średniej). PS. nie licz pojemności dysków (które są podane w GIGAbajtach), jako wielkość danych, którą możesz tam zmieścić (które są w GIBIbajtach - w przeciwieństwie co jednostek jak giga* (podstawą jest 1000), gibi to jednostka binarna (operująca na 1024), dlatego na dyskach np. 1TB, pomieści Ci się danych ledwo ponad 900GB (różna podstawa, robi różnicę ~10%)).

1TB i więcej nie są znowu takie popularne - wręcz jest to rzadkość, i spotkasz je tylko w najnowszych komputerach - sporo osób z dostępem do internetu korzysta nawet z 10 letnich i więcej komputerów z dyskami o pojemności 4-6GB, zapominasz też o całej masie osób z dostępem do internetu z telefonów (kilka mega do kilka giga), tabletów (kilka GB - 32GB), netbooków (od kilka do kilkadziesiąt GB), a już w szczególności zapominasz o laptopach, które mają spory udział w rynku, a nowe, najpopularniejsze modele mają 250-320GB... no max 500GB, ale one nie są tak popularne (a tu też nie ma tak, że wszyscy mają nowe i wiele osób ma jeszcze laptopy z dyskami poniżej 80GB).

Wręcz nadzwyczaj sensowne, tylko takie wyszukiwanie, jest stosowane w rendererach trójkątów od lat 80 jak nie wcześniej i to w wielu wariantach takiego wyszukiwania (BVH, Octree, KDtree i setkach odmian - np. renderery GPU korzystają z QBVH (w przeciwieństwie do klasycznego binarnego BVH rozgałęziają się węzły nie na 2, a na 4 - ta struktura bardzo dobrze działa z SIMD - 4 jednostki wektorowe, jednocześnie mogą przeszukiwać różne liście w drzewie)). Tu nie jest nic nowego - dokładniej rzecz biorąc zmodyfikowali trochę znany od lat osiemdziesiątych Octree i tyle - nie ma w tym, żadnej magii czy nowinki... jest tylko marketing. Słaby wybrałeś przykład - to, że Gmail pokazuje Ci 7.5GB nie znaczy, że ma pojemność dysków równa 7.5GB * ilość użytkowników. Ta liczba jest płynna i faktycznie możesz tyle zapełnić, bo polega to na tym, że na jedną osobę która tyle wykorzysta przypadnie z kilka milionów które wykorzystają mniej niż 100MB. Gdyby np. 5% użytkowników nagle zapełnił całe 7.5GB, to na innych kontach zobaczyłbyś ograniczenie, np. 500MB, albo mniej. Liczba pokazywana przez Google jest płynna i zależy od wykorzystania zasobów przez użytkowników i nie ma to pokrycia pewnie nawet w 1% faktyczną powierzchnią dyskową.

Chciałeś powiedzieć chyba silnik Q3 (id Tech 3). Bez masy pracy nad rendererem nie przyniesie wielkich korzyści - renderer się już strasznie zestarzał i wymaga aktualizacji (wymaga, bo na tym silniku animacja większej ilości postaci odpada (animacja szkieletowa robiona na CPU (każdy wierzchołek siatki jest mnożony przez kilka macierzy kości na CPU), zamiast jak to ma miejsce od lat w vertex shaderze)) - ofc wcześniejsze silniki id Tech i formaty modeli nie obsługują wcale animacji szkieletowej.

Dla nikogo nie jest to obraźliwe (skąd ten pomysł) - problem w tym, że mówi bez sensu, nie jest to w żadnym stopniu odkrywcze (ot to co mamy od lat 80), a zabawne nie jest jak na pytania o ważne problemy nękające nas od kilkudziesięciu lat, jak np. pamięć odpowiada, że on ma algorytm szukania (który jest odpowiedzią na zupełnie inne pytanie, na które wszyscy znają odpowiedź - tak mają fajną strukturę drzewa octree, tylko co z tego?). Męcz twórców aplikacji, bo viewporty w aplikacjach graficznych ssą przez nich, nie przez trójkąty.

Jeśli jako "bogaczy" masz na myśli inwestorów to masz rację oni nie są milionerami dlatego, że są idiotami... dlatego, nie słyszałem o żadnym prywatnym inwestorze zainteresowanym wsparciem tego projektu - jedynie państwowe fundusze są w to inwestowane, a nimi, często nie zarządzają osoby kompetentne.

Nielimitowane detale to marketing (tu nie ma co rozumieć). Ogólnie jest to uproszczenie bardzo dużej szczegółowości (która prowadzi w ślepy zaułek, ale jest na tyle chwytliwa, żeby zyskać dotacje i zarobić). OFC, że mają powody, żeby kłamać - powodem jest kasa, na tym marketingu zarobili już miliony $. Wcale nie będą musieli nic wyjaśniać... tak jak w wypadku prawie wszystkich dotowanych projektów projekt upadnie z powodu napotkania problemów, których się przeskoczyć nie dało - to ze wyjdą na palantów raczej ich nie obchodzi, bo już wyszli.

Co nie zmienia faktu, że przy wspomnianej ilości unikalnych wierzchołków (ta wyspa to podobno 21 062 352 435 000) i 3 bajty na pozycję (XYZ - mniej przekreślałby sens unlimited bo limitowane byłoby przez samą precyzję) daje prawe 60TB - a gdzie kolor, normalne, a co ważniejsze gdzie pomieścić strukturę akceleracyjną (bo same "kategorie" w tym ich "algorytmie wyszukiwania" będą zajmować niesamowite ilości przy takich danych) - tu ofc problemu nie ma gdy jest kilka obiektów na scenie i instancing, ale do zadnego innego zastosowania poza demem się nie nadaje. Opisałeś mniej więcej tessellację znaną z Dx11 czy OpenGL 4... tu chodzi o zupełnie coś innego - te dane nie są generowane (jak w tessellacji, gdzie sobie teksturą możesz przesuwać lub wygładzać płaszczyznę za pomocą interpolacji), a modelowane, zapisywane i odczytywane z pamięci. Ofc patent nie polega na wyświetlaniu tego (nawet nie chodzi o naiwność, tylko jakieś zgrabne drzewo), ale nie wiem skąd przypuszczenie, że w tym jest jakiś patent i kiedykolwiek coś z tego wyjdzie. To nie brak wyobraźni tylko pamięci (dlatego nie użyli obiektów z poprzedniej prezentacji - po prostu się nie zmieściły). Nie interesowało mnie jak to zrobił, bo nie miałem w planach implementacji czegoś podobnego, jeszcze z 3-4 lata ;p. Trochę mnie to co mówisz zdziwiło - spodziewałbym się raczej po podpisie pod filmem ("Rendered with CUDA and OpenGL at 36 fps.") animacji w CUDA, raytracing w CUDA do tekstury i rendering textury w OpenGL na pełnoekranowym quadzie (żeby jak już wszystko robimy na GPU, nie kopiować niepotrzebnie danych do CPU kiedy można współdzielić między API), lub na lenia animacji voxeli w CUDA i przekazania jako tekstura 3D która wyświetlona byłaby już w OpenGL. Jednak to nie zmienia podstawowej rzeczy - problem jest z poradzeniem sobie z animacją 3M punktów, a w UD podobno tyle mieści się w 3x cal do 3, więc o animacji tych kolosów nie ma mowy. Spokojnie, do szybkości procesorów takich, żeby można było naśladować świat, to lata świetlne, a do rozpakowania takich danych jak w DNA (które wcale tak mało danych nie mieści - tylko jest małe rozmiarami) do budowy wirtualnych atomów w czasie rzeczywistym to jeszcze dalej. Fajnie, że Ci się podoba pomysł budowy wszystkiego z małych punktów, ale ten pomysł nie jest nowy - po prostu z dzisiejszym sprzętem jest to niemożliwe... może za dziesiątki, setki lat.

Dla ścisłości - twierdzi, że to bujda, a później twierdzi, że to bujda tylko źle zrobił obliczenia (co nie zmienia faktu, że to bujda), bo przyjął chmurę punktów jako voxele (poprawki tez nie wiele pomogły bo dalej źle to oblicza, mimo, że faktyczne wyniki chociaż mniejsze dla pamięci i tak są tak wysokie, że nie ma jak myśleć o tym poważnie ;p). Filmik z animacją nie jest jakoś specjalnie ciekawy - są to rzadkie voxele (a nie wielokrotnie gęstsza geometria z chmury punktów), a mimo to wydajność jednego animowanego obiektu to 36fps (przy takich chmurach o jakich mowa byłoby dobrze gdyby jeden obiekt osiągnął 1fps (mowa o jednym obiekcie na scenie)), a przy 36fps nie da się myśleć o grze (2 animowane postacie to już poniżej płynności, a co dopiero gdy mówimy o całej dynamicznej scenie).

Tak jak pokazane prawdopodobnie nigdy nie będzie w użyciu. Tessellacja to zagęszczanie siatki, która może być sterowana z shaderów (zagęszczasz tylko to co widzisz i tylko to co blisko kamery zagęścisz bardzo, to co dalej mniej) i nie wymaga większej ilości pamięci (siatka jest zagęszczana w locie przez tessellatory). To nie jest takie lepsze od normalek symulowanie hipoly, bo to jest robienie hipoly w locie z lopoly, a displace mapy (vector displace jeśli chcesz) i nie jest to jakieś mapowanie tekstur tylko właśnie geometria (którą możesz przesuwać w shaderach za pomocą np. wypalonych mapek, lub wzorów matematycznych, żeby się łatnie wygładzała siatka). Mniej więcej pokazane jak działa tessellacja masz w na filmie nagranym 2 lata temu i działającym na sprzęcie obecnym wtedy w sklepach - kolejne generacje kart graficznych pójdą w tym kierunku jeszcze dalej (będą miały więcej tesselatorów i będzie można poszaleć z zagęszczaniem siatki dalej od kamery i z większą gęstością przy kamerze).

Jeśli ta prezentacja była faktycznie robiona z 20fps jak mówią to jakiś dobry procek i 16/32 gb ram to może się wyrobili na te kilka/kilkanascie powtarzanych ciągle obiektów przy jakimś dobrym drzewie akceleracyjnym. Problem zaczyna się kiedy chciałbyś mieć mniej powtarzalne środowisko, dobre oświetlenie (które jest dużo ważniejsze dla realizmu od szczegółowej geometrii) i animację.

@Sisay: nie tyle gigantyczne przepustowości, co gigantyczną ilość pamięci (na te sceny gdyby nie było takiego instancingu, potrzeba z 300 000 razy większej ilości Ram niż obecnie średnie 2gb, lub pojemności dysków wielkości ~60TB - ale wtedy można zapomnieć o RT zapewne). A to i tak nie rozwiązuje problemów z oświetleniem @KONAn: Mówi się, jedynie tyle, że to nie ma szans na dzisiejszym sprzęcie (najbardziej pochlebne opinie to są), albo że to oszustwo dla wyłudzenia kasy. Co do Carmacka to nie robią - Jon Olick (z tego co pamiętam były pracownik id Software) zrobił demo Sparse Voxel Octree (z jednym modelem) - w tej chwili prace nad tym są zawieszone aż sprzęt pozwoli dalej rozwijać. Carmack jest jednak jednym z osób, które są bardziej optymistyczne (mówi, że może za kilka generacji sprzętu i upływie X lat będzie można zacząć o czymś takim myśleć (jednak nie mogę oprzeć się wrażeniu, że Carmack myśli już o sprzęcie opartym o grafen ;p)).

Żeby była jasność ten link co podałeś jest odpowiedzią na http://notch.tumblr.com/post/8386977075/its-a-scam Troszkę rozminął się w obliczeniach ze względu, że przyzwyczajony jest do voxeli (x*y*z niezależnie od tego czy coś jest czy nie) i wyszło mu 512 petabajtów (ja dałem liczbę opierającą się o ilość punktów na tej scenie podanych przez nich w filmie -zapewne tylko powierzchnia obiektów, a środek jest pusty, w przeciwieństwie do voxeli (ofc liczylem czyste dane bez nawet struktur akceleracyjnych, animacji itd)). W tej odpowiedzi z Euclideon najbardziej mnie rozśmieszyło nie to, że na zarzuty o to ze nie ma szans na pomieszczenie tego w pamięci lub na to, że animacja nie ma prawa działać dobrze w czasie rzeczywistym (o ile nie mówimy o animacji przesuwania całych obiektów lub robienia animacji opartej na klatkach - ilość danych które i tak nie mieszczą się w pamięci pomnożyć przez ilość klatek kluczowych), odpowiadają tym, że mają algorytm szukania (strukturę akceleracyjnego drzewa stosowaną powszechnie), dzięki któremu rendering nie jest problemem wśród dużej ilości punktów (tylko to nie jest przez nikogo wytykane - jednak i tak w to ze nie jest ciężko uwierzyć), a to, że przy porównaniu do księgarni mówi, że dziś wszystko leży na ziemi (bez struktur akceleracyjnych, jak regały z kategoriami), co jest wręcz śmieszne, bo nie znam żadnego silnika w którym nie stosuje się struktury akceleracyjnej (ja w swoim silniku gier wykorzystuję QBVH (często spotykane jest też octree), bo jest łatwy do aktualizowania, co jest ważne przy interaktywnych scenach) do testu czy coś rysować czy nie (czy mieści się w kadrze), ani nie znam silnika renderującego już nie w RT, który nie stosuje drzew akceleracyjnych (które są właśnie odpowiednikiem wyszukiwania w 3d) do raytracingu (na początku wyszukujesz z kilku grup (kategorii) te z którą promień się przecina, te grupy mają swoje podgrupy (podkategorie), które mają swoje podkategorię i tak szukasz aż znajdziesz trójkąt/punkt - tak jak w bibliotece) - nazywanie wykorzystania struktur akceleracyjnych nowością, której do tej pory się nie wykorzystywało jest śmieszne.

Tak tylko niskie ustawienia grafiki, zaniżona rozdzielczość, skalowana na ekranie, a działa mimo to podobno bardzo słabo - do masakry wizualnej to w usługach streamingowych potrzeba lat - fajne jest to rozwiązanie jeśli chcesz zagrać w gry na telefonach, tabletach czy netbookach, ale jeśli masz hiend PC to lepszą jakość Ci zapewni lokalnie tworzona grafika.

Do faktycznego wprowadzenia tego typu usługi na dużą skalę jeszcze wiele lat musisz poczekać, bo są 2 istotne ograniczenia - jedno mniej znaczące to przepustowość łączy, drugie dużo ważniejsze moc obliczeniowa po stronie serwera (w założonej przez Ciebie jakości grafiki, jeden gracz zajmuje czas kilku/kilkunastu serwerów z podzespołami hiend sam - albo usługa musiałaby być bardzo droga, albo przeznaczona dla małego grona odbiorców)... ale jest to kierunek z przyszłością. To nie są voxele. Mam podstawy graniczące z pewnnością, pozwalające mi tak mówić ;p. Mówili ze to chmura, a nie voxele (i nawet naiwnie wierząc, że uporali się jakość ze strukturą akceleracyjną na te punkty, nawet myśląc naiwnie nie uwierzę, że uporają się z resztą problemów). Nie musisz śmigać do Australii, bo takie granty na badania, z których nic nie wychodzi, bo napotkają "nieoczekiwane" problemy to norma - wiesz ile przyznano grantów na badania nad np. lekarstwem na raka czy szczepionkę na malarię (ostatnio koleś dostał prawie milion $ od Billa Gatesa za robienie pułapek na komary ze śmierdzących skarpet) - z których nic nie wychodzi, poza wydaną kasą? Wtedy mówili o 16 miesięcy na pozbycie się wszystkich problemów, a SDK preview (taka wersja alpha) z tego co było wtedy na filmiku mieli dostać programiści za miesiąc, dwa - przez programistów gier i programów graficznych zostali wyśmiani i zmienili swój target. OFC przez te 1.5 roku nie pozbyli się żadnego problemu, tylko zeskanowali kilka assetów i kilka wymodelowali i zrobili kolejny propagandowy filmik, który o postępach mówi tyle, że ich brak. Rozwiązanie to dokładnie chmura punktów, tylko inaczej przetwarzana (podobno zrobili jakąś strukturę akceleracyjną, która pozwala przyspieszyć wyszukiwanie - czyli coś w stylu octree, kd-tree, bvh znane z akceleracji renderingu trójkątów). Przypuśćmy, że to jest realne (mało, ale niech będzie), ale rozwiązanie problemów z oświetleniem, animacją czy większą ilością obiektów nie są w stanie rozwiązać - przykładowo, taka wysepka którą zrobili, jeśli nie stosowaliby instancingu i wszystko nie byłoby powtarzalne, potrzebowałoby około 58 TERABAJTÓW pamięci RAM - czyli przyjmując standardowo 2gb u graczy pamięci potrzeba 300 TYSIĘCY razy więcej niż dziś - kilka modeli statycznych może jeszcze przejdzie - a nawet mając taką ilość pamięci nie rozwiązujesz reszty problemów. Nie zamykają się, a wręcz przeciwnie - po prostu to nie jest rozwiązanie, które rozwiązuje jakikolwiek ważny problem, a jedynie wprowadza problemy dużo istotniejsze niż wszystkie dzisiejsze ograniczenia.

Z chmurą jest wiele problemów, i z pewnością nie znaleźli takiego panaceum - chmura się nadaje fajnie do udawania GI, ale nic ponad to. Jak nie wiadomo o co chodzi to chodzi o... no właśnie, po to aby zebrać kasę - 1.5 roku temu mieli na ukończeniu i programiści mieli wpłacać kasę, żeby dostać za miesiąc (w marcu 2010?) SDK ;p. Nie wielu programistów się nabrało więc postanowili iść w innym kierunku i dostali 13mln $ australijskich grantu - pewnie znowu mają coś na oku i robią szum, mimo, że praktycznie nic się nie zmieniło. Wyobrażać, sobie wyobrażam, ale takie gry nie potrzebują takiej geometrii. Powiem więcej, nie sądzę, by ten cały projekt miał na celu stworzenie jakiejkolwiek gry w oparciu o niego ;p. Cienie dla jednego światła to podwojenie czasu renderingu, dla 2ch świateł to potrojenie czasu. Do oświetlenia trzeba mieć normalną do powierzchni, co w chmurze punktów jest nie do zdobycia ze względu na charakter danych. Zanim chmura punktów dogoni możliwości trójkątów w oświetleniu, trójkąty dogonią wielkością te punkty, a dodatkowo nie będą rasteryzowane tylko będzie pathtracing ;p. Cały czas pojawiają się ciekawe rozwiązania i modyfikację wcześniejszych ciekawych pomysłów, i wcale o nich słuch nie zanika - tzn dla graczy czy osób, które zajmują się tematem od święta może to tak wyglądać - nie sztuka zrobić demo, z efektem gdzie 30fps lub często mniej masz na scenie z jedym obiektem, małą ilością geometrii, i bez innych shaderów, ale wcielić to do gier to zupełnie inna bajka - od pomysłu do realizacji w grach może minąć nawet kilkadziesiąt lat - i to nie jest ciche siedzenie i czekanie na sprzęt i dobry czas na wprowadzenie, a ciągła modyfikacja i optymalizacja... często jak z tym filmem jednak zapewne nigdy nie będzie zrealizowane, z prostego powodu - jest masa ważniejszych rzeczy do wprowadzenia, i jest za kosztowne, jak na mało znaczący element tła (lepiej moc przeznaczyć na coś innego). ...dwadzieścia, trzydzieści.... sto ;p.

Nie mówi się bo nie ma o czym - i nie mówię o tym ze prawie nic nie wiadomo tylko o użyteczności tego co robią. Tak - pracują nad tym od co najmniej 3-4 lat tylko wyjdzie, za jakieś 6-7 lat kiedy sprzęt na to pozwoli. Od lat ilość polygonów jest zupełnie poboczną sprawą - marketingowo jak i wydajnościowo liczą się mocne jednostki teksturujące i szybkie obliczenia shaderów - od lat prawie cały czas renderingu klatki jest pożerany przez shadery fragmentów, a przetwarzanie wierzchołków spadło na dalszy plan (a każde przyspieszenie tu, nie idzie na zwiększenie ilości poly, tylko na efekty postprocess). Ostatnio ruszyło tu, za sprawą tesselacji dzięki której można bardzo zagęścić siatkę blisko kamery, nie zajmując się zwiększonymi obliczeniami tego co daleko (zagęszczoną siatkę możesz przesuwać za pomocą wypalonych mapek np. displace, co daje bardzo ładne efekty). W realistycznej grafice nie chodzi przecież o ilość poly, a jakość oświetlenia, animacji i symulacji, dlatego gry niechętnie nawet idą w tesselację, bo lepiej wykorzystać czas renderingu, w kierunku GI. Nezumi mieszasz - voxele nie mają wiele wspólnego z chmurami punktów o których mówi filmik podany przez bolitic. Voxele są fajne tylko drogie obliczeniowo i pamięciowo - żeby można było zrobić gry porównywalne wizualnie do gier opartych na trójkątach musi minąć jeszcze dekada. W wypadku pokazanych chmur jest masa problemów które uniemożliwiają wyjście tego poza zabawy - punkty w chmurach nie mają orientacji (jak to punkty), dlatego, nie masz normalnych i nie masz oświetlenia na filmiku (a nie jest łatwo taką normalną zdobyć (jeśli nie chce się zapchać pamięci/procesora) - w voxelach czy trójkątach jest to stosunkowo proste), nie ma mowy o animacji (chyba ze mówisz o przesunięciu całego obiektu w czasie jako o animacji) - zwykły ruch ramieniem tu oznacza taką ilość obliczeń jak animacja 40 milionów wierzchołków na raz (licząc tak jak mówili czyli 64 punkty na mm^3, i licząc tylko punkty na powierzchni, bez wypełnienia)... no chyba, że nie mówimy o animacji szkieletowej to wtedy zabójstwo pamięci (ilość punktów * ilość klatek kluczowych). Problemem jest też różnorodność (punkty nie mieszczą się w pamięci) - nie bez powodu całe sceny na ich filmikach to instancje tylko kilku obiektów. Problemy z cieniami (tak wiem - powiesz ze są na filmiku, tylko wątpię, że one są dynamiczne - jest to po prostu bake po długotrwałym obliczaniu tego wcześniej - podobnie tu też nie ma tekstur z założenia - punkty mają po prostu kolor, a nie teksturę (i kolor jest modyfikowany - bake sprawdza czy jest w cieni i jesli tak to kolor punktu jest przyciemniony)). To demko z animacją drzew to już zupełnie nie wiem do czego - to normalna geometria, i efekty postprocess, takie jak stosowane w grach od lat - nie ma nic wspólnego z voxelami czy chmurami punktów. Słaby pomysł (symulacja cieczy na voxelach jest np. w blenderze (rozdzielczość domain to wiadomość na ile voxeli będzie podzielony)). Dużo lepszym pomysłem jest symulacja particle, rendering punktów do 2D i obróbka w postprocess ( ). Chmury punktów to coś zupełnie innego niż voxele. No tak, mamy animację, ale nie pokażemy (bo albo jej nie mamy, albo polega na przesuwaniu całych obiektów i lepiej powiedzieć ze mamy niż pokazać). Nie są artystami to nic innego jak wykręt, bo to źle wygląda nie przez słabe modele, a brak oświetlenia i praktycznie brak możliwości jego zrobienia. PS. teraz też nie ma tekstur - są tylko zapisane kolory punktów, które zapisane zostały zapewne przy konwersji z siatkowej wersji. Tessellacja też nie ma jakiś wielkich ograniczeń - ostatnio robiłem taki mały test na 460 i przy tessellacji w OpenGL (dając w efekcie na scenie około 77 mln poly) działało ~12fps (w trybie siatki widać prawie było to samo co w geometrii, bo tak gęsto, a nie było problemów ani z oświetleniem, ani z innymi efektami), a to na średniej karcie z pierwszej generacji kart z programowalną tesselacją (w kolejnych kartach będzie więcej tesselatorów). Ofc teoretycznie mniejsze ograniczenie geometrii ma ta ich technologia (teoretycznie), ale wprowadza masę innych ograniczeń znacznie poważniejszych w skutkach dla efektu. O ile ten tłum to jedna postać skopiowana i bez animacji, oraz olewasz oświetlenie to można nawet powiedzieć i przyjmując że jesteśmy naiwni może się to udać ;p. Ja tam mimo, że rasteryzacja jest z nami od lat dalej nie widziałem dobrej przezroczystości w RT (wręcz się jeszcze bardziej od tego oddaliliśmy przenosząc oświetlenie do postprocess deferred shading (uzyskując wydajne wiele źródeł światła - które jeszcze do niedawna były niemożliwe i na całe sceny było po kilka świateł (ofc tylko kilka moze dawać cienie, bo to za duzo by było ;p))) czy wydajnych wielokrotnych odbić (o odbiciach obiektu sam w sobie lepiej nie wspominać) w RT korzystając z rasteryzacji. Wszystko ma wady których obejść się nie da, co najwyżej można z nimi żyć - z niższą geometrią można żyć, z problemami z niektórymi typami materiałów, z trudem... ale ze słabym oświetleniem wsystkiego nie.

Nazwa trochę wprowadza w błąd - to nie jest książka o pisaniu skryptów dla blendera w eclipse... nie nauczysz się z niej programować, nie poznasz pythona, nie poznasz script API blendera, nie poznasz możliwości Eclipse i Pydev (jedynie mini wyfinek możliwości jest pobieżnie pokazany). Ta jak nazwał ją WJaworski "broszurka" z tego co się zorientowałem to jedynie ustawienie Eclipse do milszej współpracy z Blenderem, zakładająca jednak, że potrafisz programować w pythonie, znasz api blendera, znasz eclipse itp.

@ola-f: Nie chodzi o popularne formaty/rozwiązania, a popularne aplikacje z błędem (bo błąd będzie działał np. tylko u 10% osób które używają tego rozwiązania ;p). Nie obejdzie robienia screenshota całego okna, gdy w żadnym wypadku nie będzie można tego zrobić (W WebGL wcale nie możesz robić screenshotów, a jedynie czytać buffor ramki/tekstury). Sam WebGL nie zmniejsza bezpieczeństwa przeglądarki (ogólnie to do niczego nie ma dostępu, poza dostępem do niektórych funkcji udostępnianych przez sterowniki) i w praktyce nie może nic większego wyrządzić niż zawieszenie kompa (spowolnienie pracy do tego stopnia, ze ciężko będzie zabić przeglądarke), jak aplikacja będzie nadużywała GPU. Problemy z bezpieczeństwem samego HTML5 i JS są znacznie poważniejsze, ale tu jakoś nikt nie protestuje i wszyscy twórcy przeglądarek będą je wspierać ;p. Plików fla nie dostanie nikt - tylko swf (w którym kod AS jest podany na tacy) i często podawane mu są parametry zewnętrzne z html/js. Jednak to jest najmniejsze zagrożenie (po co edytować cudze i szukać błędów, jak można dużo łatwiej, tworząc plik swf samemu?) - wystarczy zrobić stronę która wykorzystuje lukę w flash playerze i doda do jakiejś niezabezpieczonej strony z html (takich jest masa, a wystarczy wpisać komentarz, który doda do normalnej strony flasha o rozmiarach 1px na 1px którego nie zauważysz, a będzie mógł przejąć kontrolę nad Twoim kompem).

@ola-f: Raczej poza podpiętym kontekstem renderowania pod kontrolkę (czyli poza screenshotem z samej aplikacji WebGL - możliwość tego jest i tak konieczna, do gier i renderingu postprocess), do reszty aplikacja WebGL nie powinna mieć żadnego dostępu i bez możliwości obejścia (o ile nie nawalą) - banalne do obejścia... ciekawe - chciałbym zobaczyć jak banalnie to obchodzisz w Chrome, gdzie po prostu nie nawalili w implementacji. Problemem faktycznym jest tylko możliwość zawieszenia komputera, ale to jest kłopot wszystkich - reszta jest zależna już od konkretnej przeglądarki (podobnie jak zależne jest bezpieczeństwo implementacji flash/silverlight od ich autorów). Co więcej, realnie WebGL może się okazać bezpieczniejsze ze względu na mnogość implementacji (nie opłaca się atakować dziury obecnej w danej implementacji (np. tylko mozilla), gdy u innych nie zadziała... a z pewnością mniej się opłaca niż atakowanie pluginów jak silverlight czy flash gdzie wszędzie jest ten sam kod, i atak na bug w tym oprogramowaniu, zwiększa ilość potencjalnych ofiar).

Nie, podobnie jak nie możesz tego zrobić za pomocą WebGL (a raczej nie mam aktualnych danych, bo ostatnio coś adobe łatało, ale do niedawna przynajmniej można było dosyć łatwo przejąć kontrolę nad komputerem i uruchomić tam złośliwy kod (trojan/wirus... program robiący screenshot i wysyłający komuś na maila ;p) - zapewne jest to dalej możliwe z flash playerem który jest pełen błędów, a bezpieczeństwo to ostatnie co można o nim powiedzieć) - możesz tylko i wyłącznie za pomocą jednej implementacji (Mozilli) to zrobić i tylko do czasu, aż tego nie naprawą (zapewne już jest naprawione), jednak to wina twórcy przeglądarki, a nie samego standardu (podobnie można obwiniać JavaScript czy HTML, i błędy bezpieczeństwa w przeglądarkach (np. w przeglądarce Microsoftu)). Microsoft też nic o screenshotach nie mówi, a o zawieszaniu kompa (np. ktoś zrobi shader robiący masę obliczeń w takiej ilości, że zawiesi kompa)... ale to już nie wina standardu i jego twórcy tu wiele do powiedzenia nie mają (tu trzeba zmienić jądro systemu operacyjnego i sterowniki do kart graficznych, a dopóki tego się nie zrobi, problem będzie obowiązywał w każdym 3d w sieci (a szczególnie jeśli jest dostęp do shaderów)).

Czasami jest to wskazane, a czasami wręcz przeciwnie - wszystko zależy od modelu, i często jest to uzasadnione względami wizualnymi (ale bywa, że wizualnie lepiej wygląda hard).

DAE to rozszerzenie formatu Collada i w 3ds max z tego co pamiętam masz wbudowany eksporter - jeśli jednak Ci się nie podoba (np. za wolno eksportuje) to użyj innego pluginu jak http://opencollada.org/download.html

@SYmek: konkurencja nie ma szans wprowadzić tu swojego API, bo to pogrzeb dla firmy, i aby konkurować z dominującym standardem można jedynie się do niego przyłączyć, lub do największego otwartego konkurenta. Konkurencja zachowuje się dokładnie tak samo kiedy tylko ma w tym interes: - przykład 1: Apple i wymuszanie na klientach instalacji systemu, tylko na ich sprzęcie), - przykład 2: Nvidia i promowanie wśród programistów CUDA, mimo oficjalnego wspierania i nawet tworzenia OpenCL (prezes Khronos Group i szef standaryzacji OpenCL, jest wiceprezesem Nvidii) i dbanie o jego dominację (dzięki temu, jeśli ktoś chce robić obliczenia na karcie graficznej, jedynym słusznym wyborem jest karta Nvidii). Wcześniej podobną taktykę miała firma 3dfx ze swoim GLIDE. Podobnie jest ze wszystkimi innymi firmami (Google tak samo zachowuje się wszędzie tam gdzie jest liderem i dyktuje warunki... tam gdzie jest jednym z wielu inwestuje w otwarte standardy)... taka już jest norma - jeśli otwarte standardy są dobre dla firmy (nie ma opracowanego własnego standardu, który jest przyjęty przez rynek), to się ich przestrzega, a jeśli się posiada własny standard dominujący, to otwartych standardów się nie uznaje, a pielęgnuje się swoje standardy, na które się ma całkowity wpływ i co najważniejsze, rezygnacja na rzecz otwartego standardu, spowodowałaby straty dla firmy (i to jest ogólna zasada, niezależna od firmy (jedynie firmy które nie mają swoich standardów dominujących na rynku, wspierają otwartość)). PS. Jak najbardziej to JEST złe dla rynku i klienta, ale dobre dla firmy i nie istnieje firma, która dobro klienta/rynku liczy wyżej niż swoje własne dobro, więc firma MS tu nie robi niczego, czego każda inna firma na jej miejscu by nie zrobiła... w tym względzie nie robi niczego złego, a z jej punktu widzenia (jak i każdej innej firmy postawionej w takiej sytuacji), robi to co może najlepszego. Np. weźmy pod lupę najważniejszy produkt MS, czyli system operacyjny i alternatywa w postaci Linuksa - ceną nie da się powalczyć, jakością jądra od lat Windows niechlubnie odstaje i dużo słabiej obsługuje wielowątkowość, czy zarządza pamięcią, łatwość i przystępność interface jest podobna, a jedynym faktycznym atutem jest właśnie dominacja - czyli dominująca większość użytkowników zna już interface i ich produkt oraz przy przejściu na konkurencję najważniejsza jest właśnie wyłączność - to urządzenie ma sterowniki wyłączne na system MS, ten program działa wyłącznie na systemie MS, ta gra jest tylko na system MS, więc na miejscu MS masz wybór, promować swoje produkty i podsycać dominację i zarabiać miliardy $, lub otworzyć się przed konkurencją i zostać w skarpetach bez możliwości nawet rozsądnego konkurowania (musieliby dużo pracy wykonać w jądrze, a wtedy dalej ceną nie powalczy) i w bardzo szybkim czasie ogłosić bankructwo - dla firmy i jej pracowników istnieje tylko jedna opcja.