ca mel

Todd Palamar seria "Mastering Maya". http://eu.wiley.com/WileyCDA/WileyTitle/productCd-1119059828,subjectCd-CSC0.html Bywa na allegro najnowsza, do 2016. Przejrzałem tę książkę i myślę, że się nie zawiedziesz. Osobiście też wolę książki, szczególnie czytane na tablecie w pdf. Mam wrażenie, że videotutoriale w jakiś sposób ogłupiają, wiedza podana jest szybko, ale nie zatrzymuje się w głowie na dłużej. Czytając książkę bardziej się skupiam i pamiętam konkretne rozwiązania po latach. Edit: Może zabrzmi to kuriozalnie, że polecę też bardzo starą książkę do prastarej już Mayi, ale "Maya 4 - 30 przykładów animacji" jest bardzo świetną pozycją. Oczywiście w nowych sporo się zmieniło, niektórych rozwiązań już nawet nie ma (np starego modułu clotch), ale ta króciutka książka w fajny sposób wprowadza w animację nieliniową. Czyli pozy z character editor i obsługa trax editora z animowanymi przejściami. Jeśli uda Ci się gdzieś to znaleźć, to koniecznie przeczytaj.

Właśnie, platforma pobiera więcej. Wstawiłeś bardzo fajny wykres z którego jednoznacznie wynika, że procesor AMD przy @4,5 pożre jakieś 155W, a przy @4,2 jakieś 140W. Czyli o 15W mniej. Teraz odejmij od tych 300W które pobierał cały testowany komputer te 15W i przelicz czy jest to jakaś wielka różnica. Platforma plus podkręcony procesor to nie 200W, nie wiem skąd bierzesz tę liczbę. Zasilacze mają też swoją sprawność, często spora ilość energii (na poziomie 40%) idzie w piach. Ja wiem, że w cenie komputera z 5960X można zmieścić z 5 takich AMDków, i zgadzam się z Tobą. Rzecz tylko w tym, że już przy trzech sztukach, po kilku miesiącach ciągłych renderingów dogoni Cię rachunek za prąd, bo on nie jest tani. Rendering 24/h to 8-9 miesięcy, 12/h półtora roku. Czyli średnio po roku zwraca się koszt inwestycji 3k w jeden lepszy komputer, a od tej pory już tylko na tej inwestycji zarabiasz. Dlatego do mini farmy nie nadają się tak słabe procesory jak zaproponowałeś. Oczywiście, że zamiast jednego 5960X jeszcze lepiej jest mieć dwa 5820K, ale to kolejne różnice w kosztach. Mam takie 3 sztuki @4,3, dwie z nich renderują coś na okrągło i widzę po rachunku, że utrzymanie jednego to średnio jakieś 80zł /mc. Rozwiązanie z 5960 podałem jako przykład pomysłu, jak lepiej zainwestować pieniądze w kontekście dłuższego renderowania 12h/dobę dziennie. Po roku - półtora, inwestycja się zwraca, a komputery kupuje się średnio co 3 lata. Różnica w wydajności kilku, 5-6 amdków byłaby już miażdżąca, i opłaciłoby się to może kupić do pojedynczego projektu, gdzie potrzebna jest chwilowo duża ilość mocy obliczeniowej. Ale przy ciągłej eksploatacji koszty energii przemawiają za mniejszą ilością silniejszych komputerów. Dążę do tego, że za kwotę którą będzie trzeba zapłacić dostawcy prądu, lepiej jest dołożyć już na starcie do lepszego komputera niż użerać się z kilkoma i opłacać nieporównywalnie większe rachunki. Gdyby było jak mówisz, wszelkie farmy stałyby na desktopowych AMD. Poza tym przedmówca słusznie zauważył - renderujący komputer to nie tylko sprzęt.

