Raydium 3D Game Engine

Official forum for everything about Raydium, ManiaDrive, MeMak, ...
It is currently Thu Mar 28, 2024 3:24 pm

All times are UTC




Post new topic Reply to topic  [ 28 posts ]  Go to page Previous  1, 2
Author Message
 Post subject:
PostPosted: Tue Nov 18, 2003 10:38 pm 
Offline
User avatar

Joined: Sun Mar 16, 2003 2:53 am
Posts: 2591
Location: gnniiiii (Scrat)
Donc, nous avons testé sur une Debian avec batcox ce soir et le probleme est le suivant: la libphp n'existe pas sous cette distrib ! (les applications sont liées statiquement à PHP.. perso, ca me semble totalement idiot, m'enfin le mainteneur doit avoir ses raisons semble-t'il).
Donc je m'adresse ici aux debiannistes: il faudrait essayer de compiler les sources de PHP pour en faire une lib (ou à partir du paquet php4-dev, je ne sais pas) voire un paquet utilisable avec Raydium !
On a réussi à faire tourner PHP sous Windows, on devrait bien y arriver sous Debian.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Nov 21, 2003 10:13 am 
Offline

Joined: Mon Mar 17, 2003 10:06 pm
Posts: 30
Quote:
J'aimerais avoir des retours sur cette partie de Raydium, qui est importante, et encore TRES peu testée !


Est-il possible d'installer Raydium sur une Mandrake en moins de 10 min ?
(RPM ou install.sh)

Si oui je serais très heureux de tester çà, car je suis un très grand amateur de PHP !!!

Je suis actuellement en train d'écrire une frontend pour image-magick en PHP-GTK DL d'où l'intérogation qui surgit de mon esprit à la vue de ces nouvelles :
- Un infographiste aura-t-il la possibilité de réaliser intégralement un jeu (ou une autre application 3D) avec cette solution PHP haut niveau ?
- Si oui je suppose qu'il doit être possible d'insérer la vue 3D dans un widget, d'où ma seconde question, lequel ? Serait-il possible d'avoir un exemple de code ?

Voici un simple sample qui montre comment j'ai fait dans ma front end, il s'agit de la fonction handle2pixbuf qui se trouve tout à la fin du script.

L'idée du PHP est une très très bonne idée !
Car je me suis rendu compte que malgré qu'il s'agisse d'un langage interprété de très haut niveau, ma frontend imagick-gtk offre une très grande réactivité, et les performances sont très bonnes (ce qui dans le domaine de la manipulation d'image est un point noir tout comme pour la 3D temps réel).

Malgrés tout les performances sont très bonnes si on utilise GdkPixbuf, car avec un Pixmap de base, c'est vraiement pas çà du tout !

A+
PS: voici les deps pour tester ce simple sample code sur une Mandrake php-gtk-1.0.0 & php-imagick-4.3.1


Top
 Profile  
 
 Post subject:
PostPosted: Sat Nov 22, 2003 1:28 am 
Offline
User avatar

Joined: Sun Mar 16, 2003 2:53 am
Posts: 2591
Location: gnniiiii (Scrat)
Installation de Raydium en moins de 10 minutes: non :)
Il faudra à priori un peu plus de temps à qq1 qui ne connait pas déjà la procédure d'installation, en particulier au niveau d'ODE (cela fait qq temps que je dis que j'integrerais ODE patché/configuré à l'arbre de Raydium.. ton intervention me le rappelle :)), mais regarde tout de même la doc formatée par batcox à ce sujet si tu veux: http://wvs.cqfd-corp.org/browse.php?dir=/doc

Ensuite, à propos de PHP, il y'a qq chose d'important à bien voir: c'est Raydium qui intègre PHP, et non PHP qui intègre Raydium sous forme de module/extension !
Comme décrit plus haut, il est possible depuis Raydium d'appeller du code PHP (depuis la console ou depuis le code de l'appli elle même) et d'échanger des variables et des appels de fonctions entre les deux mondes.
Ce qui ressort de tout ca, c'est qu'il est possible d'écrire peut être 90% de l'application en PHP, mais une petite partie au moins restera en C (initialisation de l'appli, appel des frames, et bien sur appel du/des script(s) PHP en question).
Reste que si qq1 se donne la peine de terminer ce qui est déjà commencé dans reg_api.c, il est possible de manipuler la quasi totalité de l'API Raydium depuis PHP (seules les variables de type tableau ne sont pas encore gérées).
Le but de cette intégration est donc de simplifier au maximum l'écriture de la logique de l'application/du jeu qui utilise Raydium... mais pour l'instant, l'heure est aux tests des possiblités de cette intégration de PHP ;)

