Discussion :

[florian.g]

Bonjour,

Je suis actuellement en train d'ecrire une bibliotheque pour faire des calculs geometriques en N dimension, par exemple determiner des intersections de droites, ou le point le plus "proche" des intersections, determiner des intersections de polygones, polyedres, etc...

Je me demandais en fait si qqn aurait des conseils pour que ma bibliotheque soit facile a utiliser et evolutive.

L'idee est quand meme de garder les meilleures performances possible ou presque, et d'avoir tres peu de consomation en memoire pour autant que les objets manipules sont petits.

Mais j'aimerais que ca reste facile a utiliser.
J'aimerais aussi savoir a quel niveau d'abstraction je devrais envisager la librairie...

En fait j'ai en tete 2 facons de faire:

1. Pseudo-objet:
Je definis l'interface pour chacun de mes objet et jessaie dabstraire les caracteristiques communes... par exemple ca pourrait donner.

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
 
typedef void _fIPOINT;  //general type for point's methods
typedef void _fPOINT;   //general type for point
typedef struct _fIPOINT_{
  double (*x)(_fPOINT* A, int i);  //get coordinate x[i] from point A
  int (*dim)(_fPOINT* A);         //current point's dimension (2d / 3d etc...)
}fIPOINT;
 
typedef void _fIGEOMOBJ;  //Geometry object (polygon/polyline/line/segment)
typedef struct _fIGEOMOBJ_{
  _fPOINT* (*pnt)(_fIGEOMOBJ* Iobj,_fGEOMOBJ* obj,int i);  //get pointer to point i
  int (*opt)(_fGEOMOBJ* obj);               //get option
  int (*setOption)(_fGEOMOBJ* obj);         //set option flags
  _fPOINT* (*inter)( _fIGEOMOBJ* Iobj,_fGEOMOBJ* obj1 , _fGEOMOBJ* obj2 , _fPOINT* out); //returns all the intersections between obj1 and obj2(null if no intersections)
}fIGEOMOBJ;

Et en implementant cette interface pour definir des lignes, des segments, il doit etre possible d'obtenir un code tres facile a maintenir...
L'idee pour l'abstraction ici serait que tout objet geometrique est defini par ses points, qui sont relies entre eux d'une facon dependant de l'option (cercle, dernier point relie/dernier point libre, limite/infini) et selon ces parametres et le nb de points on peut savoir si on manipule un segment, une ligne, un polygone etc...

L'interet est d'avoir une seule fn d'intersection par exemple (et j'imagine qu'on peut factoriser d'autres concepts, apres avoir reflechi a ce dont il y a besoin).

L'un des probleme de cette approche c'est que ca risque d'augmenter le temps de calcul, car chaque fonction sera appelee comme un pointeur de fonction dans une structure.
De la meme facon, il faudra qu'une structure garde un pointeur sur les implementation de l'interface, pour chaque objet geometrique concet (ligne, polygon etc...).
Quand je dis interface, c un abus de language, car l'idee c'est plus une classe abstraite qu'une interface au sens strict ici.

Pour l'instant l'idee n'est pas tres mure vis a vis de quoi abstraire, et l'interface que j'ai definie la est mauvaise, c'est pour ca que j'aimerais ecouter vos avis, si quelqu'un a une bonne idee, ou a deja vu une abstraction plus interessantes sur les concepts manipules en geometrie a N dimension.
En fait j'aimerai principalement abstraire tout ce qui concerne l'intersection entre objects, pour ne pas avoir a traiter tous les cas possible, mais que chaque objet geometrique soit capable de se traiter par rapport a un autre en quelque sorte... et recuperer les infos necessaires pour calculer ses points d'intersection avec une autre figure...
Est-ce qu'il serait possible dans ce cas d'avoir la meme fonction d'intersection pour des polyedre que pour des polygones par exemple?

2. Je ne m'embete pas avec l'abstraction. J'ai une fonction d'intersection pour chaque cas possible:
- polygoneXpolygone
- segmentXpolygone
- droiteXpolygone
- droiteXpolyedre

Par contre, le temps de calcul sera peutetre reduit? et ca n'est pas sur que ce soit plus difficile a manager que le cas 1.
En general mes points se definissent comme suit

Code :

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

1
2
3
4
5
6
 
//pour des calculs en double
typedef struct _POINTd_{
  int dim;     //dimension
  double* x; //pointer to coordinate's buffer (siz=dim)
}POINTd;

et ds ce contexte, les polygones et polyedre par exemple

Code :

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

1
2
3
4
5
6
7
8
9
10
 
//pour des calculs en double
typedef struct _POLYGONEd_{
  int order;     //polygon order
  POINTd* pnt; //pointer to point's buffer (siz=order)
}POLYGONEd;
typedef struct _POLYEDREd_{
  int order;     //polyedre order
  POLYGONEd* pol; //pointer to polygon's buffer (siz=order)
}POLYEDREd;

En fait je suis plus tente par cette approche qui m'a l'air plus simple que l'approche 1, et suffisament abstraite au final, puisque je ne vois pas trop quelle evolution du code m'obligerait a redefinir les concepts de base...

Le probleme principal sera d'avoir une fonction separee pour chaque intersection, mais apres tout pourquoi pas? Dans tous les cas je risque d'avoir une implementation differente pour chaque intersection meme dans l'approche 1...

Voila j'aimerais donc savoir un peu ce que vous pensez de tout ca, et aussi savoir quelles fonctionnalites vous interesserait dans une librairie de calcul geometrique, et si vous avez des conseils sur la realisation je suis tout ouie.

De la meme facon, je vais surement devoir ecrire une librairie pour manipuler des matrices (je recherche des performances optimales aussi dans ce cas), donc je serais heureux de savoir si vous avez des conseil ou des requetes concernant une telle librairie.

Merci d'avance pour vos reponses.

Florian