Just spending a lazy Sunday afternoon lost in thought. This is not a feature request, but simply my thoughts on the above topic and an invitation for others’ thoughts.
I am thinking about how different domains may link together in physical space (meta-space?) and there are a number of things that pop out of my head, somewhat randomly!
Grid. Be it a 2D grid (such as in SL/OS) or a 3D grid, this is the simplest idea, but also probably the most limiting. Each domain is already defined at a maximum size of 16384m3 so spacing them out at this distance on a regular grid is an obvious approach. However 16km is a lot of world to fill! This approach would mean high-density spacing of domains is impossible. Incidental: the current positive-only coordinate system lends itself to this approach.
Arbitrary Coarse-grained placement. This is my preference. A meta-space is defined to some coarse grain (say, 1m resolution) and domains can place themselves at any coordinate in that domain. Assuming a 32bit coordinate system with 1m resolution, that is an awful lot of space, which is good. It overcomes the ‘standard sea-level’ issue as someone who needs a sea-level of 4000m can place themselves 3900m ‘below’ an adjoining domain that only wants a 100m sea level.
This also allows domains to overlap (including having small domains inside the space of larger ones - eg a private unit in a larger apartment building). So - access permitting - a user will see objects from both domains served to them if they are in an overlap area. If placing an object in such a space where both spaces are write permissive, the user would choose the host domain for that object from a drop-down at resource upload/creation time. Spatially overlapping two domains would require some sort of formal negotiation, probably with the first to claim a location granting permissions for others wishing to overlap on that space. All the usual humans-living-together caveats apply!
Variable-sized/resolution domains. Related to above is this idea. Instead of having domain sizes fixed at 16384m3, an ability to scale up or down, sacrificing/gaining entity placement resolution within the domain. This idea is that under-the-hood, the domain’s dimensions don’t change, but if you only need 64m3 for your domain, you can set your physical extent at 64m, and everything you see scales accordingly. At the other end, you might define a physical range of, say 256km, in which the scaling is at the other end, losing precision placement of objects (less digits after the decimal point) in return for the larger area.
Basically the domain doesn’t use metres any more, but ‘units’ (which by default are 1m). A scaling factor is automatically applied in the numbers shown in the UI, entity importers, API, etc. so that the size of an entity works the same irrespective of the underlying scaling factor.
Use case of the above 2. Eg: Set up a physically huge domain, at 1024km3 holding a relatively low-resolution terrain. People then place their own higher-resolution domains on it, overlaying more detailed terrain as appropriate, and objects. One of these objects may be a shopping centre, providing a plaza for people to meet in, plus the shells for shops, in which physically small domains can be fitted.
Aside: Coordinate systems. Presently HF uses positive-only coordinates with the origin in one corner. I must admit I like a centred origin with movement either side of zero. There is no programmatic or performance advantage of either way over the other (two’s-compliment integers are no better/worse than unsigned integers from the CPU’s perspective). Probably because I personally like to build from centre-out is the only reason for my preference.
I do feel that a centre-origin is more useful if arbitrary-sized domains were to be used. Makes resizing a domain easier - for example, my present domain uses 1km3. If I wanted to grow that to use 4km3, with the same centre, I have to translate everything (including centre-of-domain-referencing scripts) by 3072m on every axis. Not a biggie and can be worked around with global variables for things like centre-of-domain, however. And of course people who prefer to only work in positive-coordinates could just define their domain extent as double what they need and ignore everything negative of the origin.
Okay, enough rambling for now.