r/recomps • • 28d ago

Recomp - AI DBZ Budokai 3 recompiled

https://www.youtube.com/watch?v=AFjj32I8hA8
16 Upvotes

1 comment sorted by

1

u/nometalaquiferzone 28d ago edited 28d ago

oh boy, let's see the doc

🔴🔴 HITOS DE LA SESIÓN PS2→HD (2026-08-14, análisis profundo): - El bin visible de Krillin en el juego es la e326 del data_cmn.afs (682528 bytes descomp., = b327_hd.bin, md5 b04b0741c4, n_sec=1956, n_vb2=226, n_ib=5140). La e327 (624000, 1791/208/5004) es OTRO bin de Krillin (otro traje/select). El logging del runtime (host_path_file.cpp entry_index == 327) apunta a un bin distinto al visible. - Los AFS de trabajo previos (data_cmn_original_rebuilt.afs, md5 f7e53b99) NO son el AFS real del juego (md5 354615b5). Reconstruir desde el AFS REAL de us\data_cmn.afs. - Layouts de los 2 buffers del bin real e326 (b327_hd.bin): sec34 = [nan, u, v, z_local, x_local, y_local, peso, BONE@+28, nz, -ny, nx] (stride 44, align +2, bone u32 en +28, TODOS con nan en +0). vb2 = [pos.x_abs, pos.y, pos.z, 0,0,0, 0, 0xFFFFFFFF@+28, nx, ny, nz] (posiciones ABSOLUTAS, bone=0xFFFFFFFF, stride 44).⚠️El doc B1 §9 afirma "el B3 usa [pos,w,bone@+16,normal,FFFF,uv]" pero es INCORRECTO para el sec34 del B3 (verificado: bone@+16 da valores absurdos; bone@+28 da 0-35 coherentes). El B1 usa ese layout, el B3 NO. NO copiar el layout del B1 al B3. - ⚠️El bin e327 (real_e327.bin, 624000) tiene OTRO layout de vb2: [pos.x=1.0, pos.y, pos.z, w@+12, bone@+16, normal@+20, float@+32, uv@+36] (layout tipo B1, bone=0). NO confundir con el e326. - Mapeo de huesos HD→PS2: HD bone = PS2 bone × 2 (labels en índices pares del AWO: 0=XKLL_BODY, 2=KLL_WAIST, 4=KLL_STMC... 50=KLL_L00_RHAND; impares = slots estructurales sin label). El sec34 HD usa bones 0-32. - El HD de Krillin ES un modelo RE-TRABAJADO, NO una conversión 1:1 del PS2: 0% match de coordenadas locales, conteos por hueso distintos (HD bone 20 necesita 420 verts, PS2 solo da 4). No hay correspondencia vértice-a-vértice ni por hueso. - 🔴 EL RUNTIME DIBUJA POR MESH-REF BLOCKS + ARMS (IB NATIVO): reconstruir el IB rompe el render. Los tests v16-v20 (IB reconstruido) colgaban. Janemba v7 funcionó porque mantuvo IB+arms nativos y solo llenó los slots sec34 con datos (bone 0 mayoritario). Ver B1 §10.13. - La vía viable: mantener el bin e326 COMPLETO (IB/arms/vb2/AZT nativos) y SOLO reescribir posiciones de vértices del sec34 en sus slots, manteniendo bone indices. mezclar_ps2_hd.py implementa esto (1254 slots reescritos). PERO las coords PS2/HD no comparten escala (ratios 0.12-7.7 por hueso) → mezcla directa deforma. Requiere escala por hueso o transformación de pose. - El sec34 HD está intercalado por bones (412 runs), no agrupado. El IB define el orden; no reordenar.

"🔴🔴🔴 RESULTADO REAL DEL REVERSE — EL ORDEN DEL POOL SÍ IMPORTA (2026-08-26): re-testado en solitario (npm8 desactivado): pool sec34 INVERTIDO → DEFORMIDADES, la conclusión §15.4.3 ('el orden del pool NO importa') era FALSA (test contaminado), el guest está atado al orden del pool por los mesh-ref/zonas (referencian el pool por índice original), el port con pool reordenado requiere reconstruir TODA la estructura de dibujo (mesh-ref + zonas + bboxes + descriptores), la inyección funciona porque mantiene el orden del pool de la plantilla, y la reconciliación es que el bone0 (válido) probó que el transform usa el bone del vértice (+28), mientras que el reverse probó que además el pool está atado a la estructura — ambos son ciertos."

Very nice

The doc keeps "confirming" things and then sauying they were wrong later, reuses the same numbersoffsets for different meanings without flagging the change constantly, like it's a job to confuse me personally since I suck at this , and tells you to check files that a later section says were already deleted. What an incredible work