Pokaż wiadomości

Ta sekcja pozwala Ci zobaczyć wszystkie wiadomości wysłane przez tego użytkownika. Zwróć uwagę, że możesz widzieć tylko wiadomości wysłane w działach do których masz aktualnie dostęp.


Wiadomości - taki_tam

Strony: [1] 2 3 4 5 ... 8
1
Matematyka i fizyka / Odpowiedź kolizji ciał sztywnych
« dnia: Marzec 30, 2012, 17:14:31 »
Siema!
Długoo nie pisałem nic, co nie znaczy, że nie śledzę forum.
Na początku chciałbym wyrazić zadowolenie z nowego warsztatu 3.0, jak dla mnie świetny (poza paroma błędami, 1 ważny zamieściłem w bug-truckerze).

A teraz do rzeczy.

Ostatnio zacząłem pisać od nowa mój silnik fizyczny, tym razem prawdziwe ciała sztywne.
Poprzedni symulował ciała (nie tylko sztywne) typu "Verlet-based rigid body".
Zdecydowałem się na napisanie wszystkiego od nowa, tym razem wg. dokumentu Pana Chrisa Heckera, ponieważ pojawiły się problemy ze stabilnością i wydajnością przy ogromnej liczbie przeróżnych ciał(mimo podziału przestrzeni - tutaj jednak znaczenie na wydajność miał mój zabytkowy komputer na który jestem jeszcze skazany, podział przestrzeni działał sprawnie). Jednakże Verletowskie ciała sztywne/miękkie wymagają nieco więcej od procesora, a w zasadzie miękkie nie są mi do niczego potrzebne.

Odpowiedź kolizji na prędkość liniową wyglądają bez zarzutu, jednak z prędkością kątową są już jaja.
Na początek przedstawię mini schemat działania silnika:
1: sprawdzanie kolizji metodą SAT
- jeśli jest odsuwam ciała o MTD(jest znormalizowany więc mnożę go przez głębokość)
- liczę odpowiedź kolizji
2: liczenie prędkości
3: liczenie pozycji
4: pętla
5: render

Dla kolizji liczę dwa punkty kontaktu jeśli to możliwe(obliczenia działają bez zarzutu)

Teraz przedstawię równania, które biorą udział w odpowiedzi kolizji.

R1, R2 - wektor od punktu kontaktu do środka masy
VA, VB - wektor prędkości w punkcie kontaktu
VAB - Prędkość względna w punkcie kontaktu
N - wektor normalny kolizji
e - współczynnik restytucji <0, 1>
J - impuls

Teraz tak
R1 = contact.pos - bodyA.pos
R2 = contact.pos - bodyB.pos
VA = bodyA.vel + Cross(R1, bodyA.AngVel)
VB = bodyB.vel + Cross(R2, bodyB.AngVel)
VAB = VB - VA
VN = Dot(VAB, N)
J = (-(1.0 - e) * VN) / (Dot(N, N) * (bodyA.InvMass + bodyB.InvMass) + (Sqr(Dot(R1, N)) * bodyA.InvI) + (Sqr(Dot(R2, N)) * bodyB.InvI))

Nowe prędkości:
bodyA.vel = bodyA.vel + N * J / bodyA.InvMass
bodyA.AngVel = bodyA.AngVel + Dot(R1, N*J) / bodyA.InvI

bodyB.vel = bodyB.vel - N * J / bodyB.InvMass
bodyB.AngVel = bodyB.AngVel - Dot(R2, N*J) / bodyB.InvI

Objawy: Tak jak napisałem na początku, obliczenia dla prędkości liniowej wyglądają w porządku, jednak dla prędkości kątowej wygląda to tak, że ciało przewraca się cały czas z jednego boku na drugi i z powrotem.

Osobiści przez 2 noce przeglądałem źródła, czytałem dokument Heckera ale bez skutku decydując się na prośbę o pomoc na forum.

Edit: Oo, żeby nie lamić, zapomniałem pytania :P Co robię źle, czy moje obliczenia są poprawne?
Jeśli to konieczne mogę dodać RAR'a z demkiem.

Pozdrawiam! ;)

taki_tam

2
Unity 3D / Odp: Unity3D Mobile Basic za darmo do 8 kwietnia
« dnia: Marzec 07, 2012, 18:36:29 »
A jak jest z kluczem aktywacyjnym? Jest dożywotni?
Chodzi mi o przypadek, że np. dysk padnie i co wtedy?

Pozdrawiam!

Edit: Oczywiście instalkę zachowam na innym nośniku. Czy klucz traci swą wartość po pierwszej rejestracji?

