Merci merci pilo

J'ai essayé vite-fait d'ouvrir ton perso sous blender et de l'exporter en cal3d, ça a l'air de fonctionner nickel. Maintenant, je n'ai pas encore essayé de mettre tout ça dans mon projet, car avant je voudrais bricoler 2-3 trucs pour faciliter l'insertion d'un modèle cal3d dans un projet OpenGL. Car là faut que je modifie pas mal de choses sinon. Donc réponse dans quelques jours je pense.

Pour ce qui est des bounding box, je verrai ça plus tard dans mon projet, ce n'est clairement pas dans le plus urgent ^^

Après pour les textures, ça va être difficile de mettre du code : ce n'est pas un simple fichier comme le tien, il y en a une bonne vingtaine Du coup moi-même j'ai du mal à bien me représenter quels appels sont fait avant les autres. Je me vois mal expliquer ça ici maintenant. Je vais tenter de tracer mon code pour voir l'ordre d'appel de ces fonctions OpenGL et après j'essaierai de mettre tout ça à plat ici si je ne trouve pas

De toute façon j'ai encore des problèmes avec mon ordi en ce moment J'ai dû réinstaller toute ma partition Linux à cause de mes tentatives de bidouillage cet aprem en plein TP. Car j'ai un problème : il y a des chances pour que tu ne puisses rien y faire, mais je t'explique, au cas où ^^. En fait, je bosse sur la distrib Pardus 2007. J'ai une carte graphique ATI modèle Radeon XPRESS 200M 5955 (PCIE). J'ai beau installer le package ati-drivers, l'ordi me répond "pas du support 3D". J'ai beau chercher une solution, je ne trouve rien. C'est plutôt problématique car j'ai un cours de Synthèse d'Images Avancée ce semestre, dans lequel on programme les shaders... Plutôt embêtant quand on aura le projet à faire... En plus je peux pas demander à mon ordi de faire de trop grosses choses du coup sinon... ben il rale Enfin voilà, parenthèse fermée.

Après niveau boulot, j'avoue que côté jeux vidéo ça me plairait bien ^^. Je ne sais pas qui est Lapintade, mais c'est vrai que s'il pouvait ne serait-ce que m'éclairer sur le sujet ça serait super cool
Sinon, t'en as pensé quoi de ton stage dans cette boîte ?

Enfin voilà pour ce soir, j'aurai sûrement plus de temps demain pour regarder tout ça au calme avec mes 3 petites heures de cours.
Mais là j'ai 9h de cours derrière moi, autant dire que la fatigue se fait sentir...

A très vite je pense

driver ati + linux aie! enfin moi je tourne sous slackware, et sur 2 machines ca a été aie! aie! je ne saurais pas dire comment faire sur une autre distrib, mais soit le driver est mal installé (y'a des problème avec les ati), soit X est mal configuré? En effet c'est embêtant si tu n'a pas les shader....

Lapintade c'est le modo de ce forum ;)
Pour le stage de toute facon tu peux postuler spontanément dans toutes les boites que tu trouve.
Moi j'ais trouvé que c'était un boulot bien, maintenant ca peut etre bcp bcp de boulot, donc a voir...

Salut

Après une lutte acharnée, j'ai résolu mon problème de carte graphique ! On peut dire que ça fait plaisir !

Bon sinon, je n'ai pas trop planché sur les problèmes de textures, ni les blendCycle (on attend la réunion avec le prof pour ça, vu que ça concerne une de ses parties de code). Par contre j'ai remodeler tout mon code de sorte à avoir un Loader Cal3D portable. En fait l'idée est venu des autres de la classe qui auraient voulu s'en servir ^^. Du coup ça m'a donné l'idée de la portabilité du loader dans n'importe lequel de nos projets OpenGL. J'avoue que réfléchir en ce sens n'est pas évident mais le résultat est plus que satisfaisant !
Au final, il n'y a plus qu'à inclure dans un répertoire de projet le loader, un modèle Cal3D, et en 4 petits appels de fonctions le personnage s'anime à l'écran
J'espère que cette idée sera un bon petit plus dans le rapport du TER ^^

Bon, tu pensais peut-être y échapper, mais non, j'ai encore une question sur un truc que je ne comprends pas bien
C'est à propos de la fonction update(). Le paramètre que l'on passe joue quel rôle exactement ? Est-ce le temps qui s'est écoulé depuis le dernier update() ? Je n'en suis vraiment pas sûr...

Sinon, je crois que c'est tout pour le moment. Le projet commence à avoir de l'allure, ça fait plaisir. Surtout que le prof adore, c'est très bon signe

Ah aussi, vu que tu as l'air de connaître un minimum Lapintade, tu crois qu'il pourrait me faire un petit topo sur le sujet jeux vidéo dans ce topic ? Car je sais pas si ça serait très bien de créer un n-ième topic juste pour cette petite question... Dis-moi ce que tu en penses

Voilà, ça ira pour ce soir.

Encore merci de ton aide.
@++

Voilà un petit moment que je n'ai pas bossé sur ce projet (à causes des 4 autres projets sûrement ^^).

Je ne sais pas si tu traînes dans le coin pilo masi j'aurais besoin d'aide encore une fois

C'est à propos de l'animation et de ce fameux paramètre de la fonction update() : je ne sais pas à quoi correspond ce paramètre.
Par exemple, quand il vaut 1, le personnage marche à la bonne vitesse, mais à reculon... quand il vaut 0.5, il 'tremble' bizarrement... et à 0.1 il marche normalement, mais un peu trop vite !
Je ne sais donc pas du tout ce qu'il faut mettre comme paramètre

A part ça le projet touche à son terme (enfin). Mais j'ai toujours ce problème de texture qui n'apparaît pas ! Je ne sais toujours pas d'où ça vient...
Aussi, le prof a ajouté le texturage du terrain. Le problème, c'est que la texture est rosie à l'affichage, et on ne sait pas pourquoi Même résultat avec des textures différentes. Une idée du problème ?

Voilà c'est à peu près tout, j'espère que mes questions trouveront réponse

En tout cas merci d'avance

le paramètre de update c'est le temps écoulé depuis le dernier update...

voici comment je gère ca en général :
je définis une valeur pour le temps d'une frame, par exemple, 1.0f/60.0f, pour 60 frame /s.

J'utilise toujours cette valeur pour tout mes updates (pas seulement l'animation, mais aussi la physique par exemple).

