Autor Wątek: Własny silnik fizyczny - podstawy  (Przeczytany 4938 razy)

Offline MatlertheGreat

  • Użytkownik

# Grudzień 13, 2012, 21:19:31
Witam,
Ostatnio zainteresowałem się fizyką i jej działaniem w programach. Postanowiłem napisać prosty silnik fizyczny, obliczający podstawowe siły. Z implementacją fizyki do kodu miałem jedynie styczność przy animowaniu kamery (zwyczajne przyspieszanie i zwalnianie). Nadszedł jednak czas na coś bardziej wymagającego.
I tu pojawia się problem. A mianowicie, jeżeli chcę operować na wielu obiektach w 3 wymiarach, każdy może być nieregularny; czy powinienem stworzyć dla każdego obiektu osobny dynamic vertex buffer i fizycznie zmieniać położenie wierzchołków w razie potrzeb, czy może stworzyć sobie kopię modelu z wektorów, na nich pracować, a później wyliczyć odpowiednie matrix'y i wykorzystać je w shaderach? A może powinienem inaczej to zrobić?

Dla ścisłości programuję w c++, używając DirectX 11.

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline Santor

  • Użytkownik

# Grudzień 13, 2012, 22:39:55
Taka moja propozycja, stwórz sobie klase odpowiedzialną za fizyke i dziedzicz ją w wszystkich obiektach które są z fizyką  związane. Metodami modyfikuj za pomocą różnych sił wektor przesuniecia obiektu.

Offline Kuba D.

  • Użytkownik

  • +3
# Grudzień 13, 2012, 22:49:32
W większości silników fizycznych wizualizacja jest oddzielona od fizycznej reprezentacji obiektu ( czyli operujesz na dwóch zestawach danych - jeden do fizyki a drugi do renderingu), przy czym przeważnie obiekt fizyczny nie jest dokładnym odzwierciedleniem tego renderowanego ( jest to mniej lub bardziej uproszczona siatka lub zestaw brył najlepiej opisujących w przybliżeniu kształt).

W skrócie silnik fizyczny dostaje obiekt który ma być poddany fizyce a zwraca macierz przekształceń ( której używasz podczas renderowania obiektu we właściwym położeniu i orientacji).
Oczywiście mówimy tutaj tylko i wyłącznie o fizyce ciał sztywnych - czyli tej prostszej ;).

Offline koirat

  • Użytkownik

  • +5
# Grudzień 14, 2012, 01:29:19
@MatlertheGreat Najpierw pobaw się jakimiś gotowymi silnikami, zobaczysz o co biega.
A jak już się pobawisz to odechce ci się tworzenie własnego.

Offline Witek9002

  • Użytkownik

# Grudzień 14, 2012, 02:15:50
czy powinienem stworzyć dla każdego obiektu osobny dynamic vertex buffer i fizycznie zmieniać położenie wierzchołków w razie potrzeb, czy może stworzyć sobie kopię modelu z wektorów, na nich pracować, a później wyliczyć odpowiednie matrix'y i wykorzystać je w shaderach? A może powinienem inaczej to zrobić?
Dla ścisłości programuję w c++, używając DirectX 11.
A co ma silnik fizyki do API graficznego?

Offline MatlertheGreat

  • Użytkownik

# Grudzień 14, 2012, 16:53:34
A co ma silnik fizyki do API graficznego?

Chyba głównym celem aplikacji jest wyświetlanie efektów pracy na ekranie więc sądzę, że w gotowym projekcie wszystko ma mniejszy czy większy związek z grafiką.

Offline st3tc

  • Użytkownik

  • +3
# Grudzień 15, 2012, 01:57:14
Poszukaj na początek pozycji:
"Game Physics Engine Development", autor: Ian Millington  (obowiązkowa)
"Real Time Collision Detection", autor:  Christer Ericson ( a co tam - też obowiązkowa)

Będziesz miał nie tylko pogląd na problemy związane z tworzeniem silników fizycznych ale i będziesz w stanie napisać swój własny całkiem zgrabny silnik, choć będzie to wymagało nieco zacięcia i determinacji :)
(do havoka itp będzie mu wciąż bardzo daleko - ale od czegoś trzeba zacząć :) )

« Ostatnia zmiana: Grudzień 15, 2012, 02:02:05 wysłana przez st3tc »

Offline MatlertheGreat

  • Użytkownik

# Grudzień 15, 2012, 14:28:31
Poszukaj na początek pozycji:
"Game Physics Engine Development", autor: Ian Millington  (obowiązkowa)
"Real Time Collision Detection", autor:  Christer Ericson ( a co tam - też obowiązkowa)

Ok, biorę się do nauki. Dzięki za zainteresowanie