I've decided to make full use of the 3D modeling tool "PELOGEN2" for my new game project.

I was able to create something that roughly took shape, and only recently have I been able to incorporate the 3D models I created.
However, when I try to actually incorporate and operate the models, or create the model I need based on my own image, the result leaves something to be desired.

Repeating Textures (Loop Patterns)

For example, if you want to create a polka-dot tablecloth, you'll need many polka dots on one triangular surface.
Pico-8 has a limited sprite sheet size, and I want to make effective use of the texture area for other models in the game I'm making.
Therefore, if I can use the area of a single sprite to repeatedly apply it to a large surface, I don't need a large image.

Preventing Texture Overflow

When UV mapping is performed directly using the "tline()" API for drawing texture lines, the texture will often overflow, or the edges will be slightly short of the specified range or not displayed.
By using the loop settings above, the overflowing parts will return to the other side, allowing the edges to be displayed and allowing for some tolerance of this misalignment.

(However, figuring out how to calculate this as a triangular surface can be quite a challenge.)

The texture display before and after the correction; the orange blur is gone.

Rotational compositing of multiple models

I'm not good at complex equations.

But I've always just been thinking, "This should work!", so when I come across a problem, I feel like today is finally the day to give up.
Even though it's compositing, I was able to reach my goal by rotating in an orderly manner from the base coordinates and rotation state.
When rotating a single model, I was able to do most things by rotating it twice.

But how do you rotate two models at an angle, even shifting them from the center of the rotation axis, so that their left and right sides swap? This requires new processing (which was previously minimal).
It requires the concept of a Global (all models) and a Local (individual models) for the rotation center (pivot), and it strongly emphasizes the need to rotate as a Group(multiple models selected from the whole).

Previous implementations always involved rotation from a base, followed by additional rotations. If you wanted to shift the pivot or return the rotation axis to its original position during additional rotations, the result was either incomplete or chaotic.
To achieve the intended multiple rotations, you can retain the vertex coordinates after each rotation and return the rotation axis to 0 (using it as the base), making it easier to achieve the intended additional rotations.

Polygon Overlap

While prioritizing the Z coordinate relative to the screen is essential,

to improve the results, we tried sorting by taking the average Z coordinate of three points. However, even this resulted in an unintended reversal phenomenon.
If two points are on a face with the foreground Z coordinates and three points on a face with different Z coordinates, the former will come out in front. This is likely to occur when a small face is diagonally positioned above a large face.

So instead of taking the average of the three points, we take the median. This improves things to some extent.
If this still doesn't work, we can improve things to some extent by dividing each face into smaller pieces. Going beyond this would require a Z-buffer method, which would require major changes, so we compromised. This tends to be heavy to implement and doesn't seem to be very effective, so we think we can alleviate it by dividing the polygons.

UV mapping data was being read and written incorrectly

When saving UV data, it was off by one bit, and when loading it, that one-bit discrepancy was corrected. One bit of data for an unimplemented texture loop (which exists as a specification) was being discarded.
Fixing this will render all previous UV data unusable.
Since it's easy to recreate the UVs, I've decided to fix the previous data manually, but if there are any users who can't bear the extra effort required for this fix, I'll create a data fix patch cart.

It's a far cry from its former self...

While we're revising the specifications...

we'll also be changing the UV data grid.

We've been correcting the current way UV points are placed to a grid that runs from one edge of the sprite cell to the other, but we felt it was time to change it because the 1px shift made it difficult to use and limited the range of expression.
Instead of edge-to-edge, it will now be a simple 4px grid. The loop process described above will reduce overflow. (There are some cases where this doesn't work.)

It's best if both ends of the sprite in the specified range are the same color...