Autor Wątek: Celowanie - wyznaczanie celu  (Przeczytany 1327 razy)

Offline t4fun

  • Użytkownik

# Maj 31, 2010, 12:30:18
Nie wiem czy w dobrym dziale piszę, ale przejdźmy do rzeczy. Piszę FPP na własnym silniku, i teraz doszedłem do miejsca w którym chcę wyznaczyć obiekty na które wskazuje celownik. Tzn chcę wiedzieć które obiekty podświetlić itp. Najprostsze co mi przychodzi do głowy to wyznaczenie półprostej od kamery i sprawdzanie czy się nie przetnie z jakimś trójkątem w scenie, ale jak tego będzie całkiem dużo na scenie i liczone co klatkę to trochę to może zając. Są już do tego jakieś ogólnie dostępne algorytmy, o co mam zapytać google?

Offline Mr. Spam

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

Offline mihu

  • Użytkownik
    • mihu

# Maj 31, 2010, 12:41:36
Z grubsza rzecz biorąc - tak jak przy normalnych kolizjach. Możesz sprawdzać najpierw czy promień przecina bryły otaczające, a następnie, jeśli potrzebna jest dokładność, geometrię.

Offline Kos

  • Użytkownik
    • kos.gd

  • +1
# Maj 31, 2010, 13:01:39
Słowo kluczowe: picking

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Maj 31, 2010, 13:21:56
Cytuj
Możesz sprawdzać najpierw czy promień przecina bryły otaczające, a następnie, jeśli potrzebna jest dokładność, geometrię.
A jak masz dużo takich brył otaczających, to grupujesz je w kupki i robisz bryły otaczające tych kupek (i tak do skutku, aż zostanie ich garść). W ten sposób dostajesz swobodne drzewo podziału przestrzeni. :)

Offline t4fun

  • Użytkownik

# Maj 31, 2010, 13:35:56
hmmm dzięki za hint z tym picking. Trochę poczytałem i w OpenGL (a w tym piszę) jest niby wsparcie, ale stanowczo doradzają, zalecają color picking, ale jak to łączyć z VBO?
Jeżeli chodzi o pojedyncze obiekty to nie będzie ich dużo, problemem jest teren, bo chce w trybie lornetki/lunety pokazywać odległość do celu. Chyba zrobię z terenu drzewo i leciał tak jak Krzysiek K. pisał

Offline DrUiD

  • Użytkownik
    • HaCra Team

# Maj 31, 2010, 14:24:10
najprosciej wykorzystac silnik fizyczny.. w kazdym masz metody/funkcje do raycast'ingu..

Offline t4fun

  • Użytkownik

# Maj 31, 2010, 14:35:37
W sumie racja i tak planowałem użycie BulletPhysics, widzę że jest coś tam jest: btCollisionWorld::rayTest() i btCollisionWorld::rayTestSingle()

Offline Kos

  • Użytkownik
    • kos.gd

# Maj 31, 2010, 14:43:54
hmmm dzięki za hint z tym picking. Trochę poczytałem i w OpenGL (a w tym piszę) jest niby wsparcie, ale stanowczo doradzają, zalecają color picking, ale jak to łączyć z VBO?

Chyba gładko, nie? Rysujesz samą geometrię z VBO ze stałym kolorem, bez teksturowania czy oświetlenia, ot. Color picking nie jest zły :).

Offline t4fun

  • Użytkownik

# Maj 31, 2010, 14:55:44
hmmm dzięki za hint z tym picking. Trochę poczytałem i w OpenGL (a w tym piszę) jest niby wsparcie, ale stanowczo doradzają, zalecają color picking, ale jak to łączyć z VBO?

Chyba gładko, nie? Rysujesz samą geometrię z VBO ze stałym kolorem, bez teksturowania czy oświetlenia, ot. Color picking nie jest zły :).
No właśnie stały kolor nic mi nie da. Bo oprócz nieba i kilku obiektów zawsze trafię w teren. I dalej nie będę wiedział czy trafiłem w pagórek obok mnie czy 300m dalej. Musiał bym dla każdego trójkąta zmieniać kolor.

Offline counterClockWise

  • Użytkownik

# Maj 31, 2010, 15:04:03
No właśnie stały kolor nic mi nie da. Bo oprócz nieba i kilku obiektów zawsze trafię w teren. I dalej nie będę wiedział czy trafiłem w pagórek obok mnie czy 300m dalej. Musiał bym dla każdego trójkąta zmieniać kolor.

To by fajnie działało z Deferred Rendererem. W jakimś kanale jednego z rendertargetów przechowywałbyś indeks obiektu lub grupy obiektów.

Offline Kos

  • Użytkownik
    • kos.gd

# Maj 31, 2010, 15:07:20
No właśnie stały kolor nic mi nie da. Bo oprócz nieba i kilku obiektów zawsze trafię w teren. I dalej nie będę wiedział czy trafiłem w pagórek obok mnie czy 300m dalej.

Color picking jest doskonały na sytuacje, gdzie zupełnie Ci to odpowiada: "obiekt X vs obiekt Y vs obiekt Z vs żaden obiekt". Całkiem dużo jest takich sytuacji.

Jak chcesz zamiast tego dokładny punkt XYZ, to raycasting. Albo kombinowanie z gluUnProject - też wykonalne.

Offline Dab

  • Redaktor
    • blog

# Maj 31, 2010, 17:08:29
No właśnie stały kolor nic mi nie da. Bo oprócz nieba i kilku obiektów zawsze trafię w teren. I dalej nie będę wiedział czy trafiłem w pagórek obok mnie czy 300m dalej. Musiał bym dla każdego trójkąta zmieniać kolor.

To by fajnie działało z Deferred Rendererem. W jakimś kanale jednego z rendertargetów przechowywałbyś indeks obiektu lub grupy obiektów.

No i w połączeniu z DR miałbyś od razu pozycję i wektor normalny.
Tyle że color/DR picking czy kombinowanie z wyciąganiem XYZ z bufora głębi nie są dobre, jeżeli chcesz sprawdzać takie kolizje w każdej klatce. Odczyt choćby 1 piksela co klatkę skutecznie zabije wydajność.

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Czerwiec 02, 2010, 15:22:49
Cytuj
To by fajnie działało z Deferred Rendererem. W jakimś kanale jednego z rendertargetów przechowywałbyś indeks obiektu lub grupy obiektów.
By nie było fajne. Cały kanał (których w deferredzie jest zawsze za mało) poszedł by na picking, który jest wykorzystywany niezmiernie rzadko (w porównaniu z ilością wywołań pixel shadera).

Cytuj
Color picking jest doskonały na sytuacje, gdzie zupełnie Ci to odpowiada: "obiekt X vs obiekt Y vs obiekt Z vs żaden obiekt". Całkiem dużo jest takich sytuacji.
Pod warunkiem, że piszesz edytor i przyciach wywołany takim pickingiem nie będzie dla Ciebie problemem. W samej grze, jeżeli ma to działać płynnie, color picking jest rozwiązaniem niezbyt dobrym.

W samej grze zdecydowanie najlepszym rozwiązaniem będzie po prostu rzucenie promienia w scenę z wykorzystaniem silnika fizycznego (mają takie rzeczy w standardzie), albo jak ktoś lubi kodować samemu: test przecięcia odcinek-trójkąt ze wsparciem swobodnego drzewa podziału przestrzeni (np. swobodne ósemkowe).