SYmek

Szkoda tylko, że miała jakby mieszane uczucia, jakby tak... gryzła się w język, żeby czegoś nie powiedzieć :)

ale, ale to muszą być Xeony... cena sklepowa cztero-rdzeniowca zaczyna się od 1300zł, a kończy gdzieś w okolicach 6.000zł... Jakby nie było, każdy Windows od XP w górę będzie działał dobrze.

Z czego domniemuję, że ten Kepler z 680, to nie Kepler?

To jest constant shading, czyli dokładnie to samo, co jak byś wziął alfę obiektu i pomnożył przez swój kolor.

dzieki, rzucilem to, bo sie okazalo, ze nie ma dla kogo :)

Dzięki ca mel za podpowiedź. Właśnie szukam takiego cacka i nie mogłem znaleźć swojego typu. Ukochane HP 8710w powoli się kończy i rozglądam się za następcą (ale jak ktoś poszukuje bardzo taniego laptopa do pracy w 3d, gorąco polecam, chodzą po 1500zł, a pracują bez żadnych problemów w H./M./N. pod Win i Lin. Poza raczej średnim wyświetlaczem nie mają właściwie wad ;) ). Mam tylko nadzieje, że to Vaio to nowa konstrukcja. Stare modele dużych laptopów od Sony miały koszmarną wadę konstrukcyjną, a mianowicie zawiasy zamontowane były tak, że przy szarpnięciach wyświetlacza łamały płytę główną. Znam trzech byłych właścicieli tych komputerów, którzy kilka razy wymieniali (na gwarancji) połamane płyty główne w 17+ calowych modelach...

Aha, rozumiem. Po File dajesz ConnectivitySOP a następnie PartitionSOP. W tym drugim w polu "Rule" wklepujesz na przykład grupa$CLASS i done. Masz grupy dla każdej części geometrii połączonej ze sobą. pozdr., skk. ps ConnectivitySOP sprawdza, które prymitywy są połączone ze sobą i dodaje atrybut "class", którego wartość jest stała dla połączonych prymitywów. PartitionSOP zajmuje się tworzeniem grup według wyrażenia z pola "Rule". Może na przykład użyć atrybutu (tak jak dzięki zmiennej $CLASS). Wszystkie punkty lub prymitywy, dla których wyrażenie zwraca tę samą wartość stworzą jedną grupę·

Nie rozumiem, masz przecież na VoronoiSOP zakładkę Groups, gdzie możesz je włączyć, a potem iterować po nich w ForEach, chodzi Ci o coś innego? (zwróć uwagę na pole "Group Mask" w ForEachSOP, musisz tam wpisać odpowiednia maskę, coś jak "piece*" na przykład). O ile mi wiadomo, muszą się znajdować wewnątrz. Houdini bardzo dosłownie traktuje obiektowość danych, jak coś jest w środku czegoś, to jest w środku, a nie tylko tak wygląda ;).

Tu są dwie sprawy: 1) $COSTAM to zmienna (w tym przypadku lokalna), która często, ale nie zawsze, odnosi się do atrybutu na geometrii o nazwie "costam". To jest konwencja, ale warto się jej trzymać. Niektóre zmienne są wbudowane, inne tworzy użytkownik przez tzw. "variable mapping" najczęściej w trakcie tworzenia samego atrybutu. To ważne, bo 90% zabaw w Houdinim polega na żonglowaniu atrybutami a swobodny dostęp do nich jest podstawową zaletą tego programu. Jakie atrybuty masz na geometrii i jakie mapowanie na zmienne zawsze możesz łatwo sprawdzić klikając środkowym przyciskiem na noda. 2) Podwójny podkreślnik to jakaś zupełnie nowa konwencja wprowadzona przez SESI, najprawdopodobniej na podobieństwo Pythona, gdzie zaznacza się tak atrybuty prywatne klasy, których nie należy dotykać. SESI nazwało tak atrybuty i zmienne, żeby nie było kolizji z czymś, co wymodzi (lub już wymodził) użytkownik. Znów, ja o tym nie wiedziałem, po prostu kliknąłem prawym przyciskiem i sprawdziłem, co w trawie piszczy. W tym przypadku atrybuty także miały "__" przez większość czasu, a dopiero na końcu zmienia się im nazwy na te podane na zewnątrz w zakładce Attributes. O zmiennych po prostu zapomnieli ;) (bug!). Tu masz podręczną (i mam nadzieję poręczną) pomoc w sprawie atrybutów i zmiennych: http://www.forum3d.pl/f3dbb/index.php?md=post&nw=1&pid=122857#122857 http://www.sidefx.com/index.php?option=com_forum&Itemid=172&page=viewtopic&t=11090&highlight=attributes+name+rule