Tcho.
PS: Je vais tenter de trouver du temps pour tester ton appli :)


Top
 Profile  
 
 Post subject:
PostPosted: Wed Dec 10, 2003 9:15 pm 
Offline

Joined: Mon Mar 17, 2003 10:06 pm
Posts: 30
Quote:
il est possible d'écrire peut être 90% de l'application en PHP

quatre questions:
1) Est-il possible de charger les datas 3D à partir du PHP ?
2) Est-il possible de modifier ces datas 3D à partir de PHP ?
3) Est-il possible de charger les datas 2D sur les datas 3D à partir du PHP ?
(à partir de php-imagick)
4) Est-il possible de modifier les datas 2D chargées dans Raydium ? (toujours avec php-imagick)

J'avais pour ambition de travailler sur le fichier chépuquoi.c qui charge les datas 3D dans Raydium pour mettre au point un vrai format de datas 3D xml digne de ce nom :p, mais je suis assez accaparé par d'autres activités pour pouvoir poursuivre mon apprentissage du C en ce moment. Malgré tout s'il est possible de faire ce boulot en PHP j'ai déjà un peu d'expérience sur la manipulation de datas 3D et sur le XML en PHP, ce qui me permettrait alors de parvenir à mes fins plus facilement. (j'avais même commencé à travailler sur un décimateur comme dans Blender à un moment lol)


Top
 Profile  
 
 Post subject:
PostPosted: Wed Dec 10, 2003 9:32 pm 
Offline
User avatar

Joined: Sun Mar 16, 2003 2:53 am
Posts: 2591
Location: gnniiiii (Scrat)
1) Est-il possible de charger les datas 3D à partir du PHP ?
Oui: les raydium_vertex_*_add() sont compatibles avec l'interface PHP.

2) Est-il possible de modifier ces datas 3D à partir de PHP ?
Humpf... en l'état actuel des choses, et étant donné que l'interface PHP ne gère pas les tableaux: non (aucune fonction n'est présente dans Raydium pour des modifs) mais je vais y penser (et même pkoi pas gèrer les tableaux).
Quelles sont les modifs que tu souhaites faire sur ces données ? (de quelles fonctions voudrait-tu disposer, en d'autres termes)

3) Est-il possible de charger les datas 2D sur les datas 3D à partir du PHP ?
(à partir de php-imagick)
Il existe une fonction pour changer la texture courante (la texture utilisée pour les prochains vertex_add, donc), qui utilise un nom de fichier TGA. Si tu est capable d'exporter ta texture en TGA, c'est tout à fait possible.
Tu pensait à qq chose en particulier ?

4) Est-il possible de modifier les datas 2D chargées dans Raydium ? (toujours avec php-imagick)
Non, Raydium ne propose pas ce genre de méchanismes, qui implique un certain travail ou une certaine consomation mémoire, puisque les données 2D, ne l'oublions pas, sont stockées dans la carte vidéo :)
Là encore, si tu as plus d'infos sur ce que tu souhaites, laisse le moi savoir.. dans l'absolu, tout est possible ;)

L'intégration de PHP dans Raydium cherche exactement à combler ce que tu décrit: programmer en C, c'est contraignant et ça demande de la rigueur.. et pour certaines choses, le PHP est très suffisant et préférable (gestion des chaines et des tableaux, en particulier) au C.
Ah, une dernière note: On ne sait rien encore quand à l'utilisation de modules externes PHP dans Raydium.. Comment se présente php-imagick, par exemple ?


Last edited by Xfennec on Thu Dec 11, 2003 7:42 am, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: Wed Dec 10, 2003 11:40 pm 
Offline

Joined: Mon Mar 17, 2003 10:06 pm
Posts: 30
vraiment génial !
En fait pouvoir charger des datas dans l'envirronement c'était vraiement le point primordial.
Pouvoir après les modifier, c'était juste pour se faire plaisir à faire des trucs de ouf qui déchirent tout, la Mère et les nuages.

