Implémenter un graphe de scène en Javascript

Citation:

---

Envoyé par screetch

sinon, nouknouk, pourquoi des singletons? :)

---

Parce que les singletons c'est le mal ... mais dans certains cas bien précis, ne pas les utiliser c'est pire que le mal.

Les singletons ont leur utilité pour des fonctionnalités qui sont par nature uniques dans ton application et auxquelles tu as besoin d'accéder à beaucoup d'endroits épars dans ton code.

Ici, le cas des inputs est un bon exemple: même le plus petit élément de ton graphe de scène peut en avoir besoin (genre une implémentation d'un widget type bouton qui veut savoir si la souris le survole, ...). Vouloir éviter le singleton revient à vouloir se trimballer partout une référence vers ton instance d'Input qui pourtant ne servira à rien dans 90% des cas.

Pour le reste, je ne peux que te renvoyer à toute la prose dispo sur le net qui détaille sans aucun doute les choses bien mieux que moi.

A noter que quand je parle de singleton, je parle du concept de ressource accessible de façon globale depuis n'importe quel endroit du code ; dans cette acception, une simple variable avec une portée globale (et un minimum de rigueur) suffit ; pas besoin forcément de se taper l'implémentation classique avec une classe, sa méthode statique getInstance(), etc... :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

// des 'objets globaux' STAGE et INPUT STAGE = { width: 640, height: 480 };   INPUT = { isMouseOver : function(node) { return /* true or false */ } }   // blablabla   // et somewhere dans mon code: monObjet = { mafonction: function() { this.setPosition(STAGE.width / 2, STAGE.height / 2); } onUpdate: function(tickTime) { if (INPUT.isMouseOver(this)) { doSomething(); } } }

---

Après, c'est sujet à débat (y compris mon choix pour ce cas ci) et d'une façon générale je reste contre le fait de conseiller les singletons car ils sont souvent utilisés à mauvais escient. Mais dans la pratique tout n'est jamais complètement noir ou blanc et ils ont leur utilité quand ils sont utilisés aux bons endroits.

Un autre truc (décidément, je suis en verve ce soir :aie:). qui m'a pas mal apporté de confort syntaxique. C'est peut-être évident pour les habitués du JS, mais en tant que débutant dans ce langage, ça m'a pris du temps avant de tilter (et ce fut coûteux en refactoring). Donc j'en parle dès le début, tant qu'à faire :

A propos du passage des paramètes aux constructeurs des (sous)classes de Node:

Premier jet: mon noeud a une position et une taille. C'est bête comme choux, je lui fait donc un joli constructeur:

Code:

---

1 2 3 4 5 6

// ma classe Rectangle = Node.extend({ constructor: function(x, y, width, height) { /* ... */ } }); // et je l'instancie: monRectangle = new Rectangle(100, 100, 300, 200);

---

Jusque là, c'est super.

Ah et puis il peut aussi avoir une couleur et être visible ou pas:

Code:

---

1 2 3

monRectangle = new Rectangle(100, 100, 300, 200); monRectangle.setColor(255,255,0); monRectangle.setVisible(true);

---

Bon, 3 lignes c'est un peu long à écrire, et je suis fainéant.
On va passer ces paramètres directement dans le constructeur et si la valeur est à null on dit qu'on prend la valeur par défaut (genre blanc pour la couleur).

Code:

---

monRectangle = new Rectangle(100, 100, 300, 200, null, false);

---

Jusque là ça va encore...

Puis on va vouloir faire des choses de plus en plus complexes où les paramètres possibles vont s'accumuler.
Genre pour un bouton: position + taille + visible + alpha + image normale + image en hover + image cliquée + label + couleur du label + ...

On se retrouvera avec un constructeur à 12 000 paramètres et des allers retours incessants dans notre doc parce qu'on se demande si "le paramètre de la couleur on le met en 12ème ou 13ème position dans le constucteur de Bouton et en 8ème pour le TextField ?". Je parle même pas de l'absence de clarté du code le jour où on se relit.

Bref, imbuvable à terme.

La petite solution à deux sous: un seul argument au constructeur (params) qui est un objet et contiendra seulement les paramètres nommés et spécifiques qu'on veut appliquer ; les autres seront pris par défaut par la classe elle-même mais aussi par ses classes parentes.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Button = GroupNode.extend({ constructor: function(params) { // on peuple params avec les valeurs manquantes par défaut: addDefaultParams(params, Button.BUTTON_DEFAULT_PARAMS);   // appel du constructeur parent this.base(params);   // récup' des paramètres propres à bouton this.image = params.image; this.hoverImage = params.hoverImage; } },{ BUTTON_DEFAULT_PARAMS: { image: "/img/button_default.png", hoverImage: "/img/button_hover_default.png", alpha: 127, // utilisé par la classe PARENTE de Button, width: 300 // utilisé par la classe PARENTE de Button, } });

---

Avec addDefaultParams qui prend les params et va ajouter ceux par défaut pour cette classe là.

Code:

---

1 2 3 4 5 6 7

addDefaultParams = function(params, defaultParams) { for (var paramName in defaultParams) { if ( typeof(params[paramName]) == "undefined") { params[paramName] = defaultParams[paramName]; } } }

---

Si c'est également organisé de la même façon dans chacune des classes parentes , on va pouvoir:

- spécifier des valeurs par défaut spécifique à cette classe là (image, hoverImage)

- surcharger des valeurs par défaut pour notre classe spécifique mais pour des paramètres utilisés par les classes parentes (alpha, width)

- avoir une syntaxe au moment de l'instanciation qui reste simple, concise et limpide et sans souci d'ordre de passage des paramètres, il faut juste se rappeler de leur nom (bien plus facile à retenir):

Code:

---

1 2	var but1 = new Button({x:300, y:500, color:[255,255,0]}); var but2 = new Button({y:600, x:300, width: 150, height: 50, image: "/img/bouton_rond.png", visible: false});

---

Et le tour est joué ;)
D'autant qu'on va pouvoir passer n'importe quoi dans ces paramètres, y compris par exemple des fonction callback (merci JS pour le coup):

Code:

---

var but1 = new Button({ y:300, x:500, onClicked: function(btn) {alert("i am button "+btn.label);} });

---

Et encore mieux: le jour où je décide de changer l'image de mon bouton par défaut pour l'ensemble de mes boutons de mon appli, j'ai un seul endroit à changer (ou surcharger), genre au début de mon appli:

Code:

---

1 2 3 4

include("buttonClass.js");   Button.BUTTON_DEFAULT_PARAMS.image: "/img/mon_autre_button_default.png"; // désormais, tous les boutons utilisant l'image par défaut auront cette nouvelle 'skin':

---

Je suis stagiaire p3ga5e :) !!
Merci des infos nouknouk :) !!

