this got me thinking... why not build a world where there's a financial cost to creating laggy prims?
determining what's laggy these days isn't an exact science, but i think we know enough to know make a few reasonable assumptions. saying "unoptimized textures and large collections of prims lead to more lag" is a good start.
maybe users in the virtual world could be given a "lag budget" measured in ARC-hours. (ARC is "Avatar Rendering Cost.") if you go over your lag budget, you have to pay for more. so if you were given 6000 ARC-hours per month, you could wear your 1500 ARC outfit for only four hours before you had to buy more lag. but you would get 40 hours of use out of your 150 ARC ruth-esque outfit.
maybe a benefit of premium accounts could be you could sell your unused lag on the "open lag exchange."
just a thought.
maybe the converse of "paying for lag" is "getting paid for ARC." people running viewers would say how much aggregate ARC they're willing to live with. if you had a beefy GPU or didn't mind low frame rates you would move the slider one way to tell the system you were willing to sinc more ARC. move it the other way, it tells the system you don't want so much.
ReplyDeleteand there are some things that will likely cause "client side lag" and other things that cause "server side lag." you may need budget for both.
i think the key here is that lag is analogous to "flux." you have things like large textures and complicated builds that create lag. the lag flows through the virtual world to each viewer rendering the scene. if you're pumping too much "lag" into a viewer or simulator that can't handle it, bad things happen.
maybe we need a lag resistor to counter the lag current.
I think you need a much clearer idea of what you mean when you say "lag" before you can consider taxing it.
ReplyDeleteIMHO rendering cost is irrelevant here, for starters. If your viewer is working too hard to render a scene, it's up to you to reduce the quality of the rendering it attempts. Instead of blaming the scene and its creator. If it's too hard to see, maybe you shouldn't look...
Load imposed on a shared server might be a proper target for a "lag tax"...but will require a very deep understanding of what the resource issues inside a simulator server are. The upcoming Second Life script memory constraints are an example of this. But again...it can be difficult to decide whose "fault" some aspects of server load are.
If I rez a prim and look at it, obviously all the costs of doing so are properly attributable to my usage of the VW. But if I rez a prim in a public place, and 500 avatars look at it for an hour, is all the cost of that properly "my fault"? How much of it is theirs?
(Oops. Wrong login. Above was me. feel free to delete it, repeat follows)
ReplyDelete"I think you need a much clearer idea of what you mean when you say "lag" before you can consider taxing it.
IMHO rendering cost is irrelevant here, for starters. If your viewer is working too hard to render a scene, it's up to you to reduce the quality of the rendering it attempts. Instead of blaming the scene and its creator. If it's too hard to see, maybe you shouldn't look...
Load imposed on a shared server might be a proper target for a "lag tax"...but will require a very deep understanding of what the resource issues inside a simulator server are. The upcoming Second Life script memory constraints are an example of this. But again...it can be difficult to decide whose "fault" some aspects of server load are.
If I rez a prim and look at it, obviously all the costs of doing so are properly attributable to my usage of the VW. But if I rez a prim in a public place, and 500 avatars look at it for an hour, is all the cost of that properly "my fault"? How much of it is theirs?"