Dynamiczna globalna iluminacja w CryENGINE 3

[norden]

Nie zepsuł uwierz mi ;) ale rozkręcił wątek... Poza tym fajnie jest usłyszeć że gadasz bzdury jeżeli mówi to osoba która więcej wie na te tematy... Każdy kto poczyta się czegoś dowie... Zarówno od bełkoczacego nordena jak i od Skotiego który zna aktualne ograniczenia i możliwości sprzętu...

Czy jak to było kto bełkotał w koncu.. bo ja już nie wiem?

[Gość Gosc]

Tjviking: Ok, wyjasnienie mojego posta dla : Nie pytalem sie jak sie oblicza normalna dla powierzchni, po to wiem od liceum. Odnioslem sie do posta mokramyszka666, gdzie pisal o obliczaniu normalnych dla pointclouds :) Bardzo bym chcial wiedziec jak cos takiego zrobic...

 

EDIT: Jak dla mnie jedynym sposobem na obliczanie takich normalnych jest pogrupowanie punktow w strukture siatki czyli z pointclouds robi sie znowu siatka polygonow. Ale moze czegos nie chwytam.

 

dla chmury punktow nie trzeba tworzyc geometrii, wystarcza wielomian interpolujacy, a normalna to efekt uboczny wielomianu

[Skoti]

Skoti - nie rozumiem dlaczego z taka zajadloscia atakujesz raczkujaca technologie (ktorej autorzy zaznaczyli ze nie sa grafikami wiec ich twory moga wygladac slabo ;)). Sluchales w ogole tych kolesi na jakiej zasadzie dziala to ich demo? Wlasnie w tym rzecz ze nie musisz juz miec superkomputera zeby to generowac.

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)).

 

Tesalacja jest fajna ale tez sie posmarka jek bedziesz chcial wygenerowac galaz z igielkami , bo te igielki sa widoczne juz na wyciagniecie reki i to juz by byly grube tysiace poly. A teraz wez sobie spojrzyj z bliska na drzewo gdzie tuz przy kamerze masz tysiace igielek z ktorych kazda ma ilestam poly... Powodzenia w chodzeniu po lesie.. (no i jak wyobrazasz sobie uproszczenie geometrii galazki z igielkami z ktorych kazda jest czescia obiektu? Jak sie oddalisz to sie zamieni.. na klocek z namalowanymi iglami czy jak? Z tesalacja wciaz jestes skazany na rozwiazania znane od lat - to tylko usprawnienie ale nie przelom). Fajnie, ze lubisz tesalacje ale nie stanowi ona panaceum na wszystkie bolaczki - kamienie w murze to nie to samo co listki i igielki czy trawa.

Niemal wszystkie nowosci i prototypy w fazie raczkowania (ci goscie chyba dopiero szukaja inwestorow - ten ich pokaz bardziej traktowalbym jako proof of concept niz pokaz mozliwosci) nie wygladaja zachwycajaco. Wrozysz z fusow ze potrzeba dziesiecioleci zeby dalo sie to wykorzystac. Moze tak, moze nie - ale bycie takim zamknietym na nowinki jest bezsensowne. Zobaczymy co z tego wyjdzie - na pewno jest to bardziej obiecujace niz tesalacja ktora zeby byc lepsza bedzie potrzebowala coraz to lepszego sprzetu. Na razie cieszmy sie tym co mamy a potem zobaczymy co przyniesie przyszlosc.

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).

 

Alibaba: napisałem wcześniej o co mi chodziło z wyliczeniem normalnej. Rozpatrując od początku: masz algorytm, który dla konkretnego pixela w drzewie chmur punktów odnajduje ten konkretny żeby go wyświetlić. Specjalnie dla Skotiego wyjaśnienie: nie, nie znajduje setek tysiecy tylko ten jeden konkretny.

Nigdzie nie mówiłem, że w tym momencie znajduje więcej niż jeden.

 

 

Podobną metodą, można przeszukać otoczenie tego punktu szukając, dajmy na to, 5 najbliższych punktów, które w tym niewielkim otoczeniu tworzą styczną do płaszczyny i dalej już wiadomo.

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))).

 

Odnośnie przechowywania/generowania normalek: zbrush robi to w kilka minut, a nie dni. Obudź się Skoti. Tu nie trzeba liczyć normalnych dla wielkiej sceny, bo wystarczy dla jednej igły która jest potem transformowana i rozmieszczana na gałęziach.

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).

 

