[Titres-Items] Gérer les objets (multi-enviros et formats)

[meuh21]

Le fait que nous ayons eu différentes générations d'objets (ou items maintenant) et l'arrivée du multi-environnements m'amènent à faire part de quelques observations et à poser quelques questions :

Lorsque l'on importe un objet avec le fichier.Item.xml on définit la collection. Ce point est primordial car je ne vois pas comment revenir en arrière ensuite. Effectivement, si l'on change la collection dans un 2ème temps, par exemple de Common à Valley, alors la map ne reconnaît plus l'Item . Donc dans les faits, on ne peux plus changer la collection lorsque un item a été utilisé dans des maps.

Ce point crucial me posait problème car j'avais eu une fâcheuse tendance à faire des items en collection Common en me disant ça peut servir. MAIS si cet objet utilise des textures d'un environnement (ex : Valley), quand il est utilisé dans un autre (ex : Canyon) les textures provenant de l'environnement de départ (ex : Valley) deviennent blanches... SAUF qu'un nouveau test dans le titre Nadeo multi-environnements (et non un environnement séparé) m'apporte une bonne surprise les textures de Valley sont disponibles dans Canyon (et aussi dans Stadium)
Ma première question : Est-ce que quelqu'un peut valider ce point ?
Mon nouveau problème : j'avais corrigé le tir et mes nouveaux objets ne sont plus en Common (qui en plus ne permet pas de "NotCollidable" + "Wood" : voir http://forum.maniaplanet.com/viewtopic. ... 14&t=27438) mais en Valley... Existe-t-il un moyen de revenir en arrière (changer de collection) sans casser les maps qui utilise ces items ?

Les difficultés liées à l'ancien format des objets (.ObjectInfo) sont du même ordre. Pour garantir la compatibilité des anciennes maps avec une nouvelle version d'un titre, je me dois de conserver les anciens objets. Pourtant, j'aimerai que ceux-ci profitent des nouvelles fonctionnalités (voir supprimer certains objets). Existe-t-il une astuce ? Sinion je vais bricoler quelque chose en faisant des icones grisés pour que ces objets ne soient plus utilisés dans les nouvelles maps, éventuellement en les remplaçant aussi par des formes basique pour encourager les mappeurs à modifié leur maps ou à mettre des textures blanches pour arriver au même objectif (tout en supprimant des textures pour alléger le titre).

Avoir les textures de Valley disponibles dans Canyon (et vice-versa) est une excellente nouvelle qui mérite toutefois d'être confirmé avant d'ouvrir le Champagne Merci d'avance

[damien]

hello,

1. pour le fait que les textures de Valley son disponibles dans canyon : Oui, ca marche, mais c'est uniquement dans le contexte du titre multi-env, (qui "ouvre" et rend disponible les fichiers de chaque env).

2. Aujourd'hui on ne peut pas revenir en arriere (changer de collection) sans casser les maps.
Et on ne peut pas charger une map si les objets ne sont plus la.
Faudrait pouvoir marquer des objets comme "obsolete" et qu'ils n'apparaissent plus dans l'editeur...
Aujourd'hui on peut pas, on va voir si on le rajoute.

3. Tu peux détailler le pb du wood + notcollidable ? (et envoyer les fichiers qui posent problème ?)

merci !
damien

[meuh21]

3. Tu peux détailler le pb du wood + notcollidable ? (et envoyer les fichiers qui posent problème ?

Je t'envoie un MP avec les fichiers pour le "NotCollidable" dans Common (il se peut que j'ai fait une erreur quelque part...)

1. pour le fait que les textures de Valley son disponibles dans canyon : Oui, ca marche, mais c'est uniquement dans le contexte du titre multi-env, (qui "ouvre" et rend disponible les fichiers de chaque env).

Après un peu plus de réflexion il me semble que créer en Common des Items qui utilisent des textures d'un environnement donné va demander un peu de dextérité (soit utiliser l'ancienne méthode avec _TDSN et sans <Material> ou alors avec une ancienne version de l'importer) mais ça paraît encore faisable

Si je comprends bien toutes les textures de tous les environnements sont disponibles dans un titre multi-environnements ? Est-ce que utiliser cette possibilité en multipliant les textures du jeu dans les Items risque de ralentir ou perturber le jeu ? Ou est-ce que de toute façon elles sont d'office présentes et les mettre ou non dans des objets ne change rien ?

Cette dernière information est primordiale pour savoir dans quelle direction aller... ou pas

[Fix]

