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]

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, ...

[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