Czego użyć do wizualizacji modelu ramienia robota?

Witam Was!

Chciałbym się zwrócić z prośbą do bardziej doświadczonych kolegów/koleżanek o pomoc w doborze narzędzi/bibliotek do wykonania mojego zadania, a jest nim Zaprojektowanie i wykonanie aplikacji (wraz z GUI) do wczytywania i symulacji ruchów ramienia robota.

Miałoby to wyglądać następująco: mam model robota w jednym z formatów CAD (SolidWorks, Catia, Inventor, Blender), nieważne jakim dopóki uda się go doprowadzić do stanu używalności przez moją aplikację, a następnie wczytuję go, i mam możliwość (poprzez przyciski, klawisze czy zadawanie wartości) symulacji tych ruchów w postaci wizualizacji (użytkownik zadaje ruch - wizualizacja pokazuje go). Z dotychczasowych sugestii skłaniam się ku bibliotece OpenGL i konwertowaniu plików CAD na format .obj ale pisanie loadera plików .obj wydaje się samo w sobie nieco żmudne i zastanawiam się czy nie istnieje jakaś prostsza metoda (a zapewne istnieje) na oprogramowanie symulatora ruchów ramienia robota.
Dodam, że robiliśmy już coś takiego na studiach ale związane to było z robotami mobilnymi i polegało na łączeniu środowiska Matlab z modelem w Catia i LMS Virtual Lab (czy coś takiego), Matlab zadawał prawa ruchu a wizualizacja działa się w środowisku Catia. Miało to dwie główne wady: nie działało (zbyt dobrze) i było trudne do połączenia/opanowania, dlatego chciałbym skupić się na czymś innym. Znam środowisko Visual Studio i język C# oraz VB.NET dlatego fajnie byłoby znaleźć rozwiązanie oparte właśnie o nie.

Czy ktoś z Was zajmował się czymś podobnym lub ma wiedzę/pomysł na to jak ugryźć temat? Może ktoś ma doświadczenia z wizualizacjami ruchów? Na dobrą sprawę problem sprowadza się do wczytania modelu robota i poruszaniu jego elementami w złączach (a będą to ruchy zazwyczaj obrotowe wokół danego środka obrotu z zachowaniem wiązań pomiędzy przegubami ale to inny temat).

Czekam na Wasze pomysły i rady. Każda wskazówka mile widziana. Mam nadzieję, że wątek się rozwinie :)

peeteerq

Pisanie loadera plików wavefront obj to chwila roboty (zwłaszcza, że nie potrzebujesz pełnego loadera, bo możesz go ograniczyć do samych trójkątów, wektorów normalnych i ewentualnie współrzędnych nakładania tekstur. Czyli w obj bierzesz linijki z nagłówkami v, vn i vt oraz f (wskazuje on na indeksy v, vn i vt wierzchołków, które tworzą face - trójkąt). Także żmudne to nie jest :) Wystarczy się dowiedzieć jak zbudowany jest ten plik, napisać loader i w OpenGL napisać wyświetlanie.

W Unity 3D możesz za to wczytywać modele bezpośrednio z pliku Blendera. Wizualizację ruchów możesz ugryźć na dwojaki sposób. Napisać sobie skrypty w C#, które zmieniają rotację poszczególnych elementów. Albo zaprzęgnąć do pracy animatora (taka funkcjonalność w Unity) i stworzyć animacje dla robota w edytorze.

Spine, czyli uważasz, że wczytanie mojego modelu powinno odbywać się przy użyciu formatu .obj i dalej tworzyć skrypt (np. C#) poruszający poszczególnymi częściami robota przy wykorzystaniu OpenGL ? To jest najbardziej optymalny sposób robienia takich rzeczy? Fakt, że robot składa się z kilku(-nastu?) części na pewno komplikuje całe zagadnienie ale myślisz, że uda się to tak ogarnąć?

W OpenGL po prostu składasz przekształcenia macierzowe i ilość części nie ma znaczenia.

1) translacja podstawki ramienia.
2) rotacja podstawki ramienia.
3) rysowanie podstawki ramienia.
4) translacja części ramienia względem podstawki.
5) rotacja części ramienia względem podstawki.
6) rysowanie części ramienia.
7) translacja drugiej części ramienia względem pierwszej części ramienia.
8) rotacja drugiej części ramienia względem pierwszej części ramienia.
9) rysowanie drugiej części ramienia.

To wszystko bez resetowania macierzy, chyba, że gdzieś po drodze chcesz dodać inną część robota, niezależną od poprzednich przekształceń.

W Unity 3D musisz odpowiednio poukładać hierarchię obiektów i również ilość części nie ma znaczenia.

Ogólnie
Model możesz wczytać z *.obj, jednakże musisz go sobie podzielić na części - także będziesz miał kilka plików *.obj. Ważny jest punkt obrotu (pivot, punkt 0,0 obiektu), żeby był odpowiednio zorientowany, bo wokół tego właśnie punktu będzie obracać się dana część robota.