DéZastreux, le coiffeur ?

Oui, c'est pour le moins bizarre, tu as vérifié le vertex painting ? à tout hasard ? Au pire envoit moi le nif avec les textures pour voir si Blender, lui trouve quelque chose d'anormal, sait on jamais

L'équipe qui bosse sur les modèles Bab avait eu le même problème à un moment il me semble et ils ont réussi à le résoudre... Par contre, je n'ai aucune idée de comment ils ont fait.

J'ai eu en aspect le même problème que toi, celà dis c'est peut-être pas la même ressource mais sait-on jamais !!

En fait c'est possible que ce soit dû à ta Normal Map, il suffit que tes UV soient sur une face normal et sur l'autre en fait tes UV sont à l'envers (comme si l'on faisait un 180° sur l'axe Z) de ce fait sous 3DS le rendu est correct, ta texture est parfaitement bouclé, mais InGame ça coince avec la gestion de la lumière sur ta Normal Map. C'est assez dur à expliquer, mais vas jeter un oeil sur ce topic sait-on jamais :

https://wteamoblivionmod-for.forum2jeux.com/vous-avez-un-probleme-f82/sudoku-t1024.htm

Walzou a écrit:

En fait c'est possible que ce soit dû à ta Normal Map

Euh, non, pas à ma NormalMap, ça c'est sûr ,puisque quelle qu'elle soit, le problème persiste (voir screen ci-dessus).

