Raydium 3D Game Engine

Script et README dispo à cette URL:
http://raydium.cqfd.ath.cx/data.php?nom_rep=blender

C'est un début, mais ca tourne pas trop mal.. j'attend des retours des utilisateurs de Blender pour voir comment faire évoluer le truc.

PS: Ouverture d'un script Python dans Blender:
Shift+F11, Open Datablock, ALT+P dans la fenetre du script.

moi j'ai fait un script de convertion wrl2gl
http://web3d.tuxfamily.org/downloads/

> Ce script va convertir les meshs Blender vers Raydium (.tri)
> Le modele Blender doit etre a base de triangles seulement, donc il
> faut selectionner les objets de votre modele, passer en mode edition (TAB),
> selectionner tt les vertices (A) et passer le tout en triangles (CTRL+T).

Je viens d'apprendre les premières bases d'openGL et il semblerait bien que la convertion des facettes à 4 côtés en triangles est superflue pour les facettes à 4 côtés dont les points sont coplanaires !

cf les 2 premiers didacticiels openGL sur linuxgraphic.org :
http://www.linuxgraphic.org/section3d/o ... idact.html


> Ce script a ete teste sur les version 2.25 et 2.26 de Blender, il est capable
> d'exporter les textures, ou passe l'objet en gris s'il n'en trouve pas.
> Les textures utilises pour Raydium doivent etre en TGA, non compressees et
> avec une origine NON en bas a gauche.

L'utilisation d'images .JEPG ne semble pas très compliquée :
cf didacticiel N° 6 et 7 sur linuxgraphic.org :
http://www.linuxgraphic.org/section3d/o ... idact.html

Pour ce qui est des points de facettes quadrilatères coplanaires je vais essayer de programmer un truc pour vérifier leur coplanarité

Je ne sais pas trop si j'en serais vraiement capable, mais au cas où, est-ce que je pourrais avoir la charge de la gestion des data-3D dans Raydium/meuleMaker ? C'est à dire m'occuper du format de stockage des data-3D, de leur chargement dans le moteur, etc...
bon attention je débute tout juste en C donc il faudra être patient mais j'aimerais beaucoup m'y faire les dents avec cet exercice.

Bien:
L'utilisation des triangles est la seule option viable, pour plusieurs raisons:
- Le matériel n'est optimisé que pour ce type de données (tout les moteurs utilisent au final des triangles, même s'ils doivent convertir les polygones en triangles au chargement)
- Vérifier le fait que les 4 points d'un quad (ou plus) soient coplanaires coute plus cher (il faut comparer les normales) que de splitter ce quad en 2 triangles. Il faut également voir que seul le triangle interdit la génération des formes concaves, qu'OpenGL ne sait pas gérer
- Utiliser le même type de données tt le long du pipeline de rendu (que des triangles dans notre cas) est un gage de rapidité énorme ! Les données sont uniformes, et les tests sont d'autant plus simples
- Le script Blender n'est proposé ici que comme une base ! Il n"a rien de définitif, alors bien sur, l'utilisation des JPG et PNG dans Raydium n'est qu'une affaire de minutes (libpng et libjpg) mais n'est absolument pas prioritaire ! Convertir une JPG en TGA ne me semble pas une tache complexe (Le format TGA offre pas mal de facilités bien pratiques pour le chargement de textures)

Pour moi la conclusion est: est-il vraimment si génant de faire un coup de CTRL+T avant l'export (pkoi ne pas l'automatiser à partir du script ?) et d'utiliser pour l'instant (il s'agit bien de qq chose de temporaire) des TGA ?

En ce qui concerne la manipulation des données 3D, les sources sont dispos sur le site de Raydium, section "files" .. voir file.c pour les actuelles fonctions de chargement (changent souvent !), et un post dans la section Dev de ce forum qui expose les types de fichiers utilisés.

A+

> L'utilisation des triangles est la seule option viable, pour plusieurs raisons:
> - Le matériel n'est optimisé que pour ce type de données (tout les moteurs utilisent au final
> des triangles, même s'ils doivent convertir les polygones en triangles au chargement)

Ok, je vais opter pour le tout triangle alors :)

> - Vérifier le fait que les 4 points d'un quad (ou plus) soient coplanaires coute plus cher (il
> faut comparer les normales) que de splitter ce quad en 2 triangles. Il faut également voir que
> seul le triangle interdit la génération des formes concaves, qu'OpenGL ne sait pas gérer

c'était au niveau du script d'export que j'aurais pensé faire çà.

> Pour moi la conclusion est: est-il vraimment si génant de faire un coup de CTRL+T avant
> l'export

Oui c'est génant car c'est source d'erreurs potencielles.
Si on sauvegarde après avoir fait Ctrl_T au lieu d'avant, on perd notre maillage propre ce qui sera génant pour le retravailler ultérieurement.

