• Announcements

    • Xiola Linden

      The New Community Platform   03/21/2017

      We are still working on making adjustments and changes to the new platform. Thanks  to everyone who has been sending in feedback and filing any bugs you've encountered! 
Sign in to follow this  
Followers 0
Nyx Linden

Calculating "Prim Equivalency"

40 posts in this topic

Greetings all!

There's been a bit of confusion around how we deecide how many "prims" a given mesh is equivalent to, so I wanted to take a moment to go over the system from a high-level view to try to clear up some of the confusion.

Prims that are subject to these rules fall under one of the following categories:

1) Its a mesh

2) It uses the new physics shape type

3) It is linked to #1 or #2

Anything else will fall under the legacy system of 1 prim = 1 prim.

 

For content under the new system, we measure the content against three metrics (or "weights"). These are: Download weight, Physics weight, and Server Weight. Once these values are computed, we take whichever one is highest and treat that (rounded) as the number of prims charged against your land's budget.

  • Download (streaming) weight depends mainly on the number of triangles in a primitive (mesh or not), as well as its physical size. This is to account for approximately how complex the object will be to download & draw at various distances from the object.
  • Physics weight depends on the physics representation used (prim, convex hull, none), as well as how complex that representation is. Note that "Prim" physics shape type could refer to an uploaded convex decomposition, or an undecomposed physics mesh.
  • Server Weight tries to approximate the amount of messages that a given object will generate on the server that has to be passed to observers. There is a per-object (linkset), as well as a per-primitive cost (a single unlinked prim counts as both). Physical and scripted objects generate significantly more messages than static content, and thus are charged more in server cost.

Please note that the different weights are computed completely independently. Specifically that means that adding a script or making an object physical will affect the Server weight, but will have no effect on the Download weight.

 

I'll be working on trying to update / keep up to date the costs and fees page with the latest information. https://wiki.secondlife.com/wiki/Mesh/Costs_and_fees

 

Please note that we are still working on adjusting the exact numbers being generated by each system, so if you have content that seems too heavy or too light in terms of prim equivalence please send it in. We believe the current structure should be a straightforward system for the first release, though we reserver the right to make changes as appropriate in the future. Please let us know if you have questions!

 

 -Nyx

 

Share this post


Link to post
Share on other sites

I noticed the costs display in the edit floater changed on the latest Mesh servers. Is it now this number we should take as prim count, or should we still go with the Show Render Info > Selection Streaming Cost display?

Share this post


Link to post
Share on other sites

If i have only one single object, then i sometimes see the costs for the link set and the costs for the object differ. Which of the 2 will be the final value to take care about ? Or will it be ensured that for one single object the costs for the linkset and for the object are always the same ? why would they be different for one single object at all ?

Share this post


Link to post
Share on other sites

Linkset (Object) cost should be the one that you are actually charged against. We're going to be cleaning up our build tools display of data soon hopefully. The only difference between the two should be that the linkset cost should be rounded from the total prim cost for a single object.

Share this post


Link to post
Share on other sites

So. I make a building out of 99 meshes (I have to break it up to keep the streaming cost down) these are simple small pieces with streaming weight 1.0 each. But my server cost is now 200. Oh well, it will still fit on my 1024m. Oh, I forgot, I have to put a script in the door that opens it in response to a touch. It's a simple script because I used my work-around to get the pivot at the hinge. What! the cost is now 400! It got returned! Oh well, I'll buy some more land.

Now I may as well put half a dozen of my favourite scripts in each of the 99 prims. I'' have them tell me who goes near them with a sensor and sending http messages to my database. I'll make them switch textures in response to commands on an open channel. Some of them can have streamed media on. After all, that won't cost me any more than the door script. Oh.

Even better, I can sell that extra land. I can attach the whole building to a bot and still have all the prims left. Time tier down to a 512.

