SWRSC

ok, w updatach NEXTa były dwie kluczowe zmiany w proxy. Spróbuj debugować kolejno modele proxy tak jak wyżej opisałem. Jak znajdziesz wadliwą serię to może wygenerowanie go na nowo pomoże. Sprzęt, tekstury - to raczej wszystko ok.

Hej, cieszę się, że mamy już jakiś trop 🙂 Jeśli to proxy to może być problem również z RAM komputera (w sensie jego ilości) i przepustowością pamięci. Ile masz go na pokładzie? Dysk to SSD? Proponuję sprawdzić, czy podczas tego długiego liczenia LC w drugiej i kolejnych klatkach dysk twardy mieli coś - Task manager. Generalnie jego użycie powinno iść na 100% przez pierwsze sekundy liczenia LC, a później już niemalże na 0%. Jeśli dysk mieli na 100% przez cały okres liczenia LC to jest problem z bitmap pager lub z niewystarczającą ilością RAM w komputerze. No albo jakaś wolna konfiguracja, której bardzo wolno zajmuje przerzucenie 50GB sceny do RAM, ale to raczej nie w tym przypadku. Jeszcze jedna sprawa - Twoje największe tekstury w scenie jaką mają rozdzielczość? I druga - te proxy masz utworzone na obecnej wersji vRay czy pochodzą ze starszych scen/starszej wersji vRay? Jeśli chcesz też debugować proxy - zacznij od tych najcięższych (rozmiar pliku proxy). Kolejno rób hide ze sceny zaczynając właśnie od tych ciężkich.

Rozumiem, że liczysz lokalnie, bez backburnera? Kilka propozycji, które przetestuj osobno wg poniższej kolejności: 1. W Task manager zmniejsz priorytet dla 3dsmax na "poniżej normalnego" - to u nas rozwiązywało kilka problemów z długim zapisem klatek i ogólna responsywnością systemu. Generalnie zawsze to robimy, polecam. 2. Sprawdź czy na pewno masz wyłączony bitmap pager (w zależnie od wersji maxa ta opcja będzie dostępna z poziomu UI lub z poziomu max scripu - znajdziesz w sieci komendę wyłączającą bitmap pager). Może jakimś cudem się włączył. 3. Wyłącz globalnie displacement, nawet jak jesteś przekonany, że go nie wstawiałeś w scenie (vRay > global switches); 4. Ten punkt łączy się z trzecim. Więc jak trzeci nie pomógł, to tutaj również wyłącz displacement oraz w zakładce vRay Settings > System ustaw Default geometry na static. Przy okazji upewnij się, że Dyn mem limit, mb masz ustawiony na wartość "0". 5. Czy korzystasz w scenie z jakiś pluginów do scattera geometrii? Jeśli tak to dla testu wyłącz cała warstwę z taką geometrią i odpal render. 5b. Wyłącz również wszystkie obiekty proxy. 6. Sprawdź liczenie przy wyłączonym Motion Blur Jak masz czas aby przetestować powyższe to podziel się spostrzeżeniami. Chętnie pomogę w razie dalszych problemów.

Wiesz co, na początku też miałem podobne przemyślenia, ale ostatecznie to ta optymalizacja jest naprawdę świetna. U nas wyeliminowało to praktycznie wszystkie problemy z GI i vRay stał się w końcu silnikiem bezproblemowym jeśli chodzi o liczenie animacji. "Przetestuję dla pewności. Jeśli to to będzie powodowało problem z lightcache, to znaczy, że trzeba będzie liczyć na full evaluation lights, prawda?" Nie rezygnowałbym z adaptive, bo to naprawdę niezły boost jeśli chodzi o czasy renderingu. Jeśli okaże się, że przy zaproponowanym teście LC liczy się poprawnie to szukałbym przyczyny w scenie, która stwarza problemy. vRay sam z siebie nie powinien generować takich wzrostów czasu liczenia LC z klatki na klatkę - problem leży gdzieś indziej (np w geometrii, która zmienia liczbę swoich poligonów z klatki na klatkę). Możesz opisać dokładniej co liczysz? Może jakieś screeny/podgląd na to co się dzieje w animacji?

