Jump to content

How to change LOD Factor in SL Viewer?


Jaylinbridges
 Share

You are about to reply to a thread that has been inactive for 864 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

How to change LOD Factor in SL Viewer?

Where is it in SL viewer?  I have looked everywhere including debug settings.

Never mind, found it in debug settings as RenderVolumeLODFactor   Debug Search window can't just find LOD, unlike TPV viewers.  You need to know to search for RenderVolume to find LOD by scrolling down.

Are you kidding me?  The SL Viewer default for the LOD factor is 1.000 ?  No wonder newbies can't see things in SL.

 

 

Edited by Jaylinbridges
.
  • Like 1
Link to comment
Share on other sites

30 minutes ago, Lyssa Greymoon said:

FWIW its the Objects slider in advanced graphics preferences. The default setting depends on your GPU. 

Hmmm, that makes no sense either. I can run it at 4.000 in FS with two accts running.  I never seen any lag no matter where I set it.  Only difference is immersion, since some older 1 prim mesh objects turn into a single triangle 10 meters away.  The default is 1.125 on the SL viewer at every Quality setting from Low to between Ultra and Mid. 

If I set Quality to Ultra, it defaults to 2.000, while on the other settings it defaults to 1.125 LOD.  This is nonsense.  Nothing to do with my GPU card.  In debug the max value moves to 2.000 LOD in Ultra,  and is still too low for some objects at a distance.  So this means anyone with an NVidia card that is good for 100 fps XXX06Ti series,  will run their LOD at the 1.125 default, unless they manually set it?   Why is the SL Viewer set to give the worst immersion for the newbies that run it?

In Debug the Reset to Default is always 1.000, which is ridiculously low for my NVIDIA card.  Clearly it's not setting according to my GPU, at 1.000.

I run my LOD at 3.000 in FS because I like to actually see objects when I am not sitting on them.

 

Edited by Jaylinbridges
  • Haha 2
Link to comment
Share on other sites

1 hour ago, Ansariel Hiller said:

Wrong question! The correct question would be: Why are content creators creating crappy content and not providing proper detail levels other than high detail?

because they use firestorm with a LOD factor higher than other clients and it looks fine to them .... ?

*ducks and runs away*

  • Like 3
  • Thanks 2
  • Haha 4
Link to comment
Share on other sites

To the OP - also try the debug setting RenderVolumeLod and give it whatever figure you choose. Jut don't tell anybody you're dong it.

 

To a few others - I'm an old Laissez-Faire Liberal, I don't see why people can't put their Lod setting where THEY want it to be.

Oh, I just realiesd, it would deprive the forums of a significant number of posts?

Ok, Stet

 

 

Edited by Profaitchikenz Haiku
Link to comment
Share on other sites

2 hours ago, Profaitchikenz Haiku said:

To the OP - also try the debug setting RenderVolumeLod and give it whatever figure you choose. Jut don't tell anybody you're dong it.

 

To a few others - I'm an old Laissez-Faire Liberal, I don't see why people can't put their Lod setting where THEY want it to be.

Oh, I just realiesd, it would deprive the forums of a significant number of posts?

Ok, Stet

Why the snark? Of course you can use whatever LOD setting you want, it doesn't affect anyone else. Nobody was giving OP a hard time for using the debug setting.

What does affect everyone else (and forces more people to increase their LOD setting regardless of whether their hardware can handle it) is content creators making terrible content that's useless at lower settings, like Ansariel pointed out.

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

13 hours ago, Wulfie Reanimator said:

Why the snark?

Since it's you asking, I'll give a sensible reply. (I am no boojum),

It's just push-back.

The existence of creations requiring a higher-than-normal LoD setting is well-known and irreversible, and while it is lamentable, it's not a game-killer. However, I recognise it does raise the hackles of several people who like to remind us, in case we forget, that it's the fault of creators who should know better. I, in turn, like to remind people that there are far worse sins.

  • Like 1
