A draft to end PEwt discussions: The resource point system.

[Psistorm Voxel]

After giving much thought to the ongoing debates of prim equivalency, streaming weight, server weight and all these complex schemes, I did develop an idea of a system which may actually provide a solution. Allow me to explain my thoughts in greater lengths here.

Problem

Linden lab seems to want to curtail excessive resource usage, and more efficiently model the actual load that certain builds have on the server. Right now, they attempt to force these new weights on mesh objects,  and mesh objects alone, the entire process seems a bit convoluted, since people dont exactly know what the plan is. It is all very much in flux. The current implementation, if it goes through as planned, creates the following issues:

1. Mesh objects were understood by the community to be a new, shining future of efficient and prettyful builds. Actual 3d modeling in a virtual world, tremendous possibilities. These hopes are now sorely dampened.
2. Meshes are laden with so many restrictions that it seems impossible to make a build that looks equivalent to a prim or sculpt build, and have it cost less than said build, even though the prim/sculpt build is a lot heavier on the renderer and other resources, due to the skewed weighting.
3. Scripted meshes arent viable anymore due to the harsh doubling of prim costs currently introduced on mesh objects.
4. Linking prim and mesh objects makes the linkset subject entirely to the new weighting system, thus creating more confusion among beginner builders than anything.
5. Since prims and sculpts currently remain under the old system - and apparently are remaining for a while yet - this encourages people to further ignore any benefits mesh could - but currently does not - offer and continue to build in less efficient ways.

 

Solution

The idea of integrating the actual load of a build into a single, easy to grasp figure has been attempted with the ARC measurement, although poorly in some cases. I suggest not pursuing this idea further, since it mostly models client-side render cost. I want to introduce a new system instead, evolved from the prim count measurements that currenty are the deciding factor of build complexity.

The resource point system.

This system is what it says on the label. Instead of measuring prim count, or worse, prim equivalency (what a long, ugly word for people who just want to build and have fun), it measures the resource cost. Resources are a common term. Whether it comes from strategy games, or the everyday work experience (HR anyone?), it is a term we are familiar with. We know what it means, what it stands for, what its defining characteristics are.

Resource points are to replace prim counts throughout the grid over a sufficiently long adjustment period (more on this later), and will encompass the following measurements:

1. Amount of primitives, sculpt and mesh objects (weighted by complexity) in a linkset
2. Amount and size of unique, streamed (meaning non-standard, not-in-viewer-installation) textures
3. Amount of scripts OR size of allocated script memory past a defined (64-128kb) treshold
4. Secondary properties, whether the object is a light, flexible, or physical, phantom or other such things
5. Discounts apply where applicable. Repeated use of mesh or sculpt objects in a linkset makes it easier to render, and lowers its proportional streaming cost. Likewise, phantom objects do not create a physics load. This should be honored.

These factors are added together to determine a resource cost number for a defined linkset. This number is NOT rounded but rather allows a single decimal point, for a weighting that is as fair as possible.

 

However, this creates one followup problem: How can we balance this system against current land prim costs?
My suggestion to this is as follows: Simplify the prim count system when switching over to the new resource point system. Lets assume the easiest way. One square meter of SL land will allow for 10 resource points. This will make resource point measurements for new residents easy to guess. You wont have to struggle with arbitrary numbers (even I cant remember how many prims a 512 parcel holds. Its a weird number), but instead, are able to derive the resource capacity of a parcel at first glance (bonus factors witholding, i would like to keep this mechanic).

This means a 512 parcel will have 5120 resource points available to spend. A 1024 will have 10240. This measurement is easy and simple. On a sidenote: a parcel with 512 size and up is eligible for rounding down of decimal costs. So if your overall prim cost is 5120.9, it will still fit on your parcel. This allows a fair, small and non-exploitable buffer zone for parcels, which should not noticeably affect server performance in any way.

 

The marketplace and the resource coefficient

The Second Life Marketplace has become a large part of the SL experience. As such, it will require special treatment as well. The questions here are the following:

• How to make residents aware of the resource point system and its importance?
• How to give an idea to people of how complex and/or efficient a build has been completed?

To these questions, two solutions are presented:

