Mesh Equiv Cost kills my art SIMS - please change equiv prim cost ?

[Kolor Fall]

I was building a new sim with mesh ... mainly interactive art where people would be flying through meshes ... everything was going fine ... testing was good ... but i hadn't logged tested for 2 weeks since everything was going fine.   Now I find the resize cost is killing me.   (i.e. 10 prims when something is small ... 300 prims when it's big).  This is for regions which I own ... and their is no performance impact i have ever noticed on my sims if a object was small or large.  Paying tier for art sims is death (i.e. almost impossible to recoup costs) ... and this rips out my entire strategy of using mesh for large interactive installations(I was in alpha on mesh ... so also years wasted testing) .  It just freaks me out seeing my sim object count change dramatically during object resizes.

Atleast I can recode what i did using the new mega resizing(so thank you to whom ever did that).   But this means that all my testing of mesh, for interactive art is basically useless (which was a ton of work).   This is my second experience on getting completely wiped out by LL decisions as a region owner ... I will not be fooled a third time ... and will do all my new installs external to SL and just backport things to SL as there is interest.

[tomm Pye]

Agree completely. I've been working also a long time understanding it all.

Never realized the enormous impact of scale on PE. Some impact I could understand (does it take longer to render the same thing when its bigger?) But from 20 to 400 (in my case) is ridiculous. Please Lindens : don't kill your new baby with this never clearly  communicated rule. Change it to something more acceptable. And/or explain why?? 

[Josh Susanto]

Can suggest any other way for them to mitigate massive lag?

[Kolor Fall]

Concerning the possible lag of large objects:

 I have not noticed any lag difference between a large and small mesh objects.  Now i mainly link the objects to a non-mesh control object which has physics(i learned this needed to be done in alpha and beta testing), and the mesh object is non-physical.   I have been doing this btw for a long time with mega's to improve performance.

Since I have dedicated CPU's, the lag issue doesn't make sense anyway .... i.e. it's up to me to tune my sim to avoid lag.   If anything with people coming into my sim with mesh is the performance problem, not having large mesh structures on my sim.

[Niko Kozower]

It just their way of "forcing" you to buy more sims and/or land. I mean noones going to use a 1 meter build, so most make it 20 meters or something and most think it will of course raise in prim limit by 10 prims or something but nope, raises by 200 prims, crazy.

LL has been proven wrong on many occasions but still they insist that mesh creates a lot of lag, when in fact sculpties are probably one of the biggest elements that create lag.

Maybe they will realize this some day, though I doubt it.

[Helium Loon]

The problem of mesh 'lag' is not the geometry....it's the physics.  Anything but the simplest of shapes is going to create a complex physics hull (especially if it isn't optimized!)  This puts a big load on the server calculating the physics simulations.

 

The scale affecting the PE is a bit excessive.  I know it is based on the fact that the larger an object is, the shift between LODs happens at a longer distance.....hence, it shifts to lower LODs much further away.  If an mesh gets large enough, the highest LOD is the only one ever seen, meaning that it's PE at that size would best be represented by the PE of the same object with ALL LODs set to the the same top level LOD mesh.

 

However, the argument breaks down, since that isn't exactly how they calculate it.  A simple 4-triangle mesh, scaled up, will easily go way beyond the cost of the top-level LOD cost at a smaller level.  Why?  It makes no sense, since the rendering cost would never change anyway......it is either rendered or not, no LOD changes affect it.  This is how the PE should be calculated for scaled objects.

 

[Kolor Fall]

Agreed niko and helium. Which is why I run my mesh physics on my external server using linked objects .... So there is no physics impact on CPU of mesh in my sims. For region owners they should just turn off eqiuv costing ... Any other reason they give is just not logical. Only good news is sometimes I wouldn't do all my physics external to sl .... Now that I am m igrating all this code, my migration to mixed reality platforms is much easier.

[Phoenix Steampunk]

The PE is fine as it is.

Creators just need to understand that they gotta support their own physics shape or work their way around it. Especially for large mesh builds, which are pretty much a mistake to begin with. Its much more efficient to break down mesh builds into sections.

As for the physics itself noone forces creators to use LLs physics creation algorithm, which is just meant to support those that don't really care what they are actually doing. Just do your own physics if you wanna save PE. Beside that there really is no need to rely on the actual mesh based physics at all. The easiest way for larger build is just to go with something like a bounding box low poly count physics shape that you support with your meshes, turn of the meshs physics and prim the physics.

Its not LL that fooled you, you pretty much fooled yourself by obviously missing the idea of a beta test. Not their fault if you call something final before LL called it final, tho. In case you would follow the jiras and repositories you would know that the PE formular isn't final yet but still adjusted.

[Kolor Fall]