Odnośnie fragmentu filmiku (2:40) ja mówię o milionach igieł a ty mi pokazujesz 5 kolcow na krzysz. Z czym do ludzi??

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)).

 

I na koniec powtórzę tylko po raz trzeci, bo ciągle nie dociera - wszystkie te przerażające obliczenia o których mówisz mogłoby załatwić rozwiązanie sprzętowe, dedykowane temu konkretnemu problemowi.

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.

 

dla chmury punktow nie trzeba tworzyc geometrii, wystarcza wielomian interpolujacy, a normalna to efekt uboczny wielomianu

Możesz napisać jakie znane dane chciałbyś w tym wypadku interpolować? Pytam z ciekawości.

Edytowane 9 Sierpień 2010 przez Skoti

[Nezumi]

Chyle czola przed wasza wiedza magiczna. Powaznie.

Dla mnie to rybka tak na prawde co bedzie koniec koncow - wiadomo ze slabsza technologia nie wyprze lepszej wiec... cokolwiek by nie bylo bedzie tylko lepsze ;)

 

Jak juz tu panowie dzielicie sie madrosciami - a co z uzyciem w grach vector displacent map? Jak to technicznie wyglada?

[Skoti]

Jak juz tu panowie dzielicie sie madrosciami - a co z uzyciem w grach vector displacent map? Jak to technicznie wyglada?

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)).

[mokramyszka666]

@Skoti: ty bez przerwy zakładasz że wiesz wszystko na temat UD, a gdyby tak było (np. teoria, że ich konstrukcja drzew się nie nadaje do szybkiego wyszukiwania punktów) to nie widziałbyś płynnego odświeżania sceny 3d w tym demie. Śmiem zatem podejrzewać, że stoją za tym trochę mądrzejsi ludzie od ciebie, i możliwe że właśnie te elementy, których nie rozumiesz/nie znasz, sprawiają, że ta technologia jest krokiem na przód. Co do otoczenia punktu w chmurze - to już kwestia sensownego generowania punktów - należy dążyć do tego aby były rozłożone jak najrównomierniej. Tego, jak jest to rozwiązane w UD nie wiesz, a możesz jedynie podejrzewać na podstawie dostępnych informacji. Szczegółów działania UD nie znasz, inaczej nie byłoby tej dyskusji, bo posiadałbyś argumenty a nie domysły.

Odnośnie instancji, tu mogę się mylić, ale podejrzewam, że UD generuje obraz inaczej niż standardowe 3d, a bardziej jak raytracing. Nie ma zatem potrzeby mnożenia miliona punktów przez macierz, bo wystarczy do niej wciągnąć rzucany promień. I tu zaczyna wychodzić prymitywne działanie dzisiejszego 3d.

A co do sprzętu... tutaj też oczywiście stawiasz wróżby nie mając nic poza domniemaniem. Nie zdziwiłbym się gdyby takie rozwiązania sprzętowe były już w fazie testów, i wiem, że jeśli nic w tym temacie nie drgnie przez najbliższy czas to UD czeka marny los.

[Skoti]

@Skoti: ty bez przerwy zakładasz że wiesz wszystko na temat UD, a gdyby tak było (np. teoria, że ich konstrukcja drzew się nie nadaje do szybkiego wyszukiwania punktów) to nie widziałbyś płynnego odświeżania sceny 3d w tym demie. Śmiem zatem podejrzewać, że stoją za tym trochę mądrzejsi ludzie od ciebie, i możliwe że właśnie te elementy, których nie rozumiesz/nie znasz, sprawiają, że ta technologia jest krokiem na przód.

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).

 

Co do otoczenia punktu w chmurze - to już kwestia sensownego generowania punktów - należy dążyć do tego aby były rozłożone jak najrównomierniej. Tego, jak jest to rozwiązane w UD nie wiesz, a możesz jedynie podejrzewać na podstawie dostępnych informacji.

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).

 

Szczegółów działania UD nie znasz, inaczej nie byłoby tej dyskusji, bo posiadałbyś argumenty a nie domysły.

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ę.

 

Odnośnie instancji, tu mogę się mylić, ale podejrzewam, że UD generuje obraz inaczej niż standardowe 3d, a bardziej jak raytracing. Nie ma zatem potrzeby mnożenia miliona punktów przez macierz, bo wystarczy do niej wciągnąć rzucany promień. I tu zaczyna wychodzić prymitywne działanie dzisiejszego 3d.

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ę...))).

 

A co do sprzętu... tutaj też oczywiście stawiasz wróżby nie mając nic poza domniemaniem. Nie zdziwiłbym się gdyby takie rozwiązania sprzętowe były już w fazie testów, i wiem, że jeśli nic w tym temacie nie drgnie przez najbliższy czas to UD czeka marny los.

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).

