Skoti

Chciałeś powiedzieć jedną podstawową wadę? Połączenie renderingu CPU+GPU ma sens tylko i wyłącznie w APU i SoC, gdzie CPU i GPU współdzielą pamięć, ale na takim GPU zapewne renderować i tak nie będziesz. Renderując na CPU+GPU przy dyskretnym GPU uzyskasz gorszy rezultat niż renderując na samym GPU (gdzie procek jest zajęty mocno przerzucaniem danych na kontekst GPU i kopiując dane z pamięci CPU do GPU i w drugą stronę). Sam pomysł wykorzystania algorytmów, które da się zastosować na CPU i GPU jest największym błędem Luxa, przez co ani na CPU dobrze nie działa kod OpenCL (słabe kompilatory w sterownikach), ani na GPU (niepasujące do architektury GPU algorytmy). Wszystkie renderery oparte o OpenCL czyli Vray czy IndigoRT mogą bez problemu pracować w trybie CPU+GPU, ale twórcy tych rendererów specjalnie zablokowali tą opcję (bo przy dyskretnych GPU, a tylko takie się używa do GPGPU działa to na niekorzyść wydajności). LuxRender miał oddzielny projekt SmallLuxGPU czyli super prosty pathtracer, oparty na SmallptGPU, ale to dawne dzieje. Później projekt przerobiono na LuxRays i to on jest w LuxRender, ale ze SLG nie ma wiele wspólnego, bo zupełnie inaczej renderuje - ma dużo większe możliwości, ale jest też co najmniej kilkadziesiąt razy wolniejszy.

VRay to zupełnie inny typ renderingu - duże uproszczenia, ale szybki czas renderingu. To, że lux ma fajne featur'y nie oznacza, że jest to soft nadający się do poważnej pracy. Mitsuba też ma fajne możliwości, ale co z tego jak nadaje się do testów featurów, ale nie do poważnej pracy. To nie ilość punktów pod "features" jest ważna, a jakość i wydajność implementacji tych potrzebnych w praktyce. Przykładowo taki Cycles teoretycznie możliwości ma mizerne, ale w praktyce jest dużo lepszym silnikiem niż LuxRender (który teoretycznie potrafi dużo więcej, ale podstawowe rzeczy robi dużo gorzej i wolniej, przez co nie nadaje się do niczego, poza wykonywaniem testów możliwości (lub przy ekstremalnie cierpliwych osobach do stila renderowanego kilka dni)).

Zaletą Luxa jest chyba jedynie tylko to, że rozwój jest wspierany przez AMD i jako nieliczny silnik działa z ich niedopracowanym kompilatorem OpenCL. Pewnie wspomniane wyżej kilka osób to nieszczęśliwi posiadacze kart AMD, którzy nie mają praktycznie wyjścia chcąc renderować na GPU.

Lampa typu Area. PS. Emit by działało, jakbyś włączył Indirect lighting, ale zapewne nie spełniłoby to Twoich oczekiwań, bo nie dostaniesz tak speculara, a prawdopodobnie o niego chodzi (ofc możesz włączyć mirror na obiekcie który ma odbierać światło i będzie prawie jak w Cycles wtedy ;p).

@god_of_dump: Dalej nie obsługuje CMYK (pomijając wsparcie w postaci pluginu Separate który istnieje od dawna)... jedynie przez przepisanie całego jądra GIMPA na GEGL jest dopiero szansa, że w przyszłości będzie wspierał CMYK.

@Nezumi: Gdyby to była tylko niewiedza z dziedziny PS to jeszcze nie byłoby źle (nie musisz znać Photoshopa, aby pisać o Gimpie, podobnie jak nie musisz znać Gimpa, aby pisać o Photoshopie - ot nie powinni robić porównań tylko robić swoje)... ale tu problem jest większy, bo razi niewiedza z zakresu samego Gimpa, a to już magazyn o Gimpie zupełnie dyskwalifikuje.

Tu się wykazali nawet nieznajomością Gimpa, bo tu powinni porównywać to narzędzie Patch Tool który jest w Gimpie, a nie Clone (który działa zupełnie inaczej).

Niestety to nie błąd. Collada nie przewiduje czegoś takiego jak normalmapki. Możesz podpiąć sobie do eksportu mapkę przykładowo do Ambient/Emit to się wyeksporuje. Co prawda Blender może dodać normalmapkę jako "blenderowe rozszerzenie" i poprawnie importować, ale inne programy tego nie odczytają.