Petite précisiion de language :
la Texture correspond à l'image utilisée (la diffuse est une texture, la normap map aussi, etc..). Le Materiau appelle plusieurs Textures (DNSIE etc...) pour les combiner avec l'éclairage (pour faire simple) et donner le résultat final.
Donc, ici tu parles de "Materiau" et non pas de Texture.
Nous avons historiquement synchronisé la nomenclature des Materiaux avec celle de leurs textures (ou vis versa), ce qui peut prêter à confusion (c'est le cas ici), mais globalement aide 90% du temps à comprendre qui fait quoi et à retrouver ses petits dans des centaines / milliers de fichiers.

Quand tu charges une map valley, seulement les Materiaux Valley sont dans la carte graphique. Ensuite déchargées pour charger celles du prochain enviro (les changement de maps en multiEnv sont donc plus long quand on change d'enviro).

-Si un item charge un Materiau canyon, ça fera des textures en plus en mémoire (je ne pense pas que ça charge toutes les textures de l'enviro canyon, mais je n'en sais rien à vrai dire).
Ça équivaut à priori a avoir quelques Materiaux custom en plus (sauf que les joueurs n'ont pas à télécharger ces données, déjà incluses dans maniaplanet , si ils ont déjà tous les TM (nécessaire pour le mutienv)
-Si un mod est appliqué à la map, les textures appelées par ce matériau ne seront pas modifiées/modables, car externes à l'enviro en cours.

-Une texture de plus ça fait de la charge mémoire en plus, mais quand il n'y a plus de place dans la carte graphique, maniaplanet diminue la résolution des textures. Ca devient flou, mais ne ralenti pas.

-Un matériau (souvent 3 textures) en plus, ça fait une primitive graphique à envoyer à la carte graphique (GPU) en plus, et ça... ça coute du temps de calcul processeur (CPU).
De manière générale, moins il y a de matériaux différents, mieux le moteur se porte.

[meuh21]

Petite précision de language :
la Texture correspond à l'image utilisée (la diffuse est une texture, la normap map aussi, etc..). Le Materiau appelle plusieurs Textures (DNSIE etc...) pour les combiner avec l'éclairage (pour faire simple) et donner le résultat final.
Donc, ici tu parles de "Materiau" et non pas de Texture.
Nous avons historiquement synchronisé la nomenclature des Materiaux avec celle de leurs textures (ou vis versa), ce qui peut prêter à confusion (c'est le cas ici), mais globalement aide 90% du temps à comprendre qui fait quoi et à retrouver ses petits dans des centaines / milliers de fichiers.

Je crois que j'ai aussi fait une confusion quand j'évoque les matériaux dans un autre sujet. Je me basais sur le terme "material physicsId list" de la documentation. Mais si je reprends la "Library" on a DMaterial qui correspond donc à un matériau. Celui-ci regroupe donc des textures "DTexture" et le comportement physique du Materiau (DSurfaceId). Comment on doit appeler ce dernier in french (ou même en anglais) ? Physics, Surface, id ?

Quand tu charges une map valley, seulement les Materiaux Valley sont dans la carte graphique. (...)
-Si un item charge un Materiau canyon, ça fera des textures en plus en mémoire (je ne pense pas que ça charge toutes les textures de l'enviro canyon, mais je n'en sais rien à vrai dire).

Quelqu'un peut-il nous dire si c'est un matériau ou tous les matériaux de l'environnement qui se chargent car ça change sacrément la donne...

Ça équivaut à priori a avoir quelques Materiaux custom en plus (sauf que les joueurs n'ont pas à télécharger ces données, déjà incluses dans maniaplanet , si ils ont déjà tous les TM (nécessaire pour le mutienv)

Donc si seulement un Materiau d'un autre environnement se charge c'est une bonne solution pour limiter les textures custom et donc la taille du titre. Si tout l'environnement se charge il vaut mieux ne pas utiliser cette possibilité car les performances du moteur risque d'être dégradées.

Je pensais éventuellement utiliser cette possibilité pour disposer de textures techniques supplémentaires comme le béton, le métal ou encore pour faire des "Road Dirt" basées sur Valley dans Canyon (sachant qu'effectivement ces textures seraient uniquement celles d'origine et non un mod).

Bon, je crois que la sagesse est de ne pas trop s'engouffrer la dedans avant d'être certain que tout l'environnement n'est pas chargé...

[franck70]

Quelles sont les differences entre importer en Dyna ou en Static , je veux dire pourquoi ne pas importer tout en dynamique par exemple(vu que d'apres ce que j'ai compris le dyna a un avantage de plus :le mouvement)

J’espère que j'ai pas dis trop de conneries lol

[Fix]

static : inclus dans le décors (quasi équivalent aux blocs), fait partie du calcul des lightmaps (reçoit et émet des ombres, etc...)
dyna : comme cet objet peut bouger, son rendu est plus simple et différent de celui des blocs.

[TitiShu]

Et impossible d'avoir de collision avec un dynamic si je me trompe pas... (dommage d'ailleurs)

Et on ne peut pas charger une map si les objets ne sont plus la.
Faudrait pouvoir marquer des objets comme "obsolete" et qu'ils n'apparaissent plus dans l'editeur...
Aujourd'hui on peut pas, on va voir si on le rajoute.

Permettre de charger une map sans item serait peut être plus facile...
dans le cas où on changerait les collections ou tout simplement une refonte total des objets/item (ce que je pense faire pour speedball et obstacle, hehe) pas mal de maps risquent d'être "cassées"

Cette fonction serait vraiment utile, c'est quand même embêtant de perdre le terraforming, les block les mt etc... alors qu'il n'y a que les objets qui "cassent" la map

[meuh21]

C'est vrai que ça serait bien mais ça ne paraît pas si simple et il y a surement aussi des effets pervers.

je vais bricoler quelque chose en faisant des icones grisés pour que ces objets ne soient plus utilisés dans les nouvelles maps, éventuellement en les remplaçant aussi par des formes basiques pour encourager les mappeurs à modifié leur maps ou à mettre des textures blanches pour arriver au même objectif (tout en supprimant des textures pour alléger le titre).

Après réflexion, je pense m'en sortir en changeant les icones (en espérant arriver à faire fonctionner une ancienne version de l'importer) et en virant les textures. L'effet "arc en ciel" devrait encourager le mappeur à refaire sa map

Si tu as fait toi-même les objets, tu peux aussi les remplacer par un simple cube histoire de gagner un peu de place dans le titre et afin de pouvoir reprendre les maps.

[TitiShu]

C'est une solution mais c'est plutôt encombrant/polluant dans l’éditeur même si il y a moyen de les mettre sur les dernières page en jouant avec le noms des futur objets ( a moins qu'on puissent tous les mettre dans le même dossier jamais essayer de changer l'arborescence des objets)