particles 'find target'?

[Juzwa 202]

Witam,

 

Chcialem sobie wystrzelic particle z jednego miejsca, zeby dolecialy do innego, konkretnego miejsca po czym "zdechły".

 

Chcialem to zrobic za pomocą Particles > Goal, ale nie wiem czy to dobra droga. Problem w tym ze gdy mam niższy goal weight niż 1, to particle latają sobie wokół mojego docelowego obiektu. Przy goal weight = 1, nie da sie ich "trajektorii" wlasciwie niczym zmienic i w prostej linii leca (mozna powiedziec ze od razu znajdują sie w miejscu "targetu")

 

A ja bym chcial powiedzmy zeby wylecialy z punktu A do punktu B po randomowym łuku który (czyli nie curve flow), po czym kill.

[ApaczoS 403]

Randomowy łuk zrobisz Random walk(Pflow). W drugim evencie dajesz find target a w trzecim lock/bond. Jeśli chcesz żeby zdychały po dotknięciu punktu B, dajesz kolejny event ze stopem i delete lub samo delete, zależy jak leży.

Poniżej mój setup do "czachy", co prawda tutaj jest physx ale zasada jest identyczna i w "zwykłym" pflow.

 

[Juzwa 202]

w maxie wiem jak to zrobic :) Dlatego dalem w tytule find target :)

 

Ale ucze sie dynamiki/particli w majce, chcialbym miec szersze pojecie w tym temacie i sie nie ograniczac do jednego softu.

[beny 524]

w maxie wiem jak to zrobic :) Dlatego dalem w tytule find target :)

 

Ale ucze sie dynamiki/particli w majce, chcialbym miec szersze pojecie w tym temacie i sie nie ograniczac do jednego softu.

 

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.

[ApaczoS 403]

Sorki Juzwa :) Zmylił mnie find target-operator w pflow i nie spojrzałem na dział.

[ca mel 326]

Możesz zrobić tak jak radzi Beny, jeśli chcesz pobawić się w skrypty, z tą małą różnicą, że nie normalizujesz, a unifikujesz wektor (poleceniem unit tworzysz wektor jednostkowy wyznaczający kierunek).

 

Druga metoda, to rzeczywiście goal, tyle że animowany, połączony z dużą wartością goal smooth.

Przydatne może być też kuliste pole siłowe drag wyhamowujące particle,

albo animowany parametr cząstek conserve.

 

Trzecia metoda - particle curve flow. Rysujesz łuk, puszczasz particle po krzywej z zadanym tempem. Albo jeśli wolisz po powierzchni.

 

Czwarta, dająca szybki ładny efekt - pole siłowe Volume Axis. Weź sobie przykład z visora, dość ciężko wytłumaczyć jak go użyć

 

Zabijanie cząsteczek najłatwiej zrobić jako event przy kolizji, druga metoda to prosty skrypt.

[beny 524]

... nie normalizujesz, a unifikujesz wektor (poleceniem unit tworzysz wektor jednostkowy wyznaczający kierunek)...

 

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

[legomir 476]

Ew. jak chcesz jakiegoś łatwego, przyjemnego rozwiązania to możesz użyć MASH nodes ;)

[ca mel 326]

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

 

Masz rację, bijąc się w pierś przyznaję że palnąłem durnotę. Unifikować można wektorową teorię czteropędu co najwyżej, a nie same wektory ;]

Tak czy owak strasznie mylące jest to melowe polecenie, nie wiedząc o 'unit' można stracić masę czasu i nerwów.

 

@Juzwa:

I tak jak pisze Beny - bez Mel'a trudno o coś konstruktywnego w mai, ten program chyba powstał głównie po to, żeby programiści mogli się bawić animacją.

http://www.wetransfer.com/downloads/109fe7a59d2a677f088d85e7b69d625120140403222420/716f65

Wrzuciłem pod tym linkiem skromny test instancji połączonej z animowanym goal, układającym się po uv innego animowanego obiektu,

instancje dodatkowo układają się wg krzywizny.

Powinien rozwiązać te i część przyszłych zapytań z goals.

Pozdr.

[Juzwa 202]

beny - dzięki wydaje sie to rzeczywiście świetne rozwiązanie. Pytanko tylko jak wyciagnac z Position (chodzi o pozycje particli, nie targetu) poszczegolne xyz? probowalem positionX, position.X, position[0] ale zadno z nich nie działa a w helpie za cholere nie moge tego znalezc.

 

ca mel - dzieki. Goal zbytnio nie ufam, przynajmniej do tego co chce zrobic, czyli mniej wiecej cos w stylu łuku elektrycznego. Goal ma tendencje do tworzenia sciezki w prostej linii, albo jak zmniejszych weight to mozna sciezki sobie zaklócać, powiedzmy turbulace field, ale wtedy particle nie trafiaja w cel i brzydko oscyluja wokol targetu.

 

legomir - fajne te MASH nodes ale z tego co widze to płatne... :P Najpierw sprobuje skorzystac z tego co ma majka wbudowane na stale, bo wiem że na pewno coś moge to zrobić bez pluginów.

[beny 524]