@Nezumi: Rozwoju kodu gimpa nie śledzę tak uważnie i bardziej jako kibic (użytkownik nie oglądający kodu), ale zapewne (jak zwykle) błędy projektowe spowodowały większe błędy w zaprogramowaniu podstaw (core), co uniemożliwiło/utrudniło napisanie dobrze narzędzi, a że wybrali pisać narzędzia aby były szybko, a nie dobrze to powstało wiele narzędzi niewspółgrających ze sobą (skąd my to znamy?) i im dalej w to brnięto tym trudniej teraz przywrócić możliwość rozwoju dalej (po "dynamicznym rozwoju" walnęli w ścianę i muszą pisać wszystko od nowa). OFC poza ostatnim nawiasem co jest tylko przetłumaczonym mailem od jednego z twórców jest to tylko moje przypuszczenie i nie odpowiadam za to jak ono trafne lub nie w tej konkretnej sytuacji jest, bo jak wspomniałem, rozwój gimpa znam od strony która mi nie pozwala nic stwierdzić, poza tym, że te narzędzia są, ale są źle wykonane (o czym sam wiesz ;p).

@ikkiz: Mi też się przydają (gdyby jeszcze kod był lepiej zaprojektowany to pozwalałoby to lepsze narzędzia tworzyć i było by super), ale dobrze wiesz, że bez ngonów możesz się w każdym wypadku obejść (może czasami mniej wygodnie, ale zawsze możesz uzyskać to co chcesz bez nich), czego nie można mówić o sztucznym ograniczeniu możliwości cycles zmniejszające jego możliwości i elastyczność w wielu zastosowaniach - to taka różnica. Odpadliby tylko Ci wiecznie testujący o których pisał mrys. Inni 2 lata przeklinali korzystając dalej z 2.4x i jakoś nie upadł, a ten czas zmarnowano. Krita jest super... bo jest super zarządzana z pomysłem i planem budowanym dobrze od podstaw. To powinien być wzór dla Blendera (a bliżej mu tu niestety do gimpa - z tym, że Gimp doszedł już do momentu kiedy aby się rozwijać trzeba wszystko wyrzucić i przepisać (całe jądro Gimpa jest przepisywane, bo narosło tyle złego kodu, że już się rozwijać nie dało i trzeba napisać cały program od nowa), a Blendera to czeka za kilka lat).

Jest to przeraźliwie proste zadanie ;p. Tesselacja w dyntopo zachowuje się tak, że jedna z krawędzi trójkąta jest dzielona na 2 (zależnie od szczegółowości powstałe 2 tri w ten sposób, w ten sam sposób są dzielone). Zachowanie UV to przy podziale i dodaniu wierzchołka na środku EDGE (wyciągnięcie średniej z dla punktu A i B tej krawędzi) po prostu zapisać mu w UV średnią z punków Auv i Buv (czyli w UV tą krawędź też przedzielić na pół co jak wiesz jest bardzo proste), a reszcie wierzchołków nic nie zmieniasz, bo one zostają ze starą pozycją i UV. Dyntopo jest głównie przydatne przy dodawaniu szczegółów, a to o czym mówisz (podział całej siatki na pierdyliony tri, aby zrobić w jednym miejscu rysę na małej powierzchni) to tragedia. Właśnie tu do tych zastosowań dyntopo jest potrzebne (masz base mesh i chcesz dodać szczegóły, a nie z cube robić całą postać - już tu bardziej zasadne jest odesłanie do multiress czy podziału siatki ;p).

@Nezumi: Mam podobnie w stosunku do Ciebie. "Kiedy przychodzi do tematow, ktore juz z latwoscia moge sprawdzic (ngony, rozwoj Blendera) zaczynaja sie schody." Rozwój Blendera, aby można było się rzetelnie wypowiadać, trzeba znać z większej perspektywy. Nie tylko ze strony użytkownika, a i od strony rozwoju oprogramowania i łatwości rozwoju kodu. Ty znasz tylko sielankową wizję przez różowe okulary od strony użytkownika, który dostaje nowe cukiereczki, ja patrzę na tą sprawę po prostu z większego dystansu. To co mówisz nie jest nieprawdą - wręcz przeciwnie, tylko się zdaje się nie dopuszczasz myśli, że to nie tylko może współgrać z tym co mówię o rozwoju oprogramowania, a wręcz jest z tym ściśle powiązane. Gdyby blender miał dokonać zmiany w rozwoju pewnie przez najbliższy rok przeklinałbyś programistów jako użytkownik, a dopiero po 3ch latach zauważył słuszność tej decyzji i docenił od strony użytkownika, bo rozwój blendera byłby znacznie bardziej dynamiczny i dopracowany. Co do ngonów jest to kwestia opinii. Nie mówię, że ngony to zło, ani że nie są przydatne... tylko tyle, że nie są konieczne - z pewnością nie tak, jak poprawne działanie knife, bevel itp co długo leżało, a czasami dalej leży.