[norden]

ale fight... jeszcze troche i napiszecie SDK ; ). Pociesze cię Skoti..... polygony i tak ciągną druta...

Edytowane 10 Sierpień 2010 przez norden

[mokramyszka666]

To prawda, nie napisałem raytracera, ale odpuść sobie na przyszłość tłumaczenie matematyki na poziomie liceum bo się ośmieszasz. Skinning postaci robiłem jeszcze w czasach DOSu, chociaż rozumiem, że musisz sobie poprawiać humor pisząc oczywistości na 5 stron A4.

Akurat w przypadku UD taniej wydajnościowo jest transformować rzucany promień w przestrzeń elementu niż przemnażać 50 mln punktów żeby coś obrócić. Ja myślę o UD w kategoriach innych niż działanie typowego raytracera bo są to inne wielkości i inne problemy. Ty wolisz się trzymać swojego archaicznego podejścia i zakładać że jak już coś zostało opisane 10lat temu to nie ma sensu rewidować poglądów. Promień trafia w BB? wciągamy go do przestrzeni elementu i szukamy przecięć bez potrzeby ogromnych obliczeń. Ja cały czas traktuję elementy UD statycznie bo nie spodziewam się w ciągu najbliższych 50lat animowanych point cloudów w takich ilościach. Natomiast animowane elementy oparte na point cloudach jak najbardziej, to już kwestia animowania jednej transformacji.

 

EDIT:

tak, uważam środowisko gamedev za ignorantów, którzy jedyne co potrafią, to upraszczać zaawansowane rozwiązania stworzone przez innych, a które powstały z myślą o czymś większym niż biegający po ekranie kanciasty ludzik z karabinem. Sam się domyśl, czy żartuję.

Edytowane 10 Sierpień 2010 przez mokramyszka666

[Skoti]

To prawda, nie napisałem raytracera, ale odpuść sobie na przyszłość tłumaczenie matematyki na poziomie liceum bo się ośmieszasz. Skinning postaci robiłem jeszcze w czasach DOSu, chociaż rozumiem, że musisz sobie poprawiać humor pisząc oczywistości na 5 stron A4.

Z tego co piszesz uznałem, że przyda ci się lekcja podstaw.

 

Akurat w przypadku UD taniej wydajnościowo jest transformować rzucany promień w przestrzeń elementu niż przemnażać 50 mln punktów żeby coś obrócić. Ja myślę o UD w kategoriach innych niż działanie typowego raytracera bo są to inne wielkości i inne problemy. Ty wolisz się trzymać swojego archaicznego podejścia i zakładać że jak już coś zostało opisane 10lat temu to nie ma sensu rewidować poglądów. Promień trafia w BB? wciągamy go do przestrzeni elementu i szukamy przecięć bez potrzeby ogromnych obliczeń. Ja cały czas traktuję elementy UD statycznie bo nie spodziewam się w ciągu najbliższych 50lat animowanych point cloudów w takich ilościach. Natomiast animowane elementy oparte na point cloudach jak najbardziej, to już kwestia animowania jednej transformacji.

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))).

 

EDIT:

tak, uważam środowisko gamedev za ignorantów, którzy jedyne co potrafią, to upraszczać zaawansowane rozwiązania stworzone przez innych, a które powstały z myślą o czymś większym niż biegający po ekranie kanciasty ludzik z karabinem. Sam się domyśl, czy żartuję.

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ą.

[mokramyszka666]

Zacznę od końca: na Siggraph pojawiają się papery zarówno z dziedziny gamedev jak i poważne opracowania. Tak się składa, że śledzę poczynania autorów i zwyczajnie opowiadasz bajki twierdząc, że ludzie pracujący dla ILM czy prowadzący od lat badania na uniwersytetach pochodzą ze środowiska gamedev. Myślenie życzeniowe - z resztą jak w przypadku większości twoich nawiedzonych wypowiedzi.

Odnośnie animacji. W żadnym miejscu sobie nie zaprzeczyłem, a jedynie potwierdziło się, że nie rozumiesz tego, co mówię (lub w ogóle rozumiesz tylko to, co sam tu wylewasz). To, że każdy liść na drzewie będzie animowany nie wyklucza użycia jednej statycznej instancji (animacja transformacji, o czym pisałem w poprzednim poście). Każdy liść jest taki sam, lub istnieje kilka wariacji, a animowane są jedynie ich transformacje (czyli rotacja w tym wypadku). Rozwiązanie analogiczne do proxy w vrayu czy mentalu.

