Taking on the laborious job of retexturing RBR (questions)

[Juha_Werx_Team]

Hi all,

My introductory post here, and it's filled with questions about RBR's files. I'm a experienced hobbiest texture modder, & being bored as well as unsatisfied with DR, I've reinstalled RBR after what seems like forever. Actually thrice, with differing mods. So you can guess my reaction to the texture quality, after making uhq textures for other games...



After analyzing RBR's memory footprint w/ RSRBR, Czech plugin, etc, etc, on all of the most intensive tracks, I found the old girl's still got a bit left in her performance overhead-wise.

So, on to my quandary...

Primarily, as to whether or not RBR even uses bump maps/normal maps. As I've not found any at all, at least in the .rbz files that is (.lbz? If so, how to unpack? 7z and Universal Extract balk @ doing so). Kind of doubting that it's using any, perhaps aside from cars from observations whilst driving around. Vehicles are not my focus atm, & haven't looked, as they seem pretty well covered so far on textures. Thanks for any advice you can give.

 

[Juha_Werx_Team]

No one? Any ideas who to go to that might know the answer then?

Also, an ENB preset I'm working on at the moment:

It's a bit geared towards medium-to-high spec systems, but visually satisfying.

 

[Dinos I]

Hi! Try to ask here

 

[Juha_Werx_Team]

Hi Dinos, thanks for the direction. As soon as I have a moment to spare, I will do so. Although it will have to wait for the moment. Family arriving from out of town in a few moments, staying for the weekend +.

I do have some bad news though, I went through a few more tracks and found some that are conversions from other games that perform quite badly by default. Those in specific are running into the mem limit with my ENB, and stuttering ensues. Large (memory) Address Aware switch being activated in the RBR .exe will solve the problem, however the competition plugins are apparently hashing the executable to ensure they're unaltered to avoid cheating methods.

All in all, that is fine.

On the other hand I have no idea why anyone in this day & age wouldn't have L.A.A. enabled by default, especially on a Win 95/98/Millenium/2000 era developed game. Xp bumped that up to 3.1 Gb addressable memory space per executable, for those that don't know. No reason at all we shouldn't be able to leverage that additional memory in reserve.

Probably going to post on each of their forums to see if they would be willing to update the .dll to accept as valid the executable with that change. Perhaps Boris might be willing to port his ENBoost as well, giving a bit of additional headroom.


...and there's the knock at the door. Time to go.

 

[WorkerBee]

Well, that is a very simplified view on Windows' memory and application management.
The LAA flag only has an effect on 64bit Windows, AFAIK.

You never know which libraries being used by RBR are affected by such a manipulation (DirectX, etc. etc.).
There may happen weird crashes or other strange behavior.

RBR has a memory footprint of roundabout 300 to 400 MB.
I think it is nuts to invent an "optimization" which requires 10 times the memory.
Not everybody likes the kinky looks of (most) ENB mods.

So I am pretty sure that none of the online plugins' admins will go your way.
Doors shut.

 

[Juha_Werx_Team]

"The LAA flag only has an effect on 64bit Windows, AFAIK."

Hello WorkerBee, thanks for your input & all you've done for RBR over the years.

I think you are under the assumption that I am suggesting supplanting an LAA enabled for the original. That I am not, & it ofc would not be practical to force everyone onto x64 operating system. Simply, my suggestion is tailored to adding a secondary allowable hash result for the enabled executable in the competition plugins, which is currently excluded.

That in and of itself handicaps anyone using an OS that can address more memory space, & would affect no one who doesn't. I can't see any benefit to disallowing that out of hand. As for the testing, I've been doing so, and haven't encountered a problem so far. I am on the other hand, only one person with only so much time at my disposal, & there is much left to do.

As to ENBoost, I have to apologize for not being more clear, but I was racing the clock trying to get my post in. I tend to forget that ENBoost is not very well known. With it, it's not necessary to use the visual effects of the binary with the boost function if one doesn't like them. They can be disabled if one prefers, dropping the binaries footprint to nearly nil, all while gaining large benefits for those with 64 bit systems.


This is how you would do so in the ENB .ini, thereby allowing a 32 bit binary to address up to 10 Gb of memory without ctd'ing & without the visual FX if they are not desired.


