Discussion :

[GilbertLatranche]

Bonsoir à tous !

J'ai repris un projet perso qui consiste en une implémentation du concept de "vue nodale".

En exemple je peux citer, le Node Graph du logiciel de compositing Nuke :
http://www.fxguide.com/wp-content/up...uke_screen.jpg

La partie graphique étant quasiment finie, je m'intéresse à la partie logique, aussi aurais-je voulu avoir quelques conseils, avis (si quelqu'un s'y connaît un peu)...

J'ai touché rapidement à Nuke, au FlowGraph du CryEngine, ce qui en ressort :
- une node représente un ensemble de propriétés
- une connexion d'une node à une autre réalise une action précise : par exemple, relier un noeud "Image" à un noeud "Vue" aura pour effet d'afficher l'image dans la vue... ...merci capitaine évidence....

Il me semble logique qu'il y aura une classe par type de node.

Me conseilleriez-vous une solution plutôt qu'une autre pour "si tel noeud est relié à tel noeud, alors faire ceci" (pour chaque type de noeud donc) ?

Devrais-je aller voir du côté de la théorie des graphes ?

Merci

[AdmChiMay]

De ce que je comprends, ton problème n'est pas de la théorie des graphes, dans le sens où tous les nœuds n'ont pas la même sémantique. Il s'agit plutôt d'actions. Je dirai plutôt que tu es dans le domaine des automates d'état finis, qui peuvent se modéliser par des tableaux ou des graphes : passer d'un nœud à un autre implique de faire certaines actions (bon, selon les littératures et points de vues, les actions sont soit dans les nœuds, soit dans les arcs/transitions).

[GilbertLatranche]

Merci pour ta réponse.

Certains développeurs de ce genre de système disent que cela s'apparente à du scripting.

[AdmChiMay]

Je ne serai peut-être pas très utile pour ta solution (et je n'ai jamais erré du côté de Nuke).
Si tu dis "scripting", je pense à une manière de coder : langage de script versus compilé. Cela ne change pas le problème de fond.
Sois tu cherches un algorithme à programmer, et je peux peut-être avoir des idées, soit tu es franchement dans le domaine "Nuke" ou une bib spécifique, et il faudra poser la question dans la section "programmation jeux" de dvp ou d'un autre forum.

[GilbertLatranche]

De mémoire, l'éditeur nodal du CryEngine génère du LUA.

En fait au final, mon souci est plus au niveau de la conception.

J'avais pensé à une fonction virtuelle par classe "*Node", dans laquelle on devrait définir les actions à faire en cas de connexion avec tel node (donc à coups de cast ou de metaObject), mais je me demande s'il n'y a pas plus simple ou moins lourd.

Conception, algorithme, je ne sais plus très bien

[LittleWhite]

Bonjour,

Je pense actuellement aux éditeurs de matériels (Unreal Engine et autre 3DS Max).

En fait, chaque noeud possède une méthode process (qui fait le traitement) et une ou plusieurs entrées et possiblement une (ou plusieurs) sortie.
Le truc, c'est de genre un code assez générique pour avoir plusieurs entrées et sorties. Généralement, ça renvoie une données assez simple (une texture (donc un tableau 2D)), si vraiment on doit envoyer une données scalaire ou une texture, il faut aussi faire une surcouche (type de variant) pour envoyer et recevoir la données.
Sinon, on peut aussi imaginer que pour chaque entrées (ou sorties) ont est une classe Socket, qui détermine la data attendue/renvoyée. Les connexions deviennent simple après.

[gbdivers]

De mémoire, l'éditeur nodal du CryEngine génère du LUA.

En fait au final, mon souci est plus au niveau de la conception.

J'avais pensé à une fonction virtuelle par classe "*Node", dans laquelle on devrait définir les actions à faire en cas de connexion avec tel node (donc à coups de cast ou de metaObject), mais je me demande s'il n'y a pas plus simple ou moins lourd.

Conception, algorithme, je ne sais plus très bien

Si tu fais ça, tu pars sur des approches de double dispatching, c'est lourd.
A mon avis, dans ce genre de script (représenté par un graph), les connexions ne sont pas des fonctionnalités. Elles connectent simplement un node avec un autre node, ce sont les nodes qui ont des fonctionnalités.
Donc, c'est pas "si tel noeud est relié à tel noeud, alors faire ceci", mais "tel noeud fait ceci, tel noeud fait cela".

Un exemple d'implémentation est d'avoir une classe pour les nodes, chaque entrée et sortie est une variable, et une classe connexion, qui relient 2 propriétés de 2 classes

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
struct Node {
    // input
    int in_1;
    double in_2;
    // output
    image out_1
    string out_2;
 
    void run(); // lance le calcul
};
 
template<class T>
struct Connect {
    Node* out;
    T* var_out;
    Node* in;
    T* var_int
};

Avec Qt, tu peux aussi utiliser le systèmes de propriétés et des signaux/slots : une variable de sortie est un signal, une variable d'entrée est un slot, et les properties sont les états internes des nodes :

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
class Node : public QObject {
    Q_OBJECT
    Q_PROPERTY(int in_1 READ int_1 WRITE setIn_1 NOTIFY in_1Changed)
    Q_PROPERTY(double in_2 READ int_2 WRITE setIn_2 NOTIFY in_2Changed)
    Q_PROPERTY(image out_1 READ out_1 WRITE setOut_1 NOTIFY out_1Changed)
    Q_PROPERTY(image out_2 READ out_2 WRITE setOut_2 NOTIFY out_2Changed)
 
public slots:
    void receiveIn_1(int);
    void receiveIn_2(double);
 
signals:
    void sendOut_1(image const&)
    void sentOut_2(string const&)
};
 
// création d'une connexion
QObject::connect(&node_1, SIGNAL(sendOut_3(image)), &node_2, SLOT(receive_In_1(image)));

Avec cela, tu peux facilement exporter tes classes Node pour être utilisé dans le designer par exemple ou créer ton designer. Ou utiliser les scripts ou le QML de Qt

Bon courage