2024-04-12 snapshot

[Jakob Hubbard]

I just tried hidden hud while loading up a demo and have 3419 MB texture memory usage and didn't have this issue. Jlv, did you fix the wrapping for the texture memory value yet? I'm wondering this value is possibly 6GB instead of 2GB. Does this happen every time for you Race? Or does it seem inconsistent?

Everytime

That's good news, at least there's some consistency here. It might help jlv solve the problem a little easier. I'm just not sure why it would be at 2GB of texture memory. What GPU do you have?

[jlv]

Think theres a pretty game breaking glitch with this snapshot, seems like sometimes the wheels glitch into the ground and come back out and make u crash.

here is some clips just from the racing tonight in rf:

https://streamable.com/oyqrgm

https://streamable.com/c3ihxy

https://streamable.com/asykfw

https://gyazo.com/25a911c1da01536a4269cf1fc2381ebd

The physics haven't changed in this snapshot, but high speeds with a low terrain spacing might expose more glitches in the terrain collisions. Looks like Hangtown is .4 which is really low. Probably better to stay around .75 or higher for efficiency and cleaner collisions. Going under .5 seems pretty extreme.

[jlv]

Same issue here, I disabled reshade but to no avail. Uninstalling reshade might have a different outcome but I didnt test it. Anything over 2k texture memory usage usually results in black textures for me.

I just tried hidden hud while loading up a demo and have 3419 MB texture memory usage and didn't have this issue. Jlv, did you fix the wrapping for the texture memory value yet? I'm wondering this value is possibly 6GB instead of 2GB. Does this happen every time for you Race? Or does it seem inconsistent?

I changed the counter to 64 bits but maybe I missed something that truncates it somewhere.

[jlv]

I just tried hidden hud while loading up a demo and have 3419 MB texture memory usage and didn't have this issue. Jlv, did you fix the wrapping for the texture memory value yet? I'm wondering this value is possibly 6GB instead of 2GB. Does this happen every time for you Race? Or does it seem inconsistent?

I changed the counter to 64 bits but maybe I missed something that truncates it somewhere.

Turns out I passed the value through a 32 bit variable in the texture loading code. It didn't just truncate the counter. It takes the difference between the truncated value and the actual value to calculate the size of the texture it just loaded. Not sure what the exact effect would have been but it'll definitely make it report the wrong value when over 2G. I'll fix it and post an update.

[jlv]

Turns out I passed the value through a 32 bit variable in the texture loading code. It didn't just truncate the counter. It takes the difference between the truncated value and the actual value to calculate the size of the texture it just loaded. Not sure what the exact effect would have been but it'll definitely make it report the wrong value when over 2G. I'll fix it and post an update.

Haven't tested this with over 2G yet but I think this should fix the texture memory counter.
mx-2024-05-30-1669.exe
mxbin-2024-05-30-1669

[jlv]

Just made a track with 80 4k by 4k textures to test it and it seems like the old version worked despite the bug. Could be there's some undefined behavior rule in C that lets the compiler upgrade the value to 64 bits even though I only asked for 32. I only tested on the Linux version. Might make a difference in the Windows build.

[SethShirley44]

Haven't tested this with over 2G yet but I think this should fix the texture memory counter.
mx-2024-05-30-1669.exe
mxbin-2024-05-30-1669

Noticed with testing this updated snapshot the load times on the decals I was mentioning a couple weeks ago is barely noticeable now with how much faster it loads them in

[jlv]

Noticed with testing this updated snapshot the load times on the decals I was mentioning a couple weeks ago is barely noticeable now with how much faster it loads them in

This shouldn't have changed anything but the texture memory count shown. Which apparently was working anyway despite the bug.

[SethShirley44]

This shouldn't have changed anything but the texture memory count shown. Which apparently was working anyway despite the bug.

I might just be tweaking then

[Racers52]

That's good news, at least there's some consistency here. It might help jlv solve the problem a little easier. I'm just not sure why it would be at 2GB of texture memory. What GPU do you have?

3080TI, memory shouldn't be an issue I'm thinking.

Turns out I passed the value through a 32 bit variable in the texture loading code. It didn't just truncate the counter. It takes the difference between the truncated value and the actual value to calculate the size of the texture it just loaded. Not sure what the exact effect would have been but it'll definitely make it report the wrong value when over 2G. I'll fix it and post an update.

Haven't tested this with over 2G yet but I think this should fix the texture memory counter.
mx-2024-05-30-1669.exe
mxbin-2024-05-30-1669

Appears the issue has been fixed, no more black textures so far.

[Racers52]

Went to a more intensive track and its back, no settings changed.

[jlv]

Does it not happen for the first track you load after starting the game?

[Racers52]

Does it not happen for the first track you load after starting the game?

It does happen for the first track I load in

[Racers52]

Reducing "Ground Geometric Detail" from 100 -> 80 seems to have fixed it for me, again. Testing the same tracks with no issues so far.

[jlv]

Does it not happen for the first track you load after starting the game?

It does happen for the first track I load in

OK. The game does keep the previous race's textures around when it loads the next race so it doesn't have to reload the textures shared by the previous and current race. That could make it go exceed the texture memory while still reporting totals less than the available memory. Wouldn't be an issue on the first load though.

Reducing "Ground Geometric Detail" from 100 -> 80 seems to have fixed it for me, again. Testing the same tracks with no issues so far.

I have no idea why that would change it. That should be independent from the texturing.

I'll try adding some sanity checks to the texture allocation code for the terrain textures. Maybe it'll get an error message at least.