Je réfléchis en ce moment sur l'architechture d'un jeu qui va demander pas mal de ressources probablement.
 
Il s'agit de détecter des mouvements avec une webcam, et de les reproduire dans un environement en 3D.
 
 
Sachant que la webcam fournit 15 images par secondes, le module acquisition/détection fournira 15 coordonnées par secondes.
 
D'un autre côté la scène en 3D devra être le plus fluide possible. Il faudra donc interpoler les coordonnées entre deux mesures.
 
 
Je suppose qu'il serait donc judicieux d'avoir 2 threads pour cela.
 
De plus le joueur devra avoir un retour webcam sur l'écran. Un thread supplémentaire pour afficher un tableau de pixel dans le viewer openGL?
 
 
Qu'en pensez vous?  

up?

Tout ce que je peux te dire c'est que les drivers OpenGL Nvidia ne sont pas vraiment "thread safe" en tout cas on a eu quelques petits problèmes à ce niveau au boulot. Pour le reste désolé mais je ne peux pas t'aider.

Détecter des movements avec une web-cam ... tu veux faire de la reconaissance d'image, t'as deja des idées la dessus ? parceque franchement c'est pas un truc facile.
 
Sinon ca à l'air sympa et ambitieux

C'est un projet commun que ma promo de DESS doit réaliser... en 1 mois ... on est 17.
 
Tout ce qui est détection on sait faire, créer une scène en 3D aussi, mais faire tourner le tout en temps réel avec des sons et la gestion du réseau... ça semble pas évident, surtout qu'on va devoir se mettre tous d'accord...  ²
 
 
Voilà un boulot de recherche trouvé sur internet baptisé mytoy comme le jeu de chez Sony. Essayez si vous avez une webcam c'est très sympa.
http://koli.lame.hu/~goldberg/myto [...] php?p=news

ouais ouais, la reconnaissance d'image 3D telmps réel, y a des gens qui fotn des théses dessu, faudra voir a limiter vos ambitions.
 
et pour la 3D (2) webcams minimum seront necessaires (cf geometrie stereoscopique tout ca )

vi, ce n'est pas un simple petit projet ça, il peut y en avoir pour des années ...

pas besoin de deux caméras pour les contraintes qu'on s'est fixées, on fait pas de la stéréovision là. On cherche pas à faire de la reconstruction de mouvements 3D mais du tracking. voilà le programme de mon DESS cette année, je venais pas discuter des techniques qui seront mises en oeuvre, parce que la téhéorie on l'a, je voulais juste savoir comment se comportait une application openGl avec plusieurs threads.  
 
Est-ce que par exemple un modeleur 3D (style 3dsmax) utilise 1 thread par viewport? Je vous demande des conseils techniques là parce que jusqu'à présent je faisais de la 3D "en TP", de la vision "en TP" mais pas dans des conditions réelles d'application.

(ton truc ca me rapelle ce qui se fait en reseau (interpoller entre deux coordonnées recu via le net))

 
 
exactement, on va devoir gérer ça comme dans les jeux (je crois que c'est le dead reckoning).

me semblait que ca s'appelait "biniou predicting" (bon, je me rapelle que du predicting, mais ca doit etre 'movement' ou un truc du genre). Jpense tu devrais pouvoir trouver de la ressource la dessus

ok thx pour l'info
 
 
Et pour l'openGl, c'est possible pour deux threads de se partager le color buffer pour que chacun écrive dans une partie de l'écran? (genre un thread écrit dans la moitié gauche, et l'autre dans la moitié droite). Deux surfaces de rendu indépendantes gérées par un seul conteneur, de manière à ce que le rendu de la partie gauche n'ait pas besoin d'avoir le même FPS que la partie droite.
 
 
Je me fais bien comprendre?  

alors la jpeux pas te dire, absolument aucune idée. Dans l'absolu je sais pas si je ferais ca comme ca, vu qu'il faudra bien flipper() a un moment, et si tu flippe pendant que l'autre thread ecrit encore dans le color buffer, bonjour la tambouille.
 
Plutot maj les 2 images au rythme du plus rapide, qui a ce que la meme scene soit dessinée plusieurs fois sur une partie de l'ecran (et perso je doute que ta CG soit re-entrante, mais bon)

comme c'est deux parties de l'écran différentes je me disais qu'il n'y avait pas besoin de mutex pour gérer le color buffer puisque les threads n'accèderaient pas à la même partie de l'écran. Mais il doit bien exister en openGl un moyen d'avoir plusieurs zones de rendu indépendantes ? Je ne sais pas quoi utiliser comme mot clé pour ma recherche sur google là

oué enfin c'est deux partie de l'ecran differentes, mais derriere c'est la meme cg, et le meme buffer. Perso, je le sens pas

ok oué je vais chercher plutôt du côté des fonction openGl alors pour faire plusieurs viewports

Tu pourrais aussi créer 2 fenetres avec chacune son thread et son RC associé.

ok je check ça