beny

Super! Tu masz highlighter do eclipsa melowy. Sprawdzałeś go? http://www.creativecrash.com/downloads/applications/syntax-scripting/c/eclipse-maya-mel

Najlepiej używać w Mayce edytora zewnętrznego jak Eclipse czy Notepad++. Niestety edytor Maykowy jest toporny że szok ... itak chwała mi że po 16 latach dodali syntax highlighting :P ... tracając do np. Eclipsa - piszesz sobie kod w takim eclipsie (do którego możesz ściągnąć syntax highlight do MELa i pythona) na przykład C:\mojKatalog\mojSkrypt.py - piszesz w nim cały kod zapisujesz a w Mayce masz tylko do odpalenia linijkę: dla Pythona - exec(file(r'C:\mojKatalog\mojSkrypt.py')) albo dla MELA - source "C:/mojKatalog/mojSkrypt.py" Można do Eclipsa wgrać odpalanie kodu z samego programu poprzez commandPort w Mayce, ale mi to zawsze do kitu działało - może za głupi jestem, ale ja odpalam sobie linikę. W ten sposób nie gubisz kodu po przypadkowym wciśnięciu ctrl+Enter bez zaznaczonego skryptu, oraz możesz łatwo wrócić do danego skryptu po paru latach nieużywania na przykład. ps. Mam podobne zdanie do tego co wyżej napisałeś. @toomek - pamiętaj że czasami mieć wszystko w jednym miejscu jest gorsze od wielu okien - patrz Max :)

Myślę że najprościej będzie przeciągnąć Śr.P.M. lokator w outlinerze na jointa (wtedy joint bedzie parentem lokatora) a potem wyzerować na lokatorze transformacje. W ten sposób lokator otrzyma wszystkie transformacje z jointa. Jeżeli nie będziesz chciał aby pozostał lokator dzieckiem jointa (jakkolwiek by to brzmiało) to wyciągnij znowu po tej operacji ŚPM lokator od jointa i już nie będzie dzieckiem ale będzie miało juz naniesione wszystkie koordynaty z jointa ze zsumowanymi transformacjami po drodze. Jeżeli będziesz chciał żeby lokator pobierał orientację jointa w biegu a nie chcesz constrainować to pozostaje Ci xform komenda melowa. Niemniej jednak myslę że tak naprawdę chodzi Ci o taki workflow - Maya way: - Zgrupuj sobie lokator do samego siebie i grupę skonstrainuj do jointa. W ten sposób się robi skonstraintowany obiekt który normalnie sobie obracasz itd. później, bo constraint jest na grupie ale obiekt możesz dalej sam obracać. Nie można. Chyba, że skryptem. W outlinerze możesz sobie pociągnąć na dole taka kreskę w outlinerze z kropkami do góry przez co outliner dzieli się na 2 outlinery i wtedy robisz sobie ŚPM drag & drop ale tylko do hierarchii DAG czyli relacji parent->dziecko. Do operacji kopiowania materiałów i połaczeń używasz hypershade (ew. Node Edytor w Maya 2013+), do UV "UV Texture Edytor", do animacji "timeslidera" na dole ew. graph editor/trax editor. Jak już pisałem gdzieś tam. Nie wkurzaj się na Maykę że nie jest tak jak w XSI. Jest inaczej i tak zostanie, a trzeba się softu nauczyć :(

Chuck Norris

"Przepracowane osoby o ponadprzeciętnej wadze" olaf'ie!

Dlatego mówię, że na razie jeszcze tak nie jest, ale sam napisałeś "urazona moze sie poczuc", więc lada dzień i to będzie podchodziło pod paragrafy.

Ja pierdykam, niedługo samo wystawienie oferty będzie dyskryminacją, bo na przykład ktoś sparaliżowany poczuje się ugodzony, że przecież on/ona/ono (żeby być poprawny prawnie) nie może pracować.

Ekscytujące może być latanie samolotem. Praca grafika nie jest ekscytująca - jej efekty są.

@olaf: Chodzi o stwierzenie "sekretarka"? Bo jak tak to powinni napisać "sekretarza"? :) tak bo za niepełnosprawność zwrotu nie dostaną, a za orzeczenie tak :)

