mokramyszka666

Nezumi... trochę się spiąłeś chyba niepotrzebnie :) Staruszki z demencją wierzące w diabła z kopytami to jedno. Sam bardzo chętnie włączam się w dyskusję gdy młoda siksa wciska babuni super zdrowe i rewolucyjne wkładki do butów, bez których odpadną nam stopy obrośnięte grzybem... Ale teoretycznie zdrowi na umyśle, raczej młodzi ludzie, którzy mają prawo wyboru kupienia czego 'chcą' - to inna sprawa. Jeśli komuś posiadanie iTelefonu powiększa wirtualnie penisa i lepiej się czuje w towarzystwie to jest kretynem. I niech go Jobs wykorzystuje. :) Pamiętajmy że są też ludzie którzy lubią zabawki. A iPhone to fajna zabawka. A iPad to fajna zabawka dla tych którym nie wystarcza iPhone ;)

Ok. To częściowo wracając już do tematu, uważam, że zdecydowanie błędnie interpretujesz możliwości rozbudowy Mayi. Chciałem zacytować, ale praktycznie cały twój drugi post składa się z błędnych wniosków i założeń pozbawionych logiki. _Nie_ wszczynam wojny, bo nie ma o co, szczególnie, że animator nie musi wiedzieć o takich rzeczach. Nie zmienia to jednak faktu. Tworzenie 'narzędzia' z klocuszków, które daje do dyspozycji ten soft i robienie z tego Melowego automatu - a pisanie pluginów do konkretnych zadań to dwie bardzo różne rzeczy. Zakładasz że nie ma sensu pisać nowych kości a wszystko to zgrabnie poukładane w UI standardowe rozwiązania. Jestem na 99% pewien, że jest dokładnie odwrotnie. Mel nie jest językiem, który umożliwia stworzenie sprawnego i funkcjonalnego programu. Sorki, ale drażni mnie takie 'mitologiczne' podejście, bo ktoś kiedyś rzucił tekstem jakoby praktycznie cała Maya była napisana w Melu, ludzie to podchwycili i często nie mając pojęcia o tym języku konstruują błędne wnioski. [interface Maya to faktycznie Mel, ale w ten sposób jest jedynie budowane UI oraz wywoływane właściwie funkcje programu.] Analogią niech będzie cMuscle, którego możliwości na upartego też można by odtworzyć ze standardowych narzędzi posklejanych Melem, ale jednak jest (była) to osobna biblioteka - plugin napisany w API. Podobnie maxowy CAT czy Biped teoretycznie mogły powstać w Maxscripcie (i niech nikt tu nie wyjażdza ze stwierdzeniem że MaxScript jest gorszy bo pod wieloma względami jest lepszy ;) W takich sytuacjach chodzi o wydajność i większe możliwości, bo co z tego że jakoś się da coś-tam sklecić, skoro pisanie tego będzie męczarnią, szybkość działania dyskwalifikująca, a bałagan powstały przy okazji nie do ogarnięcia. Pomijam już fakt, że udostępnianie narzędzia w Melu to jak dawanie open-source'a (nie dopatrzyłem się możliwości enkryptowania) A pisanie skinningu od nowa faktycznie bez sensu, bo MCS to system kości a nie deformer ;) Nie chodzi o to, żeby coś udowadniać. Wydaje mi się tylko, że pisząc takie rzeczy, dewaluujesz to narzędzie. Co do zaprzeczania samemu sobie, szkoda czasu na przerzucanie się teraz cytatami, ale chociażby fakt, że argumentując wspomniałeś w kilku miejscach o Pixarze na koniec przyznając że używają Marionette.

Każdego użytkownika forum, którego masz okazję spotkać w RL odsyłasz na priva? Czy tylko niewygodnych rozmówców? :] ... a nie udowadniam niczego, raczej uściślam nieścisłości, które się przewinęły w twoich wypowiedziach, mogące sugerować młodym użytkownikom, że Maya to MastersOfTheUniverse i każda duża firma tego używa. Moim nieskromnym zdaniem Maya jest postawą nauczania animacji w AM właśnie ze względu na ogromne możliwości budowania custom rigów, a nie dlatego że jest powszechnie używanym softem do animacji (choć jest oczywiście bardzo popularna). Ucząc się pracy na rigach w Maya później taki człowiek nie jest zaskoczony widząc zupełnie nowego riga w pracy. Więc mówiąc ogólnie ten soft pozwala nauczyć animacji w najbardziej ogólnym pojęciu i o to chodzi chyba w tej szkole.

