I slept a little and now I've been making some tests. My hypothesis was that black artifacts shown in the track preview screen for the track Cactus Festival reminiscent of inkblots were due to the presence of player cars in the track design whose miniature shape included ellipses that were incorrectly rendered and that this was to be expected of custom made cars, like is the case of the Melange.
My test yields affirmative results. In fact, the Melange is not the only one to cause this issue. All the cars that produce these effects are custom-made, though most custom-made cars do not produce it. For each car, the distribution of the artifacts is different and sometimes, it may change for each peek in the track preview. Other artifact also appear occasionally. This suggests that there is something we do not know about how 3D shapes are supposed to be designed because some aspects of them are rarely put to the test.
Cars that produce these bugs:
Audi DTM - Huge black and red painted areas
BMW DTM - Huge black triangle
Porsche 911 Turbo - Yellow regions and distortions in terrain rendering
Melange - Two black inkblots
Custom-made cars that don't:
Mercedes DTM - Very curious since the other two DTM cars do
Speedgate
Nissan Skyline
Ford Ranger
Superkart
Xylocaine
Ferrari F40
GT3 Mark II
Lotus Esprit
McLaren Honda
After a track has been displayed in the preview and exhibited glitches, Stunts becomes unstable and is likely to crash. The colours in the glitches appear to be complete unrelated to the paint job colours.
I saw blue triangle shaped artifacts with the Porsche 962 IMSA.
Oh... well, if these things happen with original cars, the message is that including car shapes in track designs can lead to these things in general. The thing is the shape has to be rendered so small that it can yield strange results.
Thanks for starting a thread about the inkblot! While I have been aware of artifacts of this kind for a long time, I never gave any thought at all to what might cause them.
Quote from: Daniel3D on December 19, 2020, 11:02:11 PM
I saw blue triangle shaped artifacts with the Porsche 962 IMSA.
So it's not just custom cars then. That closes a few possible lines of investigation.
Another thing I have noticed is that results seem to also depend on the track. For instance, there is an artifact with the Corvette on ZCT075 (another track with a scenery car), but not on Cactus (both tracks are attached below).
Quote from: Cas on December 19, 2020, 10:01:41 PM
After a track has been displayed in the preview and exhibited glitches, Stunts becomes unstable and is likely to crash.
While I had not noticed any related instability instability before today, that was probably due to lack of testing. A reproducible example: if you start the game, pick the Kart as your car, then go to the track selection menu and pick Cactus, a "check disk" error will happen out of nowhere when you try to go back to the main menu. The same thing happens with the Trueno on ZCT075, with the additional weirdness of the menu music rewinding back to the start of the song! Note that you can still drive normally with those car-track combinations as long as you select the car after the track, so this issue is not quite as severe as it might seem.
Between reading your posts and doing some tests of my own, I think I now have a reasonable hypothesis to account for this issue.
Much like a car's P3S/3SH file holds car0, car1 and car2 shapes, every track object 3D shape in GAME1.P3S and GAME2.P3S has a low detail counterpart which is used when rendering the track preview, its shape name having "z" as a prefix (for instance, tunn and ztun are the two tunnel shapes in GAME1). Now, the scenery cars we add with the 0x02 and 0x03 values in a track files aren't actually track elements -- presumably we are taking advantage of the car1 shapes, by a happy accident, being loaded in just the appropriate places in memory for us to pretend so. Since the cars aren't track elements, there is no low detail counterpart of their shapes, and so whatever addressing mechanism the game uses to find the low detail shape gives back arbitrary stuff, leading to unpredictable behaviour. (Note, by the way, that even when there are no visible graphical artifacts you never actually see a car in the preview; at best, you get an empty-looking tile.)
Uhhmm... I tried the kart with both tracks, loading the car first and track after and the other way around and none of the two gave an error or showed artifacts. So weird! Makes me think that maybe, how many cars you have in your "garage" can affect the results. Otherwise, I can't see how one would get a certain result and another person won't. On the other hand, I have indeed got that error message when I did my previous test with some cars. At a point, Stunts crashed and took me back to DOS.
There's no doubt that the issue has to do with rendering the player's car in the track preview, but it's unclear how the issue develops exactly. Instability problems usually have to do with memory being overwritten. If executable code is being overwritten, usually you get a fatal crash. This looks more like data being overwritten, so then the information is corrupt, but the code tends to stay up for longer, until some unsustainable calculation is made with extreme parameters or a corrupt pointer leads to executable code overwriting getting back to the first type of crash.
All in all, the only way to be sure this won't happen appears to be to not use player or opponent cars in tracks.... sad :( I think we can cope with the risk :P
Quote from: Cas on December 20, 2020, 03:48:11 AM
Makes me think that maybe, how many cars you have in your "garage" can affect the results. Otherwise, I can't see how one would get a certain result and another person won't.
That does seem possible. (I currently have 31 cars, one fewer than the maximum.)
Quote from: Cas on December 20, 2020, 03:48:11 AM
All in all, the only way to be sure this won't happen appears to be to not use player or opponent cars in tracks.... sad :( I think we can cope with the risk :P
I agree, it is manageable. The upshot is that we now kind of understand the glitch and won't be too confused next time anyone runs into it.
Quote from: Cas on December 20, 2020, 03:48:11 AM
Makes me think that maybe, how many cars you have in your "garage" can affect the results. Otherwise, I can't see how one would get a certain result and another person won't.
The used a clean ZakStunts 2020 copy with only the melange and the two tracks added.
It does have the car pack with the DTM car's included.
This is so cool. The game passed 30 and even custom car shapes have been around for years and there are still people figuring new stuff out.
Yeah, makes me want to retake my 3D engine project, but it's so much work!
I was compelled to have another look at this issue after noticing that Ryoma's Jaguar XJ220 is badly affected by it, at least in my install with 32 cars. Almost every track with a ghost car leads to a crash if you start the game and try to select it with the XJ220 as the chosen car (I have attached Visegrád and ZCT193, which can be used to reproduce the issue). Workarounds include:
- As mentioned above, choosing the track before the car seems to be enough to avoid the problem.
- Additionally, the crashes appear to only happen the first time you try to race after switching to an affected car. That being so, starting and quitting a race with the XJ220 on Default, or some other unproblematic track, seems to be enough to prevent the issue on further track changes. (Note that if you select some other car and then go back to the XJ220, you'll have to do it again.)
Whether, and to which extent, the issue manifests itself appears to depend on arbitrary minutiae of the car shape memory layout, and so a proper solution for this issue seem out of reach. For instance, I have tried to fool the track preview renderer by adding an empty
zcar shape to
STXJ22.3sh (see my longer post above for why I hoped that might work). While that does seem to prevent the issue for the XJ220, the trick doesn't work on the Trueno doesn't work, as it crashes on ZCT075 regardless. (I have attached both modified 3sh files, in case you want to inspect them.)
zct16 has ghost cars too ;)
BTW I enjoy these threads but I don't know how to contribute :D
I'm not near a computer now. But the cars that produce artifacts. Are they close to the limit of vertices?
Scenery has a lower limit I believe.
That would explain why there are no artifacts when the car is not selected yet.
Quote from: Daniel3D on January 08, 2022, 09:27:58 PM
But the cars that produce artifacts. Are they close to the limit of vertices?
Some are, such as the XJ220, but others are quite far from it, such as the Kart.
Quote from: Daniel3D on January 08, 2022, 09:27:58 PM
That would explain why there are no artifacts when the car is not selected yet.
(If we load the game and start a race without going to the car selection screen, are the Countach files loaded on startup, or just when we choose "Let's drive!" on the menu?)
On startup the base selection values are loaded. But the car itself is loaded when you press let's drive.
The track is also loaded then.
The preview of the car or track is separate from driving and unloaded from memory before driving.
This sounds to me like the whole-track renderer expects some restrictions from the 3D shapes that go beyond what's normally expected in game, yet the original cars respect these restrictions. When a car is loaded, the shape is brought to memory as-is, but then, if you run a race or load another track, it seems that these mini-shapes are processed, so the problem disappears. This lead me to think, too, that cars nearing the vertex or primitive limit could be more likely to cause problems.
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. I would assume it's car1, because that one has the same scale as the track elements. But if it happened to be car2, it's a lot simpler to get restrictive with it. If it's car1, I would like to test whether cars that do cause problems with this also bring similar problems when you give the opponent that car and your race with him/her and watch the car from afar (so it looks as small as in the track screen). If it were car2, I would be highly suspicious of wheels, which are normally absent in car2 models of original cars.
Quote from: Cas on January 09, 2022, 01:08:01 AM
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.
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.
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.
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.
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
New glitch alert! Selecting the Pantera and then r4k48/City Greens (the current R4K track) (https://www.raceforkicks.com/index.php?page=race&race=2023-12) 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:
load_036.mp4
(The underlying nature of the glitch appears to be the same as before, and the mitigation measures mentioned earlier still work.)
The "laser" appears to cycle between the same colours as the menu selection border.
Well spotted,
@KyLiE ! In general, the artifacts aren't completely arbitrary, no matter how wacky the glitches can get.
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
Quote from: Cas on December 18, 2023, 10:15:46 PMWell, 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)
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
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...
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.
Quote from: Cas on December 18, 2023, 10:15:46 PMIf 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.
That doesn't seem to be the issue. For instance (Duplode mentioned),
Quotethe 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??
It could be, yes, that there is an array of pointers to the models that have to be loaded for each code, but the car models are not in memory while in the track section, so it points to a random location. That would explain random polygons being drawn, some extremely large, but doesn't explain crashes or how this appears to interfere with the button borders, since it's a read-only procedure to load the shapes and draw the track.