W sumie to nie wiem już jak z Tobą rozmawiać, nie pierwszy raz zresztą. Ja piszę 300W plus sprawność zasilacza, Ty swoje, że 200W. Wstaw w takim razie AMD-kom zasilacz 200-250W i zobacz co się stanie gdy podkręcisz. Bo jeżeli nie podkręcisz, to dostaniesz wydajność 6core intela z dobrym OC za 1600zł/CPU. Podkręcisz mniej, to będziesz dłużej czekał na sceny, i dojdą dodatkowe godziny, każda po kilkaset wat. Dość logicznym jest fakt, że skoro już podkręcasz, to wyciskasz ze sprzętu jak najwięcej. Zakładam więc mocny OC AMD i mocny dla 8core @ 4.3. Odpowiada to mniej więcej 3x (300-350W) vs 1x (350-450W) przy tej samej wydajności. Weź do ręki kalkulator i przelicz kiedy, mi wyszło że po 15-18 miesiącach, przyjemnej pracy z jednym komputerem. Zakładając, że nie liczy non stop, a przez połowę czasu. Skoro ktoś buduje maszynę do renderingu, to zwykle używa jej dzień w dzień, jednego dnia 8h innego 16h, a jeszcze kiedy indziej non stop 24/h (tak, komputery umieją też liczyć gdy śpisz!). Nie kupuje się przecież sprzętu, żeby na niego patrzeć.

Napisałem, że po kilku miesiącach, nie po jednym. Zakładam, że jeden komputer z podkręconym AMD na pokładzie zeżre 350W w stresie, nie liczę tu już sprawności zasilacza, powinno się do tego dodać jeszcze parę watów. http://www.overclock3d.net/reviews/cpu_mainboard/amd_fx_8320e_8_core_cpu_review/2 http://www.guru3d.com/articles-pages/amd-fx-8320e-processor-review,18.html Autor wątku zamierza renderować 12godzin dziennie, stad przeliczenie 350W x 12 h x 30 dni x 3 sztuki = 370kWh miesięcznie, czyli 230zł. Oszczędność w przypadku 8core intela to 150 /mc. Masz rację, nie odnotowałem, że ceny procesorów tak bardzo poszły w górę. Różnica 3 x AMD vs Intel 8C to 2500-3000zł. Gdy ostatnio składałem komputer, 5960x można było kupić za ok 4k, a kupiłem kilka 5820K za 1,5k zł. Zakup zwróciłby się po kilkunastu, a nie po kilku miesiącach. Po około półtora roku.

Odnośnie kilku kiepskich komputerów w sieci dodam jeszcze, że osobiście wolałbym już jeszcze inne inne rozwiązanie. Dołożyłbym dodatkowe 1500-2000zł i kupił nowy zestaw oparty na 8 rdzeniowym i7. 3 komputery z AMD to 350W x 12 h x 30 dni x 3 sztuki = 370kWh miesięcznie, czyli 230zł do rachunku za prąd. Jeden i7 8core OC pracujący na pełnych obrotach pół doby, to koszt ok 90zł/mc, więc inwestycja zwróciłaby się po kilku miesiącach. A podkręcony jest o 30% szybszy od stacji Z800 i trochę szybszy od tych amdków. W kilka komputerów warto pchać się dopiero wtedy, gdy pojedynczy komputer jest znacznie droższy niż dwa równoważne. W przypadku różnicy 10-15% nie warto, bo zjedzą Cię koszty utrzymania kilku maszyn.

Oczywiście, można tak robić jak mówisz, choć takie dzielenie scen na dłuższą metę może być po prostu upierdliwe - zakładam, że chodzi Ci o render region. Ja np. liczę w 99% procentach animacje, więc oczywiście robię jak mówisz - fotony, FG wypalam na jednym komputerze do map, a potem przeliczam całość na 2-3 komputerach. Natomiast szlag by mnie pewnie trafił za którymś razem, gdybym miał robić to, plus dzielić scenę na regiony za każdą renderowaną próbną klatką. Taki distributed rendering spisuje się tu jako tako jeśli chodzi o testowe rendery, szczególnie, że uwzględnia render region wybrany myszą w oknie render view, więc jest to bardzo wygodne, póki ciężkie tekstury lub obiekty nie popsują całej zabawy. A nawet jeśli coś się wykrzaczy raz na parę razy, to przy czasach testowych klatek nie jest to wielka tragedia. Gorzej gdy krzaczy się w finalnym renderingu, trwającym dajmy na to 4 godziny. Rozwiązaniem jest to co napisałeś, czyli ręczne dzielenie regionów. Może się ewentualnie pojawić lekki problem z kompozycją, jeżeli używasz render passów, jakieś zróżnicowane wzory fraktali, jeśli algorytm zależy w jakiś sposób od konkretnego komputera. Wszystkie te drobne problemy mogą wystąpić, lecz nie muszą, a jeśli wystąpią to na pewno da się je obejść, bywają po prostu upierdliwym pochłaniaczem czasu. No i ma wielokomputerowy rendering swoje inne wady - przede wszystkim ogranicza go właśnie przepustowość sieci. Pracuję czasem na scenach z olbrzymim cache obiektów, tekstury nierzadko też swoje ważą. Te dodatkowe komputery muszą pobrać te dane, nawet jeśli nie pracują w DR. Są co prawda rozwiązania łączące kilka gigabitowych kart w jedno pasmo, ale to chyba trochę wyższa szkoła jazdy stawiać to na windowsie i mieć pewność że niezawodnie działa. Przyjemniej byłoby mieć zamiast 2-3 komputerów jedną porządną maszynę która to wszystko ogarnia, nie pojawiają się po prostu dodatkowe niespodzianki. Dlatego myślę, że dobrze zrobiłeś kupując porządniejszą stację. Może wolniejszą o 20% od tych amdków, ale oszczędzającą sporo nerwów i kasy za prąd.