• When listing an item on the marketplace, the final goal is to make it a mandatory field to publis the resource point cost, as well as the newly introduced resource coefficient (name not final)
• The introduction of the resource coefficient. This factor is a simple, straightforward measurement of how complex a build is for its size. Imagine an aqueduct, 100 meters long, with 5 1024 textures and maybe two scripts, meshed out of 20.000 vertices. This would yield a rather low coefficient, which is good. Now imagine a car, with the same specifics, 3 meters long and appropriately proportioned. The coefficient here would be very high, indicating that for its size, it is a very complex object.

 

Secondary considerations: Scripts

Scirpts certainly do play a large part in this as well, thus for this system to truly work in a fair way, a few technological changes are needed:

• Variable script memory. This is a big one. Should a door script take up 64k of memory? I dont think so. it might do with 2-4k. Should I be forced to create a second 64k script with overhead and double the codebase, because dynamic data storage drives the peak usage to 70k? Again, i dont think so. These examples are why variable per-script memory is a good idea.
• Parcel-based script and script memory limits. Again, quite a big one, since it prevents people exploiting the "free 64-128k memory per linkset" idea by creating single-prim objects with scripts in them. These limits should be within the expected borders of current peak script usage, and will be subject to discussion.

 

Implementation

A system change this noticeable will need preparation and information. My suggestion is as follows:

• First roll-out of new sims/viewers on beta grid with the new mechanic in place as a for-show system only. Resource points are in the UI, but only illustrate the costs of builds on the new system. This is to find a balance that both residents and Linden Lab can agree on being fair and feasible. Furthermore, the build menu is restructured to allow for complete and easy resource analyzation, to answer questions of the nature of "how much resources does this prim eat?" "how many resources does my script take up?" etc.
• A public beta on the main grid. Again, the system is for show, to verify the fairness of the resource system. Final tweaks to weighting of certain components may be completed.
• A transition period of 3 to 6 months. New builds will fall under the new weighting system, newly created prims, uploaded textures, scripts, sculpts and meshes are calculated under the new system. Old builds are grandfathered until the end of this period before being calculated in resource points instead of prims.
• The final transitional phase. The resource point system fully replaces the "prim count" measurement on SL. It becomes mandatory to publish resource cost figures for every item sold on the marketplace, all grandfathered builds are turned over to the resource point system and may be returned if they overfill parcels. There was sufficient warning and information given. At this point, viewers must support this metric to be allowed to connect to the main grid

 

Benefits

• A fair, easy to understand system to model every aspect of a build into a universal point system. New methods of building may easily be incorporated into this comprehensive model. Also compared to PEwts, this system handles everything. Prim, sculpt, mesh, textures, physics and scripts, and isnt exclusively biased against new and promising technology.
• The amount of resources in relation to the parcel size, bonus multipliers set by sim owners witheld, is easy to understand for anyone.
• Mesh objects may be properly balanced and brought in line with the resource cost on the server as well as the resource cost for the client (render weight) of prims and sculpted objects, thus giving them  a purpose
• The resource coefficient metric allows residents to tell how efficient a build is, and it allows shoppers to easily see whether that prim or mesh hair they buy will be a laggy piece of *expletive*, or whether it will be an efficiently modeled piece of beauty. Again, a simple, straightforward, and easy to use mechanic.
• Discounts and other, detailed calculations provide a fair way to tell complexity, and directly reward builders who go the extra mile to make sure their building, texturing and scripting is as perfect as can be. This creates a direct motivation to build efficiently and makes SL a better place.

Closing words

I have put a lot of thought into this post, as the verboseness hopefully shows, to try and highlight what i would like to see introduced, why i would like it, and why I believe it would be a really, REALLY good idea for Linden Lab to create a universal, all-encompassing resource measurement that people both old and new can immediately identify with.

I would enjoy hearing your comments, and I would especially be honored if a linden or two could post their thoughts on this system and its implementations, whether and where they might see issues, and also where they might see benefits and chances.

[Drongle McMahon]

To get started...

This sort of proposition has the enormous benefit of addressing the real underlying problem we have come across, trying to apply reasource related costing selectively to a class of content. It also challenges the very strong commitment to not affecting existing content types, which stands in the way of equitable application. A few complicating points come to mind immediately.

