Skoti

Facet mówi normalnie poprawnie po angielsku (z typowym dla anglii akcentem). W filmach z Hollywood tak mówią aktorzy, którzy udają anglików (bo w stanach mówią bardzo "spłaszczonym" angielskim i akcent jaki powinien być w języku angielskim zanika).

Pointcloud możesz generować jak najbardziej, ale wyliczenie normalnej w tym wypadku, jest bardzo problematyczne i już tego się nie da zrobić w rozsądnym czasie Niby dlaczego zakładasz brak AA? Rozumiem, że wpisałeś w google deferred shading i dowiedziałeś się, że były problemy z AA (dx9 i dx10, a także OpenGL

No nie wściekaj się już (napisałem Ci już , że się z tobą droczę ;p). Tu dalej nie rozumiesz - nie można generować normalnych dla każdego punktu w przyzwoitym czasie i temu nie zaprzeczaj, bo tu nie ma żartu tylko tak jest. Można za to liczyć jako postproces jako obróbkę renderu tylko dla tych punktów które zostały wyrenderowane (i będzie to bardzo wydajne - masz tylko 8 sąsiadów, z każdej ze stron, które chcesz mieć, masz ich pozycje w gbufforze, więc obliczenie normalnej to bajka). Nie tyle z nudów, co po prostu mózg musi pracować (głupie rozrywki są zajmujące i potrzebne, ale co jakiś czas trzeba pogłówkować), a nie ma lepszej łamigłówki, jak myśleć jak coś napisać, żeby wyglądało na prawdę, mimo że nią nie jest (chodź w wielu sprawach była to prawda, ale w niektórych ostre naciąganie prawdy), ale przyznaje, że to również dobra rozrywka ;p.

Zmienia to dużo, bo w przypadku trójkątów i mnożenia ich wierzchołków przez macierze, nie musisz dochodząc do igieł używać rekurencji bo wszystko masz zrobione podczas preprocess (lub na żądanie, ale do tego nie potrzebujesz rekurencji), a w wypadku tego jak Ty mówisz dochodzisz do drzewa (które jest instancją i trzeba, modyfikować promień), dochodzisz do gałęzi (która rusza się na wietrze i też musisz przekształcić), później dochodzisz go gałązki..., do n igieł, gdzie muskasz tylko BS, a dopiero wtedy dochodzisz do BS w którym trafisz i tu dopiero jest tak jak w Tri ;p Zastanawia mnie dlaczego tak późno ;p. Mam teraz akurat wolny tydzień od programowania i jako ćwiczenie dla umysłu wymyśliłem sobie negowanie wszystkich argumentów pro UD (nawet jeśli byłyby sensowne (chociaż większość była bezsensowna - co więcej jestem pewien, że dobrze o tym wiesz ;p). Dziwi mnie fakt, że mówisz, że znasz gamedev, a tak łatwo odpuściłeś normalne i jedyny sensowny sposób ich liczenia w UD mimo podpowiedzi (deferred shading, normalne jako postprocess ;p) - bo można przecież zapisać dane z renderu do G-buffora na podstawie pozycji już w 2d obliczyć normalną i dodać oświetlenie tak jak daje się w dzisiejszych grach jako shader postprocess, bo normalnie więcej niż kilka świateł byłoby katuszą wydajnościową... będą pewnie nieścisłości (przez brak normalnych i oblizanie ich na podstawie pozycji tylko wyrenderowanych obiektów) przy odległych obiektach, ale do zaakceptowania. Jednak IMO i tak UD nie nadaje się do renderingu realtime i nie będzie przez wiele, wiele lat (może jednak znaleźć małą niszę w narzędziach dla grafików).

Tu na każdym z tych potencjalnych nie załamujesz promienia i nie jesteś coraz głębiej w rekurencji (siatka jest już przemnożona) Tak buduje sobie drzewko... dokładne tak jak robi to z resztą sceny (i dokładnie tak jak z instancjami) - tu nie ma żadnej różnicy (jedyna różnica to to, że jest ładowany z proxy który jest plikiem). Tylko częściowo korzysta ze sprzętowej implementacji - materiały i wiele innych rzeczy liczy już za pomocą shaderów GLSL (i to w wypadku CG po prostu będzie kompilowane do kerneli OpenCL... tak jak to zapewne ma miejsce w reszcie urządzeń (bo raytracing liczony na CPU/GPU nie wykorzysta shaderów GLSL i to ich karty też muszą liczyć za pomocą swoich jednostek obliczeniowych w oparciu o program, a nie fixedpipeline na karcie)). Pokazali prototyp na Siggraph rok temu, i produkcja sprzętu nie ruszyła, nie wyszedł do sprzedaży. Ja jestem daleki od atakowania CausticGraphics... po prostu ze sprzętem niestety im nie idzie za dobrze. Myszka widocznie lubi się męczyć w małym okienku do komentarzy - ja nie zamierzam. W przypadku liści, igieł... (które są przeważnie 4x pkt z teksturą) wydajniej jest je przemnożyć (przemnożyć na żądanie czyli jak uderzy w BS to mnorzymy), i tak dalej robią raytracery. W wypadku UD na zapisywanie historii transformacji braknie pamięci, bo same punkty ledwo się zmieszczą. //edit: Dla rozjaśnienia dodam, że renderer który robi tak jak Ty mówisz działa słabo w głównych zastosowaniach instancji/proxy - liście/igly/trawa (gdzie geometrii prawie nie ma - a ja w silniku mam wręcz 1pkt na obiekt w takich przypadkach (geometry shader już po umieszczeniu go w dobrym miejscu generuje te czworokąt pod teksturę ;p)), i animacja tłumu (siatka jest instancją ale jest modyfikowana przez inne kości, przekształcenia...) więc w wypadku animacji szkieletowej obiektu który ma instancje/proxy to tylko n mnożeń mat4x4*mat4x4 (gdzie n to liczba kości), a mnożenia siatki przez kości i tak nie unikniesz. Akurat duża liczba obiektów przezroczystych nie zabije raytracera (spowolni go znacznie, ale nie zabije ;p) - promień nie pójdzie dalej niż ustawiona z góry głębokość promienia. Czerpią i to dosyć sporo... (tak samo jak idzie w drugą stronę) i każda branża korzysta, ale to też nie przeszkadza im wymyślać wielu rzeczy które rewolucjonizują rynek nie tylko gier ;p. //Edit @down: A co ma czas sprawdzenia czy promień przecina tri, do modyfikacji promienia (po zmodyfikowaniu i tak musisz sprawdzić czy przecina się z tri)? //Edit, edit ;p Ja nie pisałem nigdzie o kosztowności tego, tylko o potencjalnym i w wypadku UD tak jak sobie to wyobrażasz praktycznie nie uniknionym przepełnieniem stosu (a przepełnienie stosu nie jest problemem z wydajnością, tylko z małą możliwą głębokością rekurencji wykonywanej na stosie pamięci w PC (co prowadzi do wywalenia się programu)) // Edit, edit, edit Zrozum, że nie korzystając z mnożenia macierzy, i struktur hierarchicznie ze sobą związanych (obracasz drzewo, to obracasz każdą igiełkę), to wchodząc do dużego BS modyfikujesz promień i jesteś na kolejny, poziomie rekurencji, znajdujesz w nim mniejszy BS i modyfikujesz promień... itd.

Jak patrzysz się tylko wzdłuż jednej gałęzi masz miliony potencjalnych kandydatów. Co do proxy to radzę zgłębić temat bo jedyne czym różni się od instancji według dokumentacji to to, że nie bierze siatki z programu graficznego tylko przy renderingu ładuje go z pliku (vray dostaje tylko info gdzie ma wstawić obiekt z pliku i później sam ładuje sobie siatkę i z pliku i traktuje to dalej jako normalną siatkę). Ich oprogramowanie to OpenRL SDK, i korzysta z OpenCL (a SplutterFish wykorzystuje ich soft w Brazil - tak samo jak konkurencja w postaci mental images iray korzysta z softu nvidii (cuda+scenix)) i obsługuje każdy sprzęt OpenCL i jeśli wreszcie wydadzą sprzęt (który zapewne będzie się zgłaszał jako urządzenie OpenCL, tak samo jak może każdy inny sprzęt karty graficzne, procesory, karty dźwiękowe z dsp (nie widziałem sterowników z opencl, ale w teorii i założeniu opencl jest to możliwe i zależne od producenta sprzętu)) to będzie ten sprzęt wspierany (pewnie nawet przez inne silniki korzystające z OpenCL i nawet moje programy).... póki co nie jest ten sprzęt wspierany ani przez ich soft, ani przez brazil bo go nie ma.

Nie twierdzę, że ludzie z ILM pochodzą ze środowiska gamedev (nie wkładaj mi w usta słów których nie użyłem), ale osoby prowadzące badania na uniwersytetach bardzo często mają przeszłość gamedev lub dalej w tej branży pracują, często prowadzą konsultacje i wspólne badania z firmami gamedev (bo to przeważnie ta sama działka - wykorzystać moc do maksimum, rozwijać sztuczną inteligencję, fizykę... a przy czym wszystko musi być w czasie rzeczywistym lub zbliżonym do tego). Nie jest możliwe, żeby każdy liść był osobnym obiektem w twoim pojmowaniu UD (ruszasz promieniem, zamiast obiektem). Proxy w vray/mray działa zupełnie inaczej (normalnie mnożone są wierzchołki przez macierz przekształceń przed renderingiem). Wcale nie podważyłem sensowności raytracerów, tylko twojego pojmowania jak może działać UD (w raytracerach nie masz bilionów obiektów na jednej choince tak jak chcesz tego z UD, i nie przekształcasz promienia n razy przy takiej ilości obiektów rekurencyjnie co wywali Ci program, tylko leci w pętli po wszystkich wierzchołkach i mnoży je przez ich macierze (tu nie ma mowy o przepełnieniu stosu, a podczas śledzenia promieni gdzie głębokość jest ustawiona od 0 do kilkadziesiąt (przy pojmowanym tak jak to mówisz UD głębokość rekurencji byłaby od kilka do do setek bilionów (zależy od ustawienia kamery i na co trafią promienie), ale tu ciężko nie widzieć zagrożenia przepełnieniem stosu))). Tak jak wszystko jest statyczne, pojedyncze obiekty są stosunkowo duże (tak jak na filmikach (a nie jak w wypadku choinki, gdzie każda gałąź i igła jest osobnym obiektem)), to przeszukiwanie jest stosunkowo szybkie i niegroźne. Akurat obrót nie powinien być problemem (no chyba ze nie mnożą przez macierz, a ręcznie dodają przesunięcie do współrzędnych) i myślę, że spokojnie mogłoby być z obrotami to z tymi piramidami (jednak w życiu z igłami na choince). Tylko powiedz mi co z tego, że potrafi w miarę szybko zrobić obrzydliwy render? Niczego więcej nie wyciągniesz w przyzwoitym czasie. Możesz napisać co pokazali? Póki co nie wydali sprzętu na rynek, a ich oprogramowanie teraz korzysta właśnie z procesorów Intel/AMD i kart nVidia/Ati (ich soft renderuje za pomocą OpenCL). Do tej pory właśnie pokazali, że nie są w stanie zrobić sprzętu takiego jak zapowiadali (Q1 2010 na który zapowiadali kartę wydajniejszą 20 razy kart z 2009 dawno za nami, a nawet nie zająknęli się o dacie wydania sprzętu), a widziałem tylko scenki wyglądające na banalne obliczeniowo wyciągających 5fps, przy 640x480 (spokojnie z tą samą rozdzielczością, geometrią i efektem końcowym da się obliczyć z takim samym fps na kartach z 2006), a zapowiadana cena to 2500$ za kartę. Jeśli coś pokazali w ramach sprzętu to właśnie, że się nie da. Po tym co mówisz pokazujesz, że nie bardzo wiesz o czym mówisz i dzwoni, ale nie dokładnie wiesz w którym kościele, a że nie wiem jakie masz braki to piszę rzeczy oczywiste, żebyś więcej nie gadał bzdur.

Z tego co piszesz uznałem, że przyda ci się lekcja podstaw. Wydajniej byłoby gdyby było to takie proste - bounding shape z pewnością będą mieć części wspólne, a jak wyobrażasz sobie gdy promień wejdzie w jeden BS, i zanim zdąży wyjść wchodzi w inny (nie możesz promienia obrócić, bo jeszcze może trafić w coś co jest w tym pierwszym BS... jeszcze gorzej gdy te BS się w sobie zawierają (np. A(B©)) )... w normalnym wypadku odpowiedzią na to jest łatwe proste słowo "rekurencja"... w wypadku UD rekurencja nie jest rozwiązaniem problemu, a synonimem przepełnienia stosu (w przypadku dynamicznej alokacji pamięci stracisz jeszcze więcej wydajności, a pamięć w tym rozwiązaniu to bardzo kruchy temat gdzie zawsze jest jej brak i jest znacznym limitem). Co do animacji w UD to właśnie potwierdziłeś, że nie ma szans na jakąkolwiek popularyzację (ani w grafice, ani tym bardziej w grach)... oraz zaprzeczyłeś sobie, że nadaje się do fauny (gdzie liście, gałęzie, trawa, krzaki muszą być animowane, reagować na wiatr, fizykę, interakcję, bo zamiast realistycznego efektu, dostajesz nieciekawą stop klatkę (i tu wszyscy zarówno gracze jak i programiści wybiorą opcję ładniejszą, bardziej realistyczną nawet jeśli ceną jest to, że jak podchodzisz z kilometra to będziesz mógł zobaczyć zmianę (trwającą jedną klatkę) poziomu detali (LoD))). Akurat tak się składa, że większość tych zaawansowanych rzeczy publikowanych na Siggraph jako nowinek, na które trzeba czekać lata są stworzone przez ludzi ze środowiska gamedev (są to jednak przeważnie niezoptymalizowane prototypy, lub implementacje zbyt dokładne (dużo łatwiej jest uzyskać dokładny efekt, niż wydajny przy niskim spadku wydajności) i nadają się do implementacji w zadaniach poza realtime (np. programy graficzne, renderery), a ludzie z gamedev muszą myśleć dalej, bo jest ograniczona moc, i trzeba problem ugryźć z innej strony, żeby zyskać wydajność). Co do domyślania się czy żartujesz to obchodzi mnie to całe g. Komentuje bo widać, że nie bardzo wiesz o czym mówisz, a to jeszcze inni czytają.

Nie powiedziałem, że nie nadaje się do szukania pojedynczego punktu, bo tu sprawdza się dobrze (i tu z prawie płynnym odtwarzaniem sceny nie ma nic szczególnego jak dla mnie). Nie nadaje się do szukania grupy punktów w otoczeniu, zadbanie o to żeby znalazło w każdą stronę (o ile tam są) i obliczenia normalnej, nie nadaje się już przy animacji itd (a animacja tylko potwierdza, że też nie dają sobie rady z tym, żeby było to wydajne). Cały trik związany z chmurą punktów jest to, że dane z założenia nie są równomiernie rozłożone (jak jest to przy voxelach). Dążyć możesz, ale przy tylu punktach nie jesteś w stanie o to zadbać (często się nawet nie da). Dokładnych szczegółów komplementacyjnych nie znam, ale znam szczegóły działania (jakieś pół roku temu krótki kontakt mailowy - bo ogólnodostępnych info praktycznie nie ma), podaje Ci argumenty, a w minimalnym stopniu przypuszczenia, a i tak kontynuujesz rozmowę. Standardowe 3d to dla mnie raytracing (rasteryzacja to już mniej naturalne jest) i tak jest tam dokładnie raytracing... jednak po tym co mówisz wnioskuje, że nigdy nie napisałeś raytracera, ani nigdy nie interesowałeś się jego działaniem - w raytracingu też bardzo dużo mnożysz przez macierz (odchodzi mnożenie przez macierz projekcji, ale pozostaje przemnożenie promienia przez macierz widoku, a jeśli jakiś obiekt jest przesunięty/obrócony/przeskalowany to mnożysz wszystkie jego punkty przez macierz transformacji (jest to bardzo szybkie, bo nie musisz liczyć przekształceń dla każdego z tych punktów, a jedynie raz i później tylko szybkie mnożenie przez macierz... no szybkie jak się ma "normalną" ilość pkt ;p), jak dodatkowo chcesz animacje kości to mnożysz każdy wierzchołek przez N kości (trzymane najczęściej jako kwaterniony (ładniejsza interpolacja jest niż przy trzymaniu kątów eulera (nie zachodzi problem gimbal-lock)), z których robi się macierz i mnoży) - N to liczba kości dla których wierzchołek ma wagę większą niż 0). Przekształcanie za pomocą macierzy/kwaternionów jest nieodłącznym elementem matematyki 3d, niezależnie czy to śledzenie promieni czy rasteryzacja (tu w OpenGL/DirectX od lat jednak wszystkie mnożenia przez macierz, razem z animacją szkieletową robi się na GPU (ostatni duży tytuł jaki pamiętam który animację szkieletową robił na CPU to Doom3 i nie bez powodu jest tam zawsze mało obiektów animowanych za pomocą kości na raz (procek nie wyrabiał z dużą ilością obliczeń, a jeszcze miał na głowie fizykę, muzykę...))). Wiem jak szybko się rozwija sprzęt, wiem jakie nowinki się pojawią, wiem jak działa UD - tu nie ma mowy o wrużbach - to jest normalna prognoza oparta o twarde fakty... dodatkowo jedyne firmy władne stworzyć wydajny sprzęt wyraźnie mają UD w poważaniu. Czy Ty myślisz, że nVidia i Amd (któremu zyski przynosi tylko grafika Ati, a procki straty) postanowiłyby czekać na zagładę zamiast wykupić ich zdmuchnąć z pola widzenia na jakiś czas? Lub intel nie zwęszyłby okazji do sprzedaży większej ilości wydajnych procków kosztem rynku kart graficznych? Czy może, że te firmy nie stać na wykupienie projekciku amatorów-hobbistów (bo tak są określani w środowisku gamedev i sami się tak określają)? Ostatecznie czy uważasz, że rację mają praktycznie wszyscy związani z gamedev, czy ludzie, którzy potrafią mówić w prezentacji, że ich technologia jest tak samo unlimited jak unlimited jest wyszukiwarka google (jak ktoś czytał to wie jakie mają tam klastry, jakie zbiory danych i jak bardzo narzekają, że to są straszne dla nich limity i muszą cały czas powiększać klastry i przestrzeń pamięci)? Twórcy UD już na samym początku trochę bawią, bo szukają problemu tam gdzie go nie ma (w ilości poligonów). Dzisiejsze karty graficzne potrafią renderować niesamowite ilości geometrii i nie znam gry w której geometria była wąskim gardłem. Geometria mogłaby być znacznie gęstsza, kosztem efektów, shaderów i ogólnie pikseli. Jednak gry idą w przeciwną stronę świadomie - bo jakby siatka gęsta nie była to realistycznie nie będzie - realizm robią shadery pikseli, które pożerają prawie całą moc kart w dzisiejszych grach - gry bez SSAO, SSDO, light scattering, atmosphere scattering, deferred shading, motion blur, depth of field i wielu innych efektów mimo gęstej siatki stałyby się bardzo mało realistyczne. Teraz mamy programowalną tessellacje, która załatwia sprawę tak, że wilk jest syty i owca cała (a UD nie ma co już szukać nawet tu).

Od lat się stosuje (tylko się tak nie nazywa tego) - to po prostu zwykła normalmapa, która służy do przesunięcia wierzchołka według wektora zapisanego w normalmapie (zwykła mapa diplacement nie ma kierunku wektora, i jest tylko wartością skalarną która mówi o ile przesunąć wierzchołek względem normalnej (tu po prostu nie modyfikuje normalnej z geometrii normalną z tekstury)). Jest to możliwe od ~SM3 (od kiedy jest możliwość odczytania tekstury z poziomu Vertex Shadera (DirectX 9.0c)).

Nie atakuję po prostu mówię jak jest. Co więcej ciężko mówić o raczkującej technologii, bo wszystko co w niej wykorzystano jest od lat używane przy poligonach, a i same chmury punktów nie są nikomu obce. Ja nie mówię, że grafika jest słaba ze strony którą robi grafik... a od strony technicznej za którą odpowiadają programiści. Co do filmików to oglądałem je jakiś czas temu (myślę, że było to gdzieś w Q1 2010, jak nazwa filmików brzmiała słusznie propaganda2009) i to co mówią jest po prostu w wielu miejscach śmieszne... ale wracając do rzeczy to nie musisz mieć super maszyny, żeby uzyskać taki obraz jak na filmiku (mimo, że jeśli dobrze pamiętam jest z 15 FPS czasami mniej i się tnie), ale przy geometrii gdzie 90% nie jest instancją jednego obiektu (a 5% innego), oraz przy zbliżonej jakości i efektach do gier z 2005 roku to trzeba czekać kilkanaście lat co najmniej na sprzęt... a grafika poligonowa zrobi w tym czasie olbrzymi postęp (już teraz ilość geometrii nie jest praktycznie problemem, a problemem jest szyna pamięci (procek musi przesłać dane do karty co długo schodzi)... no przy statycznej grafice i instancingu (jak tu) to można renderować niewyobrażalne ilości tri... jednak jest jeszcze bindowanie które też pożera dużo czasu (ale nVidia i Bindless graphic i już jest po problemie, a geometria ląduje w gpu do 7x szybciej)). Tesselacja drzew iglastych wygląda tak - na wyciągnięcie ręki nie widzisz każdej igiełki, tylko te które są do ciebie pod kątem bliskim 90 stopni (wystarczy bilbordowany prostokąt z teksturą z przezroczystością i nie zobaczysz różnicy praktycznie), a jak się zbliżasz kamerę blisko to wkracza do gry tesselacja (i masz igiełki wystające ładnie z dokładną geometrią (z tego czworokąta z teksturą wyskoczą tak jak będzie na teksturze disp/normal)). O las i chodzenie w nim nie masz się martwić (dalsze gałęzie nie będą poddane tesselacji jeśli nie potrzeba (nie ma blisko kamery)). Co do tessellacja będzie potrzebować coraz lepszego sprzętu... to też nie do końca prawda, bo tesselacja już praktycznie eliminuje problem tego, ze widzisz poligony na scenie (dalsze przyspieszanie kart będzie dotyczyć tak jak od prawie 10 lat, nie powiększeniu ilości poly na scenie, a większej mocy obliczeniowej do shaderów (coraz lepsze GI, bardziej naturalny scatering atmosfery (i wpływ jej na oddalone obiekty), hybrydy z raytracingiem...)). Pościg za ilością poly skończył się dawno, a teraz już prawie się zakończył (tessellacja + shadery contol/evaluation którymi możesz kontrolować tesselację jak i modyfikować pozycję punktów praktycznie wyeliminował problem). Nigdzie nie mówiłem, że w tym momencie znajduje więcej niż jeden. No i tu są dwa podstawowe problemy: - nie tak łatwo znaleźć 5 najbliższych punktów (ostatnio jak miałem informacje na temat UD to mówili, że przy tych scenach drzewo kończyło im się na setkach tysięcy punktów (brakowało im ramu pewnie na bardziej dokładne drzewa) - i wśród nich trzeba szukać) - jak znajdziesz 5 najbliższych to będziesz miał sieczkę, a nie normalną (punkty nie są ładnie ułożone w równych odległościach i z każdej strony jak w voxelach) - jak te 5 najbliższych będzie blisko siebie po jednej stronie to co? Będzie zupełnie błędna normalna bo jeden dalszy punkt z drugiej strony bardziej zmienia normalną niż te 5 bliskich... to powiesz, że szukasz 100 najbliższych punktów (ale jak są one źle ułożone to znowu jeden punkt którego nie weźmiesz pod uwagę niszczy Ci normalną (bo pod kontem 180 stopni nie znalazłeś żadnego innego, a dodatkowo był stosunkowo daleko więc on bierze połowę wag i jest tak samo ważny jak tysiąc po drugiej stronie (tak samo jak w poligonach - im większa powierzchnia tri tym większa waga przy uśrednianiu normalnej))). W Zbrush nie ma mowy o trilionach punktów i więcej jak w wypadku UD, nie opiera się o chmurę punktów tylko poligony (pewnie mówisz o HD Geometry, czyli normalna siatka + tessellacja + malujesz po teksturze (malujesz po obiekcie, a program zapisuje do tekstury) która służy do przesuwania wierzchołków po tessellacji), a w grach chodzi o to, żeby obiekty nie były powtarzalne, (a jeśli już takie samo to animowane inaczej, inaczej wpływ wiatru ma być innaczej reagować na interakcje z użytkownikiem... a animacja chmur punktów, jest wielkim problemem (w najlepszym przypadku (animacji szkieletowej) miliardy punktów musisz mnożyć przez macierz, żeby zrobić ruch... wtedy drzewo wyszukiwania się wali bo zmieniają położenie)), więc o instancingu takim jak mówisz nie ma mowy (taki sam instancing możesz zrobić z geometrią i będzie bardzo wydajnie... a widziałeś, żeby jakaś gra korzystała z tego?). // Postanowiłem zedytować i dopisać to, bo przypuszczam, że mądrzyłbyś się, że Zbrush działa na kartach bez tessellacji i w sumie miałbyś rację... ale tam obiekt jest statyczny, więc tessellacja może być liczona na CPU przy przy ustalaniu szczegółowości, i wysłany raz do karty (a vertex shader + tekstura odpowiedzialne są za przesunięcia). To tylko przykład, a to, że mówisz o milionach igieł to mnie nie obchodzi (i tak takiej ilości, a z bliska możesz ustawić jaką chcesz ilość geometrii bo karta to zniesie (jeśli chcesz każdą igiełkę oddzielnie to rób nawet instancing, żeby tesselatorów nie męczyć, ani szyny danych i masz to samo)). Mogą... za wiele, wiele lat kiedy to już nikt o ud pamiętać nie będzie, a grafika poligonowa, będzie pójdzie wiele lat do przodu. Możesz napisać jakie znane dane chciałbyś w tym wypadku interpolować? Pytam z ciekawości.

Tylko w UnlimitedDetail nie możesz wykorzystać kilku punktów, a kilkaset, kilka tysięcy punktów z najbliższego otoczenia i liczyć powierzchnie każdy z każdym, co już jest wyzwaniem olbrzymim. Żeby upchać normalną trzeba ją na początku obliczyć (i tu jest pies pogrzebany, bo obliczenie normalnych dla wszystkich punktów na scenie nie jest w tej technice możliwe nawet mając dni czy miesiące na obliczenia) i właśnie dlatego tych normalnych tam nie ma. Siggraphowe nowinki, mają solidne podstawy i dodatkowo coś dają. Tu ta technologia nic nie daje (a wręcz dużo zabiera), a trzeba czekać na sprzęt 10-20 lat, żeby osiągnąć tym sposobem grafikę jak za lat 90tych. Ja oceniam tą technologie dokładnie przez to jak ją opisali (zebrali to co od lat 90 programowanie grafiki poznało, i zrobili to coś, co może ładnie wygląda, bo jest bliska naturze (punkty to atomy w normalnym świecie), ale żeby osiągnąć grafikę na poziomie dzisiejszych wierzchołków trzeba czekać dziesięciolecia, a wtedy albo siatki będą już wiele poziomów wyżej (tym bardziej, że już teraz z tesselacją siatka ma więcej wierzchołków i dokładność (nie mówiąc już o jakości i realizmie) niż grafika na Unlimited Detail)). Jak pokazano w demo nie nadaje się do kamieni, roślinności... i ogólnie do grafiki ;p. Nie wolę płaskich trójkącików (wolę tessellację gdzie mam wszystko wydajnie, nie tracę nic z efektów, oświetlenia etc. a mam gęstą siatkę która się ładnie LoD'uje). Tak tylko te przykłady potrzebowały tylko troszkę lepszego sprzętu i dzięki nim był zysk jakości obrazu. Tu jest strata jakości, a żeby idealny sprzęt do tego (CPU) przyspieszył tak bardzo trzeba czekać z 10-20 lat (aż procki porzucą krzem na grafen), a i wtedy będzie słabo z wydajnością. Nie traktyhe wybiurczo tylko to było komentarzem do fragmentu w którym mówiłeś o samym czysty, UD, a do tego, że nie wszędzie się nadaje odniosłem się później (bo nie nadaje się do niczego) Jak to nie? Właśnie to zrobi (jak kamera zbliży się do gałęzi to siatka się zagęszcza i jest przemieszczana za pomocą normalmapy lub displacement mapy) - dzięki temu jak jesteś blisko widzisz każdą igiełkę, a jak jest daleko to nie (dzięki temu automatycznemu LoD jest wydajnie i nie potrzeba gigantycznej ilości pamięci (co więcej nie traci się innych zalet siatki)). //edit: pewnie chcesz przykładu to masz (2:37 nie ma "igiełek" (kolców), 2:40 już ma (a to co daleko siatki nie zagęściło bo nie było sensu)):

Jeśli nie chcesz mieć np. na prostej ścianie po zbliżeniu kamery takich artefaktów http://img22.imageshack.us/img22/6489/31224541.jpg to w najbliższym otoczeniu musi być olbrzymia ilość punktów (już pomijam takie oczywiste rzeczy, jak to, że prosta ściana normalnie to 4pkt i jest idealnie płaska... a tu nawet z milionem punktów będzie nienaturalna i będą takie artefakty (za duże żeby tłumaczyć nierównością tynku, co lepiej symuluje i tak normalmapa)). Możesz powiedzieć o czym mówisz, bo przez dekadę, którą zajmuje się praktycznie tylko tym nie zauważyłem nic co źle rokowało na starcie i okazało się przełomowe... ofc były rzeczy, które od ukazania się na Siggraph czekały przez 5-10 lat na wprowadzenie w grach, ale od razu było widać potencjał i perspektywy, tylko trzeba było przez lata optymalizować i przyspieszać sprzęt - w tym wypadku nie ma ani potencjału, ani perspektyw. Ja też nie widzę zagrożenia, bo takiego nie ma, natomiast nie spodziewałbym się takich hybryd, bo to co zrobione za pomocą chmur pkt odstawało by strasznie jakością, a do tworzenia roślin i innych takich elementów się zdecydowanie nie nadaje. Normalnej (wektor prostopadły) do punktu w 3d nie da się określić (jest ich nieskończenie wiele). W 3d można określić tylko normalną do płaszczyzny i nie bez powodu grafika 3d opiera się o trójkąty (jedyny wielokąt którego wszystkie wierzchołki znajdują się zawsze w jednej płaszczyźnie). Masz trójkąt ABC (wektory AB, BC, AC i przemnożone przez -1 (czyli BA...) należą do płaszczyzny), więc żeby obliczyć do niego normalną bierzesz wektor AB i mnożysz go wektorowo przez wektor AC (wynikiem iloczynu wektorowego jest zawsze wektor prostopadły do mnożonych wektorów) i masz normalną do płaszczyzny (czyli dla wszystkich punktów A, B i C).

@ziomuś: Cienie, a cieniowanie to dwie zupełnie inne sprawy ;]. Cienie to jeszcze pół biedy, bo da się już zrobić przy ~2x (przy jednym świetle) stracie wydajności w porównaniu z bez cieni (tak jak rzucasz promień z kamery i szukasz chmury, żeby znaleźć najbliższy punkt, to rzucasz z tego punktu w kierunku źródła światła i szukasz chmury dla tego promienia). Cieniowanie to opis jak materiał zachowuje się pod danym wektorem światła i wektorem oka - czasami zależy od kąta pomiędzy wektorem oka, a wektorem od światła do punktu odbitym od normalnej (Phong), czasami jest to wektor połówkowy (wektor pomiędzy podanymi wektorami), i sprawdza kąt pomiędzy nim, a normalną (Blinn) - (jakiego modelu cieniowania byś nie wybrał np. Phong, Blinn, Oren–Nayar, Cook–Torrance, Lambert, Ward isotropic/anisotropic, Strauss, Ashikhmin-Shirley, czy jaki sobie nie wymyślisz który ma naśladować realizm (nawet toon), musi wykorzystać normalną). Jasne, że jestem sceptycznie nastawiony, bo programuję grafikę nie od dziś i wiem co w UD piszczy. UnlimitedDetail nie działa na GPU z bardzo prostej przyczyny - tego typu obliczenia, na GPU są niemożliwe ze względów wydajnościowych, a ilość ramu nie jest wystarczająca dla danych (tu bardziej nadaje się CPU i na nim rendering jest szybszy). Na wyliczenie podobnej jakości grafiki jak podali w galerii za pomocą siatki i rasteryzacji na CPU jest bardzo szybkie i działałoby w RT (sam pisałem rasteryzer CPU z optymalizacjami jednostek wektorowych SSE2 i mówię Ci, że nie ma z tym problemu - instancing (tu z pewnością jest, i wszystkie te powtarzalne obiekty to jeden obiekt w pamięci, powielany jako instancja), dobre drzewko do przyspieszania testów widoczności w bryle widoku i zasłonięcia i idzie rendering na GPU jak burza (nawet raytracery realtime z siatką są na CPU z teksturami i odbiciami)). Sąsiednie piksele na renderze nie mają nic wspólnego z normalną w punkcie, a przechowywanie danych o nielimitowanej liczbie sąsiadów wymagałoby niewyobrażalnej ilości pamięci (a na same pozycje nielimitowanej ilości pkt im brakuje ramu, nawet mimo, że widać, że stosują instancing i renderują te same punkty (ten sam model) w wielu miejscach (w normalnej grze (nie takim demie) to nie przejdzie i ramu braknie choćbyś nie wiem ile go miał)). Co do samych chmur pkt jestem pozytywnie nastawiony i sam je wykorzystuje w renderingu (póki co jeszcze testuję wydajnościowo i jakościowo moją implementację), bo napisałem ostatnio GI do rasteryzera oparte o chmurę punktów, gdzie też tak jak w UD stosuje "wyszukiwanie w strukturze drzewa" punktów (i działa całkiem nieźle... przy rzadkiej chmurze punktów (detale nie muszą być małe... mogą być duże, bo to tylko oznacza, że z tamtego miejsca odbija się takie światło i nie musi być wiele detali, nie trzeba normalnych etc.)).

@ziomuś: Bez normalnej nie obliczysz padania światła, odbicia... praktycznie wygląda to tak, jak na przykładach (nie ma normalnej, nie można obliczać shaderów (bo praktycznie wszystkie shadery materiałów i składowe spectular/difuse/... są liczone tylko dzięki normalnej do powierzchni (do obliczenia koloru potrzebne jest odbicie (kąt odbicia światła... a światło odbija się według praw fizycznych względem normalnej i bez niej tego nie ustalisz)), a jeśli nie masz normalnej to nie masz oświetlenia (tak jak w przykładowych obrazkach)). Choćbyś nie wiem ile miał punktów, bez normalnych nic nie zrobisz. Shadery mogą być, ale bez normalnej nie zrobisz materiałów, jakie przeważnie chcesz uzyskać (nie shadeless)... a moc obliczeniowa którą trzeba do zdobycia normalnej jest "unlimited".

To ja Ci już mówię, że to nie wyjdzie nigdy poza ciekawostkę, bo się nie nadaje do normalnego zastosowania, a uzyskanie takiego efektu jaki mamy dziś w grach jest z tym praktycznie nie możliwe (ciężko nawet uzyskać normalną (no chyba, że mamy na to nielimitowany czas), i nie bez powodu nie ma co szukać, na obrazkach/filmikach shaderów/gi... (są tylko cienie bo wymagają stosunkowo mało obliczeń (przeszukać drzewo czy w kierunku światła widzi chmurę pkt))). Unlimited detail to tylko sposób na wyciągnięcie kasy (żeby się dowiedzieć chodź odrobinę szczegółów i trzeba z tego co pamiętam ich dofinansować... a dowiesz się tego, że nigdy nie będzie użyteczne).

To nie są voxele tylko o point cloud, a jest to rzecz, która jest strasznie do dupy i jakość obrazu strasznie spada w porównaniu do dzisiejszych gier (nie bez powodu, nie ma tam cieni czy są tak słabe shadery - po prostu sposób przechowywania danych te rzeczy tak utrudnia, że wprost nie da się zrobić tego w czasie rzeczywistym)... a samo unlimited dotyczy się również sprzętu - do tego musisz mieć nielimitowaną pamięć i nielimitowaną moc obliczeniową. Niekoniecznie za pomocą Beast - mogłobyć wypalone za pomocą jakiegokolwiek programu graficznego (Blender (Bake, Full Render i Radiosity i też będzie w grze GI ;p), 3ds Max, Vray) - po prostu obiekty mają 2x UV i drugie uv służy do lightmap (dawniej wypalało się tylko cienie, a teraz już całe GI idzie i nawet na telefonach w grach jest takie GI). Na grach się znasz - chociaż to są gry których ciężko nie lubić ;p - (chociaż w wypadku Syberii/Dreamfall (i częściowo TLJ) nie ma mowy o prerenderowanych rzeczach - Dreamfall wszystko idzie w RT. Syberia to normalne postacie 3d renderowane RT, a tła nie są prerenderowane... tylko malowane (niektóre w TLJ też)). Voxele prawdopodownie nie będą nigdy w grach. Jednak zastanawia mnie to co mówisz, bo w wypadku Voxeli też jest obraz przekształcany do 2d (musi być przekształcony do obrazu 2d NxM pikseli taki jak ekran może wyświetlić). Tu nie ma różnicy pomiędzy między voxelami, a siatką gdzie punkty są 3d (w obu przypadkach, masz punkty zawieszone w przestrzeni 3d (w wypadku voxeli po prostu marnujesz sporo pamięci i czasu), a raytracing/rasteryzacja przekształca dane 3d do 2d (rasteryzacja przed obliczeniami shaderów i kolorów, przez co trudniej o GI czy odbicia, ale za to jest dużo wydajniej)). Fajnie... tylko, że to co pokazałeś nie ma nic wspólnego z voxelami, a jak sama nazwa filmiku wskazuje cząsteczkami (tu nie ma NxMxK rozdzielczości z góry ustalonej i z góry ustalonej szczegółowości której nie możesz sobie zwiększyć w trakcie działania tak jak w Voxelach - tu są cząsteczki, czyli luźno zawieszone w przestrzeni punkty (nie marnuje się miejsca, czasu, cząsteczki mogą iść gdzie chcą (nie ogranicza się z góry, że przestrzeń ma ograniczone wymiary NxMxK, tylko może w trzech wymiarach wyskoczyć cząsteczka gdziekolwiek chce))). To co pokazałeś to normalny fluid, który za chwilę będzie dostępny w praktycznie każdej grze (teraz mimo promowania przez nVidię nie wchodzi, bo działa tylko na PhysX i kartach nVidii w przyzwoitym czasie... pod koniec roku jednak wychodzi Bullet Physics 3.0 który będzie liczył za pomocą OpenCL (czyli działa zarówno na nVidii, Ati, prockach Intel(ma wydać implementacje na swoje CPU pod koniec roku)/AMD czy ARM/PPC)). PS. to co pokazałeś polega na tym samym co tylko tu jest słabszy renderer (ale można już się zbliżyć do tego co pokazałeś, w czasie rzeczywistym - nie będzie jeszcze to samo (bo tu inny renderer jest, który nie musi się spieszyć z renderingiem), ale już blisko) PS. Co śmieszniejsze rendering takich fluidów w grach idzie już zupełnie w 2d (w przestrzeni ekranu) ;]. Tu masz papierek: http://developer.download.nvidia.com/presentations/2010/gdc/Direct3D_Effects.pdf Podsumowując voxele nic nie dają poza spowolnieniem i większym zapotrzebowaniem na ram... to, że modele są kanciate to nic (dasz tessellację i nie będzie, a będzie i tak wydajniej niż voxele (co więcej tu spodkasz się z aliasingiem, a robienie antialiasingu 3d (żeby nie mieć kantów) zabije każdy sprzęt)). Co ma piernik do wiatraka? Te błędy nie mają nic wspólnego z siatką trójkątów i będą tak samo w grafice opartej na voxelach (z mapowaniem tekstury to mnie rozbawiłeś do łez) - tu nie jest problem trójkątów, tylko wydajności i optymalizacji (a takie rzeczy jak dym, najlepiej robić na cząsteczkach (punktach, 3d zawieszonych dowolnie w przestrzeni, a nie na voxelach) - zresztą tak w grach się robi od prawie zawsze, tylko wcześniej bez wolumetryki i aby było wydajniej cząsteczką był duży (często wielkości odpowiedniej kilka metrów^2) czworokąt ustawiony pod kątem prostym do ekranu - przez co były artefakty czasami, ale ogólnie było dużo wydajniej i artefakty były usprawiedliwione) Ekranu nie przeskoczysz, a póki co nie każdy ma hologram w domu (w innym wypadku niezależnie jak generujesz obraz dostajesz 2d). Z tym, że chciałem się zapytać czy Ty naprawdę myślisz, że my widzimy oczami 3 wymiary? Oczy to optyka generująca obraz 2d (tak jak aparaty fotograficzne) - po prostu do oka wpada promień światła i uderza w komórki światłoczułe które są z tyłu oka (po prostu uderza w odpowiedni piksel 2d - mamy bardzo dużą rozdzielczość, bo tych światłoczułych punktów jest dużo ale to dalej 2d (i to dodatkowo tak jak w ekranie lcd/matrycy aparatu, za kolory odpowiadają inne punkty (przez co jak są uszkodzone niektóre to mamy subpiksel (jak jest dużo wypalonych tego samego typu to człowiek jest daltonistą)))) - człowiek właśnie widzi tylko obraz 3d przekształcony do 2d (przestrzeni ekranu/oka). No chyba, że mówiąc o 3d masz namyśli 2x 2d z przesuniętymi obiektywami (czyli stereoskopię), ale to zupełnie inna bajka i też nie widzę przewagi voxeli (które nie są bardziej 3d od punktów 3d w siatce (wręcz przeciwnie)).

Link nie działa, ale ktoś kto ściągnął może powiedzieć czym różni się od tego co prezentowali rok temu? http://www.geeks3d.com/20090811/light-propagation-volumes-in-cryengine-3/

Z tego co zauważyłem to nie ma tu mowy o różnych teksturach (chociaż też by się dało po prostu przesłać 2x atrybuty TexCoord zależne od strony, i dwie tekstury... lub lepiej tablicę tekstur (multiteksturing) do shadera i tam w zależności czy normalna jest skierowana w stronę kamery decydować co i jak ;] - wszystko się da ;p). @n-pigeon: Zastanów się czy nie lepiej mieć obie strony jako osobne siatki (kopia i flip normals), bo i tak to tak działa dla OpenGL (jak renderujesz dwustronnie to karta i tak 2x renderuje każdy tri (jedną i drugą stronę osobno)).

@Adek: Jeśli chcesz robić animacje z użyciem rendererów GPU, to myślę, że się opłaca (bo karty dla graczy (dużo tańsze) mogą nie wystarczać z powodu małej ilości pamięci), bo taniej wyjdzie niż podobnej wydajności klaster CPU... ale jeśli chcesz statyki i nie odpowiadają Ci renderery, które są dostępne na GPU to jest zupełnie nieopłacalna ;]. OFC w przyszłości coraz bardziej będą takie karty opłacalne (fizyka/fluidy... też dostają kopa liczone na GPU, ale póki co niewiele takich silników jest, a w programach graficznych praktycznie ich się nie wykorzystuje jeszcze)... i w przyszłości takie karty pewnie będą też sporo tańsze (bo więcej osób będzie je kupować - chociaż amatorzy będą kupować i tak GeForce i starać się nie przesadzać z rozdzielczością tekstur i złożonością scen ;p). Rynek nie zmieni się jednak z dnia na dzień i chwile jeszcze takie karty będą opłacalne tylko dla niektórych... w przyszłości (nie mówię o roku czy dwóch) pewnie będzie to prawie obowiązkowy sprzęt (no i jeszcze jest pytanie czy do tego czasu GPU dla graczy nie dostanie takiej mocy, że i tak profesjonalne karty będą zbędnym luksusem).

