Quelles sont les bibliothèques de mathématiques vectorielles / matricielles / d'algèbre linéaire C ++ les plus utilisées, et leurs compromis coûts / avantages? [fermé]


243

Il semble que de nombreux projets rencontrent lentement le besoin de faire des calculs matriciels, et tombent dans le piège de la première construction de certaines classes vectorielles et de l'ajout progressif de fonctionnalités jusqu'à ce qu'ils se retrouvent pris en train de créer une bibliothèque d'algèbre linéaire personnalisée à moitié déterminée, et en fonction de cela.

Je voudrais éviter cela sans créer de dépendance vis-à-vis d'une bibliothèque liée de manière tangentielle (par exemple OpenCV, OpenSceneGraph).

Quelles sont les bibliothèques de mathématiques matricielles / d'algèbre linéaire couramment utilisées, et pourquoi décideriez-vous de les utiliser les unes par rapport aux autres? Y en a-t-il qui serait déconseillé d'utiliser pour une raison quelconque? Je l'utilise spécifiquement dans un contexte géométrique / temporel * (2,3,4 Dim) * mais j'utiliserai peut-être des données de dimension supérieure à l'avenir.

Je recherche des différences en ce qui concerne: l'API, la vitesse, l'utilisation de la mémoire, l'étendue / l'exhaustivité, l'étroitesse / la spécificité, l'extensibilité et / ou la maturité / la stabilité.

Mettre à jour

J'ai fini par utiliser Eigen3 dont je suis extrêmement satisfait.


2
Puisque vous avez mentionné OSG et OpenCV, je suppose que vous avez juste besoin de matrices / matrices de type graphique 3D, c'est-à-dire: matrices 3x3 et 4x4. J'ai basé ma réponse sur cela, mais vous voudrez peut-être préciser comment vous l'utilisez exactement - avez-vous besoin d'une résolution matricielle? Mathématiques matricielles de dimension supérieure? etc.
Reed Copsey

Pour le moment, je ne fais que des trucs basés sur la géométrie 2D, mais hypothétiquement, vous avez parfois besoin d'opérations 3x3 sur des données 2D, et il n'est pas clair si des données 3D et des opérations 4x4 pourraient être nécessaires. Nous aimerions utiliser une bibliothèque commune dans toute l'entreprise. Je n'ai pas une bonne idée de ce que serait le compromis. Plus général serait mieux, mais à quel prix est la question.
Catskul

1
Si vous faites juste des transformations géométriques, je recommanderais vraiment de regarder GGT, comme je l'ai mentionné dans ma réponse. Il est très complet pour cela, mais ne fait vraiment rien MAIS cela, c'est donc une option très propre et facile. BLAS et LAPACK sont plus pour les solutions matricielles complexes (ie: matrices 50x50, matrices clairsemées, etc.) pour les sciences et les mathématiques, pas les transformations géométriques.
Reed Copsey

Réponses:


114

Il y a pas mal de projets qui se sont installés sur le Generic Graphics Toolkit pour cela. Le GMTL est sympa - il est assez petit, très fonctionnel et utilisé assez largement pour être très fiable. OpenSG, VRJuggler et d'autres projets sont tous passés à l'utilisation de ceci au lieu de leurs propres calculs vertor / matrice roulés à la main.

Je l'ai trouvé assez sympa - il fait tout via des modèles, il est donc très flexible et très rapide.


Éditer:

Après la discussion sur les commentaires et les modifications, j'ai pensé jeter plus d'informations sur les avantages et les inconvénients de certaines implémentations, et pourquoi vous pourriez choisir l'une plutôt que l'autre, compte tenu de votre situation.

GMTL -

Avantages: API simple, spécialement conçue pour les moteurs graphiques. Comprend de nombreux types primitifs orientés vers le rendu (tels que les avions, AABB, quatenrions avec interpolation multiple, etc.) qui ne figurent dans aucun autre package. Très faible surcharge de mémoire, assez rapide, facile à utiliser.

Inconvénients: l'API est très axée spécifiquement sur le rendu et les graphiques. N'inclut pas les matrices à usage général (NxM), la décomposition et la résolution des matrices, etc., car elles sont en dehors du domaine des applications graphiques / géométriques traditionnelles.

Eigen -

Avantages: API propre , assez facile à utiliser. Comprend un module de géométrie avec quaternions et transformations géométriques. Faible surcharge de mémoire. Résolution complète et hautement performante de grandes matrices NxN et d'autres routines mathématiques à usage général.

