Questions diverses de mapping

[/!\ LES INSCRIPTIONS AU FORUM FONCTIONNENT A NOUVEAU, VOUS POUVEZ RECREER VOTRE COMPTE EN TOUTE SERENITE /!\]

[Le Débilarium :]

[Polaris]

Bon alors, tu as ta map en elle-même: tes bâtiments, tes control points etc etc.

Ensuite, technique de DÉBUTANT (si jamais tu te met à faire du vrai mapping, tu ne devra pas utiliser cette technique): tu fais un cube qui englobe ta map et tu utilises le hollow pour le creuser. Ta map est donc dans le cube. Sur la face intérieur du cube, il faut utiliser la texture tools/skybox, et sur toutes les faces extérieur, la texture tools/nodraw.

C'est bien comme ça que c'est chez toi?

[ZoomBox]

Comment ça au dessus de la map ? La structure de cette dernière est très simple : un grand pavé évidé. J'ai logiquement mis les textures du ciel sur la face supérieure (mais tout de même à l'intérieur) du pavé. Comme si c'était le plafond. Ce n'est pas ainsi qu'il faut procéder ? Faut-il mettre une texture transparente au plafond, et derrière (enfin, au dessus) mettre les skybox ?

Non c'est bien comme ça qu'il faut procéder [même si souvent on met le ciel plus haut pour les Stikies/rocket jump].
Pour ton problème de ciel qui recouvre apparemment tout ce qui n'est pas "enceinte" du la map [les gros mur autour], je n'y vois aucune raison, peut être une skybox invalide ! [regarde le nom de ta skybox] ou alors peut être que tu a texturé en "2d Skybox" plutôt qu'en "skybox" simple.

Essaies de faire plusieurs screen Hammer si ça n'a pas résolu ton problème.

Edit: Et au fait, un env_cubemap sert à faire les reflets sur une surface luisante [souvent les vitres mais aussi que les métaux comme metal/metalchrome002 ], sans ça, ces vitre et autre vont refléter un truc hideux par défaut: Un démié rose et noir, si tu en place un,  les reflet sur ces surfaces seront normaux. En fait ça agit comme un appareil photo qui prendrais dans toutes les directions à la fois. Ensuite avec ces photo afin de créer une image "lisse" et sans arrêtes il en fait une bulle et projette ces photo sur la vitre: On a l'impression d'un reflet alors que ce ne sont que des photo prisent au préalable [d'ou l'intérêt de bien le placer, si tu place ton env_cubemap dans une autre pièce la vitre concerné reflétera cet autre pièce et ça semblera étrange.
Bref: Si tu souhaite l'utiliser [ça t'arrivera un jour ou l'autre] tu le place à hauteur d'homme [tête] et dans les propriété tu "pick" la surface réfléchissante.

[Hunk]

C'est bien comme ça que c'est chez toi?

Absolument pas : j'avais lu que c'était fortement déconseillé.

La texture du ciel est : sky_dustbowl_01_hdrup. J'en conclu que c'est une texture utilisée sur dustbowl, et je n'y ait jamais vu de pareil bug. J'ai essayé avec pas mal d'autres textures de ciel, le résultat a toujours été le même.

peut être que tu a texturé en "2d Skybox" plutôt qu'en "skybox" simple.

Comment savoir si c'est le cas ? Mais je doute que ce soit le cas car même en testant la partie, et donc en dehors de Hammer, le ciel recouvrait le reste. Je prendrai plus de screens sous peu.

Merci pour les cubemap

Sinon j'ai, encore, une question : comment intégrer une porte coulissante, du genre que l'on voit à la sortie des resuply, par exemple ? Je ne trouve pas de model de porte. Je suis un peu pommé, il y a tellement d'entité que je ne suis pas près de trouver.

EDIT : pendant que j'y suis, où trouver des models de fenêtre ?

[ZoomBox]

Ah, OK je vois le gros problème: Tu as texturé ton ciel avec une texture portant le nom "sky_dustbowl_01_hdrup" !
Ce n'est pas ce qu'il faut faire !
Il faut texturé tout ce qui est ciel ou horizon avec une texture nommée "tools/toolsskybox" [c'est une texture bleu ciel avec écrit "skybox" réguliérement dessusn un peu comme le nodraw mais en diffèrent ].
C'est uniquement ensuite que tu pourras modifier le ciel en allant dans Map/map properties et dans le champ "skybox texture name" tu met un truc genre "sky_trainyard_01" ou celui que tu veux [relis le tuto du SDZ]..

Pour une porte c'est assez compliquer à faire, c'est expliqué sur le SDZ, tente déjà les portes coulissantes simple et si tu as envie de les faire comme dans TF² je [ou quelqu'un d'autre] t'expliquerais mais pour l'instant essaies déjà de faire un truc tout bête.

Les models de fenêtre c'est simple, tu va dans le browser et en filtre tu met "window", ça marche avec tout 'faut juste quelque base de vocabulaire anglais.

[Hunk]

Pfiou ! Merci beaucoup, je commençais à croire que mes fichiers étaient corrompus ou je ne sais quoi C'est parfait, ça marche au poil !

Pour une porte coulissante basique, faite à partir d'un bloc et non d'un model, j'y suis parvenu, mais pour faire une porte à la TF2... je suis perdu !

Encore merci pour ton aide

[ZoomBox]

Derien.
Donc maintenant pour la porte, il y a plusieur méthode, j'ai une préférence pour les 2 premières mais les 3 marchent:
1)Tu as ta porte coulissante banale et moche, à l'ancienne, et bien sache que tu est déjà proche de la fin
Spawn un volet de porte, tu lui donne un petit nom: Ici ce sera "petitnomdeporte".
Séléctionne ton func_door et dans le champ "parent" tu mets "petitnomdeporte": Ton prop est maintenant lié à la porte, ils se déplacent ensemble !
Textures ta porte coulissantes en Nodraw et fait la très fine, de l'épaisseur de ton prop voire plus fin.
"Autour" de tout ce bordel tu met un prop banal d'encradement de porte [les petit rail muraux avec le cylindre du volet].

2)Plus simple: Tu texture direct ta func_door en texture de volet de porte et tu bidouille un encadrement avec des blocs classiques ou tu t'en spawn un en prop.