Co do pierwszego akapitu... Tu już mnie rozbawiłeś, bo podważyłeś sensowność podstawy działania większości raytracerów. Co z tego, że bounding box się przecina lub ma części wspólne? Drzewo jest przeszukiwane w celu znalezienia najbliższego punktu na drodze promienia, i dość oczywistym jest, że nie będzie to pierwszy trafiony.

To, że UD działa w miarę RT oznacza, że hierarchie są przeszukiwane bardzo wydajnie i tu według autorów można dopatrywać się wyjątkowości tej technologi. To czy obiekty są transformowane czy nie, jest drugorzędnym problemem. Być może w obecnej postaci powodowało to zbyt duże spowolnienie, bo jednak z jakiegoś powodu jedyną stosowaną transformacją jest tam przesunięcie, ale ja traktuję cały ten szum jako wstęp i myślę że wiele jeszcze na tym polu chłopaki zdziałają.

 

Jeszcze co do sprzętu: Caustic Graphics jest żywym dowodem na to, że nie potrzeba błogosławieństwa ani Intela ani nVidii, żeby wprowadzić w życie wsparcie sprzętowe swojej technologii.

 

Produkujesz się jak natchniony wypisując oczywistości nie tylko do mnie, bo już co najmniej jedna osoba z doświadczeniem zwróciła ci na to uwagę w tym wątku, i nie wiem, czy chcesz zrobić wrażenie na młodzieży, która dopiero zaczyna przygodę z komputerem czy na sobie samym. Stawiam na to drugie.

[Skoti]

Zacznę od końca: na Siggraph pojawiają się papery zarówno z dziedziny gamedev jak i poważne opracowania. Tak się składa, że śledzę poczynania autorów i zwyczajnie opowiadasz bajki twierdząc, że ludzie pracujący dla ILM czy prowadzący od lat badania na uniwersytetach pochodzą ze środowiska gamedev. Myślenie życzeniowe - z resztą jak w przypadku większości twoich nawiedzonych wypowiedzi.

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).

 

Odnośnie animacji. W żadnym miejscu sobie nie zaprzeczyłem, a jedynie potwierdziło się, że nie rozumiesz tego, co mówię (lub w ogóle rozumiesz tylko to, co sam tu wylewasz). To, że każdy liść na drzewie będzie animowany nie wyklucza użycia jednej statycznej instancji (animacja transformacji, o czym pisałem w poprzednim poście). Każdy liść jest taki sam, lub istnieje kilka wariacji, a animowane są jedynie ich transformacje (czyli rotacja w tym wypadku). Rozwiązanie analogiczne do proxy w vrayu czy mentalu.

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).

 

Co do pierwszego akapitu... Tu już mnie rozbawiłeś, bo podważyłeś sensowność podstawy działania większości raytracerów. Co z tego, że bounding box się przecina lub ma części wspólne? Drzewo jest przeszukiwane w celu znalezienia najbliższego punktu na drodze promienia, i dość oczywistym jest, że nie będzie to pierwszy trafiony.

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))).

 

To, że UD działa w miarę RT oznacza, że hierarchie są przeszukiwane bardzo wydajnie i tu według autorów można dopatrywać się wyjątkowości tej technologi. To czy obiekty są transformowane czy nie, jest drugorzędnym problemem. Być może w obecnej postaci powodowało to zbyt duże spowolnienie, bo jednak z jakiegoś powodu jedyną stosowaną transformacją jest tam przesunięcie, ale ja traktuję cały ten szum jako wstęp i myślę że wiele jeszcze na tym polu chłopaki zdziałają.

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.

 

Jeszcze co do sprzętu: Caustic Graphics jest żywym dowodem na to, że nie potrzeba błogosławieństwa ani Intela ani nVidii, żeby wprowadzić w życie wsparcie sprzętowe swojej technologii.

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.

 

Produkujesz się jak natchniony wypisując oczywistości nie tylko do mnie, bo już co najmniej jedna osoba z doświadczeniem zwróciła ci na to uwagę w tym wątku, i nie wiem, czy chcesz zrobić wrażenie na młodzieży, która dopiero zaczyna przygodę z komputerem czy na sobie samym. Stawiam na to drugie.

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.

[mokramyszka666]

Bzdury w twoim krótkowzrocznym mniemaniu to pojęcie bardzo względne.

 