You mention the aim of making the system reasonably comprehensible to the general user. This is important. I think the prerequisites for this are (a) that it be additive - none of this dramatic change on linking things. Each component, texture, scrip has its own cost and the cost of the whole is the sum of the costs of the parts. (b) preferably that it be independent of object size, but if that is impossiblke that the changes with size are linear. The size dependence in the current system is complex and confusing, because that is necessary to reflect resources use accurately. Some compromise here should be considered.

A second requirement for user acceptability should be that it bears a perceivable relationship to the user's experience. Now here ther is a problem, because the components of resource, server, physics engine, streaming, rendering, are ofvery different realtive importance to diffrent users. Consider, for eaxmple, the user of a top-of-then line machine with a 1Mb/s broadband connection with the user of a cheap laptop who has a 20Mb/s connection. This makes the median point problem for raelative resource weighting quite hard. However, this already exists with the mesh costing as it is, so we must assume as solution of some sort has already been chosen.

"Scripted meshes arent viable anymore due to the harsh doubling of prim costs currently introduced on mesh objects"

I thoroughly dislike the introduction of this parameter, especially as it is non-additive, but it's import may be overstated. It only affects linksets whose overriding cost is the server cost. Given the high cost of most meshes of any size, this will be rather few objects. rather, it adds an uneccesary complication ton decideing what level of linking as opposed to joining of mesh objects is optimal. That was hard enough already.

"Amount and size of unique, streamed (meaning non-standard, not-in-viewer-installation) textures"

I think this could lead to very misleading resouirce consumption estimates. It takes no naccount of the extent to which other objects in the same region reuse the same textures. Reuse is an effective method to reduce texture streaming, and needs to be encouraged. Thus this could only effectively be aplied at the region level, not the object level. The same is, unfortunately, true of mesh reuse.  The developers have indicated an interest in incorporating a reward for within-region instancing of meshes (and so presumably textures) into future costing methods. However, this only goes further against keeping a reliable constsnt object-related cost, which is your goal.

Textures streaming is actually subject to the same size-related effects as mesh LOD streaming. So comparabvle decisions aboout the form and extent of object (or face) dependency of cost would arise here.

 

 



 

[Psistorm Voxel]

I think the suggestions you make are mostly covered with how i would want this system to work. Most notably an additive nature, and a straightforward, easy to understand system that illustrates how many resources a certain object will cost.

As for the mention of meshes only having a doubled script count when the server cost is overriding - I think we can both agree that this is not something the end user should have to bother with. A builder wont undertand PEwts, they wont understand streaming or server cost, and they certainly wont grasp why their little mesh is double the primcount all of a sudden. Hence why i introduced this linear system.

On the nature of a size scaling factor: Ive tackled this question via the resource coefficient. I believe an object should cost the same whether it is 10m or 60m in size. The streaming weight is the same. The server cost, save for physics calculations, is mostly the same. Rendering should not be all that different either. Thus, the resource cost should not scale with size. What however does scale with size is the coefficient. This means a complex, small object has a worth, say, efficiency rating than the same object enlarged. This keeps large scale builds viable. So if you want to have, say, a large skyship, you can do this, as long as you dont go overboard with complexity.

However the final word on this isnt spoken, given that a 10m object versus a 60m object of the same shape may have considerable diferences in rendering cost and physics cost that I dont know about right now. This is why i would like linden feedback.

 

On the subject of texture and mesh/sculpt reuse: This is hard to judge indeed, since the re-use is very much dynamic. Think of a bunch of popular anthro avatars gathering in a common place. You will see a lot of re-used sculpts for same species avatars, for the duration of the event. After said event, the re-use is gone. Thus, since this really is impossible to predict, and since per-minute dynamic resource cost numbers are out of the question  - they should be static and reliable - I would say that the average asset re-use should be taken into consideration when balancing the individual costs for object components in the first place.

[Drongle McMahon]

Yes, I know. I am agreeing with you, just vexpanding on what I mean by easily understood. However...

"whether it is 10m or 60m in size. The streaming weight is the same. The server cost, save for physics calculations, is mostly the same"

Unfortunately, this is not true. The streaming cost (sorry, weight!) varies very much with size (up to 40x40x40m). This is because the LOD switch is based on the ratio of object size to camera distance. The bigger an object is, the bigger is the area around a camera over which it has to download the larger volume of higher LOD data. This is the basis for the streaming cost calculation (which is basically three segments of quadratic functions of the object size, followed by by a plateau).