[GLOBAL]
UsePatchSpeedhackWithoutGraphics=true
UseDefferedRendering=false
[MEMORY]
ExpandSystemMemoryX64= ;you may set this to either true or false and it will work, but you must also have ReduceSystemMemoryUsage=true and EnableUnsafeMemoryHacks=false if it is set to true. (If you have a 64-bit OS setting it to true is recommended. If you are on Windows 10 it must be set to false.)
ReduceSystemMemoryUsage= ;see: ExpandSystemMemoryx64 (recommended:true)
DisableDriverMemoryManager=false
EnableCompression= ;if you have a lower end system setting this to true may improve performance, worth trying both ways to see if there's a difference
ReservedMemorySizeMb= ;This may be set to 64, 128, 256, or 512. Start at 64 and work your way up until you can play without experiencing stutter in game. Most 64-bit users will use 128. If you don't get stuttering at 64 all the better.
VideoMemorySizeMb= ;vram + (system mem*.5)


All is dependent on whether Boris feels like taking the project up again, but the benefits are substantial.

I understand most people's consternation concerning ENB in game, but most of the issues with appearances are due to the badly executed textures, not ENB in and of itself. Over saturation & bad brightness/contrast settings is the source of those issues.


However, the topic's focus is on the textures themselves. Sorry for my divergence into the subject of ENB & ENBoost, as I seem to have sidetracked this myself being pleased with my results & wanting to share my findings.

 

[Juha_Werx_Team]

As a sidebar to the question of plugin functionality, I've had my nephew, niece, & myself playing for the last 4 hours (kept them busy, and out of everyone else's hair, lol). To whit, only on the stock maps mind you:

- pacenotes plugin
- fixup plugin
- NGP

...have all worked flawlessly. No crashes, no errors in any logs, nor anything out of sorts with LAA enabled on RBR 1.2 patch running in Win 7 x64. Next step is going to be bumping the ground & perhaps foliage textures up to 8k - 16k resolution to see if it will breach 2 Gb without crashing.

To anyone is willing to help test with whatever plugins are out there in question, here's a utility for patching your executable. Tech Power Up is a reliable source, but feel free to verify it with Virus Total or whathaveyou. Backup your original executable beforehand, in case something goes awry (doubtful). You will have to restore the original .exe before using any competition plugins.

https://www.techpowerup.com/forums/threads/large-address-aware.112556/

Prior analysis by VT: https://virustotal.com/en/file/7c8f...63b86f2682818633a97ccbd31b45fd0514a/analysis/

8 negatives are AV's that don't scan executable's. If you don't feel comfortable doing so yourself, any .dll you specifically want tested in conjunction with, let me know and I'll do so. Just supply a link.

@Dinos Thank you again for the help. I found the answer I was looking for, the RX plugin does apparently support normals. There's no further explanation in the post, but at least it is a starting point.

 

[Juha_Werx_Team]

Update.

After about 50 real time hours of testing, I can safely conclude that enabling the LAA flag has absolutely no negatives with RBR, including about 2/3's of the competition plugins tested. RSRBR, RBR.Hu plugin's allow it without problem. The Czech plugin, is the only one so far that will not allow the modified executable. RBRWorld, RealRally, etc. haven't been tried yet, due to a lack of drive space available for more installations, but coming soon. I've not spoken with admin's at the Czech forum yet, due to time constraints and the fact that my registration confirmation email was never sent. Likely I'll make another attempt in the near future though.


I've also been tracking the bad performing courses. That one which appears to be bugged in some manner. Undetermined at this point, but it is consuming a huge amount of cpu cycles compared to any other track. My original off the cuff guess was incorrect, but the fact remains that it's performance within margin of error, with or without ENB, and with/without LAA flags set. Consistency of the performance is the same across all methods tried.


The other two, I must admit I overlooked an ENB setting & was doubling anti aliasing, with Edge AA & SMAA injection and Virtual Super Resolution on top, both AA at highest possible settings, resulting in terrible frame rates as one would expect. Disabling the Edge AA fixed the problem for two of the tracks. It should be pointed out that quite a few others have complained about the optimization of that one as well. I know partially where the problem lies, but not the majority of the source. It suffers from a large amount of duplicate texture files mapped to other duplicated meshes all under different file names. Which are certainly unnecessary & inefficient with respect to memory & draw calls, but not the overarching cause.


All of this troubleshooting & testing is however taking away time from the core reason of my project, which is a modernization of the graphics. A large reason behind most that are slowly drifting away, and less new players are being attracted. Which is in a word, pretty much the reason I quit playing back in 2006 too. Modding extends the life span, something everyone here should be intimately familiar with by now. Without a new influx, eventually it's all just going to fade out with no "sim" suitable to replace it.