Stworzenie struktury AABB dla choinki, gdzie liściem w hierarchii jest igła to żaden wyczyn. Przeszukanie takiego drzewa również. Transformowanie promienia w przestrzeń konkretnej igiełki nie odbywa się w każdym przypadku a jedynie dla kilku potencjalnych kandydatów na trafienia. Zatem cały ten proces nie różni się niczym od rzucenia promienia w obiekt który ma milion face'ów (tu na dole hierarchii mamy igły a nie face'y). Zatem twoje teorie o przepełnieniu stosu i kilometrowej rekurencji można dorzucić do calej reszty banialuków.

 

Co do proxy, to radzę zgłębić temat, albo w ogóle się tym zainteresować, bo gdyby było tak jak mówisz (typowa transformacja wierzchołków przez macierz), to proxy nie różniłoby się niczym od instancji. Chyba, że w dokumentacji vray'a kłamią.

 

edit:

'ich oprogramowanie' czyli Brazil (http://www.splutterfish.com) korzysta w tym momencie z OpenRL i oprócz znanych producentów wspiera również sprzęt Caustic Graphics.

http://www.prnewswire.com/news-releases/caustic-graphics-launches-brazil-for-developers-at-siggraph-2010-99280119.html

Edytowane 11 Sierpień 2010 przez mokramyszka666

[Skoti]

Stworzenie struktury AABB dla choinki, gdzie liściem w hierarchii jest igła to żaden wyczyn. Przeszukanie takiego drzewa również. Transformowanie promienia w przestrzeń konkretnej igiełki nie odbywa się w każdym przypadku a jedynie dla kilku potencjalnych kandydatów na trafienia. Zatem cały ten proces nie różni się niczym od rzucenia promienia w obiekt który ma milion face'ów (tu na dole hierarchii mamy igły a nie face'y). Zatem twoje teorie o przepełnieniu stosu i kilometrowej rekurencji można dorzucić do calej reszty banialuków.

Jak patrzysz się tylko wzdłuż jednej gałęzi masz miliony potencjalnych kandydatów.

 

Co do proxy, to radzę zgłębić temat, albo w ogóle się tym zainteresować, bo gdyby było tak jak mówisz (typowa transformacja wierzchołków przez macierz), to proxy nie różniłoby się niczym od instancji. Chyba, że w dokumentacji vray'a kłamią.

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ę).

 

edit:

'ich oprogramowanie' czyli Brazil (http://www.splutterfish.com) korzysta w tym momencie z OpenRL i oprócz znanych producentów wspiera również sprzęt Caustic Graphics.

http://www.prnewswire.com/news-releases/caustic-graphics-launches-brazil-for-developers-at-siggraph-2010-99280119.html

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.

[kengi]

jest problem chlopaki, walka jest nierowna, mokrej myszce nie nalicza postow :/

 

wiec na razie jest 210 do 19 dla skotiego.

[olaf]

a ja mysle, ze jakbyscie sie spotkali na piwie, to wyszloby ze sie zgadzacie i ze ogolnie fajne chłopaki jestescie i wymienicie sie krowami na farmville. A tak pompujecie sie od rana do wieczora.

[mokramyszka666]

"Jak patrzysz się tylko wzdłuż jednej gałęzi masz miliony potencjalnych kandydatów."

Tak samo, jak w przypadku raytracingu po face'ch, i co z tego?

 

Proxy: Oprócz tego że przechowuje w osobnym pliku, generuje do tego pliku również strukturę optymalizacji. Czytaj uważniej, bo coraz bliższy jestem stwierdzeniu, że przelatujesz tekst po słowach kluczowych, które rozumiesz, a resztę pomijasz.

 

OpenRL w przypadku sprzętu CausticGraphics korzysta ze sprzętowej implementacji rzucania promieni. W przypadku pozostałego sprzętu wykorzystuje OpenCL. Pierwsze swoje karty C-G już zaprezentowało. Na zapowiadane, szybsze wersje, ciągle czekam. Ja ich nie bronię, ani nie winie, po prostu kibicuje takim rozwiązaniom.

 

Myszka nie wchodzi na forum tylko załatwia się z okienka do komentarzy. Postów nie kolekcjonuje.

[Gość Gosc]

 

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).

 

no wlasnie nie sa, nic nie kumasz jak dzialaja wspolczesne raytracery,

nic nie jest mnozone, bounding box obiektu jest przypisany do lisci

w kd-tree albo gridzie, a promien jest uginany po wejsciu do kolejnej kostki, transformacja jest zapisywana jako zlozenie wektorowe,

