Blender - NEWS oraz dyskusje

[Monio]

Fix dodający obsługę nowego shader model który jest w tytanie i tesli został dodany do blendera dopiero 2 dni temu a build którego używali do tych testów ma 2 tygodnie i hulał jeszcze na starszej wersji SM. Dlatego testy trzeba będzie powtórzyć na świeżym buildzie. Ja patrząc na ilość i taktowanie rdzeni oraz masakryczną cenę tej karty spodziewałem się przynajmniej 3 krotnej wydajności gtx480 a nie +30%...

 

Poczekam na nowe testy ale na razie wygląda mi to na hiper-przecenioną zabawkę dla onanistów i nic poza tym.

[legomir]

Mówię tak samo było z Teslami w generacji przed i po Keplerze. Dopiero po pół roku otrzymano satysfakcjonującą wydajność

[Monio]

Czyli biorac pod uwagę moce przerobowe teamu cycles ta karta będzie używalna jak nvidia będzie zaczynała reklamować serie 800. ;) Poczekam na testy na najnowszym buildze ale już jestem prawie przekonany że w takim razie kupuje dwa gtx580, najpierw jeden a za parę miechów drugi. Kamień z serca. ;)

[Skoti]

Fix dodający obsługę nowego shader model który jest w tytanie i tesli został dodany do blendera dopiero 2 dni temu a build którego używali do tych testów ma 2 tygodnie i hulał jeszcze na starszej wersji SM.

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.

 

Śmiech na sali. Magiczne 2688 rdzeni titana daje wydajność o całą 1/3 większą niż 480 wolniejszych rdzeni trzyletniego gtx480. Architektura kepler to milowy krok w temacie GPGPU... krok wstecz oczywiście.

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.

Edytowane 23 Luty 2013 przez Skoti

[Monio]

To mnie trochę uspokoiłeś. Mówiłem o tym btw: http://www.miikahweb.com/en/blender/svn-logs/commit/54710

Zanim wykorzystają rzeczy o których piszesz pewnie miną wieki. Na razie żaden developer nie będzie sobie zaprzątał głowy bajerami z grafiki za tysiąc dolców. Do tego czasu pewnie zjaram te dwa gtx580. ;)

[Skoti]

To mnie trochę uspokoiłeś. Mówiłem o tym btw: http://www.miikahweb.com/en/blender/svn-logs/commit/54710

Zanim wykorzystają rzeczy o których piszesz pewnie miną wieki. Na razie żaden developer nie będzie sobie zaprzątał głowy bajerami z grafiki za tysiąc dolców. Do tego czasu pewnie zjaram te dwa gtx580. ;)

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).

[Creator]

Widzę że fajna rozmowa się tu rozwinęła :) Pozwólcie że wrzucę coś z innej beczki. Zakładamy że mam kasę na Titana. Warto w niego zainwestować czy lepiej kupić coś słabszego za połowę ceny ale np za rok wymienić na nowszą wersję? Jakie jest wasze zdanie?

Moje zakupy zawsze kończyły się na numerach z 60 w końcówce (460 660) Nigdy nie miałem odniesienia jak to jest np z 480/580 po czasie. Jest znaczna różnica ? Np 460 benchmarkową scenę w Octane liczy 15 minut, 660Ti liczy 11 minut, więc nie jest to jakiś hiper skok. Wiadomo 4 minuty robią różnicę, ale... Zadowalającym faktem jest to, że Octane może liczyć na obu kartach (jak każdy soft na CUDA, w tym blender), co zmniejsza czas oczekiwania do 6 minut.

Wracając do myśli przewodniej. Warto kupić Titana, czy może lepiej kupić 690? Chodzi mi głownie o liczenie na CUDA.

[Monio]

Na chwile obecną patrząc na price/performance Titan nie opłaca się zupełnie totalnie. Jak Skoti mówi, dostosują kod cyclesa, karty potanieją to będzie się można zastanawiać.