I tu pojawia się śmieszna sprawa, albowiem distributed rendering ogranicza prędkość wszystkich do najwolniejszego komputera. Nie wiem jak to jest z Coroną, ale Vray i Mental mają taką właśnie przypadłość. Czyli 3x szybszy komputer działałby jak jeden z tych AMD. Mógłby jednak szybciej wypalać odpowiednie mapy i tekstury. Więc najlepszym rozwiązaniem byłyby wtedy 2 stacje Z800. Do tego, jeśli jeden z komputerów w międzyczasie się popsuje czy odłączy od sieci, tracisz pracę wszystkich, bo zadania rozsyłane są tylko raz. Nie raz już kłąłem na wszystko co się da, gdy po kilku godzinach renderingu proces z ostatnim tile zawieszał się na którymś z komputerów bez wyraźnych powodów. Wiele komputerów stosuje się głównie wtedy, gdy liczysz animacje, każda z maszyn ogarnia wtedy swoje klatki spływające w jedno miejsce. Do statycznych obrazów, liczonych na wielu rdzeniach dobrze jest, jeśli liczone są na tym samym komputerze. Bardzo dużo "mocy" ucieka na komunikację, wymianę tekstur, sama sieć między komputerami też musi mieć bardzo dużą przepustowość jeśli tekstury są duże. Także ma to wiele wad, nie mówiąc już o prądożerności starszych procesorów i reszty komponentów budujących całe dodatkowe komputery.

Przed chwilą wyszedł Ci jeden zestaw za 3700zł, więc jak w cenie 4500zł chcesz złożyć 3 takie zestawy? Upraszczając konfigurację: Wyrzucając SSD i zamieniając silną kartę graficzną na słabszą, wystarczającą w farmie, wychodzi ~2300za jedną stację na siepowatym AMD z cinebench na poziomie 5,5 - 7 pkt po OC. Czyli w budżecie 4,5k są dwie stacje, o mocy jednej z cpu 5280K albo gotowej Z800. Dwie, żrące półtora raza tyle prądu, mające o 50% mniej pamięci i trzy razy bardziej przeszkadzające niż jeden komputer HP Z800 bez OC. Choć fakt, że w takiej sytuacji gdy jeden komputer się skiepści, zostaje drugi do obliczeń na pół gwizdka. Dochodzi też 2-3 letnia gwarancja na nowe części. Gdy popsuje się Z800, na jakiś czas zostaje się z niczym.

Amd w ogóle bym odpuścił, bo jego wydajność to nie ta klasa sprzętu (60-70% wydajności 5820K). Jeśli chodzi o 5820K, po podkręceniu możesz liczyć na wynik w Cinebench11 w przedziale 13,5 - 15, zależy od modelu. Natomiast 2x X5650 daje Ci pewne 14 pkt i dużą kulturę pracy, bo nie będziesz tego podkręcał. Wydajność z pojedynczego rdzenia w stacji Z800 będzie marna, ale jeśli nie zamierzasz na nim pracować, a jedynie renderować, to wybrałbym gotową używaną stację.

