stencil portals

[coderofsalvation]

@Bai0. @gunpigew How about a thought experiment about that:

• when clicking a link (room.objects.mylink e.g.) or when <link js_id="mylink" auto_load="true">
• we create a room (lightweight version of load())
• portal.openLink() attaches the room to the portal room.objects.mylink.room = (no scripts are loaded, nothing is rendered)
• we add an update-function to portal.js with if( this.room && this.open && !this.stencil ) this.createStencil()
• when walking into the stencil:
  • load the required assetscripts
  • portal.room.previous = window.room; window.room = portal.room
  • update URL: janusweb.setActiveRoom(url, prevRoom.referrer)

Thoughts? naive? interesting?

Regarding performance: I was thinking of a janusbase attribute skip="portal,vr,ar" to allow JML-entities to hint the renderer of skipping certain objects in certain contexts.
Examples:
<object id="hugemodel" skip="portal"/> would not render that object until the user actually walks into the portal.
<object id="skydome" skip="ar"> would not render if the user is in ar-immersive mode but would render inside a portal and VR
<paragraph skip="ar,vr" text="this space is about john doe who never existed"> would only render inside the portal/stencil (basically a 3D thumbnail)

[jbaicoianu]

Thanks for putting this all into a formal proposal. Some of this logic is already implemented in the portal / <link> class here https://github.com/jbaicoianu/janusweb/blob/master/scripts/portal.js#L346-L517

It currently works by just creating a new room object referencing the new URL, and storing it as this.portalroom. We don't have specific handling to prevent certain objects or scripts from loading, we go through the normal loading process that rooms usually use. This includes loading of scripts - but the script and any objects in the room won't have their update() functions called unless the room is "active".

I like the idea of a tag which specifies "layers" which control visibility in AR, VR, portals, etc. I believe there might be a layer subsystem already implemented, in which case it's mostly a matter of picking a convention and using it.

The more pressing performance issue with seamless portals is that it makes it more important for us to implement logic to automatically close portals and remove the rooms and their assets as you go. In theory if you're using portals to their fullest extent, it's perfectly reasonable to have a portal to a room, with a portal to another room, with a portal to a fourth room, and if they all line up there's no reason you shouldn't be able to render them all. But for this to work well we'll want to do some portal stencil mesh occlusion testing, which we can use to decide whether we need to do any work on that portal or consider it closed. But then when you get "far enough" away from the portal it should be completely ejected from memory - probably need something like an LRU cache of rooms, and a traversal graph to know which ones are "furthest away" from the player, and should be safe to unload.

[coderofsalvation]

Thanks I will do further reading on portal.js, great news that there's already some existing logic in there.
My hope is that this brainstorming will make it a bit easier to reason about together, as it is a feature which probably requires more thinking upfront than coding afterwards.

LRUCache

Just putting this here just as a note:

function LRUCache(capacity, onEvict) {
  let cache = [];
  return (value) => {
    if (value !== undefined) {
      cache.push(value);
      if (cache.length > capacity) {
        onEvict?.(cache.shift());
      }
    } else {
      return [...cache];
    }
  };
}

// Usage:
const lru = LRUCache(2, (room) => room.die() )

lru( window.room );
// walk into next (active room)
lru( window.room );
// walk into next (active room)
lru( window.room ); // cleaning up first room 
console.log(lru()); // [ room, room]

"In theory if you're using portals to their fullest extent, it's perfectly reasonable to have a portal to a room, with a portal to another room, with a portal to a fourth room, and if they all line up there's no reason you shouldn't be able to render them all."

I've noticed with <portal mirror="true"> there's an ability for the world-builder to specify the level of recursion.
Perhaps the LRUCache allows for similar control.