3)Plutôt chiante:
En plus de ton func_door en nodraw et très fin, tu spawn un prop_dynamic de porte, un prop avec une animation d'ouverture et de fermeture et pas un simple volet inactif. Et là tu dois maitriser les Output ce qui est très chiant. Considérons que le nom de mon func_door est "door_red_cp2_5" et celui de ma porte en prop_dynamic est "door_red_cp2_5prop" [j'avoue, ça vient de me map en cours]. En output de ton trigger tu met tout ce bordel:
Et voilà ! En fait c'est une mécanique à chopper mais le plus chiant ça a été de trouver tout ça tout seul , l'autre truc chiant c'est que cette fois ton func_door et ton prop_dynamic sont "indépendant", car les output disent en gros:
Si un type est dans le trigger: Ouvrez le func_door
Si un type est dans le trigger: Enclenchez l'animation de la porte qui s'ouvre
Si le type quite le trigger: Fermez le func_door
Si le type quite le trigger: Enclenchez l'animation de la porte qui se ferme.
[en réalité sur le screen les 2 dernier et les 2 premier sont inversé, mais pour la compréhension c'est mieux comme ça].


Pour la plupart des portes, la méthode 3) ne sert à rien et est juste chiante à faire, mais certaine porte necessitent cette méthode, c'est le cas de la très stylé porte de Well: main_entrance_door.mdl [utilisé dans l'exemple sur le screen].

[Hunk]

Pfiou, je dois dire que j'ai du mal. Si j'ai bien compris :

Le trigger_multiple active le func_door, qui lui même active l'animation d'ouverture ou de fermeture du model ? Ne serait-il pas plus simple de se passer du func_door, histoire que le trigger active directement le model ?
De plus, je n'arrive pas à activer le model, si bien que je passe au travers qu'il soit ouvert ou fermé. En fait, le champ "with a parameter override of" reste vide, je n'ai ni de "open" ni de "close", juste un "none" déprimant

[ZoomBox]

PS: Pour résoudre ton problème, go direct dernière ligne, le reste c'est à titre d'information.

Là j'ai pas Hammer sous les yeux, mais fais bien attention à bien choisir un prop_dynamic de porte avec des animation !
Pour être sur, prend celui que j'ai utilisé.

Et tu as mal compris:
Le trigger_multiple active le func_door et en parallèle l'animation du prop.
C'est:
Trigger____> Open Func_door
           |__> SetAnimation: Open
Et pas:
Trigger____> Open Func_door___> SetAnimation: Open


