Raydium 3D Game Engine

Bonjour,

Le code de picking marche à merveille , voici le détail.
Pour le moment il s'agit d'une fonction qui renvoie juste l'objet pointé.

La méthode ressemble beaucoup a tes recommandations , en fait c'est de loin la meilleure solution, mais je n'avais pas assez bossé la partie collide d'ode.
Maintenant c'est fait !

Jette un oeil pour les "grosses" bourde, j'incorpore ça dans le svn après.

Est ce que j'essaye d'ajouter un gravity gun à test6, je sais que ne veux pas trop surcharger test6.
Sinon dans quel testx penses tu qu'il faudrait l'integrer.

J'ai aussi implanté le support des rayon pour les objets statiques.
Je récupère les infos de position / orientation du geom et pas du body.
Cela permettrait de faire des détecteur "passif" (trigger ???)
As tu une opposition de principe ?

A+
Jacques

Pas mal, pas mal C'est effectivement très proche de la manière dont je voyais les choses !

Ma seule objection concerne l'absence de retour des coordonnées du point de picking. Ta fonction actuelle est cependant très pratique pour les bindings (uniquement une valeur de retour entière), ce qui me fait penser qu'il faudrait sans doute proposer au moins deux versions de cette fonction (sans redondance de code, bien sûr). Je vais attendre de voir comment tu utilises cette fonction avant de m'avancer. En clair : complétement OK pour le commit, c'est du bon boulot !

En ce qui concerne l'écriture d'un test pour le picking, test6 me semble être une très bonne idée. Il faut cependant faire gaffe à ce que le code ne soit pas trop long, quite à rajouter de nouvelles fonctions pour aider à "l'attachement d'objets pickés" dans RayODE.

PS : Pour les rayons sur les geoms, je serais assez intéressé par le fait de voir le code. C'est possible ou tu as tout prévu dans un seul commit ?

PS2 : Pour le picking, il faudra surement prévoir un callback pour que l'utilisateur puisse exclure certains éléments. Ou plus simple.
L'exemple qui me vient à l'esprit pour ce problème est la sphére qui représente le joueur dans test6 : en vue à la première personne, le picking va toujours trouver la sphère, et pas ce qui est "juste après".

Beaucoup de lecture:

Voici le nouveau proto de la fonction de picking:


Le pciking renvoie l'id de l'object et la structure du contact avec toutes les infos (pos, depth, normal, ...) dedans. Je rajouterai des fonctions:
raydium_pick_get_pos(raydium_pick_info pick_pt);
raydium_pick_et_depth(...


Je passe sur les details du code.
J'ai ajouté les callback d'espace et de collision.
Par contre le rayon n'a pas d'existance en tant qu'element raydium.
Les callback sont appelés avec 2 fois le meme objet (celui qui est touché par le rayon).
Sinon plutot qu'un callback on pourrai faire du picking avec distance min et max, moins souple.

L'utilisation devient:



Concernant les rayon sur geom
dans ode.c 3927 ( a peu pres)




je vais remplacer la multiplication de matrice par le dMultiply133 d'ode qui semble largement plus optimale.
Normalement ce code ne doit rien "casser".

Enfin dans quel fichier le picking finira ???
ode.c me semble un peu gros non ?
picking.c un peu petit.

A toi de voir.
A+
Jacques

Ok, ça devient du massif tes posts là

Quelques remarques dans le désordre :

- Je pense que tout ça doit aller dans ode.c (et les noms de fonctions doivent refleter ça (raydium_ode_pick_...). Personnellement, les gros fichiers ne me gênent pas, mais il est tout à fait imaginable de fragmenter ce fichier (tout comme ode_net.c en fait).

- Les callbacks ("le", à mon avis) ne doivent servir qu'a filtrer si l'objet (ou l'élément ?) doit être utilisé pour le picking. Un truc du genre :

Qu'en pense tout ?

- Même si c'est discutable, le style de Raydium consiste à cacher un maximum les structures. Du coup, je suis pas fan de "raydium_pick_info"
Ou alors, sous forme d'une version "avancée" du picking ?
Que pense tu de ça ? :

(par exemple)
La première faisant appel à la seconde, bien sûr. Il est même possible d'imaginer une version qui retourne l'ensemble des contacts trouvés (là sous forme de dContact), et ainsi de suite.
Ça parait peut être lourdingue et un peu inutile, mais ça me semble important de proposer à la fois une fonction "KISS" et d'autres plus complètes/complexes, pour que tout le monde y trouve son compte.

- Le support des rayons sur les éléments statiques me semble tout à fait OK. Si tu as eu le temps de tester cette partie là, n'hésite pas à commiter.

- Ton exemple d'utilisation me va, mais c'est la partie création de contact pour le "gravity gun" qui me semble plus complexe. J'avoue ne pas avoir réfléchit plus que ça à cette partie

Comme d'hab, tout ça représente ma vision du bidule, et pas la voie à suivre obligatoirement

Soucis ...

Le picking à besoin des matrices de projection et autre.
Il ne peut donc être appelé qu'après le début d'un render
(camera_replace).
Comment pourrais-je avoir les info sur ces matrices en dehors d'un contexte de rendu (sont elle cachées quelque part dans raydium ?).



A+

ouille, je réveille ce post, car il proposait des choses intéressantes et très proche de leur version finale. Ou en est-tu ?

Je ne me souviens pas avoir vu ce dernier post, donc mes excuses si tu attendais une réponse pour aller plus en avant En l'occurence, quelles infos te manque t'il précisément ?

Bonjour,

Je n'ai pas vraiment eu le temps d'avancer, et ca ne va pas en s'améliorant ;o(

Concernant le picking, l'algo marche mais si je me souviens bien il y a quelques soucis sur lesquels je n'ai pas réussi à trancher.

1) Le picking dépend des matrices de projection on ne peut l'appeler que dans la partie de code qui assure le rendu.
Ceci limite les possibilités d'appel, et risque de poser des problèmes pour des utilisateurs non avertis.

2) Les infos retournées par le picking sont assez nombreuses suivant l'utilisation:
----1) Objet pické
----2) Distance
----3) Point relatif de piking
----4) ...
Le retour de l'ensemble des ces infos dans un structure serait très lourd.

