Raydium 3D Game Engine

Bonjour à tous,
Je recherche un moteur 3D adapté à mon projet.
Je cherche à créer un logiciel 3D dont le but est de modéliser une scène d'intérieur (genre salon) dans lequel je peux ajouter de façon dynamique des objets (chaises, tables, ...).
L'objectif est de créer son intérieur et de placer une source de lumière dont l'algorithme de propagation du faisceau lumineux est défini par moi via un certain nombre d'algo. Je sougaite donc à un instant donné lancer une simulation de la propagation de la lumière dans ma scène (la simulation peut prendre qq heures) et ensuite de visualiser l'eclairage en 3D.
Pour celà, j'ai besoin d'un moteur 3D qui me permette de calculer l'eclairage de la scène et qui implémente donc des algos de radiosité assez poussés.
Raydium me permet-il de faire celà ?
J'envisage de créer mes objets sous 3DSMax, je crois que Raydium gère l'import de ces formats.
J'envisageais d'utiliser un moteur 3D gérant le lightmap et de créer ce lightmap via FSRAD ! Mais, j'ai quelque soucis au niveau de ce calcul (utilisation d'un export .ASE de 3DSMax avec FSRAD).
Dernier point, j'ai un projet dont la finalité est commerciale... ai-je des contraintes de licences avec Raydium.
Merci à vous.

Salut !

Je ne suis pas sûr de comprendre la totalité de ta question. D'un coté, tu sembles disposer toi même d'algo de calcul de radiosité, et d'autre part, tu sembles demander ces capacités au moteur de rendu ("algos de radio assez poussés"). Pourquoi ? Et quel est le rôle de FSRad, dès lors ?