Dużo lepiej, teraz masz tu znacznie ciekawsze światła. Pokombinowałbym jeszcze z tynkiem, żeby nie był dla odmiany aż tak bardzo surowy, betonowy. Na ujęciu z garażem dodałbym jeszcze jedno światło, niezbyt mocne, by wydobyć trochę detalu z białej ściany, ram okiennych. Z kolei na tym z dwójką dzieci biała ściana wyszła zbyt brudna. Spróbuj wyrzucić tam teksturę, ale sprawić dodatkowym światłem (niepoprawnym fizycznie, z liniowym decay) by ściana nie była jednostajnie biała, a miała na sobie lekki gradient. Cienie postaci też jeszcze do poprawy. Roślinom na pierwszym planie dałbym blur alfy - trzeba zmieszać je lekko z niebem, żeby powstało wrażenie przenikania światła przez krawędzie liści. Po całości przydałaby się też jakaś flara, dodająca odrobinę ciepła i dodatkowych naturalnych barw.

Na ostatnim ujęciu dzieci myślę, że mają dobrą skalę i jest to najlepsze ujęcie, pomijając nienaturalne światło na postaciach. Za to na pierwszym kobieta jest dwa razy większa od samochodu, dziecko rzuca cień w kompletnie inną stronę niż wynika z oświetlenia budynku. Mimo tego, że jest dość blisko kamery, to też wydaje się być gigantem. Fiolet we włosach - skąd taki pomysł, wygląda jak wklejone z kompletnie innej bajki. Nocne ujęcie samo w sobie byłoby ciekawe, gdyby nie samochody. Oświetlone są w taki sposób, że wyglądają na wklejone. Są płaskie, powinna oświetlać je jakaś latarnia. Drzewo na pierwszym planie ewidentnie widać, że wklejka - zero zmieszania liści z niebem. Przydałby się tam chyba lekki dof, by uwiarygodnić pierwszy plan. Jeśli chodzi o materiały - wyglądają trochę jak wstępne testy betonu. Szczególnie parking na pierwszym ujęciu, wygląda jak odlany z jednego kawałka plastiku. Nawet ulica - asfalt, pozbawiona jest tekstury, albo przynajmniej na taką wygląda. Samo światło na dziennych ujęciach myślę, że ma za mało zdecydowane cienie. W tak mocnym słońcu, na jakie wskazują przepalenia cienie są ostre, rzucają czasem ciekawe wzory, budując przestrzeń na modelach. Za to trzeba pochwalić trawę. Szczególnie na nocnym ujęciu wyszła bardzo fajnie.

Fajne. Przyczepię się tylko do ostatniego ujęcia - wg mnie za dużo pierwszego planu jest tu w cieniu, w dolnej części wizualizacji. Zostawiłbym zacienioną tylko lewą albo prawą część Nie podoba mi się też ten świerk (coś ma nie tak z proporcjami i wyrazistą teksturą) i kształt tych małych choinek. Ale to detale, ogólnie 4+ ;]

Ode mnie trójka z plusem ;]

Dołożę swoje 3 gorszę do tego wątku. Pytanie, czy wymiana sprzętu ma odbyć się już teraz. Bo jeśli wstrzymacie się z tym jakieś 2-3, być może nawet 4 miesiące, za cenę 6ciu rdzeni będzie można kupić 8. W pierwszym kwartale 2016 wchodzą do masowej produkcji desktopowe Broadwell-E: 6-rdzeniowe/12-wątkowe Core i7-6800K i i7-6850K 8-rdzeniowe/16-wątkowe Core i7-6900K 10-rdzeniowe/20-wątkowe Core i7-6950X Ceny płyt głównych znamy, bo tym razem Intel zrobił niespodziankę i procesory te wejdą na istniejące płyty z podstawką LGA 2011-3 i chipsetem X99. A znając politykę cenową Intela: 10 rdzeni to 999$ 6 rdzeni za 400$ 8 rdzeni zaś planują sprzedawać za 500$, a jest szybszy i sporo tańszy niż 5960X Taki komputer posłuży 3-4 lata, nim powstaną 2x szybsze, więc być może warto poczekać na lepszy jeszcze chwilę. Piszę to na wypadek, gdyby z jakichś powodów firma nie chciała jednak przekroczyć budżetu 8k. Jeśli nie chcesz/nie możesz czekać, na dzień dobry wyrzuć tę kartę 970, zamień na GTX950. Edit: Swoją drogą, kupno 5960X to trochę taki niecodzienny ruch. W podobnej cenie (10k) można złożyć dwa oparte na 5820K, czyli mieć 12 szybszych rdzeni zamiast 8, w cenie o tysiąc zł większej. Czyli 65% wydajności więcej w cenie jednego tysiąca ;)

