LOD?

[Tenly]

I purchased an older sculpt mesh that I had to reset the LOD in order to see it correctly...but everytime I come back into SL its setback to the default. is there a way to change it so it doesnt flip back or is it that the newer viewers just wreak havoc on the older scultp map creations? I wouldnt think it would matter...its all mesh after all. but Im stumped.

[Amethyst Jetaime]

It probably depends on what viewer you use.  I use Firestorm and it stays at the setting I select.  I can't speak for the SL viewer though because I don't use it.

[Drongle McMahon]

I can't speak for the SL viewer

The setting of RenderVolumeLODFactor is persistent in the current (and past) LL viewers. It stays set across logins whether you alter it directly or via the Object Detal slider. It even stays set if you relog after setting the slider but don't close the Preferences dialog. It may sometimes change when the viewer gets updated. The persistent value is stored in settings.xml (in users\....\AppData\Roaming\SecondLife\user_settings\ on Windows 7). So it will also change if you use a different computer or log on to the same computer as a different user.

[valerie Inshan]

The LOD is more for sculpties than mesh. Go to advanced menu > debug settings > meshMaxConcurrentRequests. The default value is 32. Set it higher if needed until you can see mesh correctly.

[Gaia Clary]

---

valerie Inshan wrote:

The LOD is more for sculpties than mesh.

---

I always thought it is one of the major advantages of mesh that we can optimize the LOD, while for Sculpties the LOD's are predefined.

[Theresa Tennyson]

---

valerie Inshan wrote:

The LOD is more for sculpties than mesh. Go to advanced menu > debug settings > meshMaxConcurrentRequests. The default value is 32. Set it higher if needed until you can see mesh correctly.

---

Okay - this will take a while:

1) RenderVolumeLOD is for both scupties and mesh, and will have the same effect.

2) MeshMaxConcurrentRequests is only for the number of simultaneous mesh fetches that the viewer will do; it has nothing to do with the actual rendering of the mesh itself.

3) Turning up MeshMaxConcurrentRequests was a major contributor to sim lag on crowded regions a couple of years ago because people set it to ridiculous settings that would cause the server to try to send send massive amounts of data over and over again.

4) Since then, it's been capped both at the server level and in the viewer - actually I think 32 is now the upper limit for the viewers and the default is 16; it may be even lower now.

[Coby Foden]

---

valerie Inshan wrote:

Go to advanced menu > debug settings > meshMaxConcurrentRequests. The default value is 32. Set it higher if needed until you can see mesh correctly.

---

Actually what Linden Lab recommends is this:

http://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Release/3.6.14.285253

Mesh2MaxConcurrentRequests

    Controls the maximum number of concurrent mesh download requests issued by the viewer. If you encounter unreliable networks or routers or have a low-bandwidth connection, you might find that lowering this value improves your experience. [default value is 8]

 

MeshUseGetMesh1

    If set to TRUE, the viewer will revert to the original HTTP scheme for downloading meshes. (This also re-enables the old MeshMaxConcurrentRequests setting [default value is 32].) We don't imagine any scenario where this might be needed. But it's available as a possible workaround for unforeseen problems

 

It was noticed that setting the old MeshMaxConcurrentRequest to high values actually may make things worse than better. High setting also increased server loads increasing general lag.

 

[Coby Foden]

---

Theresa Tennyson wrote:

---

valerie Inshan wrote:

The LOD is more for sculpties than mesh. Go to advanced menu > debug settings > meshMaxConcurrentRequests. The default value is 32. Set it higher if needed until you can see mesh correctly.

---

Okay - this will take a while:

1) RenderVolumeLOD is for both scupties and mesh, and will have the same effect.

2) MeshMaxConcurrentRequests is only for the number of simultaneous mesh fetches that the viewer will do; it has nothing to do with the actual rendering of the mesh itself.

3) Turning up MeshMaxConcurrentRequests was a major contributor to sim lag on crowded regions a couple of years ago because people set it to ridiculous settings that would cause the server to try to send send massive amounts of data over and over again.