Quelles sont les modifs que tu souhaites faire sur ces données ? (de quelles fonctions voudrait-tu disposer, en d'autres termes)
en fait en PHP, je suis habitué à manipuler les datas 3D en un haut niveau qui est un peu différent de celui bas niveau d'openGL. C'est à dire avec les coordonnées des points d'un côté, et le maillage de l'autre basé sur les index des coordonnées de la première liste.
À première vu cela peut parraître plus compliqué mais il n'en ai rien, car à l'usage d'une part c'est bien plus facile à manipuler, et d'autre part c'est beaucoup plus souple pour en faire toutes sortes de choses diverses et variées.

Par exemple pour tout ce qui est généré, on crée la géométrie d'abord et mailler le squelette se fait alors ensuite tout seul, en suivant l'ordre des points.

Idem pour ce qui n'est pas généré mais construit à la main, on peux faire apparaître ou disparaître certaines partie du squelette des points en manipulant uniquement les index. Et en manipulant uniquement les coordonnées, on peux faire bouger la géométrie (et donc le personage ou autre objet) vraiment, et pas juste avoir des personnages qui sont des sortes de pantins avec les bras et les jambes dans un autre mesh (même s'il est vrai que cela peu être très bien fait et ne pas être trop remarqué)

basiquement voilà ce que çà donne pour une pyramide
<geometrie>
<point>1,1,0</point>
<point>1,-1,0</point>
<point>-1,-1,0</point>
<point>-1,1,0</point>
<point>0,0,1</point>
</geometrie>
<maillage>
<facette>0,1,4</facette>
<facette>1,2,4</facette>
<facette>2,3,4</facette>
<facette>3,0,4</facette>
</maillage>

Comme tu vois c'est suffisamment trivial pour pouvoir être utilisé assez facilement par un graphiste et qu'il puisse s'éclater avec. Une fois celà parsé en PHP, ce qui est extrèment simpe (y'a juste à copier-coller l'exemple du manuel de php), et chargé dans Raydium, ce qui serait cool ce serait de pouvoir accéder au point d'index 4 (ici le sommet) pour pouvoir en changer les coordonnées 0,0,2 par exemple, pour surélever le sommet.

Idem pour les facettes, pouvoir en ajouter d'autres à la fin de la liste, comme par exemple 0,1,2 et 1,2,3 pour lui ajouter une base. Ou encore masquer certaines facettes comme la deuxième par exemple (à partir de leur index ce serait suffisent) pour créer une ouverture dans la pyramide. J'ai dis masquer plutôt que supprimer car il me semble (mais je me trompe peut-être) que se serait plus dur à faire d'une part, et d'autre part cela modifierait l'index des facettes qui suivent celle supprimée (ils serait alors difficile d'y accéder, il faudrait tenir le compte des index des facettes suivantes et les décrémenter à chaque fois qu'on en suprimerais une)

Pour ce qui est des datas 2D imagick est capable de charger toutes les data d'une image dans une variable, et libre à nous ensuite d'en faire ce qui nous chante (imagick étant l'expert en convertion de format, il va de soit que convertir préalablement l'image en TGA ou n'importe quoi d'autre se fait les doigts dans le nez, pour passer une image à php-gtk c'est le format RGB qu'on utilise, et çà ne pose aucun problème)

Idem ajouter des points à la fin de la liste des points comme par exemple 0,0,-1 pour faire un somment en dessous, puis ajouter des mailles dans la liste du maillage pour créer les nouvelles facettes. On aurrait alors de vrai objets évolutifs, et pas juste coller un canon ou un réacteur en plus à la barbare en ajoutant un autre mesh distinct. car là l'UV pourrait se poursuivre sur les extention sans aucune discontinuités.

Tu pensait à qq chose en particulier ?
Animer une texture par exemple, ou en changer on the fly suivant divers événement.
Ou encore faire bouger la texture sur l'objet en modifiant les coordonnées UV.

Pour ce qui est de les changer dans la carte vidéo, je n'ai aucune idées des contraintes et des couts, mais il ne s'agirait pas de toutes façon d'en changer à chaque nouvelle frame mais ponctuellement. D'autant que les textures sont souvent en 512 ou 256 si c'est gourmand, est ce que çà passerait si on utilisait cette fonctionnalité qu'avec les 256 voir des 128 ?