Ensuite dans ma boucle grosso modo ca ressemble a ca :

while(!end)
{
static float time += TimeSinceLastFrame(); // le temps ecoulé depuis la dernière
int iteration = time / (1.0f / 60.0f); // combien de frame doivent etre calculé?

// limiter les iterations pour eviter l'effet boule de neige
iter = iter > 4 ? 4 : iter;
for(size_t i = 0; i < iter; i++)
{
Update(1.0f/60.0f); // peu importe ce que tu update.
time -= 1.0f/60.0f;
}

RenderScene();
}

TimeSinceLastFrame() renvois la temps en secondes écoulé depuis le dernier appel. Ca permet de temporiser ton code (j'utilise SDL, je sais plus le nom exact de la fonction qui fait ca).
Le nombre d'iteration sera en général entre 0 et 1 (car une petite scène sur des machines rapides, ca devrait passer tranquil).
Conserver un temps d'update fixe peut etre très important quelque fois (comme pour la physique), c'est pour ca que j'utilise ce mecanisme.

Pour les textures, il faudrait que l'on puisse jeter un coup d'oeil a ton code, car ca peut venir de plusieur chose.

Merci pilo pour les explications. J'ai essayé comme tu m'a dit mais le résultat n'était pas satisfaisant. J'ai donc cherché un autre moyen... que j'ai trouvé dans un mini-viewer du site officiel de Cal3D. Maintenant l'animation est fluide, c'est bien sympa

Pour les textures, j'ai commencé à lister et tracer tous les appels à OpenGL pour voir dans quel ordre tout est fait (en fait il y a beaucoup d'appels répartis dans beaucoup de fichiers, ce qui n'est pas évident pour te présenter ça). J'essaierai au plus vite de mettre tout ça ici avec des explications.

Sinon j'aurais une autre question. Je ne sais pas si tu as déjà essayé ça mais bon, au cas où... c'est une fonction du prof qui ne marche pas en fait C'est à propos de la texture utilisée pour le terrain. Il fait des manips qui rosissent la texture. De mauvais décalages d'octets je pense, mais je n'y comprends rien... Voici le code :

/***************************/
void
wlMesh::SetTexture(QImage image)
{
printf("coucou\n");
this->Trace("-> SetTexture(%ux%u)", image.width(), image.height());
image.convertToFormat(QImage::Format_ARGB32);
// on est oblige de faire cette conversion car Qt ne propose que le codage ARGB quand OpenGL ne propose que RGBA !
this->w = image.width();
this->h = image.height();
this->texture = QVector<unsigned int>(this->w*this->h);
QRgb *pixels = (QRgb *)image.bits();
for (int i=0 ; i<this->texture.size() ; i++)
//~~~~~~~~~~~~
this->texture[i] = (pixels[i] << 8) + ((pixels[i] & 0xff000000) >> 24);
//~~~~~~~~~~~~
this->Modified("DisplayList");
this->Trace("<- SetTexture()");
}

/***************************/

Je suis quasiment sûr que c'est la ligne entre ~~~~~ qui rosit la texture. J'ai essayé de changer quelques trucs, mais je n'arrive jamais à retrouver la texture d'origine...

Ah oui, une dernière chose ^^ :
C'est à propos de l'orientation d'un personnage par rapport à son déplacement. En fait je récupère la position courante du personnage et celle à laquelle le personnage va se retrouver. Je calcule ensuite l'angle formé par le vecteur défini par ces 2 points et le vecteur représentant l'orientation d'origine (avant le début de l'animation).
Le problème est que certains de mes personnages ne se tournent pas comme il faut... J'aurais juste voulu savoir si tu n'aurais pas une autre méthode plus efficace, car là je ne vois pas trop comment faire autrement...

Voilà, désolé de t'embêter encore, mais je sens que j'approche du but

pour vérifier la couleur, il faut afficher le RGBA avant et après convertion, ca devrait sauter aux yeux si ca se trouve la!

Pour les textures :
le code ne devrait pas être autant étalé

Quand tu rends ton perso, tu initialise ce qu'il faut
glEnable(GL_TEXTURE_2D)
glBindTexture(...)

pour les coord pour chaque vertex etc

Plus ton code opengl est étalé, moins tu pourra connaitre l'état (y'a vraiment 500 raisons qui font que les texture ne peuvent pas marcher, du chargemet du fichier au fait qu'opengl ne les utilise pas etc).

Pour l'orientation des perso :
Utilise le root bone :
tu as tes 2 points, tu calcul le vecteur entre eux, tu le normalize, et tu obtient le z de ta matrice. tu calculele prod vcectoriel avec le up (0, 1, 0), tu obtient le vecteur right. Tu peux recalculer le vecteur up si ton perso n'est pas droit par rapport au sol.
Ensuite tu multiplie, a l'affichage, le perso par cette matrice (avec la translation en plus).

correction :

Quand tu rends ton perso, tu initialise ce qu'il faut
glEnable(GL_TEXTURE_2D)
glBindTexture(...)

pour les coord pour chaque vertex etc

je veux dire, tu initialise ta texture (enfin toutes les options de rendus propre a ton modèle), puis tu passe les coord de texture, les position, les normal etc pour chaque vertex etc.

Longue absence mais bon, je n'avais pas prévu qu'un prof nous donnerait un projet de plus (le 5ème en tout...) à faire en peu de temps qui plus est. Du coup j'ai passé mes rares moments de vacances libres sur ce projet (du GLSL).

Enfin me voici de retour sur ce fameux TER. J'ai en partie une bonne nouvelle : j'ai plutôt isolé le problème des textures En fait ce n'est en aucun cas un problème d'appel à OpenGL. Du moins ce n'est pas le problème principal.
J'ai pu me rendre compte d'un détail en faisant quelques affichages. Voici le morceau de code :

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

if((pCalRenderer->getMapCount() > 0) && (textureCoordinateCount > 0))
{
..glEnable(GL_TEXTURE_2D);
..glEnableClientState(GL_TEXTURE_COORD_ARRAY);
..glEnable(GL_COLOR_MATERIAL);
..// set the texture id we stored in the map user data
..glBindTexture(GL_TEXTURE_2D, (GLuint)pCalRenderer->getMapUserData(0));
..// set the texture coordinate buffer
..glTexCoordPointer(2, GL_FLOAT, 0, &meshTextureCoordinates[0][0]);
}

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

En fait le problème vient du pCalRendered->getMapCount() qui me renvoie toujours 0, alors qu'au départ, lors de la création du CoreModel, le résultat est le bon. Et là comment dire... je ne sais pas du tout d'où ça vient
Peut-être un problème dans le chargement des textures, au niveau de :

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

textureId = (Cal::UserData)LoadFile(this->ModelPath + strFilename.c_str());
// store the texture id in the user data of the map
pCoreMaterial->setMapUserData(mapId, textureId);

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Sinon tu ne saurais pas d'où peut venir ce problème par hasard ?

Pour ce qui est du terrain rosi, j'ai aussi isolé le problème. C'est en fait une mauvaise manip du prof dans ses conversions manuelles d'image. Un mauvais décalage

Bon, après ça il me restera encore le rapport ^^

je ne me souviens plus très bien comment cal3D gère ces modèles, mais les matériaux ne sont pas décrit par leur format?
Es-ce que le modèle que tu utilise a bien une texture associé?

sinon tu peux forcer la texture a utilisé (sans passer par des appels cal3d genre getmap etc mais en conservant l'id de ta texture).

Salut pilo

Bon et bien voilà, le projet est enfin terminé (enfin presque, reste 1 ou 2 petits détails mais minimes).

Alors :

Le terrain rosi Cela venait bien d'un mauvais décalage d'octets dans sa conversion ^^. En bataillant j'ai bien fini par trouver le bon décalage.

Les textures Alors là, il m'aura fallu toute la journée d'hier pour avoir du résultat. En fait, le problème était plus délicat à trouver mais pourtant assez évident : la création des textures était faite lors de la création d'un modèle cal3d (dans le constructeur). Le problème, c'est qu'avec le reste du code (la trentaine de fichiers du projet), la création d'un modèle se fait avant toute initialisation de l'environnement OpenGL, d'où les textures blanches. Il a donc fallu pas mal modifier le code et maintenant ça marche nickel
Et ça, ça fait plaisir !

Enfin voilà, je te dois pas mal pour ce rapport. Merci infiniment

Par contre j'aimerais te poser une dernière question si possible, mais pas au niveau du codage cal3d. En fait, il reste le rapport à faire. N'etant pas évident, saurais-tu où je pourrais trouver (où aurais-tu, peut-être) un exemple de rapport type ? J'avoue qu'on est habitué à faire des rapports, mais pas de ce calibre et qui va être lu par un juri de profs...
Mais t'inquiètes, si tu n'en as pas, c'est pas grave.
J'essaye juste de trouver de bons exemples de rapport ^^

Pour finir, un petit screen de l'appli :
http://img148.imageshack.ack.us/my.php?image=terwv5.png

Bon et bien au cas où tu repasserais par là sache que c'est bon, le rapport est presque terminé et le prof a décidé de le pré-corriger avant la date de remise, donc il dira ce qu'il faut modifier ou non.

Je te remercie encore une fois pour toute ton aide

Salut!

C'est ce que j'allais te conseiller, de voir avec ton prof. Quand j'avais fais mon TER, mon prof m'avait guidé dans la rédaction et aussi pour la realisation des diapo pour la présentation.

Pour les textures : en effet c'était pas simple a trouver!!
Juste par curiosité, ca parle de déplacement de foule, avec interaction entre les personnages? (un système multi agent?).

Salut pilo

Pour le rapport, le prof ne nous a quasiment pas aidé. Il l'a cependant corrigé avant qu'on le rende, mais l'a trouvé très bien.
Par contre on va préparer la soutenance avec lui cette semaine.

Pour ce qui est du déplacement, je ne saurais pas très bien répondre étant donné que cela concerne une partie du projet qui ne nous concernait pas. Pour ce qui est du système multi-agents, je ne sais pas trop ce que c'est (je ne vois ça qu'à la rentrée prochaine), mais je pense qu'il doit y en avoir un peu, d'après ce que j'ai pu en voir avec 2 copains qui bossaient dessus pour leur TER.
Nous devions pour notre part créer uniquement un chargeur de modèle 3D approprié au projet de manière 'encapsulée' (au projet déjà existant).

En fait le but ultime du projet est de créer un simulateur de déplacement de foule 'intelligente'. Au final, les personnages devront se déplacer en conséquence de l'environnement dans lequel ils se trouvent (normalement marcher sur le trottoir, certains pourront marcher sur l'herbe, d'autres ne se gêneront pas pour traverser une route, etc...). Il faut en gros que cela représente, par exemple, le comportement de plusieurs catégories de personnes, de plusieurs pays différents (tous n'ont pas le même comportement en général). Bien sûr, ils devront contourner les bâtiments, s'éviter entre eux (collisions donc), chercher le plus court chemin ou le plus rapide pour se rendre à un point (toujours suivant l'environnement).
C'est en somme un très gros sujet de recherche qu'a demandé une grande ville, et qui concerne en plus un sujet de thèse (évacuation d'un bâtiment en feu).
Du coup avec mon binôme on devrait apparamment figurer dans le grand rapport de cette recherche comme étant les développeurs du chargeur de personnages 3D à partir de modèles déjà existant.

Voilà, j'espère avoir répondu à tes questions ^^

En tout cas le prof a adoré ce qu'on a fait. Vu le temps passé dessus, ça fait plaisir et ça rassure

Encore moi

J'aurais besoin d'aide ou de conseil de toute personne passant par là.
En fait, ça ne concerne plus mon projet TER (terminé, soutenance lundi prochain ).
Alors voilà, je suis à la recherche d'un stage pour l'année prochaine (de Février à Juin 2009), et de (nette) préférence dans le jeu vidéo (programmation particulièrement). Le problème c'est que je ne sais pas où chercher... on est 3 amis à chercher un tel stage mais on ne trouve rien. Du coup si quelqu'un pouvait m'aiguiller sur le sujet, ça serait vraiment génial ^^ Ou même mieux (sait-on jamais), si quelqu'un connaît des personnes travaillant dans le milieu
Enfin bon, ne trouvant pas, j'essaye tous les moyens qui me passent par la tête. En tout cas ça serait vraiment trop beau

Merci d'avance à ceux qui répondront !

Salut!

Je te dis deja merde pour ta soutenance ;) Mais le projet à l'air plutot interessant, et comme tu as bien bossé dessus ca devrait pas poser de problème!