Comme tu dis,  ce serait plus simple de faire juste l'anim du prop, d'ailleurs j'me suis posé la question en rédigeant ce "tuto", donc je ne suis plus sur de rien, mais ce qui est sur, c'est que c'est utile si ta porte n'est pas "solide", si elle est traversable même fermée [Si elle n'a pas de "collision"], et ça, ça arrive plutôt souvent; et ici, c'est le cas avec la porte de l'exemple.

Donc pour résumer:
Fais gaffe à prendre un bon model de porte ! Pour savoir si elle est "ouvrable" tu vas dans le model Browser et dans l'onglet "Sequence" de ton prop_dynamic tu regardes s'il y a autre chose que "idle" du genre "open" ou "close" dans notre cas.
Pour le champ <none>, c'est normal, en fait rien ne te sera jamais proposé, c'est bizarre mais c'est comme ça: Tu dois toi même taper open ou close et c'est peut être là ton problème principal !

[Hunk]

Ah d'accord, je n'avais même pas pensé à écrire moi-même "open" et "close" -_-' C'est sûrement le cause de mon problème, je vais tester ça demain.

c'est utile si ta porte n'est pas "solide", si elle est traversable même fermée [Si elle n'a pas de "collision"], et ça, ça arrive plutôt souvent; et ici, c'est le cas avec la porte de l'exemple.

Oui, effectivement, c'est d'ailleurs le cas avec la porte que j'avais choisis, je ne m'en suis rendu compte que tout à l'heure. D'ailleurs, je trouve ça assez étrange, ces props non-solide. J'ai intégré à ma map un prop_static représentant une "mini" grange et j'ai eu la mauvaise surprise de découvrir qu'on passait au travers. Dans ces cas là, est-on toujours forcé de créer des blocs nodraw (ou d'une autre texture) à encastrer dans les murs pour rendre le prop solide ?

[ZoomBox]

Oui, on est bien obligé de le faire [perso je met la texture "invisible" qui ne créé pas d'ombre et ne fonce pas les props] mais globalement on évite: S'ils n'on pas de CM [Collision Model] c'est souvent qu'ils n'en ont pas besoin [qu'ils sont destiné à être à l'extérieur de la carte inaccessible, ou en hauteur].
Je vois bien pour le cabanon de bois, ça m'étonne comme toi qu'il n'y est pas de CM mais bon ... Au pire tu fais ça en blocs normaux.

Par contre, maintenant qu'on y est: Travaille direct ton optimisation, aprend à placer un minimum de hint etc ... même si ta map sera surrement jeté d'ici pas longtemps [à moins que t'y mette vraiment du temps, c'est rare de garder sa première map], c'est un entrainement et n coup à prendre
PS: C'est horriblement chiant.

[Hunk]

Par contre, maintenant qu'on y est: Travaille direct ton optimisation, aprend à placer un minimum de hint etc ... même si ta map sera surrement jeté d'ici pas longtemps [à moins que t'y mette vraiment du temps, c'est rare de garder sa première map], c'est un entrainement et n coup à prendre
PS: C'est horriblement chiant.

Je ne sais absolument rien sur l'optimisation Je n'ai trouvé "que" ça : http://www.logout.fr/hammer/?p=optimisation , mais j'ai une flemme monstre de tout lire... j'aime pas le vert "à-la-steam" ! Enfin, va bien falloir que j'arrête de faire mon gamin et que je m'y colle

[ZoomBox]

Et si tu n'as trouvé "que" ce tuto, c'est bien parce qu'il est ENORME et c'est une vrai mine d'or !
Le plus complet en français [et peut être même plus complet que la plupart des tuto Anglais] et il est primordial de le lire pour mapper ...
Je sais que le site n'est pas très agréable à l'oeil et que le pavé ne donne pas envie mais les apparences sont trompeuse.
Perso j'ai préféré lire ça que le tuto de mapping du SDZ [même si ça n'a pas grand chose à voir]: Il n'y a globalement rien à faire et on maitrise déjà les plupart des outils dont il parle.
Pour commencer lis le I], c'est les méthode de "base" [même si ça semble déjà avancé comme technique, ça reste la base], le I] comprend un millié de petites astuces et de Nota Bene très utile et à retenir [ça rentre tout seul ]. Pour le reste du tuto, c'est bon à lire mais tu n'en retiendra pas grand chose, le truc c'est qu'en le lisant tu découvre les possibilité du moteur. Ex: Tu as une maison et même quand toutes les portes son fermé, ce qui est dehors est toujours calculé ! Comment faire ? Et bien en lisant le tuto tu peut voir qu'en utilisant les areaportals tu peux résoudre en partie ce problème. Alors que sans ayant lu le tuto tu te serais dit que c'est normal ou alors que t'as couillé quelque part.

