J3D File Format

[faxnico]

Thank you for sharing.

Just a couple of points...

The value at Model+0x58 is a dword, and if it equals 1, the model is drawn through DrawPrimitiveUPs. This occurs once or twice during the recursive traversal of the hierarchy.

As for Model+0x5C, it represents another dword, typically set to 0, and points to an item within an array of render data. Each structure in this array is 0x5c bytes in size and contains at least two user-provided vertex data buffers for the DrawPrimitiveUP calls mentioned earlier, filtered by the condition Model+0x58. The second buffer is utilized, and the draw call is executed, only if Model+0x294 is true as well. This draw call is wrapped by special render state enable/disable code...

Hope this helps.
Keep up the good work.

[Polak2]

Let me be the 1st to congratulate you on this milestone achievement.

Not sure if Dangerous Waters also uses the same J3D format or not, I haven't tested it with DW.

Yes, it does. In fact, as my earlier picture shows the models in JFC are nearly identical with SC (Sub Command) and subsequently DW (Dangerous Waters).
It will be interesting (time permitting) to test the Obj models export to J3D for use in all of the above Sonalyst titles.
and

[Jeff-Groves]

Nice work HoneyFox!
I lost interest with the format way back. Still have the 010 scripts and such.
I'll check your work and see what I missed. Always good to learn from others.

[HoneyFox]

Originally Posted by faxnico

The value at Model+0x58 is a dword, and if it equals 1, the model is drawn through DrawPrimitiveUPs. This occurs once or twice during the recursive traversal of the hierarchy.

As for Model+0x5C, it represents another dword, typically set to 0, and points to an item within an array of render data. Each structure in this array is 0x5c bytes in size and contains at least two user-provided vertex data buffers for the DrawPrimitiveUP calls mentioned earlier, filtered by the condition Model+0x58. The second buffer is utilized, and the draw call is executed, only if Model+0x294 is true as well. This draw call is wrapped by special render state enable/disable code...

I'm curious about how you get these info. Maybe via debugging JFC or debugging DW?
For "Model+0x294", I don't quite get it. AFAIK, the "Model" size is 0x60(96) bytes. Model+0x294 seems to be way out of bound, unless it is some runtime-only structure different from J3D file structure, or it is some optional field of "Model" which only becomes available when the "Model+0x5c" is not 0.

[faxnico]

Debugging and offline/static analysis.
I had this sorted out a while ago to code a J3D loader replacement with something more modern (GLTF).
+0x294 was an offset to the runtime structure indeed (S3DModel).
The model/mesh/subset data size is 0x60 bytes.
The render state change that wrapped that 2nd drawprimup was, on the other hand:
SetRenderState(D3DRS_ZFUNC, D3DCMP_NEVER);
DPUP();
SetRenderState(D3DRS_ZFUNC, D3DCMP_LESS);
SetRenderState(D3DRS_ZENABLE, TRUE);
Maybe for some decals rendering, I don't know.

[Aktungbby]

faxnico!...after 14 years!??

[HoneyFox]

Originally Posted by faxnico

Debugging and offline/static analysis.
I had this sorted out a while ago to code a J3D loader replacement with something more modern (GLTF).
+0x294 was an offset to the runtime structure indeed (S3DModel).
The model/mesh/subset data size is 0x60 bytes.
The render state change that wrapped that 2nd drawprimup was, on the other hand:
SetRenderState(D3DRS_ZFUNC, D3DCMP_NEVER);
DPUP();
SetRenderState(D3DRS_ZFUNC, D3DCMP_LESS);
SetRenderState(D3DRS_ZENABLE, TRUE);
Maybe for some decals rendering, I don't know.

This additional 2nd DPUP is rendered with ZFunc = Never? If ZTest is enabled previously, nothing will be drawn then. That's quite strange, even for decal/VFX/... transparent mesh rendering (They usually have ZENABLE = True, ZFunc = Less/LEqual and ZWRITEENABLE = False). Does it instead have any stencil-test related API call nearby?