Who would be in favor to open portals between domains?


#1

Domains are very isolated compared to the Second Life grid world of simulators. A way around this to create the sense of an open world compared to these private domains would be the integration of “portals”.

High Fidelity makes usage of three.js and when thinking about ways to link domains like you can link a sim I did find this on Github.

This is the demo: http://zadvorsky.com/projects/portals/

This is not the first time I bump into this concept but adding them to High Fidelity could make things more interesting.

Here is the Github cache for this project.
http://webcache.googleusercontent.com/search?q=cache:0SZmB8xwuFMJ:https://github.com/scenevr/client/issues/12+&cd=6&hl=en&ct=clnk&gl=be

It does belong to scenevr.which is virtual world software also based on three.js I have seen this used before so the concept of portals is nothing new.

The question is if these portals are limited to doorways or can you make them really big at 4 sides of a domain to simulate an open world that consists out of domains.

What if you can make a cluster of 9 domains that have a terrain of 2048 x 2048 metres with portal borders connecting each other?

You get a grid.

These are ideas but feel free to give your input on this.


#2

I Agree. They add to discover ability.

I always wish that at some-point High Fidelity have seamless, see through portals like in JanusVR, where you actually see right through them to another region. This is how you can literally have a Tardis, where a walkin box is actually much, much bigger on the inside.

Portals shouldn’t be limited to just doorways, but should be resizeable to different sizes, however they should, atleast, be limited to 10mx10mx0.01m:
However, they should only be placeable by specific rights, as it could get over abused otherwise.

This way we could even over-use the 16 kilometers of space with cleverly created loops like in Standleys Parable or Antichamber and would open up for fun little domain puzzles.

For now, there are “links” to other domains, but they are not so apparent, because they usually are objects. Forexample there is a phone booth in hq that leads to the sandbox, and there is a toilet in music that leads to cafe, etc and etc.


#3

Thinks once we have all the server stuff working then a single domain would be more than large enough for everyone,They’re not really claustrophobic just for now they don’t handle large crowds so well.I’m told the gta5 map is smaller than a hifi domain.

and didn’t opening portals to other domains traditionally end badly, well in most movies o.o


#4

Well when thinking about this it does provide you with a massive amount of options.

Now you can press Ctrl+L and then type in a domain to get a transfer to another webpage. That is boring period.

The next option is click an object and then the script will teleport you. More practical in use but users need to know how it works, figure it out. Sometimes a user will bump into an object and get a teleport without wanting that. The teleport script is a viable system in games and mmo’s and virtual worlds.

Portals, these portals are indeed interesting, they invite exploration, easy to understand, practical, no thinking required you just use them. It is more easy to walk through a hole in the wall than to figure out where the doorknob is or taking a key to open a door.

My biggest interest in this is the potential solution to a bigger issue, these portals can provide the solution or a solution in generating a seamless connection between domain instances. Instead of a 2 by 2 meter door how about a 16 by 16 kilometer one without a frame.

Suddenly your world made out of instances turns into an open world.

What if you have a roleplay area with castles, houses game areas, terrain, you did build a game community with events, you would be obligated to stuff it all in a single domain and you would run out of resources or get 8 minute load times. What if you use 4 domains and connect them seamless. You solve the load issue. It removes the restriction and limit that a single instance domain gives you.

This could for example make it possible to generate flight simulations, flying fighter jets crossing very large surfaces because with an instance you still have the limitation.

Using boats is another thing.

In theory you could create a grid made out of webpages that is infinite for an extremely low cost when you know you can host 10000 webpages in a single server.

I see no technical reasons why this could not work. It does not exist yet but it should be possible if it can be done with the Second Life grid it should be possible with webgl.

I do know about JanusVr, project quark did also have these portals.


#5

The thing is, domain to domain connection has been mentioned in the past demos. It was removed at some point though.
So the 16km portals aren’t neccessary, but if not they really do have to be locked down to a permissions as all I can think of is a rapidly spinning 16 km portal at the centre of the domain… Scooping up anyone who ends up there…

If I recall they are planning to have stars in the distance as the other neighboring domains registered in the Hifi DNS.

Overall, portals would be a good addition for linking domains at a much smaller distance


#6

I think if you can lift a restriction that is an advantage. I also think in terms of load balancing this can be beneficial to the ones who would or could use such a system.