GTX690 to również średni biznes imho. To są 2 sklejone GTX680 tylko o trochę niższym taktowaniu z uwagi na wydalanie ciepła. Nie jestem pewny na bank ale te 4 giga ramu też jest dzielone równo na każdy procesor czyli nadal masz tylko 2 giga na scene. W temacie renderingu gpu dostajesz troszkę mniej niż zestaw 2x GTX680. Dodajmy że GTX680 działa z cyclesem na podobnym poziomie co GTX580.

[mallow]

Po obejrzeniu tego filmu na cg cookie:

bardzo mnie zainteresowało dyntopo (o którym wcześniej wiele nie czytałem),

 

Mam jednak pytanie - jak potem teksturować te rzeźby zrobione z dyntopo? Bo dostajemy w efekcie skomplikowany model highpoly bez wersji w mniejszej "rozdzielczości" jak z użyciem multires i zwykłego sculpta. Czy jedyną metodą na rozsądne rozłożenie UV jest zrobienie najpierw retopo tego modelu do mniej szczegółowej wersji, wypalenie normal mapy i teksturowanie tej mniej szczegółowej wersji czy jest może jakaś metoda, żeby ten proces uprościć?

[Monio]

No właśnie na razie nie ma. Podchodziłem do tematu parę razy i ręczne rozkładanie UV na takich modelach to jest koszmar, nie przez skomplikowanie tylko po prostu wydajność. Wszystko trzeba robić po kawałeczku i czekać wieki. Największy problem to samo wejście do editmode, przez vievport samo wybranie werta ciągnie się wieki. Smart unwrap po prostu nie działa bo szatkuje częśc modelu na kilka dużych wysp a resztę rozwala na malutkie wysepki po parę trisów. Nie da się na tym malować bo na łączeniach mikro wysepek robią się artefakty i wydajność jest beznadziejna. Obstawiam że przez te mikrowysepki blender musi robić n razy więcej transformacji dla każdego pociągnięcia pędzlem.

 

Teoretycznie jak chcesz mieć szybkie efekty to na razie jedyna opcja to vertex paint. Jednak te blenderowe narzędzia do niego niestety ssą pałkę według mnie.

 

Od 4:20

 

BTW. Jakiś czas temu bawiąc się dyntopo wpadłem na pomysł jak rozwiązać problem unwrapu gęstych trisowych modeli. Chce to zpisać i wrzucić na BA ale oczywiście czas na udokumentowanie tego znaleźć jest trudno. Prawdopodobnie bałoby się to załatwić jako pythonowy addon. Kwestia jest taka czy do opcji editmode da się dostać bez wchodzenia w niego. Tego nie wiem.

Teraz tego dokładnie nie opisze ale możesz to sobie zasymulować tak jak pisze niżej i powinieneś załapać.

 

1. Zaznacz verta > grow selection X razy > selekcja faceów > zapisanie vertexgrupy A > select boundary loop > mark seam > zapisanie vertexgrupy B > wybranie vertex grupy A > zwykły Unwrap > Hide.

2. Wybranie jakiegoś* verta z vertexgrupy B > punkt 1 i tak w pętli aż do momentu jak cały model będzie Hide.

3. Pack islands... Done

*Ten vert powinien być na styku 2 ostatnich ukrytych grup.

 

Wszystko robione po kawałku z uwagi na wydajność. Mi jeszcze nie udało się od tak rozłożyć całego modelu który miał np pół miliona poly. Blender liczył wieli albo wywalał się po kilkunastu sekundach. Przy tej metodzie na raz wykonywana jest tylko mała część obliczeń które idą sprawnie. Największy problem to Pack Islands na końcu.

Oczywiście to jest tylko taki ogólny schemat jakby to miało działać, nawet bez testowania można sobie wyobrazić jakie będą problemy. Czyli strech wysepek albo co stanie się jak zaznaczona wyspa będzie rurką. O ile da się dojść pythonem do tych danych które odpowiadają za obliczanie strecza wysepki to bardzo łatwo można ten problem rozwiązać przez coś ala prościutki pathfinding, robimy seama gdzie trzeba i ponownie unwrap tego kawałeczka.