Link to comment
Share on other sites

On 2/7/2022 at 4:21 AM, Jaylinbridges said:

Never mind, found it in debug settings as RenderVolumeLODFactor   Debug Search window can't just find LOD, unlike TPV viewers.  You need to know to search for RenderVolume to find LOD by scrolling down.

Are you kidding me?  The SL Viewer default for the LOD factor is 1.000 ?  No wonder newbies can't see things in SL

Quoting my first post Prof, I know where it is.  Maybe I should correct the thread title to something more snarky :)

Edited by Jaylinbridges
New title: why does SL Viewer hate newbies?
  • Haha 1
Link to comment
Share on other sites

I have never seen those GPU tables affect my Graphics settings.  But then I have my NVidia Image settings set to "Use the advanced 3D image settings" in the NVIDIA control panel, so I wouldn't expect the SL viewer to try to mess with my detailed settings.  Maybe that explains why my popular and common card used in SL and mid level gaming is not recognized.  I think it is in the table, and its hardly a Class 0 obsolete potato card.  I can still buy a new one for $1200 usd.

I asked where to find the LOD in debug (before I found it - I used Firestorm debug search to find it btw), because a friend still on the SL Viewer removed some cute little snowmen for our winter landscape.  They were 1 prim mesh each, and if LL had designed them, they would be 5 prims.  But they were also a freebie seasonal  item, hardly worth much effort on  the designers part.  

I asked why she removed them, and she said they were just a triangle 10 meters away.  But with my LOD set at 3.000 in FS, I could see them 30 meters away.  So I asked her to increase her LOD setting.  Of course it is hidden in debug, and called simply Objects in advanced graphics.  Objects also maxes out at 2.000 in the SL Viewer.  

Now this is just the sort of simple object that a newbie, with their $25L/week skybox and a generous LI limit of 15 prims might buy - low prim because after the sex bed they only had 5 prims left, and free, from a freebie place where there is a load of badly made early mesh.  And because their SL viewer thinks 1.125 is a suitable LOD, they watch the snowman break into a triangle 10 meters away.  Their conclusion - SL is really primitive because they can't even make a snowman I  can see across my room,   And then they tell their friends, and they all quit SL when their week rent is up.    And another sex bed goes unused forever...

Edited by Jaylinbridges
  • Like 1
Link to comment
Share on other sites

58 minutes ago, Jaylinbridges said:

Quoting my first post Prof, I know where it is. 

Oh gosh crikey, yes you did. I missed that. Maybe I need to go to the optician and ask for some glasses with a higher Lod factor different focal length :)

 

59 minutes ago, Jaylinbridges said:

Maybe I should correct the thread title to something more snarky

There are days when I feel like changing my sig to a line from Screamin' Jay Hawkins, but let's not go there until we absolutely have to :)

  • Haha 1
Link to comment
Share on other sites

2 hours ago, Jaylinbridges said:

I asked where to find the LOD in debug (before I found it - I used Firestorm debug search to find it btw), because a friend still on the SL Viewer removed some cute little snowmen for our winter landscape.  They were 1 prim mesh each, and if LL had designed them, they would be 5 prims.

But then they also might have come with proper detail levels so you don't have to crank the LOD in the viewer up to 1,000,000... So called "creators" often leave out lower and medium detail levels to cheat the LI system so they can advertise "all this great stuff and only 5 LI" - and add a notecard telling people to just crank up the LOD value to have their content "viewed best".

  • Like 5
Link to comment
Share on other sites

16 hours ago, Wulfie Reanimator said:

Why the snark? Of course you can use whatever LOD setting you want, it doesn't affect anyone else. Nobody was giving OP a hard time for using the debug setting.

What does affect everyone else (and forces more people to increase their LOD setting regardless of whether their hardware can handle it) is content creators making terrible content that's useless at lower settings, like Ansariel pointed out.