4) Since then, it's been capped both at the server level and in the viewer - actually I think 32 is now the

upper

limit for the viewers and the default is 16; it may be even lower now.

---

I checked in Second Life 3.7.20 (296094):

I saw that MeshMaxConcurrentRequests was 16. I clicked the "Reset to Default". It changed to 32. It is still possible to use higher value than that, it's not locked in that value as a maximum.

Anyway, if the MeshUseGetMesh1 is in its default setting [= False] then the MeshMaxConcurrentRequests has no effect at all (it's disabled).

[Perrie Juran]

Just adding in for reference:

So actually it's better to use a smaller concurrency in that case so requests have a chance to finish within the timeout.

 

I'll confirm that this is the better strategy for the stated reason and for several others.  Higher concurrency increases the chances of a retry/failure cascade.  These come along with warning messages in the SecondLife.log file that include:

  Timeout or service unavailable, retrying.

Each of these represents connection churn (disruptive to certain routers and other gear as well as detectable as a DoS/SYN flood) and a possible charge against future requests at servers.  Too many of these too fast and all mesh download service will stall indefinitely.  I have seen this at 32 but never 16.  Reduce those messages and you should be heading in the right direction.

Monty Linden: LINK

 

Also see: Nalates Blog

[ChinRey]

---

Tenly wrote:

..but everytime I come back into SL its setback to the default.

---

I can think of two possible explanations. One is that your setting.xml file has become corrupted. Perhaps it's a good idea to just remove it (or move it somewhere else in case you need to replace it) and let the viewer generate a brand new one.

Another possible (but not plausible to be honest) explanation is that your LOD setting is too high. Lots of people believe that increasing the RenderVolLODFactor doesn't add lag. That's a truth with modifications. The LOD factor doesn't seem to affect the server, network or your CPU's performance but it does affect the load of your GPU. That means objects stay grey a little bit longer before the textures appear and - more significantly here - they remain at a lower LOD model for a little bit longer before they switch to a higher one. Setting the LOD factor too high may actually decrease, not increase your LOD.

 

---

Gaia Clary wrote:

I always thought it is one of the major advantages of mesh that we can optimize the LOD, while for Sculpties the LOD's are predefined.

---

You can make sculpts LOD resistant too by strengthening crucial points or by increasing the bounding box size.

But you have a point. One of the advantages of mesh is that it gives you far better control over the various LOD models. Unfortunately this isn't nearly as simple as it should be. Documentation is scarce, hard to find and usually rather difficult to understand and the automatically generated models the uploader offers, don't really help much either. As a result, much (perhaps most) of the mesh we see in SL is far from optimized and have unnecessarily low LOD and high LI and lag.

 

[Perrie Juran]

---

ChinRey wrote:

---

Tenly wrote:

..but everytime I come back into SL its setback to the default.

---

I can think of two possible explanations. One is that your setting.xml file has become corrupted. Perhaps it's a good idea to just remove it (or move it somewhere else in case you need to replace it) and let the viewer generate a brand new one.

 

---

It's an odd one because I know many people who randomly find it reset to default.  I have to check it periodically.  For me it is not necesarily with every relog.  There is no other setting I have that problem with.

[Drongle McMahon]

It's an odd one because I know many people who randomly find it reset to default.  I have to check it periodically.  For me it is not necesarily with every relog.  There is no other setting I have that problem with.

Perhaps it is getting reset every time a new viewer version is auto-installed?

[Perrie Juran]

---

Drongle McMahon wrote:

It's an odd one because I know many people who randomly find it reset to default.  I have to check it periodically.  For me it is not necesarily with every relog.  There is no other setting I have that problem with.

Perhaps it is getting reset every time a new viewer version is auto-installed?

---

I'm on Firestorm myself, haven't been any updates recently.

The reports  I've heard have been for both FS and the Official viewer.

(I really dislike when settings get reset by an update.  Very glad FS has a "back up settings" function.)