Subdistrict Paging For Ahra Pahts

[Robert The Rebuilder]

For this paging prototype, I'm taking you all to the future. The file size of this version is approximately what the final version of Ahra Pahts will be - with every shell completed. This way, you can judge for yourself how well this mechanism fares against the real thing.

This time, I've followed Nadnerb's suggestion to page in portions of each district (or subdistrict) ahead of where you're going, so that there is no "popping" of geometry into view. As you cross the threshold between subdistricts, the geometry that is two subdistricts behind you is paged out, and the geometry that is two subdistricts ahead of you is paged in. Look at Figure 1 for an example.

Figure 1 Show Spoiler

Pages_Walk.gif (86.18 KiB) Viewed 6180 times

While the geometry pages out/in, there is a noticable pause. The largest pause happens when entering the middle subdistrict of each district, because it is paging in two subdistricts instead of just one.

The total file size of this age is about 1 GB. (Luckily, it compresses to just 12.5 MB.) Each shell PRP is 5.6 MB, and each subdistrict PRP is 11.5 MB. When the PRPs are loaded into memory, it tends to double in size. So, if no geometry is paged out, the age will take up 2 GB of memory (in addition to the 200 MB that Uru takes up with no ages loaded, and the other 200 MB that the OS takes up).

To try it out for yourself, first clear out all LinkTest01 files from your Uru install. [Easy way: right-click on Uru folder and choose Search..., then enter LinkTest01, then select all the files it found and hit the delete key.]

Then download the prototype:
LinkTest01_subdistrict.zip (12.5 MB)

Alternatively, you can view the video of a walkthrough from the southernmost subdistrict to the central district (i.e. the top row of Figure 1):
PahtsSubdistrictPaging.wmv (12.8MB)

Let me know if you can live with this solution.

[Grogyan]

Love your signs sayin

Show Spoiler

Got RAM?

[Paradox]

That certainly seems to be the best solution.

I still think that we should load entire districts during if they are linked to from the Nexus. That saves people from the pause later, and the screen is already black during the fake link so it shouldn't be an issue.

[Nadnerb]

Perfectly acceptable load times here. You might want to move the page regions closer to the centers of the transition points, when the paging is on the exit side of the transition points, you can see the next district as it pages in. However, as a proof of concept, it works perfectly.

[Aloys]

You have no idea how great this feels to see this system work! The very short loading time, the great framerate, the low memory footprint. This is just wonderful.. This trully lifts a heavy fog of worryness from my horizon.. Together with the visregions, this will allow large Ages to become possible.. (Just for fun, once version 1 is released I should spend the time to do a video with one of my unreleased versions just to show you the horrible loading times and performance )
And even medium-sized Ages should benefit from this as it will allow for more detail.. For instance I can't imagine fully loading in memory an Age like Kemo.. Although it is small it is very detailed and the performance on many computers would be awfull. But now such level of detail becomes possible.

Now of course that reminds me that I totally forgot to reply to your PM.. Shame on me..
To answer it: right now the subdistricts range from 4 megabytes to over 15 ( ), but that's because: 1) I have textures in those PRPs that should only be in the main texture PRP; just a bit of mess I haven't cleaned up yet and 2) I haven't taken the time yet to do a 'release' export and compress the textures.. When all of that is done the files should be much lighter, and loading them should be a snap.
So for now your >11 megs test districts are an interesting approximation, as it is a bit of a 'worst case scenario' and it works very decently. (However I don't understand why your shells her weights over 5 megs each.. surely that ain't your new special texture? )

[Ehren]

How would this work for the linking hub area? With so many books going to so many intersections isn't that going to be a major pain to get to work? Other then that though this seems like a really good idea since the paths connecting the areas are pretty thin too, so there shouldn't be worry about skipping past the loading area by mistake.

Also the first loading of the age was a lot faster this way.

[Robert The Rebuilder]

Paradox: That's a good idea, and it should be possible. I'll need to add a bookkeeping mechanism that tracks which subdistricts are already paged in; I've found that calling PtPageInNode() on an already loaded node causes a crash. Once that's in place, that will prevent the game from crashing when the player triggers a reload when walking into another subdistrict.

Nadnerb: Good point about the regions.

Aloys: Thanks for verifying the page size. Note that, in the new plugin, "Generate Release" no longer is responsible for compressing the textures. That's now handled by toggling on the "INTERPOL" button on the Texture properties. Oh - and the shell size is due to that seemingly innocuous texture; it is 1024x1024 uncompressed with mipmaps. That was an easy way to provide the approximate size.

Ehren: I already have a paging version of Prin Pahts (the "linking hub area"). The way it works is that the linking points and a small patch of collidable floor underneath them will always be in memory. So, when using a Prin Pahts linking book, it first warps the player to the linking point (and on the floor patch); it then pages in the visible geometry.

My next version of the prototype will include Prin Pahts, plus the modifications suggested by Paradox and Nadnerb above. After that, it will be ready to incorporate into the real Ahra Pahts. Stay tuned!

[Robert The Rebuilder]

Here is the final prototype. It includes Prin Pahts and the city linking books/pedestals/cameras/regions/spawn points. I've incorporated suggestions from Nadnerb and Paradox, with one exception: in order to keep the maximum memory footprint from exceeding 4 subdistricts, I do not page in the entire district when linking in to a subdistrict adjacent to another district.

To try it yourself, first clear out all LinkTest01 files from your Uru install. [Easy way: right-click on Uru folder and choose Search..., then enter LinkTest01, then select all the files it found and hit the delete key.]

Then download the prototype:

LinkTest01_subdistrict2.zip (21.14 MB)

Note: this age will decompress to a total size of 1 GB.

Alternatively, you can view the video of walking from District 4 to District 1, linking to Prin Pahts, then linking to the top of the Hub:
PahtsSubdistrictPaging2.wmv(8.5 MB)

With this prototype, the mechanism is ready to incorporate into Ahra Pahts. Aloys: let me know if you want to discuss the details here on the forum, or via PM.

[Nadnerb]

It works well when it works, but it seems to be missing transition regions between shells 408 and 117. Nothing is paged in or out when crossing this boundary, leaving a cliff into nowhere at the start of the first green subdistrict. However, I can link to that subdistrict via the nexus, but it will not page out when I cross over the mentioned boundary.

[Ehren]

Yeah, I hate to say it but it isn't working very well for me, I am coming up to the "edge of the world" a lot (without using flymode or even Prin). For example it doesn't seem to work walking between the blue district and the part of the white district with your shell 111 (where it WOULD be that is).

Maybe the city should just be blocked more, so that you can't see past the big walls and HAVE to use Prins or a special gate to get from different colored districts? Like putting a big solid gate in those gaps in the connecting area of the triangles? Then the whole white, blue, green, and red areas would be switched out all at once? And you wouldn't have to worry about adding so many barriers to have those spots always appearing before you get to them.

Those gates could be like one of those eairlier link tests you did, where one opens, then closes then opens on the other side after paging in an area (and screen fade in and out), that would be a lot more simple right? And I don't think having to wait for one thing to close and another to open would take away that much (just at district walls, not subdistricts I mean)

Basically what I'm trying to say is the gates would be there to block visablity so you don't see the area behind it isn't really there, so that you also don't have to worry about getting an area to appear BEFORE you even get to it. It wouldn't have to be a long tunnel or anything just two gates or doors.

This is all suggestion though, swear I'm not trying to be demanding, just wanted to give that idea, however poorly I explained it...