@Nezumi: czyli co proponujesz skoczyć ze spadochronem, a później w locie na żywo uczyć się jak on działa, kiedy otworzyć itp? Podobnie z pływaniem wskoczyć na głęboką wodę nie znając podstaw? Ja tam wolę podchodzić do sprawy inaczej. Znajomość teorii nie gwarantuje sukcesu, ale nieznajomość teorii boli i znacząco utrudnia końcowy sukces. Z tym porównaniem to wyolbrzymiłeś strasznie... mniej więcej tak jakbym powiedział, że wyrostek robaczkowy nie jest niezbędny do życia, a ty "w tych kategoriach" napisał, ze serce czy mózg też nie są niezbędne bo przecież można nie żyć.

To nic nie zmienia - to też jest robione przez podział już istniejących face i działa tak samo jak dla zrobienia szczegółu jak szrama na pysku modelu. Te wyciągnięte teksturę normalnie przez podział. Wyglądałoby to mniej więcej tak: Jest to naturalna rzecz jaką robią obecnie wszystkie nowoczesne silniki gier na rynku. Tekstura się będzie Ci rozciągać w tych miejscach jak najbardziej, bo rozdzielczość tam będzie niska i pod koniec masz już pojedyńczy piksel na wiele wierzchołków. Dla tego PTex byłby lepszy, ale też dużo więcej pracy trzeba włożyć, aby PTex działał. Jednak bezsensowne jest porzucanie UV tak jak jest to robione teraz, bo podział UV z dyntopo jest wręcz darmowy (ten sam kod co dla wierzchołków załatwia sprawę), a w wielu przypadkach jest dobry.

@mallow: Gdzie napisałem, że się nie przydają? Pisałem tylko, że nie są niczym niezbędnym, a to różnica.

@Nezumi: Zapominasz o tym, że jestem programistą grafiki i teorię zazwyczaj znam przed praktyką ;p. Blenderem poważniej zainteresowałem się dopiero na przełomie 2007/8, a wcześniej już teorię znałem, a grafiką w innych programach zajmowałem się od 99/00 (wcześniej programowałem ją). Więc tak... nie pamiętam czy kiedykolwiek, a jest też możliwe, że nigdy.

To akurat bardzo proste - ja robię tesselację części siatki (w zależności od odległości od kamery niektóre face są bardziej lub mniej zagęszczone) u siebie w silniku i jakoś*UV nie gubię (podobnie nie gubię przy Mesh Simplifier (Decimate), a blender do dziś to robi). Tu zachowanie UV jest bardzo proste, bo nowa siatka nie powstaje - są dodawane tylko wierzchołki na już istniejącej siatce (obecna już siatka z UV jest dzielona i tak jak wyliczana jest pozycja nowych wierzchołków z pozycji wierzchołków już istniejących tak można interpolować UV z wierzchołków już istniejących). Czyli jak trójkąt teselujesz to powinien ten trójkąt teselować się też w UV. Koncepcja PTEX jest przydatna (rozdzielczość tych szczegółów można by dostosować bardziej niż na zwykłym UV, gdzie dzieliłoby istniejące na UV face i te szczegóły miałyby mniejszą rozdzielczość niż w niektórych przypadkach by się chciało), ale nie jest to konieczne. Gdyby nie to, że już kilka osób się do tego zabierało, miało usuwać nieistniejące już w OpenGL rzeczy (jak GL_SELECT wywalony z OpenGL 4 lata temu (w połowie 2008 oznaczony jako przestarzały)) i nic z tego do dziś nie widać to może bym się i ucieszył.

@Krzysiek: Ogólnie dyntopo czyli teselacja siatki gdzie malujesz obecnie niszczy UV (szkoda) i zmniejsza zastosowanie tego narzędzia. Obecnie raczej rób base mesh -> sculpt z multires i dopiero jak to zrobisz dyntopo można użyć na kopii do rzeźbienia małych szczegółów, które wypalisz na model z mniejszą siatką (normal czy displace mapki)... obecnie tylko taki scenariusz wydaje mi się użyteczny dla dyntopo. @up: Decimate w blenderze robi tragiczną siatkę i artefaktów sporo (co zresztą pokazałeś).