W sumie nie wiem jaki efekt chcesz uzyskać i jak wyobrażasz sobie to przejście z ostrego kantu w nieostry. Gdzieś wokół z założenia muszą pojawić się jakieś zagięcia. Wpadałoby więc się jeszcze tym pobawić i mimo wszystko zrobić jakąś linię rozdzielającą. Jeśli chodzi o coś takiego: to dodałem Poly split ring z ustawieniem absolute .1, po czym w miejscach gdzie geometria ma być gładka EdgeFlow, tak by maya znów ją zaokrągliła po swojemu. (na tym obrazku kliknij jeszcze raz, będzie rozdz. 2,5k) Edit: Tak wyobrażam sobie łączenie, dwie wersje - z gładszym i bardziej "uszczelkowym" przejściem, że tak to nazwę Dołączyłem plik MB (v2016) - po lewej wersja z edgeFlowem, w środku pogrzebana lekko pędzlem i ręcznie poprzesuwane wierzchołki, po prawej inny flow przejścia w nieostrą część. test_obiect.zip

1 Trzeba po prostu dodać tam dodatkowe podziały. Wykorzystałbym wariant ten z pierwszego obrazka, lecz robiąc trójkątne zamknięcie pętli wcześniej (skończyłbym na środkowym edgeloopie). A w miejscach gdzie będą trójkąty wstawiłbym dodatkowe krawędzie, przerabiając tym samym trójkąty na czworokąty (czyli wstawiłbym po obu stronach dodatkowego edgeloopa przez całą krawędź lub chociaż kawałek). 2 Albo dodaj dwa czy trzy dodatkowe loopy, jeden na środku tych ścian z przodu, a i 1-2 powyżej, tak by oddzielić dużą połać płaskiej geometrii od tych trójkątów. 3 Przyjrzyj się też okienku Crease. Być może ustawiając wysoką wartość crease tylko potrzebnym, ostrym krawędziom, obejdzie się bez dodatkowych podziałów na tym przegubie.

Pisałem oczywiście czysto teoretycznie - moja wiedza o dokładnym przetwarzaniu rozkazów w procesorach zatrzymała się na Pentium 4, miałem to jako jeden z głównych przedmiotów na studiach. Ale zakładam tu, że diametralnie się to wszystko do dziś nie zmieniło. Mikrorozkazy, wielopotokowość z przewidywaniem instrukcji i podmienianie całych bloków rejestrów bynajmniej nie są mi obce. Chodziło mi o to, że być może używając często tych samych danych, procesor nie zamienia bloków rejestrów na inne, bo byłoby to nieopłacalne, wykorzystuje więc te same zestawy. Używając więc często tych samych, np mnożąc przez taką samą macierz wiele kolejnych bloków danych, odwołuje się do owych rejestrów tak często, że nie wytrzymują tempa ciągłych odczytów z tego samego miejsca. Natomiast pracując na przypadkowych danych, procesor chętnie wymieni zestaw rejestrów (wymieni by nie opróżniać istniejącego, jest to wolniejsze), albo wpisze do nowego dane już wcześniej w pobocznym potoku (np w dodatkowym wątku przewidującym udane skoki) i po prostu "da spokój" poprzedniemu zestawowi. W ten sposób nie będzie czytał z tego samego miejsca, co chwilowo ochłodzi tę partię krzemu lub po prostu wydłuży czas dostępu do danych, opóźniając też spadki impulsów, które gdy są za krótkie powodują zawieszenie procesora. To oczywiście tak jak pisałem teoria, coś jednak jest na rzeczy - pewnym jest, że praktyczne operacje i być może powtarzalne dane wykańczają procesor bardziej niż stress test. 3-4 dni stress testów procesora 5820K @4.5 i pamięci - wszystko w porządku, mimo temperatury około 96-98C. 5-7 godzinny rendering, temperatury 96-98C - lecz zwiecha za każdym razem, wcześniej czy później. Jak wyjaśnisz ten fenomen, sensei? Skoro stress test potwierdził stabilność procesora i pamięci, to pewnie winny jest monitor...