Donc la solution la plus pratique est de faire un arbre n-aire avec pour chaque node un GroupNode.

Du coup GroupNode extends Node !!
Et dans GroupNode on aura toutes les transformations spécifiques à un objet puis son affichage.

C'est probablement pas la seule possibilité ; mais si peu ou prou l'ensemble des libs graphiques retombent sur cette organisation à la fin, c'est pas juste un hasard ou à cause un manque pathologique de créativité de la part de leurs auteurs ;)

A nouveau: je te conseille vraiment en parallèle de jeter un oeil à d'autres libs existantes, que ce soit dans le même langage ou même dans un autre (C++ / Java / ...) ; c'est vraiment comme ça qu'on apprend le plus vite amha.

Comme osgjs ou o3d par exemple ?

Perso, je ne les connais pas. Mais d'une façon générale tout est bon à regarder, d'autant plus si la librairie à déjà 'fait ses preuves' (projet actif, communauté importante, ....) car c'est souvent un gage de qualité.

Encore moi. Perso je galère beaucoup pour faire un arbre n-aire en Javascript.

Que penses tu de ca ?

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79

/**  * @author sylvain  */   // Classe de gestion des graphes de scènes   //////////////////////////////////////////////////////////////////// // Constructeur de noeud du graphe de scène // Arguments : Les parents, les enfants, un identifiant, un objet // et une transformation // ////////////////////////////////////////////////////////////////////   var WebGL_Node = Class.create({   initialize : function(obj, node) {   this.obj = obj; this.node = node; this.nb_elem = 0;   node = new WebGL_GroupNode(null);   },     //////////////////////////////////////////////////////////////////// // Méthode pour ajouter un enfant à l'arbre // Entrée : Un objet WebGL, le parent, la matrice de transformation // Sortie : Le nouveau parent // //////////////////////////////////////////////////////////////////// addNode : function ( node) {   // L'arbre est nul, on le crée if(node == null) {   node = new WebGL_Node(this.obj, this.node);   } else {   this.node = node; this.nb_elem = this.nb_elem + 1; } return node; }, //////////////////////////////////////////////////////////////////// // Méthode pour supprimer un noeud // // // //////////////////////////////////////////////////////////////////// removeParent : function (id_node) {     }, //////////////////////////////////////////////////////////////////// // Méthode pour rechercher un noeud avec son identifiant // Entrée : l'arbre, et l'identifiant // Sortie : le nouvel arbre // //////////////////////////////////////////////////////////////////// searchNode : function (id_node, root) {       },   //////////////////////////////////////////////////////////////////// // Méthode pour savoir si un arbre est vide ou non // // // //////////////////////////////////////////////////////////////////// isEmpty : function () { return (this.root == null); }   });

---

J'ai trouvé 2 articles très intéressants

http://www.nczonline.net/blog/2009/0...-linked-lists/

http://www.nczonline.net/blog/2009/0...h-tree-part-1/

:)

j'utiliserais un scenegraph sous forme de DOM ou JSON pour pouvoir importer ma scène plus facilement ... sinon ton scenegraph il te servira pas à grand chose. Pour un scengraph dynamique le DOM est peut-être plus approprié.

il me semble que three.js s'occupe assez bien de ce genre de chose