In other words, the suggested implementation of server cost bears no relationship to the actual server burden. It's only effect is yet another step to make meshes unusable for anything except attachments. If this is the plan, then please tell us, so we can stop wasting our time. If not, then at the very least make it a per-script cost, although I suppose scripts can still vary in server burden by orders of magnitude.



Share this post


Link to post
Share on other sites

 


arton Rotaru wrote:

I noticed the costs display in the edit floater changed on the latest Mesh servers. Is it now this number we should take as prim count, or should we still go with the Show Render Info > Selection Streaming Cost display?

I'd have to echo Arton's question. Should we still look at streaming cost for the most accurate indicator or prim cost versus the edit floater?

Share this post


Link to post
Share on other sites

We hear a lot about prim costs and rigging in this forum but I have only one question...  Will we, or will we not be able to build Mesh vehicles that have as much detail as today's sculptie ones?   Anyone have any insight on this?   TY 

Share this post


Link to post
Share on other sites

 


HD Pomeray wrote:

We hear a lot about prim costs and rigging in this forum but I have only one question...  Will we, or will we not be able to build Mesh vehicles that have as much detail as today's sculptie ones?   Anyone have any insight on this?   TY 

No, i dont think so. With the last correction to streaming cost, i doubt it will be possible anymore.

You can still do it, if the vehicle is an attachment, thought

Share this post


Link to post
Share on other sites

There is at least one highly detailed mesh vehicle around; arton's land rover. Has had a prim cost as high as 160; currently has a streaming cost of 80. It drives great. none of it is an attachment. There is currently a copy of it in sandbox 21 and meshHQ 3

Share this post


Link to post
Share on other sites

Well yes, since the prim count and the physics count are seperated with mesh, you can build highly detailed mesh vehicles, and they will still be physical as long as the Physics Costs are 32 or less. The Prim count can be 5000, or something, if you want.

Share this post


Link to post
Share on other sites

Ok, this, to me, is quickly getting to the point of crazyness. Right now, I can make sculpty animals that are physical and have many scripts in them. They are pretty dang lag free. I even have 1 working at the SL8B, and is performing perfectly despite 20 avatars or more being on the sim, and lag being generated from 100s of sources. Plus, avatar is punching robot with information traveling from the avatars hud to an outside google server and back. And it all functions flawlessly, at the SL8B.

With mesh, what you are telling me is that this will be impossible because of the total cost that you think it is generating. LL, have you done any real tests to see that your logic is correct? Personally, I don't see the reasoning when my sculpty versions function pretty dang well.

We need more info on how all these things affect the costs. Why would I now use mesh, even though the geometry will be far more efficient, when I don't get penalized at all for using sculpts, or prim. The rendering costs for those sculpts and prims are way higher than an efficient mesh. Is LL just looking at this from extreme situations? Again, we need more info.

You know, I've never waivered on the fact that mesh will be great for SL, but I'm starting to now. What could have been great has been drawn out far too long and now is becoming algorythmed out of favour. No offense to coders, but sometimes, they don't know when to stop.

Share this post


Link to post
Share on other sites

But you don't have a wooden computer, do you? Evidently if it's mesh it has to work on a wristwatch.

1 person likes this

Share this post


Link to post
Share on other sites

I am loosing it too:

High lod 1770 tri's, Medium lod 830 tri's, Low lod 516 tri's, Lowest lod 228 tri's, Physics 12 tri's (cube)

Rezzed at 0.25x0.25x0,25m

Costs 4 prims of my land.

Object can be made with 2 sculpties and looks better (about 4000 tri's)

Or maybe I take 3 sculpties, I still win 1 prim.

But what happens now, I tortured myself to make this object out of 1 sculptie in the past.

And I managed and it sells great -ONLY 1 PRIM- OMG look at this :-)

***

If my mesh would have same tri's and prim numbers as my sculptie I could make this object completely perfect.

And as a plus way better texturing abbilities.

It would help SL better if we get rewarded for using mesh.

 

 

Share this post