Hmm... nie do końca rozumiem... ale to Jobs jest zły bo jest sprytny i kosi mamonę? ...czy idioci, którzy się nabierają na tą 'otoczkę'? Tylko gdzie tu faszyzm? Większość ludzi z tego forum, zajmujących się profesjonalnie 3d żeruje pośrednio lub bezpośrednio na kretynach zarabiając pieniądze tłukąc reklamy, które zachęcają to kupowania niepotrzebnych nikomu rzeczy. W sumie gadasz do rzeczy, ale czy nie czas już pogodzić się z rzeczywistością? A jabłko jest po prostu pedalskie. :)

Proprietary software zazwyczaj nie bazuje na niczym, ewentualnie na API a nie na Melu. Więc mówienie o czymś, że zostało zrobione w Maya tylko dlatego, że był tam interfejs tego softu jest trochę przesadne. Podobnie jak mówienie, że '2012' zrobiono w Maxie, chociaż nie wykorzystano praktycznie żadnego standardowego narzędzia tego programu. EDIT: Krzysztofie, gdybyś słuchał uważnie tego, co mówił niejaki Stephan Bugaj, a obaj mieliśmy tą okazję, to wiedziałbyś że Pixar używa Maya praktycznie tylko do symulacji fluidów i innych FX'ów, natomiast cały rigging i animacja są robione na ich 'proprietary software' ;) i bynajmniej nie są to skrypty w Melu.

Już widzę jak robią 'KungFu Pandę' i 'Shreka' w Mayi :]

Trudno w sumie rozmawiać o tym produkcie :) W/g mnie wydali to jeszcze trochę za wcześnie. Poza kilkoma przyjemnymi opcjami (jak symulacja w 'realtime' bez blokowania interfejsu, ładny podgląd liczony na GPU), zbyt wielu rzeczy brakuje żeby to traktować jak konkurencję dla fuma (na razie).

Adku, nie wszystkie fluidy to ciecze.. :P I chociaż widziałem jakieś testy 'wody' w Phoenix'ie to raczej nie jest to jego główne przeznaczenie. Akcent pana Krasteva - fenomenalne przeżycie.

Ja bym powiedział raczej, że nie ma w tym momencie żadnej alternatywy dla realflow5, bo w żadnym innym sofcie nie widziałem w miarę realistycznie wyglądającej wody.

Na końcu prezentacji są wymienione solvery którymi liczyli te symulacje. Niestety po raz kolejny okazuje się, że każde SPH wygląda pięknie jako kolorowe partikle a po zmeshowaniu jak zwykle wychodzi kulkoglut :] ale to oczywiście tylko dowód na to że kilkaset tyś. partikli to zawsze za mało żeby było dobrze...

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

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.

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.

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

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.

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

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

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.

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

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

@Norden: lepiej nie zostawiaj takich spraw ciapciakom, bo potem taki Skoti swoim pseudo-naukowym zindoktrynowanym trójkatnym bełkotem zepsuje Ci cała zabawę :D

Dajcie spokój, przecież ten człowiek ma myślenie ograniczone do dwóch wariantów, albo są 3 punkty albo nieskończoność... 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. 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. Z resztą mogą istnieć inne sposoby, bardziej wydajne i oszczędne (distance fields?) Chodziło mi tylko o to że jest to jak najbardziej możliwe i wcale nie musi trwać wieki. 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. Odnośnie fragmentu filmiku (2:40) ja mówię o milionach igieł a ty mi pokazujesz 5 kolcow na krzysz. Z czym do ludzi?? Im dłużej z Tobą 'rozmawiam' tym więcej argumentów nieświadomie mi podsuwasz na korzyść UD. 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.