Nadal jednak powraca sprawa Pack islands. Przynajmniej nie zacina kompa ale nadal trwa wieki. Nie wiem czy python by na to pozwolił ale można obliczyć powierzchnie wyspy i zrobić z niej proxy ngona z convex hull, te ngony rozłożyć na layoucie Packiem i przenieść ich informacje o zmianie skali i rotacji na już te normalne wysepki z trisów.

[Creator]

Ja bym szedł w Retopologie. Jest schludniej i masz porządną siatkę, którą łatwiej dalej przetworzyć.

Jest opcja nr 2 którą stosuję w 3D Coat czasami. Robisz auto UV z tej potriangulowanej siatki i bakeujesz na to. Śmierdzi to amatorszczyzną, ale na modelach statycznych czasem przechodzi.

 

Edit:

Najlepiej na duplikat wcześniej walnąć Decimate'a i na nim rozłożyć UV z automatu i na niego bakeować :)

Edytowane 24 Luty 2013 przez Creator

[mallow]

Monio, dzięki za odpowiedź. Ja równoległe znalazłem jeszcze inny ciekawy film w tym temacie. Przypadkowo tego samego autora :-)

 

Jak widać bardzo szybko można ze skomplikowanego modelu zrobić model o mniejszej liczbie wierzchołków przy użyciu modyfikatorów remesh, multires i shrinkwrap. Potem na tym lżejszym modelu można by wypalić normal mapę i zrobić UVkę.

 

Próbowałeś też taką metodą? Jeśli tak, to jak się to sprawdzało? Mi w sumie nie zależy na tym, żeby ten teksturowany model miał na końcu dużo wierzchołków. W sumie lepiej żeby był lżejszy.

 

Chodzi mi ogólnie o wypracowanie możliwie najlepszego workflow, w którym mógł bym:

1. Sculptować z dyntopo.

2. Zamienić ten model na lżejszą wersję bez wyraźnej straty jakości.

3. Rozłożyć UV mapę i oteksturować.

 

Przy czym fajnie by było mieć możliwość po etapie teksturowania zrobić poprawki modelu w sculpcie i nie teksturować od zera, ale ewentualnie wprowadzać jakieś tylko poprawki w UV i seamach. Czy tak w ogóle się da z dyntopo czy jednak zwykły sculpt będzie lepszy?

 

@Creator: Dzięki, porównam też z Twoją metodą.

[Monio]

Creator - Wooot? Dziwne tezy ostatnio wyciągasz. Przecież teksturowanie to nie jest tylko coś co dotyczy gotowych modeli lowpoly. Można przecież teksturować hipoly a potem robisz projekcje i bejki. Nawet nie tyle co można to jest to przecież już od lat standardowy workflow w gamearcie.

 

Mallow- Próbowałem bo coś takiego jest u mnie na standardzie w workflow zbrushowym. Jednak z blenderze nie jest już tak pięknie. Przy bardziej złożonych modelach robienie tej projekcji jest strasznie upierdliwe i zajmuje z 10 razy więcej czasu niż to samo w zecie. ;) Przy małych detalach, uszach czy palcach ten Remesh czasem robi takie cuda że nie da się tego obejść bez mozolnych ręcznych poprawek. Inna sprawa gdyby się miało zrobioną dobrą topologie i wtedy robiło projekcje. Czasem mi się zdarzało że musiałem wywalić całego multiresa bo dopiero przy projekcji na którymś levelu mogłem zobaczyć że siatka jest sklejona i nie nadaje się do przeniesienia detalu.

 

Żeby coś sensownego wyszło z projekcji to trzeba je robić level po levelu i dociągać siatkę gdzie jej nie łapie lub łapie krzywo. I tutaj pojawia się problem nie obsługiwania Shrinkwrapa w sculptmode, przed każdą poprawką trzeba go zatwierdzać i potem ustawiać na nowo. Brrr.