Comment se présente php-imagick, par exemple ?
l'extention imagick, contrairement aux extentions pear qui elles sont en php simple, est une extention pecl et donc en C.
http://chora.php.net/co.php/pecl/imagic ... n=2&r=1.48
(perso je vous conseille de consulter ce lien sous links car dans un navigateur classic c'est pas très agréable de lire du code:)


Top
 Profile  
 
 Post subject:
PostPosted: Thu Dec 11, 2003 8:12 am 
Offline
User avatar

Joined: Sun Mar 16, 2003 2:53 am
Posts: 2591
Location: gnniiiii (Scrat)
A propos du "mode indexé":
Pour la description de facettes en lieu et place de simples vertices seuls, j'avais commençé une reflexion ici: [url]viewtopic.php?t=125[/url] .
Si ce mode vennait à être écrit, il semble simple d'implémenter des fonctions de modifs des facettes d'une part, et des vertices d'autre part.
vertex: px,py,pz
face: v1, v2, v3, normv1x, normv1y, normv1z, normv2x, normv2y, normv2z, normv3x, normv3y, normv3z, texuv1, texvv1, texuv2, texvv2, texuv3, texvv3.
Ces structures de données te semblent correctes dans l'idée ?

A propros des changements de textures:
Il y'a encore un grand inconnu dans tout ca: le cout de PHP en terme de temps CPU: je n'ai aucune idée de l'impact de PHP sur une utilisation à chaque frame, en particulier avec l'utilisation de modules externes... il faudrait mener qq tests là dessus et voir s'il y'a un terrain d'optimisation possible.
Quand au chargement d'une texture, c'est une opération lente: les cartes vidéos sont horribles sur les changements de contexte de texture (c'est probablement les opérations les plus lentes sur une carte vidéo :)), et surtout quand on charge une TGA, y'a un truc lourd: le chargement depuis le disque (les TGA utilisées par Raydium ne sont pas compressées), qui est là aussi une opération lente (à chaque frame en tt cas).
Ceci dit, Raydium utilise bien sur un système de cache: Si on rappelle raydium_texture_current_set_name("toto.tga") deux fois à des endroits différents, la texture n'est pas rechargée et Raydium retrouve très vite l'identifiant de cette texture en mémoire vidéo.
Bref.. à tester :)

A propos du chargement de modules:
Les modules PHP externes peuvent être chargés par Raydium au moment de l'initialisation, ou par le script lui même, si je ne dit pas de bêtises (cf http://fr.php.net/dl).. là encore, faudrait voir laquelle des 2 méthodes est la moins couteuse :)


Top
 Profile  
 
 Post subject:
PostPosted: Thu Dec 11, 2003 5:01 pm 
Offline

Joined: Mon Mar 17, 2003 10:06 pm
Posts: 30
Ces structures de données te semblent correctes dans l'idée ?
Presque pour le point çà va mais toutes les coordonnées devraient être indexées sur le même principe des points pour avoir la même souplesse qu'avec les points

vertex: px,py,pz ; px,py,pz ; px,py,pz
norm: v1x,v1y,v1z ; v2x,v2y,v2z ; v3x,v3y,v3z
texuv: u1,v1 ; u2,v2 ; u3,v3
face: v1,v2,v3 ; n1,n2,n3 ; uv1,uv2,uv3

Pour ce qui est du cout des textures, déjà avec le système d'indexation ci-dessus il est très simple de manipuler l'UV et donc de faire des effets assez poussés.

Sinon tu parlais du cout de PHP, là je te le dis tout de suite calculer les normales à partir de PHP c'est très très couteux [1] ! Il est intéressant de pouvoir les manipuler en en modifiant certaines à partir de la structure ci-dessus, mais toutes les calculer à partir de PHP dans le cadre d'environnements générés, ce sera très lent (du moins pour créer les datas, après une fois que c'est fait c'est bon; dans un réseau se sera ceux qui ont des P4 qui prendront çà en charge;)

[1] { malgré tout je suppose qu'on peut imaginer sans peine pour en réduire ce cout d'avoir les fonctions mathématiques codées dans raydium et non en PHP. Car moi évidemment mes fonctions PHP de produit scalaire, etc. que j'utilise pour convertir en pov, çà suce un max, des fois c'est pas rare que çà mette 1 ou 2 heures, voici les fonction que j'utilise :
http://web3d.tuxfamily.org/V2/raymak/geom_012.html
http://web3d.tuxfamily.org/V2/raymak/geom_xyz.html
à prioris, je ne pense pas que ce soit très dur à recoder en C ?
}


Top
 Profile  
 
 Post subject:
PostPosted: Thu Dec 11, 2003 6:57 pm 
Offline
User avatar

Joined: Sun Mar 16, 2003 2:53 am
Posts: 2591
Location: gnniiiii (Scrat)
Ok, en effet, c'est très intéressant d'indexer aussi les normales et texcoord, par contre ca donne donc un truc du genre:
vertex: px,py,pz;
norm: vx,vy,vz;
texuv: u,v;
face: v1, v2, v3, n1, n2, n3, t1, t2, t3;
(pas de répetition pour les vertex, norm et texcoord), non ?

Quand au cout, je me suis probablement mal exprimé: ce qui m'inquiete, c'est plus le "chargement/init/interprétation/execution/libération" de PHP à chaque frame.
Ceci dit, il est bien certain que les calculs "critiques" doivent être implémentés dans Raydium, et c'est déjà le cas pour les calculs/lissages des normales (en revanche, rien n'existe pour la majorité des calculs matriciels que tu utilises dans les fichiers que tu montres :)), et pour bcp d'autres choses.
Si nous sommes d'accord pour la structure données plus haut, eh bien.. faut le coder dans Raydium (cad réécrire la base de Raydium et des outils autours ;))