Voxlap był enginem stricte voxelowym, nie dzialał w oparciu o point cloudy. Natomiast wstawki voxelowe w Buildzie istniały w czasach kiedy nawet poligonowe 3d było w powijakach a ludzie myśleli że postacie ze sprite-ów to szczyt techniki. Osobiście, jestem po prostu ciekawy jak wyglądałoby dzisiaj 3d, gdyby włożono tyle pracy w rozwój technologi voxel/pc co w poligony. Dzis można tylko zgadywać i liczyć na to że ingoranci się otrząsną ;) EDIT: swoją drogą, skoro już wspomniałem o spritach to całkiem trafna analogia do tego co się może przydarzyć z technologią 3d w przyszlości. Na poczatku były wolfensteiny, doomy i tym podobne pseudo-3d twory, które w każdym miejscu, gdzie potrzeba było czegoś więcej niż czworokąta, wykorzystywały sprite. Później udało się wprowadzić kanciaste postacie, które przynajmniej były już w pełni 3d, choć wyglądały jak klocki. Do dzisiaj problemem jest zrobienie ładnego w pełni trójwymiarowego drzewa, nie mówiąc już o choince. Może w tym momencie własnie wkracza coś nowego, co na razie tylko cześciowo, a z czasem w coraz większym zakresie zastapi kanciastość w 3d... ...bo teselacja nie sprawi w cudowny sposób, że na jodle wyrośnie 2 miliony szczegółowych igiełek.

Wykorzystujesz kilka punktów definiujących powierzchnię w otoczeniu liczonej normalnej i dalej już zwyczajnie jak z poligonami. Swoją drogą skoro UnlimitedDetail przechowuje pozycję i kolor to może i normalną możnaby upchnąć w jakimś half-floatcie... zależy jakie struktury wykorzystują do zapisu danych. Z resztą to juz zwykłe 'gdybanie'. Edit: tak właśnie, chociażby siggraphowe nowości, które czakaja nieraz latami, miałem na myśli. Możesz być dla siebie samego wielkim autorytetem, ale nie tobie oceniać czy jest w tej technologi potencjał czy nie. Jak pokazano w demo, właśnie do kamieni, roślinnosci i innych nieregularnych kształtów, nadaje się to doskonale, a to, że ty wolisz płaskie zmapowane trójkąciki, bo tak robiłeś przez 10 lat, na szczęście nie wszystkich interesuje. Gdyby poligony były liczone na CPU bez antialiasingu i filtrowania to ciekawe co by ładniej wyglądało.... W jednym zdaniu piszesz, że technologia nie ma przyszłosci, po czym wymieniasz przykłady rozwiązań które musiały 'tylko' poczekać na lepszy sprzęt. To już zakrawa na paranoję. Podałeś przykład płaskiej ściany zupełnie potwierdzając fakt, że cudze wypowiedzi traktujesz wybiórczo i nie potrafisz sie sensownie ustosunkować. Dlatego napisałem o enginach hybrydowych, bo wiem doskonale, że nie do wszystkiego się ta technologia nadaje.

Z góry zakładasz, że twoi rozmówcy nie wiedzą o czym mówią, więc chętnie odpuściłbym sobie dalsza dyskusję, szczególnie, że pomijasz niewygodne dla ciebie kwestie, albo odpowiednio źle interpretujesz lub przekręcasz słowa. W każdym razie nie pisałem nic o liczeniu normalnej w pixelu tylko liczeniu jej dla konkretnego punktu chmury widocznego w tym pixelu. Mimo, że teoretcznie liczba punktów jest nie limitowana to chyba jesteś na tyle myślący, żeby wiedziec, że w najbliższym otoczeniu ta ilość już jest ograniczona. Po drugie, nie mówiłem nic o GPU, tylko o tym że Unlimited Detail nie jest wspierane sprzętowo, dlatego że taki sprzęt jeszcze nie powstał a wymaga innego podejścia niż klasyczne 3d. Ja również programuje grafikę, nie od dziś i zdążyłem się przekonać, ze już niejedno rozwiązanie, które miłośnicy przestarzałych technologii spisali na straty, w dłuższej perspektywie okazywało się przełomowe. Bardzo chętnie zobaczę przykład grafiki o podobnej ilości detalu działającej w RT z poligonów. Na koniec dodam tylko, że nie widzę w tej technologi żadnego 'zagrożenia' dla typowego poligonowego 3d, natomiast spodziewałbym się w niedalekiej przyszłości engine'ów hybrydowych, o ile oczywiście producenci hardware'u zechcą szerzej otworzyć oczy. Bo o ile rendering postaci przy użyciu pointclouda wydaje się poronionym pomysłem, to użycie tego do tworzenia roślinności oraz innych powtarzalnych i proceduralnych elementów jest już jak najbardziej wskazane.