Skoti

@Nezumi: W tej rozmowie chodziło pewnie o coś innego - Darmowy soft to niższe koszty wejścia i każdy dzieciak może się uczyć tworzyć w 3D. Co zwiększa znacznie konkurencje na rynku, a konkurencja może spowodować obniżenie wynagrodzeń (bo łatwo będzie można takiego grafika zastąpić innym). OFC jest to spore uproszczenie i dobry grafik nie ma się czego obawiać. Podsumowując nie chodzi o to, że źle jest dlatego bo mogę za darmo mieć program do swojej pracy, tylko to, że inni mogą go mieć za darmo, a to już zwiększa potencjalną konkurencje na rynku.

Jako użytkownika interesuje mnie, aby poprawki były poprawkami, a nie tuszowaniem błędów ;p. OFC jako użytkownik chcący to na już nie ma opcji tylko takie tuszowanie jest możliwe, ale trzeba być świadomy, że takie tuszowanie błędów się później strasznie mści i odbija na przyszłym rozwoju programu. Wiem, że moje posty są mało popularne wśród wręcz fanatyków blendera, ale warto wiedzieć, że pod przykryciem szybkiego rozwoju idzie w blenderze krok wstecz i przepisywanie. Tak jak twórcy blendera mówili przed 2.5 czasami trzeba zrobić krok wstecz, aby zrobić krok do przodu, ale tego kroku nie zrobili... wręcz pozostaje wrażenie, że stało to w miejscu i odroczono ten krok wstecz, z którego w efekcie zrobi się marsz kilometrowy wstecz, aby iść w przód.

BMesh czy tego chcesz czy nie jest niedojrzały (oraz kiepsko zaprojektowany - co z tego, że 5-6 lat już jest rozwijany... a wręcz głównie dlatego ;p), a jest tu trochę osób (jeśli dobrze pamiętam), które uważają, że bmesh to była duża, bezsensowna strata czasu i lepiej byłoby dla blendera (i nie mówię tu o sobie ;p). Co więcej nie ma paredziesiąt fixów do bmesha jak piszesz tylko kilka (nie liczysz chyba jednolinijkowych czy kilku-znakowych (lub usuniecie zbędnej linijki/warunku) fixów, jako znaczącą pracę nad narzędziami?)

Ta z czego większość dotyczących niedojrzałych nowinek z poprzedniej wersji, a bugfixów dotyczących tej niedawnej dyskusji może kilka drobnych fixów narzędzi które potrzebują przeprojektowania, a nie bugfixów ;p.

Możesz uściślić, bo nie do końca wiem o czym piszesz.

@Nezumi: Nie zmierza ku katastrofie i nowy blender odrobinę podratował sytuacje... jednak na tyle mało, że zmierza to dalej w kierunku "za 2 lata kolejne wielkie przepisywanie, regresje, i wrócimy to punktu wyjścia", zamiast wykorzystać to przepisywanie robić i zrobić wszystko tak jak trzeba i za 2 lata tylko dalej rozwijać, a nie się cofać. Miałem spore nadzieje w sprawie przepisywania 2.4x -> 2.5+... przetrzymać to i rozwój będzie szybki... ale praktycznie stracono czas, a jak było źle tak niestety jest.

Blender != Cycles. Blender jest użyteczny (źle rozwijany o czym większość nawet tu go broniących wie, Ci którzy widzieli kod dodatkowo wiedzą jaki bałagan w nim jest... ale użyteczny), mam gotowe własne łatki do niego i nie mam go puki co zamiaru zamieniać, a Cycles to zupełnie inna bajka... w tej chwili jest dla mnie bezużyteczny. Na dyskusję straciłem może godzinę czasu wolnego. W blenderze aby poprawić CORE trzeba poprawić wszystko co narosło - czytaj napisać od nowa... na to już czasu nie znajdę.

Nie mam czasu pracować przy bezużytecznym dla mnie projekcie. Kiedy będzie już minimalnie dla mnie użyteczny, to zobaczę, czy warto wspierać, podsyłać łatki czy po prostu olać, bo nic z tego nie będzie i używać wypiekania konkurencji lub poświęcić czas na własny render (mam ochotę pa point based rendering + wypiekanie, ale czasu brak).