1. Czy jest to NEXT najaktualniejszy? 2. Odpal tak dla testu jakąkolwiek scenę (najlepiej nową), gdzie nic się nie rusza (ani obiekty, ani kamera), ale licz to jako "animację" na kilka klatek (LC w mode "single frame" + bruteforce). Sprawdź czy ten efekt również występuje. vRay od nie pamiętam dokładnie której wersji wprowadził do LC algorytmy wspomagające adaptive lights. W zależności od tego co się dzieje w scenie, LC może liczyć szybciej lub wolniej. Dlatego przetestuj kompa na statycznej scenie, gdzie nic się nie zmienia. Naprowadzi Cię to nieco bliżej rozwiązania problemu.

ok, dzięki za sprawdzenie, szukam dalej...

no dobra, wracam do tematu. Jednak problem istnieje nadal i zaczyna się nasilać. Otóż stacja na 2xE5 2696 v4 obecnie liczy wolniej niż pojedynczy 7900x czy 9900K i prawie tak samo jak stary 6800K co już jest grubą przesadą. Ustaliliśmy, że wartości turbo boost są takie jak powinny być. Ktoś ma pomysły co powinienem sprawdzić? @matszklar może pomoże, to stacja od Was. Spotkaliście się z czymś takim? Będę wdzięczny za wszelkie sugestie. ----------------- Edit: Nie jest dziwne, że Backburner monitor pokazuje liczbę CPUs przy tych Xeonach jako "32"? (tam jest 88 rdzeni razem z HT) Reszta procesorów jak 7900x, 9900k pokazuje prawidłową liczbę. Task manager na xeonach pokazuje użycie wszystkich 88 wątków na 100% podczas liczenia.

ok, chyba jednak fałszywy alarm. Jest tak jak mówicie. Jeszcze raz dokładnie posprawdzałem czasy liczenia na różnych scenach. Tylko przy niektórych, bardzo specyficznych Xeony liczyły wolniej. Najczęściej tam, gdzie na jednym buckecie jest jest masa różnych rzeczy do przesamplowania (GI+transparentnosć+refl gloss+dof+mb) . W takim przypadku czasy równały się z prockami o mniejszej liczbie rdzeni a ich mocniejszą mocą. We wszystkich pozostałych przypadkach - liczy tak jak powinno.

Hej, Czy jest w stanie ktoś wyjaśnić mi dlaczego (nie wiem od kiedy) Intele nie rozwijają pełnej prędkości w trybie Turbo Boost? Przykładowo przy renderowaniu E5 2696 v4 rozpędza się tylko do 2.6Ghz, a specyfikacja mówi o 3.6Ghz Problem zauważyłem, w momencie kiedy rendernod na 2xE5 2696v4 niemalże zrównał się czasami na klatkę z pojedynczym i9-7900x. Z reguły był prawie 2x szybszy. Badając sprawę zauważyłem, że każdy Intel u nas nie osiąga pełnego Turbo Boost. Tym sposobem mocne, wielordzeniowe stacje (o słabym pojedynczym rdzeniu) zrównały się swoja wydajnością do stacji z procesorami o mocnych rdzeniach w mniejszej ich liczbie. Wyeliminowałem temperatury czy też problem wewnątrz scen 3ds max. Dzieje się to niezależnie od softu/silnika renderującego oraz również przy renderowaniu przysłowiowego czajnika maxa) Ktoś kumaty może to jakoś konstruktywnie skomentować? Dzięki!

Hej, dawno mnie tu nie było. Chciałbym pochwalić się nasza ostatnią realizacją - Animacja 3D systemu domu inteligentnego. Przyjemny projekt, w którym mieliśmy sporo wolnej ręki. Jesteśmy świadomi kilku mankamentów, jak np nie do końca udane wklejki ze stocków, ale budżet realizacyjny nie pozwolił na nakręcenie czegoś we własnym zakresie pod ten konkretny projekt. Niemniej jednak z efektu końcowego jesteśmy bardzo zadowoleni, a praca przy tym zleceniu należała do ogromnej satysfakcji! Renderowane tradycyjnie jak to u nas na vRay. Pozdrawiam, SWRSC

