Bonjour,

Je me pose en ce moment deux questions technique sur le BGE:

J'ai fait un laucher qui me permet de regrouper mes futurs projets mais il est probable que chaque projets soient conçus avec des versions différentes de blender (bah oui, blender est souvent mis à jour, logique ).

Ma première question:
Quand on compile le BGE, en supposant que d'une version à une autre un sensors ou une fonctionnalité à été supprimée, cela concerne t-il le stand-alone en lui-même où les blend ?

Autrement dit, si je compiles le stand-alone en 2.50 ou en 2.70, Si je lance un blend d'une version différente, dois-je m'attendre à un bug ?

Ma deuxième question:
On dit que les matériaux consomment du process durant le jeu.

Si j'importe un blend de façon dynamique (Libload), les matériaux de ce blend sont-il rajouté et, par conséquent, rajoutent du poids ? Ou ça reste des datablock ?

En supposant que je n'ajoute pas d'objets provenant du blend chargé, bien sûr.

Salut,

Première question: la "compilation" d'un standalone est en fait une opération extrêmement idiote (du point de vue informatique):

AVANT


APRES


Je sais pas si mon "dessin" est assez explicite, mais ce que je veux dire c'est que la soi-disant "compilation" du standalone consiste simplement en

1. la copie du fichier blenderplayer.exe, qui va donc fournir l'exécution

2. l'ajout à ce fichier, simplement à la suite, du contenu du fichier .blend, qui va donc fournir le data

3. l'ajout finalement de quelques bits d'information pour

a) indiquer à l'exécution que du data est contenu dans le fichier lui-même (mot magique "BRUNTIME")

b) spécifier la plage de ce data dans le fichier .exe en indiquant tout bêtement la position de la séparation entre data du .exe et du .blend (la position * dans mon deuxième diagramme).

Si on lance le standalone, il va donc aller chercher dans ses propres entrailles

1. l'information selon laquelle il contient du data customisé ou non (mot magique)

2. le cas échéant, ce data en lisant au préalable la plage concernée.

Bref, la réponse est simplement que le moteur de jeu est le même qu'en interne à Blender, donc les mêmes risques s'appliquent.

Dans l'absolu tu pourrais lancer indépendamment d'autres instances de blenderplayer.exe - dans des versions correspondant donc aux fichiers .blend concernés - à partir du principal, à l'aide d'un subprocess. Mais ça implique d'avoir les différentes versions du player sous la main. Pas sûr que ce soit ton but.

N.B.: le fait que la procédure de "compilation" soit si triviale rend également le processus inverse très simple - voir l'un des addons sur mon GitHub (lien dans ma signature).

ça résume effectivement ce que je pensais.

Tout ceci explique pourquoi le dossier "lib" est dans "2.70" par exemple.

Mais c'est bien ce que je craignais pour la compatibilité des versions. Cela dit, c'est pas insurmontable (du moins, je l'espère )

Petite question le "pad" signifie une manette de jeu je suppose ?

Non pas du tout.

J'ai utilisé le mot "pad" comme on le trouve dans le code Blender à certains endroits, mais c'est un abus de langage.

Je voulais simplement indiquer que ce sont quelques bits ajoutés au fichier et qui servent à stocker des informations pour le runtime.

Voir mes points 3.a) et b) du post précédent.

"To pad" veut aussi dire "rembourrer". Ça s'utilise plus souvent dans des contextes où un paquet de données ou un fichier doit avoir une taille fixe ou minimale (champ d'une base de données, paquet de données TCP...). Si ce qu'on veut enregistrer ou envoyer est plus court que ce minimum, on ajoute des bits pour compléter, de la même façon qu'on rembourre un colis avec du polystyrène. Ici, c'est de données utilisables qu'il s'agit, pas d'un tas de bits arbitraires pour occuper l'espace, donc il n'est pas vraiment approprié de parler de padding, mais on n'est pas à un petit abus de langage près .

...Et dans le cas de Blender on l'utilise dans le DNA pour aligner les blocs de bits en mémoire (par 8 bytes, sauf erreur).

En même temps, trouver un autre mot de trois lettres qui évoque cette idée...

Bonjour à toutes et a tous,

Je ré-ouvre ce topic car j'ai un problème avec blender 2.77.

En effet, je développe mon projet depuis Blender 2.70. J'ai voulu passer sur blender 2.77 pour la portabilité Windows 10.
Comme j'avais précédemment posé des questions au sujet des changements/correctifs etc., j'étais prévenu.

Quand j'ai voulu continuer à développer mon projet, j'ai constaté deux problèmes: l'actionneur "action" en mode "propriété" ne fonctionne pas très bien voire pas du tout.

Après avoir cherché le problème, je me suis rendu compte que c'est (ou ça semble) le senseurs "always" (pulse mode) qui est responsable. J'ai pus constater ça sur un autre objet de ma scène. Voyez plutôt:

Mais là, c'est pas possible, il y a vraiment un problème.

Remarque1: Il est possible que le "bug" ne se produise pas tout le temps où différemment (testé ailleurs).

ça m'embête beaucoup car ça casse certains systèmes mis en place précédemment et je peux plus avancer.

J'ai constaté ça aussi, j'ai du bouger certaines choses a cause de ça. J'en ai profité pour revoir toutes mes briques logiques. J'ai l'impression que les pulses sont bien moins supportés car chez moi cela fonctionné mais avec beaucoup de lag voir plus du tout.

La version 2.76 est aussi concernée (j'ai voulu tester)...

Par contre, il semblerai qu'en stand alone, ça ne se produit pas... comme si la version 2.77 détectais des fichiers .blend 2.70 et se mettait en 2.70 (j'ai fais testé par une connaissance qui a Windows 10 et il ne m'a rien dit au sujet d'un "bug" que je rencontre actuellement).

Et le fichier blend est celui de la béta 0.2 (que je n'ai pas modifiée, naturellement).

Quand je sortirai la version 0.3, je ferai un laucher en 2.77 (pour win 10) et un en 2.70 en plus pour comparer et voir ce que ça donnera...

Bonjour,

Je suis à la recherche d'une méthode python qui me permettrai de faire animer une armature dans le champs de vision de la camera.

ça me permettrai d'optimiser au maximum le process "animation" et gratter quelques fps.

Mais parmis ces 3 méthodes, je ne sais pas laquelle peut convenir:



La 3e me semble la plus intéressante mais je ne comprends pas l'intérêt des arguments x et y.

Je veux que ça prenne l’entièreté de la camera en compte. Si je mets la hauteur et la largeur de la camera, ça peux marcher (je sous entend bge.render.getWindowWidth() et height) ?