cala zawartosc obiektu wogole nie podlega transformacji, dlatego

proxy i instancje sa takie wydajne - inaczej dla kazdej instancji musialbys

transformowac cala geometrie pod konkretne przeksztalcenie

 

i tak sam dziala to w UD, chmura danego obiektu nie jest transformowana dla kazdej instancji, jest tylko zapamietywana transformacja (ugiecie promienia) przy wejsciu do danego bounding boxa

 

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))).

 

tu juz Skoti jakies science-fiction tworzysz, udzial krawedzie i promieni

przestrzelonych na skutek antyaliasingu jest bardzo maly w stosunku

do calego obrazu, jedyne co moze miec silny wplyw na wydajnosc

to duza liczba obiektow polprzezroczystych, co zabija wiekszosc raytracerow

 

jak widac w demach UD, tam antyaliasing jest olany sikiem prostym koherentnym, bo wszystkie krawedzie drgaja jak reka 90-latki

 

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.

 

nie przerzucajcie sie na takie argumenty bo to do nieczego nie prowadzi,

sedno problemu polega na tym ze nie dopuszczacie do mysli innych rozwiazan i kazdy broni wlasnego punktu myslenie... a to prowadzi

tylko do zatwardzialego stania w miejscu

 

gamedev i jego technologie w duzym stopniu czerpia z pomyslow i prac

osob wogole nie zwiazanych z rynkiem gier i kart graficznych, wiekszosc

mozgow w ILM nie gra w gry czesciej niz raz na rok i nie przeszkadza to

im wymyslac algorytmow ktore rewolucjonizuja potem rynek

[mokramyszka666]

TJ: Dziękuję za skonkretyzowanie moich ogólnych i trochę teoretycznych rozważań ;)

Nie zamykam się na inne rozwiązania, dlatego w kilku miejscach wspomniałem o enginie hybrydowym opartym o poligony oraz pointcloudy.

[Skoti]

Tak samo, jak w przypadku raytracingu po face'ch, i co z tego?

Tu na każdym z tych potencjalnych nie załamujesz promienia i nie jesteś coraz głębiej w rekurencji (siatka jest już przemnożona)

 

 

Proxy: Oprócz tego że przechowuje w osobnym pliku, generuje do tego pliku również strukturę optymalizacji.

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).

 

OpenRL w przypadku sprzętu CausticGraphics korzysta ze sprzętowej implementacji rzucania promieni. W przypadku pozostałego sprzętu wykorzystuje OpenCL. Pierwsze swoje karty C-G już zaprezentowało. Na zapowiadane, szybsze wersje, ciągle czekam. Ja ich nie bronię, ani nie winie, po prostu kibicuje takim rozwiązaniom.

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 nie wchodzi na forum tylko załatwia się z okienka do komentarzy. Postów nie kolekcjonuje.

Myszka widocznie lubi się męczyć w małym okienku do komentarzy - ja nie zamierzam.

 

no wlasnie nie sa, nic nie kumasz jak dzialaja wspolczesne raytracery,

nic nie jest mnozone, bounding box obiektu jest przypisany do lisci

w kd-tree albo gridzie, a promien jest uginany po wejsciu do kolejnej kostki, transformacja jest zapisywana jako zlozenie wektorowe,

cala zawartosc obiektu wogole nie podlega transformacji, dlatego

proxy i instancje sa takie wydajne - inaczej dla kazdej instancji musialbys

transformowac cala geometrie pod konkretne przeksztalcenie

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.

 

jedyne co moze miec silny wplyw na wydajnosc

to duza liczba obiektow polprzezroczystych, co zabija wiekszosc raytracerow

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.

 

gamedev i jego technologie w duzym stopniu czerpia z pomyslow i prac

osob wogole nie zwiazanych z rynkiem gier i kart graficznych, wiekszosc

mozgow w ILM nie gra w gry czesciej niz raz na rok i nie przeszkadza to

im wymyslac algorytmow ktore rewolucjonizuja potem rynek

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:

Natomiast przecięcie promienia z trójkątem jest bardziej czasochłonne niż wciągnięcie go do transformacji (tak jak to by było w tym przypadku), a mimo to nie stanowi większego problemu.

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

Próbujesz przekonać że zaginanie promienia jest zła praktyką. Ja odnosząc się do analogii rzucania promienia w obiekt poly przekonuję cię że taka transformacja nie jest bardziej kosztowna niż klasyczne przecięcie z trójkątem, co odbywa się w typowym raytracerze.

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

Edit2:

