Mais … mais !

Souvenez vous ! Le PATRIOT de Polhemus, le machin à 2400 euros… eh bien voilà ce dont on me parle à l’instant par mail : Mad Catz "invente" le Gametrak, un truc pour jouer à des jeux de golf, de baston avec ses mains, et plus avec un pad. Et en fouillant un peu, il me semble bien comprendre que ce truc fonctionne exactement comme le PATRIOT ! Mais pour moins de 30 euros (si si).

Je vais attendre de trouver un peu plus d’infos, mais si je ne me trompe pas, j’achète le truc tout de suite, même si je dois écrire le pilote moi même !

A moi les joies de la réalité augmentée PARFAITE ! Hahahahahaha !

PS: pour ceux qui ne suivent pas, le PATRIOT est un système capable de donner la position très précise de deux capteurs dans un espace 3D. La portée du GameTrak est un peu inférieure à celle du PATRIOT (3m selon les premières infos), mais c’est déjà bien assez.

Source : http://www.in2games.uk.com/testsite/index.php


Publié

dans

par

Étiquettes :

Commentaires

4 réponses à “Mais … mais !”

  1. Avatar de hubadu
    hubadu

    A quand la prochaine release du source de raydium ? quid du problème de licence avec ARToolKit ?

    merci d’avance

    Et est-ce qu’il y serait possible d’avoir une version PHPraydium (ou PyRaydium avec python) où, à la manière de PyOrgre (pour Ogre3d), on aurrait pas besoin de toucher au main code en c pour créer un petit jeu ? (en gros une séparation totale entre moteur(compilé en c) et jeu(géré dynamiquement en php ou en python).

  2. Avatar de Xfennec
    Xfennec

    Intéressantes ces questions.

    Je vais probablement lâcher très prochainement une release stable de Raydium (semaine prochaine ?), principalement le temps de préparer la "pub" autour (articles sur le site, freshmeat.net, …). Reste que le repository SVN est toujours accessible (et stabilisé) : http://raydium.yoopla.org/wiki/RaydiumSvn

    En ce qui concerne ARToolKit, rien n’a changé (et rien ne risque de changer à mon avis) : le projet n’est pas libre. Les sources sont dispos, mais je ne peux pas intégrer leur bibliothèque à Raydium (qui lui est GPL). Si quelqu’un est intéressé, j’ai les sources (crades) des divers programmes codés pour l’occasion à disposition, qui permettent de faire joujou avec la réalité augmentée (Linux only).

    Enfin, PyRaydium existe déjà ! 🙂 Il est même publié sur le SVN. PHP, effectivement, est plus utilisé pour le scripting depuis Raydium (et non l’inverse).
    Pour PyRaydium, cf quelques articles plus bas : http://blogs.nofrag.com/Xfennec/2005/aou/25/8913-raydium-et-python/

  3. Avatar de hubadu
    hubadu

    Ah je comprend maintenant, je me disais c’est bizarre quand même, il y a un log svn et il n’y a pas d’accès.

    J’ai d’autres questions:
    – Au niveau de la définition d’un objet, dans le moteur, un ‘objet’ est lié directement a un fichier tri, est-ce que le terme mesh serait plus approprié (ou entity) ? En plus c’est lié directement à un fichier (filesystem avec gestion ressources?) . La notion d’objet ça serait plus pour regrouper d’autres sous objets de bases, comme des mesh, des forms pour les physique, des valeurs liés au gameplay…

    – Est-ce qu’il y a des toolkits de prévu, genre un truc comme sandbox pour farcry avec un object properties et du picking pour bouger les objets, voir meme construire et assembler des physics-forms en temps réel à la souris in-game. Voir même un sandbox-like en réseau avec d’autres(je m’emballe).

    – et le multithreading ?

    – et enfin, quid de la gestion client/serveur au delas des objets physiques (notament le partage d’objet dynamique entre le client et le serveur) et de l’avancement de la reflexion sur Le ServeurMaster

    En tout cas, sache que tu/vous faites du très bon boulot ! C’est un très beau projet

  4. Avatar de Xfennec
    Xfennec

    Content de voir quelqu’un s’intéresser aux tréfonds de la chose 🙂
    Dans l’ordre :

    – Notion "d’objet" : Raydium n’est pas une API objet, ni même orientée objet. Le vocabulaire est donc un peu différent de ce que l’on retrouve en général. Pour Raydium, un objet est effectivement un modèle 3D, mais "encapsulé" dans le moteur. Le fait que l’objet en question arrive du disque ou d’un autre endroit n’a aucune importance du point de vue de l’utilisateur de l’API. L’objet est une primitive comme une autre pour Raydium, c’est comme ça 🙂 (autre point : il est impensable de modifier ("casser") l’API maintenant).

    – Outils de construction : Test7 doit être la prochaine étape vers ce genre d’outils. Les "Testx" sont des programmes qui cherchent à tester "en vrai" les capacités actuelles du moteur (voir Test6, FPS multijoueur avec véhicules, par exemple) et préparer le terrain pour les prochaines évolutions. Test7 doit permettre la construciton de "trucs" en live, et en réseau.

    – Multithreading : Merde, grillé 🙂 L’orientation KISS (keep it simple stupid) de Raydium fait qu’il reste pauvre sur certains points très techniques. Le bon point de la chose est que l’archi monothreadée facilite beaucoup le portage du moteur 🙂

    – Client / Serveur : La couche réseau de Raydium ne se limite pas à la physique ! Voir les propags et les netcalls (forme de RPC simpliste). Je ne suis pas certain en revanche de comprendre ce qu’est un "partage d’objet dynamique" 🙂

    Le MasterServer (et tout ce qu’il y’a autour) en est exactement là ou le wiki le montre : au point mort 😉 Ce domaine n’est pas une priorité forte, et étant seul sur le code, la gestion des priorités est assez complexe.

    Merci pour ton intérêt !

Laisser un commentaire