Edytowane 24 Luty 2013 przez Monio

[Creator]

Tak wiem, ale blender, jak sam zauważyłeś, nie daje sobie rady z meshem z 2 mln faceów w Edit mode. Dlatego jak zrobisz sobie duplikat który będzie miał mniej poly (np jak mówiłem Decimatem) i walniesz na nim mapowanie, to możesz sobie wybejkować wszystko co chcesz i masz to na mniejszym modelu który wciągasz do dowolnego softu, a jak chcesz zagęścić to masz displacement itd itp. Gorzej jak zaczną wyłazić lipne seamy. Jak będe miał chwilę to podeślę co mam na myśli.

[Creator]

Ok dorzucam screena:

 

Walę Decimate z HP i robię Smart UV Projection. Na taki modelik mogę bakeować normalmapę/Displace itp. Można też malować po nim i Blendek nie kwiczy :) Mimo wszystko i tak polecam zrobić retopo.

[Skoti]

@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ś).

[mallow]

Dzięki za odpowiedzi. Wydaje mi się, że wszyscy macie rację :-) W zależności od konkretnej sytuacji oczywiście.

 

@Skoti: Jeśli docelowo ma powstać model z poprawną siatką (np. jako asset do gier lub przeznaczony do animacji), to chyba rzeczywiście nie obejdzie się bez robienia tak jak piszesz.

 

@Creator: Na Twoim przykładzie widać z kolei, że o ile siatka idealna nie jest to ten sposób sprawdzi się idealnie tam, gdzie wynikiem ma być jedynie ilustracja. Sporo automatyki, powinno być dużo szybciej niż robienie retopo.

 

Teraz tylko muszę trochę przećwiczyć wszystkie te sposoby.

[Creator]

Decimate w blenderze robi tragiczną siatkę i artefaktów sporo (co zresztą pokazałeś).

Wiem, ale kolega mallow szukał szybkiej metody, szybszej nie znam :) Artefakty związane z Shadeingiem (głównie w szczelinach, rowkach i na ostrych krawędziach) naprawia normalmapa. Jak nachodzą na siebie trisy, to można w SculptMode Smoothem lekko wygładzić, albo jakiegoś relaxa dać, opcji jest kilka. Wiadomo jest to metoda partyzancka ale działa :D Zamiast Decimate można sprawdzić jak zadziała modyfikator Remesh, ale nie testowałem nigdy.

 

@mallow

Wiadomo, jak dasz taką siatkę animatorowi to gwarantowane że wpadnie do Ciebie w nocy z piłą łańcuchową :D

[Monio]

teselacja siatki gdzie malujesz obecnie niszczy UV

Nie przeskoczysz. Nie potrafię sobie wyobrazić rozwiązania które w locie by ci rozkładało UV nowo dodanej geometri i dodatkowo nie psuło już istniejącej. To już by zahaczało o AI a nie proste algorytmy. Prędzej chyba zrezygnujemy z całego konceptu UV i przejdziemy na rozwiązania ala PTEX. Jak dojdzie kiedyś do takiego momentu, a dojdzie na bank, to już prawie żaden grafik 3d nie będzie pamiętał że istniało coś takiego jak mapowanie i UV. ;)

 

 

Tak w międzyczasie. Looking for attention:

 

Cycles-proposal-Divided-render-resolution-option-in-viewport-rendering

 

Popchnijcie ten wątek jeśli uważacie ten pomysł za użyteczny. Tak na marginesie nie znoszę pomysłów Harley'a gdy mówi o UI. :P

 

 

-----------------------

 

Hi all,

Here are the notes of today's session in irc.freenode.net #blendercoders

 

1) 2.66 release review

- Some showstoppers have been found already:

- A change in how textures use alpha (option moved to Image block), required a do-version patch which crashes for library linking in cases.

- Compositor: File Output node missed socket input menu