Wyczyść asset tracking (strip path na teksturach), problem zniknie.

jeśli to vRay 1.x to odszumisz to jedynie za pomocą silnika AA (wysokie max w DMC i niski color threshold) jeśli to vRay 2.x to włącz sub pixel mapping, możesz sprawdzic clamp output, ale też dosampluj światła i materiały. jeśli to vRay 3.x to zwiększa wartość min shading rate, włącz sub-pixel mapping + najprawdopodobniejsza przyczyna to kosmiczna intensywność świateł w tych lampach w stosunku do reszty sceny.

skalpel3d: Niedługo rozpisałbym program takiego szkolenia. Kierowałbym je do osób, które chciałby by udoskonalić swoją wiedzę o silniku, co przełoży się na efektywniejszą pracę. Główne założenia to: - najważniejsze: szkolenie nie byłoby przeprowadzane w oparciu o "warunki idealne", z jakimi mamy do czynienia na większości oferowanych szkoleń. Stawiam na wiedzę praktyczną w oparciu o konkretne projekty/zlecenia nad jakimi pracujemy w luminance studio. Zawsze miałem zdanie, że szkolenia, które uczą np. "Jak zrobić wizualizację wnętrza w vRay" (np na podstawie rysunku CAD w .dwg), które prowadzą krok po kroku co i gdzie nacisnąć niewiele dają - uczestnik potrafi zrobić dobrze tylko tą jedną scenę, na której się uczył. Rysunek w .dwg dostanie idealny, bo przygotowany na potrzeby szkolenia, a wystarczy jak na pierwszym komercyjnym zleceniu otrzyma .dwg wadliwe, które źle importuje się do maxa i już taka osoba leży. Chciałbym nauczyć myślenia - tłumaczyć dlaczego coś się dzieje, jak panować nad konkretną funkcją, a nie prowadzić za rączkę w stylu "kliknij tu". Wszystko przełoży się na: - efektywniejszą pracę przy silniku, czyli mniej błądzenia; - krótsze czasy liczenia przy zachowaniu jakości; - efektywne zarządzanie sceną, które przekłada się na szybsza pracę; - eliminowanie problemów związanych z renderingiem i pracą nad projektem; Chciałbym teraz przekonać się jakie są preferencje i zapotrzebowanie. Dzięki za opinię!

Hej, Jako właściciel firmy luminance studo (wizualizacje, animacje) mam możliwość zorganizowania stacjonarnych szkoleń z vRay na poziomie zaawansowanym, czyli: - omówienie każdej z zakładek i klarowne objaśnienie najważniejszych funkcji, które się tam znajdują; - omówienie silników AA i dokładne przykłady przypadków zastosowań; - dokładne omówienie silników GI, wyjaśnienie ich zasad działania; - dokładne omówienie kwestii samplingów; - optymalizacja czasu renderingu - nauka radzenia sobie z rozwiązywaniem problemów renderingu. Coś w tym stylu. Po takim kursie, zdobywacie wiedzę typowo techniczną, która pozwala na dużo sprawniejszą pracę z silnikiem vRay, niezależnie od tego przy jakim projekcie będziecie pracować (wizualizacja, animacja, motion graphic etc.) Nie byłaby to sucha teoria na postawie tzw. "Warunków idealnych" z jakimi spotykamy się w typowych materiałach szkoleniowych specjalnie stworzonych na potrzeby samego szkolenia, tylko wiedza wykładana w oparciu o projekty/problemy z jakimi mieliśmy do czynienia w naszej firmie. Czy jest jakiekolwiek zapotrzebowanie na tego typu stacjonarne szkolenia? Dodałem również ankietę z kilkoma opcjami dotyczącymi innego rodzaju szkoleń, będę wdzięczny za głosy, które pomogą w podjęciu odpowiedniej decyzji. Dzięki! SWRSC

zwiększ jakość AA (Antyaliasing).