Inconvénients: la portée peut être un peu plus grande que vous ne le souhaitez (?). Moins de routines spécifiques de géométrie / rendu par rapport à GMTL (ie: définitions d'angle d'Euler, etc.)

IMSL -

Avantages: Bibliothèque numérique très complète. Très, très rapide (soi-disant le solveur le plus rapide). De loin l'API mathématique la plus grande et la plus complète. Soutenu commercialement, mature et stable.

Inconvénients: coût - pas bon marché. Très peu de méthodes spécifiques géométriques / de rendu, vous devrez donc rouler les vôtres au-dessus de leurs classes d'algèbre linéaire.

NT2 -

Avantages: fournit une syntaxe plus familière si vous êtes habitué à MATLAB. Fournit une décomposition et une résolution complètes pour les grandes matrices, etc.

Inconvénients: mathématique, pas de rendu focalisé. Probablement pas aussi performant qu'Eigen.

LAPACK -

Avantages: algorithmes très stables et éprouvés. Je suis là depuis longtemps. Résolution complète de la matrice, etc. De nombreuses options pour les mathématiques obscures.

Inconvénients: Pas aussi performant dans certains cas. Porté depuis Fortran, avec une API étrange pour l'utilisation.

Personnellement, pour moi, cela se résume à une seule question - comment envisagez-vous d'utiliser cela. Si vous vous concentrez uniquement sur le rendu et les graphiques, j'aime Generic Graphics Toolkit , car il fonctionne bien et prend en charge de nombreuses opérations de rendu utiles sans avoir à implémenter les vôtres. Si vous avez besoin d'une résolution de matrice à usage général (par exemple: décomposition SVD ou LU de grandes matrices), j'irais avec Eigen , car il gère cela, fournit certaines opérations géométriques et est très performant avec des solutions de matrice de grande taille. Vous devrez peut-être écrire davantage de vos propres graphiques / opérations géométriques (au-dessus de leurs matrices / vecteurs), mais ce n'est pas horrible.


Avez-vous évalué d'autres bibliothèques avant de décider de GMTL? Une comparaison superficielle m'a amené à croire que Eigen était mieux pris en charge, mais c'est sur la base de l'examen des sites Web respectifs. Connaissez-vous des avantages spécifiques de l'un par rapport à l'autre?
Catskul

Eigen fonctionne bien aussi. Ce n'était pas aussi mature au moment où j'ai mené mon enquête, mais je pense que ce serait une bonne option à ce stade. GMTL a été utilisé assez largement et était très mature et solide lorsque j'ai décidé de l'utiliser.
Reed Copsey

Je suppose que pour réduire ma question à l'essentiel: avez-vous fait votre choix subjectivement comme "Cela semble mieux" ou là où il y avait des fonctionnalités spécifiques (API, vitesse, utilisation de la mémoire, étendue, étroitesse, extensibilité) qui ont fait la différence. Je suppose que la maturité tombe sous ce critère, mais si la maturité était la seule mesure, j'imagine que vous auriez sélectionné une option basée sur BLAS ou LAPACK.
Catskul,

J'ai choisi cela après avoir essayé plusieurs options, et je l'ai basé sur: les performances, la convivialité et le faible temps d'exécution / temps de compilation. Eigen a l'air beaucoup mieux maintenant qu'à ce moment-là, donc je ne peux pas juger entre eux. Cependant, j'ai été très satisfait de GMTL pour nos utilisations.
Reed Copsey

C'est en partie pourquoi j'aime GMTL et je l'ai utilisé. C'était tout simplement très naturel à utiliser et très facile à utiliser. Il a également pris en charge tout ce dont j'avais besoin, dans ce cas, car j'étais juste inquiet de gérer directement la transformation géométrique et les rotations quaternioniques.
Reed Copsey

38

Je suis donc une personne assez critique, et je suppose que si j'investis dans une bibliothèque, je ferais mieux de savoir dans quoi je me mets. Je pense qu'il vaut mieux aller lourdement sur la critique et la lumière sur la flatterie lors de l'examen; ce qui ne va pas a beaucoup plus d'implications pour l'avenir que ce qui est bien. Je vais donc aller un peu trop loin ici pour fournir le type de réponse qui m'aurait aidé et j'espère que cela aidera ceux qui pourraient suivre cette voie. Gardez à l'esprit que cela est basé sur le peu de révision / test que j'ai fait avec ces bibliothèques. Oh et j'ai volé une partie de la description positive de Reed.

