Discussion :

[robinsondesbois]

Bonjour,

J'ai un petit souci dans mon code.

Je possède des objets 3D "classe Object3D" qui peuvent être redéfini en caméra par exemple "classe Camera" et qui possède des renderer "classe Renderer".
La classe "Renderer" utilise les infos de la caméra.
J'ai donc le schéma suivant :

Camera inclue Object3D
Object3D inclue Renderer
Renderer inclue Camera

Que faire ???

Merci d'avance,
Robin

[robinsondesbois]

Pour corriger mon problème, j'ai utiliser l'héritage.

J'ai dérivé Object3D en GraphicObject3D qui contient un renderer.

Du coup plus d'inclusion multiple.

[koala01]

Salut,

Bonjour,

J'ai un petit souci dans mon code.

Je possède des objets 3D "classe Object3D" qui peuvent être redéfini en caméra par exemple "classe Camera"

Non!!!! une caméra n'est, définitivement, pas un objet 3D... Elle en affiche très certainement ou -- plutot -- elle capture la position des objets 3D qui se touvent dans son champs de vision, mais ce n'est surement pas un objet 3D : même si une caméra venait à être orientée vers l'endroit où se trouve une autre caméra, cette autre caméra n'apparaitrait pas à l'écran

et qui possède des renderer "classe Renderer".

Heu, tu parle de la classe Object3D ou de la classe Camera, là

