Prim Cost Calculation

What if rather than putting a limit on the number of prims allowed in a certain area, there were a limit on resouce utilization?

By this, I mean once a set of prims and it's associated scripts are compiled into the final object, the sim would perform some tests on it to see how it would affect the client and sim in terms of system resources. It would then assign a series of metrics to that utilization (e.g. client rendering complexity, network utilization, database cost, sim complexity).

Using this, a given area would be limited by it's resource caps.

Say, for example we are only going to measure sim utilization and client rendering complexity. We put a limit on a given area to a maximum of 100 on each metric (the scale here is artificial and arbitrary).

I decide to build a kiosk to sell shoes (why not?). Normally, if this were prim-limited, I could build a relatively simple kiosk out of 10 prims and load it up with scripts to flip pictures, send e-mails, and intercept all kinds of events. But now the client runs slow because of all the streaming data and the sim runs slow because it has to sit there and run the kiosk. On a small plot I now have 11 kiosks that are bringing everything in the area to a screaching halt.

A resource-based system would recognize that these things are having a negative affect on the client and the sim and assign a resource rating to the kiosk itself. Perhaps it's load on the client is given a 30 and its load on the sim is given a 25. All the sudden, I can only place three of these annoying devices on the entire plot before I run into the plot's resource limit.

If the actual resource utilization were limited in this way, it would encourage designs that are light on server utilization and keep the experience on the client MUCH more consistent.

I also like the idea of not being limited by prims. That measurement is being exploited, as anyone who goes near any hub already knows. A resource based measurement, if not entirely precise, is still far more accurate.

Newer limits and ways to quantify resources are being discussed, I believe. While you won't see much of the effect of this now, give it a little time.

It's my humble belief that they know what they're doing here, but don't have the resources (pun intended) to "deliver" just yet. Since there's a want to move to more "formal" standards over time, I'm pretty sure you'll get your wish.

Some stuff they've said they were looking into:
- Texture resource allocation
- Script allocation
- Inventory management
- Monocode for scripts
- Externalizing the utility of the Event Browser
- The long-term "want" to use more formal standards (3D modelling, coding, protocols, etc)

You can search Linden responses to these issues here on the forums. I suggest you do so. They're good reads.

Interesting idea, but since SL is such a dynamic place (and many objects are dynamic themself), I would imagine that this approach might only aggravate the lag on the server side, as LL spends lots of computing cycles simply calculating the "cost" of objects.

- Ace

I agree that the cost calculation would be relatively expensive. The only true way to do this, after all, is to actually render the object and run its scripts and monitor over time.

However, think about the measurement from a different perspective. Quantifying the resources is merely incidental to the goal of resource management. It would not be necessary to calculate the cost as items were being created or even on the sim itself.

As an example, imagine a customized client application that runs on a dedicated resource management server. It's job is just to travel the grid and take measurements of resource utilization for a "representative" client. Broken into several synchronous scans, this could happen very quickly, say thirty minutes.

It would then update the properties for that area with "hard" numbers. From an end-users perspective, their private client would generate a cost estimate (and this in itself would be nearly identical to the hard estimate, but because actual money is at stake these calculations would be marked as temporary because they come from "untrusted" clients).

Take it a step further and distribute the cost estimation to ALL clients that are currently visualizing an area. These results could be combined, and if sufficient in number, be considered the "hard" number and the resource management bot would never have to scan an area - enough clients have already done it to be considered a trusted number.

While technically dynamic, the end user would, 99% of the time, see a single number that quantifies the resource cost of their build, and that number never appears to change.

I'm more interested in cache size at a given point in time, myself. That can be done at the client side.

The problem with this would be that you wouldn't know how much stuff you could put on your land without first trying it.

I would argue that one doesn't know right now, unless of course everything on your lot were made of one prim.

When someone purchases an item, they look at the prim-count to determine if it will fit on their lot. The only change to this would be the term "prim-count" would be replaced with "resource cost" (although, I would definitely want to come up with a more lamen friendly name).