Discussion :

[sylvain230]

Bonjour,

Je cherche à implémenter un graphe de scène en Javascript mais j'ai du mal à trouver une bonne définition, savoir ce qu'il y a dans geode, node ...

Je ne sais pas non plus si c'est possible en Javascript !

Pourriez vous m'aider ? Merci

[p3ga5e]

Salut,

Créer un arbre en JavaScript est tout à fait possible, le plus simple est d’ajouter une propriétée Childs et Parent a un objet pour l’insérer dans un arbre
un truc du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
function Attach(parent,child)
{
    if(parent.Childs==undefined)
        parent.Childs = [ child ];
    else
       parent.Childs.push(child);
 
    child.Parent = parent;
}
 
var earth = 
{   Name : "Earth",
    Matrix : [ 1, 0, 0, 0,
               0, 1, 0, 0,
               0, 0, 1, 0,
               0, 0, 0, 1],
};
var moon =
{   Name : "Moon",
    Matrix : [ 1, 0, 0, 384467,
               0, 1, 0, 0,
               0, 0, 1, 0,
               0, 0, 0, 1],
};
 
Attach(earth,moon);
 
alert(earth.Childs[0].Name); //"Moon"
alert(moon.Parent.Name); // "Earth"

Si tu cherche à étudier l’architecture d’un excellent moteur 3D en Javascript, je te conseil de jeter un œil a O3D de google

[sylvain230]

En effet, O3D a l'air d'être pas mal foutu. Je vais essayer de comprendre un peu les détails et "mettre les mains dans le cambouis" lol pour développer mon propre moteur.

[nouknouk]

Faire un moteur de type scénographe est évidemment tout à fait possible en Javascript ; je me suis d'ailleurs amusé à en faire un pour développer des jeux sur la freebox (cf. ma signature).

Les quelques idées de base:

- si tu est un minimum familier avec d'autres langages orientés objet (genre C++, Java), je te conseille de passer par une librairie additionnelle pour te donner un moyen d'écrire du code 'simple et limpide' (pour qui a déjà touché aux langages sus-cités) avec les principales fonctionnalités 'objet' à portée de main: constructeurs, héritage, ... Perso je me suis tourné vers Base.js.

- l'architecture des classes est assez simple au premier abord. Exemple:

* un singleton qui va s'occuper de tout ce qui concerne le contexte (chargement, canvas, gestion du temps, ...). Appelons le 'Stage'.

* un singleton pour gérer tout ce qui touche aux inputs (clavier, souris, ...).

* une classe 'Scene' qui sera la classe de base qui contient le graphe de scène et les animations en cours dans la scène. Le Stage exécute et affiche une et une seule scène à la fois.

* une classe générique représentant un élément dans le graphe (noeud ou feuille) avec les caractéristiques qui y sont rattachées, genre: position, taille, visibilité, alpha. Appelons là 'Node'.

* une classe dérivant de 'Node' qui représente un noeud dans le graphe, et qui est donc capable de contenir des enfants (typiquement avec une liste chainées). Appelons la 'GroupNode'.

* des classes dérivant de 'Node' qui représentent les feuilles de ton graphe et qui -elles- sont capables de se dessiner: une BitmapNode, TextNode, RectangleNode, LineNode, ... ; chacune a en plus des propriétés communes (position, taille, ...) des paramètres spécifiques (url de l'image, couleur du rectangle, ...).

Voilà pour la partie 'graphe de scène' ; tu poruras ensuite raffiner:

- avec des objets graphiques plus complexes, par exemple une classe 'Button' qui dérive de GroupNode et qui est composé d'une image de fond (le bouton), et d'une texte par au dessus (le label).

- avec la gestion des animations et des événements dans le temps.

- etc...

Mais comme le dit p3ga5e, il est plus qu'opportun de s'inspirer des libs existantes, de s'en faire deux ou trois pour comprendre leur fonctionnement et leur architecture interne. Ca permet non seulement de voir ce qui est commun à toutes les libs et ce qui peut être amené à varier en fonction des sensibilités propres et des besoins de leurs auteurs.

Perso si tu connais un peu Java, je te conseille de jeter un oeil du côté de la façon dont est organisée la lib PulpCore que j'ai un peu pratiqué et dont je me suis directement inspiré pour ma propre lib JS. Pour moi, elle a une approche extrêmement intéressante pour abstraire la notion de 'propriété' associées aux sprites (couleur, alpha, position, visibilité, ...) pour ensuite pouvoir les réutiliser de façon très élégante et générique dans les animations.

My 2 cents.

[sylvain230]

Merci pour toutes ces informations.

Pour l'instant, j'ai créé 3 classes :

- WebGL_Node qui va plutôt gérer tout ce qui est arbre. J'ai pensé que dans un noeud, un a un objet et une transformation( 1 matrice). Chaque noeud possède 1 identifiant.
Au début, je pensais à grouper Node et GroupNode mais je ne sais pas si c'est une bonne idée. De plus, est ce que seul les feuilles sont capable de dessiner ? Si c'est le cas ma structure ne va pas.

- WebGL_Context qui serait la classe singleton dont tu parles. Elle spécifie la taille du canvas et le navigateur a utilisé ainsi que le contexte selon le navigateur

- WebGL_Object qui implémenterait les fonctionnalités de base. Construire un cube, une sphère ...

Je ne comprend pas trop l'utilisation de Base.js. En effet,dans les classes par prototypage, toutes les méthodes sont séparées et forment plusieurs blocks alors que dans l'autre méthode tout est réunit dans un seul block.

Du coup, cela serait plus lourd dans des appels de fonction de toujours appeler toute la classe alors que avec prototype on appele juste la méthode de la classe qui nous intéresse non ?

[nouknouk]

Au début, je pensais à grouper Node et GroupNode mais je ne sais pas si c'est une bonne idée. De plus, est ce que seul les feuilles sont capable de dessiner ? Si c'est le cas ma structure ne va pas.

C'est sujet à débat ; pour moi le groupe et les feuilles sont des fonctionalités séparées. Mais ça peut se discuter.

toutes les méthodes sont séparées et forment plusieurs blocks alors que dans l'autre méthode tout est réunit dans un seul block

C'est juste que les blocs distincts sont passés à Base.js au moment de la définition de la classe en les regroupant dans une collection de blocs pour ne faire qu'un appel à 'extend' pour que le code soit plus joli. Ca n'empêche que le résultat est le même.

Du coup, cela serait plus lourd dans des appels de fonction de toujours appeler toute la classe alors que avec prototype on appele juste la méthode de la classe qui nous intéresse non ?

Non, c'est juste une couche syntaxique ; au niveau perfs pour les accès aux méthodes / fonctions c'est totalement équivalent.

Il y a (peut-être) juste une légère perte pour deux opérations beaucoup moins récurrentes: l'instanciation (new) et la conso mémoire ; à vérifier mais pour moi c'est plutôt négligeable,alors que je suis pourtant dans un environnement extrêmement contraint (un MIPS à 200MHz et quelques dizaines de Mo de RAM pour faire tourner l'ensemble du système).

Après, comme dit précédemment je partage juste cette lib qui m'a plu parce qu'elle correspondait bien à mon approche du JS: une grosse expérience en C++ et Java et très peu en JS. Mais c'est pas pour ça que tu dois te sentir obligé de l'utiliser (et ce n'est sûrement pas la seule qui existe non plus).