Spróbuj zrozumieć że nie mówię o rekurencji głębszej niż ma to miejsce w przypadku raytracingu z trójkątami. Dochodzisz do liścia hierarchii, wciagasz promień do pointclouda - jeśli go przecina, to odnotowujemy punkt i na tym etapie koniec, nie ma nic głębiej na etapie przeszukiwania drzewa, 'wychodzimy' z pointclouda i szukamy dalej potencjalnych bliższych kandydatów tą sama metodą.

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.

Edytowane 11 Sierpień 2010 przez Skoti

[mokramyszka666]

"Tu na każdym z tych potencjalnych nie załamujesz promienia i nie jesteś coraz głębiej w rekurencji (siatka jest już przemnożona)"

To, że nie jest przemnożona, wytłumaczył ci już wyżej bardziej obeznany w temacie człowiek. Natomiast przecięcie promienia z trójkątem jest bardziej czasochłonne niż wciągnięcie go do transformacji (tak jak to by było w tym przypadku), a mimo to nie stanowi większego problemu.

 

Odnośnie proxy, nie dociera do ciebie to, co piszą inni, więc nie zamierzam się bez przerwy ustosunkowywać do tego samego błędnego rozumowania.

 

Edit:

Cytat z poprzedniego postu: "A co ma czas sprawdzenia czy promień przecina tri, do modyfikacji promienia (po zmodyfikowaniu i tak musisz sprawdzić czy przecina się z tri)? "

 

Próbujesz przekonać że zaginanie promienia jest zła praktyką. Ja odnosząc się do analogii rzucania promienia w obiekt poly przekonuję cię że taka transformacja nie jest bardziej kosztowna niż klasyczne przecięcie z trójkątem, co odbywa się w typowym raytracerze.

W UD nie mamy trójkątów ale obiekty/zbiory pointcloudów w liściach struktury AABB. Zatem wciągnięcie promienia do transformacji takiego obiektu w końcowej fazie szukania przecięcia nie jest bardziej kosztowne niż przecięcie go z analogicznym trójkątem w strukturze obiektu poly.

 

Edit2:

Spróbuj zrozumieć że nie mówię o rekurencji głębszej niż ma to miejsce w przypadku raytracingu z trójkątami. Dochodzisz do liścia hierarchii, wciagasz promień do pointclouda - jeśli go przecina, to odnotowujemy punkt i na tym etapie koniec, nie ma nic głębiej na etapie przeszukiwania drzewa, 'wychodzimy' z pointclouda i szukamy dalej potencjalnych bliższych kandydatów tą sama metodą.

 

Edit3:

odnośnie:

"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. "

 

 

W tym momencie zacząłem podejrzewać, że już udajesz i celowo marnujesz mój czas, bo niemożliwe żeby człowiek z twoją wiedzą nie rozumiał tak prostych rzeczy. Ale będę twardy i w uniesieniu chwilowej empatii spróbuję:

 

Masz sobie choinkę. Jest to obiekt poly z ładnym displacementem na korze. Piękna poligonowa sztuka jaką lubisz. Teraz wyobraź sobie zbiór miliona oddzielnych trójkątów które są osobnym obiektem i udają igły. Przechowane w strukturze AABB trójkąciki, łatwo można przeszukać i znaleźć przecięcie promienia z najbliższą trójkąto-igielką. Do tej pory nie widzisz problemu?

To podmień teraz wszystkie trójkąto-igiełki na instancje pointclouda i zostanów się co się zmieniło, poza tym że zamiast przecięcia z trójkątem robimy przeciecie z pointcloudem jednorazowo na ta okazję transformując rzucany promień.

Kończę bo brakuje mi wiary w twoje możliwości pojmowania.

Edytowane 11 Sierpień 2010 przez mokramyszka666

[Skoti]

Masz sobie choinkę. Jest to obiekt poly z ładnym displacementem na korze. Piękna poligonowa sztuka jaką lubisz. Teraz wyobraź sobie zbiór miliona oddzielnych trójkątów które są osobnym obiektem i udają igły. Przechowane w strukturze AABB trójkąciki, łatwo można przeszukać i znaleźć przecięcie promienia z najbliższą trójkąto-igielką. Do tej pory nie widzisz problemu?

To podmień teraz wszystkie trójkąto-igiełki na instancje pointclouda i zostanów się co się zmieniło, poza tym że zamiast przecięcia z trójkątem robimy przeciecie z pointcloudem jednorazowo na ta okazję transformując rzucany promień.

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

 

