"Portals" proposal - Discuss

Where does the money come from for the extra hardware? (The 'land' will need processor cycles as well as the 'sim' its attached to.)

Another downside is the increased network traffic when a resident transitions between 'sim' and 'land' (or 'land' and 'land'), over and above the current 'sim' to 'sim' transitions.

Portals also make hidden face culling much easier when they are used extensively in the rendering engine (this is called "portal rendering", eh). Considering SL cannot precalculate culling, this might give a fps boost as well

Which is why the "private space" proposal uses currently un-used coordinates in the existing sim. It's basically a skybox underground with script-conrolled access.

Linden Labs could even charge a fee for setting it up, create a new money sink for the economy.

There's likely less network traffic at least from neighbouring sims. The transition would be no different to a normal teleport, and you already have no control over the number of TPs at any given time.


The actual processing should'nt be much more or less than it is currently. In fact it's likely to be less as there's no need to worry about other agents or scripts in the sim and all the constant checks that need to be made on them. The portal space could run as a simple process, it doesn't require extra hardware.

If I'm standing on a plot in a sim, data about me is sent to every other agent in the sim, if I'm in a portal space it isn't. And no need for me to know about agents that are not in the portal. That in itself is a significant reduction in traffic and processing.

And if there's no other agents in the sim it makes no difference! So really, properly implemented portal space is a win win situation.

I'm not against a Private Space proposal, but please discuss it in it's own thread.
This thread is for discussing the implementation of portal space. I don't want it hijacked, not that you are, but it could go that way. Please keep on topic. Discussion of pro's and cons is fine, please don't compare with other proposals other than to provide a link to a discussion thread. This isn't a competition

Portal rendering (in the sense you describe) is best when a fixed or static architecture is being rendered. It uses a special tree structure to store vertex and visibility data but unfortunately it must be precalculated and it's a very complex calculation and there's the rub within SL. It does provide massive efficiency boost when dealing with lots of rooms with doors and windows which need to be rendered in the correct order but I'm not sure how it would help very much here as my definition of "portal space" is not suggesting any change to SLs dynamics.

My use of the word Portal, really only means a "gate" from main grid to seperate space. However I believe there would be a big FPS improvement simply because in the portal space there is no requirement to draw neighbouring builds which is yet another processing reduction on the client side and a network traffic reduction on the server side.

"Portals could be a method to enable disconnection of land parcels from the main grid".

That's the bit I'm talking about. Whether you get there through a see-through portal or through a script calling llTeleportAgent() is irrelevant. And, really, however it's implemented the landowner should be able to hand out landmarks for it or teleport you there.

Anyway... there's no reason to disconnect parcels from the grid to create a private space... the grid's got lots of coordinate space unused that could be put into service without having to add new computational resources.

As for the portal itself, that's a good idea, and I've suggested the same kind of thing myself... but that part of the proposal is a lot more work to implement. What I'm talking about is the first part... the disconnected private lands... and an efficient way to implement it.

I'm not sure but it looks like you're suggesting it's implemented by using empty space above and below a plot of land ? Or some empty space anywhere in the grid ? I'm really not sure what you're describing is any different at all, except my proposal allows for the plot to change shape. Why limit it to an area within the main grid ? The whole point of my proposal is to take us out of the grid and remove us from visibilty from the main grid! Are we misunderstanding each other here ?

There's no requirement for many new computational resources in my proposal apart from the addition of code to implement it. The amount of old resources that are not used will pretty much end up balancing those required by the implementation.

Also there are many reasons to disconnect from the main grid as I clearly point out in the proposal. The proposal is precisely aimed at removing a plot from interaction with the the land that surrounds it on the map without greatly increasing the resources needed to compute it.

Perhaps the confusion is in the usage of the word "grid" I am not suggesting we remove any servers from the farm!

I'm not proposing a simple solution to a privacy problem, the proposal is aimed at using resources which are current wasted on an ant hill design for something more productive, immersive and useful.

lawd this wasn't meant to turn into a rant really but I think somewhere along the line you're missing the point of the proposal.

To make a point clear.

The way I see it working from an agents POV is like this...

If a land owner decides to use the portal option, then no building or scripting at all is allowed on the plot in the main grid. From the main grid the plot would look like any other empty plot except it would have some visible way to go through the portal.