- Dynatopo crash in some cases.

- We will check next sunday again, then do apply fixes on the release branch and call for an 'a' build...

- Important note: let's not do cleanups of code now please, except when approved by all involved module owners!

 

2) Targets for 2.67

- Freestyle, no real news, but final review can start soon.

- Sergey Sharybin worked on (motion tracking) Bundle Adjustment, should be in svn soon.

- Proposal for release planning:

March 10 bcon2 (= targets are defined)

March 31 bcon3 (= targets are in svn)

April 14 bcon4 (= only fixes, test builds and/or RC)

April 21 bcon5 (= release imminent)

 

3) Other projects

- Antonis Riakiotakis works on subsurf drawing speed improvement.

- Ton Roosendaal suggested to work on replacing GL_SELECT (OpenGL select feature, used for object mode). Too many problems are arising with it now. Could be simply replaced with using back-buffer color codes. Alternative is to do brute-force raycast tests. Might even work surprisingly fast.

 

Thanks,

-Ton-

 

To ostatnie bardzo dobra rzecz. Zaznaczanie włosów albo gęstych modeli to czasem udręka.

Edytowane 24 Luty 2013 przez Monio

[Skoti]

Nie przeskoczysz. Nie potrafię sobie wyobrazić rozwiązania które w locie by ci rozkładało UV nowo dodanej geometri i dodatkowo nie psuło już istniejącej. To już by zahaczało o AI a nie proste algorytmy. Prędzej chyba zrezygnujemy z całego konceptu UV i przejdziemy na rozwiązania ala PTEX. Jak dojdzie kiedyś do takiego momentu, a dojdzie na bank, to już prawie żaden grafik 3d nie będzie pamiętał że istniało coś takiego jak mapowanie i UV. ;)

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.

 

To ostatnie bardzo dobra rzecz. Zaznaczanie włosów albo gęstych modeli to czasem udręka.

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ł.

[Monio]

Ty mówisz o banalnej telestacji obiektów a nie rzeźbieniu za pomocą dynamic topology... To są inne rzeczy. Weź kulkę, odpal dyntopo i wyciągnij snakebrushem takie coś:

 

 

Jakim niby cudem podzielisz istniejące UV na modelu tak żeby tekstura kolosalnego rozciągnięcia w tych miejscach? Jak masz pomysł to od dzieła, zmienisz wtedy całą branże. lol.

[Skoti]

Ty mówisz o banalnej telestacji obiektów a nie rzeźbieniu za pomocą dynamic topology... To są inne rzeczy. Weź kulkę, odpal dyntopo i wyciągnij snakebrushem takie coś:

 

Jakim niby cudem podzielisz istniejące UV na modelu tak żeby tekstura kolosalnego rozciągnięcia w tych miejscach? Jak masz pomysł to od dzieła, zmienisz wtedy całą branże. lol.

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.

Edytowane 24 Luty 2013 przez Skoti

[mookie]

Skoti - czyli czysto teoretycznie byłoby możliwe stworzenie takiego dyntopo, które by "trzymało" UVałkę? Nie jest to jakieś przeraźliwie trudne zadanie?

[ikkiz]

jak by się zastanowić, to jak się ma siatkę ze szwami i z uvką i się porozcina jakieś edge, pododaje wierzchołki i.t.d. to z uvką nic się nei dzieje, szwy nie znikają. Nawet jak sie zrobi edge colapse to wszysko jest w porządku. Nie wiem dla czego w dyntopo jest to problem. oczywiście się bardzo bitmapa porozciąga, ale to się rozumie samo przez się.

 

Może tylko (albo aż) chodzi o wydajność

Edytowane 25 Luty 2013 przez ikkiz

[Monio]

Byłoby możliwe dyntopo które zachowuje UV tylko że po minucie roboty, czy to na dużych czy małych detalach, to UV nie nadawałoby się kompletnie do niczego. Super technologia po nic.