Je mentionnerai en haut que je suis allé avec GMTL malgré ses particularités parce que l'insécurité Eigen2 était trop grosse d'un inconvénient. Mais j'ai récemment appris que la prochaine version d'Eigen2 contiendra des définitions qui arrêteront le code d'alignement et le rendront sûr. Je peux donc basculer.

Mise à jour : je suis passé à Eigen3. Malgré ses particularités, sa portée et son élégance sont trop difficiles à ignorer, et les optimisations qui le rendent dangereux peuvent être désactivées avec une définition.

Eigen2 / Eigen3

Avantages: LGPL MPL2, API propre et bien conçue, assez facile à utiliser. Semble être bien entretenu avec une communauté dynamique. Faible surcharge de mémoire. Haute performance. Conçu pour l'algèbre linéaire générale, mais une bonne fonctionnalité géométrique est également disponible. Tous les en-têtes lib, aucun lien requis.

Idiocyncracies / inconvénients: (Certains / tous peuvent être évités par certaines définitions disponibles dans la branche de développement actuelle Eigen3)

  • Les optimisations de performances dangereuses entraînent la nécessité de suivre attentivement les règles. Le non-respect des règles provoque des plantages.
    • vous ne pouvez tout simplement pas passer la valeur en toute sécurité
    • l'utilisation de types propres en tant que membres nécessite une personnalisation spéciale de l'allocateur (ou vous vous plantez)
    • utiliser avec les types de conteneurs stl et éventuellement d'autres modèles requis personnalisation d'allocation spéciale (ou vous planterez)
    • certains compilateurs ont besoin d'une attention particulière pour éviter les plantages lors d'appels de fonction (fenêtres GCC)

GMTL

Avantages: LGPL, Fairly Simple API, spécialement conçu pour les moteurs graphiques. Comprend de nombreux types primitifs orientés vers le rendu (tels que les avions, AABB, quatenrions avec interpolation multiple, etc.) qui ne figurent dans aucun autre package. Très faible surcharge de mémoire, assez rapide, facile à utiliser. Tous basés sur l'en-tête, aucun lien nécessaire.

Idiocyncracies / inconvénients:

  • L'API est originale
    • ce qui pourrait être myVec.x () dans une autre bibliothèque n'est disponible que via myVec [0] (problème de lisibilité)
      • un tableau ou un vecteur stl :: de points peut vous amener à faire quelque chose comme pointsList [0] [0] pour accéder au composant x du premier point
    • dans une tentative naïve d'optimisation, supprimé le cross (vec, vec) et remplacé par makeCross (vec, vec, vec) lorsque le compilateur élimine de toute façon les temps inutiles
    • les opérations mathématiques normales ne renvoient pas de types normaux, sauf si vous désactivez certaines fonctionnalités d'optimisation, par exemple: vec1 - vec2ne renvoie pas de vecteur normal, donc length( vecA - vecB )échoue même si cela vecC = vecA - vecBfonctionne. Vous devez envelopper comme:length( Vec( vecA - vecB ) )
    • les opérations sur les vecteurs sont fournies par des fonctions externes plutôt que par des membres. Cela peut vous obliger à utiliser la résolution de portée partout car les noms de symboles communs peuvent entrer en collision
    • vous devez faire
        length( makeCross( vecA, vecB ) )
      ou
        gmtl::length( gmtl::makeCross( vecA, vecB ) )
      où sinon vous pourriez essayer
        vecA.cross( vecB ).length()
  • pas bien entretenu
    • toujours revendiqué comme "beta"
    • documentation manquante d'informations de base comme les en-têtes nécessaires pour utiliser la fonctionnalité normale
      • Vec.h ne contient pas d'opérations pour les vecteurs, VecOps.h en contient, d'autres sont dans Generate.h par exemple. cross (vec &, vec &, vec &) dans VecOps.h, [make] cross (vec &, vec &) dans Generate.h
  • API immature / instable; toujours en train de changer.
    • Par exemple, "cross" est passé de "VecOps.h" à "Generate.h", puis le nom a été changé en "makeCross". Les exemples de documentation échouent car se réfèrent toujours à d'anciennes versions de fonctions qui n'existent plus.

NT2

Je ne peux pas le dire car ils semblent être plus intéressés par l'en-tête de l'image fractale de leur page Web que par le contenu. Ressemble plus à un projet académique qu'à un projet logiciel sérieux.

Dernière version il y a plus de 2 ans.

Apparemment, aucune documentation en anglais, bien qu'il y ait quelque chose en français quelque part.

