Visibility zones first?


I’ve just watched this:

Interesting discussion about the ability to connect domains within a domain.

I think this is the way to go for many good reasons.
This could allow large worlds. It’s a good solution to allow many people to build in a same world with a lot of freedom, allowing people to exist between the linked domains, walking and taking in the parent domain.
This could give to HF a serious advantage over the other platforms that might not be able to follow us on that move.

But this won’t solve the problem that we have a limit on what we can render about the number of polygons. (and I won’t talk about the download time which is not really a technical limit but a limit in “human patience”.)
This limit will still be there even with those nested domains. That’s why I think we would need “visibility zones” before “hierarchic domains”.

I think we need to be able to have entities configurable to be “visible” or “not visible” from outside a specific zone.
This would allow seeing some structures from far away without having to load the secondary objects that are inside of it.
Considering that the sum of all the small objects of a living room can be as rich in polygons and textures than a whole island’s landscape, there is a serious benefit to not render those objects when you are outside of the house.

This kind of optimization could make a huge difference. I think this is needed for the single domain use case. (and certainly even more needed for the hierarchical domain use case.)


I know someone had worked on something like this using Overlays, since that’d be the only way to create the illusion of what you are talking about.

I think the easiest way of getting it to work would be the following:

  1. A new zone property that allows objects within the zone to be visible/invisible when not in said zone.
  2. A new zone property that allows linking to other zones of which the visible/invisible property is carried over (ie: Zone A has objects that users in Zone B can see as though they were in Zone A).
  3. A new entity property that supersedes the zone property to be visible at all times, even if a zone has the rule to make objects visible/invisible that are within itself.
  4. A new entity visibility property that allows a client to hide/show an object that only effects their own visibility. This is so scripts can still perform the same illusion in their own controlled manor (and could open up a doorway to some interesting tricks).

This could then be carried over as a property to the hierachic domain zones.

Another thing that could help loading of the hierachic domain zones was the mentioning of using voxel data instead of model data. This could save bandwidth greatly, improve loading times, and act as a means of LOD control on a great scale. For larger items, this may not work 100%, but it could be an option for domain operators to offer this information to help keep things low cost.


I know this post is 6 weeks old but IMO it’s a very important topic.
This is a long term problem/project but it’s not as long term as one could think.

Looking at OrbusVR (possibly the first VR MMO) I see it peaking at around 150 concurrent players even though it’s only available on PC and it’s very early access.

One can easily imagine the number going up by more than an order of magnitude if/when the game is released and is possibly available on the Oculus Quest.

I’ve been thinking a lot recently about MMOs within virtual worlds… @FlameSoulis describes a reasonable path to bodge this feature using existing features.

Longer term there needs to be specific client-server logic to handle this and features like instancing and so on.

Last but not least I’d like to point out MMOs have been a very solid source of revenue on every platform so far and should be so in VR as well. In fact in VR some aspects of monetization in MMOs may be amplified, for example the need for player houses, more personalised avatars, more personalised everything.