Object LOD question/observation

[Jackson Redstar]

this is based on the FS viewer 6.6.8 (68380)  but  this more about object LOD in general. I had a strange situation last nite shooting a wedding where some items 'un rendered' often when I zoomed closer into them. I tried all the usual tricks - zooming way out and snapping back in, turning off dynamic adjust LOD.. usualy when something isn't rendering right you would turn up the LOD a little, but as I was sliding the slider up and down I noticed that at .876 everything was there in the scene - benches, candle sticks, etc. any higher those objects would un render again. of course some objects worn, like glasses, needed LOD to be at least at default - 2 - so I had to go from .876 to 2 depending on what I was shooting. I really hadn't seen it where lowering the LOD would make some object render normaly - but I had seen this issue in the past on occassion but could never figure out what was going on. Can any one explain why this is - that some oblects need this really low LOD to appear "normal"? I would guess it has something to do with how they are made but still it doesn't make much sense. Is there some other setting besides LOD that would keep items like that rendered normaly?

[Chic Aeon]

Don't have an answer but on the same viewer number:

 

You can look at the triangle count in the build menu.

 

This is a pretty typical scenario with high to low numbers. Sometimes the lowest setting is VERY low and sometimes that is fine depending on the object. 

In theory I guess someone could have made the LODs "backwards" with the bigger number at the bottom and not much up top (likely because they didn't understand how LODs work?).   If the place is still set up you can go back and check that and also check on the Linden viewer.  

I haven't ever seen this but I am interested in any comments.

ALSO the LODs can go wonkie if you have zoomed in to via the viewer with Ctrl + 0 and then forgotten about it. I have had THAT hjappen long ago.   

[Henri Beauchamp]

This is due to the viewer capping the octree size (RenderMaxNodeSize): the larger the number of vertices, the bigger the vertex data in the octree, so the highest the LOD factor setting and the closer the camera to high-vertices count objects, the more likely you will hit the configured limit, and when it happens, the viewer simply skips rendering the whole spatial group (and since the objects are grouped in a humanly unpredictable way, you can see a seemingly ”random” group of objects vanishing from your screen at once).

This is one of the reasons why it is a bad idea to push the RenderVolumeLODFactor setting too much (anything beyond 3.0 should be unnecessary and can really become toxic in render-heavy places).

Sadly, some meshes are so badly designed that they will crumble to a low LOD even at short distance, and the incompetent creators of such meshes will most likely recommend that you push that setting to 4, 5 or even 6...

To work around those issues, I implemented a ”Mesh objects boost factor” in the Cool VL Viewer: it may vary between 1.0 and 3.0, with 2.0 as the recommended max value, and allows to keep the Objects LOD factor at 3.0 or less, while still seeing the badly designed meshes rezzing properly: this new factor is in fact simply multiplied with the RenderVolumeLODFactor (i.e. the Objects LOD factor) but only when the latter is applied to mesh objects, meaning non-mesh objects may keep using a more reasonable value that won't fill up too fast the octree. Also, as soon as you set the boost factor above 1.0 (which is the ”no operation” value), mesh objects get a ”discount” on the number of vertices they are accounted for against the RenderMaxNodeSize limit (meaning the latter gets overridden when there are a lot of meshes around, but the viewer will not stop the resulting bloated octree from rendering); this of course comes at a cost in VRAM usage and FPS rates...

In other viewers, to try and work around the vanishing objects issue, you can stay at 3.0 max for RenderVolumeLODFactor and increase the RenderMaxNodeSize (it is set at 65536 KB by default in recent viewers which got the ”performance viewer” changes implemented; the old default value was 16384KB)...

Edited July 14, 2023 by Henri Beauchamp

[Jackson Redstar]

Thanks Henri. I gotta say I never understood the whole LOD thing that much other that more is better - to a point, I just figured what I was seeing was "old mesh" Question though - if I run into this situation again other than settings object LOD on a really low value - is there any other tweeks like in debug settings to keep the items rendered (I have the latest version FS and the RenderMaxNodeSize is already as you mentioned above)

Edited July 15, 2023 by Jackson Redstar

[Henri Beauchamp]

6 hours ago, Jackson Redstar said:

Question though - if I run into this situation again other than settings object LOD on a really low value - is there any other tweeks like in debug settings to keep the items rendered (I have the latest version FS and the RenderMaxNodeSize is already as you mentioned above)

You can manually increase the configured value: as long as your system is strong enough, doubling it should not be much of an issue...

[Beq Janus]

The derendering when you zoom in close is only slightly related to LOD, it is precisely what @Henri Beauchamp describes.

I get called to investigate such things a couple of times a year on average, the common cause is sports shoes (seriously). People model every last detail on a shoe that nobody is going to look at for more than 5 seconds, and then they set out 20 of them on a stand at an event. The poor merchant in the stall next to them will frequently find that some of their own products are not showing up for some people because, as Henri noted, the cutoff is simply based on how much is stuffed into "this part of the scene", and once it passes a limit everything else is arbitrarily discarded. The issue is ancient, but sadly people are still making over complex items, and I don't expect them to stop any time soon.

Edited to add: Another common cause is table decor, flowers and serving places. Possibly why you found this at a wedding. Here is an example from a few years ago where the creator themselves was confused by the behaviour (https://jira.secondlife.com/browse/BUG-225107)

 

 

https://jira.secondlife.com/browse/BUG-1509

The FS default for that setting has been 64MB for as long as I can recall. Runitai notes that the LL default was 64 in 2013 so It does beg the question as to whether a larger default would be better suited in this day and age, perhaps something that scales to the RAM/VRAM available.

Sadly though, we are once again making the viewer compensate for unsociable, irresponsible asset design. 

 

Edited July 19, 2023 by Beq Janus

[Ardy Lay]

6 hours ago, Beq Janus said:

unsociable, irresponsible asset design

An un-punished crime...  If there is no enforcement, then there is no correction.  Currently the creators of this stuff think they are in charge.  Next time some ass tells me to "Crank up the volume LOD!" I am gonna...  I am going to ....  what?  What can I do?  Not buy their crazy?  Too late.  They already got my money and won't give it back because I am failing to follow instructions.  "Leave a negative review" doesn't work either because they get those removed and reviews with details don't work anyway because so many people have been sucking down the rhetoric that states that Linden Lab doesn't know what they are doing, use (third party viewer) and these special settings to fix all that stuff Linden Lab cannot fix.  It's really a big mess.

I think I should be able to submit a report to a special task force that takes these items, examines them, then SPANKS the item's creators for a period of time and with intensity proportionate to their crimes!  Uhm, some of them would probably like that though.

[animats]

I'd like to have LOD enforcement when objects are uploaded to Marketplace. A proposal:

For non-clothing items, once we have glTF mesh uploads:

• The Marketplace system should generate a panorama preview of the object. See what you're getting before you buy. This is easy to implement with glTF objects, because how to render them is well-defined by a standard and there are many open source renderers that can display them. If you upload textures with the meshes, you get a textured preview. Otherwise, it's just grey. This encourages uploading textures and mesh together. You can still have other textures, but there should be a primary set. With glTF, you can export textures and meshes as a linkset from Blender/Maya. (In theory you can do this with COLLADA, but it doesn't work right for SL.)
• Generate panoramas for each LOD. Find out if it has bad lower LODs before you buy. The Marketplace web site might display a big image for the high LOD, and smaller images for the lower LODs.
• Use basic automated image comparison for quality control. Downsize the big panorama to each lower LOD size and run an image compare program. The minimum requirement is that textured outlines must roughly match. Don't even let those go on sale on Marketplace. This rejects lower LODs with holes in them.
• Find or implement a mesh reduction algorithm for the uploader that has "silhouette protection". Unreal Engine 5, for example, has that. This means the outline will roughly match for default automated LODs, and they will pass the test above.

Clothing items have a different set of problems. Maybe they could be displayed rendered on something like a dressmaker's dummy.

 

[mikka Luik]

For another 'marketplace' I used to post stuff to sketchfab and that was either dae or obj (been a while) so not even needing the newish format. So yes not a bad idea at all. Would mean reloading a bunch but fair enough. . For SL I have the stuff rezzed out but thats just me  

[Beq Janus]

15 hours ago, animats said:

I'd like to have LOD enforcement when objects are uploaded to Marketplace. A proposal:

For non-clothing items, once we have glTF mesh uploads:

• The Marketplace system should generate a panorama preview of the object. See what you're getting before you buy. This is easy to implement with glTF objects, because how to render them is well-defined by a standard and there are many open source renderers that can display them. If you upload textures with the meshes, you get a textured preview. Otherwise, it's just grey. This encourages uploading textures and mesh together. You can still have other textures, but there should be a primary set. With glTF, you can export textures and meshes as a linkset from Blender/Maya. (In theory you can do this with COLLADA, but it doesn't work right for SL.)
• Generate panoramas for each LOD. Find out if it has bad lower LODs before you buy. The Marketplace web site might display a big image for the high LOD, and smaller images for the lower LODs.
• Use basic automated image comparison for quality control. Downsize the big panorama to each lower LOD size and run an image compare program. The minimum requirement is that textured outlines must roughly match. Don't even let those go on sale on Marketplace. This rejects lower LODs with holes in them.
• Find or implement a mesh reduction algorithm for the uploader that has "silhouette protection". Unreal Engine 5, for example, has that. This means the outline will roughly match for default automated LODs, and they will pass the test above.

Clothing items have a different set of problems. Maybe they could be displayed rendered on something like a dressmaker's dummy.

 

While I agree that more information can do no harm; indeed, the reason I added the in-viewer LOD preview on FS was to increase the visibility of this issue and enable "look before you buy". None of these tools overcomes the basic problem of consumer indifference and creator time-to-market pressure. 

While as users, we may collectively curse the erratic frame rates, the FPS killers and the texture hogs. As individuals, we are all too willing to tolerate a bad item if it serves our needs. I don't think that uncosted bad assets will be halted by pretty pictures and information overload. If the server on upload were able to reject poor assets or, more realistically, if worn assets carried a proper impact cost, that would prevent entry to regions that were already at "capacity", then we'd get appropriate pressure on creators to be economical with render impact in the same way as we see with land impact for non-worn items.

I have written this before here I am sure; right now the market pressures are entirely wrong. Creators are expected to produce new, unique items on a very regular basis if they are to stay at the top of the market. A 1 million poly dress is not going to sell fewer units than a 50K poly dress, but the 50K poly dress takes time, effort and some skill to retopologise properly and so there is no revenue incentive to spending that time, it is a very simple commercial choice to say "screw it, good enough, it'll sell". Many conscientious creators out there will take the extra steps, and we should celebrate those because the reward for them in doing so is higher production costs and possibly lower sales, a sacrifice made to help us keep performance higher. You also have the argument that those who do optimise lose sales because the side-by-side comparison with a ludicrously over-dense dress makes their offering look less appealing visually and looks win the day. 

Ultimately we need enforcement, a tangible penalty/cost that incentivises good asset creation, but we also know that this is a pretty tough nut to crack.

 

 

 

 

[Perrie Juran]

23 hours ago, animats said:

Clothing items have a different set of problems. Maybe they could be displayed rendered on something like a dressmaker's dummy.

I have for a long time advocated that Merchants be required to post the complexity of their clothes in their MP Listings.

It could serve two factors.  One, over all bring more awareness to the issue of complexity  and Two, embarrass some creators into better optimizing their offerings.

It has been a long time  mantra with mesh clothes, "No Demo, No Buy." One day it occurred to me that I should be checking more than just the fit when I demoed but the complexity also. I will skip that pair of shoes that raised my complexity by 30,000 points.

[Wulfie Reanimator]

4 hours ago, Perrie Juran said:

I have for a long time advocated that Merchants be required to post the complexity of their clothes in their MP Listings.

It could serve two factors.  One, over all bring more awareness to the issue of complexity  and Two, embarrass some creators into better optimizing their offerings.

It has been a long time  mantra with mesh clothes, "No Demo, No Buy." One day it occurred to me that I should be checking more than just the fit when I demoed but the complexity also. I will skip that pair of shoes that raised my complexity by 30,000 points.

Complexity still has the problem of it being a useless, easy-to-manipulate number. Look at some of your attachments with the "performance tools" in Firestorm. The attachments that take a long time to render are often the ones with low complexity, and high complexity attachments are the opposite. It's not consistent at all.

Edited July 21, 2023 by Wulfie Reanimator

[Ardy Lay]

The quantity of time required to render my avatar on my computer is varying from 63 to 120 microseconds, without me moving the camera.  There are 4 avatars here dancing.  Until you know that my computer is an Intel i9-13900k with an NVidia RTX 4080 GPU that time doesn't mean anything to you.  It might still not mean much.  When I move to another region and sit on a pillow it takes a few more microseconds to render my avatar.

Edited July 21, 2023 by Ardy Lay

[Wulfie Reanimator]

Let's not forget that complexity values are completely arbitrary unlike measured render time. While the 'absolute values' (exact microseconds) don't have much meaning, you can still make relative comparisons between render times and complexity to conclude that there is no correlation between the two. When we look at our avatars, we should expect higher complexity items to take longer to render, but that's often not the case!

Related reading:
https://beqsother.blogspot.com/2021/11/i-dont-wanna-mesh-with-nobody.html
https://beqsother.blogspot.com/2021/12/upgraders-of-lost-arc.html

Edited July 21, 2023 by Wulfie Reanimator

[Ardy Lay]

In this world of meaningless and superfluous standards, maybe we should create one more?  The render cost scale to rule them all!  Uhm, never mind that.  There is already a comic about it.

I just use the avatar render time chart to know that my friends whom I want to see have the avatars that take the longest to render, and, thus, I do nothing about it.  Well, I did spend a few thousand U.S. Dollars to build a new computer for the sole purpose of running Second Life on it, but, silly me got a curved 5120 x 1440 display for the GTX 4080 and SL won't let me "zoom out" because it already has a 180 degree field of view at that aspect ratio.  Also, the Intel i9-13900k is bored and loafing most of the time.  When the camera moves about there is a flurry of CPU activity when the worker threads discover all those idle cores and go nuts sucking down lots-O-watts for brief moments.