3
Matematyka i fizyka / Odp: Tarcie i restytucja.
« dnia: Lipiec 04, 2011, 19:35:14 »
Problem rozwiązany. Nie uwzględniłem iteracji na klatkę symulacji. Przez to prędkość wypadkowa była za każdym razem znikomo mała.

Pozdrawiam! ;)

4
Matematyka i fizyka / Tarcie i restytucja.
« dnia: Lipiec 04, 2011, 15:02:19 »
Siema, dawno mnie nie było ;)

Napisana przeze mnie fizyka ciała sztywnego działała elegancko do czasu kiedy nie zaimplementowałem tarcia i restytucji. Nadmienię tutaj, że wykorzystałem tutaj integracje Verleta(ciała zbudowane z punktów materialnych połączone sztywnymi sprężynami). Napisze teraz bardziej ogólnie co się dzieje po kolei.
Sprawdzam czy Bounding-Box'y ciał nachodzą na siebie - jeśli tak sprawdzam kolizje SAT'em i jeśli kolizja zchodzi pobieram poszczególne informacje: Normalna kolizji, długość tego wektora, ściana jednego ciała, wierzchołek drugiego ciała. Przeszukując internet jak napisać odpowiedź kolizji dla takich ciał(gdyż nie jest to w zasadzie bryła sztywna i zasady dynamiki bryły sztywnej na nic się tu praktycznie nie zdadzą) znalazłem dobry artykuł na gamedev.net "A Verlet based approuch for 2D game physics". Jest tam wyjaśniona kwestia odpowiedzi kolizji w zrozumiały i klarowny sposób. Jedyny mankament jest taki, że koleś nie uwzględnił właściwości tarcia i restytucji tłumacząc sie, że to już nie będzie takie proste. I owszem dla ześlizgiwania się ciała(ściany) po wierzchołku drugiego ciała może i proste nie jest(nic mi do głowy nie przychodzi jak to zrobić) ale dla wierzchołków wydawało mi się to banalne do póki okazało się, że coś tu nie działa. Przytoczę tu kod procedurki odpowiedzialnej za odpowiedź kolizji wraz z komentarzami, a Wy jeśli możecie napiszcie czemu to nie działa(już pare dni mi to mamuci w głowie i kompletnie nie mam pojęcia dlaczego nie działa) i czy w zasadzie ma prawo działać ;)

//INFORMACJE O KOLIZJI
  TUnCollisionInfo2D = record
    sDepth: Single;
    vNormal: TV2D;

    xEdge: TUnConstraint2D;
    xParticle: TUnParticle2D;
  end;

//ODPOWIEDŹ KOLIZJI
procedure TUnPhysX2D.ProcessCollision();
var
  vCollisionVector: TV2D; 
  T, Lambda: Single;
  xPA, xPB: TUnParticle2D;
  sEdgeMass: Single;
  sInvCollisionMass: Single;
  sRatio1, sRatio2: Single;
  vVelocity, vVelT, vVelN: TV2D;
  sRestitution, sFriction: Single;
begin
  //Cząsteczki należące do krawędzi, na której jest kolizja (ciało 1)
  xPA:= TUnBody2D(m_xCollisionInfo.xEdge.Parent).Particle[m_xCollisionInfo.xEdge.ParticleA];
  xPB:= TUnBody2D(m_xCollisionInfo.xEdge.Parent).Particle[m_xCollisionInfo.xEdge.ParticleB];

  //Właściwości kolidującego ciała.
  sRestitution:= TUnBody2D(m_xCollisionInfo.xEdge.Parent).Restitution;
  sFriction:= TUnBody2D(m_xCollisionInfo.xEdge.Parent).Friction;

  //Wektor kolizji.
  vCollisionVector:= V2D_Scale(m_xCollisionInfo.vNormal, m_xCollisionInfo.sDepth);

  if Abs(xPA.Position.X - xPB.Position.X) > (xPA.Position.Y - xPB.Position.Y) then
   T:= (m_xCollisionInfo.xParticle.Position.X - vCollisionVector.X - xPA.Position.X) / (xPB.Position.X - xPA.Position.X)
  else
   T:= (m_xCollisionInfo.xParticle.Position.Y - vCollisionVector.Y - xPA.Position.Y) / (xPB.Position.Y - xPA.Position.Y);

  Lambda:= 1.0 / (T * T + (1.0 - T) * (1.0 - T));

  sEdgeMass:= T * xPB.Mass + (1.0 - T) * xPA.Mass;
  sInvCollisionMass:= 1.0 / (sEdgeMass + m_xCollisionInfo.xParticle.Mass);

  sRatio1:= m_xCollisionInfo.xParticle.Mass * sInvCollisionMass;
  sRatio2:= sEdgeMass * sInvCollisionMass;

  //Odpowiedź kolizji dla cząsteczek z krawędzi na której jest kolizją (ciało 1)
  if xPA.Active then
   xPA.Position:= V2D_Sub(xPA.Position, V2D_Scale(vCollisionVector, (1.0 - T) * sRatio1 * Lambda));
  if xPB.Active then
   xPB.Position:= V2D_Sub(xPB.Position, V2D_Scale(vCollisionVector, T * sRatio1 * Lambda));

  //Odpowiedź kolizji dla cząsteczki która koliduje z ciałem 1. (ciało 2)
  if m_xCollisionInfo.xParticle.Active then
   begin
     //najpierw odsuwam ją od ciała 1     
     m_xCollisionInfo.xParticle.Position:= V2D_Add(m_xCollisionInfo.xParticle.Position, V2D_Scale(vCollisionVector, sRatio2));

     //Tutaj liczę prędkość cząsteczki po kolizji uwzględniając tarcie i restytucję. Nie mam zielonego pojęcia dlaczego to nie działa.
     vVelN:= V2D_Scale(m_xCollisionInfo.vNormal, V2D_Dot(m_xCollisionInfo.vNormal, m_xCollisionInfo.xParticle.Velocity));
     vVelT:= V2D_Sub(m_xCollisionInfo.xParticle.Velocity, vVelN);
     vVelocity:= V2D_Add(V2D_Scale(vVelT, 1.0 - sFriction), V2D_Scale(vVelN, -sRestitution));

     m_xCollisionInfo.xParticle.Velocity:= vVelocity;
   end;
