Raydium 3D Game Engine

Je vais (probablement) profiter de mes vacances pour tenter une ré-écriture de l'ensemble du coeur de rendu de Raydium. Cette partie date des premiers mois de l'existence du projet, et souffre de son age
Un thread avait été ouvert ici : http://memak.cqfd-corp.org/viewtopic.php?t=125 sur ce sujet, et on retrouve dans un autre thread une réflexion entre Blue Prawn et moi même qui débouchait sur une structure de donnée intéressante.
J'ai commencé a regarder rapidement, et il n'y pas moins de 285 endroits différents (uniquement dans le coeur de Raydium) qui devront subir des modifications, et certains outils extérieurs (en particulier raydium_modler) sont à ré-écrire entièrement. Les différents scripts d'import et d'export (Blender, 3DS, DirectX) sont eux aussi à refaire.
Dans un premier temps, le gain serait surtout une plus faible consommation mémoire, mais peu d'autres choses devraient changer. A terme, par contre, ce changement majeur devrait permettre un support des animations (persos animés, par exemple) et une ré-écriture efficace du moteur de rendu, qui apporterait un fort gain de performances. Les mécanismes d'effacement (sur les objets et leurs vertices) seront aussi plus simples à implémenter avec cette structure.

Dans un tout autre registre, une maquette du nouveau site de Raydium/MeMak a été commencée par willou et Flex ( http://cqfd-corp.org/~willou/dev.html ), et ces deux semaines pourraient aussi permettre la naissance d'un vrai site pour ces deux projets, si Flex est libre sur cette période.

Les hostilités commencent dès le 1 aout, pour une durée de deux semaines en ce qui me concerne, et tous ceux qui sont intéressés pour aider à la tache sont bien sûr invités
Les sujets concernés sont nombreux : y'a du C, du Python, du PHP (pour Raydium), du HTML, du (My)SQL, du PHP (pour le site Web) et toute une partie analyse/réflexion.

a+

je suis partant pour donner un coup de main. Par contre je suis en plein déménagement pendant le WE du 31 juillet 1er aout, et après je n'aurai donc plus de net pendant un certain temps, et je par en vacances la deuxième semaine d'aout. Voilou

Et tu es dispo pendant la première semaine d'aout ?

Je vais tenter de tenir une sorte de carnet de bord de l'avancée de Raydium pendant ces qq jours, histoire de pouvoir faire un "avant - après" ensuite

Pour l'instant, avant de toucher au core, j'ai qq petits tests à faire sur de nouveaux algos pour le réseau: "Dead Reckoning + Reconciliation".
Le Dead Reckonig, on le fait déjà, ca consiste à évaluer la position d'un objet à t+1, sachant qu'a un moment t, on a recu des info sur la position et la vélocité de l'objet.
Le prb ici, c'est la reconciliation: c'est la méthode qui permet, au moment t+1, de ramener l'objet de sa position estimée à sa véritable position recue à nouveau depuis le réseau. Pour l'instant, on fait simple: téléportation Tous ceux qui ont joué à mania_drive ou kartagony connaissent ce phénomène. J'ai imaginé un ""truc"" à base de vecteurs convergents, mais j'ai aucune idée de la viabilité du concept.. alors je vais tenter ça avant de passer au gros morceau: le core !

A suivre

bon courage. Je n'ai pas eu le temps de revenir sur le forum car je n'ai plus l'adsl pour le moment. Je m'en vais en vacances et reviens le 17 aout. amusez vous bien

Heu, ca avance pas aussi vite que prévu
Je suis toujours sur la prédiction de trajectoires réseau, avec des résultats.. peut être intéressants, si j'arrive à trouver l'algo final

Ok, je suis arrivé à une version intéressante de la partie prédiction de trajectoires. J'ai effectué de petits essais sur test6 et mania_drive, à 2 joueurs sur un réseau 22 Mbps, avec des résultats très convenables (trajectoires fluides) même dans de mauvaises conditions (nombreux objets dans la scène). Il faudrait tester à plus grande échelle, et sur des applis plus complètes (je pense à kartagony en particulier), mais toutes ces heures passées sur le problème des trajectoires réseau semble enfin donner qqchose

Techniquement, pour résumer, on dispose d'un mécanisme qui projette les éléments distants (qui appartiennent à une autre machine) grâce à une information donnée par un vecteur de vélocité. A l'information suivante (nouvelle position + nouvelle vélocité), un algo se charge pour modifier la vélocitée reçue de facon à ce quelle permettre d'arriver à la prochaine destination estimée (calculée depuis la postion reçue, projetée sur le vecteur de vélocité pour un temps égal à l'interval de temps entre les deux dernières mise à jour reçues du réseau) depuis la postion actuelle (estimée, donc) de l'objet. (Ok, je pense que cette phrase est pas ce qu'il y'a de plus clair )