Some have disagreed and said that they think building should be shared between portal space and grid land. I personally think sharing will increase the computing requirement and that is why I said the plot should remain empty if portal space is used.

This could well have a beneficial effect on the 2D/Grid/map/landmass as it will leave open areas between builds made by people who choose not to go into portal space.

I've also suggested owning a private Island would be much less attractive if this proposal was implemented. Which is a big negative point.

Below.

Your proposal requires an additional sim to support an extra area of ground. Even if the ground you start with is unavailable somehow (and why would you want that?) it can't be run as part of the same sim. Even if the extra sim is some kind of mini-sim running on the same computer, it will still require at least as much overhead as a "water sim".

If this is something implemented in the same sim, it will require a massive redesign of the sim, since the sim is specifically designed to implement a section of the grid and every part of the sim is part of the grid.

Unfortunately, it doesn't do that. The idea that every object in the world exists as part of a contiguous coordinate space is pretty deeply embedded in the design. Even in my own non-linear space feature request (which includes what you're referring to as portals) I didn't break that.

The "grid" is not simply the servers in the farm, it's also the fact that the servers are connected in a contguous 3-dimensional grid.

And I'm proposing a way that this can be implemented with the current design.

Why?
Sharing will not increase the computing requirement, you would still have the same prim quota (in my proposal you'd be in the same parcel). If you want to make a big build in the private space, then you'll have to leave the public volume mostly empty... just like now if you want to build a fancy skybox.

If you want a parcel that's a different shape, buy a private island (or rent space on one) that's invisible on the map, and set up a portal/teleporter/whatever between your land and the island. Once you have long distance portals* it doesn't matter where in the grid you are.

* I suggested an opaque prim that was connected to an opaque prim on the other side of the portal... you could apply a texture to it to create the illusion you were looking through it. Being able to really see through it is an advantage but would add more load to the clients and servers.

This quote hilites the important point I keep forgetting and it's very important in relation to this proposal. If I could go back and edit the wording in the proposal to remove references to implementation I would, but I can't, hence the importance of this discussion. I'm guilty of being the armchair expert too. If LL read these things they'll know how to do it and whether or not it's possible to do.
---------


The one big issue that I see against portal space is the private island thing.

If we had to pay huge amounts for portal space like with an island it would be virtually useless if you excuse the pun.

The whole idea of the proposal is to make SL more flexible, safe, private, creative and immersive for the average land owner, not just those who can afford high fees. Also the idea is to move away from being a mere analogy of a continental landmass which to me has always seemed unnecessarily limiting.

Most users--regardless of their level of sophistication--are guilty of this.

I read somewhere that a common point of failure for large software projects is in requirements gathering. Either the requirements are never fully and accurately gathered or the application domain changes before the system can be implemented.

And I believe it. My first real job out of graduate school was working directly with the users of an order management system to develop new functionality for the system. Invariably, the users would describe the implementation of the system, rather than the process or workflow that it needed to satisfy.

User: "We need a textfield on Screen B for entering a description."

Me: "Well, what do you use the description for?"

User: "Oh, well, since there isn't any other place, we put keywords there to show the status of the order, priority, and point of departure."

Me: "What? Well, wouldn't it make more sense to put that information into separate fields so they would be searchable? Also, could make a listbox with common keywords and add a simple interface for adding new ones. It would only take about a day of extra work."

User: "You can do that!?!?!? Of course that's what I want!"

I don't see how you could avoid having to pay as much for "portal space" as for the same number of square meters in the grid, UNLESS it was implemented the way I suggest.

Linden Labs isn't going to give land away, and they're not going to completely rewrite the sim software to support something that reduces the value of buying more land.

There are at least two ways to look at this.

Viewpoint 1: (my emphasis added)


Possibly you might add better performance to this list.

Viewpoint 2: (my emphasis added)



Then, if you look at Lauks last sentence, you get the idea of a huge paradigm shift.



Not sure where I'm going with this, but I know that we've only scratched the surface of this proposal. It's a lot bigger and more important than we probably realize.

Non-linear space is something that's been proposed many times. I've proposed it myself, in a variety of forms. The Lindens, however, seem very tightly bound to a linear space model and any non-linear space is going to have to be introduced gradually.

If people have their own agendas here please take them elsewhere. Keep to the topic. Nowhere is it mentioned this proposal is about total privacy. Nowhere. Take the trouble to read the proposal before you attack it. If you have a problem with another resident who's posting here take it elsewhere. I'm not interested. If you've got nothing positive to contribute don't contribute.

This proposal seems to be about three things.

1. A mechanism to move physical objects and avatars between two locations, without the transported object having to do anything but walk through a connected region (portal, wormhole, teleport gate, ...)

2. A mechanism to display the scenary at a distant location (camera, portal, mirror, ...).

3. An access-controlled area that's inaccessible via travel through 3d space, but can only be reached by a portal.

In addition:

4. The access controlled area should not cost extra money to the landholder.

Do I have this right?

What I'm getting at is that these three things can and should be dealt with separately, and that I'm trying to describe a way to implement feature 3 and satisfy point 4 that fits better within the software that LL has already got than the idea you came up with.

I'm also noting that Linden Labs has promised a mechanism for feature 1: llTeleportAgent().

Pretty much.





Looking forward to it too !

Frankly this is pretty much discussed to death now, how it's done, if it ever is, doesn't matter and is is up to LL. I just want to see something like this happen. If it happens in stages, like it could do by introducing llTeleportAgent() then that's good news

I agree, though nothing is going to make all of the residents happy! Even the pro portal residents cant agree on the how the portals should work or look.

P2P and llTeleportAgent are huge. For a long time, it seemed that Linden Lab was completely against P2P, though I'm not sure if it was for technical or philosophical reasons.

[My apologies Lauk, if the rest of this derails the thread. Not my intention.]

Cost is always an issue, but I don't see cost as a driving issue.

If you look at land in general, then you'll see that some land costs much more than other land already. A waterfront mainland sim auctioned for more than $US2000 over the weekend.

Nor is the monthly tier a constant. The more land that you hold, the cheaper it is per m2.

Also looking at the current land market, you'll see that consumers are willing to pay much more per m2 for things like waterfront when they are buying significantly less than a sim. You see this behavior all the way up to about 8K m2. That seems to be a transitional price point for both land and tier.

Private sim rentals work by taking advantage of the savings afforded to large land owners. Using this, they can offer land and tier at about the same price as LL while still maintaining a profit.

All of this leads me to believe that there is room in the cost structure for LL to add significant new capabilities and charge more for it. When I look at my RL cable bill every month, I can't believe how much I'm willing to pay for that service. SL is similar in many respects. And it's likely that this proposal would lead to new forms of content that would further drive the cost structure.

In addition, I believe that server capacity is steadily increasing and will continue to do so. We can already support many more avatars per sim than we used to. Mono, Havok 3, better caching, rendering and hardware will continue this trend.

Many of the big ticket items in terms of performance are on the client side. Things like local lighting have a huge impact on the client, but none on the server. And there is potential in this proposal to increase client-side performance by reducing the number of textures and prims that must be rendered.

Then, you have hidden costs. There are costs to Linden Lab if they don't move in this direction and there are costs if they move stupidly in this direction.

By moving stupidly, I mean to implement something in an adhoc manner that is unsupportable and can't be extended in the future because it complicates the code base in a way that makes it unmanageable. That's already happening. It's the nature of software development. As bugs get fixed and features extended and the system is made to do things that were never envisioned, it starts breaking.

But I actually think Linden Lab is on the right track with this point. They seem to have moved into a mode of huge architectural change, where each release has just enough candy to keep us satisfied, but the real changes are going on under the covers.

So, my conclusion is that we should dream big. What I'm after is a paradigm shift and the supporting architectural changes over time. It's tough to change the tires on a moving car, but that's what's necessary and so far Linden Lab has done fairly well.

not derailing, changing to the right track I think.




Interestingly in another thread Andrew Linden recently hinted something very similar about the protocol changes in 1.9 possibly being a step toward future Open Sourcing. Which amazed me. If OS is still on the table as a future possibility then the Private Island vs Portals issue sort of fades into insignificance.

SL will soon need to be re-written that's obvious, and it looks like it is actually happening, being done in incremental stages.

Now is the time to think big with feature requests.

llTeleportAgent may change this, if it's smooth enough that you can create a "virtual door" that you set in a hill or a tree that teleports you to a skybox "inside the tree" and back again.

The only hitch is that llTeleportAgent is going to require approval, so you walk through the door and are interrupted by a dialog. It would be better if (for example) a landowner's own llTeleportAgent scripts were applied automatically, like llTeleportAgentHome is.