Also for me personal it would be more easy to work with smaller compartments that allow scaling versus a single larger zone. It is something to think about, I do find portals interesting and the idea of being able to create a grid is fascinating.


#7

Im not sure the domain size is written in stone as such just recently they made them bigger to put the origin in the center. its very possible you could just type a number in somewhere and go even bigger.
I think if you wanted to put all secondlife into one domain as an example subject to having enough server capacity you could do it.
The load balancing and asset servage is prob the end goal of the stack manager. just give em a chance to finish it lol


#8

I where thinking about this some week ago about this too, Possible i think more complex then needed.

It’s nice if same themed sims can join together. but everybody can have there own server. Your worried about resources, High Fidelity is have idea’s to solve that smart. So that’s the last thing i think we need to worry about. Like @judas says, domain sizes are not in stone, the now are already 32x32 sqKM in size. (not 16 km)

But the idea to have neighbors domain’s you can look in and enter with verhicles, makes it much more interesting. Also it seems people still want that. I did some thinking about other idea. I hope i can explain it. It’s just idea and need some better mind’s to work it out.

Everybody is having a domain, right.
Now i got some idea , what if someone could create a Grid, the grid would be something like a HUGH zone, calling it “Grid Zone”. Lets make that zone for example 32768x32768 sqm in size. (green area) In this zone you cannot build.
I think the grid zone is complete useless in my idea, it possible can be done without too. but i seee a grid zone like a sim, and the domain zone as parcel.

But to greate a grid zone add extra security. So the grid zone owner can say it’s not allowed to attach other grid zones next to mine. or Look in my grid zone from other is not allowed. And offcorse the grid zone owner need to add who can join the grid zone.

But instead this setup you could just have a grid zone with only your domain inside ?

Into that grid you can assign, new zones. 1,2,3,4 etc. in this example one domain zone would be 8192x8192sqm. But why not make it customizable :smile:

The new zones (call it domain zone) named 1,2,3,4 can be assigned to other domains. So every zone is a new server the user can run by itself. or a server that people rent from someone else.

So as example,

  1. Simsquare domain
  2. Shop domain
  3. Earth domain
  4. Ride domain

So it would look like this.

Now the technical part, All domains inside the grid zone can see each other. you can also walk from one domain zone to other domain zone. With this idea everybody can have it’s own server, but still stick together. If the grid zone would dissapear. you not lose yoor own creation because that is running on it’s own domain. Servers in a grid zone always share server resources with other servers in the same grid zone. still domain zone can set off corse some limitations etc.

But now we still need to have the option that people could fly from grid zone to grid zone or see in each other grid zone. :open_mouth:

Correction:

A grid domain use the resources from other domain zones.
Because the grid zone need to have some content outside the domain zones. examples are Water ways, Roads so the grid zone contains some infrastructure.


#9

Thoughts on portals:

Because HiFi does not rely on a central asset server the way SL and OS do, the bottleneck for assets are mostly just the Interface user’s download speed and video card.

Setting up domains in grids visible to each other would not decrease load times and in fact, would increase them because instead of getting the entity URLs from the domain you are in, they would have to first be fetched from the other domain.

A simple example is: 9 empty domains each with one avatar walking around. For a non grid setup the bandwidth required by one avatar is X. Depending on the draw distance, for a portal grid setup like SL, the bandwidth required can be as much as 18X.

And this in not just for asset loading, but applies to everything that moves or changes over time in two directions, both into the domain and out to the domains near it. Even a simple bidirectional one axis portal requires 4X.

Another issue is just the fact that at 32km * 32km, even placing terrain and low poly plants, trees, rocks and water, with enough detail to be interesting quickly adds up to 100’s of thousands of triangles and can easily become the limiting factor here.

Now for my own idea about seamless teleportation:

One thing that comes to mind that may help is what I will call “teleport persistent entity pairs”. These could be sets of entities that would be deployed in pairs, one set at the place an avatar was leaving and another set that is at the place the avatar is teleporting to.

In use, the avatar would see the first set while teleporting and arriving and then after the other set had loaded and/or a timeout had elapsed, the first set would be discarded in the same video frame update as the second set became visible.

If used in a way where these entities were the only things visible on the domain to an avatar (a hallway in a building, a path through a forest, road in a valley, or in a cave, etc.) the effect would be a seamless transition from one place to another.

While I can understand the need for some sort of portal system, I myself don’t want the overhead involved in trying to set HiFi up like SL and OS. And as far as load balancing goes, if assignment clients work as they should, it should not be an issue.