@n-pigeon: "Dzięki CUDA" może być źle zrozumiane - CUDA dla większości to soft, a to dzięki nowej architekturze sprzętowej CUDA w Fermi obliczenia są szybsze, a obliczenia podwójnej precyzji jeszcze szybsze (w starej serii, był tylko 1 na 8 procków potrafiących liczyć taką precyzję, a teraz w tej serii Quadro, miało ich być 1 na 2 - czyli w poprzedniej serii jak procków strumieniowych było 240 to tylko 30 liczyły fp64, a teraz jak jest ich do 896 to 448 jest fp64)

ctrl+r i wpisać ile, lub zaznaczyć krawędź i w->subdivide

Akurat w takim wypadku o którym mówisz też, nie uzyskałbyś ładniejszego przejścia.

Nie da się (to chyba jasne, bo wierzchołki nie mają nic do gadania w teksturze (materiał już ma więcej wspólnego i tam możesz połączyć dane wierzchołków z teksturą)).

@Muddy: na 3D konsole są za wolne (już teraz wiele gier nie wyrabia nawet słabszego HD i na tv 1080 gra się z rozdzielczością ~600... przy 3d ta rozdzielczość może być nawet 300 (czyli praktycznie nie da się grać ;p)). Microsoft Kinect, czy PlayStation Move robiące z ich konsol alternatywę dla Wii przedłuży trochę życie konsol (bo tak na prawdę sprzęt już się chwilę nie sprawdza i już wypadałoby wymienić)... przeciągnie pewnie do czasu jak było planowane (czas życia PS3 miał być 10 lat (ale zakładali, że xbox nie będzie tak popularny i nie będzie im się spieszyć), czyli 7-8 lat jako najnowsza konsola, i 2-3 lata jako konsola starszej generacji, ale na którą dalej wychodzą gry (tak jak żyła sobie PS2 w czasie przejściowym) - więc pozostało max kilka lat do wydania nowej konsoli).