W tych przypadkach gdzie zagaszenie siatki nie będzie powodowało kosmicznych streczy blender nie psuje UV. Bez w odpalania dyntopo. Editomode > select all > Subdivide smooth. I to jest twoja teselacja Skoti.

 

Trzeba prosić żeby dopracowali narzędzia do vertexpaintu a nie po raz enty bawić się w abstrakcyjne teoretyzowanie.

[mookie]

Monio, wyluzuj; ja bym po prostu był naprawdę szczęśliwy, gdybym np. wymodelował sobie deskę, zunwrapował, porzeźbił nieco nadając jej jakieś rysy, pęknięcia, a potem wrócił do trybu edycji widząc zachowane szwy. Nie chodzi mi o zachowaniu seamów w przypadku, gdy zaczynamy od zuwrapowanego sześcianu, a kończymy na ludzkiej twarzy.

[Monio]

Deskę mówisz... Multires?

[ikkiz]

dało by się gdzieś zastosować, ale nie są to przypadki, w których wykorzystuje się główną zaletę dyntopo.

 

A propos zachowywania UV i szwów - widzieliście co z uvką robi unsubdivide? Tak się składa, że musiałem skorzystać w optymalizowaniu hipoly do animacji. Lowpoly się nie dało zrobić, bo terminatory bym dostał w cycles, a hipoly się układało dla każdej klatki 90 sekund, co podważało sens renderowania animacji wogóle. Trzeba było się pozbyćniektórych faceów zostawiąjąc inne gęsto. Unsubdivide mi się wydał świetnym rozwiązaniem, ale w końcu musiałem robić edge colapsy i usuwać loopy ręcznie

[Skoti]

Skoti - czyli czysto teoretycznie byłoby możliwe stworzenie takiego dyntopo, które by "trzymało" UVałkę? Nie jest to jakieś przeraźliwie trudne zadanie?

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.

 

W tych przypadkach gdzie zagaszenie siatki nie będzie powodowało kosmicznych streczy blender nie psuje UV. Bez w odpalania dyntopo. Editomode > select all > Subdivide smooth. I to jest twoja teselacja Skoti.

...

Deskę mówisz... Multires?

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).

Edytowane 26 Luty 2013 przez Skoti

[n-pigeon]

Kolejny ciekawy blender podcast, dużo o Cycles: http://blender-podcast.org/?p=498

[mallow]

Pewnie wszyscy znacie ten link:

http://builder.blender.org/download/

To codzienne buildy Blendera. Myślałem, że to jakiś automat to robi. Jeśli tak, to czemu buildy na Maca są tak opóźnione? Wiecie coś na ten temat?

[ikkiz]

@mallow

Chyba nie automat, zwłaszcza, że przy ostatnim wydaniu były jakieś problemy z kompilacją na maca.

Ty używasz Blendera na Macu? Jeśli tak, to jak ci działa? Bo u mnie najlepiej sprawdza się pod Linuksem. Mam prawie 2x więcej fps przy animacji w viewporcie niż ten sam plik, na tym samym komputerze przy win7. W renderze (cycles GPU), też minimalna różnica na korzyść Linuksa, ale już ledwo zauważalna, chyba tylko czas budowania sceny (BVH). Najlepiej widać różnice w prędkości włączania Blendera. pod Lin jeszcze nie zdąży dźwięk kliknięcia odbić się od ścian, a już blender gotowy do pracy.

[mallow]

(...) Ty używasz Blendera na Macu? Jeśli tak, to jak ci działa? Bo u mnie najlepiej sprawdza się pod Linuksem. (...)

 

Tak, mam MacBooka Pro z 2010 roku, chyba najsłabszy model to był. 13", z tą jedynie słabszą kartą graficzną NVIDIA GeForce 320M 256 MB. Mimo to Blender działa bardzo dobrze. Uruchamia się w niecałe 2 sekundy. Viewport chodzi bardzo szybko. Oczywiście jak jest sporo modeli w scenie i włączę widok Textured to nie jest płynnie, ale i tak modeluję przeważnie w Local View. I spokojnie też się ten komp sprawdza przy robieniu tetstowych renderów.

 

