[java] gry 3d

Witam,

od jakiegoś czasu robię gry i aplikacje 2d w javie. Chciałbym teraz zmajstrować coś większego (chodzi o grę 3d). Niestety nie wiem jak zacząć dlatego czy możecie mnie oświecić jak i w czym robić gry java?

Zaznaczam tu że biblioteka 3d powinna być w miarę popularna gdyż jeżeli uda mi się coś zrobić na kompa może pokuszę się na inne urządzenia, a słyszałem że DirectX działa tylko na “Windzie”.

Chciałbym też spytać czy obiekty 3d do gry można zrobić w specjalnym programie (np.: blender) ,który wygeneruje mi kod do “wyrysowania” obiektu czy wszystko trzeba “klepać” ręcznie.

Byłbym wdzięczny za polecenie jakichś dobrych tutorialów.

pozdrawiam

Możesz, jest coś takiego jak java monkey engine czy jakoś tak.

Ten Monkey engine wygląda fajnie ale czy on zadziała na innych urządzeniach chociażby na Androidzie? Na linuxie będzie chodzić czy tylko na windowsie?

A jeżeli chodzi o resztę moich pytan? ^^

Dodane 15.05.2011 (N) 17:53

uprzedzam z góry że nie chodzi mi o super wybajerowane graficznie gry. Zadowolą mnie sześciany :smiley: Byle by dało się coś zrobić

OpenGL jest obsługiwane przez wszystkie możliwe platformy z akceleracją grafiki (może poza xpudłem, nie jestem pewien czy M$ łaskawie zamontował w swojej konsoli najpowszechniejszą bibliotekę graficzną)

http://www.droidnova.com/android-3d-gam … i,312.html

Na PCty możesz użyć biblioteki j3d. Jest pod całą trójcę i jeszcze jakieś (solaris chyba).

Kod musiałbyś jednak modyfikować, bo programowanie na systemy osadzone, a pctowe się trochę różni

JMonkeyEngine ma dość wysokie wymagania, chciałem się w nim pobawić, ale linuksowy sterownik radeon (fglrx nie jest dla mojej karty wspierany już) nie wydalał OGLa 2.0 i Shaderów 3.0, zobaczę jak teraz na Gallium3D.

a co do mojego pytania o to czy grafike do gry 3d mozna robic np. w blenderze to mozna?

zakladam tu ze bede robil gre w open gl gdyz jak kolega wyzej mowil jest on najpopularniejszy

może nie “najpopularniejszy”, ale “najpowszechniejszy” (więc jego znajomość jest najbardziej opłacalna i przyszłościowa).

Możesz zrobić w blenderze, ułożyć siatki UV, normalne, potem wyeksportować do np. OBJ i napisać importera takich siatek (i materiałów) do OpenGLa. Ten format do trudnych nie należy, nie jest binarny, tylko tekstowy.

Ewentualnie możesz samemu napisać własnego eksportera do blendera w Pythonie do takiego formatu jaki ci pasuje.

BTW. JMonkeyEngine na Gallium działa bezproblemowo:D

mam ostatnie pytanie:

czy ogólnie używanie opengl’a (funkcje itp.) w C++ bardzo różnią się od javy? Znalazłem tutorial C++ tylko nie wiem czy pomoże mi on to sam zrobić w javie :?

I jakie biblioteki open gl trzeba ściągnąć dla javy? Mają konkretną nazwę?

Dla zainteresowanych grafiką 3d:

http://www.dreddi.net/?s=dev&p=2

Pozdrawiam

W Javie musisz się odwołać do funkcji OpenGLa poprzez obiekt, zazwyczaj gl (w tym tutku co dałem link jest to pokazane). Potrzebujesz z tego co wiem tylko SDK do Androida. Jak będziesz miał SDK do Androida to IDE wyświetli ci wszystkie dostępne metody po odwołaniu się do tego obiektu.

Wszystkie funkcje raczej działają tak samo. Różnica jest taka, że na PC jest OpenGL, a na Androidzie jest OpenGL ES, trochę okrojony, ale problemów mieć nie powinieneś.