Physics cost is nthe other way round. The smaller the triangles the engine has to deal with the more work it has to do. I don't claim to understand that properly, but it is the reason the physics costs can ger verry large at snall sizes. In fact at a certain threshold, usually around 0.1m, the physics type secretly changes to a convex hull and you can see the physics cost suddenly drop as the object gets smaller. This is all very unintuitive.

[Vivienne Schell]

!Mesh objects were understood by the community to be a new, shining future of efficient and prettyful builds. Actual 3d modeling in a virtual world, tremendous possibilities."

This is a wrong conclusion. It might apply to desktop builds in 3Ds or Maya or even Blender. But NO professionally designed, professionally built, interactive and ONLINE game engine offers unlimited possibilities. There are serious techncal limits which only the best and highest paid 3D game designers can outweigh by experience and a solid education. 90 percent of the imports i have seen on the Mesh Betagrid so far only qualify for the trash can at EA, Blizzard or any other solid game development company - if they were not ripped 1:1 from their original games. Face it: If you want WORKING mesh imports, make these modelled according to the professional standards of 3D online game modelling, otherwise stay away from it.

And even if you are a professional online game modeller: SL software is not really an up-to-date game engine. So there are even more limits to reckon with.

[Dain Shan]

@ Vivienne

Is this a rant, or a suggestion?

 

Noone jumped out of the box as a perfect modeller.

So please .. dont tell people to stay away because they are not "THE" perfect one, that helps noone.

[Vivienne Schell]

You´ll help no one with importing meshes which will do nothing but either crash any existing viewer and server or make any rocketfast super broadband router explode. But yeah, it LOOKS terrific!

I think that LL shot their own knee by marketing Mesh Imports as they did. And now it´s almost too late to withdraw, and almost too late to direct the whole PR, IP and (predictable technical) mess into some reasonable and realistic channel. So they try to do it by introducing all kinds of absurd mathematical formulas.

My suggestion is the same as it ever was: Either abandon Mesh imports completely or license imports to reality check proof professionals. Revise every single upload for compatibility with this outdated, already overbloated engine. All the "prim equivalency" math won´t help. Mesh import, if not drastically and carefully revised and restricted, is not suitable for Second Life. And it never was - in spite of the false promises by Linden Lab.

[Psistorm Voxel]

Vivienne, I think you are misunderstanding the point we are trying to make here. Noone here is encouraging or endorsing 100.000 triangle wristwatches or other such abominations. And we do want a system which makes those meshes expensive to have in world. That is the core thought between the resource point system and the resource coefficient. Let me sum it up:

 

• The resource point system replaces the prim count system. Meaning if you want to import this ultra detailed mesh, it will cost you. If you want to put a 1024 texture on every face, it will cost you too.
• On the OTHER hand, not only should it discourage misuse, it should also REWARD if you actually build something good. Lets assume you could build an object out of 4 sculpts, aka 4096 vertices. Or you  build the same object much more efficiently out of, say, 2000 verts as a mesh object. The mesh should be cheaper here, and rated better.
• The "resource coefficient" factor I introduced should serve as an indication of how complex an object is for its given size. So everyone can tell at a glance that "oh snap, this object really is a complex abomination. Im not buying this"

 

I hope this serves to end your complaints about the system itself. No one here is a perfect modeler. But the system should be designed to both discourage mis-use, and encourage efficiency. In Linden Lab´s proposed state, really it discourages using mesh at all, no matter how good you are at using it.

 

And to touch on the subject of game content being ripped and posted on SL - this is why you have to have "payment info on file" to upload mesh content. This way, they can actually block you from further copyright infringements. Unless you really want to keep registering new paypal or credit card accounts, that is. But I would say thats a bit much hassle. Plus there is always MAC or IP bans for repeat offenders.

[Vivienne Schell]

Payment info on file is a joke. Any account located in a country where the DMCA is not covered by international treaty - and there are lots - can upload any kind of rip without any kind of legal risk. Linden Lab will be held responsible in the end. They just are about to risk entiire Second Life, and you obviously do not notice.

[Psistorm Voxel]

My opinion differs. Linden Lab has the full right to block/ban any account infringing on copyright claims. Linden Lab is based in the US, thus subject to US state law, period. Thus, any reports of copyright infringement will be dealt with and the offending account will have their payment info banned from uploading mesh content.

