Salut et puis bonne année a tous

Alors voila je voulais avoir votre avis a tous. Dans le cadre d'un jeu vidéo en 3D. On fait en général ca gui en 2D en important des images .png. Mais pourquoi ne pas utiliser d'objet 3D (des planes, plans en français) auxquelles on appliquerait la texture en .png. L'utilisateur au final n'y verrai que du feux puisque les objets serait projeté face à la caméra.

J'y vois plusieurs avantage:

- une texture est généralement carré ou rectangulaire et si l'on veut faire une boussole ou une mini carte en cercle par exemple comment on fait. Certes il suffit de mettre les bords de la texture en opacité visuellement on n'y verra que du feu mais si par contre je veux que ma boussole soit séléctionnable ben les bord en opacité le seront aussi .

- lorsque l'on change la résolution de l'écran, les objets 3D sont redimensionné en conséquence ce qui est bien. Par contre les .png que l'on importe garde toujours la meme taille que l'on a défini sous photoshop et ca quelque soit la résolution de l'écran. Le fait que la gui soit en 3D permettrait d'etre redimensionné également.

- Enfin en 3D on a un axe Z et pas en 2D. Sous irrlicht et il n'y a pas de notion d'avant plan, d'arrière-plan.etc. L'axe Z permettrai de simuler comme des calques et avoir des élément de gui qui se supperpose.


D'ailleurs il me semble que sous Ogre la gui est en 3D.

voila

Alors qu'en pensez vous ?
++

Dernière modification par Dragonblood (01-01-2009 14:11:12)

Bonjour Dragonblood et bonne année.

L'idée n'est pas nouvelle   et elle est déjà employé dans certains jeux d'une certaine façon, ou même déjà au sein de certains moteur 3D (je pense par exemple à NeoAxis).
En règle générale, il s'agit en fait le plus souvent de gui 2D que l'on applique sur des surface en 3D, le principe les relativement simple, au lieu d'utiliser
l'ecran de base, on passe par un RenderTexture, et les selection se font par un système de picking.