bref: Lis le début, tout rentre facilement, le plus dur ça restera d'appliquer, surtout pour les Hints, c'est souvent ambigüe pour les novices. Perso j'ai 2 ans de mapping quasiment et j'en apprend encore.

EDIT: Au gros mappeur du site ou à ceux qui savent utiliser Google mieux que moi:
Je cherche à lisser une colonne faite en Brush: Ma colonne ne nécessite pas beaucoup de face et j'aimerais savoir s'il y a moyen que l'éclairage sur les faces soit plus lisse et plus uniforme, un peu comme ça fait sur les prop de pipe par exemple. Il me semble avoir déjà vu un tuto l'expliquant mais pas moyen de le retrouver.
Merci !

[Vangarou]

Pour une colonne j'utilise les displacements, comme c'est expliqué a la fin de la page.

http://www.siteduzero.com/tutoriel-3-6959-les-displacements.html

[Hunk]

J'ai lu les 3/4 du tutos et j'ai bien du mal à comprendre l'utilité des hints. Ca limite les calculs, si j'ai bien tout ingurgité, mais quant à leur utilisation... Par exemple, sur cette image là, à quoi servent-ils ?

Ou encore ici :


Je n'ai pas saisis non plus l'histoire de VIS qui calcule la visibilité à deux vis-leafs de distance.

Ils sont fous ces gens d'inventer des trucs aussi tordus, c'est une secte ?

Par contre, les fun_detail, c'est enregistré ! Et je vais tester la technique proposée pour aligner les textures.

[ZoomBox]

En fait, comme il le dis [il me semble] dans ton tuto, les deux haut de colonne [et pas Cologne !] devrait être des func_detail.

En fait il faut savoir que tout ce qui n'est pas func_detail découpe le monde en plein de "pièces" ! Il est très con et n'a aucune notion des proportion donc il ne sais jamais si c'est un "couloir" ou juste 2 excroissances etc...

Donc pour la première image, supposons qu'on les laisse en brush normale, le "cylindre" va découper le monde à partir de chacune de ses arrêtes comme s'il pouvait s'agir de "pièces" => En gros, le cylindre va engendrer un millier de découpe inutiles dans le monde et ça c'est lourd à calculer.
En l'englobant d'un bon hint carré, plus de soucis, si c'est bien fait les découpes n'auront pas lieu. Au lieu de découper 8 "pièces", le jeu va n'en couper que 4 => Englober une structure complexe qu'un cube de hint sert à stopper les coupure de la structure.
Même schéma pour les toits de maisons.

En TRÈS GROS:
http://www.weplug.com/images_1/04f098d8abd1f06adb03d1a281bc9d4220100323150959.jpg
A gauche ce que hammer fait instinctivement et à droite ce qu'il se passe avec un hint.
Là j'ai fait ça juste pour une maison et seulement sur un plan 2D , on a déjà quasi doublé le nombre de "pièce" inventé par hammer, de plus,Hammer ne va pas comprendre par défaut qu'en se situant en 1 on ne peut voir ce qu'il se passe en 2.

Regardes l'image du tuto avec les colonnes dans une pièces: Tous les traits vert sont les découpes qu'Hammer a fait du monde: C'est inutile et ça bouffe en ressource, avec un hint qui engloberais le piler on aurait déjà divisé le nombre de découpe par 3 ou 4 mais le pilier n'étant pas vraiment un gros élément pouvant caché la visibilité on l'aurait plutôt transformé en func_detail.

De manière général réserve les func_detail pour les petits objet [au sens propre].
=> Pour une map en intérieur, tout ce qui est gros mur sans trop de trou [porte, fenêtre etc...], plafond et sol.
=> Pour une map en extérieur, tout ce qui n'est pas mur extérieur de batiments globalement.

Pour bien, tu fais ton truc et quand t'as un doute tu file vérifier sur une map officielle [elles sont dans ton dossier "save" de Hammer normalement donc par défaut directement dans le dossier ou Hammer va piocher] ou tu demandes. Mais le mieux c'est encore de venir ici et d'expliquer en 1 ou 2 screen.


Edit: Et merci pour les colonne, je connaissais la technique mais j'avais oublié ce moyen. Je pense, malgrè tout que ça reste trop gourmand donc je vais plutôt appliquer une texture verticale.