I znowu wypisujesz jakieś bzdury (podobnie jak z tą kartą AMD i Mayą, gdzie na wniosek, że nic się złego nie dzieje, zgodziłeś się tylko Ty, po pokręceniu przez chwilę viewportem). Możesz zatem wyjaśnić, czemu kilka dni stress testów nie zawiesza mocno podkręconego komputera, a kilka godzin renderingu Mental ray na wysokim priorytecie procesu owszem ? Wydaje mi się, że znam rozwiązanie tej zagadki - te stress testy chyba na przemian obciążają różne partie procesora, używając nowych instrukcji, tak, że ma szanse zmienić zestaw rejestrów i ochłodzić używane przed chwilą. Co skutkuje nagrzewaniem go w miarę równomiernie i ochładzaniem chwilowo nieużytych. Za to silniki renderujące zwykle napisane są pod starszy procesor, bez niektórych nowych rejestrów, więc niektóre partie używane są non stop, aż któryś tranzystor nie wytrzymuje szybkich, zbyt piłokształtnych impulsów. Oczywiście to tylko moja teoria, nie wiem czy o to właśnie chodzi. W każdym razie bzdurą jest poleganie na stress testach. Praktyczny rendering zawiesi zbyt mocno podkręcony procesor, stress test niekoniecznie.

Portfolio, portfolio. Wszyscy tylko oglądaliby portfolio. A robić nie ma komu ! Portfolio będzie, i to mocne, gdy już powstanie krótkometrażowa animacja i wygra wszystkie konkursy ;)

[quote=materalia;1253408 Subd działa okej, nic nie wyjeżdża na boki, nic nie znika itp. W takim razie kupuję AMD, potrafisz namówić ! :)

No zdarzają się niestety. Nie chcę już dorzucać do pieca, ale przyznam się, że nie testowałem na win10. Win 7 only, być może pod 10 AMD magicznie rozwiązało te problemy :)

Miło, że zadałeś sobie tyle trudu i przetestowałeś Mayę z Radeonem. Teraz wiemy, skąd biorą się testerzy w Autodesku. Albo ludzie zatwierdzający sterowniki w AMD. Wszystko się odpala? Super, po co psuć coś, co działa, no nie? To fajny i szybki, przez co na pewno oszczędny sposób - włączyć program na godzinę i sprawdzić, czy kule są okrągłe i czy wszystko widać :) Zadałeś sobie trochę trudu z bardziej skomplikowaną edycją jakiejś geometrii? Po jakimś czasie na niektórych kartach pojawiają się zacięcia viewportu, zamiast np dwóch ścianek zaznaczają się wszystkie. Sprawdziłeś te openSubdivs? Nie wystają z nich jakieś dziwne trójkąty czy krawędzie przy edycji? Wiesz chociaż JAK je sprawdzić ? Czy przy cięższych scenach, po godzinnej pracy manipulatory nie zaczęły się zacinać ? Tak, że po szybkim wybraniu opcji spod np W, menu zostaje na ekranie. Rozumiem, że sprawdziłeś sceny z przykładów, z kilkoma paintFXsami. A co z wizualizacjami, co z wczytanymi referencjami, jak wygląda praca ze scenami ważącymi dajmy na to 15GB na Twoim nowym Radeonie? Przetestowałeś jakieś przesuwanie uv w cięższym obiekcie z multi mapowaniem uv z warstwową teksturą większą niż 4k? Jak się z tym pracuje? Pytam, bo swego czasu Radki nie dawały sobie z tym rady. Sprawdziłeś iloma światłami da się jednocześnie oświetlać scenę? Implementacja openGL miała problem z większą ilością niż 4-8. Posprawdzałeś wyświetlanie double side materials, poprawnie wyświetlanych normalnych ? Jak wyglądają rozmiary cloud particles w viewport 2.0? Dobrze są teraz odwzorowane? Pytam, bo swego czasu pod radeonem rozjeżdzały się na cały ekran. Nie wiem co Ty właściwie w tym czasie posprawdzałeś, wierzę, że po pokręceniu sceną przez parę minut nic się nie skrzaczyło, bo co niby miało? Litości, sprawdziłeś jakieś podstawowe sceny, bodaj z helpa i po tym wnosisz, że sprzęt jest sprawdzony i gotowy do poważnej pracy? Jeszcze raz powtarzam, że to forum dla twórców 3d, szukających praktycznych i sprawdzonych rozwiązań. A nie ludzi oglądających obiekty i gdybających jak im pójdzie wiedźmin gdy zmienią directX, powielających echo jakiegoś bełkotu AMD o nowej lepszej przyszłości. To co zacząłeś wyczyniać tym wątku od jakiegoś czasu, to jakaś kuriozalna farsa. Tyle ode mnie.

