Contexte
Apres session 63, les textures etaient reconnaissables dans l’atlas mais :
1. Pas de couleur (tout gris/noir)
2. Le layout « interleaved 4-chunky » etait en fait une mauvaise hypothese
Diagnostic via TextureLayoutExplorer
Un outil de diagnostic a ete developpe pour tester 8 hypotheses de layout.
La variante ASMstrict_U_row_V_col etait la plus propre :
byte_ofs = bankBase + U*1024 + V*4
avec U = row (0..63), V = col (0..255)
Ceci donne 256 colonnes x 64 rows par banque (pas 1024 comme pense).
Les 2 banques font donc 512 colonnes utiles au total, 128 KB.
Le layout s’explique directement par l’ASM move.b (a0, d0.w*4), d3
avec d0 = (U_int << 8) | V_int : d0*4 = U*1024 + V*4 = byte offset
dans le buffer avec U=row et V=col.
Les 3 bytes apres chaque pixel (offsets +1, +2, +3) sont probablement
des shades pre-calcules pour accelerer le rendu ; ignores pour l’atlas PNG.
Probleme palette resolu
Le fichier 256pal etait absent de ab3d2-tkg-jme/src/main/resources/
mais present dans le projet frere ab3d2-tkg-java/src/main/resources/.
Fichier copie dans ab3d2-tkg-jme/src/main/resources/256pal. Format :
– 1536 bytes = 256 * 6 bytes
– Layout : [R:word, G:word, B:word] big-endian
– Valeur effective dans le LOW byte de chaque WORD
– Contient 42 gris de luminosite + 214 couleurs vives (rouge pur, vert, bleu…)
TextureMapConverter.loadGlobalPalette() cherche maintenant dans :
1. Le dossier passe en parametre (src/main/resources typiquement)
2. ../ab3d2-tkg-java/src/main/resources/ (projet frere)
3. Workspace NetBeansProjects si trouve
Corrections appliquees
TextureMapConverter.java : reecrit en entier.
– Constantes mises a jour : BANK_ROWS=64, BANK_COLS=256, ROW_STRIDE=1024, COL_STRIDE=4
– COL_HEIGHT=64 et NUM_COLS=256 (etait 1024, d’ou les erreurs de normalisation UV)
– renderBank() fait pixel(row=U, col=V) = texData[bankBase + U*1024 + V*4]
– texOffsetToColumn() retourne colStart = (relOfs % 1024) / 4 (0..255)
– texOffsetToRowStart() retourne rowStart = relOfs / 1024 (0..63)
– sampleColor() mis a jour pour le nouveau layout
– Recherche de palette dans plusieurs emplacements (dont projet frere)
– Atlas final : 256×128 PNG (au lieu de 1024×128)
VectObjConverter.java : generation UV simplifiee.
// AVANT (session 63) :
int colFinal = baseCol + vtxU[v] * 16; // U => col, facteur *16 a cause du layout interleaved
int rowFinal = rowStart + vtxV[v]; // V => row
// APRES (session 64, layout ASM-strict) :
int colFinal = colStart + vtxV[v]; // V vertex = delta col (1 unite = 1 pixel)
int rowFinal = rowStart + vtxU[v]; // U vertex = delta row (1 unite = 1 pixel)
Plus de facteur *16, plus de decalage par bandes, plus de confusion
sur quelle est l’axe row vs col.
Pipeline
./gradlew convertTextureMaps # regenere l'atlas 256x128 avec couleurs
./gradlew convertVectObj # regenere les .j3o avec les bons UV
./gradlew run
Verification attendue
assets/Textures/vectobj/texturemaps_atlas.png= 256×128, avec couleurs- Preview zoome visible dans
texturemaps_preview.png - Les modeles .j3o (passkey, blaster, …) affichent leurs vraies textures
Statut final session 64
✅ VALIDE : atlas genere avec couleurs vives, mapping UV correct sur
la majorite des modeles. Residuel : certains modeles (ex: Mantis) ou parties
specifiques utilisent une texture qui n’est pas correctement mappee. A
diagnostiquer en session 65.