Faut-il cacher ces infos pour les renvoyer par la commande raydium_ode_mouse_pick idoine ?

Faut il refaire le picking à chaque fois ?

Si vous avez des idées j'essaierai de reprendre le code.

La dernière question etait dans quel fichier l'inclure mais je crois que tu avais tranché pour ode.c


A+
Ouille

OK, c'est une bonne remise en conditions ... Ceci est la 3éme ré-écriture complète de ce message (Je [re]découvre les problèmes en question au fur et à mesure de l'écriture de ce post).

En ce qui concerne les limitations au niveau des matrices : OK avec toi, ça ne m'avait pas sauté au yeux la dernière fois. Raydium ne stocke pas ces informations, donc j'ai ajouté à l'instant ce code (c'est stocké au début de chaque frame), tu diposes donc des informations en question avec les variables :
(commit 540)

N'oublie pas de virer ton camera_replace, qui va tout casser dans certains callbacks

Ensuite, en ce qui concerne le retour des infos de picking, je te renvoie a ma précédente conclusion avec laquelle je suis d'accord (si ! ), c'est à dire deux fonctions :
- une simple : int raydium_ode_pick_mouse_simple(float dist)
- une complète : int raydium_ode_pick_mouse_full(float dist, dReal *pos, dReal *depth); // writes to pos[3] and depth
- et peut être même une dernière qui retourne le dContact lui même, si tu penses qu'il y'a a un intérêt (tu es aussi un utilisateur de Raydium, je te laisse juge)

Bien sur, seule la fonction la plus complète "existe", les autres ne font que simplifier l'appel de la première. Le post de DaveMDS montre bien que la plupart des utilisateurs vont chercher avant tout une fonction simple, au moins au départ. Je persiste donc à préférer cette approche sous formes de plusieurs fonctions. Je ne suis pas sûr d'être très clairs dans mes formulations, n'hésite pas à me demander une reformulation si nécessaire

Quand à refaire le picking à chaque fois, nous nous étions (je crois m'en souvenir) orientés dans un principe de picking ponctuels, donc il me semble logique de demander à l'utilisateur de relancer le picking à chaque fois qu'il souhaite cette information, et implicitement lui montrer qu'il a tout intérêt à se débrouiller pour que ça n'arrive pas 60 à chaque frame (la doc devra faire état du "prix" CPU de cette fonction, à mon avis).

PS : on met de coté pour l'instant les histoires de callbacks, mais je pense qu'il y a des petits ajustements à faire à ce niveau (cf quelques posts plus bas). On verra ca une fois le premier commit effectué.

ouille, histoire qu'on avance sur ce sujet (plusieurs demandent semblent arriver), as-tu du code à poster (même ici) pour l'instant si tu souhaites que je bosse dessus ?
Sinon la réponse ci-dessus te convient-elle ?

PS au cas ou : Je comprend tout à fait que tu ne puisse pas bosser là dessus en ce moment, pas de problème à ce propos hein

Salut,

J'ai vu le post, mais je n'ai pas ma machine de de développement sous la main.

Je m'y remet debut septembre. A prioiri j'ai toutes les infos.

Le code sera à 99% celui posté.

Je vais regarder du coté d'ode je crois qu'il est possible de ne renvoyer que le premier contact


On gagne un peu pour les collisions trimesh.

Je garde le proto de fonction defini ensemble (retourne element, distance et coordonnées point de "contact").

Le tout dans ode.c

donc si il n'y a pas d'urgence absolue ...

A+
Jacques

Entendu ! Bonnes vacances

Hello,

mouse picking is implemented in raydium.

See test6 with F8 and F9 view mode.

Try to drop boxes with 'space'

Left mouse button implement a sort of levitation gun.

Bye.

Ouille.

Nice ! I'll try to update a bit test6, we could make great things with this new function, I think (like a famous gravity gun). Good work, ouille.

Note: I've fixed a bit indentation and remove 3 unused variables.

Hello,

I've make some tests for gravity gun but i have some problems and parameter to fix to have a good feeling.

I have to work on a raydium remote with socket. That's why i just commit minimal.

A+
Ouille

I've seen a little bug making test with test6.c
If we put a pickmouse when the camera is inside the "player" element, the resulting values is always 6(the element "player") and the numbers are values from the origin of the camera to the colliding point inside the "player".

I think raydium_ode_pick_mouse should ignore elements when the origin of the ray is also inside the elements. Sadly i don't know ODE so i can not the patch.

One more thing, the collision test are done against the bounding box of each element, not the mesh of the element.

What do you say?

Maybe i'm talking about things you already spoke, but the main of this thread is in french