Discussion :

[eclesia]

Bonsoir,

Je viens profiter une fois encore de vos conaissances en moteur3D.

J'ai réalisé il y a peu mon premier logiciel utilisant OpenGL, (cf : http://img84.imageshack.us/img84/5156/visualdemiw0.jpg )
suivant les conseils j'ai amélioré basiquement mon moteur ( sujet sur l'amelioration des mt).



Il y a beaucoup de travail pour faire un moteur3D, je ne suis pas encore un autre utopiste, d'autant que pour mon travail ce n'est pas necessaire. , je suis bien conscient du travail et du temps que ca implique.


l'objectif :
Faire un moteur de visualisation de carte en 3D portable sous Linux/Windows/Mac/Solaris et sur GPS/PDA (avec une JME).


Voila ce que je sais de ce que je compte realiser:
- basé uniquement sur OpenGL (donc pas de structure abstraite DirectX/OpenGL comment j'en vois dans les tutos)
- Entierement Orienté Objet
- chargement de texture enorme (imaginez 2 ou 3 tif de 140Mo dans le pire cas)
- pas de limite de portée de vue
- une ou deux lumiere dans un premier temps
- la possibilité de mettre en pause le rendu
- lire un format basic d'objet 3D (.obj le plus simple je crois)
- le picking avec la souris

- pas de gestion de collision
- Pas d'effet dernier cri, (pas de bloom, de pump mapping ...etc... je n'ai pas l'utilité de tout ca)


Les outils a disposition :
- En Java
- JOGL (OpenGL pour java, meme fonctionnement que n'importe quel langage)
- PlateForme netbeans (je ne crois pas que ca change quelque chose, enfin bref on sait jamais)


Mes connaissances :
A ce niveau la, je me debrouille, j'ai 2ans de java derriere moi, je commence a mieux cerner OpenGL, le calcul de coordonnées n'est pas un soucis (je travail dans la carthographie, SIG). La on je suis debutant, c'est la structure, les performances au niveau 3D.



En bref :
Ce que j'aimerai, c'est un coup de pouce pour m'aider a definir une structure Objet pour le moteur, les interfaces,...etc... de maniere a ne pas avoir de grosse lacune par la suite a la realisation.


Je mettrai des liens vers des diagrammes de classes au fur a mesure que la structure evoluera.

merci

[eclesia]

voila a quoi ressemble le moteur pour le moment :
http://jsorel.developpez.com/temp/jsl3d.jpg

ma pratique de l'UML est un peu rouillé, merci d'etre indulgent

[ash.ice.loky]

En fait il faut faire la difference entre le moteur 3D (de rendu) et le logiciel.
C'e n'est pas pareil.

Pour faire de tel chose un moteur simple suffit (pas de lumiere, d'anim, d'optimisation ou de texture speciales, ...).

Le loader de texture ou de model est différent du moteur.
Tu peux tres bien couplé un loader X avec un moteur Y, ainsi tu remplaces ou modifis une partie sans tout mettre en l'air.

Pour le loader, un simple Get et Set peut servir pour commencer.

Pour le moteur c'est un peu plus compliquer, il faut déterminer avec précision ce que tu souhaites obtenir.

[broumbroum]

Salut! TEchniquement la structure des Objects en Java doit pouvoir être Serializable pour assurer les transferts par Streaming. Surtout si l'application est du Temps Réel ou de l'animation virtuelle.
C'est pourquoi j'ai parcouru plusieurs fils de discussion pour créer un gestionnaire de cache mémoire qui intègre le Streaming des données OO vers le systeme de fichiers et la mémoire vive. Actuellement les applications Java telles que l'IDE Netbeans ou les logiciels de retouche d'image de Kodak ou le MPEG-4 d'IBM implémentent un SoftCache. Par extension, j'ai développé le mien, destiné à l'animation 2D pour le jeu. disponible sur DVP.com en contribution Java

Il est continuellement mis à jour sur mon serveur Sourceforge.net.

[eclesia]

la structure des Objects en Java doit pouvoir être Serializable pour assurer les transferts par Streaming

Je ne comprend pas le rapport sauf si tu parle de la sauvegarde d'objet. Le but n'est pas de serializer et stocker dans un fichier une instance de classe, mais de pouvoir faire un modele (avec blender ou autre) et de l'importer dans le moteur.

Pour le moteur c'est un peu plus compliquer, il faut déterminer avec précision ce que tu souhaites obtenir.

l'ennui est que je ne connais pas suffisament openGL (les fonctions, les limites) pour pouvoir definir precisement ce que je veux.
Un rendu basique, une/deux lumiere, je n'ai rien a faire des effets visuels.

[broumbroum]

c'est pas le forum Java? non, mais en fait c'est un peu pareil, si les modèles sont lourds, alors il est évident de pouvoir les stocker sur disque une fois codés et chargés en mémoire vive. voilà. A partir de là, je ne peux pas te dire s'il y a effectivement un rapport avec le moteur...

[ash.ice.loky]

OpenGL n'a pas "techniquement" de limites autres que celles imposées par ta carte graphique (et son pilote surtou lol)

OpenGL ne fait QUE du rendu, rien d'autre, les colisions, les loader, les IO, ... tout ca il ne connais pas.

Maintenant a toi de voir ce que ton moteur doit faire.

Par exemple pour un moteur de jeu de type zelda les primitives seront du type :
DisplayTiles (x, y, tile * name)

dans ton cas tu semble peu interressé par beaucoup de possibilité d'opengl.

il faut que tu sache ce que ton affichage va comprendre et alors tu pourras déterminer tes methodes.

Par exemple tu peux commencer par faire la chose suivante :

Begin () ; // debut du rendu d'UNE scene
End () ; // fin de ce rendu

puis tu créés une methode qui fait une figure ou affiche un model.
et tu l'utilise entre begin et end.

moteur3D.Begin () ;
moteur3D.Display (Model truc , x , y , z) ;
moteur3D.Display (Model machin , a , b ,c) ;
moteur3D.End () ;

Le souci est que l'on ne peut pas te faire ton interface si on ne sais pas ce que tu veux en faire.

[TataJanette]

Voila ce que je sais de ce que je compte realiser:
- basé uniquement sur OpenGL (donc pas de structure abstraite DirectX/OpenGL comment j'en vois dans les tutos)
- Entierement Orienté Objet
- chargement de texture enorme (imaginez 2 ou 3 tif de 140Mo dans le pire cas)
- pas de limite de portée de vue
- une ou deux lumiere dans un premier temps
- la possibilité de mettre en pause le rendu
- lire un format basic d'objet 3D (.obj le plus simple je crois)
- le picking avec la souris

Bon, les difficultés que j'entrevois:

- Dessiner du terrain sans "limite de portée de vue" est un peu utopique. Tu vas forcément limiter le champ de vision (frustum) et il est alors intéressant de n'envoyer à la carte graphique que la partie visible. Donc tu devrais étudier des structures de culling (détermination des polygones visibles), comme par exemple un Quadtree ou un Octree ainsi que le basique "Frustum culling". Evite les BSP (Binary Space Patritionning) ou les "portals" qui ne sont moins adaptés pour les scènes extérieures. Pour tes objets, tu dois envisager des boîtes englobantes (spheres ou Axis Aligned Bounding box), afin de te permettre de tester rapidement si ça vaut le coup de les dessiner.

- Les textures en OpenGL sont limitées à 4096x4096 pixels, donc à toi de jongler ... Tu dois réfléchir comment gérer les textures, subdiviser ton terrain et/ou faire du streaming de textures ... Un moteur 3D comme OpenSceneGraph fait ce genre de chose il me semble (et il est opensource, cf. www.openscenegraph.com ). En particulier il utilise l'excellente librairie GDAL pour tout ce qui est chargement de textures GIS. Même si ce n'est pas Java ça peut t'inspirer.

- Pour les objets 3d regarde du côté de 3DS, parce que tous les graphistes le connaissent ou bien un gratuit comme sketchup

[ash.ice.loky]

Alors la, si il y a bien un format que je deconseil c'est le 3DS, il est compliqué a souhait par rapport a d'autre tel que Collada ou Obj (si les besoins sont rudimentaires).

[TataJanette]

Tu devrais aussi aller voir du côté de vterrain, en particulier ici: http://www.vterrain.org/LargeTextures/index.html et ici: http://www.vterrain.org/Textures/ground_textures.html

[eclesia]

merci des complements.
il y a du boulot en prévision.

[eclesia]

Ca avance, je commence a avoir un premier apercu de mes cartes.
(les polygones, polylignes, ponctuels pas les textures pour le moment)


Question de performance :

Je me demande si une forte structure object à une influence sur les performances?

je detail ma pensée : faut il accorder la priorité à une structure purement objet avec de multiples classes et de grande quantité d'appelle a des methodes (feature.getPoly(i).recoverStruture().generate....etc....), ou faut il mieux regrouper au meme niveau dans une classe un maximum de données quitte a perdre de la memoire en repetant des données?

[ash.ice.loky]

OUI tu as de la perte avec l'objet et
NON cela n'influence pas significativement les performances

Ensuite choisir un langage objet pour faire du fonctionnel n'est pas d'un grand interet.

Pour ton probleme c'est en effet le souci de l'objet, définir un niveau d'abstraction suffisant de facon a ne pas devoir répéter des appels incompréhensible sur 3 lignes.

Revois peut-etre ta conception.

[eclesia]

définir un niveau d'abstraction suffisant

Revois peut-etre ta conception.

j'essai justement de trouver une juste valeur d'abstraction.

je suis en train de me tourner vers la solution du pré-calculé. je vais garder un bonne structure object et prevoir une methode pour "compacter" la partie 3D, de facon a ne plus avoir de calcul mais uniquement avoir a dessiner les vertex.

[LeGreg]

OUI tu as de la perte avec l'objet et
NON cela n'influence pas significativement les performances

En fait si. Mais ce qui cause des pertes de performance ce n'est pas "la programmation objet" en elle-meme. Un langage objet va juste rendre la compilation plus compliquée (et donc potentiellement moins performante sur quelques points chauds) mais devrait permettre d'exprimer plus de chose plus rapidement (ce qui laissera du temps pour optimiser les points chauds à la mano et surtout permettra de finir le projet en temps et heure).

Par contre ce qui cause souvent la baisse de perf c'est l'inadéquation de l'abstraction proposée avec le mode de fonctionnement du projet (rendre rapide les appels peu utilisés et rendre lents les appels beaucoup utilisés) et du matériel sous-jacent.

Donc à ne pas faire :
- définir une abstraction en comité, basée sur des principes trop haut niveau.

Exemple de mauvais design :
je veux faire un jeu en 2D qui trace des sprites sur l'écran en VGA. Comme j'ai un peu étudié je sais qu'il faut etre extensible et donc que mon jeu doit pouvoir tourner sur tout format d'écran, 8 bits palettisé, 16 bits r5g6b5, 32 bits argb8 etc. Donc je vais créer une interface IPixel, avec des methodes virtuelles pour écrire un pixel. Conclusion pour chaque pixel écrit à l'ecran je vais faire appel à une fonction virtuelle qui m'assurera que mon jeu pourra s'adapter au futur des nouveaux formats d'écran..

Bien entendu c'est un peu caricatural mais c'est pousser l'idée que tout doit être objet ou que l'encapsulation et l'extensibilité prime sur tout.

Pour ce qui est de la duplication de données, il faut toujours être circonspect avec ces méthodes, parce que ce qui plombe beaucoup de jeux modernes c'est l'empreinte mémoire justement. Et l'optimisation prématurée montre là ses limites puisque un algo qui utilise beaucoup de mémoire peut-être beaucoup plus rapide dans le test initial (avec des données réduites) mais la surconsommation entraine la totalité du jeu à ramer.

LeGreg

[eclesia]

Pour ce qui est de la duplication de données, il faut toujours être circonspect avec ces méthodes, parce que ce qui plombe beaucoup de jeux modernes c'est l'empreinte mémoire justement. Et l'optimisation prématurée montre là ses limites puisque un algo qui utilise beaucoup de mémoire peut-être beaucoup plus rapide dans le test initial (avec des données réduites) mais la surconsommation entraine la totalité du jeu à ramer.

mon objectif n'est pas de faire un jeu. J'ai meme moyen de mettre en pause mon affichage et de lafficher au coup par coup.

Coté mémoire je vais tres surement tomber sur le probleme de la limite, on verra le moment venu, etant seul sur ce projet (pour le moment) j'ai d'autre chats a fouetter.

Sinon toujours pour la memoire, j'ai une structure en 3 niveau.

1) les liens aux sources (fichiers ou bases de données), je dois les garder actifs pour d'eventuel mise a jour.
2) les données en mémoire , données attributaires en struture object.
3) une classe qui "represente" la struture objet en 3D