Not true. The LOD setting affects the download stream, which affects the system and everyone downloading assets. Better connections have reduce the effect. The viewer will request the LOD level it needs and download just that file. At LOD 4 it always pulls the high resolution LOD model.

These days users aren't as ***** about the effect as they once were.

2 hours ago, Jaylinbridges said:

I have never seen those GPU tables affect my Graphics settings.  But then I have my NVidia Image settings set to "Use the advanced 3D image settings" in the NVIDIA control panel, so I wouldn't expect the SL viewer to try to mess with my detailed settings.  Maybe that explains why my popular and common card used in SL and mid level gaming is not recognized.  I think it is in the table, and its hardly a Class 0 obsolete potato card.  I can still buy a new one for $1200 usd.

As long as you use the same computer or similar level of computer you won't see a change or effect.

I use a custom set of graphics settings. I came into SL when it was a thing for novice and intermediate users to tweak their viewer settings for a personalized balance of quality and speed. I also played in combat RP games within SL. They required you optimize to have any chance of avoiding slaughter. The forum was filled with frequent posts of how to and what was best. So, on those occasions where I had to make a clean install, which also used to be a thing, I saw those viewer GPU tables kick in. However, the use of the tables changed a couple of years ago. The Lab first made the tables a downloaded file rather than an installed file. Then they changed away from total dependence on the tables to a set of graphics tests to determine how to set the default settings for the computer the viewer is running on.

Once you customize your graphics settings the viewer will not override them.

 

  • Like 1
  • Thanks 1
  • Haha 1
Link to comment
Share on other sites

19 hours ago, Profaitchikenz Haiku said:

To a few others - I'm an old Laissez-Faire Liberal, I don't see why people can't put their Lod setting where THEY want it to be.

Of course they can, as long as they don't then come to the forums whining about horrid performance that is due to their high LOD setting.

And as long as creators don't do it and build to that high LOD settings.

 

  • Like 1
Link to comment
Share on other sites

18 minutes ago, Nalates Urriah said:

Not true. The LOD setting affects the download stream, which affects the system and everyone downloading assets. Better connections have reduce the effect. The viewer will request the LOD level it needs and download just that file. At LOD 4 it always pulls the high resolution LOD model.

 

That is... i think not true at all. The Viewer cannot request certain LOD's of meshes. A mesh is a single file that contains all data for all LOD's, the Viewer always requests that single mesh file which will give it all information required to display all LOD's. If the Viewer had to re-request the same mesh over and over in different LOD's that would be... beholyjeebuschrist. I know LL does stupid things sometimes but that would be downright evil.

  • Thanks 2
Link to comment
Share on other sites

Uh-oh, what have I gone and done?

 

MY working assumption seems to be that of Nran,  my viewer will download all the objects, all the avatars, all their attachments, all the textures including bump and specular, but then the fun begins with how much I let it load to the scene on the screen. Have I told it to not bother with avatars above a certain complexity? Have I told it to not show bump and specular by turning off ALM, have I said I want a low draw distance , and do I want things to degenerate into triangles or not? My personal settings don't impact those around me.

Back in 2010 there was a belief that somebody with a very high bandwidth setting would cause lag in those around them by grabbing all the server resource and hogging them. The misconception seems to have shifted away from the bandwidth slider to the LoD setting.

Edited by Profaitchikenz Haiku
Link to comment
Share on other sites

There is a lot of confusion about mesh levels of details (LOD) and the volume LOD factor. The LOD factor (the one you can change in the graphics settings via the ”Objects LOD” slider which is linked to the RenderVolumeLODFactor debug setting) determines how fast you switch from one LOD to the next as the distance to camera decreases.

