mirror of
https://github.com/open-goal/jak-project
synced 2026-05-23 23:05:43 -04:00
Hat Kid
c64eea6337
This adds support for generating collide meshes when importing custom models. A couple of things to keep in mind: - A single `collide-mesh` may only have up to 255 vertices. - When exporting a GLTF file in Blender, a `collide-mesh` will be generated for every mesh object that has collision properties applied (ideally, you would set all visual meshes to `ignore` and your collision meshes to `invisible` in the OpenGOAL plugin's custom properties). - Ensure that your actor using the model properly allocates enough `collide-shape-prim-mesh`es for each `collide-mesh` ([example from the original game that uses multiple meshes](https://github.com/open-goal/jak-project/blob/f6688659f2ef85f5ceaacea6271580c9f4d91ed1/goal_src/jak1/levels/finalboss/robotboss.gc#L2628-L2806)). ~One annoying problem that I haven't fully figured out yet (unrelated to the actual functionality): `collide-mesh`es are stored in art groups as an `(array collide-mesh)` in the `art-joint-geo`'s `extra`, so I had to add a new `Res` type to support this. The way that `array`s are stored in `res-lump`s is a bit of a hack right now. The lump only stores a pointer to the array, so the size of that is 4 bytes, but because we have to generate all the actual array data too, the current `ResLump` code in C++ doesn't handle this case well and would assert, so I decided to omit the asserts if an `array` tag is present and "fake" the size so the object file is generated more closely to how the game expects it until we figure out something better.~ This was fixed by generating the array data beforehand and creating a `ResRef` class that takes the pointer to the array data and adds it to the lump.