Pour le stage, le meilleur moyen : envoyer des cv et des lettres de motivation! Tu es dans quel région?

Tu trouvera plein d'addresse ici :
http://www.afjv.com/

Petit conseil : si vous avez des projets, extra universitaire ou non, concernant les jeux video de près ou de loin (developpememnt opengl, animation cal3D, etc), faites en un portfolio que vous joignez avec le cv et la lettre de motiv

Espérons, oui, que la soutenance se passe bien

Nous sommes en Aquitaine, mais apparamment il n'y a pas foule par ici niveau stage.
Pour le lien, on a regardé justement, cette nuit, à cette adresse. Mais bon, on s'est un peu perdus dans tout ça...
On a aussi décidé d'essayer de se faire un projet pendant ces vacances afin de gonfler nos cv (ça ne peut qu'apporter). Vu que tu as fais ton stage dans une boîte de jeux vidéo, tu ne saurais pas quels sont les outils les plus utilisés en général dans le milieu ? Style DirectX, etc... Car on a pu voir que la plupart bosse sous Windows, et comme on a fait que du Linux...
Après on a aussi eu l'idée de chercher du côté du Canada, où ça semble plutôt être intéressant. Mais bon là aussi, pas évident, surtout qu'on aimerait partir là-bas les 3 (pas seul).
Enfin voilà, beaucoup de questions en ce moment, et ce n'est pas facile de faire le bon choix (et de trouver déjà ^^).