W zakładce Attributes noda VoronoiFractureSOP masz toggle "Keep Internal Attributes". Włączasz go, a potem ->DeleteSOP, Delete by Expression i dajesz $__OUTSIDE==1. Na koniec PolyWireSOP i done.

Przecież sprawa jest prosta. Napisz pracę inżynierską z technologii 3d w internecie. Jest kilka mniej lub bardziej gotowych rozwiązań wartych uwagi, zrób przegląd, następnie przygotuj materiał na scenę, którą zaprezentujesz możliwości jednego z nich. Masz programowanie w web + grafika. Nawet Maxa użyjesz, chociaż wiedz, że używanie Maxa w pracy inżynierskiej jest jak postawienie ketchupu obok francuskiego szefa kuchni! powodzenia, skk. ps nazwałem Twoją pracę fikcyjną, bo trudno nazwać inżynierem kogoś z Twoimi kompetencjami w dziedzinie grafiki. Może nie powinienem. Mea culpa.

Napisz pracę na temat: "Fikcyjne dyplomy inżynierskie i poziom uczelni wyższych w Polsce, czyli bezrobocie wśród absolwentów i śmierć głodowa przyszłych emerytów i rencistów".

Słyszał ktoś plotki o podwyższeniu cen Maxa? Kiedy, ile, czy w ogóle?

DN nie Mpc, dzięki Albert.

Hej, bardzo fajny rezultat, dzięki. Jak przypuszczałem, maya rulez! :) Pewnie 80% wszystkich fluidów jest robiona w Mai, i to od wielu, wielu lat, dla mnie to pionierzy. Problem o ile mi wiadomo polega na tym, że to black box, co fabryka dała, a jak ci się look nie podoba, to masz problem. Niemniej 1500^3 jest imponujące. Ile ramu to zjadło? Możesz to zrzucić na dysk do jakiegoś formatu i zmierzyć, ile zajmuje density field? Jaką to ma głębię bitową? Widzę, że tu totalne zamieszanie panuje. Jak Albert napisał hybrido to marketingowa nazwa flipa w RF, który podobnie jak Naiad i Houdini przeskoczył na inny pomysł z SPH, ponieważ SPH jest kompletnie nieskalowalne, złożoność obliczeń rośnie wykładniczo do ilości cząsteczek. Flip wprowadzili do branży ludzie od Naiada: http://www.cs.ubc.ca/~rbridson/docs/zhu-siggraph05-sandfluid.pdf implementując go zdaje się najpierw w softwarze dla MPC. Jest dostępny w Houdinim od wersji 9.0, (2007!), jako Sand Solver, ale oczywiście nie nadawał się do niczego poważnego. Coś w tym jest, że program do wszystkiego, nigdy nie będzie tak sprawny w jednej dziedzinie, jak dedykowana aplikacja, ale kombajn wnosi swoje dobre strony. Jak Albert zauważył, może render-time meshing w RF jest sexy, ale w produkcji, kiedy jakość siatek ma znaczenie, kiedy je poprawiasz, selektywnie cieniujesz, fakt, że masz do dyspozycji całe SOPy i VEX ma gigantyczne znaczenie. (Na marginesie, render-time meshing w HDK robi się w 15 minut. Wszystko, co potrzebne jest gotowe, nie rozumiem, dlaczego SESI tego nie napisało...) Odnoszę wrażenie, że problem polega na tym, że patrzycie na aplikacje przez pryzmat fajnych ficzerów (szczególnie gdy są nowe, i widziane na vimeo), a tak naprawdę a aplikacji liczy się pipeline, a nie ficzer. Jeśli chodzi o wydajność nowego Flipa, jestem zupełnie spokojny. Stoi łeb w łeb z RF2012, co zostało sprawdzone na tej scenie: E, tam. Ludzie od Mai też nie śpią i pewnie smażą teraz nowy update, podejrzewam, że chodzi o gruntowną przebudowę Mai na w pełni proceduralny pakiet. Jest to jedna rzecz, która Mai brakuje. Zły model abstrakcji, zły dostęp do danych, skopana obiektowość. Co do Krakatoa, jest to fajna rzecz, ale ponieważ w H. od co najmniej 5 lat renderuje się do 80 milionów cząsteczek, chęć przyjrzenia się wersji SR jest jakby mniejsza. W H12 można na domowej maszynie renderować miliardy cząsteczek. Znów, dedykowane narzędzie ma pewnie wiele zalet, ale możliwość całego systemu trudno jest przecenić. Koniec końców wybiera się pipeline, a nie sexy ficzer. :), chyba że nie ma się wyboru, wtedy robi się wszystko w pluginach czekając, aż ogólnoświatowy postęp umożliwi zrobienie ujęcia, które wszystkie potem wyglądają tak samo...