W tym momencie zacząłem podejrzewać, że już udajesz i celowo marnujesz mój czas, bo niemożliwe żeby człowiek z twoją wiedzą nie rozumiał tak prostych rzeczy.

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).

[mokramyszka666]

Przed rzuceniem promienia, wiem jaka jest globalna transformacja każdej igły w danej klatce, bo wyliczam je w czasie animacji. Nie interesują mnie gałęzie na wietrze, więc rzucenie promienia w tą igłę po przetransformowaniu go w jej przestrzeń nie różni się niczym od rzucenia promienia w każdy inny obiekt pointcloudowy z UD.

Nie odpuściłem normalnych tylko uznałem pisząc jeden z poprzednich postów, że można je generować podczas tworzenia point clouda i bez problemu przechowywać w obiektach. Nawet sensowniej byłoby je przechowywać niż kolor, który dla fauny można wydajnie obliczyć proceduralnie.

 

Jestem w stanie ścierpieć twoje absurdalne argumenty, które z postu na post zakrawają na coraz większą głupotę i świadczą o brakach w fundamentalnych procesach myślowych. Natomiast to, czy robisz z siebie idiotę świadomie z nudów, czy po prostu się taki urodziłeś, to już twój problem, a nie mój.

[Skoti]

Przed rzuceniem promienia, wiem jaka jest globalna transformacja każdej igły w danej klatce, bo wyliczam je w czasie animacji. Nie interesują mnie gałęzie na wietrze, więc rzucenie promienia w tą igłę po przetransformowaniu go w jej przestrzeń nie różni się niczym od rzucenia promienia w każdy inny obiekt pointcloudowy z UD.

No nie wściekaj się już (napisałem Ci już , że się z tobą droczę ;p).

 

Nie odpuściłem normalnych tylko uznałem pisząc jeden z poprzednich postów, że można je generować podczas tworzenia point clouda i bez problemu przechowywać w obiektach. Nawet sensowniej byłoby je przechowywać niż kolor, który dla fauny można wydajnie obliczyć proceduralnie.

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).

 

Natomiast to, czy robisz z siebie idiotę świadomie z nudów, czy po prostu się taki urodziłeś, to już twój problem, a nie mój.

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.

[mokramyszka666]

Czy według ciebie pointclouda też nie da się generować w skończonym czasie?

Jeśli jednak się da, to jakim problemem jest podczas tego procesu wyliczyć normalną (zakładam, że pointcloud jest generowany z lokalnie dzielonego obiektu poly, ewentualnie bez poly z użyciem level setów)?

Jak już sam zauważyłeś rozwiązania typowe dla gamedev uważam za ograniczone i często prymitywne. Tak jest również z liczeniem normalnych w postprocesie. Chyba że z góry zakładasz brak antialiasingu i nie przeszkadza ci ograniczona dokładność (i tak już bardzo ograniczonej metody) w miejscach gdzie obiekty na siebie nachodzą (tam już nie masz nawet 8 punktów.

[Skoti]

Czy według ciebie pointclouda też nie da się generować w skończonym czasie?

Jeśli jednak się da, to jakim problemem jest podczas tego procesu wyliczyć normalną (zakładam, że pointcloud jest generowany z lokalnie dzielonego obiektu poly, ewentualnie bez poly z użyciem level setów)?

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

 

 

Jak już sam zauważyłeś rozwiązania typowe dla gamedev uważam za ograniczone i często prymitywne. Tak jest również z liczeniem normalnych w postprocesie. Chyba że z góry zakładasz brak antialiasingu i nie przeszkadza ci ograniczona dokładność (i tak już bardzo ograniczonej metody) w miejscach gdzie obiekty na siebie nachodzą (tam już nie masz nawet 8 punktów.

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

[mokramyszka666]

Pierwsze pomijam, bo mi się znudziło tłumaczenie oczywistości tylko po to, żebyś po 10 postach postawiony przed faktem stwierdził, że żartowałeś.

Drugie ci wytłumaczę.

Ja nie zakładam braku antialiasingu. O deferred shading nie czytałem ani wręcz nie interesuje mnie na czym dokładnie polega.

Po prostu przy użyciu renderingu, który jest nastawiony na jak największy detal (UD) nie chciałbym go marnować wybitnie aproksymowaną normalną liczoną w postprocesie. Żeby antialiasing miał sens w przypadku UD należy go wyliczyć również w czasie renderingu, zatem otrzymujesz w g-bufforze rozmazane krawędzie, a liczenie normalnej na tej podstawie jest równie mądre co twoje ostatnie posty.

Pozdrawiam i dziękuję za uwagę.