As for meshes, while Niran is right in saying they are a single asset file, he is wrong in saying that the viewer cannot request certain LODs of a mesh; that file can indeed be requested only in part, meaning that you can download only the mesh header and the lowest LOD and not the highest LOD, for example; however, as your camera gets closer to that mesh, new LODs get loaded, and in the end you can obtain a fully downloaded mesh asset file cached on your hard disk (next time you will see this mesh, the viewer will then fetch it from the cache whatever the selected LOD).

Poor meshes (with poor ”medium” and ”low” LODs) often do not display properly until their highest LOD is selected (and this selection is based on the camera distance and the LOD factor). This is why some creators are recommending to push the RenderVolumeLODFactor setting beyond its normal value. Be aware however that doing so, you risk seeing group of objects suddenly disappearing when you get close to them: this is because there is a limit in the vertex buffer size a render group can use (governed by the RenderMaxNodeSize debug setting), and the higher the selected LODs for these groups of objects, the higher the number of vertices to render... When the limit is reached, the viewer pulls off the whole group from the render pipeline.

Edited by Henri Beauchamp
  • Thanks 2
Link to comment
Share on other sites

4 hours ago, Monty Linden said:

It's true.  The process is described at the beginning of llmeshrepository.cpp.

12 minutes ago, Henri Beauchamp said:

There is a lot of confusion about mesh levels of details (LOD) and the volume LOD factor. The LOD factor determines how fast you switch from one LOD to the next as the distance to camera decreases.

As for meshes, while Niran is right in saying they are a single asset file, he is wrong in saying that the viewer cannot request certain LODs of a mesh; that file can indeed be requested only in part, meaning that you can download only the mesh header and the lowest LOD and not the highest LOD, for example; however, as your camera gets closer to that mesh, new LODs get loaded, and in the end you can obtain a fully downloaded mesh asset file cached on your hard disk (next time you will see this mesh, the viewer will then fetch it from the cache whatever the selected LOD).

That is a major oof. And they say I'm a pessimist always imagining the worst. This IS (almost) the worst. I mean i'm not surprised i was kinda expecting something along the lines but... wow. Just wow. Why? This is so incredibly inefficient, why would the Viewer request 4 separate pieces of the same mesh file when .... oh this is Second Life i forgot. Right... right.

Seriously why request essentially the same file 4 times just 4 different pieces of it, that's 4 times the amount of requests and 4 times the chance to fail/bork something. ESPECIALLY considering that the Viewer is expected to switch between LOD's quickly at any given time, the point of requesting them separately is completely mood, you should straight away download the entire asset. This explains why some LOD's of meshes fail sometimes.. for apparently no reason... and all this time I thought it was a failure on the Viewer side somewhere in the mesh rendering/decoding or something...

It's as if you expect the Viewer to only ever see only a single LOD ever for a long time... as if you wanted everyone to turn off LOD's...

One of these days I'll have an heart attack ...

Edited by NiranV Dean
  • Like 1
Link to comment
Share on other sites

@NiranV Dean I am afraid you are wrong. The viewer mesh repository does a pretty good job downloading quickly the needed LODs to display the scene; there is no point in downloading megabytes (mesh assets can be huge !) of data to display at LOD1 a mesh in the distance.

Granted, LL's code can be (and has been, by some TPV devels) optimized for even better performances (try the Cool VL Viewer, and you will see what is a fast rendering viewer).