Cet algo cherche donc à reconcilier la dernière estimation de position avec la véritable position de l'objet. Il en résulte des trajectoires qui ne sont pas tout à fait identiques entre les machines (tout en restant très fidèles en moyenne), et le tout avec des trajectoires fluides (pas de téléportations d'éléments, comme on pouvait en voir avec la version précédente).

Ce nouvel algo complète les précédentes modifications, en particulier la modif qui permet à la couche ODENet d'être beaucoup plus "calme" sur les paquets NIDWHO, qui avaient une forte tendance à flooder le réseau lors de la construction d'objets (connexion d'un joueur, par exemple). Une autre modif qui devrait beaucoup aider que je vais tenter d'introduire sous peu est la création d'un "timeout avant ré-émission" distinct pour chaque joueur, au lieu d'un seul global: Les serveurs Raydium qui mélangent les clients LAN et Internet ont en effet tendance à ne pas être très tendres avec les clients Internet (car le délai avant ré-émission est très vite tiré vers la bas par les clients LAN).

On se rapproche d'une couche réseau "presque correcte"

A suivre !

Après test (3 joueurs à Kartagony), la nouvelle couche réseau donne des résultats corrects. L'algo de prédiction de trajectoires remplace donc son prédécesseur. Sur l'ensemble du test, aucun problème n'a été relevé. Il faudrait confirmer ces conclusions par des tests à plus grande échelle, une fois la dernière modif (citée dans le passage précédent) appliquée.

En revanche, les deux sujets originaux de ce thread (ré-écriture du core et le site web) n'ont pas bougés . Pour une autre fois...

Je réveille ce topic, puisque la modification citée plus haut (utilisation d'un délais de timeout par client et non global) est maintenant appliquée à Raydium, mais non testée !

Le but est donc d'organiser une partie de test6 (4 ou 5 joueurs, par exemple), avec 2 joueurs du coté réseau local, et le reste sur Internet. Le serveur sera hébergé sur le site de CQFD (il faut que je calcule vite fait le débit que devrait consomer test6 avec 4 joueurs pour vérifier que ce soit possible).

A titre d'info, avec l'ancienne version de test6, ce test échoue (désynchro directe des joueurs sur le net)... le but est d'arriver à un truc qui marche (même mal pour l'instant )

Alors, ceux que ça intéresse doivent :
- se manifester ic (on va donner une date ensuite)
- disposer d'un linux avec une accel 3D (on utilisera directement des binaires statiques de test6)
- avoir une ligne au moins 512/128

Y a peut etre moi sur le net

ok, et de 1

désolé mais je n'ai pas encore réinstallé de linux sur mes machines, manque de place

entendu. (tu penses pouvoir avoir au moins un linux d'ici qq temps ?)
L'idéal serait au moins 2 autres personnes.

je vais essayé de faire ça au plus vite

Histoire d'avancer un peu, on va fixer une date, on se débrouillera avec ceux qui sont présents :
Rendez-vous Mardi 28 décembre, 21h sur irc.

Rappel : eu.undernet.org sur #cqfd