Alibaba

Zrob cos takieg. Zapisz scene bedac w single wireframe, zamknij modo i otworz ponownie. W nic innego nie wchodzac odpal render view i zobacz czy jest lepiej. Stawiam ze problemem jest karta graficzna i wlasnie ilosc viewportow modo. Karty gamingowe nie za dobrze radza sobie z duza iloscia viewportow openGL w przeciwienstwie do quadro. Mialem okazje pracowac na quadro na modo i roznica jest wyrazna. Na gtx 780 mam dosc podobnie jak Ty przy 4k moze troche lepiej ale niewiele.

W modo tak, wszystko jest "jakims" viewportem:) Caly layout modo to siatka viewportow.

Jak w tytule. Support i sieci sprzedazy pozostaja bez zmian ponoc i sa dalej prowadzone przez Eyeon. Podobnie jak developing Fusion i GenerationAM. Notka prasowa Blackmagic https://www.blackmagicdesign.com/press/pressdetails?releaseID=61765&utm_source=Blackmagic+Acquires+eyeon+Software+Inc&utm_campaign=Blackmagic+Acquires+eyeon&utm_medium=email Komentarz z Redshark http://www.redsharknews.com/post/item/2015-blackmagic-s-purchase-of-eyeon-fusion-will-send-shockwaves-through-the-post-production-industry Plus drobne info o Fusion7 http://www.eyeonline.com/FusionVideo.html

Alez twierdze cos przeciwnego:) Ten zart ktory przytoczyles tak twierdzi:P

Utrafiles zarcikiem jak kula w plot. Proponuje dowiedziec sie jak karty wieloprocesorowe lub SLI wykorzystuja pamiec zanim rzucisz kolejny :P

A co dziala zle? Nie, zmodyfikuja stary. A co jest nie tak z interfacem? A od kiedy Fusion jest na linuxie pod WINE?:O Jedyna czescia fusiona dzialajaca pod wine jest obsluga GUI. Dzieki temu pluginy sa niezalezne od platformy. I nie, przepisanie tego gui by nie dzialal pod wine nie spowoduje ze fusion bedzie dzialal szybciej. Wine to nie emulator...

To nie jest niszwy soft, skad wam sie to wzielo? A juz porownywanie go do Blenda to kompletna porozka. Mati wykaz sie i oswiec mnie w czym Nuke jest lepszy. W paru rzeczach jest ale po tonie Twojego postu wnosze ze nie za bardzo wiesz jakich. Zaraz pewnie przeczytam ze max bije na glowe maye, SI czy Hudego bo jest popularniejszy:D

Nie upada i daleki jest od tego. A jak sledzisz promocje to regulanie co roku mozna go lyknac za 999$ a soft jest calkowicie porownywalny z Nuke.

Savoy nie bierz tego do siebie, ale jesli ktos potrzebuje 3 odbic i pelnego path tracking by uzyskac wymagany efekt to prawdopodobnie ma spore problemy z poprawnym oswietleniem sceny. Gros tego co widzisz w kinie lub chocby przerywnikach w grach jest oswietlana bez zadnego GI. Tam ekstrawagancja jest nawet uzycie swiatel obszarowych. Nie pisze tego by octane render w jakikolwiek sposob reklamowac bo puki co renderery oparte na gpu uwazam za straszny syf. Po czesci z powodow ktore juz podales ale glownie dlatego bo kombinowanie caly dzien jak podzielic troche bardziej skomplikowana scene by gpu renderer ja w ogole lyknal troche sie wg mnie kluci z definicja predkosci, o problemach z shaderami nie wspominajac...

Samarytian to UE3 na trzech 580tkach renderowane wiec bym sie nie zachwycal. Jesli idzie o sam silnik to jesli dojdzie porzadne oswietlenie RT bedzie rzadzil.

Osobiscie bardziej zal mi magazynu niz samej strony, a juz najmniej forum.

Mask option z render globals i mask option w camera properties to dokladnie to samo i dziala identycznie. Tyle tylko ze wnioskujac z tego co piszesz w lw11 wylecialo z jednego okienka. Jesli chcesz tej opcji uzyc globalnie to w camera mask option zaznacz Use Global. A dziala prosto. Na przykladzie: Jesli renderujesz 800x600 i chcesz miec kaszete 100px z dolu i z gory to w mask width i height wpisujesz 800 na 400 a w mask top wpisujesz 100. Tak czy siak, lepiej jest to robicw post.

Zalezy w sklad czego wchodza te triangle. W wariancie pierwszym dojdzie ci narzut z tytulu przesylania danych (nie samej operacji rysowania), w wariancie drugim narzut z racji tesselacji. I jesli mowimy o 5mln trisow skladajacych sie np na sciane to wariant pierwszy bedzie szybszy. Sytuacja moze sie zmienic jesli obiekt deformowany jest np koscmi, bo zamiast liczyc deformacje dla kazdego vertexa obiektu po tesselacji gpu liczy tylko deformacje dla obiektu bazowego. Ale bezposrednio nie ma zwiekszenia liczby generowanych poly dzieki tesselacji, tylko dzieki kolejnosci operacji deformacji i tesselacji. Zreszta ta sytuacja jest raczej rzadka bo na ogol chcesz uzyc tesselacji w polaczeniu z displacement map lub deformacja proceduralna ,wiec najpierw jest tesselacja potem deformacja.

Inside: Wszystko zalezy od tego o czym wlasciwie mowisz. Tego nie da sie traktowac hipotetycznie, za duza liczba wariantow. Daj jakis konkretny przyklad. Jesli chodzi o pamiec. Wezmy optymalna, niemozliwa do spelnienia sytuacje. Masz pamiec do ktorej dostep ma i gpu i cpu, i dziala ona z najwieksza znana przepustowoscia. Wroc...wezmy dla ulatwienia przepustowosc pamieci gtx680 ktora na pewno nie jest najwieksza ale znalazlem ja natychmiast, a troche szkoda mi czasu na szukanie dla Ciebie faktycznej najwiekszej przepustowosci. Ta wartosc wg Nvidii to 192 GB/s. Podziel to przez liczbe klatek (powiedzmy 50) a wyjdzie ci oszalamiajaca wartosc 4GB pamieci mozliwej do odczytania przez gpu na ramke. W optymalnej, niemozliwej do spelnienia w praktyce sytuacji. Te 4GB to oczywista bzdura, bo jest wiele sytuacji kiedy faktycznie mozesz rozszezac ilosc pamieci w nieskonczonosc i nadal miec z tego tytulu zysk predkosci, ale jesli idzie o teksture, to ona sie do nich nie zalicza. A ty chcesz miec 16gb w nowych konsolach. Dam glowe ze jak bedzie 6 lub 8, to zaden z deweloperow nawet nie pisnie.

inside: konsole nie maja problemow z iloscia poly tylko z wypelnianiem pixela. Dlatego wszystkie porty gier uzywaja identycznych modeli wzgledem wersji z PC. Roznica tkwi w prostszych szaderach, braku aniso i antialiasingu i gorszych teksturach. A tesselacja, wbrew temu co sugerujesz nie sluzy do zmniejszenia ilosci poly. Jest dokladnie odwrotnie:D Co do pamieci to drastyczne zwiekszenie jej ilosci nic nie da, bo na dzien dziesiejszy jest po prostu za wolna...