Impossible de trouver une trace d'une communauté autour du projet.

LAPACK & BLAS

Avantages: vieux et mature.

Inconvénients:

  • vieux comme des dinosaures avec des API vraiment merdiques

1
Concernant les assertions alignées propres: pour obtenir des performances élevées des opérations SSE (1, 2, 3 ou 4) pour de petits ensembles de données, vous avez absolument besoin de données alignées. Les opérations de chargement / stockage non alignées sont beaucoup plus lentes. La décision entre un chargement / magasin aligné ou non aligné prend également du temps. Toute implémentation "à usage général" aurait vraiment du mal à faire la bonne chose pour tout le monde, à moins qu'ils ne séparent également l'interface en opérations "alignées" et "non alignées" - et là encore, ce n'est tout simplement pas très général.
Joris Timmermans

@Catskul Je voudrais utiliser Eigen3. Pourriez-vous s'il vous plaît développer sur "les optimisations qui le rendent dangereux peuvent être désactivées avec une définition"? Les autres problèmes que vous répertoriez sous Eigen2 sont soigneusement détaillés dans le document sous Rubriques liées aux problèmes d'alignement . Je peux vivre avec ces problèmes.
Ali

Les problèmes de sécurité dont je parle sont tous liés à l'alignement et sont les mêmes que ceux de l'Eigen2. Si vous êtes d'accord avec Eigen2, tout ira bien avec Eigen3.
Catskul

2
BLAS et LAPACK ne sont pas en fait des bibliothèques mais des spécifications / API. vous auriez pu mentionner leurs implémentations initiales par netlib ou d'autres implémentations telles que ATLAS et OpenBLAS.
Foad

12

Pour ce que ça vaut, j'ai essayé Eigen et Armadillo. Voici une brève évaluation.

Avantages propres: 1. Complètement autonome - pas de dépendance vis-à-vis du BLAS externe ou du LAPACK. 2. Documentation décente. 3. prétendument rapide, même si je ne l'ai pas mis à l'épreuve.

Inconvénient: l'algorithme QR ne renvoie qu'une seule matrice, la matrice R étant intégrée dans le triangle supérieur. Aucune idée d'où vient le reste de la matrice, et aucune matrice Q n'est accessible.