A priori, le renderer est "au dessus de la mélée" (car il va représenter le "contexte d'affichage" de l'ensemble)... De manière générale, ce n'est donc ni Object3D ni Camera qui "contient" ton Renderer, et, à bien y réfléchir, ce n'est pas l'inverse non plus (ton Rendrer qui contient ta caméra ou tes objets 3D) . Si une fonction particulière (de tes objets 3D) on besoin du "Renderer", il faut le fournir sous la forme d'un paramète

La classe "Renderer" utilise les infos de la caméra.
J'ai donc le schéma suivant :

Camera inclue Object3D
Object3D inclue Renderer
Renderer inclue Camera

Que faire ???

1- t'intéresser au LSP (Liskov Substitution Principle ou principe de substitution de Liskov) et le comprendre pour éviter d'avoir des aberrations comme celle qu'on vient de voir (caméra qui serait un objet 3D... quelle horreur!!!)

2- En profiter pour t'intéresser aux autres principes SOLID, c'est toujours intéressant, et cela te permettra de respecter Liskov plus facilement

3- Revoir ta conception à la lumière des cinq principes SOLID

4- Si, vraiment, tu as besoin de références croisées, utiliser la notion de déclaration anticipée

[koala01]

Pour corriger mon problème, j'ai utiliser l'héritage.

J'ai dérivé Object3D en GraphicObject3D qui contient un renderer.

Du coup plus d'inclusion multiple.

Pourrais-je voir tes classes Object3D et GraphicObject3D car, très sincèrement, là, j'ai peur!!!!

[robinsondesbois]

Une camera est un objet 3D.
J'ai la hiérarchie de classe suivante :
- Object qui contient le nom de l'objet courent
- Object3D pour les objets 3D de la scène (comme la camera par exemple)
- GraphicObject3D pour les objets graphique.

On notera que la camera dérive de Object3D. Elle peut donc subir les mêmes transformation qu'un object 3D (déplacement, rotation) mais elle n'est pas affiché ! Seul les GraphicObject3D sont affiché.
Les informations de rendu pour chaque objets est stocké dans une classe que j'ai appelé Renderer (a tort peut être).

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
30
31
32
33
34
35
36
37
38
39
40
41
#ifndef OBJECT3D_H_
#define OBJECT3D_H_
 
#include <vector>
 
#include "Object.h"
#include "Transform.h"
#include "Dynamic.h"
#include "Static.h"
 
class Object3D : public Object
{
protected:
	Transform transform;
	std::vector<Componant*> componants;
 
	Object3D();
public:
	Object3D(std::string name);
 
	virtual void translate(float x, float y, float z);
	virtual void translate(glm::vec3 translation);
	virtual void rotate(float alpha, float x, float y, float z);
	virtual void scale(float x, float y, float z);
	virtual void setPosition(float x, float y, float z);
	virtual void setPosition(glm::vec3 position);
	virtual void setRotation(float alpha, float x, float y, float z);
	virtual void setScaling(float x, float y, float z);
 
	virtual glm::vec3* trackPosition();
 
	Static* addPhysicComponantStatic();
	virtual Dynamic* addPhysicComponantDynamic();
 
	virtual void update();
 
	glm::vec3 getPostion();
 
	~Object3D();
 
};

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
30
31
32
33
34
35
36
#ifndef _GRAPHICOBJECT3D_H
#define _GRAPHICOBJECT3D_H
 
#include "Geometry.h"
#include "GraphicRenderer.h"
#include "LOD.h"
#include "ParticleSystem.h"
#include "Object3D.h"
#include "GlobalInformation.h"
 
class GraphicObject3D: public Object3D
{
private:
 
protected: 
	Geometry* currentGeometry;
	GlobalInformation* globalInformation;
	std::vector<GraphicComponant*> graphicComponant;
 
	GraphicObject3D();
 
public:
	GraphicObject3D(GlobalInformation* globalInformation, std::string name);
 
	void addGraphicRendererComponant(Material* material);
	void addLODComponant() {this->graphicComponant.push_back(new LOD());}
	ParticleSystem* addParticleSystemComponant(int nbParticles, Material* material, bool continuous = true);
 
	void setCurrentGeometry(Geometry* geometry) {this->currentGeometry = geometry;}
 
    virtual void update();
 
	~GraphicObject3D();
};
 
#endif

[koala01]

Une camera est un objet 3D.

Je te dis que non, mais je reviens dessus d'ici quelques lignes

J'ai la hiérarchie de classe suivante :
- Object qui contient le nom de l'objet courent
- Object3D pour les objets 3D de la scène (comme la camera par exemple)
- GraphicObject3D pour les objets graphique.

Question : à quoi sert Object s'il ne contient que le non (indice : si tu me dis que c'est la caractéristique commune à tous les objets, tu as tout faux

On notera que la camera dérive de Object3D. Elle peut donc subir les mêmes transformation qu'un object 3D (déplacement, rotation) mais elle n'est pas affiché ! Seul les GraphicObject3D sont affiché.

Hé non...
Une caméra est très certainement modélisée par une position et une orientation, mais cela ne suffit pas pour en faire un objet 3D... Un objet 3D est quelque chose qui se trouve sur la scène. Or, la caméra (et la vue qui en résulte) est quelque chose de totalement extérieur à la scène et sur laquelle les objets de la scène n'ont absolument aucun contrôle.

Le fait que tu puisse la positionner, l'orienter et lui faire subir les même modifications (en termes de position et d'orientation) qu'à n'importe quel objet 3D ne suffit pas à justifier le fait que ta caméra hérite de Object3D, ne serait-ce que parce que tu as surement un comportement associé à tes objets 3D qui permet de les afficher sur la scène. Ta caméra ne faisant pas partie de la scène, il n'y a aucune raison pour que tu décide de l'afficher, et donc le comportement qui permet d'afficher les objets 3D est valide pour les objets 3D mais ne l'est pas pour la caméra.

Du coup, faire hériter Camera de Object3D contreviendrait au principe de substitution de Liskov, ce qui t'oblige (étant donné que c'est un principe de conception) écarter cette solution.

Donc, je le répète encore une fois: LA CAMERA N'EST PAS UN OBJET 3D ET NE DOIT EN AUCUN CAS HERITER DE Object3D!!!

Les informations de rendu pour chaque objets est stocké dans une classe que j'ai appelé Renderer (a tort peut être).