Par contre les système de gui 100% 3D, cela existe aussi, mais ils sont plus rare, mais il y a un créneau à prendre la dessus je pense. Toi qui semble assez
pointu sur le sujet, realiser un gui 3D, multiAPI (compatible Irrlicht qui plus est) ferait certainement le bonheur de beaucoup de coder s(je n'ai toujours pas
réussi à trouver réellement une bonne gui 2D pour mon propre moteur 3D, compatible DX9, c'est pour dire...)

Dans cet espris aussi, tu as Aximion, une interface 3D pour windows, cela peut aussi t'inspirer...

Je pense que pour la gui en 3D j'essairai de voir ca. Je receuille des avis sur les différent forum avant de me lancer. Mais ma gui en 2D que je code actuellement pour mon jeux est deja avancé je ne pense pas l'abandonner pour revenir en arriere avec la 3D. En fait les 3 avantages que j'ai cité son les 3 points qui me chagrine le plus en 2D. Je filerai surment mes travaux si ca interresse.

Dragonblood :

Je filerai surment mes travaux si ca interresse.

Ne trouvant pas de solution satisfaisante, il va falloir que je me fasse à l'idée de m'y coller aussi, je te demanderais des conseils le moment venu...

Petite question : comment "séparer" la gui 3D et la scène 3D ? Je veux dire, si on positionne des objets 3D texturés représentant les éléments de l'interface, il n'y a pas de risque que ceux-ci se trouvent cachés par du décor qui serait très proche de la caméra ? Et puis existe-il une technique facile à mettre en œuvre pour que ces objets 3D se placent systématiquement devant la caméra ?

C'est effectivement un des éléments à prendre en compte, et pour  cela il faut pondre un pipeline de sortie
spécifique aux éléments 3D assurant les représentation du gui en 3D.
Ce n'est hyper difficile ceci dit.

tmyke, c'est quoi cette histoire de pipeline ? Y'a une section de la documentation d'Irrlicht qui aborde le sujet ?

Pour resumer, quand tu definis des objets 3D sous Irrlicht, le rendu de ces objets se fait par l'instruction
'smgr->drawAll();'
Dans ce cas, si tu definis des objets 3D pour faire un rendu d'une gui, il seront 'noyés' dans le flot de tous les
objets 3D rendu.
Donc, pour les elements 3D destines au gui, il te faut les retirer du scenemanager classique, pour te faire ton
propre pipeline de rendu, avec ton controle personnalise, ce qui te permettra de mieux controler les sorties graphiques,
en particulier pour eviter les effets de chevauchement entre gui et element de la scene.
Si tu veux plus de details, je t'en donnerais plusen rentrant ce soir

Avec plaisir merci ^^

Bonsoir donc Metallizer.

Pour revenir à nos mouton, et pour rentrer un peu plus dans les détails, j'aurais d'abord une question, qui conditionne
pas mal la suite, c'est comment tu vois, et ce débat est ouvert à tous, les gui en 3D. C'est un concept large et
qui peut prendre un visage très différent selon les idées de chacun. Il s'agirait plutôt d'un systeme avec des fenetre
3D animées etc.., ou encore par exemple une gui plus ou moins traditionnelle mais que l'on pourrait apposer sur des surfaces
3D des scène, ou encore ... ???
Donc, un petit détaillage, avec pourquoi pas des croquis, serait un bon début, non ?

Oui donc moi je vois ça comme je l'ai vu dans pas mal de jeux notamment sur consoles :

Il y a une scène 3D qui sont ni plus ni moins que les mondes, nos personnages les explorent.
Et il y a la gui, le nombre de vies, du texte, un score éventuellement etc...

Dans pas mal de jeux, il était courant de voir des objets 3D "au premier plan", ils ne font pas partie de la scène (et tu le confirme avec les "pipeline") mais seraient dans une autre qui est affiché "par dessus", ce qui fait que par exemple, comme le disait Dragonblood, on pourrait avoir une gui qui s'adapte à la résolution de l'écran et c'est je pense un énorme avantage.


(ici la pomme en haut accompagnée du chiffre 25 est en 3D mais constitue un élément de l'interface comme si c'était un objet 2D)

Bon je pensais que tmyke allait me donner au moins une piste sur ce fameux "pipeline" dont il parle
Question alors ? Serait-ce un deuxième "IVideoDriver" qui a sa propre scène puis qui doit ensuite fusionner avec le premier video driver pour avoir une seule image ?

COmment tu sais que la pomme est en 3D ?

On peut pas forcément le deviner sur le screenshot mais quand tu vois le jeu tourner, c'est évident qu'il ne s'agit pas d'un sprite 2D mais d'un modèle 3D, d'ailleurs la pomme en question est en constante rotation.

C'est plus évident en vidéo ^^

http://www.youtube.com/watch?v=MA_3kyqc … re=related

Dernière modification par Metallizer (11-01-2009 13:01:25)

Le fait qu'elle tourne sur elle même ne veut rien dire

Metallizer :

Bon je pensais que tmyke allait me donner au moins une piste sur ce fameux "pipeline" dont il parle
Question alors ? Serait-ce un deuxième "IVideoDriver" qui a sa propre scène puis qui doit ensuite fusionner avec le premier video driver pour avoir une seule image ?

Désolé pour mon inconstance ces temps-ci, j'ai très peu de temps à moi

En fait, il te faut créer des Mesh 3D, que tu n'insère pas par les fonctions de type 'RegisterNodeForRending'. Tu créé une liste dynamique des mesh 3D que tu as
créé pour ton gui 3D, puis une fois que tu as fait une passe de rendu standart (DrawALL), tu fait le rendu de tes éléments 3D, ce qui garantie un bon controle de position sur un premier plan,
et tu n'a plus qu'a les placer en fonction du ViewPort au bon endroit pour qu'il soit parfaitement visible et aux bons endroits.

Je n'utilise pas RegisterNodeForRendering, mes mesh sont ajoutés via SceneManager->AddAnimatedMeshSceneNode() et quand je fais le drawAll, ils sont tous affichés dans la même scène. Je suppose qu'en utilisant AddAnimatedMeshSceneNode ça les inscrit forcément dans la listes des mesh à être rendus par drawAll.
Par contre je passe peut être pour un gros noob mais comment tu fais pour faire le rendu de mesh de manière "séparée" c'est ce point précis que j'aimerais comprendre, comment bien "séparer" le rendu, en tout cas merci pour la réponse.

Par contre je passe peut être pour un gros noob mais comment tu fais pour faire le rendu de mesh de manière "séparée" c'est ce point précis que j'aimerais comprendre, comment bien "séparer" le rendu, en tout cas merci pour la réponse.

Je suis pas sur d'avoir compris mais bon je me lance pour séparer des rendu ben tu utilise plusieur scenemanager. Chaque objet (2d, 3D, camera enfin tous quoi) de chaque scenemanager sera indépendant. Ensuite tu n'as plus qu'a spécifier qu'elle scenemanager tu veux rendre.

Dernière modification par Dragonblood (11-01-2009 17:05:11)

Metallizer :

Par contre je passe peut être pour un gros noob mais comment tu fais pour faire le rendu de mesh de manière "séparée" c'est ce point précis que j'aimerais comprendre, comment bien "séparer" le rendu, en tout cas merci pour la réponse.

Pour prendre un exemple simple, prend l'exemple du package '01.HelloWord'.
Tu écris après la creation du node (sydney) un node->SetVisible(False);

Lors du rendu, tu ne la veras donc plus, la Sydney.

Par contre, après DrawAll(), si tu ecris node->Render(), alors ho magic, elle est de nouveau là. C'est tout con non ?

Le con, je cherchais une fonction "Draw" au node, j'ai pas pensé à "Render" -_-

Merci beaucoup tmyke, je vais voir ce que je peux faire avec tout ça

CEGUI utilise la 3d je croi et il i a une notion du Z order

oui tout à fait. Ya ton copain Yamashi qui me soutenait que non sur le site du zéro ben j'ai du lui clouer le bec en reprenant une citation du site officiel de Ogre qui confirmer ce que je disais.

Dernière modification par Dragonblood (23-01-2009 08:03:59)