Ja ten przepis raczej bym interpretował jako niedopuszczanie do pracy jeżeli jesteś niepełnosprawny. A wymaganie orzeczenia o niepełnosprawności chyba może być w zapisie. Wielokrotnie widziałem takie ogłoszenia m.in. na pracowników ochrony itd. do monitoringu, gdyż PFRON dofinansowuje takie stanowiska pracy. Wg. mnie jest zgodne z prawem.

Cieszę się, że ktoś zauważył włosy i docenił, gdyż miałem w nich swój udział - master staszek czesał i shaderował to oznaczało już na wstępie, że będzie gruuuuubo, a mi pozostało nic nie zepsuć z ich symulacją i chyba się udało :) ... ufff ... noi mimo że symulacja długich stylizowanych włosów to koszmar gdy postać się zaczyna dynamicznie ryszać, z nowym systemem zarządzania włosami długimi było to znacznie uproszczone :) Co do zbieżności z cyberpunkiem - ani skan pani, ani mocap, ani włosów shader nie są cyberpunkowe. Shader skóry na pewno od tego czasu dopracowany ostro przez m.in. master Idziego, ale był zbudowany całkowicie na nowo pod Arnolda. Loki faktycznie podobne, ale zbudowane na nowym "workflow" wypracowanym dopiero w zeszłym roku tuż po Cyberpunku, więc również nowe. ps. Mam nadzieję, że niedługo ukaże się making-of, staszkowe rendery włosów w oświetleniu studyjnym wyszły po prostu obłędnie!! Dzięki za słowa uznania :) Pozdrawiam, M.

Zapraszam serdecznie. Oprócz tego, że zgromadziliśmy naprawdę spory kawałek materiału o produkcji teasera do Wiedźmina, który mam zamiar w dostępnym czasie jak najobszerniej omówić, to będzie to również pierwsza publiczna prezentacja naszego systemu zarządzania dynamiką włosów długich - stylizowanych. Zastosowaliśmy wspomniany system nie tylko w wymienionym wyżej Wiedźminie, lecz również w ostatniej prezentowanej produkcji Nitro Nation oraz kolejnych produkcjach będących w trakcie budowania. Pozdrawiam, Maciej Benczarski aka beny

"Unit" camel przecież pierwszy podał :) a co do tego błędu to czort go wie ... wygląda jak jakiś błąd w randomie - za mało randomowy przez co generują się particle w tych samych miejscach ale z różnymi prędkościami - pewnie gdzieś integer się robi zamiast floata, ale żeby mieć pewnośc zapodaj scenkę i się sprawdzi.

Cieszę się, że mogłem pomóc :)

Skaczesz między softami, że szok :) Takie fuckupy z reguły powstają jak zaczniesz skalować grida. Grid FUME'a musi mieć skalę 100% ni więcej ni mniej. W przeciwnym wypadku krzaki się robią i na taki błąd u Ciebie to wygląda.

Nooo panie - PINKNE!

Noo super!

Hmmm no nie do końca chyba o to mi chodziło ... przynajmniej z tego co zrozumiałem, że napisałes. Juzwa ma wyliczać ten wektor jednostkowy co ramkę i korygować obecne velocity o kierunek, w którym chce lecieć. Czyli działają sobie force'y normalnie na particle ale co ramkę w post dynamics skrypcie odbywa się korekcja velocity. Czyli tak: 1. Leci sobie particle w kierunku losowym $currentVelocity. 2. Koryguję go $newVelDir = unit($currentVelocity) + unit($targetPos -$currentPos) 3. Multiplikuję wynikowy jednostkowy kierunek sterując prędkością np. $newVelocity = $newVelDir * mag($currentVelocity). Czyli że będzie miał particle taką samą prędkość jak przed expresją ale będzie leciał w kierunku targeta. 4. Zakładam ze jak jest już blisko to niech już hamuje: if( mag($targetPos -$currentPos) linstep zakłada że jak jest odległość wieksza od 5 to zostawia velocity na obecnym poziomie (mnozy przez 1), a jak będzie proporcjonalnie mniejsza to pomnoży nowe velocity o wartość zremapowaną międziy 0 a 5. Tutaj będzie trochę za mocne hamowanie, wiec jeszcz emnożymy przez 0.95 coby w miejsc particle nie stanął po przekroczeniu odległości 5.0. Piszę to z czapy więc mozliwe że trzebaby pobawić się jeszcze wartościami. edit: Aha jebnąłem się - $newVelDir jeszcze trzeba tez "unit" potraktować przed przemnożeniem bo tak będzie zmieniał predkość particle.