Au fait, tu as eu ton stage en envoyant ton cv à afjv.com ? C'est juste pour savoir si c'est plutôt efficace

Bon ben si tu as d'autres liens, ou d'autres moyens, ou même si tu connais des personnes qui pourraient nous aider, nous sommes bien sûr preneurs

En tout cas merci

Salut!

en fait sur afjv tu as les coordonnées de la plupart des studio de developpement, donc il faut regarder ceux qui t'interesse (il doit y en avoir près de bordeaux? y'en a "beaucoup" à lyon, et a paris sinon...), et vous envoyez vos CV partout ou vous le pouvez.
J'avais envoyé le miens à une vingtaine d'addresse... j'ais eu une réponse positive

Pour ce qui est des outils, j'étais dans le meme cas que vous, je ne connaissais que GCC et emacs (et opengl). Alors que pendant mon stage on bossait avec visual studio (et sur PSP). Ca m'a jamais vraiment géner, sachant que vous pouvez découvrir visual studio a travers les versions express (gratuite). En pratique, et surtout à bac+5, c'est pas le genre de chose qui devrait poser problème
DirectX je n'en ais jamais vraiment fait, car je ne bossais pas sur le rendus 3D, mais sur la physique. Maintenant c'est pas très éloigner de OpenGL (a ce que j'ais pu en voir).

Ok merci pour ces infos

Par contre il y a eu du nouveau dans nos envies ^^ En effet, 2 de nos M2 sont en stage au Canada en ce moment même. Ils nous ont dit : "Faut absolument tenter, Ubisoft Montréal recrute à tour de bras".
Du coup ben on va tenter là-bas J'avoue que ça paraît un peu infaisable, mais bon, pourquoi pas (d'après leur site on a les compétences souhaitées). En tout cas ça serait le rêve, trop beau !
En plus de ça, je viens de découvrir que j'ai de la famille (que je ne connais pas personnellement) à Montréal ! Enfin bref, on ose à peine imaginer !!

Mais bon, pour être pris, ça va être une autre histoire... va falloir croiser les doigts

Sinon ben ça sera sûrement afvj...

On va voir ça dans les semaines qui viennent