Also, lets please end the discussion of whether mesh is or isnt the devils advocate. This does not belong in a topic targeted at a different problem, and frankly, has been discussed thoroughly before. Mesh is coming, and it wont ruin SL just like voice didnt. If you remember, many people foretold the end of SL when voice would come. Anyways, Id like to stop being sidetracked, and ahve comments about the proposed system rather than the "evil" of mesh itself.

[Vivienne Schell]

I never predicted the "end of second life" when they introduced voice. Nor did i predict it when they came up with Viewer 2. And don´t get me wrong, suitable Mesh Imports *probably* would add a certain enrichment.

But i am realist and not a wannabe 3D game modeller. I expect that Mesh Import, as predictably handled now, will only add tremendous technical and legal trouble which will not contribute to a brighter SL future at all. And,yes, it even could work out as a killer.

Ignoring obvious problems isn´t a valid method to avoid these problems.

[Dain Shan]

Always that pointing at wannabes ..

May i asked where you did start from?

 

Guessed so.

 

All i see here is ramting about things that are not even in the slightest a point of this thread.

If you want to rumble .. open one about IP infrigment ( not that we dosent have already a boatload of them ) and about content quality ( we have a bunch of them eighter )

Point of SL was and is that you can actually create things on your own, and display or even sell it.

If you want a Quality control bevore the items get to the market .. go to blue mars, they do that over there.

 

[Vivienne Schell]

I am pretty sure that Linden Lab will do exactly the same. They are already hiring the Mesh Police, in case you did not check their enrollment list. But even the Mesh Police will not be enough.

According to the thread: I think that i made up a reasonable suggestion related to the topic before.

And, hey, you obviously feel offended by "wannabe 3D modeller". So i conclude that you are one.

[Dain Shan]

Damm right .. i am one

I started with Modelling at the beginning of the Mesh beta.

And theres absolutely nothing wrong with that.

 

If there was a quality control about that .. i wouldnt do mesh anymore, because my very first modell would have been denied.

I think same goes for your Skyboxes too then. Because even now if we look at you first one, and comapred it to you top one, you would be thrown out from building back then.

So be glad that there wasnt a quality control back then.. he?

 

[Vivienne Schell]

True, lol. But I did neither rip my prims from Bilzzard, Turbosquid or Google Warehouse nor did my prims exceed or violate any kind of reasonable technical limit. And I am all but a 3D game modeller. Not even a wannabe.

[Drongle McMahon]

I think you are slightly wide of the mark on several points.

First, you avoid the fact that general access to user creation is one of the major USPs of SL. Comparison to other online world that do not share this feature is therefore largely irrelevant. It is for this reason the developers are tackling the  design of a costing system that can restrain excesses without compomising that feature. Attacking them for making this attempt is dectructive and unfair.

Second. It is pointless to consider the stuff presently on Aditi as if it were representative of what people might think of uploading to Agni. Much of the worst stuff, performance-wise, is from people just starting out. Others are deliberately exploring the boundaries. You do know this is a beta? I find it hard to think of a single item I have on Aditi  that I would expect to upload to Agni without extensive modification. Maybe the bench and the simplest window.

Third, you seem to be missing the central point of this thread. That is the application of restraints to static mesh while doing nothing to curtail the existing and extreme inefficiencies of prims and sculpties, and the expectation that this discrepancy will severely compromise the replacement of these horrors with more efficient meshes. It's not about the treatment of mesh alone, it's about the discrepancy. As for attachments, don't get me started. It seems there will continue to be nothing to restrain anyone from wearing countless millions of vertices whether they are in toruses and sculpties, as now, or in new meshes.

[Drongle McMahon]

"nor did my prims exceed or violate any kind of reasonable technical limit."

Oh. So you never used distorted toruses or tubes then? Have you seen what they can do to the physics engine? Just link them to a simple mesh, with the prim as root, and look at the linkset physics cost weight. :matte-motes-agape:

 If you don't want to use mesh, you can just link it to a box prim and set the box prim to Physics shape type "Convex Hull", leaving the torus/tube as type "Prim". That has the same effect of revealing the true burden of on the physics engine. (you might have to deselect-reselect to see the weight update).

[Vivienne Schell]

I had thes same discussion all over again. So lemme adress this in a few lines.

