Salut,
Je vais considérer qu'on parle ici de la version Linux de Raydium, même si ces réponses sont transposables sous windows.
En ce qui concerne la place des binaires, Raydium se présente comme une bibliothèque partagée (Shared Object ou DLL). Les programmes qui utilisent Raydium n'ont alors que leur propre code à supporter. Par exemple, l'application test6 (un FPS complet) ne pèse que 58 Ko. En revanche (et en conséquence), la bibliothèque en elle même pèse plus de 15 Mo, taille que l'on retrouve au niveau des binaires statiques par exemple.
Cette taille se justifie à mon sens non pas comme une conséquence de la simplicité d'utilisation du moteur, mais bien de la liste de ses fonctionnalités.
Et dans le petit monde des moteurs de jeu libres, le rapport taille/fonctionnalités de Raydium est pas trop mauvais
En ce qui concerne la comparaison à des moteurs comme Irrlicht, Crystal Space ou Ogre3D, l'exercice est difficile, surtout pour moi (il est forcément difficile d'être objectif).
Voilà quelques éléments de réponse :
- Un extrait du wiki de Raydium :
Quote:
Dans le monde libre, il existe bien sur d'autres moteurs 3D/de jeu, dont certaines grosses pointures (Ogre, Crystal Space, ...). Raydium ne cherche pas à atteindre le degré de complexité que l'on retrouve dans ces moteurs, mais bien au contraire de permettre un développement rapide et simple. Un bon exemple de cette simplicité est NewSkyDiver, qui tient sur moins de 750 lignes de code.
- Une réponse donnée à Greg (
http://overstorm.dyndns.org/MonWiki/) par mail pour une question du même genre :
Quote:
Raydium vise avant toute chose la simplicité, à un tel point que je ne pense pas qu'il soit raisonnable de le comparer à Crystal Space ou à Ogre.
Si je me suis lancé dans l'écriture de Raydium, c'était initialement pour placer une couche d'abstraction devant OpenGL pour pouvoir découvrir plus rapidement les possibilités de cette API. Le tout à complètement dérivé de son but initial pour devenir le "moteur de jeu" qu'il est maintenant, mais en suivant cette logique de simplification qu'il l'a fait naître.
De manière générale, le développement d'applications 3D "modernes" exige énormément de temps et de compétences, ce qui me semblait ingérable : je n'ai que de faibles compétences mathématiques, et je suis relativement vite lassé du développement d'une appli si je n'avance pas assez vite dans son écriture. Raydium est donc devenu un outil simplifiant à l'extrême tout ce qui touche à la physique, au son, à l'affichage, au réseau, etc, de façon à pouvoir se concentrer sur le coeur des l'applis.
La contrepartie immédiate est que cette "isolation" entre l'application et le moteur réduit la souplesse et la liberté de l'appli, à l'inverse justement des gros moteurs cités plus haut, Raydium automatisant énormément de choses.
D'autre part, les applications visées sont beaucoup plus petites pour Raydium qu'elles ne le sont avec un produit comme Crystal Space.
Concrètement, un projet très représentatif de ce moteur est PlaneShift, un énorme MMORPG en travaux depuis plusieurs années. Du coté de Raydium, ce sont plus des jeux comme NewSkyDiver, projet de 2 ou 3 semaines, sur moins de 800 lignes de code (ce qui ne l'empêche pas d'être un jeu complet et plutôt bien accueilli).
En bref et pour imager, si tu préfères mettre en place un véhicule "physique" en quelques minutes et t'amuser quasi instantanément avec en réseau, Raydium est pour toi. Si en revanche, ton orientation est plus de mettre en place une analyse UML sur le long terme et de décrire 10 classes avant de commencer à coder la première des 1000 lignes qui vont te permettre de construire un pneu, alors Crystal Space est pile ce qu'il te faut.
Raydium possède plusieurs défauts :
* Très orienté Linux (fonctionne à merveille sous Windows, mais on ne dispose d'aucun kit ni d'aucune doc d'installation sur cette plateforme) (ps : c'est faux maintenant
).
* Très orienté vers les jeux
* Doc pas encore complète sur les domaines avancés (ça avance ceci dit)
* Pas d'orientation objet
* Très peu de projets utilisant Raydium existent en dehors de ceux développés par l'équipe elle même (risque que ta vision du "problème" ne soit pas la même que la notre)
Pour les avantages suivants (en plus de ce qui est déjà sur le wiki) :
* Forte réactivité de l'équipe
* (je radote mais c'est important) Simple
* Pas d'orientation objet (c'est aussi un avantage
* ODE n'est pas simplement disponible, mais bien "intégré" dans le moteur (contrairement aux autres moteurs qui se limitent souvent à proposer l'API originale d'ODE)
* API ultra stable (aucune rupture majeure de compatibilité depuis le début du développement)
* Moteur varié avec des idées originales (captures d'écran 3D, réseau distribué, ...)
En gros, voilà ce que je pense qu'il faut que tu saches, après c'est à toi de faire ton choix. Ceci dit, si tu utilises Linux et que tu as déjà des pilotes 3D installés, le test de Raydium devrait être quelque chose de rapide, pour te faire une idée de la chose. Les tutoriels du wiki sont une autre façon de découvrir la "logique" du moteur."
Quand au choix du C, il était motivé à l'époque par des problèmes de compétences
Maintenir sur le long terme une API objet demande une certaine expérience que je ne me sentait pas capable d'assumer à l'époque. Avec le recul actuel que l'on a sur le projet, il est clair que l'API "plate" de Raydium est l'une des raisons majeures pour lesquelles le projet ne s'est pas écroulé en grossissant. C'est aussi une des raisons qui fait de Raydium un moteur simple.
J'avoue qui si je devais reprendre le projet à zéro maintenant, ma réponse serait peut être différente (Java ?).