Eksportujesz do fbx/mdd/obj/pc2/rib/realflow bin co tam chcesz. Chociaż w wersji darmowej zostaje Ci chyba tylko obj i pc2. To i tak więcej, niż niejeden inny program... :) ps Mógłbym prosić moderatora o przeniesienie części wątku (od postu deshu z pytaniem, jak zrobić tę scenę) do działu Houdini? Myślę, że tak będzie lepiej... chyba.

Załączam scenę. poly_from_points.hipnc.zip

he, he... dopóki nie zaczną się problemy, wtedy w ogóle nie da się go ogarnąć :) Chodził mi po głowie drugi pomysł, ale się zagapiłem, ten jest nawet fajniejszy i daje więcej możliwości: [ATTACH=CONFIG]84968[/ATTACH]

Skryptem da się to pewnie zrobić w każdym programie, także w Houdinim... fajnie jest to zrobić bez skryptu... [ATTACH=CONFIG]84967[/ATTACH] W szczegółach operowanie na krawędziach w H. jest jedną z najgorszych operacji, ponieważ pojęcie krawędzi nie istnieje w tym świecie, trzeba iterować po wierzchołkach poligonów i kombinować. Ale oczywiście da się ;)

Algorytm czy nowy ficzer nie powinien być powodem zmiany narzędzia. Nie daj się zwariować :) Mam ci napisać, do czego Houdini się nie nadaje? :)

28 minut na klatkę, ale na jakiejś monster maszynie. No jak lubisz, to tutaj ponad miliard cząsteczek we Flipie i ich render: [ATTACH=CONFIG]84953[/ATTACH] Jest akceleracja fluidów gridowych (dymki) na GPU. Kilka mikro-solverów ma toggle włączający wsparcie dla OpenCL. Działa bardzo przyjemnie o ile wystarczy Ci vramu. Idzie na każdej karcie z Cuda, nawet nasze stare Quadro 3500/3600 fx działają (choć wolniej niż 8 rdzeni CPU...). Ludzie robią testy na Gforcach. Na przykład porównanie GeForce GTX 470 z i7 930 @ 2.80ghz 4 Cores/8 threads: Grid: 256^3 OpenCL: 853.19 ms. na klatkę CPU : 8.35 sek. na klatkę

Na chłopski rozum cząsteczki próbkują geometrię klatka po klatce, aby dostać pozycje w świecie z uv. Jeśli sampler jest wolny i jednowątkowy będzie to działać wolno, także w Houdinim, jeśli spróbujesz to zrobić ekspresją, ale na szczęście jest VEX :) He, he, zmieniają się numery punktów, ale ID cząsteczek (dodatkowy atrybut właśnie na tę okoliczność) zostaje niezmienne i nigdy się nie powtarza... po prostu w cząsteczkach używamy $ID, a nie $PT. Tak to bywa z tymi programami :) Ważne są podstawy, czym się różni atrybut od zmiennej, jak zbudowana jest geometria i jak działają ekspresje i VEX. Reszta jest logiczną konsekwencją powyższych. Możesz nie wiedzieć, jak nazywa się node robiący to a to, ale sam program więcej cię nie zaskoczy. Jest przerażająco logiczny (z urokliwymi wyjątkami ;) ).

