@Redstar: Les armatures sont déjà animées que si elles sont visibles.

Si tu veut simuler ce comportement (le 'frustum culling') il faut que tu utilise les fonctions dans KX_Camera:

Sauf que les actions sont exécutés dans un script python qui est renouvelé à chaque fois (car le personnage ne fais pas que rester passif, il est censé réagir).

Dans ce cas pourquoi le process "animation" ne diminue pas quand je détourne la vue d'un personnage ?

Salut,

(Je me demande si ce n'est pas déjà le cas par défaut, que les animations ne sont jouées que si visibles, mais je ne suis pas sûr... panzergame, si tu passes par ici...)

Les méthodes getScreenPosition et getScreenVect sont plus ou moins l'inverse l'une de l'autre: getScreenPosition prend un vecteur "réel" 3D en argument et rend un vecteur 2D de l'écran*. Bref elle projette le vecteur dans l'espace caméra (alternativement un objet peut être donné en argument, dans ce cas-là c'est sa position qui est utilisée); getScreenVect prend un vecteur 2D de l'écran en argument et rend un vecteur 3D de la scène.

Elles ne sont pas exactement l'inverse l'une de l'autre, toutefois, puisque getScreenVect rend seulement un vecteur de direction** (pas de position) et en particulier non lié à la position de la caméra.

Admettons que la caméra soit à la position A et l'objet/le point à la position B (vue dans la caméra aux coordonnées écran (x, y)), alors:

1) getScreenPosition prend OB et rend (x, y)
2) getScreenVect prend (x, y) et rend normalize(OB - OA)


Quant à getScreenRay, elle fonctionne avec une "incertitude" en plus, c'est-à-dire qu'elle cherche l'objet situé, vu de la caméra, "sous" la position (x, y). C'est un peu comme un rayCast, mais en utilisant les coordonnées caméra en entrée. Typiquement on utilise cela pour récupérer un objet sous un clic souris dans le viewport (façon Mouse Over).

Les paramètres dist et property permette d'affiner la recherche en spécifiant respectivement une distance limite à la caméra de l'objet (plutôt que l'infini) et une Game Property que l'objet doit contenir pour être détecté.

Dans ton cas - et en imaginant que cette fonctionnalité ne soit pas présente par défaut dans le BGE, ce dont je ne suis pas sûr - il faut plus ou moins:

1) boucler sur tous les objets susceptibles d'avoir une animation

2) prendre leurs coordonnées écran avec getScreenPosition et s'assurer que les deux dimensions sont chacune dans l'intervalle [0.0, 1.0]

3) en tirer des conséquences sur l'animation ou non.

Je vois les problèmes suivants:

- ça risque d'être lourd, tant le bouclage que la gestion des anims en conséquence
- une partie des objets risque de "déborder" sur l'écran même si leur centre défini est à l'extérieur -> utiliser la Bounding Box??
- comme déjà dit, pas sûr que ce ne soit pas déjà implémenté en dur.


Tu peux également regarder du côté de l'Occlusion Culling, ça peut peut-être aider.


* les vecteurs 2D d'écran sont définis de façon à avoir le point (0.0, 0.0) en haut à gauche et (1.0, 1.0) en bas à droite - donc le centre du viewport à (0.5, 0.5).


** c'est normal, la fonction ne sait pas à quelle distance on doit regarder, donc par défaut le vecteur est normalisé - longueur 1.0; on peut aussi voir ça comme une conséquence du manque d'informations: on donne deux arguments scalaires en entrée - donc deux degrés de liberté - or on ressort un 3-vecteur, donc trois scalaires; par conservation de l'information, il manque un degré de liberté et les trois scalaires ne sont donc pas indépendants.


EDIT: Quand on parle du loup... Salut panzer'!

EDIT 2: oui, j'ai vraiment mis plus d'une heure à rédiger cette réponse...

Ok, je vais regarder et tester quelque chose.

Je suis maintenant sur blender 2.75 et j'ai remarqué le systême LOD "Hysteresis" dans la scène et dans un objet.

Je ne comprends pas bien son effet. C'est le fameux LOD qui permet de faire un "open world" (ce qui m'étonnerai mais pourquoi pas) ?


Édit: J'ai un autre point que je ne comprends pas:

Une connaissance, qui as Windows 10, a voulu tester mon jeu. Comme j'avais compilé le lanceur (le bge stand alone) sur blender 2.70, c'était normal que ça ne fonctionnait pas.

J'ai donc compilé le lanceur avec blender 2.77 et le jeu à fonctionné normalement chez lui.

