Bonjour à tous.
Je me dirige vers vous une fois de plus pour demander conseil. J'aimerai savoir si l'utilisation d'un moteur physique me permettrai d'affiner mes détections de collision. Avant d'en dire plus, je mets ci-dessous deux images illustrant mon cas:
Voici la première:
Et la deuxième qui est un autre point de vue:
Actuellement j'utilise les méthodes de collision d'Irrlicht et la création de boundingbox automatique comme enveloppe de collision. Comme on peut le voir sur les images, la collision est fonctionnelle mais pas très précise.
Du coup, je me suis demandé si un moteur physique pouvait mieux m'aider comme par exemple prendre le maillage de l'objet lui-même (même si je sais qu'en temps de calcul c'est beaucoup trop gourmand, je l'ai testé avec Irrlicht juste pour voir combien je passais de 60 fps à 0.5 fps ) ou encore d'autres techniques qui me sont inconnues .... Qu'en pensez vous?
Merci.
Dernière modification par Gehogor (13-10-2009 17:28:59)
Hors ligne
Certains moteur physique mettent à disposions un ensemble de fonctions permettant une gestion des collisions relativement
simple à mettre en oeuvre, et surtout à la fois plus précis et plus rapide que les fonctions natives d'Irrlicht.
Personnellement, je conseille Newton 2.xx, qui propose sa sous-couche de gestion des collision de manière assez simple, et
plutôt bien optimisé. Tu peux la mettre en oeuvre, sans pour autant faire appel à la partie physique.
Hors ligne
Et bien ainsi soit-il... J'attendais une réponse dans ce genre pour me lancer. Je vais donc intégrer Newton 2.xx.
Merci tmyke et bonne soirée.
PS: J'ai vu qu'il y avait une rubrique projet professionnel robotique et médical, exactement l'utilisation que j'en fais . Du coup, je ferai dès que mon emplois du temps me le permettra une explication précise du soft sur lequel je suis et qui se nomme "RoboticsCell" (si bien sûr tel est le but de ces rubriques!).
Dernière modification par Gehogor (13-10-2009 21:47:53)
Hors ligne
Gehogor :
PS: J'ai vu qu'il y avait une rubrique projet professionnel robotique et médical, exactement l'utilisation que j'en fais . Du coup, je ferai dès que mon emplois du temps me le permettra une explication précise du soft sur lequel je suis et qui se nomme "RoboticsCell" (si bien sûr tel est le but de ces rubriques!).
Bein figure toi que j'avais pas du tout pensé à créer cette rubrique jusqu'au jour ou j'ai vu ton projet donc c'est bien le but de cette rubrique.
Par contre une question me taraude: ect-ce que Irrlicht est suffisament fiable pour un domaine dans lequel les mots "erreur" ou "bug" n'existent pas ?
Bon ok j'exagère, mais d'après mes souvenir; il y a + de dipositifs de sécurités qu'autres choses sur les appareils médicals.
Hors ligne
J'en profite, moi aussi je me pose la question d'intégrer Newton dans mon projet depuis quelque temps, mais je me demande si c'est vraiment nécessaire. Pour ma part, la grosse majorité des collisions n'ont pas besoin d'être ultra précise, donc des Bbox sont suffisantes, sauf dans le cas de collisions avec le terrain.
Du coup je me demande est-ce que ce n'est pas un peu trop "usine à gaz" d'utiliser Newton pour ce genre de collisions ? Est-ce que je vais y gagner (en temps de calcul en particulier ?)
Hors ligne
nico :
Par contre une question me taraude: ect-ce que Irrlicht est suffisamment fiable pour un domaine dans lequel les mots "erreur" ou "bug" n'existent pas ?
C'est une très bonne question. Déjà en amont de la sécurité software il y a des sécurités électromécaniques certifiées médicales. Il n'y a donc pas de problème. Par contre, il n'y a aucune aide à l'utilisation de ces machines, pas d'évitement de collision, pas d'aide à la manipulation. Et c'est là dessus que je travaille. C'est un peu comme des options supplémentaires d'un peu plus haut niveau. De plus c'est aussi un gain de temps pour les hôpitaux lorsqu'on automatise des processus, même si ça "bug" une fois de temps en temps, la vie des gens n'étant pas en danger par la conservation des sécurités primaires, tout le monde y gagne.
Ps: bon, il est vrai que c'est mieux si ça ne plante jamais, de mon coté Irrlicht n'a jamais planté tout seul, sauf à la mise en veille de linux (mystère). En un même temps, je suis pour tenter des innovations de ce type, comme associer robotique et moteur 3D, sinon on n'arrivera pas à avancer ...
Hors ligne
à d'accord, c'est vrai que c'est une bonne idée, j'espère que ça aura du succé
En tout cas n'hesite pas à présenter la partie electronique et mecanique en plus de la 3d, enfin je sais pas si tu t'occupe de ça mais ayant fait un peu d'electronique je suis forcement curieux de voir le fonctionnement de l'ensemble.
Hors ligne
Hawk :
J'en profite, moi aussi je me pose la question d'intégrer Newton dans mon projet depuis quelque temps, mais je me demande si c'est vraiment nécessaire. Pour ma part, la grosse majorité des collisions n'ont pas besoin d'être ultra précise, donc des Bbox sont suffisantes, sauf dans le cas de collisions avec le terrain.
Du coup je me demande est-ce que ce n'est pas un peu trop "usine à gaz" d'utiliser Newton pour ce genre de collisions ? Est-ce que je vais y gagner (en temps de calcul en particulier ?)
En fait, je pense que pour quelques truc basic, les fonctions d'Irrlicht sont certainement très suffisantes. Par contre, dès que l'on à besoin de
scenes un peu plus étoffées surtout couplé à une bonne précision ( par exemple des niveaux quake3, de vastes terrains, etc...), alors passer
par une lib tierce me semble une solution fort intéressante...
Hors ligne
Merci pour ta réponse tmyke. Je pense que je vais rester avec les fonctions Irrlicht pour le moment dans ce cas.
Hors ligne
Options | Liens officiels | Caractéristiques | Statistiques | Communauté |
---|---|---|---|---|
Corrections |
|
xhtml 1.0 css 2.1 Propulsé par FluxBB Traduit par FluxBB.fr |
882 membres 1429 sujets 11119 messages |
Dernier membre inscrit: LiseBuisson96 30 invités en ligne Aucun membre connecté RSS Feed |