Ciekawy i obszerny artykuł wraz z przykładami od Coena Klostersa: http://www.apileofgrains.nl/category/tutorials

Selektywnie. Emiter zadziała w jednym wątku, goal po uv w VOPPOPie w wielu...POPy są w tej chwili najstarszym elementem Houdiniego, nawet tuż przed premierą 12 usunęli dodatkowy POP emiter z FLIPA, bo spowalniał całość. But here is a hint: W Sopach istnieje teraz SOPSolver, wchodzisz do środka, odtwarzasz wszystkie POPy za pomocą Vexa, co już od dawna robi większość 'prosów' w Popach), i masz w pełni wielowątkowe cząsteczki. Fizyka cząsteczek jest na tyle prosta, że odtworzenie większości POPów samemu nie jest żadnym problemem (zarówno wewnątrz POPów jak i SOPów). W takim przypadku prosta symulacja (adwekcja noisem), daje na przykład 0.2 sekundy dla 1 miliona cząsteczek (dwa rdzenie mojego laptopa na 100%), oraz 2 sekundy dla 10 milionów cząsteczek (oba przypadki 5 substepów). Jednak wystarczy, że dodasz DragPOP, i wydajność spada o 4 sekundy dla 10 milionów cząsteczek. Czyli unikać zwykłych nodów w POPach i robić wszystko VOPami, a będziesz miał w pełni wielowątkowe środowisko. Inna sprawa, że do symulacji cząsteczek możesz dodawać siły z SPH czy Flipa, czyli jak Ci się zachce możesz nagle dodać ciśnienie powierzchniowe, albo gęstość, chociaż cała symulacja wciąż będzie "ręczna".

Dymy są po prostu szybkie, bardzo. Sprawdź, zrób testy porównawcze, nie ma co bić piany. Szkopuł tkwi w tym, co z czym się porównuje. Fluidy Mayowe zawsze były szybkie, ale niedokładne, bo miały uproszczony model fizyczny. To samo jest z clothem, może physix jest szybki, ale czy jest wystarczająco dokładny i stabilny, aby symulować fotorealistycznie 4 warstwy ubrań? Fluidy w Houdinim zawsze były bardzo dokładne, ale wolne. Wolne głównie przez problemy z architekturą kontenerów danych. Wiele z przyspieszań w H12 bierze się po prostu z tego, że zapis do pamięci może być wielowątkowy, a do tej pory, nawet jeśli symulacja używała wiele wątków, zapis robił tylko jeden. To wciąż jest poważny problem Houdiniego na wielu polach. Na przykład nigdy nie należy robić dużych symulacji w viewporcie. Po ustawieniu sceny, należy odpalić hscripta i włączyć symulacje z linii komend. To zajmuje chwilę, a przyspiesza symulacje np. o 40%. Należy także pamiętać, że fluidy w H. od wersji 11 można posyłać na farmę na kilka komputerów, to nie tylko przyspiesza, ale umożliwia symulacje, które nie mieszczą się w jednym Ramie, jak na przykład ten grzyb (obrazek pochodzi z forum bety h12, symulacja zajmowała około 250GB ramu): [ATTACH=CONFIG]84947[/ATTACH] Ten grzybek ma 1600x2048x1600=5.5miliarda voxeli. Sam density field zajmuje jakieś ~5GB na dysku dla jednej klatki (i dla 32 bitowych danych, choć można dane zapisać także jako half float). Poza udogodnieniami w viewporcie (preselection highlights) nie ma wiele zmian w modelowaniu. To po prostu nie jest narzędzie do tego (poza przypadkami modeli proceduralnych). http://forums.cgsociety.org/showthread.php?f=86&t=1034527 Używaj, co lubisz :)