As for download failures, they do happen, especially with buggy libcurl versions when using the HTTP pipelining feature, which is great to speed up requests, but sadly can lead to corrupted downloads with all libcurl versions greater than v7.47 (and I am speaking of LL's patched libcurl v7.47, because the official/upstream libcurl v7.47 also had HTTP pipelining bugs). Thus why I keep using that old libcurl in the Cool VL Viewer... If your viewer uses a newer libcurl and you are experiencing failed mesh LOD downloads (and/or rainbow textures), disable HTTP pipelining.

Edited by Henri Beauchamp
  • Thanks 1
Link to comment
Share on other sites

6 minutes ago, Henri Beauchamp said:

@NiranV Dean I am afraid you are wrong. The viewer mesh repository does a pretty good job downloading quickly the needed LODs to display the scene; there is no point in downloading megabytes (mesh assets can be huge !) of data to display at LOD1 a mesh in the distance.

Granted, LL's code can be (and has been, by some TPV devels) optimized for even better performances (try the Cool VL Viewer, and you will see what is a fast rendering viewer).

We are downloading gigabytes worth of textures. A couple more megabytes per mesh don't matter. You're essentially cutting down on potentially 75% of the amount of requests needed to be sent, this both helps the server and the client having to process less messages and like I said, if you only ever download a single LOD you are expecting this LOD to stay for a while which is never the case unless you outright disable dynamic LOD and force a certain quality level. It's completely pointless downloading fragments of a file when you'll ultimately and quickly end up downloading almost the entire file anyway shortly after, especially since lower LOD parts are the much smaller fraction of the file, downloading the highest LOD (which is what is most often desired anyway) already takes the lions share of the file. Not to mention our cache isn't infinite so we'll end up recycling our cache at some point requiring us to re-request potentially 4 parts again, this for every single avatar in the entirety of SL, for hundreds and thousands of objects, every day, this adds up. I can understand that this may have been necessary at the times of UDP messages where they weren't exactly reliable and having only one part fail wasn't that bad or where they would have to save on bandwidth due to the limited amount of bandwidth per user (when downloading) but this time is long gone. Content download really isn't that slow anymore but is artificially slowed down and spread for no good reason, it only hurts the Viewer and the Server. I'd rather prefer to download a couple extra megabytes but get the entire file right away putting LOD handling entirely on the Viewer side right away without having it potentially be stalled for long periods because some LOD changed somewhere that hasn't been downloaded. Optimizing this process to be faster is just polishing a turd to be a shinier turd, it's never going to be a diamond. Everything ever does this and for a good reason but once again SL has to be a special snowflake.

Add an option to force the viewer to always sent a single "get me the entire file" message. I'll gladly use it. It should also speed up my Viewer loading meshes tremendously.

Edited by NiranV Dean
Link to comment
Share on other sites

1 minute ago, Henri Beauchamp said:

Not going to argue forever with you. Just keep in mind that you rarely ever need (in fact almost never) to download all the LODs of all the meshes in a sim. Downloading everything on the pretext that it saves HTTP requests is a total overkill. Period.

With a non-max LOD forcing value (which everyone has anyway) just zooming your camera or simply walking through the region once should already have you download 2-3 out of 4 LOD's easily (including the max LOD and the probably the lowest or second lowest with in-betweens usually being skipped, hopefully due to how fast you might be closing in, at least when using your camera). I highly disagree. Every other similar platform does it too, VRChat, NeosVR... and avatars in VRChat can easily reach hundreds of megabytes (if they include sounds, *****loads of 4k textures and many big rigged meshes with many blendshapes), and they don't have a problem doing it. Why do we have to split from the industry standard again? This kind of weird non-standard behavior in so many places is why SL is so ... lackluster, has so many issues, makes so little progress and often shortly after implementing such a behavior runs into problems (or later down the line when we realize that what we build was bad).

We already split all asset types (meshes, sounds, textures) into their own parts, this makes SL incredibly modular and allows us to download only what we need but doing this for mesh LOD's is simply going too far for the sake of going to far.

Edited by NiranV Dean
Link to comment
Share on other sites

  • Lindens
13 minutes ago, NiranV Dean said:

Add an option to force the viewer to always sent a single "get me the entire file" message. I'll gladly use it. It should also speed up my Viewer loading meshes tremendously.

This is trivial to implement and test for yourself.  In the above-mentioned code, disable the insertion of a byte range in the mesh request and the entire mesh asset will be downloaded with one request.  Repeat in the texture code, if desired.  Report back what you find!

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 864 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...