end;

Dodam też, że czasem przy kolizji (uwzględniając tarcie i restytucję) ciała potrafią zniknąć (pozycja w nieskończoność idzie).

Jeśli ktoś ma jakiś pomysł będę bardzo wdzięczny bo w sumie bez tego stoję w miejscu. Jeśli ktoś nie rozumie wzorów na prędkość wliczając restytucję i tarcie mogę podesłać kawałem objaśnienia wraz z rysunkiem.

Pozdrawiam!

5
Kursy do Omegi pod Delphi.
Są tam artykuły na temat, o którym mówisz.

http://www.unit1.pl/224,idx

Pozdrawiam! ;)

6
Matematyka i fizyka / Odp: Kolizja poligonów...
« dnia: Listopad 25, 2009, 16:17:05 »
Wrzuciłem na server, bo na twardzielu siedzi ;)
http://kompustelnik.unit1.pl/down/Polycolly.zip

Cytuj
wzór na odległość punktu od prostej jest w każdym podręczniku matematyki do gimnazjum
To przykre, ale nie... :( Jestem w drugiej liceum na mat-fiz i dokładnie dzisiaj to było..

Pozdrawiam! ;)

7
Językoznawstwo / Odp: Nowy jezyk od Google - Go
« dnia: Listopad 11, 2009, 13:27:46 »
Jak dla mnie żadnych rewelacji nie ma, mimo iż tak jak yarpen długo nie spoglądałem na dokumentację, ale moim zdaniem odnajdywanie koła na nowo...

Pozdrawiam! ;)

8
Compo i bitwy / Odp: Compo 3xKula+Raytracing
« dnia: Listopad 04, 2009, 18:09:47 »
Cytuj
Ahahaha kolejny epizod z cyklu 'nadgorliwy programista i grafik próbują się dogadać' ;>>>

Chociaż przyznaje że pomysł z kawałkami kul jest dobry ;>

Raczej epizod o typowym polaku ;)

Więcej OT nie robię bo temat RayTracing'u jest mi niestety obcy  :-\

Pozdrawiam! ;)

9
Szkółka / Odp: Kolizje z mapą kolizji
« dnia: Wrzesień 18, 2009, 22:49:13 »
To zależy czy gracz jest np. punktem materialnym w kształcie jakiejś elipsy czy coś.

Ja zrobiłem to na zasadzie:
- W edytorze map(u mnie mapa z poligonów ale tilesy również mogą być poligonami, prawda? ;) ) klikając na poligon można przypisać mu
  czy da się z nim zderzyć i fizyczne właściwości (tarcie i restytucje - przez co można wszelakie powierzchnie tworzyć jak beton, piach,
  lód itd.).

- Mapę kolizji tworzę w sposób(w grze):
* W pętli sprawdzam które poligony są kolizyjne.
* Tworzę tablicę jego wierzchołków.
* Ze wzory na środek ciężkości wyznaczam pozycję poligonu (wiem dziwna metoda, ale szybka i sprawna ;) )
* Mając pozycję poligonu liczę pozycje jego wierzchołków w lokalnym układzie współrzędnych(pozycja poligonu - dany wierzchołek)
* Tworzę listę tych poligonów i wsadzam wszystko do SAT'a