@ikkiz: Zanim się włączy blendera powinien powstać projekt, jednak zawsze małe poprawki są potrzebne... jednak nie miałem nigdy problemów z poprawieniem topologii korzystając z max czworokątów, i ngony mi do tego nie były nigdy niezbędne.

@ikkiz: Ngony też używam, ale nie jest to dla mnie żadne błogosławieństwo (musiałem w swoim silniku odwzorować sposób triangulacji Blendera, żeby nie było artefaktów i tyle), ani też jakaś wielka sprawa (bardziej one się przydają do pisania narzędzi niż grafikowi, któremu do szczęścia nie są potrzebne - jak są to są (jak wie się co się robi i jak to nie są żadną przeszkodą), ale nie ma żadnej tragedii jak ich nie ma). Co do gameart to dziś w praktyce nie różni się on od zwykłego modelowania pod subsurf/multires+sculpt czy pod rigowanie - model trzeba zrigować, sprzęt pozwala na dobrą siatkę, musisz zrobić model HiPoly ze szczegółami i wypalać na normalmapkę i mapkę wysokości (pod tesselację). Więc jest to najnormalniejsze modelowanie + modelowanie lo poly w kilku wersjach (inaczej pod desktop, inaczej pod mobilki) z myśleniem o wydajności RT. To już nie czasy kiedy gameart to kilka poly z teksturą, dziś GA oznacza model LoPoly (często kilka takich do LoD) + HiPoly + wypalanie.

@Creator: Jeśli tak ktoś myśli to jest głupi - wielokąty i tak muszą przejść triangulację przed renderingiem i jeśli się nie martwią o siatkę to dostaną artefakty (nawet jest to bardziej prawdopodobne, bo nie wiedzą jak ten 17sto kąt zostanie podzielony przez automat na trójkąty).

Wiem o czym piszesz (o dodaniu linijki CU_TARGET_COMPUTE_35 do kodu) ale to nie załatwia sprawy, bo trzeba trochę inaczej napisać kod. Tak jakbym miał kupować coś na już to zapewne dalej byłoby to 580 - jeśli nie 2x to nawet 1x bo zyski niewielkie przy Keplerze, a lepiej wymienić na Keplera jak już będzie dobrze obsługiwany (i tańszy ;p).

Shader model w tytanie jest taki sam jak w Fermi (480) czyli w wersji 5. Pomyliłeś shadery graficzne z kernelami odliczeniowymi. To o czym mówisz to "Compute Capability" i w Titanie jest 3.5, w serii 600 jest 3.0, a w seriach 400 i 500 zależnie od wersji 2.0 (HiEndy) i 2.1 (460 i niższe modele, oraz 560 i niższe). https://developer.nvidia.com/cuda-gpus Titan i Compute Capability w wersji 3.5 wprowadzają bardzo dużo dobrego. Dynamic Parallelism i Hyper‐Q (czyli tego czego brakowało 680 aby się nadawał do obliczeń) to bardzo fajne rozwiązania i moc Titan pokaże dopiero jak to się wykorzysta. Jeśli się to wykorzysta to wydajność Titana może być w okolicach 3x większej niż 580. 480 ma 1.4GHz, a titan niecałe w przedziale 0.8 i 0.9, więc nie porównuj tych rdzeni tak dosłownie. OFC Kepler ma dużo rdzeni w SIMD co powoduje spadek wydajności na rdzeń względem Fermi... chyba, że wykorzysta się Dynamic Parallelism i Hyper‐Q, które dostępne są w Tytanie (pełnym keplerze), a nie były w 680.

@Nezumi: o tym pisałem - dobry grafik nie ma się o co bać, bo obroni się jakość prac... Ci którzy się boją widocznie mają o co, bo uważają, że nie obronią się ;p

@Nezumi: No właśnie mówię, że jest to spore uproszczenie, ale właśnie to jest sedno tego co ich boli (bo na piratach nie będą zarabiać, tak jak na edukacyjnych wersjach które na to nie pozwalają (tylko niekomercyjne zastosowania)). Darmowe oprogramowanie do zastosowań komercyjnych (zerowa bariera wejścia) ich boli... to wielkie uproszczenie i to nie tak wprost działa, ale właśnie o tym mówią (darmowy soft -> niska bariera wejścia -> większa konkurencja -> niższe płace). To tak jak z sprzeciwem taksówkarzy, żeby znieść ograniczenia ilości taksówek w mieście i licencji.