Top
 Profile  
 
 Post subject:
PostPosted: Thu Dec 11, 2003 7:33 pm 
Offline

Joined: Mon Mar 17, 2003 10:06 pm
Posts: 30
juste par nostalgie pour l'époque où je faisais du vrml au notepad, hop une pyramide de tête:

vertex: 1,1,0; 1,-1,0; -1,-1,0; -1,1,0; 0,0,1;
norm: .7,.7,-.3; .7,-.7,-.3; -.7,-.7,-.3; -.7,.7,-.3; 0,0,1;
texfile: image.tga
texuv: 0,0; 0,1; 1,1; 1,0; .5,.5;
faces:
0,1,4, 0,1,4, 0,1,4;
1,2,4, 1,2,4, 1,2,4;
2,3,4, 2,3,4, 2,3,4;
3,0,4, 3,0,4, 3,0,4;

vu que les facettes contigues partagent les même normal, elle risque d'avoir une tête un peu applatie, mais bon :)


Top
 Profile  
 
 Post subject:
PostPosted: Thu Dec 11, 2003 8:34 pm 
Offline
User avatar

Joined: Sun Mar 16, 2003 2:53 am
Posts: 2591
Location: gnniiiii (Scrat)
Nous sommes bien d'accord, parfait :)
Quand à l'info sur la texture utilisée, pkoi ne pas la rajouter (indexée) au niveau de la face elle même ? (Raydium duplique en interne cette info pour chaque vertex de la face, au pire).


Top
 Profile  
 
 Post subject:
PostPosted: Thu Dec 11, 2003 10:21 pm 
Offline

Joined: Mon Mar 17, 2003 10:06 pm
Posts: 30
Tu veux dire quelque chose comme cela ?

vertex: 1,1,0; 1,-1,0; -1,-1,0; -1,1,0; 0,0,1;
norm: .7,.7,-.3; .7,-.7,-.3; -.7,-.7,-.3; -.7,.7,-.3; 0,0,1;
texuv: 0,0; 0,1; 1,1; 1,0; .5,.5;
faces:
0,1,4, 0,1,4, 0,1,4, image-1.tga;
1,2,4, 1,2,4, 1,2,4, image-1.tga;
2,3,4, 2,3,4, 2,3,4, image-2.tga;
3,0,4, 3,0,4, 3,0,4, image-3.tga;

héhé, effectivement çà ouvre des perspectives intéressantes :)


Top
 Profile  
 
 Post subject:
PostPosted: Thu Dec 11, 2003 10:33 pm 
Offline
User avatar

Joined: Sun Mar 16, 2003 2:53 am
Posts: 2591
Location: gnniiiii (Scrat)
Ok, on adjuge cette structure comme étant définitive :)
Style:
Code:
typedef struct raydium_Vertex
{
GLfloat x;
GLfloat y;
GLfloat z;
} raydium_Vertex;

typedef struct raydium_Normal
{
GLfloat x;
GLfloat y;
GLfloat z;
} raydium_Normal;

typedef struct raydium_Texcoord
{
GLfloat u;
GLfloat v;
} raydium_Texcoord;

typedef struct raydium_Face
{
int vertex[3];
int normal[3];
int texcoord[3];
int texture;
} raydium_Face;

... from scratch :)
Ca signifie donc une réécriture profonde des premières couches de Raydium (qui datent, donc) et aussi des ajouts importants (voire une modification ? aïe...) de l'API en elle même. Gros boulot en perspective :)
Ca intéresse qq1 d'essayer ?


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 28 posts ]  Go to page Previous  1, 2

All times are UTC


Who is online

Users browsing this forum: No registered users and 32 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group