Pytanko tylko jak wyciagnac z Position (chodzi o pozycje particli, nie targetu) poszczegolne xyz?

 

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

[Juzwa 202]

vector $pozycja = position;

 

okej, matematyka się kłania :) zapomnialem zeby otrzymac jakis wektor trzeba dodac dwa wektory a sama pozycja nie jest wektorem :)

 

tylko dla potwierdzenia czy dobrze rozumiem:

 

vector $pozycja = position;

 

to jest deklaracja nowej zmiennej jako wektor [0,position]?

[beny 524]

okej, matematyka się kłania :) zapomnialem zeby otrzymac jakis wektor trzeba dodac dwa wektory a sama pozycja nie jest wektorem :)

 

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

 

tylko dla potwierdzenia czy dobrze rozumiem:

 

vector $pozycja = position;

 

to jest deklaracja nowej zmiennej jako wektor [0,position]?

 

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

[legomir 476]

legomir - fajne te MASH nodes ale z tego co widze to płatne... :P Najpierw sprobuje skorzystac z tego co ma majka wbudowane na stale, bo wiem że na pewno coś moge to zrobić bez pluginów.

 

 

Nawet nie wiedziałem, że płatne ostatnio jak mnie interesowało to nadal było za darmoche

 

@beny na dole to okno tylko bez cytatu to nie wiadomo o co chodzi.

Edited April 4, 2014 by legomir

[beny 524]

Nawet nie wiedziałem, że płatne ostatnio jak mnie interesowało to nadal było za darmoche

 

Nie to okno? :)

[ca mel 326]

ca mel - dzieki. Goal zbytnio nie ufam, przynajmniej do tego co chce zrobic, czyli mniej wiecej cos w stylu łuku elektrycznego. Goal ma tendencje do tworzenia sciezki w prostej linii, albo jak zmniejszych weight to mozna sciezki sobie zaklócać, powiedzmy turbulace field, ale wtedy particle nie trafiaja w cel i brzydko oscyluja wokol targetu.

 

Hmm, zatem ciekaw jestem jak zamierzasz zrobić zakrzywioną trasę nadając cząstkom prędkość na podstawie różnicy wektorów. Z założenia polecą przecież po najkrótszej drodze.

Co więcej - polecą w kierunku pivota (transform) obiektu, no chyba że jesteś już na tyle biegły w melu by losowo wyznaczać docelowe konkretne punkty na powierzchni.

 

Piszesz, że z goal oscylują wokół obiektu - niekoniecznie, goal ma kilka parametrów i przy dobrych ustawieniach nic nie krąży.

Jestem zdania, że warto poznać dobrze dostępne narzędzia, a dopiero gdy nie wystarczają - brać się za skrypty.

W przykładzie który Ci przesłałem jest rozwiązanie oparte na goal, ale prędkość cząstek jest opisana prostym skryptem.

Goal ma tę zaletę, że nie przejmujesz się miejscem lądowania cząstek, wbudowany w mayę sampler robi to za Ciebie.

[legomir 476]

Zawsze możesz przyczepić jako goal animowany po ścieżce lokator i puścić za nim particle, wykryć kolizje i pozwolić im zdechnąć.

 

Nawet lepszy pomysł mam możesz użyć dwóch goal jeden zaanimowany po krzywej i wyłączający się niedaleko obiektu, gdzie aktywuje się drugi goal bezpośrednio przypisany do obiektu.

[beny 524]

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.

[Juzwa 202]

Hmm, zatem ciekaw jestem jak zamierzasz zrobić zakrzywioną trasę nadając cząstkom prędkość na podstawie różnicy wektorów. Z założenia polecą przecież po najkrótszej drodze.

Co więcej - polecą w kierunku pivota (transform) obiektu, no chyba że jesteś już na tyle biegły w melu by losowo wyznaczać docelowe konkretne punkty na powierzchni.

 

Losowe miejsca na powierzchni to zostawie sobie na potem, kiedy bedzie juz wszystko działać pięknie.

 

Ale generelnie tak jak pisał beny, a ja to na chłopski rozum tak widzę:

 

image upload no compression

 

mam wtedy magnitude M, tylko ze jak podpinam to pod velocity to nie dziala jak trzeba, musze jeszcze ten wektor znormalizowac. W ten sposob jak sobie wrzucę go jako Runtime After/Before Dynamics (albo tu i tu dla pewnosci) to bede mogl sobie sterowac predkosciami particlami dowolnie poprzez jakis tam dodatkowy parametr co sobie zrobie. No i plus wielki, tak jak chce, moge zarzucac na te particle dowolne Field'y i beda dzialaly :)

[ca mel 326]

Field'y będą działały, ale rozwalą Ci całą trajektorię na tyle, że cząstki nie trafią w cel.

 

Beny podpowiada, żeby wyliczyć jednostkowy wektor prędkości na samym początku. Czyli odejmując pozycję target od pozycji perParticle i normalizując dostaniesz wektor prędkości (można rzecz prędkość z określonym już kierunkiem) który możesz wymnażać przez zmniejszającą się liczbę w rezultacie hamującą cząsteczki.

