Anyone know the function responsible for re-rendering terrain?

[Azarchius]

Hi,

Some values in ObjectMgr I've noticed take effect right away if I were to change them (for example, changing opacity in descriptors immediately displays). Other values, such as displayid in the object's cache, though, does not take effect. Presumably because it's just a reference for what displayid is being used, rather than the value actually used for rendering. I would no doubt need to pass the object through some kind of M2Model::Render function (or something) to have it update.

The same appears to be true for ADTs--WoW seems to load them from CASC on demand, and then keep them in memory presumably for future use, but not for any immediate rendering needs (From my brief investigation). For example, attempting to wipe the MTEX chunk doesn't seem to do anything, and relogging, or teleporting five thousand feet forward and then backwards causes any changes in memory to be undone. Clearly, this is just a cache.

So I was wondering, does anyone know how would I reload terrain? I can hook the ADTs as they load and modify them there, but I'd greatly prefer if I could change the ADT and force it to reload without requiring the user to relog. I work in Legion 26972, but if anyone could give me a lead for any WoW version, or has a clue where this could be, that could at least get me started!

Thanks!

[Jadd]

I had the function a very long time ago, but I wouldn't know where to look in my old projects. IIRC I found it by looking at the gxRestart console command. There should be a function within that you can call to invalidate the terrain geometry without actually recreating the graphics device.

[Azarchius]

I had the function a very long time ago, but I wouldn't know where to look in my old projects. IIRC I found it by looking at the gxRestart console command. There should be a function within that you can call to invalidate the terrain geometry without actually recreating the graphics device.

Thank you so much for the reply! I'll post the results of my investigation when I'm done, at least for 26972.

[Azarchius]

423BC0 (called by 422BC0, which is gxrestart) is the sole function responsible for reloading terrain geometry in 26972's gxrestart. I'm looking closer at perhaps whether it might be possible to reload only a specific ADT, rather than all of them (as it's quite laggy at present).

Great place to start though!

Edit: On closer inspection, I think 423BC0 may be CreateGxDevice. If it's possible to reload geometry without running this entire function, I can't say, but I'll continue looking. I only know that of all functions in 422BC0, 423BC0 is the only relevant function as far as reloading terrain geometry goes.

Edit2: I am pretty confident this function destroys the gxDevice and recreates it. If this is really CreateGxDevice, there isn't much hope of reloading a specific chunk with this.

Edit3: Looking at the 15662 Mac binary, the only suspect function (looking at names) is TextureNotifyGxRestart, which I don't think is being directly called in gxRestart in 26972 (it's 'texture' too, so little hope with that). It would instead appear that what I took for CreateGxDevice may be some function which does some of what gxRestart used to do directly. Maybe? It seems like some sort of hybrid between ValidateFormatMonitor and CreateGxDevice, at any rate. gxrestart ends with running SetWindowTitle and some other function (two in all), whereas the Mac binary calls three (TextureNotifyGxRestart among them).

Edit4: Still, I think that it's quite likely that if I go deep enough, I'll eventually find some function whose job is invalidating the terrain geometry. It must be somewhere down the hierarchy of a function called by CreateGxDevice (or whatever 423BC0 is). My guesses regarding the calls made by gxRestart are, in order, as CgxFormat, BuildRequestFormat, AdapterMonitorModes, ValidateFormatMonitor, CreateGxDevice, ConsoleWrite, CVar::Set, CVar::Set, CreateGxDevice, ConsoleWrite, CVar::Set, CVar::Set, CreateGxDevice, irrelevant (a single mov that retrieves something from offset, doesn't set or call anything), SetWindowTitle, ReportDeviceCreationFailure, Quit

[Azarchius]

2019-12-20_21-43-04.mp4 - Streamable

To anyone who cares: While I've yet to find any way to force the game to reload all values from memory (which may yet be impossible--for example, I can't find the main .wdt anywhere in memory?), a very easy trick to force the game to reload ADTs is by invalidating the map.

I've found a table which after quite some digging I believe to be CWorldScene::s_worldMapList, located at offset 1845110. At offset 290 from the start of the list, there are several pairs of identical integers which are constantly being refreshed in memory. Modifying the value at +290 to any value greater than what it's supposed to be triggers something that invalidates all chunks from what I can gather. This eventually triggers function CMapArea::PrepareRenderChunk (CD3B50), called by CMapArea::Update (CD4130), a few times, which causes all textures, geometry, and doodads (in other words--so far everything I've checked) to reload from file. Surprisingly, CMapArea::Update does under certain conditions call CMapArea::PurgeRenderChunk, but I have found myself incapable of triggering it without crashing the game. Sending terrain swaps, relogging, moving maps and such doesn't seem to trigger it. Something else is causing a purge, hitting the entire map instead of just one lonely chunk. Still, as you can see--it's very fast.

Noggit enthusiasts may find this useful in order to reload their maps without requiring a relog. Sadly, it's not really what I'm looking for, so my search continues. Additionally, I'm not sure if the data is being purged from the client in a safe way by doing this, so there may be a very slight memory leak (from my tests it requires tens of thousands of such calls to cause the client to crash due to memory issues).