Cela aurait pu être lié au sens des normals elles-mêmes (...Et non à leur bumpmapping appellé "normalmap" mais n'ayant en fait aucun rapport avec le "sens" lui-même des normals... )

Cela pourrait aussi être lié à l'UVmap et au mirroring de celui-ci, même si dans le cas présent, il y a, je crois, une différence fondamentale avec le problème que toi tu as recontré...

*******************************

En effet, si dans le sujet que tu linkes ( ...Jolie architecture : Bravo, ça promets d'être sympa ! ) ...Ton meshe bénéficie d'un UVmap en mirroring, comme le mien ici pour le torse, dans ton cas, le problème survenait à partir du pli du mirroring ( autrement dit à partir de la ligne de jonction entre les deux parties mirrorée )

>>> En gros, tes normals étaient retournées ("flip") sur l'une des deux moitiés mirrorées seulement, et pas sur l'autre.

NOTE : Ceci a des chances d'être dû à certaines manipulations avec 3ds totalement indépendantes de l'UV lui-même, telles que l'usage des fonctions "attach", "detach" et du "vertex-welding" ]

En effet, lorsque certaines de ces fonctions se succèdent ( détacher un morcea ude meshe, le rattacher ailleurs et le souder par exemple ) il se peut que le sens des normals d'un morceau de meshe soit alors inversé lors de l'opération...

Le pire, c'est que ça ne se voit alors pas immédiatement sous 3ds ( mais + tard dans Nifskope ou inGame )
Et ça, parfois à cause de la vision par transparence des faces ET parfois à cause, aussi, de ce qui semble être un bug de rafraichissement...

Pour être sûr qu'on n'est pas victime de ce phénomène, après ce type d'opération , il peut être utile de faire un "Reset Xform" sur le résultat...
Ensuite, pour être bien sûr, il faut alors sélectionner toutes les faces du meshe : S'il y a un problème, on voit alors qu'elles sont "pour moitié" en rouge sombre et non en rouge vif comme elles devraient toutes l'être si le sens des normal avait été correctement conservé lors des opérations précédentes...

>>> Il peut aussi y avoir d'autres occasions ( clonages, symétries, etc... ) de se retrouver avec des normal inversées sans aucune vraie bonne raison, ni, surtout, sans que ça ait le moindre rapport avec le mirroring d'un UVmap ( ...Normalement, le mirroring dans un UVmap n'affecte pas le sens des normals sur le meshe : ça crée juste un reflet inversé de la texture elle-même à la surface du meshe ! )

Au final, ne pas me demander pourquoi ça fait ça, ni pourquoi le Xform le révèle dans ce cas là alors que sinon on voit toujours un meshe correct sans ça dans le preview
...Parce qu'autant ça m'est déjà arrivé plein de fois, alors que je ne le voulais pas, donc, autant je n'arrive pas à reproduire ce phénomène quand j'essaye volontairement pour comprendre à quoi il est dû !!!

>>> Pour régler ce problème, il "suffit" de sélectionner les faces indûement inversées ( rouge sombre ) et dans "Editable Meshe > Face" cliquer sur "Surface > Normals > Flip"
Le bouton "Surface > Normals > Unify" peut aussi fonctionner dans certains cas mais en général, au lieu de vraiment unifier ça mets un boxon pas possible... :/

*******************************

Enfin bref, dans mon cas, si j'avais eu le même problème que toi, j'aurais une moitié du torse inversée et pas l'autre, et la jonction séparatrice des deux serait une ligne verticale passant entre les deux seins ( et non le long des bras comme ici )

Ici, les deux bras sont affichés pareil et ont le même problème de couture apparente, mais pas au niveau de la césure en mirroring, plutôt au niveau de la frontière extérieure de raccordement de l'UVmap ( les lignes vertes appellées "Map Seam" dans le unwrapUVW de 3ds )

Petit info, avec la texture bleue unie, même dans 3ds je vois en fait bien cette fichue démarcation, comme inGame (???)
J'ai vérifié le sens des normal à tout hasard quand même mais ce n'est pas ça.
J'ai essayé sans le moindre smoothing groups ou en ne smoothant que les polys autour de la démarcation elle-même, mais rien à faire, la ligne reste là... :/

Mohawk a écrit:

Au pire envoit moi le nif avec les textures

Je vais encore procéder à quelques essais cette nuit, là, et si je ne trouve toujours rien, je t'enverrai ça demain soir, des fois que tu aies l'opportunité par la suite de trouver un peu de temps pour y jeter un oeil : Merci bien, Mohawk !

P.S. Sinon, même si je trouve, de toute façon, je mettrai vite en ligne la mise à jour de l'archive custom qui contenait les cheveux avec les corrections apportées le mois dernier et ces ajouts là.

Meseira a écrit:

L'équipe qui bosse sur les modèles Bab

Oui Ce serait chouette si je pouvais les contacter alors !
Tu aurais pas un petit lien par là qui traînerait, des fois, s'il te plais, Meseira ?
( C'est pas que j'ai la flegme de sur Google mais j'ai peur de ne pas m'adresser à la bonne personne... ! )

*******************************

En tout cas , à vous tous pour vos réponses rapides et votre gentillesse,

++

Edit : Râââââhhhh ! ...ça y est, j'ai trouvé !!!!


Bon, intuition en passant comme ça, je viens de faire un bête "Weld"à 0,1 sur les sommets de mon meshe, et la ligne a disparu (!)
En fait, le meshe n'était pas "fermé", c'était "juste" ça... !
Chose étrange parce que je n'ai pas fait de "detach" ni quelqu'autre processus pour diviser les sommets, couper les arrêtes, ou quoi que ce soit d'autre sur le meshe de EyeCandy ( j'ai juste bougé des sommets et changé l'UV )

...En plus, cette "découpe 3D" n'est pas sur le meshe d'origine, et a visiblement été "opérée" "automatiquement" ( Mais pourquoi ??? ) le long de MON propre UVmap trés différent, évidemment de celui de EyeCandy...



Donc, de façon plutôt étrange (?), 3ds a opéré cette "ouverture" du meshe, chirurgicalement, en suivant le "Map Seam" de mon UVmap.

Lorsqu'on opère des "break" sur l'UVmap, ça n'est pas censé faire un "break" sur les sommets du meshe lui-même, si ???

Ce serait pas trés logique !
...A moins que ce soit une option en plus que j'aurais de coché par là, ou que j'ai appuyé par erreur sur un raccourci clavier qui fait ça...
Mais sinon, lorsque je fais un "Weld" sur les sommets de mon UV, ça ne soude pas les sommets du meshe lui-même, hein, alors pourquoi un "break" les diviserait ???

Bon, ben je vais vérifier ça quand même, juste au cas où, parce que là je suis un peu dégôuté du temps que j'ai passé pour rien à chercher là où il falait pas alors qu'en un clic c'était réglé...!!!

...Et... Je vais enfin pouvoir enchainer sur la suite, le visage, puis les scripts d'habillement automatiques, puisque le problème semble enfin résolu !

dZastreux a écrit:

Lorsqu'on opère des "break" sur l'UVmap, ça n'est pas censé faire un "break" sur les sommets du meshe lui-même, si ???

Super Par contre je ne risquai pas de penser à ce problème n'ayant jamais rien rencontré ne serait-ce que d'approchant. De fait avec Blender, (et logiquement avec 3DS ça devrait être de même) il n'y a absolument aucun lien entre la manipulation des UV et le meshe en lui-même ... quoique en y réfléchissant il y a je crois une option à la noix qui m'a toujours intriguée et que je n'ai jamais utilisé mais qui pourrais peut être ressembler à un truc dans ce genre.

Le principal étant que tu ais solutionné ton problème de couture, même si c'est vrai que c'est parfois rageant de s'apercevoir que l'on a perdu un temps pas possible pour un détail à la con, mais lorsque l'on a trouvé c'est toujours le même soucis

Mohawk a écrit:

Le principal étant que tu ais solutionné ton problème de couture

Yep, c'est bien solutionné, merci Mohawk :
Ai encore un peu à affiner par ci par là mes bords de textures et mes UV que j'ai 1000 fois déformé au passage à la recherche de l'erreur, mais le + vilain venait de ça et je commence à aller vite pour le reste à force de le faire et de le refaire !

Mohawk a écrit:

quoique en y réfléchissant il y a je crois une option à la noix

Oui, ma main à coupé que c'est bien lié, contre toute "logique" et que j'ai dû activé par erreur une telle option.

A ce sujet, j'aimerais revenir sur quelque-chose que j'ai dit plus haut et qui concerne peut-être Walzou :

L'abruti de service a écrit:

...Normalement, le mirroring dans un UVmap n'affecte pas le sens des normals sur le meshe : ça crée juste un reflet inversé de la texture elle-même à la surface du meshe !

En y réfléchissant...

Bon, attention, ce que j'ai écrit à propos des fonctions attach/detach et du vertex-welding reste une cause possible de l'inversion des normals, hein !

Mais, compte tenu de ce que je viens de comprendre, il semble probable, du coup, que ça puisse venir aussi d'une erreur de manip dans les UVmap.

En effet, maintenant que j'y pense, lorsqu'on fait un mirroring d'un UVmap, il faut peut-être bien faire attention à bien choisir "MIRROR" et pas "FLIP"...

En effet, sur l'éditeur de l'UV, ça ne semble faire aucune différence, mais en réalité, ma main à coupé que ça doit inverser les normals !!!

Sur ce, j'y retourne, parce que bon, si je passe également un mois sur la version "Mâle impérial", et encore la même chose pour "Femelle Elfe Noire", etc... J'ai pas fini avant Noël prochain :/ !!!

++

Je voulais souligner aujourd'hui une petite avancée dans les travaux, puisqu'avec un corps entièrement retexturé ( et presqu'entièrement remodélisé ) j'ai presque terminé le premier set [Meshes+Textures] qui servira de template aux suivants dans le cadre du "remake des races"...


-----------------------------------------------------------------------------------
Concrètement, avant de passer aux scripts d'habillage-automatique-des-corps dont on a parlé dans l'autre sujet ( linké ici un peu + haut ) il me resterait à :


1> Voir comment créer de nouvelles textures de "vieillissement" avec des résolutions concordant d'avantage avec la nouvelle texture du visage ( 2048x2048 en taille max ! )

2> Regarder dans les .egt pour voir si le problème de bleuissement excessif pourrait pas y être un peu tempéré et pour voir dans quelle mesure améliorer le système, là encore en concordance avec la définition des nouvelles textures.

3> Trouver qq infos sur la possibilité de recréer un .EGM pour le head.nif car jusqu'ici, j'utilise le meshe d'origine du jeu, avec juste la texture et son UVmap modifiés...
( C'était nécessaire car la texture est tirée de bidouillages sur le logiciel POSER à partir d'un meshe différent )
Le fait de savoir faire un nouvel .EGM pour la tête permettrait justement de pouvoir envisager de tout nouveaux meshes pour ces dernières, autres que de simple variations, par déplacements des seuls sommets existants, des quelques races existantes....
Cela dit, dans l'immédiat, pour les races actuelles, les meshes d'origine, quitte à les sculpter un peu restent largement à la hauteur...

En fait, dans les 3 cas, ce n'est pas "absolument" nécessaire dans l'immédiat :
Le vieillissement standard donne un résultat correct avec la nouvelle texture du visage, le bleuissement est certes pas terrible, mais on peut l'éviter le plus souvent en changeant le teint, et les nouvelles races ne sont pas une urgence pour moi.
Bref, disons que dans l'idéal avant de passer aux scripts, faire un début d'enquête permettrait déjà de réfléchir plus posément à la suite...


-----------------------------------------------------------------------------------

Avant d'y retourner, je voulais prendre le temps de cette visite pour consigner ici une petite astuce...
Comme je l'ai fait + haut pour le modus operandi sous 3ds pour les coupes de cheveux, je voulais en effet faire un petit compte rendu des difficultés techniques ( avec 3ds + Nifskope ) des modifications d'un head.nif relié à un .egt...
Un de ces 4, avec un peu de temps et de chance, ça permettra peut-être de faire un petit tuto détaillé de A à Z sur la customisation des races...
C'est parti...

-----------------------------------------------------------------------------------
Une tête à la hauteur * !

* Jeu de mot :
En effet, pour ceux qui ont vu les screens plus haut datant de l'époque où seul le corps avait été retexturé mais pas encore la tête, la tête n'était pas "à la hauteur" question texture...
Or, l'objet de ce tuto est de permettre de modifier le meshe de la tête ( Seulement pour changer le Uvmap ou bouger quelques sommets avant de ré-exporter, hein : Pour de + amples modifs on verra + tard ! ) SANS que celle-ci ne finisse entre les pieds du PNJ ou au contraire 1m50 au dessus du cou... ( Vous pigez le jeu de mot ou je recommence mon explication ? )

Oui, donc, parce que le soucis technique pour lequel j'ai trouvé une astuce que je vais vous "dévoiler" est bien celui-ci :
Lorsqu'on ré-exporte un head.nif avec 3dStudio, et ce quelles que soient les options d'export du plugin, la tête n'est ensuite plus DU TOUT à la bonne hauteur et il devient donc dur de la garder sur les épaules ( autre jeu de mot - que je n'expliquerai pas ce coup-ci- du bout en train que je suis ! )

En fait, il existe deux cas de figures :

----------------------------------------------------------------
1> Vous exportez votre tête en .NIF directement depuis le plugin 1.16 de 3Dstudio.

Pas bien du tout : En effet, comme vous devriez le savoir si vous aviez lu mon tuto + haut sur les coupes de cheveux, l'exportation par le plugin NIF de 3ds est foireuse quant à l'ordre (et même parfois le nombre) des sommets du meshe.
Du coup, étant donné que ces meshes trés spéciaux utilisent des morphings dont chaque sommet corresponds trés précisémment à un autre, ça fait de groooooosssses erreurs ensuite !

Mais comme vous n'y avez pas fait gaffe e tque vous aimez l'aventure, vous avez tenté quand même...
...Or, là, surprise, pas de déformation débile à première vue comme pour les coupes de cheveux ( Quel morphing ont-ils stockés dans le head.egm ? ! Suspense, je cherche encore... )
Par contre, pas de bol, si la tête a l'air bien placée dans l'éditeur de visage, une fois en jeu, elle se trouve littéralement entre les pieds des PNJ ( et du joueur ) ce qui a certes un effet comique indiscutable ( réservé aux moddeurs fous qui ne prennent pas de screens de leurs essais foireux et débiles si possible ) mais qui ne fait pas beaucoup avancer les choses...

----------------------------------------------------------------
2> Vous exportez votre tête en .3ds et vous importez ça dans votre NiTriShape via NifSkope ( astuce pour les coupes de cheveux vue + haut )

Bon, c'est bien, vous êtes prudent... Du coup, je suis pas bien sûr dans le cas présent de pourquoi vous avez bien fait, mais j'ai une forte intuitio nde ces choses là, croyez moi, vous ne le regretterez pas !


...Sauf que voilà, une fois en jeu, vous levèrez alors les yeux pour vous apercevoir que votre tête vous dévisage environ 1m50 trop haut au-dessus de votre corps. Et lorsque vous déciderez que c'est assez comique pour rigoler un coup, vous aurez un peu l'impression, quand même, qu'elle se moque de vous...
----------------------------------------------------------------

Explication du phénomène :

Si on regarde attentivement le headhuman.nif d'origine avec Nifskope, en faisant un clic droit sur le NiTriShape , puis "Transform", on s'aperçoit qu'il y a de stocké une translation de (env.) Y=-1 et de Z=+112

Or, dans le procédès 1 ( export direct en NIF depuis le plugin 1.16 de 3dstudio ) , cette transformation n'est pas repércutée à l'export ( quelles que soient les options d'export, j'insiste - ce n'est pas dû à un "collapse transform" coché par erreur - ! )
Du coup, la tête est entre les pieds, ET, si vous avez la mauvaise idée de faire le transform APRES, à cause du skinning et d'une malédiction divine poussée, ça crée un autre résultat étrange que celui que vous voudriez.

De même, dans le procédès 2 ( passage par un .3ds importé via Nifskope ) , on observe une erreur de ce côté là :
La transformation est bien là, mais non pas dans le NiTrishape, directement dans les coordonnées de chaque sommet...
Du coup, lorsque vous importez votre .3ds dans le nitriShape initial, les z=+112 s'ajoutent deux fois au lieu d'une, et en jeu, la tête est loin au-dessus des corps...
Et là aussi, malgré une réinitialisation du transform à "zéro" ( après coup ), ça ne donne pas le résultat escompté et on a droit à d'autres erreurs de skinning.

Vous n'avez pas tout compris : Tout ça vous fait tourner la tête ?
Vous n'avez pas la tête à ça ?
Bon ok, ne faites pas la tête , la solution arrive, et même si vous avez rien pigé, comme je vais vous la décrire pas-à-pas, z'aurez qu'à suivre sans réfléchir à tout ça, si ça vous chante...

PAS-A-PAS pour un bon TÊTE-à-TÊTE :

1>

2> importez votre headhuman.nif (ou autre head.nif) dans 3dStudio.

3> modifiez-le, mais, attention, à moins de bien maitriser les .EGM du jeu, vous ne DEVEZ pas modifier le nombre de sommets, ni même en suprimer un et le recréer derrière !!!
Vous pouvez donc, concrètement :
Bouger les sommets dans l'espace et modifier le UVmap (coordonnées de la texture sur le meshe)
Vous ne devez surtout pas :
Rajouter/supprimer des sommets/arrêtes/faces par quelque procédès que ce soit ( pas de vertex-welding, pas de smoothing, etc... )
...OU BIEN vous aurez certainement tout un tas de problèmes avec les ..EGM et .EGT après... ça reste votre droit si vous vous sentez l'âme d'un aventurier...

4> exportez le résultat en .3ds

5> ouvrez le head.nif d'origine du jeu avec Nifskope, faites un clic gauche sur le NiTriShape, puis FILE > IMPORT .3DS
...Choisissez votre .3ds, OK

6> Désormais, dans le NiTriShapeData, les coordonnées des sommets contiennent déjà les modifs du transform ET dans le même temps, le TRANSFORM du NiTriShape est toujours à Y-1 Z+112
Faites un clic droit sur NiTriShape , puis "Transform > EDIT"
Là, inversez les signes ( c-à-d mettez -112 au lieu de +112 pour Z, et +1 au lieu de -1 pour Y ) Puis "OK"
Enfin, refaites un clic droit sur NiTriShape et là :
"Transform > APPLY"

7> Sauvegardez ce NIF là sous un autre nom ( "monData.nif", par exemple ) et fermez Nifskope

8> Ré-ouvrez le head.nif d'origine du jeu avec Nifskope.
Clic droit sur son NiTriShapeData > Block > Remove Branch

9> Ouvrez en parallèlle ( dans une autre fenêtre ) votre "monData.nif" et là, clic droit sur son propre NiTriShapeData ( ATTENTION, dans les deux cas, c'est bien le NiTriShapeData dans le NiTriShape pas le NiTriShape lui-même !!! )
Et ce coup-ci :
"Block > Copy Branch"

10> Dans la fenêtre du head.nif , clic droit sur le NiTriShape lui-même et :
"Block > Paste Branch"

11> Comme Nifskope (la version 1.03 actuelle) est encore un peu bête, au lieu de coller le nouveau NiTriShapeData directement dans NiTriShape, il va le mettre en vrac dans le NiNode principal...

Pas grave : Vous cliquez sur le NiTriShape et dans le "Block Détails" de votre Nifskope, il y a alors une ligne intitulée "Data" :
Double-cliquez en face et rentrez le numéro du NiTriShapeData que vous venez de coller...

...ça y est !!!
Sauvez votre NIf ; il est opérationnel et la tête sera à la bonne place !


http://0zForum.oblivion-z.fr/Screens/worksInProgress/0zSkinImpFemE.jpg

Superbe la texture du visage

Pour ton egm, envoit moi l'une de tes têtes au format .obj je devrai pouvoir faire quelques choses pour toi, maintenant que mon master est en cours d'upload

Merci Mohawk

En fait, de procéder ainsi ( texture pour visage féminin ET autre texture pour visage masculin, comme dans "ce bon vieux Ren's" ) offre l'avantage d'avoir des textures vraiment mieux adaptées au sexe MAIS en revanche, ça oblige à créer 2 races distinctes ( impérial ET impérialE )...

Du coup, c'est trés bien pour les PNj rajoutés ( ou le joueur ) mais évidemment, pour les PNJ d'origine ou d'autres mods totalement indépendants, c'est raté, quoi !!!

Cela dit, c'est pas bien grave non plus puisqu'à la base ces travaux sont plus prévus pour des rajouts conjoints au module de ressource que pour autre chose...

De plus, je pourrais toujours essayer de faire une texture de sexe neutre ( comme celle du jeu d'origine donc ) pour les PNJ des races "habituelles" histoire qu'eux aussi soient "raccord" avec un corps high-res s'ils bénéficient du système d'habillage automatique par exemple via un plugin ESP optionnel , et ultérieur, dépendant de l'ESM...

Citation :

Pour ton egm, envoit moi l'une de tes têtes au format .obj

Pour le .EGM c'est surtout que je ne sais pas ce qu'il faut mettre dedans , en fait !
Du coup, je me pose la question pour réfléchir à de possibles races custom supplémentaires pour + tard.
Mais actuellement, je n'en ai pas vraiment besoin.
Les meshes par défaut de Poser surlesquels on peut créer des textures de peau ne sont pas forcément bcp mieux que ceux du EyeCandy pour Obli, question forme et ont peut-être un peu trop de polys, en + ...

Enfin bref, pour les races que l'on a déjà, je peux continuer avec les meshes d'origine , quitte à bouger un peu les points de ci et de là en me basant sur un patron 3d tiré de Facegen par exemple...
Si de votre côté vous avez justement des visages tirés de facegen qui le feraient d'avantage que ceux du jeu, à la limite, je veux bien refaire mes UV une fois de plus mais sinon, ça attendra une race tout à fait nouvelle.
( Lycanthrope ? Zombi avec le crâne défoncé ? Nain ? Enfant ? ... )

Dans le cadre d'Archipel, j'imagine que vous en avez envisagé quelques-unes ?

Note : Message précédent effacé car plus vraiment d'actualité.
Je mettrai sous peu, ici, un lien vers un document qui récapitulera de façon + exhaustive les resources gratuites et légales, classifiées par catégories, m'ayant servi de base de travail pour différents texturages, modélisations 3D ou éditions sonores ces derniers mois, telles que les ressources d'ailleurs, utilisées ici pour ces travaux.
Comme en l'occurence ces dernières sont assez nombreuses, souvent que trés partiellement utilisées, et que peu mentionnent un souhait prévalent d'être créditées, seules les resources le posant explicitement comme condition seront indiquées dans le readme du projet.
Les autres seront mentionnés indépendemment dans le récapitulatif que j'évoquais ci-dessus : Non pas qu'ils aient été forcément moins utilisés, en fait, mais ce sera + simple comme ça pour ne pas saturer le readme parce qu'au fil des versions, tout a bcp été altéré.
----------------------------------------------------------------------

Pour en revenir à qq-chose d'un peu + et d'un peu - je voulais juste signaler en passant que je m'attaque sérieusement à l'étude des teintes pour les textures des corps ET des têtes.

En fait, les textures telles que sur les screens que vous avez vu jusqu'ici n'existent plus à proprement parler : Elles ont été pas mal remaniées - bien que le grain soit tjrs assez semblable - et j'ai vraiment revu à la baisse leurs dimensions...
C'était certes trés beau, mais ça restait largement excessif dans le cadre du jeu, puisque la différence n'était vraiment flagrante que si, dans la résolution d'écran max que propose Oblivion, on faisait un zoom trés trés sérré sur la peau : Or, c'est chose impossible inGame à moins utiliser la caméra libre précisemment pour ça...
Du coup, bon, l'art, c'est une chose, mais pour être pragmatique, avec des textures qui font quand même toujours + de 4 fois celles du jeu, c'est déjà largement assez beau pour changer la donne...
( J'ai viré la couche de specular sur les normalmap aussi, parce que franchement, avec ou sans, on voit pas la moindre différence... )

A partir de là, j'ai voulu faire des variations de teintes par race.
Alors que pour les Nordiques et le Bretons, globalement, on gardait la teinte blanche-rosâtre observée sur les précédents screens, j'ai essayé de faire des corps plus bronzés, plus dorés, pour les impériaux, par exemple.

J'ai d'abord essayé avec les seules valeurs des NiMaterial dans les .NIF ; sauf qu'en fait, pas possible de faire comme ça...
En effet, de deux choses l'une :
> Soit le material s'appelle "Skin" et quelles que soient ses valeurs ( Ambient, diffuse, etc... ) ça ne change rien une fois inGame...
Seule la tirette de SHOWRACEMENU permets alors d'altérer la teinte.
> Soit le material a un nom "lambda" , en auquel cas les variations de valeurs fonctionnent MAIS la tirette de changement de teint du SHOWRACEMENU ne fonctionne plus sur le corps...
( Sur la tête, par contre, visiblement, le jeu se moque éperduement du material et de son nom quoi qu'il arrive en fait... Et du coup d'ailleurs, il est impératif que les material du corps soient nommés "Skin" ou sinon il y a alors une grosse différence possible entre la teinte de la tête et celle du corps... )

Donc, j'ai essayé de modifier les textures elles-même ( ce qui est largement moins optimisé mais bon ) et le résultat, là encore, inGame n'est pas satisfaisant.
La blancheur anormale qu'on observe pour les Rougegardes lorsque la tirette est à fond s'observe encore plus vite sur un teint juste un peu "hâlé" comme celui que je voulais pour les impériaux.
Résultat des courses, à moins que la tirette ne soit à fond du bon côté, la différence entre la version "rose" de mes textures et la version "brune" est absolument indécelable.
Même lorsque la tirette est à fond du bon côté, ça reste beaucoup moins flagrant que lorsqu'on regarde les textures elles-mêmes, parce que sur la version hâlée que j'ai fait vient se superposer une texture du .EGT qui est moins hâlée que la mienne...

Bref, en gros, pour résumer, les textures contenues dans :
Data\meshes\characters\_male
body.egt
upperbodyhumanfemale.egt
upperbodyhumanmale.egt
Data\meshes\characters\imperial\
headhuman.egt
headhuman_50.egt
earshuman.egt
earshuman_50.egt

...Sont toutes trop claires !!! ( ...Et sur-saturées aussi, d'où le bleu excessif au bout "blafard" de la tirette, dont tu parlais, Mohawk... C'est toi qui avais raison. )
Je vais donc essayer de voir si je peux pas en faire une version retravaillée permettant d'obtenir des résultats nettement plus sombres et un poil plus ternes :
Même les rougegardes ont encore de la marge et pourraient facilement profiter d'être un peu plus sombres et un peu moins "rouges" qu'ils ne le sont déjà, je crois...
Je viens de récupérer le petit EGTUNPACKER de SCANTI et je me lance là-dessus cet après-midi !

A noter aussi au passage, puisqu'on en parlait dans les messages précédents, à propos des têtes customisées, j'ai trouvé ça :
http://www.oblation.eu/cgi-bin/yabb2/YaBB.pl?num=1191657299/6
Visiblement, dans ce sujet, l'auteur rajoute ses propres têtes custom et grâce à (encore ! ) un nouvel outil de Scanti :
http://www.oblation.eu/downloads/AddMorph.7z
...On peut même modifier les "morphs" des visages, ou en ajouter de nouveaux ( ...Pour les rajouts, par contre, dans Oblivion, je ne sais pas si on peut via les menus XML rajouter des tirettes pour eux... )
Ces Morphs sont contenus dans les .tri de headHuman par exemple et ça réponds à mes questions, puisque donc, après, on fait le .EGM à partir du NIF et du TRI.
Pour le moment, j'ai rien de prévu dans cette direction, mais visiblement, c'est possible donc... Reste à connaitre les noms des MORPHS utilisés par Oblivion pour créer un TRI fonctionnel...
Je pense qu'on doit pouvoir, au besoin, en obtenir une liste en demandant aux personnes en présence sur le sujet linké ci-dessus...

Je vous tien sau jus : ++ !

Note: L'image ci-dessous contient ( de gauche à droite, puis de haut en bas ) les 50 minitextures .TGA en 32x32 contenues dans le fichier Body.EGT
C'est affreux, hein ? On dirait qu'il n'y a pas de "logique" dans le dégradé des couleurs... Moi je m'attendais quand même à quelque-chose de plus ou moins foncé/clair ou rouge/bleu, de 0 à 50 mais non, c'est un vrai feu d'artifice de là !!!
Y a aussi un petit fichier texte en + lorsqu'on décompresse :

EgtPacker pour BODY.EGT a écrit:

Unknown: 91,142,89
Flags: intensity:2, enable:1, textno:7, maxed:0, invert:0
Unknown: 188,255,190
Flags: intensity:1, enable:1, textno:7, maxed:0, invert:0
Unknown: 106,135,72
Flags: intensity:1, enable:1, textno:7, maxed:0, invert:0

(...)

Si on regarde bien, le "Unknown" fait pas mal penser à une valeur RGB...
Et la dernière valeur aurait alors un BLUE à 255 ( donc au max )
Ce serait alors peut-être une combinaison entre le .TGA et un filtre de couleur ( je pige pas bien l'intérêt, et ça risque d'être tendu à retravailler ça !!! )
Si j'ai quelques screens de shtroumphs à vous faire après mes premiers essais de modifs cet aprêm, je vous montre ça, promis !

Très étrange ton truc, lorsque j'ai ouvert les egt, j'obtenai des truc totalement différents, ressemblant plus à des couches alpha bleutées que tes horreurs. Mais bizarrement je crois me souvenir avoir obtenu des fichiers en bmp et non en tga.

Si je me souviens bien de mes essais, il me semble que le soft de Scanti proposait 3 méthodes d'extractions, hors seule l'une d'elle permettait réellement d'obtenir quelque choses d'exploitables, les autres modes servant pour je ne sais plus quoi.

Pour tes problèmes de teintes sur la peau, je ne comprend pas d'où vient ton problème. Car de mon côté j'ai pas mal joué avec les textures et j'arrive sans problème à obtenir des rougegardes (c'est d'ailleurs valable pour les autres races également) de toutes les couleurs. En fait mon seul véritable problème provient de l'ajustement entre la teinte du visage et celle du corps. Et bien entendu cette cochonnerie de teinte bleuâtre. Mais comme j'ai bidouillé tellement de truc dans mes fichiers, il est plus que probable que j'utilise des fichiers egt et egm provenant de je ne sais plus où...

Si je m'y retrouve dans mon bordel, j'essayerai de te fournir les fichiers utilisés pour EC

Encore trop de difficultés à comprendre les plus grosses subilités des interactions entre tirettes de teinture visage/corps pour proposer quelque-chose de vraiment intéressant ou complet pour le moment quant à l'édition de .Egt customs, mais j'ai commencé à rédiger un petit rapport avec quelques infos pouvant peut-être déjà s'avérer un minimum utiles, ici :
http://0zForum.oblivion-z.fr/Tutos/3D/EGT/FR_OBLIVION_EGT_FILES.html

Je vous tiens au jus dès que j'ai quelque-chose de plus solide : @+

en tout cas c'est une bonne compil de pas mal d'infos

Mise à jour du document, ce 31/01/08 au matin :
http://0zForum.oblivion-z.fr/Tutos/3D/EGT/FR_OBLIVION_EGT_FILES.html
( ...Trés loin d'être terminé mais la m-à-j est conséquente )

...En gros, ai commencé à faire le détail du contenu de HeadHuman.egt puisque tellement de choses semblent lié à ce dernier ( même au niveau des coloris du corps !!! ) et a tester en jeu ce que donne l'altération de chaque fichier .Tga que l'on peut en extraire, indépendemment, un par un...

1° Résultats déjà dépeints pour les 10 premiers .Tga dans la m-à-j de ce matin et... ça fait peur !!!

En fait, je suis toujours à la recherche d'un lien "directement visible" entre les .Tga ( que ce soit sous leur forme m1 ou leur forme m2) et les tirettes qui leur semblent directement liées mais les effets constatés ne m'apportent aucune bonne corrrélations pour le moment...
Chaque tirette semble piocher ce qu'elle veut dans chaque .Tga et parfois le contenu pioché ne corresponds même pas à la dénomination de la tirette !!!

Tout ça, c'est pas la joie, mais c'est pas tout ...
Si je me base sur ce que dis Scanti, avec des .Tga extraits par m1, le noir "RGB(0,0,0)" serait un "no-mask" ( pas utilisé du tout par les tirettes )
Or, en fait, après test, certaines zones colorées ou blanche de certains .Tga ne sont utilisées par aucune tirette et certaines zones noires en revanche de certains .Tga sont bien utilisées...
( Je parle évidemment des zones noires visibles sur les .Tga m1 vu que sur les m2 il n'y en a pas à proprement parler... )

Bref, c'est assez cauchemardesque leur bazar pour le moment...!
-------------------------------------------------------------------------------------

Cela étant dit, sans s'attacher aux détails de trop près, ça reste pas trop difficile d'apporter de petites corrections ou de refaire à peu près un set custom sur le même modèle...
A propos de corrections, par exemple, je viens de faire un fix pour le headHuman.egt qui permets de modifier le rougegarde le plus bleu possible en un rougegarde disons... "trés livide"



"Evidemment", ça ne marche que sur la tête et il faudrait encore que je corrige les fichiers dans _male pour que ça soit bon pour le corps aussi...
Le hic, c'est qu'après, obligé aussi de refaire les .EGt des elfes et des autres pour que ça aille avec leur propre corps...
Or, les DarkElfes jouent aps mal sur le bleu, et du coup ça risque de les pénaliser un peu... ( A la limite, ce serait mieux de leur faire une texture un peu plus bleue à la base et basta, lol !!! )

Si ça t'intéresses, Mohawk, je fais ça et je te l'envoies, mais pour moi de toute façon, vu que le visage est une toute autre texture, il faudra que je me fasse des EGT complètement différents...
Et vu que toutes les races vont avoir leur set et bien bien personnalisé, là aussi faudra toutes que je les refasse...
Enfin bon, ça devrait aller, même si je ne pige pas exactement le détail des interactions entre les Tga et les tirettes, par mimétisme je peux créer les miens sans trop de problèmes désormais...

++

Pffiouu ...

ça commence à devenir vraiment très intéressant tes tests. Par contre une question idiote mais provenant de mes propres tests antédéluviens.

L'altération d'un tga quelconque a-t-elle la même incidence en fonction des sexes ?

Citation :

ça commence à devenir vraiment très intéressant tes tests

Merci. J'hésite par contre à poursuivre ma démarche de détail des interactions .Tga / tirettes dans mon docu...
C'est beaucoup de taff et, en plus, maintenant que je sais qu'il n'y a pas de liens vraiment "simples" ( excepté pour les premiers .Tga liés à des barettes bien précises ) mais au contraire des centaines de mini-interactions, je crois qu'il devient plus simple pour tout le monde de s'inspirer globalement du modèle de Bethesda que de vouloir faire le sien en se basant sur une logique exacte des contenus dans un tableau de 50 pages...

Par contre, quitte, donc, à s'inspirer des horreurs de Bethesda, autant partir, je pense, sur une base un peu désaturée, ici ou là, comme dans le fix ci-dessus pour les Cyans, que de toute manière, seuls les Dark Elfs utilisent vraiment à bon escient - et encore !
( Dans ce fix, j'ai aussi un peu désaturé les violets, réchauffé le tout avec un tout petit peu d'orange et empêché le + possible l'éclaircissement largement excessif qui donne des blancs neigeux totalement sur-réalistes )

Citation :

L'altération d'un tga quelconque a-t-elle la même incidence en fonction des sexes ?

Pour le moment, je ne peux pas te dire ça avec certitudes :
Je sais que les textures et les normalMap complémentaires liées à l'âge des acteurs ne sont pas les mêmes selon le sexe...
Ainsi, dans : Data\textures\characters\imperial
...Tu vas avoir pour les femmes:
headhumanfXX.dds
headhumanfXX_n.dds
...Tandis que pour les hommes, ce sera :
headhumanmXX.dds
headhumanmXX_n.dds
Du coup, comme ces masques en .Dds ont eux-même de légères colorations supplémentaires, différentes d'un sexe à l'autre, même si le sexe n'influe pas sur les masques .Tga, le résultat final par défaut peut pour le moment probablement différer un peu quand même...
Pour en être sûr, il faudrait refaire d'abord tous les .dds liés à l'âge...

( D'ailleurs, il me semble, à postériori, que certaines saturations s'observent peut-être plus du côté femme que du côté homme mais je n'en mettrais pas ma main à couper non plus )

Cela étant dit, pour ma part, je suis pour le moment tenté de croire que les mêmes .Egt n'ont pas une incidence différente selon le sexe... J'en suis d'autant plus convaincu que dans le dossier _male, on trouve un .Egt pour les upperbodymale et un autre pour les upperbodyfemale.
...ça semble bien indiquer que le jeu a bien groupé les autres sans faire de différences puisque leurs textures étaient globalement semblables.
Evidemment, ça ne prouve rien non plus, mais disons que ça réduit quand même trés nettement la probabilité que ce soit le cas...

Ici, le PNJ du screenshot ci-dessus est une vieille femme dont TOUTES les tirettes ont été placées à fond sur "Bleu/pâle".
Je pense que le fait de décocher "female" donnera un résultat masculin totalement identique.
Par contre, dans le cadre de mes textures customs, même le .Nif et les .Dds du visage, par race, seront différents selon le sexe.
A partir de là, puisque pour faire les .Tga je partirai de mon .dds d'origine, ce ne sera pas le même .Egt du visage selon le sexe.
Ce sera un poil plus de travail et aussi un poil + gourmand en jeu ( d'autant que les .Tga devront être un peu plus gros pour bien faire ) MAIS ça permettra par exemple d'avoir des visages féminins avec un maquillage un peu plus saturé que la version masculine, ou ce genre de choses... ( Les mecs un peu gothiques vont râler du coup... !!! )

Juste un petit UP pour continuer à tenir au jus...

J'ai essayé de compléter le fix ci-dessus avec une désaturation similaire des .Egt du dossier _male ( les .Egt pour les membres du corps, indépendemment de la race )
Les .Tga tirés de ces .Egt là semblent pour la plus part, un à un, avoir un profil colorimétrique identique à ceux tirés de headhuman.Egt :
Autrement dit, par exemple, lorsque HeadHuman22.Tga est trés violet, c'est aussi le cas de body22.Tga, par exemple...
Sauf que, malgré quelques bons résultats, je bute encore ( et toujours ! :/ ) sur de nouveaux soucis techniques :

1> Les similitudes entre head.egt et body.egt ne sont pas totalement systématiques...
Environ 10% des textures semblent étrangement "différentes" et ne pas concorder d'un Egt à l'autre... ( violet + vert par exemple... -!- )

2> Au-delà de vraies grosses différences de couleurs, de façon globale, les textures du body.egt sont bcp plus saturées que celles de head.egt pour une même couleur : J'ignore encore pourquoi, mais de toute évidence, une partie de cette sur-sutarution doit être conservée pour une adaptation correcte...

3> Après altération complète des body.egt dans "_male" pour obtenir quelque-chose de + uni entre head.egt et body.egt, j'ai quelques grosses différences de teint corps/têtes, probablement dûes justement à "2>".
Mais, surtout, bien pire, j'ai un drôle d'effet de luisance qui apparait parfois sur les corps ( comme un espèce de specular excessif... )
Il est assez probable que l'une des textures .Tga serve à ça mais à part en continuant les tests 1 par 1, impossible de savoir laquelle et si c'est la même pour la tête et le corps...


A la base, je me suis lancé dans ce fix pour les textures originales du jeu avec l'espoir de pouvoir proposer assez vite quelque-chose à ceux qui ont quelques problèmes de sur-saturation de leurs PNJ, comme le sur-bleu que tu évoquais...
...Mais là, tout comme pour le descriptif .Tga par .Tga, j'envisage de laisser tomber à cause de la trop grande compléxité de la chose, du manque sérieux de documentation, et donc du nombre effarant de tests nécessaires pour parvenir à un minimum de résultats !


...Attention, hein, pas non plus de "complètement" laisser tomber parce que de toute façon je voudrais vraiment parvenir à faire de bons .Egt pour mes propres textures ; mais vu le temps que ça demande au final en terme d'essais, j'aimerais autant à ne pas avoir à le faire 2 fois d'affilé : Une pour les vilaines textures de Bethesda et encore une pour les miennes.
Donc je pense laisser tomber la démarche pour les .Egt de base du jeu et ne plus m'occuper que des miens désormais et ce d'emblée de jeu.
( Suis quand même prêt à changer d'avis à tout moment en cas de demande ET d'infos supplémentaires sur les 3 pb que j'ai evoqué ci-dessus... )

Salut,
Juste un petit coucou pour tenir au courant puisque ça fait des lustres que je ne l'ai pas fait.
J'ai bien continué à bosser sur tout ça et ça commence à ressembler à quelque-chose. Actuellement, je bosse aussi en parallèle un peu sur le jeu Crysis histoire de découvrir un peu les nouveaux outils bâtis pour le modding chez VALVE et CryTek ( les outils relatifs à la 3d sont sensiblement les mêmes avec par exemple le fameux XSI )

Enfin bref, disons que question emploi du temps je suis assez sérré pour faire tout ce que je veux, mais, pour en revenir aux travaux décrits ici, d'ici à avoir un lien pour une nouvelle DEV-release, voici un petit compte-rendu vite fait de là où ça en est :

> .Egt pour les nouvelles textures féminines = OK
Soit 3X50=150 "nouvelles" textures basées sur les textures d'origine mais avec de très gros travaux de coloriage sur chaque, en gros. ( Environ 1heure de travail pour 1 seul .Tga : Faites le calcul !!! )
A noter que j'ai sensiblement conservé les saturations initiales des .Tga, en définitive ( et donc le bleuissement ne sera que trés faiblement corrigé et la couleur initiale de la peau sera toujours modifiable au-delà de ce que j'aurais voulu )
J'ai dû abandonné cette idée ( en tout cas pour le moment ) car il était trop difficile de doser un ratio colorimétrique corps/tête correct au regard des différences étranges de saturation entre les .Tga des .Egt respectivement pour corps et pour têtes.

> La 3d de la tête impériale féminine a été refaite ( sans changer le nombre de sommets ) afin d'adoucir les traits :
Plutôt qu'un seul meshe "neutre" pour les 2 sexes, et paramétrable ensuite, les femmes impériales ont désormais par défaut un visage se rapprochant de celui de ZetaJones ( Le faible nombre de sommets n'autorise pas non plus une ressemblance frappante, mais le résultat est indubitablement plus féminin )
Ce travail là devrait être étendu aux autres races humaines par sexes ( Ai prévu Jean Reno pour les Mâles impériaux, Kristianna_Loken pour Nordiques femmes, Liv_Tyler pour les Hauts-Elfes femmes, etc... )
Attention, hein, ne pas confondre : Il ne s'agit pas des réglages FaceGen par défaut selon la race qui sont modifiés mais bien le meshe lui-même d'entrée de jeu.
J'ai vérifié et ça permets certaines courbes du visage impossible sinon... Ce qui n'empêchera pas des réglages FaceGen customs par défaut et par race/sexe différents ensuite, mais ce n'est pas pour le moment ce qui a été fait.

> Les corps humains féminins refaits sont désormais des vêtements scriptés avec OBSE pour être équipés automatiquement ( PNJ ou joueur ) lorsque le slot se vide.
Autrement dit, dès qu'on enlève une armure, elle est remplacée par le morceau de corps qui va bien.
Le délai de remplacement est 99% du temps correct.
Il peut parfois y avoir l'ancien corps visible l'espace d'une demi-seconde.
En revanche, c'est l'ancien corps de Bethesda qui est forcément visible dans le ShowRaceMenu ( mais c'est bien la bonne nouvelle tête qui y apparait ) à moins qu'un autre mod changeant directement les races elles-même ne soit installé.

* Il existe actuellement un mod qui modifie les dossiers où le jeu doit aller chercher les ressources pour customiser l'apparence de la 3D du joueur. Ce mod est censé évoluer de façon à permettre la même chose pour les PNJ par la suite.
Actuellement, ce n'est pas le cas et il y a en + certaines contraintes supplémentaires qui rendent son installation / utilisation un peu trop embêtantes à mon gôut pour le moment ( tous les fichiers d'armures et de vêtements doivent être copiés en double dans le dossier redirigé même s'ils ne sont pas différents des originaux, etc... )
Ma version est nettement + simple et permets globalement le même résultat même, si, donc elle a quand même quelques petits défauts aussi. En gros, pour le moment, elle permets vraiment de + grandes libertés à un moindre côut.
Il est possible, toutefois, que le mod dont je parlais évolue de façon à devenir + intéressant que ce les quelques scripts très simples que j'ai écris pour le moment.
Si tel devait être le cas, je m'inspirerai alors de ses scripts pour corriger les miens de la façon la + efficace possible :
Pour le moment, je ne peux pas à la fois plancher sur la 3d et la 2d me restant à faire et sur une finition parfaite des scripts.
Toujours est-il que dès maintenant les corps s'équipent automatiquement par races ( joueur ou PNJ ) et que selon la faction ( "M_Gros", "M_Costaud", "F_PetitSeins", "F_GrosSeins", etc... ) c'est un corps qui est choisi à la place d'un autre.
( La 3d des corpulences différentes est encore entièrement à faire pour les hommes et seules les poitrines diffèrement pour le moment selon les femmes. )

Voilà, je reviens dès que j'ai un lien vers qq-chose d'à peine un peu + abouti : ++ !

Aspect physique géré en fonction de la faction du pnj ou pc fallait y penser , bien joué.