Jeśli zaczniesz mieszać w tym wektorze siłami, cząstki polecą tam gdzie skierują je siły, a nie określona na początku prędkość wektorowa (czyli kierunek).

[beny 524]

Field'y będą działały, ale rozwalą Ci całą trajektorię na tyle, że cząstki nie trafią w cel.

 

Beny podpowiada, żeby wyliczyć jednostkowy wektor prędkości na samym początku. Czyli odejmując pozycję target od pozycji perParticle i normalizując dostaniesz wektor prędkości (można rzecz prędkość z określonym już kierunkiem) który możesz wymnażać przez zmniejszającą się liczbę w rezultacie hamującą cząsteczki.

Jeśli zaczniesz mieszać w tym wektorze siłami, cząstki polecą tam gdzie skierują je siły, a nie określona na początku prędkość wektorowa (czyli kierunek).

 

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.

Edited April 4, 2014 by beny

[ca mel 326]

Czyli tak to widzisz.

 

Pomysł fajny, ale strasznie pracochłonny.

Dojdzie tu jeszcze kilkadziesiąt linijek wyznaczających target dla cząstek, czyli napisanie mini samplera powierzchni,

stworzenie tablic z targetami i przypisywanie ich do nowo urodzonych particli, pilnowanie by wektory prędkości zgadzały się z odpowiednimi targetami w tablicach.

 

No i przede wszystkim całość będzie skomplikowana obliczeniowo przy większej ilości cząstek.

Gdyby nie założony wpływ field'ów podobałoby mi się rozwiązanie polegające na wstępnym przeliczeniu wektorów (liczone tylko raz przy kreacji)

kierujących cząsteczki pod zadane uv'ki i wytracające prędkość po którejś klatce (linijka kodu w afterDynamics działająca tylko przez kilka klatek), to miałoby sens przy olbrzymich ilościach particli, bo byłoby zdecydowanie szybsze niż goal.

 

Tu zaś całość może przypominać budowanie armaty do zabicia muchy ;]

 

W załączniku filmik z prostym goal połączonym z dragField i uniformem, udawadniający że goal (przyciągający po uv kilkoma liniami mel)

wcale nie musi krążyć wokół targetu. 7 minut roboty, efekt ten sam ;]

Edit, na vimeo:

Edited April 4, 2014 by ca mel

[beny 524]

W załączniku filmik z prostym goal połączonym z dragField i uniformem, udawadniające że goal (budowany po uv) wcale nie musi krążyć wokół targetu. 7 minut roboty, efekt ten sam ;]

http://www4.zippyshare.com/v/36408709/file.html

 

Noo super!

[ca mel 326]

Noo super!

 

Przecież wiem, że wiesz, że się da ;]

 

To dla Juzwy filmik, przestrzegający przed armatą na muchę hehe

[Juzwa 202]

Dzieki chlopaki za zainteresowanie temate, :)

 

Okej juz cos udalo sie zrobic, czyli znormalizowac wektor :) Dzieki beny za funkcje unit, bo przemnozylem sobie to sam, niepotrzebnie jak sie okazuje.

 

Co ciekawe przy duzych predkosciach, gdy przemnazam sobie znormalizowany wektor, to particle (podobnie jak przy Goal) oscyluja wokol targetu (mysle ze wynika to z faktu, ze nie trafiaja w cel bo maja za duza predkosc ). Ale to mniejsza sprawa, mysle ze mozna w lifespan jakies ładne wyrazenie sobie do tego stworzyc.

 

Tym razem taki problem mam:

 

image hosting no sign up

 

Kazdy z particli generuje nowe particle (te nowe to tak naparwde te o które cała sprawa się rozchodzi :) ). Zauwazylem ze tworzą się dziwne linie w kierunku targetu, tak jakby to byly te "znormalizowane wektory" :)

 

Jak sobie sprawdzilem, to co klatke sie tworzy taka linia wzdłuż. Nie rozumiem.... Jest to defaultowy Omni emitter, rate = 1000

[beny 524]

Dzieki chlopaki za zainteresowanie temate, :)

 

Okej juz cos udalo sie zrobic, czyli znormalizowac wektor :) Dzieki beny za funkcje unit, bo przemnozylem sobie to sam, niepotrzebnie jak sie okazuje.

 

Co ciekawe przy duzych predkosciach, gdy przemnazam sobie znormalizowany wektor, to particle (podobnie jak przy Goal) oscyluja wokol targetu (mysle ze wynika to z faktu, ze nie trafiaja w cel bo maja za duza predkosc ). Ale to mniejsza sprawa, mysle ze mozna w lifespan jakies ładne wyrazenie sobie do tego stworzyc.

 

Tym razem taki problem mam:

 

 

image hosting no sign up

 

Kazdy z particli generuje nowe particle (te nowe to tak naparwde te o które cała sprawa się rozchodzi :) ). Zauwazylem ze tworzą się dziwne linie w kierunku targetu, tak jakby to byly te "znormalizowane wektory" :)

 

Jak sobie sprawdzilem, to co klatke sie tworzy taka linia wzdłuż. Nie rozumiem.... Jest to defaultowy Omni emitter, rate = 1000

 

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