ok, to jeszcze dla testu sprawdź BF+BF. Jeżeli problem zniknie to winowajcą jest LighCache. Wtedy zmiana jego aprametrów może pomóc (size/interpolacja/retrace itd) LC ogólnie lubi być kapryśne.

sprawdź czy masz wszystkie materiały vrayowe na obiektach, najczęściej tak świeci obiekt z nienadanym w ogóle materiałem.

Dobra Panowie, ogromne dzięki za pomoc! No to teraz poszukiwania odpowiedniej, uniwersalnej obudowy. Jak coś znajdę to na pewno przezd zakupem wrzucę tutaj do opinii. @juri36: To jest genialne :D gratulacje! Dziękuję za propozycję, ale u nas w grę wchodzi wyłącznie szafa rack.

@Vandam: dzięki za pomoc. Czytałem, że w 2U i wyżej wchodzą już zasilacze ATX, tylko trzeba pamiętać o tym, aby miały wentylator z odpowiedniej strony. Na procesor wtedy też pasuje zwykły wentylator. Zgadza się? Cenne info o tych płytach i obudowach - bardzo Ci dziękuję, zwrócę na to uwagę. @materalia: W grę wchodzi wyłącznie rack.

Czołem forumowicze, potrzebuje pomocy w kwestii złożenia zestawu komputerow do szafy rack (rendernody), takie oto pytanka: Szafa: - Doczytałem, że drzwi mają być perforowane dla lepszej wentylacji. Czy o czymś jeszcze powinienem wiedzieć budując mini renderafrmę? Myśląc o przyszłej rozbudowie, będziemy brali wysoką szafę stojącą. Komputery Rack: 1. Czy zwykły komputer pc mogę przełożyć do obudowy rack? Z tego co wyczytałem to nie ma problemu, ale nie znam się, dlatego proszę o opinię :) To tylko obudowa, a typ bebechów się nie zmienia (rodzaj płyty głównej, procesory), są dokładnie takie same jak zwykłej obudowie Tower? Planujemy upychać tam zestawy oparte na i7, 32-64gb ram w cenie 6-8k/zestaw (czy to jest realne?). Przyszłościowo pewnie też stacje GPU. 2. Widziałem różne obudowy (1U, 2U, 3U, 4U), wiem, że to określenie wysokości obudowy. Zakładając że: - chcę złożyć zestaw rendernode na rack bez karty graficznej (Procesory Intel i7): jaka wysokość obudowy będzie najlepsza? - chcę złożyć zestaw rendernode GPU: jaka wysokość obudowy będzie najlepsza? Ogromne dzięki za pomoc, pozdrawiam!

Tym najlepszym jest help GrowFXa - dokładnie opisana każda funkcja wraz z przykładami. Po przerobieniu odpalasz refkę drzewa i spokojnie jesteś w stanie wydziargać.

Zainstalowaliśmy 3.30.05, faktycznie poprawili ten bug z szarpaniem krawędzi na Adaptive AA, teraz wszystko jest git.

obecnie 3.30.03, mam nadzieję, że w tych nowszych to poprawili. Jest szansa, ze będziemy mogli zaktualizować w przyszłym tygodniu.

Problemów ze starymi scenami nie mamy - liczą się szybciej i ładniej. Jedyny problem jaki mamy czasami z 3.3 to silnik AA Adaptive - czasem, w niektórych scenach strzępi krawędzie mimo zmiany ustawień na wyższe i wyższe. Chyba jakiś bug, nie udało mi się zlokalizować przyczyny.

a liczysz w identycznym trybie zarządzania subdivsami jak przy 3.2? (3.3 ma automatyczne dobieranie ilości sampli/subdivsów/aa, domyślnie jest to opcja włączona) Global DMC: Use local subdivs. U nas generalnie 3.3 bardzo przyśpieszył liczenie, ale przy każdej scenie trzeba trochę poszperać w setach. Domyślne automatyczne zarządzanie subdivsami jest ok, ale jeszcze więcej można wyciągnąć starymi metodami (jak w 3.2 i niżej). Pozdrawiam