Au delà de cette incompréhension de ma part, voilà ce que je peux te dire sur ce sujet avec Raydium à l'heure actuelle :
- Raydium sait importer des données depuis 3DS. Il y a deux vecteurs pour ça : l'utilisation de fichiers .3ds avec notre "iconv" modifié (vieille méthode) ou le passage par des fichiers DirectX (.x, texte, nouvelle méthode) que 3DS sait exporter facilement (plugin gratuit).
- Raydium sait -rendre- la radiosité, grace au multitexturing, mais en aucun cas la calculer (ce n'est pas son rôle).
- Nous avons notre propre version de FSRad ("FSRadRay") qui sait travailler directement sur des fichiers .tri (entrée et sortie). Je suis en train de bosser sur un projet pro en ce moment même qui utilise cette partie du moteur, dont voilà un rapide aperçu sur le vif : http://ftp.cqfd-corp.org/raycap2007-04-04-160939-00.jpg
- Raydium est livré actuellement sous GPL, ce qui signifie que tout code source lié à Raydium doit être lui aussi livré sous GPL (ou compatible) en cas de distribution de l'application en question.
Reste qu'il a déjà été question de passer Raydium sous double licence GPL/BSD, cette dernière étant non-restrictive dans ce cas. Si ton projet avance, je concrétiserais ce changement de licence sans problème.

Merci pour ces réponses.
Je vais essayer d'être un peu plus clair.
J'ai besoin d'eclairer ma scène selon des sources lumineuses "custom". En fonction de certains paramètres (longueurs d'onde, ...), j'ai des algos qui sont sensés me fournir la largeur du faisceau, le field of view (largeur angulaire du faisceau si celui-ci est diffus), ...
Donc, je ne dispose pas d'algo de calcul de radiosité mais les algos qui me permettent de caracteriser ma source lumineuse.
Du coup, je pensais passer par FSRAD pour générer le lightmap qui va bien.
FSRAD intègre l'algo de calcul de radiosité et est capable de générer le lightmap pour ma scène, c'est bien ça ? Sur quelle source se base-t-il, puis-je et comment puis-je definir les caractéristiques de mon émetteur ?
Pour le resultat de ma simu, je veux par exemple avoir d'une certaine couleur les zones bien éclairées et d'une autre les zones plus sombres.
Autre chose, Raydium gère-t-il les collisions ?
Merci.

Bon, visisblement, mes (faibles) compétences en optique m'empêchent de comprendre les détails de ta démarche
Le fait est que FSRad sait calculer des lightmaps par radiosité, à partir de lumières déterminées dans la scène (cf les formats supportés par l'appli). Par contre, sauf si c'est justement le but de tes algos, j'ai du mal à imaginer comment arriver à ton exemple (zones éclairées d'une couleur, les mal éclairées d'une autre).

D'autre part, notre version de FSRad, FSRadRay, se base sur un fichier généré par un script Blender (probablement trop simpliste pour ton utilisation, puisque limité à une puissance, couleur et orientation.

Enfin, Raydium intègre ODE, qui est un moteur physique complet (simulation des corps rigides). Aucun problème, dès lors, pour la gestion des collisions.

Merci à nouveau pour ces précisions.
Vous utilisez FSRAD avec un script qui est généré de façon statique sous blender.
Je cherche à générer le lightmap de façon dynamique dans mon appli.
Pour celà, j'envisageais de modifier FSRAD et de le linker à mon appli.
Concernant la couleur pour les zones d'eclairage + ou - intenses, je n'ai pas trop d'idées pour l'instant.

... mais ça va prendre un temps fou ? Tu cherches pas à faire du temps réel alors ?

Absolument pas, si la simu me prend toute la nuit, c'est pas un problème.
Le temps d'un café pour une version moins performante.
Je n'ai pas les contraintes que vous pouvez rencontrer dans un jeu par exemple.
Avec ces nouvelles informations (c'est un peu plus clair), tu penses que Raydium peut faire l'affaire ? Du moins un FSRAD "customisé".
L'idée c'est d'avoir une appli basée sur un moteur 3D qui gère le ligthmap avec mes algos et l'outil de radiosité linkés ensemble.
Je paramètre mes algos de façon dynamique via l'IHM, je calcule le lightmap à partir d'un algo de radiosité, genre FSRAD, à partir des paramètres que j'obtiens de mes algos à moi (intensité, angle, largeur angulaire, ...), je "calque" le lightmap à ma scène et au bout de 12h, j'ai une super scène éclairées !!! Youpi.
C'est possible ?
A voir avec le fait d'associer différentes couleurs aux zones de réception.
Merci.

Effectivement, tes contraintes sont différentes de celles des utilisateurs habituels de Raydium. En général, 400ms, c'est déjà "un temps énorme" quand on est censé rendre 30 frames par seconde . Alors le temps d'un café ...


Il me semble que oui, même si il n'y a pour ainsi dire aucun lien entre FSRad et Raydium. Le principal problème en fait va être la gestion des différents formats de fichiers entre tout ce beau monde ...

Si je résume pour la partie Raydium de ta question : tu souhaites utiliser le moteur pour rendre des lightmaps calculées avec un autre outil (FSRad en l'occurence) ?

Oui, pour l'histoire des formats, j'ai bien vu que ça n'allait pas être simple.
J'ai notament essayé de générer le ligthmap d'un scène 3DSMAx exportée en .ASE ! Et bien, quand je ne me retrouve pas avec un message d'erreur windows (apparement FSRAD n'aime pas mes scènes sans texture), FSRAD plante vers 99% (pas assez de mémoire ou un truc comme ça).
Ai-je d'autres possibilités ?
FSRAD gère le .ASE, .OCT, .ENT.
AUtre chose, lui connais-tu des contraintes liées à la taille de la scène ? Ou autres paramètres ?

Oui, c'est l'idée.
En fait, je cherchais à l'origine un moteur 3D qui intègre déjà la radiosité... et y'en a pas 50000. Bon, j'ai quelques soutions qu'il faut que j'étudie egalement.
Sinon, y'a-t-il moyen de prendre en compte le pâramètre de reflexion de mes objets pour le calcul de l'illumination ? D'ailleurs comment est stockée cette info ?

Dernier point, peut-on bosser sous visual studio avec Raydium ?
Merci

Re,
J'ai peur de ne pas être la personne la plus appropriée pour assurer le support de FSRad

Pour l'utilisation de Visual Studio avec Raydium, faute de volontaire pour l'assurer, nous n'avons pas de support officiel. Cependant, une documentation existe à ce propos sur le Wiki : http://wiki.raydium.org/wiki/RaydiumWindows

Bonjour,

J'avais essayé de compiler Raydium sous Vs.

Le plus gros problème venait d'ode 0.5 (et de probleme de lib gcc).

Les ide code blocks, dev cpp, mingw studio rendent l'utilisation de Vs très facultative.

Enfin la valse des versions de Visual studio rends la maintenance encore plus complexe.

En conclusion c'est faisable, mais est-ce bien utile ?

A+
Ouille