Á ce niveau là, j'avais eu récemment connaissance d'un problème de "pulse mode True" sur 2.77 (et 2.76 au passage) et j'en avais constaté les conséquences chez moi. Or, la personne à qui j'ai refilé le lanceur version 2.77, m'avais affirmé qu'il n'y avais aucun problème !

Donc je me dit, ok, tant mieux ! Donc j'ai essayé blender 2.75, j'ai constaté qu'il y avais les même fichiers et dll que 2.77 et j'en ai conclu que ça passera sur Windows 10 aussi pour la prochaine compilation de mon jeu.

Hier, j'ai un utilisateur d'un forum musical qui à voulu testé le jeu et j'ai du recompiler le lanceur en 2.75, naturellement.

Et voilà maintenant que le jeu se lance mais il plante juste au moment ou il dois changer de blend (gl.startgame(blend)) !

Remarque: J'ai pas fais de modification sur le blend où se trouve cette ligne.

Je fais ça, -->>

Et je réessaye avec un lanceur en version 2.70 (j'avais fais un backup) et ça fonctionne sans broncher !!!

'Comprends pas ! 'Comprends pas !

Il DOIS y avoir une explication logique et rationnel !!!

Remarque: Matpi et Panzergame, vous pouvez essayer en téléchargeant le lanceur et mon jeu en cliquant sur ma signature.


edit: Avec la contribution de theo29270 et d'un utilisateur d'un autre forum, j'ai pus trouver une version stable pour Windows 10 et les versions antérieurs.

Citation :


Si tu mets "Hysteresis" a 10% et 100 en distance ça veut dire que si tu t'approche a moins de 100 de l'objet il faudra que tu recule jusqu’à 110 de distance pour que le lod se désactive. (ou s'approcher a - de 90 et reculé jusqu'a 100 pour reprendre son état , je sais plus ) .
Ça évite que si on se trouve a 99.999 de l'objet que ça change de mesh des qu'on bouge un manometre .


édit :
Au sujet des animation.
Dans mon jeux j'ai fait un système de liste. Toute les nouvelles animations (d'armature) sont ajouté dans une liste.
Pour chaque animations il y a une variable qui la lit virtuellement pour savoir a quel frame en est l'animation mème si elle n'est pas encore joué.
Quand le perso passe devant la camera (avec les frustum comme Panzergame a dit) je joue les animation dans l'ordre en la démarrant a la frame ou elle devrait être grace a la variable.
Si une animation a été joué quand le perso n’était pas visible (mort par exemple), je joue seulement la dernière frame de l'animation pour pas le voir mourir seulement quand je le vois.
C'est encore en teste mais pour l’instant ça fonctionne bien. Avant se système, mes persos marchaient couché car je les ai bien vu mourir mais ils étaient pas devant la camera quand ils ressuscitaient !
J’espère que ce que j'ai baragouiné a été compréhensible

Voilà ce que j'ai fais (cas 1).



J'ai malheureusement pas tout compris par rapport aux explications de chacun.

Pour commencer, les fonctions donnée par panzergame me sont étrange quand je lis l'api python.



J'ai du mal à visualiser le fait d'ajouter des valeurs de cette façon. Pourrait-on illustrer cela par le Cas 1 ?

En rapport aux explications de matpi, est-il possible de pousser le vice et faire comme le cas 2 (avec un cube virtuel)?

tonycheuh, je suis pas sûr d'avoir compris ton message, je ne comprends pas l'intérêt de mettre toutes tes actions dans une liste...

Mon but en fait est de faire comme ceci:

Bonjour,

J’aimerai savoir ce que signifie cette erreur:

Salut,

Citation :

Oui, mais avec la liste "box" représentant ton carré vert (typiquement la bounding box du personnage) et le "cube" rouge étant le view frustum (https://en.wikipedia.org/wiki/Viewing_frustum). Ta partie rouge n'est avec cette méthode ainsi pas un objet que tu définis, mais découle directement des paramètres de la caméra.

Si tu veux définir manuellement et le cube vert, et le "cube" rouge pour détecter des intersections, il faut le faire à la main.

L'exemple donné consiste simplement à définir la liste "box", à y insérer des valeurs pour chaque sommet (avec append, mais on pourrait tout insérer en une fois) puis à tester cette boîte.

Citation :

Peut-être qu'utiliser le type d'objet Occluder pour les "obstacles" peut fonctionner. Via Python, par contre, je ne sais pas s'il y a une méthode "propre" ou semi-automatisée pour le faire, ou s'il faut tout coder par toi-même. A quoi ressemble actuellement ton code de détermination de la prop "anim"?

Citation :

Ça a l'air lié à libload d'objets contenant des senseurs physiques (Touch/Collision). Est-ce un cas présent dans ton jeu?