Z czymś takim ciała sztywne, punkty materialne mogą pięknie reagować ; ]
Link do edytora(stara wersja, bez możliwości tworzenia map kolizji): http://www.warsztat.gd/projects.php?x=view&id=779

Pozdrawiam! ;) taki_tam

10
Szkółka / Odp: Delphi czy nadal c++?
« dnia: Lipiec 22, 2009, 01:42:13 »
Cytuj
@taki_tam

Nie popelnilo - bo wczesniej popelnil to C++. Delphi powstalo dopiero w 1995 roku, C++ - 10 lat wczesniej. Podobnie jak Java w tym czasie, Delphi po prostu nauczylo sie na bledach jezyka na ktorym badz co badz po czesci raczej sie wzorowalo.

Spoko, rozumiem. Może masz rację, może nie - dla mnie w karierze Delphi najgorsze co można było stworzyć to TD(Turbo Delphi - strasznie długi czas ładowania, bywały zwiechy po długim kodzeniu i kupa.... :( )

Mówię tak dla tego bo znam Delphi, troszkę mniej C++ i myślę, że mam podstawy by przedstawiać wyższość swoich poglądów.

Co do tematu, chodzi mi tylko o nakierowanie autora tematu, nie tędy droga, by pytać kogoś co jest lepsze. Przykład na mnie, ja doskonale czuję się w Delphi i trudno żebym powiedział że jednak C++ jest bardziej w pytę. Stawia przede mną ogromne możliwości, nic co mi potrzebne nie jest niedostępne, co więcej nie ogranicza mnie.

Pozdrawiam! ;)

11
Szkółka / Odp: Delphi czy nadal c++?
« dnia: Lipiec 22, 2009, 01:07:07 »
Cytuj
ja zobaczyłem pascala to pierwsze nad czym się zacząłem zastanawiać to po co są te "beginy" i "endy"...
Jeśli już to takie uwagi prosiłbym schować(czytaj: zachować dla siebie i przemyśleć). Wg. mni uwaga warta tyle co "kanciate jest 3 razy lepsze niż mniej kanciate...." Sorry... :(

Cytuj
zapominajac ze bez C++ tych jezykow by nie bylo, albo powtorzylyby bledy ktore farciarsko dla nich, popelniono w C++ Smiley

Inny typ myślenia. Nie to że wytykam czy coś ja jako weteran Delphi od wielu wielu lat, Delphi nigdy nie popełniło i nie popełni tych błędów, co więcej nie dąży w strone C++(na szczęście, a przynajmniej dla mnie).

Co najważniejsze wg. mnie w tym temacie: Temat od C++ above Delphi (dowodzi sedna głupoty ludzkiej) jest już założony. Moderatorów prosiłbym o wykasowanie mniej cennych postów.

A co do tematu powiem krótko: O gustach się nie dyskutuje.

Pozdrawiam! ;)

12
Irrlicht / Odp: irrlicht rozróżnianie powierzchni
« dnia: Lipiec 21, 2009, 16:02:09 »
Irrlitch wg. mnie nic do tego nie ma. Trzymaj informacje w poligonach np:

TGround = record
  ...
  iGrountType: Integer;
  ...
end;

Dla GroundType:
1 - trawa
2 - piach
3 - błoto
4 - śnieg

np. w jakiejś tablicy trzymasz wszystkie informacje i do silnika fizyki je przekazujesz.

Pozdrawiam! ;)

13
Szkółka / Odp: Delphi czy nadal c++?
« dnia: Lipiec 21, 2009, 12:54:32 »
Cytuj
Yezus christ! pascal / delphi ssieeeeee. Dłuższe ich używanie prowadzi do sraczki i zawrotów głowy.
Długo myślałeś nad fajnym textem? Nie zaczynaj, nie ten temat, nie ta epoka....

Pozdrawiam! ;)

14
Szkółka / Odp: Delphi czy nadal c++?
« dnia: Lipiec 21, 2009, 12:49:09 »
Soldat + DirectX 8

edit: mój edytor: http://www.warsztat.gd/projects.php?x=view&id=779

Silnik fizyki Phylum 2D, 3D - gadaj ze Spider100 (jego stronka www.spider.dathox.com)

Pozdrawiam! ;)

15
Design / Odp: My own GUI ;P
« dnia: Czerwiec 21, 2009, 16:39:29 »
Cytuj
czy są jakieś przeciwskazania napisania ich w allegro ?

No ale przecież, Allegro to tylko render, który nie powinien mieć nic wspólnego z całym systemem GUI.
Innymi słowy, ja przeciwwskazań nie widzę.

Pozdro! ;)

Strony: [1] 2 3 4 5 ... 8