>The PE is fine as it is.

> ... PE formular isn't final yet but still adjusted .

I was in alpha and beta testing, but somehow i missed the meeting were the equiv cost was going to jump by 20x when the object was resized.  Also, If your read my post, you would have read that I never use physics on my mesh, here is my process as I have understood the Jira and mesh web wiki(and from talking to other people):

1) upload mesh object (no matter what you have, you to have a physics model, equiv cost doesn't seem to change much even if model is trivial http://community.secondlife.com/t5/Mesh/Basic-question-about-Mesh-primcount/td-p/1041743 ).

2) create a normal prim box

3) link mesh object to box prim (with normal prim as root)

4) click on mesh object and set physics to physics shape type to none

This process has no effect on changing equiv cost(perhaps this is a error ... of which this thread could be a bug fix??).  

If there is some "trick" someone has found to eliminate resize cost by having the object physics as a single sphere or something, i'd like to know exactly how to do that so it effects equivalent costing in a significant way.   As far as I know, the equivalent cost resizing algorithm is secret.

[Phoenix Steampunk]

---

Kolor Fall wrote: As far as I know, the equivalent cost resizing algorithm is secret.

---

Aint that much of a secret at all. For details on the physics algorithm check: Mesh Physics and for the streaming as well as rendering cost algorithm and the shame calculation check the llvovolume.cpp. 

And as for the "trick" you are asking for its really to not use giant mesh builds but to cut them into small sections instead as this is the way it is meant to be.

[Kolor Fall]

Thanks for the trolling steam ... as i have repeated multiple times, I have physics turned off on my object, thus that equation should not apply.

[Phoenix Steampunk]

---

Kolor Fall wrote:

Thanks for the trolling steam ... as i have repeated multiple times, I have physics turned off on my object, thus that equation should not apply.

---

*chuckles* If you think I am trolling you just stop reading and check your resources and workflows on your own rather than making statements that are just wrong. Initially i wasn't even replying to your post but to the entire physics part of the thread. My point stays valid, the PE algorithm is fine as it is.

To focus a lil bit more on your problem and what helium said:

---

Helium Loon wrote:

 

However, the argument breaks down, since that isn't exactly how they calculate it.  A simple 4-triangle mesh, scaled up, will easily go way beyond the cost of the top-level LOD cost at a smaller level.  Why?  It makes no sense, since the rendering cost would never change anyway......it is either rendered or not, no LOD changes affect it.  This is how the PE should be calculated for scaled objects.

 

---

 

First of all the statement about a the tetrahedron is false. Just do the test your own. There is no difference in the PE for a 0.01³ tetrahedron and a 64³ tetrahedron. Both have the exact same render costs of 269 as well as the same PE which is rounded up to 1. What he is missing is the streaming costs that come with the LOD levels.

Meshes that make improper use of the LOD get a penalty which is scale dependent. If you already know that your mesh is so huge that you by no chance need any other LOD than the highest just use a low triangle mesh for all the lower LODs thats enough to show all materials you have to apply, cause no one will ever see another LOD than the highest. Same goes the other way around. If you got a mesh that only can be seen when you enter a room make sure the highest LODs match each other for whatever breakdown you need till you finally hit the expected drawing range, so you don't get the penalty cause you don't force the streaming of unneeded LODs.

Lil example. Both meshes are the same, they right one just makes proper use of the LODs for its expected scale and drawing range the wrong one obviously not (Right: PE 7, RC 869; Wrong: PE 335, RC 28209; Tetra: PE 1, RC 269; Client Version: Second Life 3.0.3 (239596))

Its not LLs fault that people miss the idea behind the entire LODs, as its not their fault that creators miss to use them for their advantage. Don't force the streaming of what doesn't have to be streamed, its as simple as this. Either art sim or not, creators will always run into issues if they just ignore the tools LL has given them to optimize the costs.

[Drongle McMahon]

Not that this has any bearing on the argument, but...

The largest mesh you can make, 64x64x64, has the first LOD switch at 231m, if you have renderVolumeLODFactor set at 1.0. You can set the view distance to 512m. Although such settings are rather unlikely to occur together, this means that it is theoretically not possible to make a mesh so big that the medium LOD is never seen. Indeed, if you set renderVolumeLODFactor to 0.25 and view distance to 512, you should be able to see all four LODs of the largest possible mesh.

[Phoenix Steampunk]

You got me there Drongle, to be honest made a chart for that and did detailed tests on that. Hardly to imagine someone that is interested in eyecandy would sacrifice renderVolumeLODFactor for max drawing distance *chuckles* Good to know anyway.

 

(Not to highjack the thread I am going to start another thread as there is something that still bothers me about the LODs and I wanted to discuss it in a more general way to get some feedback from you guys.)