j'aurais sans doute préférer garder ce nom pour représenter la classe qui s'occupe effectivement de calculer le rendu (et qui est, a priori d'un point de vue conceptuel, différente de celles qui maintient les données nécessaires au calcul du rendu )

PS: en lisant le code de ta classe Object3D, je me rend compte qu'elle dispose d'une fonction update()... Cette fonction est l'exemple type de ce que je t'explique au sujet du LSP : elle n'a rien à faire dans une classe Camera et prouve donc qu'une caméra n'a absolument pas à hériter de Object3D.

La relation d'héritage est la relation la plus forte qui existe entre deux classes. Le simple fait que deux classes exposent des fonctions communes (comme, par exemple, translate ou rotate) ne suffit absolument pas pour justifier une relation d'héritage

[Bousk]

Si ce qu'il appelle "Objet3D" est juste un item positionné, alors que la caméra en hérite est pas forcément choquant.

les objets de la scène n'ont absolument aucun contrôle

Je suis pas d'accord. La présence d'un objet peut influer sur la caméra. Cas typique : shake.

Quant à la présence d'une fonction Update dans un objet caméra, là encore je ne suis pas d'accord. Un Update a tout à fait sa place pour une caméra. Pour gérer un shake, une vitesse de traveling, de zoom, ...

[Médinoc]

tu as surement un comportement associé à tes objets 3D qui permet de les afficher sur la scène. Ta caméra ne faisant pas partie de la scène, il n'y a aucune raison pour que tu décide de l'afficher, et donc le comportement qui permet d'afficher les objets 3D est valide pour les objets 3D mais ne l'est pas pour la caméra.

- Object3D pour les objets 3D de la scène (comme la camera par exemple)
- GraphicObject3D pour les objets graphique.

[robinsondesbois]

Dans mon cas, chaque Object3D peut accueillir des Componant.
Par exemple j'ai un Componant FollowPath qui permet de modifier la position des object3D. Très utile pour les travelings.

Les GraphicObject3D ont des GraphicComponant comme un GraphicRenderer par exemple qui donne les informations d'affichages.

On notera que dans tous les logiciels que je manipule, la camera est un objet de la scène (Blender, Unity, UE4, etc...).

[koala01]

Si ce qu'il appelle "Objet3D" est juste un item positionné, alors que la caméra en hérite est pas forcément choquant.


Je suis pas d'accord. La présence d'un objet peut influer sur la caméra. Cas typique : shake.

Quant à la présence d'une fonction Update dans un objet caméra, là encore je ne suis pas d'accord. Un Update a tout à fait sa place pour une caméra. Pour gérer un shake, une vitesse de traveling, de zoom, ...

Mais cela ne suffit malgré tout pas à décider de faire hériter la caméra de la classe de base qui permet de gérer les éléments de la scène.

Si même tu envisage de permettre, comme avec blender ou unity, de permettre au développeur de la manipuler "à sa guise" tu dois en réalité travailler avec une vue reprenant l'ensemble scène + caméra qui est un sur-ensemble de la scène (car la scène ne contient pas la caméra).

Il faut te dire que le fait de pouvoir visualiser la caméra n'a de sens que pour le développeur. Une fois que tu es sorti de là, la caméra doit avoir sa "propre vie", totalement indépendante de la scène quelle filme. Elle peut donc exposer un tas de comportements très proches de ceux que l'on peut observer au niveau des différents objets présents sur la scène, mais elle n'a aucun besoin de pouvoir être placée dans la même collection qu'eux.

C'est l'une des raisons pour lesquelles il faut appliquer strictement l'ISP ici et essayer de définir les éléments strictement transversaux, de manière -- pourquoi pas -- à permettre effectivement à la caméra d'exposer une interface similaire à celle des objets 3D sans forcément l'obliger à faire partie du groupe "objets 3D"

Je verrais personnellement bien quelque chose comme (je fais ca à main levée, hein )

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
30
 
template <typename CRTP>
class Postionnable{
public:
    void move(/* ... */);
    /* ... */
};
template <typename CRTP>
class Orientable{
public:
    void turn(/*... */) ;
};
// je suis pas sur du tout qu'autre chose qu'une camera ne puisse zoomer, mais bon ;)
template <typename CRTP>
class Zoomable{ 
public:
    void zoom(/* ... */)
};
class Object3D : public Positionnable<Object3D>,
                 public Orientable<Object3D>/* ,
                 * d'autres caractéristiques intéressantes ici ??
                 */{
 
};
class Camera : public Positionnable<Camera>,
               public Orientable<Camera>,
               public Zoomable<Camera>/*,
               * j'en oublie peut etre */{
 
};

Une chose est sure, c'est que bien que les deux classes exposent une interface commune, il n'y a absolument aucun lien entre les deux

[robinsondesbois]

Ok plus le voir avec une interface. Je n'y avais pas pensé. Merci