#10

In one of the meetups that Phillip visited, we asked that question of portals, especially portals in which you could see into the destination. Phillip suggested that HF might be able do some form of real-time stereo imaging of a spot so that the portal would be able to show the scene on the other side.

This was not a hard commit, but it definitely was not dismissed. I think we could have high quality portals.

The issue of having domains abut each other spatially brings in lot of real-time issues where quite a lot of communications has to take place to create the verisimilitude of seamless connected spaces. A ton of state needs cross between the domains.


#11

What you have at the moment is a collection of spheres with content in them. You know when you go to a domain you are in a sphere, you fly around a bit watching the content, then you have seen it all and you are done. Then you can visit another sphere and repeat what you just did. That is why gamers do not like instances. Ask a gamer, do you want an open world or an instance based world. Gamers want open worlds.

When you come to High Fidelity and you are in a domain, you fly and explore and then after a while you start to wonder the following. Where does this thing stop, am I being tricked here? Then you keep going for 5 hours, you meet people discover places. That is when it gets interesting and that is when you get an actual world.

You had Cloudparty, to me that is not a virtual world they are spheres or scenes to explore.

The usage of grids or portals would never become an obligation to anyone but a feature like being able to buy extra resources for your domain is a feature.

Ricardus also makes the point of: I would find it cool to link up with my friends or with other people. 5 friends have a domain so it would be cool to them to link them up. They all are independent, do what they like in their domain but their friends are next door. This is completely different to seeing your friend is online on your friends list.

This image shows you sizes of game worlds or maps.

World of Warcraft is 64 square miles or 108 square kilometers so you would need 9 domains of 32 by 32 K for the World Of Warcraft map and you would still be short. This image also shows you that newer games use larger world sizes so in the future they can keep increasing in size. Then where will you be with your little sphere? You will be outdated, the importance of being able to scale infinite should be looked at if you ask me for various reasons.


#12

“What you have at the moment is a collection of spheres with content in them”. that describes the universe.
universe not goodenough for ya?


#13

HiFi domains are cubes not spheres and yes the content here is small so far but not because anyone has hit any limits on what can be done. One thing you should understand is that HiFi is still in the alpha stage, in other words, basic things can change here at any time which puts a damper on the time that people or companies will spend making content here.

And yes, the overhead of portals would become an obligation in many ways, even if only tests in the code to see if portals were enabled, and also allocation of resources to say nothing of the development costs and time spent on it.

Right now in HiFi you can set up 5 SL or OS sims worth of space on one domain and host your friends for free.

And as far as I know WOW, GTA and most if not all others still are “scenes” but hidden from the user by various means. Unless something has changed, in the versions of those games I’ve played, all were broken up into levels that you had to wait to load assets to access the next level or area.

In GTA a scene consists of an island or neighborhood and you only see the other areas in the background. Once you unlock the next level you can proceed to it after waiting for it to load, but then the previous level is rendered in the background and crossing from one to the other still requires changing what is cached on your machine.

Also, in HiFi you have 32km of height to use, so the WOW map would take 10 levels if you limited the level height to 3200m or 2 miles, but the reason things are broken up into levels on WOW and GTA is because at current tech 16 bit position values are the norm for consumer 3d. In other words, you can not show more than that at one time.

I guess the main thing I am trying to say is that HiFi is trying to be a framework… a
platform … to make what ever you want. I just am trying to state reasons why it may
not seem to be what you want now.


#14

As per my initial post I did bring this up as an idea. I see benefits in this idea. I did post this in here to hear what others are thinking.

My main reasoning behind this is: Would it not be interesting when you can seamless connect html5 webpages or domains in this case and what could be the result of this. Would it allow to do new things, would it allow to make certain aspects in virtual worlds better than they exist today?

I think about infinite sailable oceans or infinite flying space IF desired.

I view portals as 3D Iframes, Iframes show practical use on the 2D web.

For me personal the idea of not being restricted in space + the social aspect of this and social benefits it can offer make it worth to explore. That is why the thread is posted as a question to ask what people think. Like with all ideas some will be positive about and some will be negative which is fine.

When nobody provides input or makes suggestions or comes up with ideas everything will remain pretty stale.

The ideas of the Alphas is to give input correct?


#15

4096 256x256 regions


#16

