Impact Measuring - whats the scale?

[Loki Eliot]

Linden Lab released it's new Impact Measuring System last week with which we can see the impact our builds have on Land,Pyhisics, Server and Viewer. 

Im builiding a new structure. Im trying to decide which parts to do as normal prims and which as sculpties and by using the new "more info" option i can see how much more stress a sculpty will be on the overall build.

The problem is though that i have no reference for a scale of impact. I have the numbers, but what do they mean? Is a display impact of '8000' low, medium or high? is there a magic number i should try and keep the 'display imapact' of the over all build below?

 

[Chosen Few]

Don't try to think of it in terms of absolute measurements, but rather as comparisons.  The only way to answer to your question, "Is a display impact of '8000' low, medium or high?" is with another question, "Compared to what?"  If you can build the same item in a different way, to give it a lower rendering cost, then 8000 is high.  If every other way you can think of to make the item comes out higher, then 8000 is low.  If all methods come out more or less the same, then 8000 is medium.

Consider this.  A default cube has a display impact of 389.  A sculpty of the same size has a display imact of around 750-800, depending on the particular sculpt shape.  So, all other things being equal, it takes two default cubes to equal the rendering cost of one sculpty.  (Double the size of the sculpty to equal the size of two default cubes, and its display cost remains pretty much the same.)

But as we all know, things are rarely so equal.  Take that default cube, put a (high contrast) 512x512 texture on one side of it, leaving the other sides as default plywood, and the display cost jumps above that of the sculpty, to well over 900.  Even if we put an equally high contrast 1024x1024 texture on the sculpty, its display cost only goes up to just a hair over 800.  So, this time, all other things being equal, it would seem that a cube with two or more textures is inherently more expensive to render than the sculpty with its single texture, even if the sculpty's texture is larger than the cube's two textures combined.