SSS to też podstawa która powinna być już 2 lata temu w kodzie ;p. @mookie: Ja nie mówię, że się nie da, ja mówię, że dalej nie osiągnięto tego co było w 2.4x - niektóre narzędzia są mniej wygodne, inne dalej zbuggowane Ludzie nie są aroganccy i wcale nie myślą, że osiągnęli już wiedzę odpowiednią, bo genetyka raczkuje. Jednak mają uzasadnione przeświadczenie, że syntetycznie planowo rozwijając znacznie szybciej osiągną cel... uzasadnione, bo stworzyli już syntetyczne życie, bez DNA (XNA czyli 6 innych aminokwasów niż w nas) z w niewielkim czasie (ewolucja do DNA dochodziła znacznie dłużej przez "eksperymenty" z RNA, więc człowiek ma spore fory, bo może nie próbować wszystkiego, a kreować celowo i poprawiać z dnia na dzień). Do wiedzy przyzwoitej na ten temat potrzebujemy jeszcze setek lat, ale przy miliardach ewolucji jest to i tak spory wyczyn. Ja na BA nie piszę, jak mam sprawę to piszę bezpośrednio do Ton'a lub na listę dyskusyjną. Dopóki Cycles nie wyjdzie z fazy niemowlęcej nie mam zamiaru pisać o czym już wspominałem... dopiero kiedy znajdzie się wypiekanie i nie będzie odpowiednich shaderów (bez których wypiekanie może nie istnieć), będę pisał tam, a w tej chwili można sobie podyskutować tu na forum i wymienić się opiniami - od tego jest forum.

No pewnie, że można robić lepsze reklamy... tylko sporym kosztem... tym większym, że gdyby projektować z głową, blender miał by dziś znacznie lepsze narzędzia, a nie, w kółko poprawiać to samo jak jest to robione teraz. No popatrz, a ja znam ruch w odwrotną stronę (osób które znały Blendera 2.4 i były już sfrustrowane, że lata mijają a postępów brak (a było co poprawiać), a wręcz trzeba czekać aż stan z kilkuletnich wersji będzie przywrócony). My tu nie mówimy o radosnych wolontariuszach, gdzie ich praca jest porzucana i rzadko wchodzi do blendera, a o programistach z CORE TEAM, którzy powinni właśnie dbać o dobrą platformę podstawową. Wolontariusz niech robi sobie co chce, ale tu mowa o płatnych programistach. Takie nagrody to po prostu przegląd co dostał dany program w danym roku i Blender marketingowo wygrywa ilością features... nikt jednak nie mówi o jakości tego kodu, jak bardzo są dziurawe podstawy utrudniające prace... Używam blendera, ale widząc ten kod to nie zainwestuje czasu w jego rozwój, bo to zbędna praca (blender 2.5+ miał być aby przepisać podstawy programu, bo już się nie dało go rozwijać, a w praktyce kod jest równie zły co wcześniej). Jedynie Cycles jako pisany od nowa w C++ i dosyć ładnie może być czymś dobrym co spotkało blendera od 2.4x... ale braki w podstawach źle wróżą (tu tylko wróżą i mam nadzieje, że będzie jeszcze to uzupełnione). Nikt tego nie powiedział - po prostu takie sztuczne ograniczenia są mocno upierdliwe, a takich rzeczy w blenderze jest mnóstwo i o wielu rzeczach można powiedzieć "prawie" działa. Nie jestem aż takim pesymistą, żeby uważać, że rozwój blendera będzie tyle trwał co ewolucja. To na co ewolucia potrzebuje milionów/miliardów lat, człowiek potrafi zaprojektować w kilka lat, jak i opracować alternatywy dla DNA jak zaprojektowane syntetyczne XNA, które jest zdolne do ewolucji. Co do DNA zwierząt bardziej złożonych to zapewne słyszałeś o śmieciowym DNA (tyle jest śmieci ewolucyjnych, że rozwijać tego świadomie dalej się nie da... a i dynamika ewolucji spada wraz z wielkością materiału genetycznego). Aby rozwijać dalej świadomie i dynamicznie kod genetyczny, trzeba by wszystko wyrzucić do kosza i projektować od nowa świadomie bez śmieci. Bardzo dobra analogia z tym DNA i czasu ile trwa rozwój bez planu (razem z ilością pomyłek, ślepych uliczek, wymierań gałęzi...) i taki który jest zaplanowany.