Juzwa, jak goal Ci lata dookoła punktu docelowego to dodaj sobie takie o coś w per particle array expression after dynamics: ///// vector $tagetPosition = >; //jakas Twoja pozycja docelowa - Ty wiesz jaka to bedzie vector $curPos = position; $odlegloscZwalniania = 1.0; vector $tmpVelocity = velocity; if (mag($tagetPosition - $curPos) velocity = $tmpVelocity; //albo tak velocity = [$tmpVelocity.x, $tmpVelocity.y, $tmpVelocity.z]; bo nie pamietam czy lyknie wektor bezposrednio /////// albo po prostu daj jakiegos mocnego drag force przy punkcie docelowym i z dyni.

Nie to okno? :)

Udam że tego nie czytałem :) Pozycja jest najbardziej reprezentatywną formą wektora w świecie przestrzeni euklidesowej. Ale fakt faktem - suma wektorów też daje wektor :) Nie. To jest przekonwertowanie pozycji, która jest zwracana domyślnie w formie tablicy floatów na wektor X,Y,Z. vector $pozycja = position to jest to samo co to tylko że krócej: $pozArray = position; // tutaj position zwraca Ci tablice floatow ... np. [1.234,2.453,-6.464] vector $pozycja = >; // $pozArray[2] tak się dobierasz do trzeciego elementu tablicy

kliknij prawym w polu "Per particle (array) attributes -> position" i wybierz "runtime after dynamics" i wpisz to: vector $pozycja = position; print ("Id: " + id + " pozycja xyz: " + $pozycja.x + "," +$pozycja.y + " ," + $pozycja.z + "\n" ); potem "Create" na dole. każdy particle co ramkę będzie Ci zwracał teraz swoją obecną pozycję.

Dlaczego mieszasz chłopakowi w głowie? :p "Normalizacja wektora" to termin matematyczny i jest dzieleniem wszystkich komponentów wektora przez jego długość co w rezultacie daje wektor długości 1 (unit vector), a że w Mayce do zwrócenia znormalizowanego wektora używa się komendy "unit" dla wektorów to już inna sprawa. Wynikająca z resztą z zajętej już komendy "normalize" robiącej dokładnie to samo tyle, że na tablicy floatów. Unifikacja wektorów to zupełnie inna sprawa - unifikować można coś z czymś, czyli doprowadzać, aby jedno było identyczne jak drugie. No to się uniosłem :))) Tak czy inaczej - jak chłopak chce się uczyć particli w Mayce to bez MELa i wektorów ani rusz więc niech zacznie jak najwcześniej :)

Wektory Twoje przejaciele. Wektor posTarget-posCurrent = kierunek_w_którym_chcesz_lecieć. Jak go znormalizujesz i przemnożysz przez jakiś parametr sterujący prędkością to możesz używać tego wektora do sterowania velocity particla kierując go gdzie chcesz lecieć. Jak to zrobisz post dynamics, możesz sobie odchylać particla siłami. Proste jak wysikanie dziury w śniegu.

A dorzuć siatki. Dlaczego nie? Szkoda że straciłeś zapał na tak wczesnym etapie, bo zaczyna już autko nabierać fajnego kształtu. Jak dorzucisz kratkę na przód, dodasz grubość ścianek to zobaczysz, że nie jest na razie tak źle. Nie poddawaj się.