Link to post
Share on other sites

I still hope that the prim costs are not final. well yesterday i have seen one of my kettles suddenly showing me a primcost of 2.0 where it used to be 4.5. Unfortunately today its again as before. But streaming costs are slowly going down as far as i can tell: Last week i was not able to get below 2.0 with streaming costs, today i get 1.6 with the same mesh and the same size.

So maybe wait until we see the final numbers and then decide how to proceed ?

Share this post


Link to post
Share on other sites

Given how thanks to a bug (filed on the JIRA, reportedly with a solution coming soon) I am  unable to use the mesh beta grid, i have to go off of what people talk about here on the forums and what little experience i could gather before the bug.

In all honesty, this system is ludicrous, im sorry to say it. Please do name  a reason why the following should sound anywhere near right:

A sculpt object with 10 scripts in every prim, say, 4 prims, 4000 verts approximately. Cost? 4 prims.

A mesh object, a single script compared to the 40 above, 1500 verts, proper LOD, physics shape, whatnot. cost? maybe 3 prims, thanks to that ONE script, it costs 6 however.

 

Punishing meshes for being scripted, and for server weight and whatnot is just not applicable. Mesh costs imho should be based solely of:

- vertex count

- face count (after all, being able to load 7 1024 textures onto a mesh is considerably more resource intense than a single faced mesh with only one texture

- perhaps upload size, which would derive ultmately from vertex count and face definitions, complexity of the UV layout etc

 

Anything else is moot. Mesh should be designed as a tool to not only bring prettier builds into SL, but also to bring more EFFICIENT builds into SL. If mesh will ALWAYS be costing more prims than a way more wasteful sculpt or prim build, them Im sorry, I wont bother with it either. Why waste prims if I can just slap together some prims for something that looks same-ish, eats WAY more vertices and texture space on the renderer, but costs less prims?

If you only want it useable on avatar attachments, then say so. But at least give us the option to define morph targets (aka blend shapes, whatever you call them) so there is at least SOME justification to bother with it.

Share this post


Link to post
Share on other sites

Let us take a step back and view the big picture for a moment. Mistakes have been made in the past in allotting resources to assets. I heard Runitai moan once about the resource costs of the common torus, and yet it counts as an unbalanced single prim. Sculpties probably should have been made to cost 2 prims, or perhaps more. I have seen discussion about script demands on resources, and talk of finding some way to throttle or limit scripts. All of these things contribute to lag.

All the same, I must say I have seen huge improvements in the past couple of years on the lag front. I think the biggest improvement I saw was when my grandfathered class 4 sims were upgraded to class 5 servers. Prior to that, we would sometimes have to cancel our weekly sword tournament which has been running continuously since 2005 due to the lag being so bad that people simply could not move enough to fight. The sim would freeze when someone wearing a mono script tried to enter the arena. It was bad. However, the difference between then and now is major. I must say, "Good job Linden Lab!"

I know that you have the "mistakes" of the past you would like to deal with in term of resource costs--the torus, sculpties, and scripts. You cannot solve these problems by loading down mesh with corrections to try to make up for them. If you do, you will hamstring mesh to the point where it will be underused.

Consider the new user with his 512 sq. m of land. Do you want some low prim, quality items to be available to him with his measly 117 prims? That may help retention if he can actually do something half decent with his little plot of land.

Let us consider current users. Many of them also fade off into the distance, losing interest and becoming disenchanted. Mesh holds the potential to breathe excitement back into SL for many and might even draw some of the oldbies back in, unless it is not used or is underused. Mesh should be a big deal when it hits the grid, not a disappointment.

There are people who fear change out there who have been predicting the doom and downfall of SL due to evil mesh coming. Let us not give them more to wail and shout against. They won't bother to learn all the ins and outs and details. They will lock onto one little thing and blow it out of all proportion, and many will believe them.

Please don't hamstring mesh that badly. Scripts and physical or not should not enter the prim count equation. Very low triangle count meshes should be 1 prim.

You are doing a good job on dealing with lag Linden Lab. I think where you need to put your effort to continue to battle lag is on technology. Invest the money required to stay on the cutting edge when it comes to servers. In another year or two, technology itself will be able to handle more and you might even want to give us more prims, say 20,000 per sim? Until then, you will have to eat the errors of the past in order to attract more users and retain the users and content creators you have.

I hope someone out there is listening.

1 person likes this

Share this post


Link to post
Share on other sites

So yeah heres a fun exercise I just did to see how broken the prim calculations are.

 

Uploaded a relatively simpish table mesh ive been working on. Its two peices but uploaded together so its automagically linked when its put in world

Upon first rez cost 4

Unlinked cost 10

Relinked cost 11

picked up and put back down in world cost 8

 

So lovely to see that the system has been so well thought out that i can get 4 different costs ranging to almost 300% the original cost on one object depending on if i ever touch the linkset after initial upload. Thats not even touching upon how rediculous it is taht a 4 vert 2 triangle mesh could weigh 2prims verses a full on sculpt.

 

This system of calculating thigns is horrible. Mesh has the potential to vastly improve the appearance of SL not to mention speed up the rendering, and yet its going to be so expensive to the point that it is without worth. Why purposefully sabotage something that could only make SL better by throwing in all sorts of conditions on cost that inflate the price to practially needing your own sim just to have a nice house.

Share this post


Link to post
Share on other sites

In business terms this would be called a market failure.  Linden Lab is introducing a new "product" ie mesh objects.  If the "price" (prims) are higher than the existing product, and it is no better at doing what it is supposed to do (look nice), then people will not buy the product, and your development effort is wasted.

Nerfing the product to cater to the low end PCs some people use is the wrong approach.  If someone is using a plywood computer, just dont show them the highest LOD, ever.  Those of us with faster computers get to see the full detail model, along with the other nice graphics features (shadows, global illumination, etc).

Share this post


Link to post
Share on other sites

I dont know about others, but the build I was using was put out tuesday and was the most recent build at the time of my posting/testing. Trying the most recent build from 22nd shows the same inconsistancies and looking around the beta grid itself i see things with completely insane mesh costs attached to them still. If the costs are in fact down then they are still far far away from where they should in fact be.

 

 

Honestly I have to question /why/ they decided to go with some complicated way of determining cost for something that is designed to reduce load on peoples computers. Sure the initial download of the mesh is bigger, but once its in your cache its there for quite some time. Does it really matter if the object is smaller or bigger? Should that really effect rendering cost when an object of similar enormity made out of prims would likely cost less prims and more certainly be exponitially higher in rendering costs? Last i checked there were vew distance sliders in the graphic options for the rare occasion something big in the distance was lagging you. And what in the world does adding a script to something have to do with /anything/. Scripts are limited on an entirely different system and they have never and should never have anything to do with the primcost of an object.

 

The entire system is busted to the point that you get better returns with a sculpt that takes more effort for the engine to light and render than a simple mesh that represents a much lighter load on the GPU of a computer. Its completely backwards from the way things /should/ be weighted and if this is how the system goes live then Mesh will be almost DOA for anything that isnt an avatar attachment. At this point the only way I can see mesh being at all usefu for bulding is in very limited cases where to many prims are needed to fill gaps between shapes that it bloats the primcost out an insane amount.

 

We should be /enabling/ people with mesh to do more creative and wonderful things, making SL a less laggy and GPU intensive place in the process. instead we see LL doing all it can to make sure mesh will be the very last resort when building is concerned.

Share this post


Link to post
Share on other sites

I would agree that the platform itself, not accounting for viewer problems, is a thousand times more stable than, say 2008. Lots of things are better, and yet there are still many things that are messed up, and have been for years. Even creators have gotten better and smarter.

You can't stop people from making unusable stuff. Heck, people love tons of stuff they buy on the marketplace and can't really use. Why, cause it is cool, or whatever. You can't stop people from lagging a sim or writing a script that will crash a sim. What you can do, is give people the information they need to make good decisions. Just take a look at our marketplace. What information do we require merchants to give? None, nothing, they don't even have to write in the features, or even give a prim count, when valid. Why doesn't the marketplace require a texture count? Or even, why not an ARC number?

LL requires it's merchants to tell the customer nothing, and then tries to code in things to prevent the lag monsters from working. This is not a sound approach, and has more loop holes than any 1 person can even understand. What should happen is, that we should be able to do whatever we want as long as we inform the consumer as to the affects of our products. Informing the users will get us way more than restricting the users. Information will empower the user.

Edited. I just tested the latest viewer on my other 2 pcs. I'd consider them both somewhat low end, and everything rezzed extremely quickly. Of course, there are nothing on the mesh parcels around me, and I can't rez anything big, so this is relative to the circumstances. Earlier this year, I even paid 350 for a laptop for my son. It has 3 gigs of ram and a Radeon HD 4200 video card. I bet it will run fine on that too. So, I just don't see what all the fuss is about limiting mesh.

Share this post


Link to post
Share on other sites

I guess this one finally drove me over the top. By way of redress, I will point out that the server cost will only ever affect prims costing less than 4 PEwts. For makers of small unattached scripted things (like kettles with changeable or stirable food?), this is a real problem. Otherwise, as long as you stick to linksets costing greater than PEwts, it has no effect.

Anyway, it seems to have gone away now. My small scripted door is now 3.0 PEwts. (v233473s233117).

PS. Oh no. Sadly, it hasn't gone away enirely, only the physics part. It still says 1 + 3 = 5 when I link a standard prim cube to my simple door! And (hahaha) if I unlink them, then while they are still selectd it says 8, but reverts to 4 if I deselect and reselect them.

 

Share this post


Link to post
Share on other sites

Another thing i would like to bring up, while talking with Murry Soothsayer (posted above some) the other night, we realized something else:

Re-using the same mesh in a linkset does not offer any bonus to prim costs. It should. Why?

Lets say you build a wing, and create a low-poly mesh feather for it, no alpha maps. With the base cost of 2 prims per mesh minimum, you would end up with, say, two prims for the wing arm, lets say, 200 polies. and each feather, lets go with 50 here, at 20 polies. So for a wing, you could assume 2 meshes that are in memory (and one of which can be subject to geometry instancing if SL supports that, thus drastically reducing render cost), and generally you may also assume 1200 polies for the entire thing.

Now the prim cost? 102 prims. you COULD build the entire thing as sculpts, for 51 prims, and would end up with over 50.000 vertices, i cant be bothered to figure out the polycount atm, but you see my point.

Not only should low-poly meshes cost one prim, but also, once you start linking several of the same mesh into a linkset, there should be discounts applied.

 

On the other hand, there should be a slightly expontential scaling for meshes which are a small size and go past a certain triangle limit. Especially for physics shape. So if someone creates a 50.000 triangle physical spinning top, it´s cost should be way higher, proportionally, aka a non-linear scaling. Large objects however arent affected by that as much. This is mostly a measure to stop people from creating ultra-detailed small mesh objects, with detail that really isnt needed.
For a current equivalent, think of 100-prim wristwatches with bling.

Share this post


Link to post
Share on other sites

The problem with the instancing argument is that all the instances still have to be transformed and rendered. When we were talking about bandwidth costs, the argument made some sense, although it was still rejected. However, now that the costs are supposed to correspond to rendering load, it doesn't.  I don't know enough to say whether the gpu hardware can actually do the instancing, or whether the viewer uses that capability it it's there, but it would still have to recalculate all the vertex positions for each instance. After all, all meshes are ultimately made of of instances of just one object, the triangle. Should we only therefore pay for one triangle?

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  
Followers 0