No właśnie ja widzę to w ciemnych barwach i wiem do czego to dąży. Takie gonienie za features jest dobre jedynie marketingowo - cały czas coś się dzieje, są widoczne efekty i można zasypywać portale newsami i listami co to blender nie ma, a jak przyjdzie co do czego, to to bezużyteczne, to pełne buggów, to niekompletne, to nie współpracuje z tym i tym, a podstawowe narzędzia (nawet do modelowania) leżą w strasznym stanie, bo poprawki tu gdzie są faktycznie potrzebne są mało widowiskowe i społeczność nie będzie piała z zachwytu nad super innowacjami na forach. To, że tego nie było od początku (o ile bo nie sprawdzałem i nie interesowałem się cycles) to bardzo źle świadczy o projektowaniu. Brecht ma odpowiednią wiedzę i zaprojektowanie tego co chce zrobić, wyznacznenie kamieni milowych itp. zrobiłby bardzo szybko i dobrze. Ale wygląda to raczej na projektowanie typu: siadam do kompa i piszę bez projektu, wyznaczając mgliste cele (a później przy robieniu kolejnych rzeczy jest "Upss nie przewidziałem tego to co robiłem 2 miesiące temu muszę przepisać i robić od nowa"). To tak jakby grafik siadał do blendera bez konceptów, planów, opisu, bez koncepcji większej całości sceny... mając tylko zaznaczone w roadmapie: zrobić potwora... potwór wyjdzie pokraczny, a z dopasowaniem do reszty sceny dramat (kreskówkowa scena, potwór z horroru)... ot taka radosna twórczość bez rozplanowania. W blenderze już za dużo takich radosnych projektów było prowadzonych na radosną twórczość, a później Upss nie możesz zrobić fizyki brył sztywnych i mieszać z softbody, bo to 2 oddzielne radosne pomysły, i aby działały razem trzeba wszystko wywalić do kosza i dopiero zaprojektować i zrobić od początku tak jak powinno się to robić. Spec, diffuse, normal, dane z kamery... możliwe modyfikacje po shaderze dawały sporo możliwości (tylko jeszcze wektory świateł dodać i sam mógłbyć implementować swoje speculary/diffuse... tak fizyczne jak sobie chcesz). A pamiętasz dlaczego Brecht przestał rozwijać BI i dlaczego nie dostał on point based renderingu, microdisplacementu...? Bo kod BI był źle zaprojektowany i rozwój tego był praktycznie niemożliwy (Brecht przy Sintel powiedział, że kod jest tak zrobiony, że tego się nie da rozwijać), więc pozostawiono go dla Cycles... tylko obawiam się, że historia zatoczy koło.

Miałeś składowe, potrzebne nody aby składać wszystko jak chciałeś (nie miałeś tylko niskopoziomowych pozwalających Ci obliczyć sam dystrybucje (ale miałeś i tak ich wybór nieporównywalnie większy niż w cycles, gdzie nie masz zupełnie kontroli)). BTW co masz w w shaderach Cycles jak nie "zwykłe RGB"? Nie dość, że jest to najzwyklejsze rgb, to nawet nie masz do tego żadnego dostępu. Artyści mieli całe G do powiedzenia, a rozwój był bardziej na zasadzie - o to mi się podoba to zaimplementuje. Było to mniej więcej jak z softbody, rigidbody, cloth... i innymi rzeczami które były robione dla szybkich efektów, bo fajne, bo będą się dzieciaki na forach cieszyć... a jak trzeba to rozwijać to wywala się wszystko i robi od zera... i tak zamiast do przodu, program zatacza pętlę - co wejdzie coś nowego to zaraz regresja i tak w kółko. Znając życie z takiego podejścia wyjdzie: za dużo roboty z tym bo już tyle jest na garbie podstawy przerabiać więc napiszemy to od nowa... i znowu pominie się przemyślenie podstaw, i gnać się będzie do efektów kiedy wszyscy pieją z zachwytu nad świecidełkami. Zgadzamy się do czasu kiedy na niekompletne podstawy nie urośnie duży garb, który uniemożliwić, a z pewnością utrudnić może uzupełnienie banalnych rzeczy (jednak zmieniając w podstawach cokolwiek, musisz zmienić też to co się na tych podstawach opiera). Puki Cycles cały to podstawy renderera to nie można powiedzieć, że podstawy są złe... tylko jeszcze niekompletne. Bardziej ograniczony niż jest teraz? To chyba nie jest możliwe ;p. Jeśli tak jak mówię, to no pewnie, że nie znikną, bo będą w ubershaderze, ale nic nie dojdzie (ubershader zawiera wszystko w sobie i jak program będzie chciał aby zachował się jak Glossy, to doda stałą GLOSSY przed kompilacją i ubershader będzie shaderem glossy...).