And correction yeah @Richardus.Raymaker was correct, even I keep forgetting its actually 32 km x 32 km, not 16 km like it used to be.

I think your math is abit off here… With the Classical World of Warcraft, Kalimdor was stated to be 21 km long. Using that its estimated the world of azeroth is estimated is 50 km x 50 km, of which only half is usable by players, or rounded 25x25.

Technically speaking this is still dwarfed by hifis 32 km x 32 km = 1024 sq km. It would, as @Balpien​_​​Hammere pointed out be equal to , or a grid of 64x64, or 4096 sims (if equal to 256 m x 256 m per sim) in SL terms.

Just Cause 2 is the larger than Hifi domain however.


However processing power is another matter, and its highly doubtful that 32km x 32km domain can be hosted in a single server, especially if popular.

So it would most likely have multiple servers to handle sectors, more for handling user data. This means that there would be instances (even wow has state base instances nowdays), but all mmos usually are developed around them, but with clever trickery it can be masked.

There is some ground work to this already been done, but we have to wait and see how it develops:

Now to address some of other things you mentioned:

  • Bottlenecks are actually: The capabilities of client, and the servers involved.
  • Physics are p2p, so clients abilities handle that (thought there might be an authoring assignment client on server)
  • LOD Throttling and culling handles all the assets loading/unloading and same thing with polygons. If they are far enough compared to the player’s computing abilities, stuff simply wont render/load. This has been proved to work rather aggressively to date. Especially on systems below the minimum, where nothing renders. However its been proven even few million of triangles in a scene do not pose an too much of an issue if lod levels have been applied per object

So in summary, its important to distinguish the difference between a domain and a server: Domain has multiple servers, while a server belong to a domain. However domain can contain another domain, or be neighbored to another domain (once they work that out)

What portals would do is link domains together, be it see through to other domain, or not. They add to discoverability, so an aim for a seamless transition between domains, as Janus has between pages, would be absolutely lovely.

@Balpien​_​​Hammere: I still think links to other domains should be handled on the client side, so if a “portal” is made and its points to another domain, or another part of the domain, the client should handle it as if it is connected/seeing into the area. It shouldn’t need the server to know anything about the link to the other domain or part at all, as in JanusVR, other than a that a portal exists as an entity. This should eliminate the issue of worrying about the servers handling stuff. This way its much simpler to have the client connected to multiple domains as an “observer”, than have servers communication positions of multiple clients with each other.


#17

I’m in favour of ultimately being able to define zones in a ‘meta-domain’ where each zone points to an independently hosted ‘sub-domain’. Same sort of rules of present zones apply regarding precedence.

Means you could then lay out a square land grid, 3d apartment building grid, or go completely arbitrary in size/placement of each element, to suit oneself.

Possibly allow the ‘meta-domain’ to be much larger dimensionally at the expense of lower object placement precision (eg, 1m resolution).


#18

@leaMing , what you say is what i try to explain in my post. If i understand yours right.
The sub-domain can run on different server. So if peoplke like the can run ther eown server but still be CONNECTED to a bigger place.

Other thing, people seems to get pretty confused about.

Server instances, if people hear that the start to run around and yelling OMG.
People think when the read , when more then 40 people are on domain a new server instance get started. and the think that new people get placed on copy of the same domain. but seperated from the other master domain.

Now i hope am right, but for me a server instance just means extra resource get add to a domain, but people still see each other. it’s how cloud based systems work.


#19

This important to reiterate. Unlike the legacy SL and SL-style OpenSim grids and variants, where a single server simulates a scene (usually a fixed virtual space), domains, also defining a scene, are designed to be simulated by one or more servers. So, yes, you could have an enormous space simulated under one server. Should the activities in that domain rise to swamp the server, additional servers could be assigned to handle the high load.

Not all of this implemented yet but it is part of the HF architecture.


#20

We need portals for virtual reality community building, not because of limitations due to land size. As a practical matter a community domain will divide its land into parcels owned by various people much as is done in Second Life. When a piece of land is surrounded by others it can no longer expand except by using portals.

Thus a castle at the center of a kingdom among many other kingdoms could expand by adding rooms, gardens, etc. A cave could be used as an opening into a previously hidden valley and so on. While all this great technology is being developed for virtual reality the real challenge is how to develop the next generation of virtual reality communities (beyond that of second life). A niche seems to exist between social media like Facebook and MMORPGs that is just waiting to be filled.