Occlusion Zone Wishlist


#1

Here’s what may become the most comprehensive feature list on this topic… which seems to date from 2014.
The occlusion zone features would make a lot of things possible (if done well), but above all it would allow creators to offer even richer experiences : Serving some additional HD content only in certain cases (at some point that kind of optimization becomes necessary).

This list talks a lot about “Instances”, we could create with Occlusion Zone. Even if the two subjects are technically very different, we can easily imagine that we could join an instance via an Occlusion Zone instead of using a teleportation hub.
If you’re not familiar with occlusions, please read the “Occlusion Culling” chapter of https://en.wikipedia.org/wiki/Hidden_surface_determination

Occlusion Zone (an editable wishlist) :

  1. First, it will be necessary to understand what an occlusion zone will look like : should it include a waiting room by default ?

  2. A “Welcome Zone” that users would see the first time they visit a domain : It would be visible wherever they teleport. Note : The user’s consent will be required, if this information is used again by other scripts.

  3. Use an occlusion zone as a total privacy zone : Because once the zone is closed, we use P2P communications… And the avatars are transformed into NPC. P2P communications might also reduce server costs.

  4. Who can enter an instance (basic privacy setting)… Because if at some point you own/rent an instance, it’s to be able to choose who you invite. And if someone own/rent an instance, he should be able to allow people to join in only if he’s already inside it.

  5. Basic rules for buying or renting an instance : With a decentralized system, the rules will certainly be more flexible… but there will always be rules.

  6. In an instance, some of the core parameters may differ from what can be seen outside of it : Disable size changes or deactivate scripts use. Instances owners might even have the possibility to choose their own skybox.

  7. Smart management of the instance : If an instance uses an external service, a mechanism should be able to quickly inform the user that something isn’t working (and depending on the error, switch to a fallback solution).

  8. Tricky question : Could some users be allowed to host their instance on their server (so a domain become a hub) ?

  9. On demand based instances : If the instances offer specific features that require more resources, it should be possible to auto-scale the server at this particular time.

  10. It’s just an idea, but since we obviously won’t be able to do everything we want (create invisible malicious entities or become invisible to spy on people), at some point, it will be necessary to think about making a list of good practices.


Some funny tests using Javascript or other techniques, could allow us to see the advantages and limitations of Occlusion Zone (an editable test list) :

  • 1b) Vertex increment (LOD) when entering an occlusion zone : If this can be done in a very simple way, all creators will use it.

  • 2b) Occlusion of some NPC. If someone’s avatar enter an Occlusion Zone and becomes an NPC (with or without playback), this NPC will have to be invisible to people inside the zone.

  • 3b) Clearly inform that an avatar has become a NPC to avoid misunderstanding.

  • 4b) To be able to deactivate a script that is already running, when users enter the zone… Or to be able to warn them that the script will be deactivated in a few seconds.

Let me know what you think ! :sunglasses:


Highfidelity could also be a video game plateforme
#2

After two months thinking about what could be done with “Occlusion Zones”, I have come to the conclusion that instances are mandatory to the success of HiFi… But for rather unexpected reasons, very far from the video game aspect that I had at first.

In this recent blog article, we see clearly how HiFi server could have “one to one” interactions with the user (which is quite normal when we talk about e-commerce).
It’s very interesting, but I’m afraid the way it’s done, will make things really too complicated for designers who would like to create even more sophisticated experiences. The “Not everyone is a programmer” problem is already present, and as things are heading (on the Internet globally), it won’t change anytime soon.

Some people have ideas, but not necessarily the technical skills to bring them to life. So, many will try to learn by themselves, learning from scripts found in the marketplace or on GitHub (and in the end, most of these scripts might do a good job).
But if designers (professionals or not) get into the habit of using these cheap methods, it is likely that they will use them for ALL their projects. Designers will always need to create new content and innovate, if they want their domain to continue to be popular… and since checking the quality of the code always takes a lot of time (too much?)… The amount of old (but not necessarily obsolete) code will increase exponentially. And it could be even worse if some users decides to restore an old version of their domain by mistake.

That’s why it should be possible to create an object that is some sort of container, where designers could put some kind of “mini-domain” :
Once the “mini-domain” created, it would become possible to create templates of it, which could be easily sorted by tags, date, etc… This would make it easier to manage old scripts. But more importantly, such a feature would make it possible to offer turnkey solutions in the marketplace (e-commerce solutions, creative tools or optimization tools).

If we want HighFdelity to be as flexible as the web in a few years, then this feature is essential.

What will happen if we don’t find ANY solution to perfectly organize all our assets in a simple way?
(I suppose migration scripts will appear soon, which shouldn’t encourage creators to regularly overhaul their contents)

In fact, it’s quite ironic because that proliferation of all sorts of “old code” looks strangely similar to what we can see in “The Matrix Reloaded”.
When @philip said a few months ago in the metaverse episode of “Year Million” on National Geographic, that no one could totally control it (thanks to open-source software), I was very happy to hear that … But on second thought, I’m starting to imagine the potential risks : Old scripts (more or less secure) on most servers. Let’s hope we will ensure that this doesn’t become a self-fulfilling prophecy.

If this happens, it will be yet another argument for the supporters of an Internet controlled by big companies. Although some users will still be able to build their own servers, that won’t change the fact that the great majority of them will use the main SAAS providers.

Last but not least,
As the term “instance” is already used in many cases, it would be interesting to agree on a simple definition of this term in HiFi. Talking about subdomain might be too broad, and “mini-domain” or “pocket domain” might sound childish… But in the end it’s also related to marketing. :sunglasses: