Support mesh and curve export

[JayFoxRox]

I've done something similar as what this tool does, but instead, I used the subposition-data from OpenRCT2 to generate the position, normal and binormal of each piece.

I ran into 3 issues with my approach:

• It's heavily quantized.
• blender array-modifiers can't stretch models to fit a curve length.
• blender curves have limited control over twisting.

So I'd be interested in 2 things:

• Analytical subpositions (what this tool does, but does not export); would solve quantization issues and also allow generating new subposition data for the game.
• Properly fitted meshes (which this tool does, but does not export); would work around blender problems.

[X123M3-256]

In order to add the ability to generate new subposition data, I'd have to figure out what information the subposition data contains and how it's formatted. I think this would be useful once the new save format is merged as it would be a necessary step in the creation of new track pieces.

Adding the ability to export the meshes probably wouldn't be too difficult, but I'd have to think about the best way to do it. Most track pieces consist of multiple meshes, so merging them into one is something that would have to be added.

[JayFoxRox]

In order to add the ability to generate new subposition data, I'd have to figure out what information the subposition data contains and how it's formatted.

I might have missed some of the important nuances, but it seemed straight-forward to me.

I simply used https://raw.githubusercontent.com/OpenRCT2/OpenRCT2/f8ab48176a069e266a298b76ee28110c11cae596/src/openrct2/ride/VehicleSubpositionData.cpp

The table TrackVehicleInfoListDefault contains 4 entries per track element (so it has 256 x 4 elements in total).
The 4 different ones are for each rotation (I was surprised this is stored in such detail; I'm not entirely sure why the game doesn't auto-generate these variants; so maybe there's more to it?).

Each of the 4 elements per track-element is pointing to an array of the typical structure (filled by the CREATE_VEHICLE_INFO macro):

    struct rct_vehicle_info
    {
        int16_t x;                   // 0x00
        int16_t y;                   // 0x02
        int16_t z;                   // 0x04
        uint8_t direction;           // 0x06
        uint8_t vehicle_sprite_type; // 0x07
        uint8_t bank_rotation;       // 0x08
    };

The order of the elements is the order of steps along the animation. Note that rct_vehicle_info_list contains the number of frames, and this is also stored by CREATE_VEHICLE_INFO.
I'm not sure how the number of frames is determined, but I assume it goes by distance between frames?

My tool simply interpreted vehicle_sprite_type as a vertical angle (this is the one changing in a loop).
A loop does 2 - 4, then 9 - 16 (upside down), then 23 - 17, 8 - 5; so the order is a bit confusing.

The others are self-explanatory and it's basically the stuff explained in most docs about which sprites exist.

So you just need a function to map each orientation to the closest direction / vehicle_sprite_type / bank_rotation.
This could be done in a separate tool, so it would be enough to export normal, binormal and tangent at each step.
This would also allow people to load the curves into tools like Blender for quickly experimenting with meshes (although blender curve tools are severly limited unless the user is fine with using the animation-nodes add-on).

Most track pieces consist of multiple meshes, so merging them into one is something that would have to be added.

It's easy enough to manually post-process the mesh, so even if this isn't done, a mesh export would be useful.