Trzeba zrobić takie jak w BI gdzie sam sobie składać mogłeś BSDF'a ze składowych, wtedy wszystkie możliwości będziesz miał. Jak coś mi podpadnie czyli jest złe od podstaw jak python to nie szczędzę słów krytyki. Tu Cycles nie jest zły od podstaw (po prostu rozwój wieku niemowlęcego), bo w przeciwieństwie do niektórych lubię zarówno zalety biasów jak i unbiasów tylko do innych zastosowań. Po prostu rozwój cycles poszedł w rozwój mniej istotnych rzeczy, a od 2ch lat nic się nie zmienia w podstawach, które powinny być od początku. Nie narzucam workflow - jeśli ktoś chce to sobie połączy lub wybierze predefiniowane. Ja właśnie piszę o tym, ze przez nieprzemyślane podstawy materiałów workflow jest bardzo ograniczony i wiele osób o bardzo różnych workflow (jednak ceniących możliwości, nad łatwym interface) o tym tu pisze. Nie do końca wiem co ubershader w cycles ma znaczyć, ale jeśli to co w silnikach RT (wszystkie shadery w jednym pliku współdzielą kod, ale od strony programu i tak są widziane jako dziesiątki shaderów osobnych i osobno kompilowanych/optymalizowanych), to nie zmieni nic od strony grafika... ale dobrze, że ktoś zainteresował się przepisaniem podstaw - początkowo ubershadery, a później może budowanie shadera z nodów (powrót funkcjonalności z BI).

Z tym co powinno być już 2 lata temu? Przecież tu piszemy o takich banałach, że głowa mała... to tak jakby się rozpisywać, że extrude do modelowania jest potrzebne, podczas gdy ktoś inny pisał, żeby się nie czepiał, bo deformuje przecież deformuje siatkę w takt muzyki. Może jestem oldschoolowy, ale zawsze podchodziłem do rozwoju oprogramowania tak: najpierw podstawy później dekoracje, a nie na początek dekoracje, a podstawy się walą.

Przy zmianie kąta padania promieni światła też się zmieniają kolor (i tu spec osobny się przydaje). Ok może nie robiłeś animowanych świateł i olewałeś wpływ na animowane obiekty i nie było Ci potrzebne (uznałeś, że wystarczający fake i można to olać). Pozostaje Ci rozmyty spec... zupełnie nienaturalny dla wielu obiektów. Właśnie problem jest z tą liniową zależnością, a wiele obiektów ma materiały które działają jak filtry górnoprzepustowe (tylko nie schodkowe, a płynne przejście po krzywej) odbijając mało rozmyte mocne światło, nie odbijając odbitego. Niestety w Cycles nie możesz nawet zrobić takiego filtra w nodach (masz mniejsze możliwości niż w fotografii... a to CG - powinno dawać większe możliwości (wręcz nieograniczone)). Podsumowując jednak rozmowę - materiały w cycles ssą (nie mają nic wspólnego z realizmem, ani z elastycznością, a z możliwościami to już się bardzo rozmijają)... to samo dotyczy nodów. Ogólnie to Cycles to taka prealpha renderera i jeszcze lata będzie musiał się rozwijać. Rozdzielenie spec od refl jest równie ważne i naturalne (już jest to rozdzielone, ale nie mamy do tych składowych dostępu bo interface zrobiono idiotoodpornym). Kiedy Cycles mnie zainteresuje (dostanie wypiekanie) to z pewnością sobie to napiszę (chociażby dlatego, że Speculara nie można wypiekać na lightmapki bo zależy od kąta patrzenia i kąta padania promieni światła (a to musi być dynamiczne), a Glossy już jak najbardziej jest wskazany na lightmapkach - głównie dla niego i GI się wypieka je). Raczej pomijanie tak istotnej rzeczy (i to jest jedna tylko przykładowa z dziesiątek) to jak mówienie to super samochód tylko silnika nie ma.