1. Comparison: Compare SL to IMVU. IMVU is a static Chat Room, but even there every single mesh import is revised and utterly restricted by human peers. Content in IMVU generally is much worse to look at as it is in SL without Mesh Imports.  But IMVU runs on any kind of five years old laptop as a result. It´s not the existance of Mesh or "better" graphical quality what makes IMVU a success. It works! And it only can work if imports are utterly restricted, standardised and revised for platform compatibility and checked for IP license. A STATIC chat room. And i really don´t want to mention the fate of Blue Mars here, which has been reduced to a iPad Avatar Fashion Show - it simply never worked.

2. While prims are less efficient for rendering, Meshes will let the bandwidth explode. Ask any REAL professional on this, they all will tell you exactly the same thing. While Highly detailed meshes will not be decisively more rendering efficient than prims are, anyway. And you talk about "replacing" prims and sculots. How do you think this could work? 30,000 sims with zillions of prims and sculpties. Do you really expect these will be replaced within ten years? Who the hell will want to PAY for the replacements?

[Drongle McMahon]

1. So why are you here? If you like IMVU so much better, why not go there and leave us alone.

2. Meshes are without question more efficient to render for the same detail, and often by a very large margin. The basic cube is the best relative comparison standard prims can offer, and it has nine times the number of triangles. I meant replacement in new stuff. As for old stuff, if meshes were allowed to compete fairly, with or without resource-relative costs, I have no doubt people would start replacing stuff for more efficient better looking content, especially to get rid of those dreadful sculpty spheres and horribly mangled window frames, chairs etc.

You are right about bandwidth. That is the killer and the reason streaming cost was the cbasis of the first-tackled resource-related approach. I am on a relatively slow connection and suffer greatly from staring at spherical idiotically textured sculpty tree spheres. At least meshes don't do that. However, the future trend is ever faster connections and tablet computers. So the balance is changing and rendering load is becoming the limiting factor. As that happens, meshes will surely win out over their inefficient predecessors. 

[Vivienne Daguerre]

I am curious Vivienne. You keep talking about professional 3D modellers and how most of us are just not up to snuff. Are you a professional 3D modeller, or do you work in the game industry (and I don't mean working at the Walmart electronics counter selling games)?

You make many bold statements. Are you qualified to make them?

So far I have only seen you criticize. I have not seen any of your mesh on the grid or pictures of such here.

[Vivienne Daguerre]

That is no real answer, just smoke and mirrors.

If you know better and can do better, then show us your mesh. If not, troll elsewhere.

[Psistorm Voxel]

Ill have to agree with the other Vivienne, in that this isnt a real answer. It is certainly nice that you work with professional modelers, but your attitude is becoming condescending and mildly offensive in my eyes.

So with that, please cease this discussion now, for it is not only starting to derail in itself, it also has no connection to the nature of this topic. If you have issues with how LL handles mesh, then please take those to a topic created for that purpose. This is about creating a complexity/cost modeling system for SL´s future, not some quarrel about the subject of mesh in general, please respect that and cease further attempts to steer this off topic.

[Vivienne Schell]

Mr. ikura, i am not willing to test the other viviennes cup size against my cup size, and please remind the other Vivienne to stay on topic as well. And i made my points.

If you do not want to adress my points, it´s your problem. But don´t try to impose your double standards on people who dislike the way Linden Lab handles Mesh in general and Mesh Imports in particular.

And no, the current rules and regulations are by far not efficient enough to avoid a desaster (as long as scaling up a mesh is a potential sim killer the current rule is a joke in itself), nor is any other attempt to control imports by non-transparent, mechanical upload processes.

[Murry Soothsayer]

Im not even sure why you guys are bothering to acknowledge her posts. This is the same person who was cackling in the other thread about the death of blue mars. If they had anything worthwhile to bring to the disucssion they would have done so by now so why don't we just get back to the subject at hand and no longer feed them the attention they so crave.

[Tapple Gao]

I think a prim is a prim. Meshes are not prims. meshes are more like textures. A parcel should be given another metric besides prims, like, a parcel can have up to 100 prims, and up to 10 megabytes of unique meshes and textures within it. Any textures/meshes shared between multiple parcels on one sim get their byte allocation divided between the two parcels

Script memory and time is another metric entirely. A parcel gets, say, 1 megabyte of memory for scripts, and, 10 minutes of script time per real hour

prims are prims and should not be merging all these metrics into it