Raydium 3D Game Engine

Official forum for everything about Raydium, ManiaDrive, MeMak, ...
It is currently Fri Jun 23, 2017 10:10 am

All times are UTC




Post new topic Reply to topic  [ 7 posts ] 
Author Message
PostPosted: Sat Dec 13, 2003 7:11 pm 
Offline
User avatar

Joined: Sun Mar 16, 2003 2:53 am
Posts: 2590
Location: gnniiiii (Scrat)
Maintenant que le projet avance, il est possible d'avoir une vue plus précise sur ce qui représente un objet (object = ensemble d'éléments attachés ensembles), et je lance ici (plutot que dans le topic "dev") une réflexion:
Comment décririez vous un objet dans un fichier ?
On doit retrouver dans ce fichier:
- Le nom de l'objet
- Les éléments qui composent l'objet (emplacement, nom, forme, poid, taille, modèle, ...)
- Les liaisons entre ces éléments (nom, params, ...)
- Les moteurs (type, liaisons concernées, ...)
- ... (voire les derniers post à propos d'ODE dans la section Dev pour plus d'infos)

Des idées ? :)


Top
 Profile  
 
 Post subject:
PostPosted: Sat Dec 13, 2003 7:46 pm 
Offline

Joined: Sat Sep 13, 2003 7:44 pm
Posts: 30
Code:
nom;

sous_objets=
nom
{
emplacement;
forme;
poid;
taille;
modele;
}

liaison=
nom
{
nom du sous_objet 1;
nom du sous_objet 2;
type de liaison;
parametre;
}

.......


Top
 Profile  
 
 Post subject:
PostPosted: Sat Dec 13, 2003 7:55 pm 
Offline
User avatar

Joined: Sun Mar 16, 2003 2:53 am
Posts: 2590
Location: gnniiiii (Scrat)
Le problème de cette facon de faire est qu'elle est linéaire: tu dois préciser les paramêtres dans l'ordre, et il faut connaitre cette ordre pour comprendre le fichier.
Perso, je pencherais plus pour l'utilisation de mots clefs:
Code:
object "toto" {
file "titi.tri"
emplacement 12,3,9
...

Reste à imaginer le "langage" et sa syntaxe.
Le but est de créer un format le plus souple possible devant les inévitables évolutions des possibilités de l'interface ODE de Raydium (nouvelles fonctions, nouveaux paramêtres, nouveaux types, ...).


Top
 Profile  
 
 Post subject:
PostPosted: Tue Dec 16, 2003 9:30 pm 
Offline
User avatar

Joined: Sun Mar 16, 2003 4:02 pm
Posts: 93
Location: interface siège-clavier
La construction d'un objet complexe répond quand même à une certaine structure, tu ne peut pas commencer à mettre des roues (ou des bras ou des branches) dans le vide.
Il y a toujours une certaine hiérarchie à respecter.
Je pencherais plus pour "l'origine" par la partie qui se rapproche le plus du centre de gravité de l'objet donné (qui pourra déterminer son "vecteur cap/vitesse")
Malgré une structure "père/fils" assez contraignante (normal un chapeau n'est pas lié avec l'objet pied, sauf délire évident) une certaine latitude dans les liaisons peut être trouvé.

_________________
Soyez heureux.
XP2200+ | K7S5A | 512 Mo DDR 2100 | ATI radeon 7000 | Mandrake 9.2 kernel 2.4.22-21mdk


Top
 Profile  
 