Możesz napisać w dokładnie w jaki sposób? Możesz tak kontrolować kolory przy różnych kątach patrzenia, ale nie przy różnych kątach padania promieni światła, a to spora różnica. OFC, że są, a jeśli są powiązane z odbiciami to często jest to krzywa (znacznie mniejszy (niezauważalny) mirror niż specular). Przed sobą mam router z matowego plastiku - nic nie widać odbić otoczenia (minimalnie od ostrej limonki na ścianie), a od żarówki odbija mocno światło (i odbicie jest dobrze skupione). Co ma piernik do wiatraka? Unbiasy normalnie fejkują i jak najbardziej masz tam najnormalniejszego speculara. To o czym mówisz (odbicia otoczenia itp - nie myl ze specular, bo tu robisz jakieś żarty już chyba) to nic innego jak globalna iluminacja + glossy. Nic co by nie było w biasowych rendererach... ba nawet w starym Blender 2.4x mogłeś nie bawić się w fakeowanie takich odbić i mogłeś wstawiać jak fotograf blendy itp. stworzyć sobie Radiosity i renderować. Coraz bardziej mam wrażenie, że nie do końca wiesz co to specular, bias, unbias (bias to jest taka granica "dopuszczalna" granica błędu i w photon mapingu photony mają swoją wielkość (jest ona granicą błędu) i jak uśrednisz 100 renderów z photonmapingu nie dostaniesz więcej szczegółów (jest obardzone dalej tym minimalnym założonym błędem - biasem), a w unbiased ze względu na to, że wszystko jest punktowe każdy dodatkowy render doda trochę szczegółów - tylko tym się różni biased od unbiased (ofc poza czasem renderingu do zadowalającego efektu)), wygląda to raczej nie jakbyś pisał o czymś co wiesz, a o czymś co wyobrażasz sobie, że tak działa... a że wyobrażasz sobie, że biasowe rendery przez pryzman BI nawet bez radiosity (już o photonmapingu, czy Point Based Renderingu (m.in. korzysta z nich Industrial Light & Magic czy Pixar) zapomnieć można) to wychwalasz unbiased za to co nie jest jego zasługą, a nie lubisz biasów za to, że BI jest słabym biasem.

Fresnel to nie rozwiazanie do takich materialow, warstwy to jakieś częściowe rozwiązanie... mocno zwiększającą czas renderingu przy fakeowaniu jak z osobnym specularem i podobnym efektem. OFC. Można robić warstwy, filtry górnoprzepustowe... ale to fake i to słaby bo wymagający dużo czasu procka/GPU. Większość materiałów odbija światło... ale malo które są tak liniowo od cepa powiązane. Zazwyczaj jest to krzywa, dlatego wiele materialow słabo odbija światło odbite (ba w fotografii masz, filtr polaryzacyjny zmniejszający swiatlo odbite pozostawiając bezpośrednie), a mocne źródła bezpośrednie odbijają dobrze bez mocnego rozproszenia. Ps. Tak napisalem większość bo nie lubię kategorycznych stwierdzeń - żebyś się nie czepiał pod am przykład nie odbijający światła - czarne dziury.

Bzdura. Często są powiązane, ale jest to tylko jedna z możliwości Nie lepszy sam, a lepszy rozdzielony - wiele jest materiałów gdzie inny kolor ma specular od koloru odbicia świata, wiele jest takich gdzie kolor jest inny gdy pod innym kontem pada światło. W naturze? Ot pancerze żuków czy niektóre kamienie szlachetne/półszlachetne... mając oddzielnie specular znacznie łatwiej osiągnąć zadowalający efekt. Ale nawet głupi plastik o którym pisaliśmy odbija pięknie speculara, nie odbijając świata.