Natomiast do renderów z lepszą jakością używam komputera stacjonarnego z ubuntu. Ciężko mi to porównywać, bo tam mam inny sprzęt - 4-rdzeniowy procesor, inna karta graficzna. Raczej o to chodzi niż o system. Chociaż nie wiem, nie jestem informatykiem.

Na pewno renderuje się szybciej, ale czy viewport chodzi lepiej? No trochę więcej obiektów potrzeba, żeby zwolniło.

 

Ogólnie to nie zauważyłem jakichś wyraźnych spowolnień, które wymusiły by na mnie przeorganizowanie pracy. Pracuję głównie na Macu, a na ubuntu jedynie renderuję.

No i co mi się podoba bardzo w Blenderze od 2.5. Coraz lepiej Blender na Macu jest zintegrowany z systemem. Mówię tu np. o skrótach klawiszowych - zapis Cmd+S działa. Pamiętam jak kiedyś było to Ctrl+W, było dziwnie :-) I bardzo fajnie od ostatnich poprawek działa touchpad macbookowy z Blenderem. Były z tym problemu, przez rok nie mogli dojść przez co, ale niedawno Ton to naprawił i touchpad działa teraz idealnie. Oczywiście modeluje się wygodniej myszką, ale czasem poza biurem jak coś trzeba na szybko poprawić, np. podczas rozmowy u klienta to naprawdę jest to teraz wygodne.

[n-pigeon]

Automat robi te kompilacje. Jeśli możecie korzystajcie właśnie z tych buildów, ponieważ to oficjalne buildy testowe.

[mallow]

Automat robi te kompilacje. Jeśli możecie korzystajcie właśnie z tych buildów, ponieważ to oficjalne buildy testowe.

 

No właśnie chciałbym. Tylko jest jakieś spore opóźnienie jeśli chodzi o buildy na Maca.

[n-pigeon]

Tu masz akutalny status, http://builder.blender.org/builders

 

Wygląda na to że stacje macowe mają teraz błędy compilacji, maintainer scons dla mac powinien rozwiązać problem.

 

Jest też podany czas kiedy odpali nastepną kompilacje.

 

Edit:

 

To jednak nie jest wina zepsutego scons. Maszynka macowa jest odłączona od sieci z jakiegoś powodu:

http://builder.blender.org/buildslaves

 

Dlaczego, nie wiem, w takim razie musisz użyć wersji z GA.org albo samemu skompilować i sprawdzać czy mac znowu stoi.

Edytowane 28 Luty 2013 przez n-pigeon

[mallow]

Dzięki za linki. Fajnie, że widać kiedy będzie następny build.

 

Ja tego nowego builda potrzebowałem ze względu na błąd w 2.66 - w File Output node nie wyświetlają się Inputs w opcjach. Podobno już poprawione, ale nie ma builda na maca z tym. Na razie wróciłem do wydania RC 2.66, bo tam działało. Jak się nowe buildy nie pokażą, to poczekam chyba już na 2.66a i na razie jakoś dotrwam na tym RC.

[ikkiz]

Wracając jeszcze do os'ów, to na tym samym komputerze ta sama scena ma się tak:

 

linux

GPU 00:00:41

CPU 00:01:56

CPU' 00:01:39

 

winndows

GPU 00:00:44

CPU 00:02:37

CPU' 00:02:18

 

(HH:MM:SS) renderowałem z rozmiarem tiles 256x256, tylko CPU' renderowałem z mniejszym rozmiarem 32x32

 

Z tego wychodzi, że stosunek czasów Linux/windows to odpowiednio

GPU 0,93

CPU 0,74

CPU' 0,72

Przy renderowaniu na karcie (GTS 450) Różnica jest niewielka, pewnie wynika z czasu budowania sceny przed raytracingiem