This information (assuming it's to be trusted) is incredibly valuable.  I had always assumed that a sculpty carried the rendering weight of around 11 prims, since it has as many polygons as that many prims, by average usage.  But now we can easily see that those kinds of simple assumptions need to be reevaluated.  When the addition or subtraction of a single texture can throw things this far out of whack on just this simple little example, imagine the difference in an entire build, or an entire sim.

So, what's the magic number you should shoot for?  The lowest one you can hit.  That's really the only answer there can be.

[Loki Eliot]

Building at the lowest render cost is not  going to be the best resault though. If i want lowest render costs then yes i can do that by monitoring the impact measuring. But i dont want to get the lowest, becasue to achieve that i will need to sacrifice detail, so i need to work out a compromise where a retain some detail and to work that out i need to know what the lowest is and an idea what the maximum might be before and can decide on a compromise. 

For example a Building with the lowest Render cost is so many prims i cant fit it on the land, so i substitue some of the prims for a sculpty which  drops the prim count below the plots allowence but adds to the overall render cost. How much more detail can i put on a build before the render costs reach server or viewer performant degridation? i dont know because there is no scale.

 

If building was just a simple task of hitting the lowest render costs numbers that would be easy, but it's not, Having prims, Sculpties and now mesh is about comprimising and to do that  i need some idea oh what maximum costs to avoid.

[Drongle McMahon]

The render cost algorith appears to be described on this wiki page. Here is the texture component....

"for each unique texture (including sculpt textures) in the linkset: + 256 + 16 * (resX/128 + resY/128)"

I find that quite strange, as this is not proportional to the area of the texture but rather to the sum of its dimensions. With the 256 overhead, it turns out that a 1024x1024 costs only 512, a 128x128, 1/64 the number of pixels, costs 288, more than half as much. There must be something I haven't understood. Maybe the gpu memory occupied by the texture doesn't count for much? :matte-motes-confused:

[Chosen Few]

---

Loki Eliot wrote:

Building at the lowest render cost is not  going to be the best resault though.

---

That would depend on your definition of "best result". What's the goal?

If your goal is to be as lag-free as possible, then the "best result" obviously is to have nothing at all on your sim.  It'll run like a champ, and everyone who comes by will have the highest FPS their machines can possibly spit out when running the SL viewer. 

If the goal is to have the most realistic build that could ever be built, then the "best result" would require using hundreds of millions of polygons, and ultra-high-res textures, like Hollywood CGI.  But then it would take hours to render just a single frame.

Obviously, neither of those scenarios is what you want.  The "best result" in SL (or in any other realtime simulation), as you know, means striking the best possible balance between scene complexity and performance.

 

---

Loki Eliot wrote:

so i need to work out a compromise where a retain some detail and to work that out i need to know what the lowest is and an idea what the maximum might be before and can decide on a compromise. 

---

Yes, it's about compromise, but no, you don't need any hard limit to work against in order to find the ideal balance.  For every build, you make the best looking model you can, at the lowest costs you can.  If you've got two options that look the same, but have different costs, go with the lower cost option.  If you've got two options that cost the same, but one looks better than the other, go with the one that looks better.  It's not really a difficult concept.

 

---

Loki Eliot wrote:

For example a Building with the lowest Render cost is so many prims i cant fit it on the land, so i substitue some of the prims for a sculpty which  drops the prim count below the plots allowence but adds to the overall render cost.

 

---

It's not true that the lowest render cost version of a build would consist entirely of prims.  A single sculpty can replace a whole bunch of prims, which can easily end up lowering the rendering cost, rather than raising it.

Did you look at the numbers I posted above?  When sizing is equal, a sculpty costs as much to render as just two cubes.  Throw multiple textures on those two cubes, and they end up costing WAY more than the sculpty, even if the total texture load is relatively light.  Render-wise, you actually get far less bang for the buck with prims than you might think, certainly a lot less than I ever would have guessed (again, assuming the numbers for display cost can be trusted).

Now consider that a single mesh can replace thousands of prims, at just a tiny fraction of the render cost.  Prims, with all their unremovable hidden faces, are incredibly wasteful.  Build a wall out of 4x4 cubes, and at least 22% of the polygons will be hidden.  (For any of my non-SL projects, if I were to waste 22% of my polygons, I'd be fired, and rightly so.)  Make that same wall out of a mesh, and there would be zero waste.  Unless you go to pains to make it unnecessarily expensive, the display cost for the mesh would be far, far less than the prim version.  But even if you go to town on the poly count, to make it cost the same, at least you'd be using it all, which is still better than the alternative.

 

---

Loki Eliot wrote:

How much more detail can i put on a build before the render costs reach server or viewer performant degridation?

---

There can be no definitive way to answer that.  Technically any and every item in view causes viewer performance degradation.  So, what you really want to know is how much degradation can you suffer before it's noticeable?  That's going to be highly variable from computer to computer.

Say my machine is good enough that I'm getting 50 FPS in my usual day-to-day experience in SL.  Now let's say your build has such a high display cost that I drop 20%, down to 40 FPS, when I'm at your place.  What's the chance that I'm really going to notice the difference?  40 FPS is still going to be a very smooth experience.

Now say I've got a lesser machine, and I'm only getting about 20 FPS to start with.  I show up at your place, and that drops to 10.  Now I'm certainly going to notice.  20 FPS isn't that unresponsive, but 10 certainly is.  Even a drop from 20 to 15 is jarringly apparent.

 

If we go back to the default cube example, it's got a display cost of 389.  We can put 15,000 of them in a sim.  Would looking at 15,000 cubes cause noticeable degredation in YOUR viewer's performance?  I don't know.  Do you?

Say it doesn't.  Does this mean a total display cost per sim of 5,835,000 is OK?  Again, I don't know.  Sometimes it will be; sometimes it won't be.  There are a million other chaotic factors that can affect performance.

 

---

Loki Eliot wrote:

i dont know because there is no scale.

---

No, the reason you don't know is because you're asking the wrong question.  It's never about "What magical number in the sky should I strive to stay below?"  It's ALWAYS about "What can I do to make this build have the lowest possible cost, while still making it look as good as I want it to be?"

You're looking for absolutes where there can be none.  The scale is relative.

 

---

Loki Eliot wrote:

If building was just a simple task of hitting the lowest render costs numbers that would be easy, but it's not, Having prims, Sculpties and now mesh is about comprimising and to do that  i need some idea oh what maximum costs to avoid.

---

Again, I'd suggest you're asking the wrong question.  It's not about "maximum costs to avoid".  It's about minimizing waste, each and every time you create anything.

We've had similar discussions hundreds of times on this forum when it comes to texturing.  No doubt you've read some of them, or maybe even participated in a few.  It happens all the time that someone will ask, "What size texture should I use for ______?" or "How many pixels equal a meter?" or something else equally undefinable.  The answer is always the same: use the smallest texture you can get away with that still can have enough detail in it to look the way you want.  Most people, even brand spankin' newbies, do seem to grasp that concept, once it's been explained. 

The exact same principle applies here.  Use as few resources as possible, in order to create the build that looks the way you want it to look.  The specific resources in question are irrelevant.  The same axiom applies to all.  Whatever it is, use as little of it as you can practically get away with.

Follow the same rules of thumb that all other game artists follow.  If a surface detail can be suggested with texturing, rather than with geometry, let the texturing do it.  If you're going to expend geometry on something, make every poly count.  Avoid hidden faces.  If you can use a few large polygons instead of several smaller ones, do it.  Don't be afraid to have disjointed faces in a model, if it saves on polys.  Use a sensible UV layout, to maximize canvas usage, while minimizing the total number of UV shells.  Repeat textures wherever possible.  Use as few textures as you can.

I could go on and on listing more 'rules'.  Hopefully, the idea is coming across.  Strive to do more with less, always.  As you get more experience making models with these guidelines in mind, they become second nature.  You start to see new possibilities as you're working, for how to achieve the same result with less polygons, or less textures, or less whatever else is relevant.  You end up redoing stuff a lot as you go, because these things don't always reveal themselves right from the start.  But as you do it more, you get a feel for it, and the reworks become more and more trivial.

Even if there were some kind of universally applicable number cap that we all need to stay under, what would it matter.  If you always work with the above principles in mind, you'd never hit it anyway.

[Chosen Few]

---

Drongle McMahon wrote:

The render cost algorith appears to be described on

this wiki page

. Here is the texture component....

"for each unique texture (including sculpt textures) in the linkset: + 256 + 16 * (resX/128 + resY/128)"

I find that quite strange, as this is not proportional to the area of the texture but rather to the sum of its dimensions

.

With the 256 overhead, it turns out that a 1024x1024 costs only 512, a 128x128, 1/64 the number of pixels, costs 288, more than half as much. There must be something I haven't understood. Maybe the gpu memory occupied by the texture doesn't count for much? :matte-motes-confused:

---

From having done the experiment I described in my first post, I can attest that this formula cannot be the only factor in how it works.  Notice I specifically mentioned I used a high contrast texture in order to make the display cost jump so high on that cube.  When I put a largely uniform color texture on it, the cost only went up a little.  But when I put my test pattern on it, which utilizes hundreds of differently colored squares, that was when the cost skyrocketed.  I have to conclude, therefore, that it factors image compression into the display cost.

Why that should be, I don't know.  This was one of the reasons I said, "if the numbers are to be trusted," a few times.  I'm not convinced that they are.  Textures are uncompressed for display, so contrast really shouldn't matter.  Compressibility should only affect download cost, not display cost.

Thoughts?

[Drongle McMahon]

Thoughts?

Well. I tried some experiments and couldn't get anything that fitted with that wiki, let alone the texture part. Something wrong, although the page is less than a week old. Apparently that is not the render weight algorithm in the new viewer. May have a look at source code tomorrow, as I already downloaded it for something else.