Discussion :

[omlip]

Bonjour tout le monde,
1) Dans le cadre d'un exercice, nous(2 personnes) devons réaliser un petit moteur 3D afin de visualiser une scène avec quelques objets...

comme le dit cet article,
http://loulou.developpez.com/tutoriels/jeux_video/
, mieux vaut commencer par un langage que l'on connait déjà ==> java

Alors voilà, je voulais avoir l'opinion de gens qui avaient déja touché à java dans le monde de la 3D?

2) En deuxième question, j'ai regardé du coté d'OpenGl ==> JOGL (Java bindings for OpenGL)

Mais on se rend vite compte que la javadoc n'est pas vraiment synchro avec l'api (exemples : des fonctions décrites dans la doc mais qui ne sont pas dispo dans l'API)

Alors avant de s'embarquer, est-ce que ce genre de soucis n'est pas déjà compromettant pour tout type de projet?????????

Comprenez que l'on a pas envie de s'embarquer dans un truc où c'est mal documenté etc...

JOGL n'est-il pas assez mûr pour ce genre de travail?


Voilà merci d'avance de vos conseils

N'hésitez pas à poser des questions pour plus de renseignements ou un éclaircicement de la chose.

A+
oli

[bafman]

1. effectivement, si tu connais java, fait ton moteur en java... le principal dans on moteur 3D etant surtout l'architecture et les differents algorithme de partitionnement utilisé, il est nettement preferable de le faire dans son langage préféré (bon OK tu ne refera pas Doom 3 en java, mais si tu sait programmer, tu peut en tirer des perfs nettement suffisantes )
2. Pour JOGL, j'avais essayé il y a quelques temps, et effectivement, la doc n'est pas parfaitement à jour, mais etant donné que ca concerne principalement les entré/sortie/fenetrage, ca ne pose pas tant de probleme que ca, une fois que tu aura reussi à afficher une fenetre openGL et à capturer les entrée/sortie clavier et souris, tout ca qui concerne l'affichage est de l'openGL, et tu trouvera donc toutes les info necessaires sur le net (generalement en C/C++, mais ca s'adapte sans probleme au java vu que ce sont les même fonctions qui sont appelé )

[omlip]

(bon OK tu ne refera pas Doom 3 en java, mais si tu sait programmer, tu peut en tirer des perfs nettement suffisantes )

Ce n'est pas mon but ici mais pourquoi pas ??? qu'est-ce qui empecherai de faire un Doom 3 en java? si c'est de l'opengl derrière?



En effet pour JOGL, yapluka comme on dit mais bon, justement je suis arrivé sur ce genre de pépin et je trouve pas... Mon problème se situait non pas à comment cpater les évenements pour cela j'utilise l'api java mais comment à redéfinir le contexte opengl afin de faire de l'affichage

Ex: voir les didacticiels de linuxgraphic.org


voilà a+
omlip

[Laurent Gomila]

Est-ce que tu as consulté ce tutoriel ?
http://info-rital.developpez.com/tutoriel/java/api/3d/

Peut-être pourra-t-il répondre à certaines de tes question, ou t'aider à t'orienter.

[omlip]

oui je l'ai lu
c'est justement grâce à lui que jai porté mon choix sur JOGL...

Mais voilà, du fait que la doc soit pas à jour, c'est assez embêtant... le fait que ce soit pas a jour, il est difficile de réaliser certaines choses comme rendre le contexte OpenGl pour le thread qui s'éxécute

fin bref

Je vais essayer LWJGL pour voir ce que ca donne

Au fait, si Java n'est pas plus lent, pourquoi on ne pourrait pas faire un Doom 3 ???

A+
omlip

[plegat]

Mais voilà, du fait que la doc soit pas à jour, c'est assez embêtant... le fait que ce soit pas a jour, il est difficile de réaliser certaines choses comme rendre le contexte OpenGl pour le thread qui s'éxécute

C'est quel style de doc qui n'est pas à jour?
Si c'est tous les tuto qui trainent sur le net, c'est normal... la toute dernière version de JOGL a tout remanié par rapport aux précédentes, donc il va falloir un peu de temps pour remettre ça d'aplomb. Mais rien ne t'empêche de prendre une version précédente (genre la 1.1) pour t'initier. Ensuite, il n'y a que peu de changements pour adapter le code pour la JSR-231... enfin... peu... ça dépend...

J'ai une grosse appli qui tourne avec JOGL, en version 1.1. Dès que la JSR-231 passe en release, j'adapterai le code. Mais pour l'instant, je reste avec l'ancienne, et je n'ai aucun problème de documentation, j'arrive toujours à trouver une réponse sur le net.

[omlip]

wow wow que de réponses intéréssantes

moi j'utilise la dernière version et c'est la javadoc qui est pas à jour mais si maintenant l'API subit un grand bouleversement, c'est peut-être pour cela que c'est pas évident de développer avec

heu comment se fournir la version 1.1 et surtout la doc et javadoc concernant cette version

Et quand sort la jsr-231 ???

A+
omlip

PS: peut-être devrais je ouvrir un autre sujet??? non?

[plegat]

Pour la version 1.1, c'était pas très loin de là où tu as dû récupérer la dernière:

https://jogl.dev.java.net/servlets/P...&folderID=2771

Quant à la date de la sortie de la version stable... aucune idée!

[omlip]

OK OK moi apparemment j'ai pris une beta de avril 2006...

je vais essayer en prenant la version 1.1 et que ainsi je n'aurai plus de problèmes

Merci à tous de vos réponses


Au fait pkoi pas de Doom3?

[plegat]

Doom3?

Pourquoi pas... Je me demande si ça n'a pas déjà été fait en plus... Je me souviens avoir récupéré un doom-like en java, mais je ne me souviens plus du nom exact... Je vais essayer de récupérer l'info...

Mais c'est largement faisable. Il n'y avait aucun soucis de vitesse (depuis le temps que l'on dit que java est potentiellement aussi rapide que les langages natifs... on va bien finir par se faire entendre! )

[omlip]

OKy


heu tu est sur que la javadoc de la 1.1 est a jour???

[plegat]

heu tu est sur que la javadoc de la 1.1 est a jour???

Pour ce que j'ai eu besoin d'y chercher, oui. Après...

Si tu précisais ce que tu cherches, ça serait plus facile...

Sinon, doom3, peut-être pas... mais quake3, ça oui. Le 2 a été adapté en Java, ça s'appelle Jake2, et c'est dispo ici: http://www.bytonic.de/html/jake2.html

Avec quelques screenshots: http://www.bytonic.de/html/screenshots.html

[omlip]

Hello,

( super le jae2 je vais essayer sinon le jeu Chrome aussi a ete fait en java)
bref passons

En fait mon soucis est...

Tu es d'accord avec moi que JOGL s'executent dans un mode multi thread de par l'existence de awt ou swing etc...
(Thread pour la gestion clavier, souris etc...)

De par ce fait lorsque je veux utiliser des méthodes issues de Jogl dans des méthodes des gestion de clavier par exemple je n'ai pas de contexte opengl sur ce thread (cfr GLContext)

Ma question est comment avoir le contexte afin de pouvoir faire appel aux fonctions OpenGL

voila j'espere que je suis cler???

[plegat]

Je ne suis pas un gros expert de Jogl, donc je ne suis pas sûr de bien comprendre ta question... Pour l'instant, je me limite à tracer des lignes et des triangles! (il y a mon site en lien si tu veux voir ce que je fais exactement... pas trop à jour, j'utilisais encore Java3D à l'époque!).

Pour ce qui est du GLContext, si j'ai tout bien suivi, c'est un concept qui n'apparait qu'avec la JSR-231, donc vu que j'en suis resté à l'âge du bronze, je ne m'en suis jamais servi.

Pour la gestion du clavier (et en général tout ce qui est interaction utilisateur), j'ai laissé ça du côté AWT/Swing (je sais, j'ai mélangé, c'est mal, mais c'est MON programme!). J'ai deux classes, en gros, une pour le GUI général, qui gère toutes les interactions (actions clavier, menu, etc), et une autre pour le GLCanvas OpenGL, qui s'occupe de gérer tout ce qui est OpenGL (ça doit être l'équivalent du GLContext), et les deux s'échangent les infos.

Après, ta question est peut-être plus pointue que ça...

[omlip]

ça l'air intéréssant ce que tu fais

en fait pour en revenir au GLContext, j'ai posté également un message que javagaming.org

et la on m'a conseillé de faire autrement:
je vais essayer d'expliquer clairement le problème et sa solution

Situation : Je rappelle que le but etait de modifier le type d'affichage en appuyant sur une touche
Pour gérer la touche, je crée une classe qui implémente KeyListener.

Base:
Pour faire du JOGL (comprendre par là de l'OpenGL en Java), on utilise un composant appelé GLCanvas ou GLJPanel.
A ce composant, on doit lui fournir une implémentation de GLEventListener qui va nous permettre par l'intémédiaire d'un GLDrawable, d'obtenir un contexte OpenGl afin de pouvoir dessiner sur le composant et faire appels aux fonctions OpenGl classiques

Mon idée mais qui est pas la bonne apparemment:
etait de trouver un moyen de récupérer le contexte OpenGL dans les méthodes de gestion de touches afin de changer le mode d'affichage


Solution: Passer par l'intermédiare de variables d'instances pour contrôler l'affichage


voila je sais pas si je suis clair mais j'espere que si quelqu'un a le même soucis, que ceci puisse l'aider

A+++
omlip

[plegat]

Solution: Passer par l'intermédiare de variables d'instances pour contrôler l'affichage

ouaip, c'est plus ou moins la méthode que j'ai utilisée.
Le GLEventListener ne te permet pas de gérer les touches, juste l'affichage, le redimensionnement, etc... Il te faut utiliser encore un KeyListener, un MouseListener.... pour gérer le reste des interactions.

A chaque évènement clavier ou souris, tu modifies des flags (instances de ta classe qui gère la 3D OpenGL) pour indiquer dans quelle configuration tu te trouves (mode filaire, rendu 3D, rendu texturé...), et tu utilises ces flags dans ta procédure display pour afficher ta 3d en conséquence.
Enfin, c'est comme ça que j'ai fait...

Je crois que Gfx utilises pas mal Jogl, il devrait pouvoir te donner plus d'infos quand il rentrera de week-end!

[omlip]

ouais c'est exactement ca

Merde suis vraiment null pour expliquer

j'ai fait comme cela aussi...

oky, merci bien de tes conseils

A+ omlip

[omlip]

Tenez voici un lien très intéressant...
faut lire le pdf sur jogl

c'est très instructif

http://fivedots.coe.psu.ac.th/~ad/jg/jogl1/index.html



A+++
oli