> (pkoi ne pas l'automatiser à partir du script ?)

çà c'est une très bonne idée !
Le script d'export n'ayant pas l'air très compliqué, je vais essayer de faire çà.

> et d'utiliser pour l'instant (il s'agit bien de qq chose de temporaire) des TGA ?

On va dire qu'on va automatiser çà dans le script aussi :)
car le faire à chaque fois à la mains, pfff, j'en suis fatigué d'avance :)))
(oui je sais je suis une grosse faignasse:)
s'il s'agit de faire tout un monde avec gavé d'objets il vaut mieux éviter les manip inutiles et sources d'erreurs

> En ce qui concerne la manipulation des données 3D, les sources sont dispos sur le site de
> Raydium, section "files" .. voir file.c pour les actuelles fonctions de chargement (changent
> souvent !), et un post dans la section Dev de ce forum qui expose les types de fichiers
> utilisés.

Ok, je v d'abord continuer a faire des petits bricolages perso pour me faire la mains, et après j'essayerais de voir si j'arrive à bricoler avec vous.

Vi.. au niveau du moteur 3D c'est de toutes facons absolument nécessaire.. maintenant, rien n'empeche les fonctions de chargement de faire le boulot pour découper les quads ou n-gons en triangles (pas du tout évident pour les ngons).

Ok, mais si ton quad est bien dans un même plan... tu en fait quoi ?


En effet, ca risque d'être une source d'erreur assez fréquente
N'hésite pas à voir si ca peut être fait (puis annulé !) à partir du script lui même.. à ce propos, j'ai noté avec RyLe que dans certains cas, la "triangulisation" ne se fait pas entierement du premier coup ! ... il faut ré-éditer les points après le premier CTRL+T et relancer un autre CTRL+T ...
Il serait aussi idéal (je pense) que le script fasse un "rem. double", non ?


En ce qui concerne les TGA, pkoi ne pas bosser directement avec des textures en TGA ?
J'imagine que blender sait manipuler ce format (il y arrive très bien avec les .RGB, y'a pas de raison ) qui en plus est non-destructif ! Que demande le peuple ?!


Donc, tes taches sont:
- modif script python
- chargement / export en VRML 2 depuis Raydium ?

N'hésite pas à bosser directement dans les sources de Raydium (file.c et object.c), puisque tu disposes de tout ce qu'il te faut pour visualiser le résultat de ton chargement (cf raydium_modler)

> > Ok, je vais opter pour le tout triangle alors
>
> Vi.. au niveau du moteur 3D c'est de toutes facons absolument nécessaire..
> maintenant, rien n'empeche les fonctions de chargement de faire le boulot
> pour découper les quads ou n-gons en triangles (pas du tout évident pour les ngons).

Avec Blender il n'y a pas de n-gons avec n > 4 pour l'instant.


> > c'était au niveau du script d'export que j'aurais pensé faire çà.
>
> Ok, mais si ton quad est bien dans un même plan... tu en fait quoi ?



Mais bon vu que tu m'a démontré que c'était beaucoup moins performant, je n'insiterais plus


> > Oui c'est génant car c'est source d'erreurs potencielles.
> >
> > Si on sauvegarde après avoir fait Ctrl_T au lieu d'avant, on perd notre maillage propre ce
> > qui sera génant pour le retravailler ultérieurement.
>
> En effet, ca risque d'être une source d'erreur assez fréquente
> N'hésite pas à voir si ca peut être fait (puis annulé !) à partir du script lui même.

J'aurais plutôt pensé à une écriture directe genre :


> à ce propos, j'ai noté avec RyLe que dans certains cas, la "triangulisation" ne se fait
> pas entierement du premier coup ! ... il faut ré-éditer les points après le premier CTRL+T
> et relancer un autre CTRL+T ...

Avec la solution ci-dessus pas de Ctrl_T, donc pas de problème


> Il serait aussi idéal (je pense) que le script fasse un "rem. double", non ?

oui, un équivalent en python ca ne devrait pas être compliqué, car l'infographiste pourrait éventuellement ne pas vouloir que le script n'affecte l'intégrité de son fichier.


> En ce qui concerne les TGA, pkoi ne pas bosser directement avec des textures en TGA ?
> J'imagine que blender sait manipuler ce format (il y arrive très bien avec les .RGB,
> y'a pas de raison ) qui en plus est non-destructif ! Que demande le peuple ?!

ah bin oui effectivement...
Ah mais ce qu'il est bien cet homme là, il a la solution à tous les problèmes


> > Ok, je v d'abord continuer a faire des petits bricolages perso pour me faire la mains,
> > et après j'essayerais de voir si j'arrive à bricoler avec vous.
>
> Donc, tes taches sont:
> - modif script python