Avantages du tatou: 1. Large gamme de décompositions et autres fonctions (y compris QR). 2. Raisonnablement rapide (utilise des modèles d'expression), mais encore une fois, je ne l'ai pas vraiment poussé à des dimensions élevées.

Inconvénients: 1. Dépend du BLAS externe et / ou du LAPACK pour les décompositions matricielles. 2. La documentation manque à mon humble avis (y compris les détails par rapport à LAPACK, autre que la modification d'une instruction #define).

Ce serait bien si une bibliothèque open source était disponible, autonome et simple à utiliser. Je rencontre ce même problème depuis 10 ans, et ça devient frustrant. À un moment donné, j'ai utilisé GSL pour C et j'ai écrit des wrappers C ++ autour de lui, mais avec le C ++ moderne - en particulier en utilisant les avantages des modèles d'expression - nous ne devrions pas avoir à jouer avec C au 21e siècle. Juste mon tuppencehapenny.


2
Armadillo a une syntaxe délibérée de type Matlab, de sorte qu'il est facile à utiliser. Je ne sais pas trop ce que vous voulez dire par "la documentation manque ... les détails par rapport au LAPACK". La documentation documente clairement toutes les fonctions disponibles pour l'utilisateur, ainsi que des exemples d'utilisation. L'intérêt d'une bibliothèque d'encapsuleurs C ++ est d'abstraire la complexité et la verbosité de LAPACK. Vous pouvez toujours parcourir la source si vous voulez voir comment Armadillo appelle LAPACK.
mtall

À propos de la décomposition QR dans Eigen, voulez-vous dire Eigen2 ou Eigen3?
qed

11

Si vous recherchez une matrice haute performance / algèbre linéaire / optimisation sur les processeurs Intel, je regarderais la bibliothèque MKL d'Intel.

MKL est soigneusement optimisé pour des performances d'exécution rapides - en grande partie sur la base des normes fortran BLAS / LAPACK très matures. Et ses performances évoluent avec le nombre de cœurs disponibles. L'évolutivité mains libres avec les cœurs disponibles est l'avenir de l'informatique et je n'utiliserais aucune bibliothèque mathématique pour un nouveau projet ne prenant pas en charge les processeurs multicœurs.

Très brièvement, il comprend:

  1. Opérations vectorielles, vectorielles et matricielles de base
  2. Factorisation matricielle (LU decomp, hermitian, sparse)
  3. Ajustement des moindres carrés et problèmes de valeurs propres
  4. Solveurs de systèmes linéaires clairsemés
  5. Solveur des moindres carrés non linéaire (régions de confiance)
  6. Plus des routines de traitement du signal telles que la FFT et la convolution
  7. Générateurs de nombres aléatoires très rapides (torsion de mersenne)
  8. Beaucoup plus .... voir: texte du lien

Un inconvénient est que l'API MKL peut être assez complexe en fonction des routines dont vous avez besoin. Vous pouvez également jeter un coup d'œil à leur bibliothèque IPP (Integrated Performance Primitives) qui est orientée vers des opérations de traitement d'image hautes performances, mais qui est néanmoins assez large.

Paul

Logiciel CenterSpace, bibliothèques mathématiques .NET, Centerspace.net


8

J'ai entendu de bonnes choses sur Eigen et NT2 , mais je ne les ai pas utilisées personnellement non plus. Il y a aussi Boost.UBLAS , qui, je crois, devient un peu long dans la dent. Les développeurs de NT2 sont en train de construire la prochaine version avec l'intention de l'intégrer dans Boost, donc cela pourrait compter pour quelque chose.

Mon lin. alg. les besoins ne dépassent pas le cas de la matrice 4x4, donc je ne peux pas commenter les fonctionnalités avancées; Je souligne simplement quelques options.


D'après mon expérience (matrices plus grandes), Boost.UBLAS est plus utilisé. Cependant, quand je l'ai examiné, je ne l'aimais pas (principalement à cause de la documentation) alors je me suis concentré sur Eigen. Eigen a un module de géométrie , mais je ne l'ai pas utilisé moi-même.
Jitse Niesen

Eigen est apparemment utilisé par ROS (saule garage), Celestia, Koffice et libmv. Je vois des bavardages sur UBLAS, mais j'ai eu du mal à trouver un projet qui annonce qu'il l'utilise. Idem pour NT2. Pouvez-vous nous expliquer quelles bonnes choses vous avez entendues?
Catskul

C'était dans une discussion sur la liste de diffusion Boost sur l'ajout d'une bibliothèque LinAlg moderne à Boost - Eigen et NT2 ont tous deux été mentionnés comme candidats possibles, mais seuls les développeurs NT2 ont exprimé leur intérêt à la poursuivre. Les deux bibliothèques semblaient décentes; comme vous l'avez dit, Eigen est un peu plus populaire, et aussi plus C ++ - ish; NT2 est conçu pour imiter MATLAB autant que possible.
Jeff Hardy

8

Je suis nouveau sur ce sujet, donc je ne peux pas en dire beaucoup, mais BLAS est à peu près la norme en informatique scientifique. BLAS est en fait une norme API, qui a de nombreuses implémentations. Honnêtement, je ne sais pas quelles implémentations sont les plus populaires ni pourquoi.

Si vous voulez également pouvoir effectuer des opérations d'algèbre linéaire courantes (résolution de systèmes, régression des moindres carrés, décomposition, etc.), examinez LAPACK .


7

Et GLM ?

Il est basé sur la spécification OpenGL Shading Language (GLSL) et publié sous la licence MIT. Destiné clairement aux programmeurs graphiques


eh bien, il fournit un vecteur de programmation graphique et des matrices. il introduit une bonne quantité de surcharge pour rester conforme à GLSL (si vous pouvez le faire dans GLSL, la plupart du temps, c'est mieux dans GLSL, surtout avec GL 4.x), et manquer de nombreuses primitives de programmation graphique (frustum, AABB, BB, ellipsoid ). Son interface swizzle est obèse. Une bien meilleure alternative serait d'avoir des fonctions ".xyzz ()" générées avec une certaine génération de code. Il est parfait lorsque vous devez prototyper des applications opengl et commence à montrer ses côtés négatifs sur des projets plus importants. ne codez jamais une bibliothèque de mathématiques.
CoffeDeveloper

5

J'ajouterai un vote pour Eigen: j'ai porté beaucoup de code (géométrie 3D, algèbre linéaire et équations différentielles) de différentes bibliothèques à celle-ci - améliorant à la fois les performances et la lisibilité du code dans presque tous les cas.

Un avantage qui n'a pas été mentionné: il est très facile d'utiliser SSE avec Eigen, ce qui améliore considérablement les performances des opérations 2D-3D (où tout peut être complété à 128 bits).


1
Le tout "si vous faites cela, alors assurez-vous de ..." me semble être un peu un drapeau rouge. Jusqu'à présent, j'ai rencontré deux fois ces problèmes et je viens de commencer à l'utiliser. J'espérais vraiment ne pas inciter les futurs développeurs à connaître toutes sortes d'idiosyncrasies de chaque bibliothèque incluses: en particulier les problèmes d'alignement où elle se bloque si vous n'utilisez pas certaines macros à chaque fois que vous avez des membres, et le fait qu'ils ont réparti les fonctionnalités pour chaque individu classes sur plusieurs en-têtes. Seul, cela ne m'empêchera peut-être pas de le choisir, mais c'est un peu un drapeau rouge.
Catskul

1
L'alignement et cette macro n'ont d'importance que si vous utilisez SSE, ce qui n'est en aucun cas requis. Et si vous utilisez SIMD, ces problèmes augmenteront quelle que soit la bibliothèque que vous utilisez. Au moins Eigen ne se bloque pas seulement, mais fournit des messages d'erreur significatifs qui pointent directement vers le problème.
ima

Et il existe un moyen simple d'éviter les macros d'alignement: utilisez des pointeurs ou des références en tant que membres.
ima

1
Je ne pense pas que ce soit vrai. Je n'ai utilisé aucune option SSE spéciale et j'ai eu plusieurs plantages après l'avoir utilisé avec des conteneurs stl. Oui, je sais que cela vous donne des messages utiles, et Oui, je sais qu'il y a des instructions spéciales, mais c'est mon point. Je ne veux pas imposer aux autres développeurs des instructions spéciales pour chaque bibliothèque incluse. La chose ne pas passer par valeur, par exemple, est tout simplement trop.
Catskul

Je viens de découvrir que la dernière branche de développement a des définitions que vous pouvez utiliser pour désactiver l'alignement et éviter les problèmes liés.
Catskul

4

D'accord, je pense que je sais ce que vous cherchez. Il semble que GGT soit une assez bonne solution, comme l'a suggéré Reed Copsey.

Personnellement, nous avons lancé notre propre petite bibliothèque, car nous traitons beaucoup de points rationnels - beaucoup de NURBS et de Béziers rationnels.

Il s'avère que la plupart des bibliothèques graphiques 3D effectuent des calculs avec des points projectifs qui n'ont aucune base en mathématiques projectives, car c'est ce qui vous donne la réponse que vous voulez. Nous avons fini par utiliser les points Grassmann, qui ont une solide base théorique et ont diminué le nombre de types de points. Les points de Grassmann sont essentiellement les mêmes calculs que ceux que nous utilisons actuellement, avec l'avantage d'une théorie robuste. Plus important encore, cela rend les choses plus claires dans nos esprits, nous avons donc moins de bugs. Ron Goldman a écrit un article sur les points Grassmann en infographie appelé "Sur les fondements algébriques et géométriques de l'infographie" .

Pas directement lié à votre question, mais une lecture intéressante.


C'est intentionnellement illimité dans la mesure où je ne suis pas au courant des compromis. Il est probablement juste de dire que la géométrie est notre principale préoccupation, la dimensionnalité de la géométrie n'est pas claire. Actuellement, il est de 2/3 (2 + temps) et pourrait théoriquement être assez élevé (3dims + temps + multi-dim-costmaps).
Catskul

Je suis d'accord avec la question. Par exemple, de nombreuses applications de ce type nécessitent des performances en temps réel (comportement dans le temps cohérent), tandis que de nombreuses autres sont très bien abandonnant la cohérence et / ou la vitesse pour plus de précision.
TED le

Alors, vous dites que parmi les bibliothèques que vous avez étudiées, aucune ne s'est occupée de NURBS et de Béziers? Une raison particulière pour ne pas prendre l'une des bibliothèques existantes et construire le support NURBS et Bézier à côté d'elle?
Catskul

Ce que j'essayais de dire, c'est que les NURBS rationnels et Béziers utilisent beaucoup plus de points de contrôle rationnels que la plupart des applications 3D, donc nous faisions plus d'erreurs. En règle générale, la plupart des applications 3D n'ont que des points et des vecteurs 3D vanille jusqu'à ce que la transformation de perspective soit terminée. Beaucoup de nos algorithmes doivent être capables de gérer correctement les points pondérés / rationnels / projectifs et cartésiens, les allers-retours, etc.
tfinniga


En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.