Artifacts in track preview rendering with custom cars

[Duplode]

One thing we should try is modify each of the shapes in a car one by one leaving the other two untouched and then render the track to find out which of the three models is rendered in the whole-track screen.

On this point, my working hypothesis is that none of the models is loaded: the preview renderer tries to load a shape but retrieves an arbitrary stuff which might, by pure chance, be a chunk of the 3SH of the car. One observation that IMO supports that is how nothing is actually drawn on the ghost car tiles when there is no glitch. Confirming that would, of course, require more careful investigation.

[Daniel3D]

Track elements also have a z-variant. That is for far away. Like the car2 shape. I think that those are used in the track preview. I don't know what car shape is used. But it might be car2 as well.

[Cas]

It does make sense that the actual model isn't read at all. Probably, the car model is loaded prior to racing and pointed to in a "slot" that relates it to track elements 2 and 3, causing them to be rendered during a race, but then, if this loading is not done or is somehow undone while the user is at the menus, it'd be sensible to get nothing drawn.

The only thing that makes me think otherwise is the simple fact that the odds of getting glitches clearly depend on which car you're using. So if it isn't the car 3D model, then something else from the car is being taken into account somehow.

About track elements in low resolution, if I remember well, they do contain fewer polygons, but they are at the same scale as high definition ones.

[Daniel3D]

I think that the track preview uses the low poly models because you don't have to see details anyway. If the car model is used in the track and no opponent car has been selected yet, it has a placeholder that doesn't render(therefore no artifacts).
If it uses car2 in the preview, then it makes sense to check those models for irregularities.

[Cas]

Independently of whether Stunts attempts to render one of the models or not, the contents of the car file do have something to do with all this. Replacing individual files or individual chunks and trying until we see the difference come up would help us understand what's going on

[Duplode]

New glitch alert! Selecting the Pantera and then r4k48/City Greens (the current R4K track) breaks the tracks menu, in that you no longer can select any of the options with the keyboard, and pressing enter brings you back to the main menu. Moreover, pressing left twice with the menu in this state activates a laser cannon:

You cannot view this attachment.

(The underlying nature of the glitch appears to be the same as before, and the mitigation measures mentioned earlier still work.)

[KyLiE]

The "laser" appears to cycle between the same colours as the menu selection border.

[Duplode]

Well spotted, @KyLiE ! In general, the artifacts aren't completely arbitrary, no matter how wacky the glitches can get.

[Cas]

Well, it looks like the routine that draws the 3D track view reserves some not very big amount of memory to work with each model at drawing time. I'm thinking maybe a maximum number of primitives a lot lower than 255 can be used because the low-res track elements never exceed this number, so it works well for most models, including original cars car2 model, but custom cars frequently have a high number of polygons even in the car2 model, so there's an overflow and other memory is overwritten... memory having to do with the menu locations, aparently.

If this is it, then all we have to do is give our cars a low-poly car2 model

[Daniel3D]

Well, it looks like the routine that draws the 3D track view reserves some not very big amount of memory to work with each model at drawing time. I'm thinking maybe a maximum number of primitives a lot lower than 255 can be used because the low-res track elements never exceed this number, so it works well for most models, including original cars car2 model, but custom cars frequently have a high number of polygons even in the car2 model, so there's an overflow and other memory is overwritten... memory having to do with the menu locations, aparently.

If this is it, then all we have to do is give our cars a low-poly car2 model

I was thinking te same. But many custom cars have car0 and car1 the same. So I think that the threshold is not far below the maximum.
Many of ryoma's cars are high in number, so I should be possible to find the edge by just swapping cars ..(working up or down in big steps and change direction in increasingly smaller steps each time to bug appears or disappears)

[Cas]

Yes. I'm pretty sure car2 is used for this, so we could try removing primitives (or vertices) gradually to see when we get to the sweet spot.

It's also possible that the limit is not about the number of primitives or vertices, but about the size of the loaded model in memory. Not sure if car models in Stunts are decompressed at load time or just drawn from compressed. In the second case, the fact that our custom cars are not compressed can play a role here. A good test would be to decompress an original car and see what happens if we use the decompressed model... but it probably won't have an impact because car2 is always very small (in bytes) in Stunts

[Daniel3D]

Let's first check which cars trigger it and which don't.. and see what is different to them.. if all glitch cars are higher in poly or vertices that the others we know we're on the right track...

[Duplode]

I don't think this has specifically to do with excess detail in car2, as the glitches have sometimes happened with the original cars as well. Also, even when there's no glitch no car gets rendered in the preview, so it's quite possible the game isn't actually trying to load a car shape there.

[KyLiE]

If this is it, then all we have to do is give our cars a low-poly car2 model

The De Tomaso Pantera GTS already has this, and as @Duplode mentioned, nothing is usually rendered anyway, so I doubt this is the cause.

[Daniel3D]

That doesn't seem to be the issue. For instance (Duplode mentioned),

the Kart + CACTUS.TRK combination can lead to a game-crashing glitch, and yet the Kart 3SH has a purposefully designed (not scaled down, just 13 polygons) car2.

My thoughts on the added information.

Track element 02 and 03 were off course never meant to be scenery. They are placement markers, They trigger a code that looks up the car.
The preview track loading code is not the same as the driving track loading...
The start tile gets two location markers for the two possible cars.
The starting animation also uses it als endpoint i believe.
The car is loaded with the orientation of the marker

I think that the extra cars are placed in the track on the left or right side of where the track would be relative to the orientation of the start tile..
The preview doesn't load the markers of the start tile, they aren't appointed at that time because they are not needed..

They have no preview object...
But that doesn't explain why it sometimes glitches..

So maybe it does try load the car, can orientation be a factor??