Je m'y attèle dès que possible,
mais l'idéal serait que j'ai un raydium/meulMake qui marche avant pour tester vraiement.
D'ailleur ce serait bien si l'install pouvait se faire avec le système de dépendance dont Willou a parlé pour pas affecter son système. l'idéal serait même une option --prefix dans le ./configure pour pouvoir créer un utilisateur raydium et lui installer tout çà dans son home (avec l'intégralité des deps inclue)

> - chargement / export en VRML 2 depuis Raydium ?

Ah bon ?
* bluePrawn qui se redresse et tend l'oreille avec l'oeil qui brille *
cette fonctionnalité serait-elle sérieusement envisagée ?
* se replonge dans son bouquin de C pour pouvoir la faire *

> N'hésite pas à bosser directement dans les sources de Raydium (file.c et object.c),
> puisque tu disposes de tout ce qu'il te faut pour visualiser le résultat de ton chargement (cf raydium_modler)

y'a que 2 fichiers sources pour l'instant ?

> mais l'idéal serait que j'ai un raydium/meulMake qui marche avant pour tester vraiement.

il est prévu pour quand le MDL raydium ))

Eh... j'avais même pas pensé à le faire depuis le script lui même, héhé
Attention tout de même à cette approche: OpenGL se base sur le sens (trigo/anti-trigo) du dessin des vertexs pour déterminer les faces avants et arrières d'un triangle, donc...

A ce propos, vous, Blenderiens, savez vous comment Blender gère les faces singles-sided ? .. pour l'instant, il est nécessaire de modifier la gestion des faces de Raydium en double-sided pour que les meshs exportées depuis Blender passent correctement.. sinon, gros prb sur les normales ! ... y'a t'il un moyen de lui dire de recalculer tt les faces "vers le haut" ou trucs du genre ?



Vi, je suis d'accord qu'il faut lui laisser son fichier dans un état correct mais justement, n'y a t'il pas moyen de faire un "gros undo" (tm) à la fin de l'export ? Dans l'ensemble, je trouve dommage de se re-taper le boulot en python à la place de Blender (m'enfin ca ne me gêne pas, après tout ), alors pkoi faire dans le script un truc du genre:

Ce prb est mineur, de tt facons, mais voilà mon avis à 2 cents


:p Ok, heu... explications:
Mon role dans cette affaire est avant tout dans le code.. je n'ai pas (trop) d'avis philosophique sur la question des formats de fichiers 3D (à tord ?), tout ce qui m'a poussé à d'abord utiliser le format 3DS, c'est sa disponibilité sur le net ! .. j'avais besoin de meshs, et j'étais incapable d'en faire
Donc, direct à la solution la plus simple: import 3DS.
Maintenant, le but étant d'ouvrir le projet le plus possible, en particulier aux infographistes, il est clair que le VRML me semble une solution géniale... tout ce qui m'importe, c'est que les données soient feedées correctement dans Raydium, après tout
Donc oui, cette solution est envisagée sérieusement


Non ! mais "file.c" en particulier et pkoi pas "object.c" sont les fichiers responsables du chargement et de la manipulation des "objets" (meshs) et c'est là que ton bonheur se trouve, à priori



Vi, on est bien d'accord


Et c'est là que je ne comprend pas/plus ... qu'y a t'il de "genant" dans la facon actuelle de présenter les sources ?
Ok, les dépendances ne sont pas vérifiées avant la compil, mais elles sont connues et (TRES) volontairement légères !, pour rappel: OpenGL, GLUT, GLU, OpenAL, et maintenant ODE.
Au dela de ca, Raydium reste d'ailleurs confiné au home de l'utilisateur...
J'ai manqué qq chose ? Ou willou à t'il proposé ca ? (pas souvenir d'en avoir parlé) .. il est clair qu'il nous faut qq chose de plus propre à terme, donc autant en parler maintenant

> y'a t'il un moyen de lui dire de recalculer tt les faces "vers le haut" ou trucs du genre ?

Tab puis Crtl_A puis :
Ctrl_N pour recalculer les normales vers l'extérieur du model (pour une roue par exemple qui doit être vue de l'extérieur du model) ou
Ctrl_Shift_N pour recalculer les normales vers l'intérieur du model (pour une fly box, une pièce, un hanger ou tout autre objet vu de l'intérieur)

> Pseudo code (si si):
> sauver tout dans un truc temporaire
> modifier la mesh pour notre tembouille
> parcourir les faces, exporter...
> effacer tout
> recharger le truc temporaire

ou plutot
Pseudo code
récup tout dans un truc temporaire*
modifier le truc tmp pour notre tembouille
parcourir les tmp_faces, les exporter...
fin


* : une variable quoi


> Donc, direct à la solution la plus simple: import 3DS

Tu trouveras également pleins de trucs sur le wouéb en VeuRMLeu
et en plus l'avantage c'est que ce sera du low-meshing et non du high,
donc tout bénèf' pour faire du temps réel
Et en plus y'en a plein qui sont UV mappé et tout et tout !



j'en salive d'avance