ale przy renderowaniu na procesorze (AMD Phenom II X4 955) jest szybciej o 1/4 a to już dużo (strand rendering, OSL na razie tylko na CPU)

A jeszcze animacja we viewporcie prawie 2x szybciej

Nie zdawałem sobie sprawy, że różnica będzie tak wyraźna, więc zwlekałem z naprawieniem sobie tego linucha, ale teraz to już domyślne bootowanie mam na lin. Tak piszę, nie żeby się pochwalić, tylko może się komuś przyda info, jak można trochę czasu oszczędzić kosztem 8GB zajętego dysku.

[woyoooo]

ktos uzywa Blendera + Vraya? szukam kogos kogo bede mógł posmamować na GG. Aktualnie pracuje( dla zabawy) w nim :)

[mallow]

Z tego wychodzi, że stosunek czasów Linux/windows to odpowiednio

 

Już słyszałem wcześniej, że Blender jest szybszy na Linuxie niż na Windowsie. Szczegółów nie sprawdzałem, bo Windowsa nie używam już chyba 10 lat. Od 3 lat pracuję za to również na Macu i system makowski jest dla mnie dużo bardziej przystępny niż ubuntu. Lepiej przemyślany User Interface. Natomiast jak się ma wydajność linuxa do OSX? Nie wiem. Ciekawe jak by wyglądało porównanie jak by jeszcze do tego zestawienia doszedł OSX.

[ikkiz]

A można OSX zainstalować na tym samym PC co Windows i Linux? Wtedy by to było miarodajne, bo jak inny sprzęt, to inna sytuacja. W każdym razie po moim ponad rocznym niebycie w Linuksie (zepsułem, nie chciało mi się naprawiać) zdziwiłem się, że przesiadka jest tak bezproblemowa. Wszystko działa, aplikacje te same a działają szybciej.

[Idaho]

Witam

Tak jest to możliwe ale musi istnieć zgodność hardwerowa. Śledziłem ten temat przy okazji kompilacji gier na Appstore. W pierwszej kolejności trzeba mieć sprzęt kompatybilny z osx. Później podrzucę adres stronki która prowadzi zestawienie płyt i kart graficznych no i konfiguracji na których można zainstalować OSX. Następna sprawa to zakup samego OSX, do którejś wersji można było oddzielnie kupić w wersji fizycznej, w tej chwili tylko i wyłącznie poprzez internet. Myślę że na eBayu jeszcze by się dało. Nie bardzo pamiętam ale by wszystko było ok to chyba trzeba mieć jednak jeszcze maca, jakieś tam niuanse licencyjne. Jest to możliwe no i co najważniejsze działa. O jest http://www.tonymacx86.com/home.php

Pozdrawiam

Edytowane 1 Marzec 2013 przez Idaho

[mookie]

Miło mi napisać, iż Campbell odpisał na mój mail i zapowiedział usprawnienie Blendera o część wskazanych przeze mnie "ficzerów" (kilka stron wcześniej w tym wątku). Super sprawa!

[mandragora]

http://www.blendernation.com/2013/03/04/ubershader-material/ ubershader

[n-pigeon]

Raczej duży node group, nie ma normalizacji, przydatne to, ale mocno uproszczony setup.

Edytowane 5 Marzec 2013 przez n-pigeon

[mallow]

Jest już nowy Blender 2.66a:

http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.66a

[Monio]

 

Clipbrushe w blenderku. :) Przy sculpcie bardzo przydatna sprawa. Za jakiś tydzień ten addon będzie udostępniony dla wszystkich.

[Monio]

 

Laurka od Brechta. :D

W ciągu przyszłego tygodnia SSS powinien pojawić się w buildach.

[ikkiz]

nawet nie wiesz Monio jak często tu zaglądałem, żeby to przeczytać!

[n-pigeon]

a ja dalej bardziej wyczekuje ubershadera i dispa :D

 

ale i tak dzięki, ja wypadłem z obiegu na razie