The Great Renumbering Plan

[Jojon]

So we will also rename all files and the elements (objects, materials, etc) they contain, to reflect the shells' page numbers, rather than their "addresses", did I get that right?

No - we'll keep the shell numbers the same. Think of the shell number as your street address, and think of the page number as some annoying behind-the-scenes attribute that's unrelated.

Ah, good. It struck me as a pointless and confusing change - glad to hear that was just me misunderstanding. :)

Oh and about the range of "static" pages: do we apply to have one of these assigned to us (..or have one assigned through a predefined layout scheme), for development use and then the administarators merge any content sharing page, upon submission/release, or what? :7

Apply for one of these. We'll dish them out on a first-come, first serve basis. I'll add another Wiki table for these. Right now, Marcello has 11. Which one would you like, Jojon?

[EDIT: added sign-up table here]

Ha-HAH! Number 12 is mine, all mine, muahahaha-eh-heh--ehrmmh......

We'll see whether the day comes at all, when we run out of these and deal with it then, I suppose. :)

[Paradox]

All this dynamic paging reminds me... is there any plan to use Paradox' system at some point, i.e. vis regions and occluders instead of all this python code?

In a perfect world, sure... it definitely makes things easier to organise and makes playing the Age a bit nicer.
However, it might also render the Age unplayable.

Essentially, we would like Pahts to run acceptably on the minimum hardware specifications for PotS. The fear is that as the city grows, it will take up more memory and become unplayable for people on older machines.

I've mentioned before that I really hate the paging scheme because of the extra work it adds and the delays it causes while paging in. But the alternative might be the sum of those delays upon link-in.

[Aloys]

I'd say that's a flaw in the fundamental concept of the Age, but heh, it's not like we can change it now..
A while ago, during my 'great rush of work of 2008', as a performance test I had added a ballpark estimation of random polygons and textures to the Age of what I estimated the new courtyards to represent (5000 poly per courtyard + 20 megs of textures). And the result wasn't pretty.. Performance was pretty bad, but the loading time was downright terrible..

[Robert The Rebuilder]

If only Plasma had a threaded LOD/paging capability similar to Second Life. Then you wouldn't notice any interruption in frame rate. [Yet another thing to add to the growing open source TODO list...]

[EDIT] I just found out that shell 223 needs to be renumbered to page 173. Currently, when loaded, it comes across with a page number of -33. I updated all the earlier posts to reflect this.

[diafero]

IIRC, The negative numbers are caused by libHSPlasma using a signed value for the page number (and the prefix) - because textures and BuiltIn have IDs of -1 and -2. However, as long as you keep 254 and 255 free, it should be more convenient to treat the numbers as unsigned values. The difference is just in what the application uses to write/read the numbers from a file or display them on screen.

[Robert The Rebuilder]

I had an idea, regarding the paging... I could add an SDL variable to Ahra Pahts that controlled whether or not to use paging. If the variable was set to false (or 0), then it would page in everything upon first arriving at the age, and everything would stay in memory the whole time. By default, paging will be active. But it would be simple for people to turn it off - especially those with Alcugs servers

Would that be useful?

Note: there will be a performance lag whenever the view frustum intersects a large number of shells - especially completed shells. Not to mention that people with low-end systems (i.e. system memory <= 512 MB) wouldn't be able to visit the age with paging disabled. But as we well know, there ain't no such thing as a free lunch.

[Aloys]

That sound like a good flexible system.
But in order to really improve perfmance we will need to implement visregions, right?
The Age layout have been designed with this in mind (district walls, buffer zones etc), so it is possible but then we have to actually do it.. And that looks like a lot of work. (not to mention that we need the final assets..)

[Egon]

Just a wild idea: all object have already a page_num assigned.

Isn't introducing visergions just a mater of properly builded script, which will assign an object to vissregion, depending on the page_num of the object?

[Aloys]

That sound like a good idea. Or at least a good starting point. That might seriously limit the amount of manual Alcscript editing.

[Paradox]

The city file I uploaded (in a different thread? It's somewhere around here ) has softvolume region objects for each shell. These regions could be used to hide objects until the avatar is inside the shell.

The visregions can then be constructed as follows:

Code: Select all

410DeskInsideHouse:
    visual:
        visregions:
          - svintersect:pahtsShell410Vol@city

This might require some changes to the trunk PyPRP, and probably an import of my city blend file (to define the region objects).

Basically what I'm saying is that all of the shell visregions can be defined in the city page, and then referenced by the shells; rather than requiring builders to create visregions in their own shell files. I also started (but probably didn't finish) visRegions for the districts that could be used for the shell walls, or anything that should be visible from the street when standing outside the shell.