Ja zaś przerzucam zawsze obj'tem. Maxa trzeba tu pochwalić za świetny, konfigurowalny eksporter. Nigdy nie zginęły mi uvki, geometria trzyma swój układ (nie trzeba triangulacji). Od biedy, gdy jest wiele tekstur, albo jakieś podwójne mapowania, w ruch idzie fbx, ale czasem dzieje się coś ze ściankami.

1. To nie są testy tworzenia scen, a wyświetlania bardzo prostej geometrii. Problem znikających manipulatorów, źle zaznaczanych wierzchołków i inne nieprzyjemne jazdy pojawiają się przy edycji scen. A forum to zrzesza raczej twórców grafiki 3D, a nie biernych jej obserwatorów. 2. W tych testach nie ma openSubdivs, to nowość, a one tworzą ostatnio najwięcej problemów. 3. Są karty od AMD Fire, zgodne ze specyfikacją Autodesku i wierzę, że wszystko działa z nimi jak powinno. Rzecz w tym, że kosztują tyle co cała stacja robocza, więc po co je kupować, skoro 5-10x tańsza nvidia też działa jak powinna ? 4. Fajnie jest czasem poużywać trochę iRay, czyli renderera GPU dla Mental Ray, swoją drogą wykupionego przez nVidię. Na Radeonach się to kaszani. Tu masz pierwszy lepszy przykład, jak pracuje się w Maya z kartą Amd i jak z nVidią Inna sprawa, że w najnowszej 2016 wymienili API i co chwilę pojawia się kolejna masa bugów i niespodzianek.

Coś mi się wydaje Panie materalia, że nasza rozmowa zaczęła się już jakiś czas temu sprowadzać do czysto teoretycznej. Czy Ty używasz profesjonalnie oprogramowania 3D, czy raczej gdybasz sobie co by było, gdyby viewporty były lepiej dopracowane? :) Są jakie są, szukamy tu kart do poprawnej obsługi tego, co jest na rynku, a nie czysto teoretycznych rozważań jak powinno to wyglądać. Oczywiście, bardzo miło jest poczytać o teoriach rozwoju sterowników i planach AMD, nikt też na pewno nie ośmieli się krytykować ich wydajności. Patrząc na stosunek cena/wydajność, osobiście też na pewno kupiłbym AMD, gdyby tylko dało się dzięki niej pracować. Ale nie da się, w co najmniej jednym, bardzo popularnym programie, którego używam i tak się przypadkiem składa, że autor wątku też ;) Skupmy się na praktyce, nie teorii, być może za kilka lat viewporty będą opracowane pod wizję AMD. Póki co niestety nie są. Do dziś wspominam porażkę w pracy, w postaci kupna karty dwuprocesorowej (bodaj GeForce GTX 295) i wielkie rozczarowanie gdy okazało się, że jest wolniejsza niż GTX 280, także na bank jakoś słabo jest to napisane. Odnośnie fillrate: Oczywiście, masz rację i na pewno fillrate zależy między innymi od prędkości pamięci. Ja jednak poruszam ten temat od innej strony - nie wnikam w sposób, jakim mierzy się te wartości, a co z nich wynika. A wynika prosta zależność: Im wyższy fillrate, tym wyższa wydajność viewportu wyświetlającego prostą geometrię. Tabelka zaś bardzo ładnie pokazuje, jakie są wartości dla poszczególnych kart i rzeczywiście się to bardzo zgadza (+/- 5% rzecz jasna). Po zmianie z GT 8800 (Fillrate 10.4) na GTX 570 (Fillrate 30) ilość klatek podskoczyła trzykrotnie, po kolejnej zmianie na GTX 970 (Fillrate 58.8) ilość klatek wzrosła niecałe 2x. (Nie wiem jak się ma to do 8800, bo 8800 i 570 pracowała pod starszym cpu, a zmiana 570 na 970 odbyła się pod nowszym, lecz względne różnice się zgadzają). Więc myślę, że jest to doskonały przelicznik, a w jaki sposób liczony, to już inna sprawa. Test Cinebech - te wyniki myślę, że można sobie odpuścić. W ustawieniach karty możesz ustawić różną jakość, choćby filtrowanie tekstur czy antyaliasing, w zależności od ustawień na danym komputerze ilość klatek diametralnie się zmienia.