Tak zawsze jest - Spec jest tylko spec i tu tylko jest sztucznie z mirrorem podpięty Dopóki nie ma wypiekania tekstur w cycles mi nie zależy ;p. Specular jest liczony jak promień trafia w obiekt razem dla każdego światła mixowany z kolorem i zwracany jako kolor materiału w tym punkcie. Co ty mówisz o 2giej kaustyce? Kaustyka powstaje tylko przy backward pathtracing, materiały Glossy robi się przy forward pathtracing (jak uderzy promień od światła w obiekt to jego kolor jest obliczany przez diffuse + specular + forward pathtracing (rzucane są wektory w hemisferze do normalnej (losowane przez montecarlo) + podobnie w hemisferze do załamanego promienia - często nawet w mniejszym promieniu (tym mniejszym im bardzie przypomina powierzchnię lustra) i jak uderzy taki promień forward w inny obiekt to pobierany jest diffuse + specular i jeśli ustawienia nadrzędne w light patch nie wskazują niższej głębokości dalej). Jest to tzw Bi-Directional Path Tracing. Spec zawsze masz oddzielnie (bez niego nie widziałbyś odbić od świateł - odbijały by Ci się tylko obiekty realne na scenie), a brak dostępu do niego jest denerwujący. Specular pojawia się tylko od świateł - to, że odbija Ci się specular od innego obiektu to już zasługa mirrora, który odbije drugi obiekt wraz z jego specularem. Połączenie tego jakie jest obecnie jest bardzo sztuczne, ale też idioto odporne (jeden suwak dostosowuje jak ma zachowywać się specular na tak chropowatej powierzchni i jak bardzo ma działac mirror i z jakim glossy)... odbiera to całą gamę możliwości... jedyną zaletą jest to, że ciężko spartaczyć jak się nie wie co się robi. Pokaż mi kogoś tu kto nie lubi unbiasów. Problemem nie jest unbias tylko sztuczne ograniczenia. Tak jak nie lubię w innych programach stylizowanych na łatwe w użyciu (chowające ustawienia lub je wyrzucające, bo traktuje się użytkownika jak idiotę i usuwa się w strachu aby się nie skaleczył). Blender to nie zabawka dla dzieciaków, tylko do zastosowań profesjonalnych i niektórych irytuje, że odbiera się funkcjonalność, aby promować idiotoodporny system... to jednak nie ma nic wspólnego z biased/unbiased.

Mix materiałów to najgorszy fake jaki można zrobić. W Specylar Cyclesowym też Ci się lampy odbijają - reszta to glossy tak jak w internalowym materiale z włączonym mirror i ustawieniu stopnia odbijania i glossy.

Nie będę przeglądał 37 stron, żeby szukać tej dyskusji. Dziwi tylko to, że tylko niektórym - obecnie nie masz prawie żadnego wpływu na wygląd materiału i nawet specmapki nie możesz zrobić (a są materiały które mają dany kolor, a rozbłyski specular mają inne) - ogólnie od początku nie podobało mi się to jak wyglądają materiały w Cycles (niektórym się to podoba i wychodzili z siebie ze szczęścia), a rozwija się już trochę i dalej materiały wyglądają jak wersja prealpha tego co powinno być.

Spec to tylko spec! Czyli właśnie bezpośrednio od światła. Odbicia to już zasługa pathtracingu z montecarlo. Połączenie dystrybucji specular i dystrybucji promieni w pathtracingu to jedynie ułatwienie ustawień materiałów... ale też ograniczenie.

Wszystkie? Beckmann (ostatnio robiłem implementacje w GLSL i działa nieźle na mobilkach nawet) czy GGX stosowane obecnie w Cycles też? Beckmann jest stary jak świat i opiera się na nim Cook-Torrance, a GGX to kolejna praca Torrance'a i kilku innych gości. To co Ci się podoba to nie tyle, że nie ma spec (bo jest), a to, ze łatwo się go ustawia (wystarczy glossiness materiału i tyle), a efekt który Ci się podoba, to zaleta głównie pathtracer vs raytracer. BTW. Właśnie sprawdziłem kod blendera i z tych przytoczonych wcześniej Ashikhmin-Shirley i Ward już są (pod Velvet i Anisotropic).

Tak tylko odstraszyło to wcześniej kiedy nie było dobrych implementacji na CPU (a implementacja AMD dla CPU też ssie ;p). Phong jest fajny do plastiku, ale do innych rzeczy wolałbyś użyć Ashikhmin-Shirley, Ward, Cook-Torrance. Nie trywializuj odrębnego specular do plastikowego Phonga.

Co by cię bardziej odstraszyło rzecz wymagająca więcej pracy czy niemożliwa? Kod Cycles dla OpenCL jest znacznie bardziej rozbudowany niż jest to włączone w buildach, ale co z tego, że napisał, jak nie działa (błędy kompilatora AMD) i kod sobie czeka już od bardzo dawna, aż użycie go będzie możliwe (tzn jest u Nvidii czy Intela, ale nie u AMD). MDL to z tego co pamiętam kastrat na potrzeby iRay, bo ten nie byłby w stanie obsługiwać całego MSL, więc wątpię, aby MDL zastąpił MSL, a raczej kiedy iRay dorośnie to zmieni na MSL. RSL to opis shaderów, a to jest takie samo i nie ważne jakim rendererem jest Cycles - RSL jest stosowany w bardzo odległych od siebie rendererach. Nie czytałem całego wątku, ani nawet ostatnich stron, ale jeśli tak ktoś uważa to jest w błędzie - Cycles z założenia mial olewać fizyczną dokładność i miał być szybkim rendererem wystarczająco dobrze udającym, aby dało się go dalej używać do filmów.