 Post subject:
PostPosted: Tue Dec 16, 2003 10:01 pm 
Offline
User avatar

Joined: Sun Mar 16, 2003 2:53 am
Posts: 2590
Location: gnniiiii (Scrat)
Je suis [très] d'accord avoir toi sur le principe Jimbo, mais le but ici est de proposer un format de fichier "bas niveau" pour Raydium.
Raydium en lui même n'a pas pour rôle de gérer des ensembles cohérents d'éléments (c'est le rôle du jeu qui utilise Raydium de poser ses règles), mais juste des informations pour stocker les paramètres des différents éléments qui composents les objets.
Par contre, si tu souhaites commencer à décrire le format de fichier de MeMak (qui lui doit respecter une certaine logique), il faut en effet imposer une certaine logique (sans brider l'imagination du joueur, même si son montage est voué à se casser la gueule dans les 10 secondes). Des idées ?


Top
 Profile  
 
 Post subject:
PostPosted: Tue Dec 16, 2003 10:44 pm 
Offline
User avatar

Joined: Sun Mar 16, 2003 4:02 pm
Posts: 93
Location: interface siège-clavier
Hmmmmmmm pas évident au premier abord, tant pis je me lance (il n'y a que le premier pas qui coute :) ), à l'arrache en faisant abstraction de tout, ma façon de voir ça, brute.

Pour Raydium :
- les objets se doivent d'être élémentaires (pour l'application de règles postérieures par MeMaK par exemple)
- de par son aspect générique la description se doit d'être aussi générique.
- désignation de l'objet (son nom quoi, chaine de caractères)
- position de l'objet dans le référentiel (coordonnées de son "centre", trinome de nombres (entiers, floats, ... ?))
- orientation de l'objet dans le référentiel (vecteur, coordonnées cartésiennes ou polaires ? idem position pour la représentation)
- liste des vertices composants l'objet (en référence à sa position et son orientation propres)
- liens entre les vertices (composition des arètes de l'objet)
- texture (nom du fichier de texture et pour le texturage en lui-même grande inconnue au niveau de l'application, je ne sais pas en détail comment cela fonctionne)


Pour MeMaK :
là ça se complique :shock:
- liens "indéformables" ou indestructibles entre objets (un rocher de 1000 tonnes est lié au sol et réputé fixe par exemple ou la description du sol en lui-même)
- liens "mobiles" en oposition avec ci-dessus (un véhicule peut perdre un élément de carrosserie, un arbre une branche)

En extrapolant les deux précedentes descriptions cela amène à devoir rajouter à la description "raydium" des points d'ancrage possible sur les objets :
- un système de brique pour les éléments fixes, faire que les éléments de sol ou de décors soit juxtaposables ou superposables simplement en les "posant" les uns à côté des autres (valable pour le siège ou le moteur d'un véhicule qui forment un ensemble indissociable)
- des points d'ancrage entre élements dissociables répondant à des critères de "souplesse/faiblesse" (limites de déplacement, rotation de ces éléments entre eux, résistance de l'ancrage) qui correspondent à la mécanique entre les objets.
- interaction avec un élément fixe (je me vautre contre un mur, si le mur résiste je m'endommage, si le mur ne résiste pas, le mur et moi sont endommagés (ce qui va à l'encontre de ma théorie d'éléments fixes pour raydium, donc inclure un ou plusieurs paramètres de "fixité" de l'objet, mon rocher de 1000 tonnes peut avoir une "peau" déformable et mobile dans ce cas))

Tout ceci en vrac et surtout à développer

_________________
Soyez heureux.
XP2200+ | K7S5A | 512 Mo DDR 2100 | ATI radeon 7000 | Mandrake 9.2 kernel 2.4.22-21mdk


Top
 Profile  
 
 Post subject:
PostPosted: Tue Dec 16, 2003 11:07 pm 
Offline
User avatar

Joined: Sun Mar 16, 2003 2:53 am
Posts: 2590
Location: gnniiiii (Scrat)
Intéressant.

Pour Raydium:
Les informations à stocker sont connues (et ressemblent en effet bcp à ce que tu cites, cf le premier post du thread), mais le problème ici est plus de déterminer une structure, une syntaxe, ou que sais-je encore pour les stocker. Il ne faut pas oublier que tout cela devient très concret avec la récente intégration d'ODE: Les fonctions existent, fonctionnent, et l'on sait donc exactement ce dont nous avons besoin pour décrire un objet (nom, éléments composants cet objet, avec: nom, masse, taille, éventuelle position/rotation par rapport à l'origine, fichier .tri associé, liaison entre eux (sisi, c'est à Raydium de gérer ces liaisons, même si c'est à l'application (MeMak dans notre cas) de les créer :)), et la description des moteurs et les joints auquels ils sont liés.
Bref, il nous faut juste un "truc" bien précis (et évolutif) pour stocker tout ça.

MeMak:
Les liens indéformables existent maintenant dans Raydium sous la forme d'objets "statiques": ils ne sont pas soumis à la physique (rien ne peux donc perturber leurs position, orientation, etc) mais génèrent tout de même des collisions: si on fonce dedans.. ça fait mal.
Les liens mobiles sont implémentés sous formes de joints (type "hinge2" (suspension) seulement pour l'instant) reliants les éléments d'un objet entre eux. Il est possible de leur donner une limite de rupture (en compression/extension seulement, pas en torsion) au delà de laquelle ils s'effacent du monde, et avec une très prochaine gestion des frictions paramètrable-en-temps-réel (pour simuler un pneu par exemple [objet d'une complexité abominable sur ce point, d'ailleurs :)]).
En ce qui concerne les points d'ancrage, ils me semblent en effet indispensables, la question étant: comment on décrit/gère/stocke ca ? (et le joueur avec sa souris et son clavier, comment il manipule ca ?)
Les liaisons fixes (objets "soudés" entre eux)... ça c'est un cauchemar: cf le second post ici http://memak.cqfd-corp.org/viewtopic.php?t=109


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 7 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


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