Nie, nie potrzebujesz SDK Androida(jeśli nie piszesz na Androida), potrzebujesz bindingu/wrappera OpenGL, renderera lub całego silnika. Niestety nie znam i nie używam Javy, ale z tego co wiem to istnieje kilka: JOGL, jMonkeyEngine, Ogre4j(port Ogre3D), Jirr(port Irrlichta). Z tego co wiem żaden nie jest przenośny na inne platformy niż PC(prosta przyczyna: wszędzie indziej jest OpenGL ES).

Sprzeczałbym się. Po czym wnosisz, że OpenGL jest “najpowszechniejszy”(vide karty Intela, na których jest marne wsparcie OGL-a)? Windows ma większość rynku, więc tak szczerze powiedziawszy wielu potencjalnych odbiorców nie tracimy. Konsol nie liczymy, bo tylko na XBox-a jesteśmy(my, w sensie osoby nie mające produktu i kasy na devkit) w stanie coś napisać, ale tylko XNA-only. Dodatkowo nawet Carmac stwierdził, że OpenGL jest teraz w tyle za Direct3D.

Dodatkowo przy portowaniu gier na konsole czy też komórki renderer jest najmniejszym problemem(to nie jest moje doświadczenie, a zdanie ciut bardziej doświadczonych ode mnie). :wink:

OpenGL:

  • Windows

  • Linux

  • Mac

  • Solaris

  • BSD

  • PlayStation 1/2/3 (no i kolejne nextgeny sony)

  • Wii (no i kolejne nextgeny nintendo)

  • SymbianOS

  • BadaOS

  • Android

  • Windows Mobile

DirectX:

  • Windows

  • Xbox’y

  • Windows mobile

Po co pisać w DX i mieć w garści jedynie windowsy i xpudła, skoro można pisać w “nieco gorszym” OpenGLu i mieć w garści wszystkie platformy ze wsparciem akceleracji? Tym bardziej że Android ma spore udziały w telefonach, a potrex chce właśnie gierkę która będzie działać zarówno na PCtach jak i Androidzie?

Porównując najnowszego DXa a OGLa, to jedyne różnice jakie można zauważyć to inaczej napisane shadery.

Sama Java nie daje wsparcia dla OGL, oferują je dopiero biblioteki (np. JOGL), czy też silniki graficzne (irrlicht, ogre), które odwołują się do natywnych bibliotek.

O te SDK dla androida to oczywiście miałem na myśli że jeśli chce pisać pod androida

Windows Mobile(a tym bardziej Windows Phone) nie ma sprzętowego wspierania OpenGL, to jest tylko swego rodzaju “nakładka” na Direct3D. Na Wii ani na PS nie ma OpenGL ES - są to ich odmiany, które są podobne do niego, ale nie są z nim identyczne.

I będę się powtarzać: nie-Windowsy mają ZNIKOMY udział na PC, a pisanie gier na telefony jest “trochę” odmienne od tego na PC i sam podsystem renderujący jest tu niewielką ich częścią. Nie, nie mówię, że nie warto się uczyć OpenGL, ale trzeba przemyśleć, co wziąć pierwsze(sam skrobię od czasu do czasu w OpenGL, Direct3D znam tylko minimalnie). Bo warto znać oba API(ale jeszcze bardziej warto znać teorię). :wink:

Bardziej do autora: najpierw napisz grę na jedną platformę, naucz się pisać gry, dopiero próbuj je portować - to nie jest takie proste jak się może wydawać, naprawdę.

Różnicą nie są “inaczej napisane shadery”, różnic jest wiele więcej. Począwszy od dziwacznie zbudowanego API(ni to obiektowe, ni to nieobiektowe), a co za tym idzie odmiennej filozofii pisania, niezbyt udolnego wsparcia przez producentów kart graf.(Intel w szczególności, do nie tak dawna ATI również), różnice w sterownikach, różnice w obsłudze niektórych featurów na różnych kartach(szczególnie różnych producentów), mnogość rozszerzeń(poprawiło się to w wersji 4.0), brak “zintegrowanej” biblioteki matematycznej(patrz: XNA Math czy też starsze części D3DX).