Le rendu est important mais ne doit pas couter beaucoup de ressource processeur, car le logiciel qui utilise le moteur doit disposer d'un maximum de ressource . (le FPS est limité a 30 par defaut)

En resumé, contrairement aux jeux, le rendue 3D n'est pas la priorité (les actions du logiciel prime sur l'affichage).

[ash.ice.loky]

Pour ton probleme de priorité cela releve encore une fois de conception, un taskmanager avec une priotité forte sur les IO et la logique et une faible sur l'affichage devrait faire l'affaire.

de toute facon ceci n'est pas en soit une priorité, si ton moteur 3D est suffisament bien concu il te siffiras desactiver telle ou telle fonction (comme l'eclairage par exemple) pour booster tes fps et ainsi laisser plus de temps a la logique de ton application et n'ai crainte, l'OO ne se verra même pas sur les perfs finales de ton appli.

[eclesia]

voila, j'arrive a un resultat assez interessant, seulement le temps va me manquer (le projet reclame mon attention sur d'autres points)



j'aurais donc besoin d'un volontaire/benevole pour participer au projet et developper le moteur3D de celui ci.

le projet est serieux, il s'agit d'un logiciel de cartographie (SIG) pour le monde du libre (license GPL). J'ai obtenu un hebergement du projet sur developpez.com ( je n'ai pas encore les acces mais j'ai l'accord ).

le projet ne compte que moi pour le moment, mais j'ai fait des annonces sur des forum SIG et je devrais obtenir quelques developpeurs supplémentaires (s'ils tiennent parole). Il y aura d'autres "postes" a pourvoir, j'en ferais une liste une fois le site en place.

plus de detail ici :
http://www.forumsig.org/showthread.php?t=11821

pour le coté 3D, le moteur n'utilise pas Java3D mais JOGL.