Jump to content

Proposal - FAST MESH


Coffee Pancake
 Share

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

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

Recommended Posts

10 minutes ago, Mollymews said:

in full screen mode 2560 x 1440 up in the sky sitting on a box on Evard region up at 1000meters (the closest rez zone to where I showed before)

nothing in the view except me in same outfit and the box. average about 64-65 FPS

Hmmm... that's not good, that's not good at all.

10 minutes ago, Mollymews said:

the big killer in SL is how much work the CPU has to do even when nothing is being rendered.

Yes, but it can't be that much, not in an almost empty scene.

Come to think of it, Skogholmen hasn't been online for a while so the performance figures I have for it are all pre EEP. Maybe that's what causes this huge drop in performance?

Edited by ChinRey
Link to comment
Share on other sites

1 minute ago, ChinRey said:

Hmmm... that's not good, that's not good at all.

Yes, but it can't be that much, not in an almost empty scene.

Come to think of it, Skogholem hasn't been online for a while so the performance figures I have for it are all pre EEP. Maybe that's what causes this huge drop in performance?

if nothing is being rendered then am not sure what effect EEP would have on this. I would have to do the same kinda test on a Windlight viewer to see if there is any difference

Link to comment
Share on other sites

46 minutes ago, Mollymews said:

if nothing is being rendered then am not sure what effect EEP would have on this. I would have to do the same kinda test on a Windlight viewer to see if there is any difference

I still have an old 32 bit Firestorm version installed so I just did a quick test on a set of empty sims on SoaS. I got 35% higher fps with it than with the latest 64 bit EEP enabled Firestorm.

I haven't been paying attention to performance figures recently. I'm mainly working on landscaping on SoaS at the moment and with my poor computer having to serve 30 4x4 sims in addition to running the viewer (and YouTube in the background of course) I don't expect great fps anyway.

Edit: Comparing the two scenes you showed us, the base build of a region - houses, roads, vegetation and other landscape fixtures - shouldn't really affect the performance much at all. That part of the scene doesn't need that many tris or texture pixels after all; for a scene like the one in the Bellisseria picture doesn't need more than - say 25,000 tris and 25-50 512 textures - and that's barely a noticeable load for any gpu. If you get 65 fps in an empty scene, you shouldn't get much less than 60 in an otherwise empty Bellisseria style scene, maybe down to the low fifties if those street lamps are switched on. But of course, we don't know what extra content there are hidden inside those houses so it's hard to draw a conclusion.

Edited by ChinRey
Link to comment
Share on other sites

3 hours ago, ChinRey said:

Edit: Comparing the two scenes you showed us, the base build of a region - houses, roads, vegetation and other landscape fixtures - shouldn't really affect the performance much at all. That part of the scene doesn't need that many tris or texture pixels after all; for a scene like the one in the Bellisseria picture doesn't need more than - say 25,000 tris and 25-50 512 textures - and that's barely a noticeable load for any gpu. If you get 65 fps in an empty scene, you shouldn't get much less than 60 in an otherwise empty Bellisseria style scene, maybe down to the low fifties if those street lamps are switched on. But of course, we don't know what extra content there are hidden inside those houses so it's hard to draw a conclusion.

i had a quick go on Cool VL Viewer with Windlight. When I run it with same settings as Linden up in the same Belli sky sitting on the box then I get the same about FPS as Linden. But if I enable Cool VL Viewer's custom shaders then I get 198-200 FPS. It motors!

on the Belli ground where I get 20 FPS with Linden then I get about 36 with CoolVL custom shaders so pretty much double

i did have a go on the latest Firestorm EEP and up in sky on the box with same settings as Linden EEP I only got about 45 FPS. Not sure what that's about

my basic point in all of this tho is that I just want to be able to see stuff that doesn't crumble, and Mole stuff doesn't crumble at LOD 1.125 even if it could be little less tris. 

Link to comment
Share on other sites

22 minutes ago, Mollymews said:

my basic point in all of this tho is that I just want to be able to see stuff that doesn't crumble, and Mole stuff doesn't crumble at LOD 1.125 even if it could be little less tris. 

Oh yes, that's because they don't really do LoD models at all. Most of the time they just use the same model for high, mid and low and butcher the lowest LoD model as low as it goes. It's the quick and dirty way to avoid LoD breakdowns. Effectively it means you disable the whole LoD function so it doesn't matter what your LoD factor is (unless you turn it way down to 0.5 or such that is). The downside is of course that by disabling the whole LoD function you won't get the performance improvements it's supposed to give either. It works with simple builds; keep the total number of tris down to 100,000 or less per sim and nobody should have any problems with it. (With draw distance as low as the default 128 you can even get away with 500,000 tris of unreduced mesh per sim but what's the point of large continuos landscapes with draw distance that low?) But the moment you start adding some more elaborate content and/or a couple of avatars, you start to hit ceiling fast. I wonder what Eric Linden would have said if he saw what his successors were doing. He was very lag concious. I know he ocne chewed out a poor new builder in public for using a 1024 on a house.

 

Edited by ChinRey
Link to comment
Share on other sites

  

14 hours ago, Mollymews said:

i go to places like Bellissaria and this is what I see

Benchmarking the SL viewer is exceptionally difficult.

Bellissaria is a terrible place to test. Sure the houses and road furniture are all consistent, but you can't account for what's going on inside those buildings or neighboring regions. It ends up being very chaotic unless you're very very careful about controlling what's in view. Just because you can't see something / someone, doesn't mean it's not killing your viewer.

Decide what you want to test - object performance, avatar performance, etc

Get an alt with no friends and no groups. Those can both mess with any numbers you're trying to get.

Find an isolated region that will consistently give you the same objects / people over and over again matching your test criteria. (avatars need to absolutely set in stone, no new avatars , no avatars leaving etc. (C list afk sex places are good for avatars - well made mesh avatars, always the same ones, no real people showing up to mess with your results). If you're not specifically interested in avatar performance, find a place with NONE and bomb your own avatar back to nothing but an alpha layer.

Go to the location, clear cache (and make sure the cache folder is added as an exception to your AV/ win defender) and spend a solid 20 camming about everything, give the viewer cache the best chance possible to have everything. Set you avatar up so its standing and looking exactly where you want it to. Log out. Log back in and touch nothing, wait for the FPS to plateau (after all the texture loading and decoding has passed). wait some more. seriously, touch nothing. write the numbers down from the stats floater. relog to the same point and do it again. If someone shows up, that test is junk. start over. 

(we went down the rabbit hole with Catznip using out own external profiling tools this last year to make up for the 20%+ EEP performance hit and that's why R13 is still only in beta and firestorm is releasing with our new RLVa features before we are)

  • Like 1
Link to comment
Share on other sites

This morning I met up with Molly at the same location as she posted her results from and performed similar tests with the latest Firestorm EEP viewer.  I replicated as much of the initial settings that Molly shows above though some aren't exact due to the UI having different options.  There are still a lot of differences, I appreciate that.  For one I am not even on the same OS as her.  Anyway it was fun and great to meet Molly inworld for the first time.  I am not expecting this to be taken as anything other than an interesting exercise and was mostly for my own curiosity.  I wore a completely mesh-free avatar for the test and had "Show Friends Only" turned on.

My setup:

Firestorm 6.4.13 (63251) Mar  2 2021 00:42:56 (64bit / SSE2) (Firestorm-Release)
Release Notes

You are at 128.5, 132.1, 1,000.5 in Evard located at simhost-059a82961cf0081ad.agni
SLURL: http://maps.secondlife.com/secondlife/Evard/129/132/1000
(global coordinates 264,577.0, 248,196.0, 1,000.5)
Second Life Server 2021-02-22.556255
Release Notes

CPU: Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz (3306.11 MHz)
Memory: 31962 MB
OS Version: Linux 5.4.0-66-generic #74-Ubuntu SMP Wed Jan 27 22:54:38 UTC 2021 x86_64
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce GTX 1080 Ti/PCIe/SSE2
Graphics Card Memory: 11264 MB

OpenGL Version: 4.6.0 NVIDIA 450.102.04

RestrainedLove API: (disabled)
libcurl Version: libcurl/7.54.1 OpenSSL/1.0.2l zlib/1.2.8 nghttp2/1.25.0
J2C Decoder Version: KDU v8.0.6
Audio Driver Version: FMOD Studio 2.01.08
Dullahan: 1.8.0.202011061705
  CEF: 81.3.10+gb223419+chromium-81.0.4044.138
  Chromium: 81.0.4044.138
LibVLC Version: 2.2.3
Voice Server Version: Not Connected
Settings mode: Firestorm
Viewer Skin: Firestorm (Grey)
Window size: 3840x2114 px
Font Used: Deja Vu (96 dpi)
Font Size Adjustment: 2 pt
UI Scaling: 1.5
Draw distance: 128 m
Bandwidth: 1500 kbit/s
LOD factor: 1.125
Render quality: Ultra (7/7)
Advanced Lighting Model: Yes
Texture memory: Dynamic (4096 MB min / 30% Cache / 5% VRAM)
VFS (cache) creation time (UTC): 2021-1-9T5:50:24
Built with GCC version 50400
Packets Lost: 100/172,043 (0.1%)
March 19 2021 06:14:29 SLT

This was the initial result:

265337080_Gabriele-PerformanceTesting1.thumb.jpg.aa30423a4133b4566a71633321bcd79d.jpg

If I turned off Ambient Occlusion however:

1578480640_Gabriele-PerformanceTesting1_003.thumb.jpg.ef356a12b63799a1ce344c8c20d225f5.jpg


However by the time I was done Molly was using the Cool VL Viewer and getting around 200fps in the same area somehow.  I may have to take a look and see how my setup works with that too considering there is a Linux build.

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

8 hours ago, Coffee Pancake said:

  

Benchmarking the SL viewer is exceptionally difficult.

for sure i agree with everything you have said about robust methodology. Otherwise any comparative results for other people are all pretty much meaningless

i have posted what I have as this is what I encounter and see going about my everyday SL with the computer that I have. I don't project that what I post is definitive for others. Just that this is what I get in my everyday and applies to me

in my everyday, I like to see shadows, I like to see EEP (the idea of it more correctly at this time) and I like to see stuff within all of my draw distance that is not broken/crumpled from where I am standing, and at the same time I like it when I can move about reasonably ok within the scene with all this going on

i accept that I can't always get what I would like with the computer that I have, so make do as best I can. While also appreciating the devs both Linden and TPV, to make my SL better as best they can. So big up from me to all the devs

just about Bellissaria

as a everyday thing, I prefer using Bellissaria to see how I am going. Is a killy place. Stuff all over the view, home owners using up most of their LI jamming as many furnishings in as they can, heaps of scripts and so on. If I don't get killed in Belli then I find that I am going to go reasonably ok everywhere else on the grid pretty much (with the odd exception here and there)

when I downtune my settings then I can get more FPS for sure, but when I do then for me the view is all kinda flat and uninspiring. For my everyday then I rather have a rich view at 20 than a flat view at 50 when that is all my computer can do with what there is

this is the same view as before on the Linden viewer, downtuned

flatprefs.png.600947cabfd8ad9094215df824584c5e.png

 

flatfps.png.40b243feef8c31bf2b62784efc9f1d2b.png

 

flatv1_002.png

  • Like 1
Link to comment
Share on other sites

i just finish off about viewer FPS. I did some more tests with Henri Beauchamp's latest CoolVLViewer-1.28.2.14-Windows-x86_64-Setup.exe (2021-03-13)

i downtuned to the same approx. settings as Linden to see what the differences might be in terms of raw FPS

on the ground at Bellissaria (same view as before). Downtuned about 80 FPS

vlcool.thumb.png.e23d983d800065a290839db40e73c16c.png

 

sitting on the box same same. 250 FPS

vlcoolbox.thumb.png.e079104714a3ef394bfd1088ec9eaf32.png

 

if it was just about raw FPS then I probably use this viewer all the time

 

  • Like 1
Link to comment
Share on other sites

Here is mine also with your settings Molly and the similar type of no-mesh, no attachments, system layer avatar at the same complexity of 2K:

299863464_GabrieleGraves-PerformanceTesting-CoolVL_001.thumb.jpg.471e36e1cbb2d29059b15b57c472a93d.jpg

Of course it is a contrived test, after all we aren't really rendering anything.  There is no way I would use SL this way.

At ground level on the same spot with all textures and objects loaded (as far as I could tell) things changed obviously:

222240115_GabrieleGraves-PerformanceTesting-CoolVL_002.thumb.jpg.77816a75cfd09f3abc79d139c7d517e4.jpg
 

At my home landing spot where I measured my "typical" FS settings vs. Cool VL as-close-as-equivalents as I could get and with my normal style avatar, etc. within a window of a few minutes, the results were probably about 5-10fps in CoolVL favour and that was all.  That might make all the difference to someone though.

I guess that fact that my results here are only slightly better than Molly's (about 6fps) despite it being the top card of the same generation shows that it isn't the graphics card that is struggling to keep up when rendering at ground level, it is most likely being under-served by the CPU.  Of course there could be other factors such as drivers, OS, the different resolutions, etc. that have a bearing too but I think that is most probably the main cause.

I also think it does serve to confirm and highlight what other folks have been saying for a long time though.  Going with the top of the generation Nvidia card isn't really worth the money for SL.  Sticking with the '60s/70's is much better for the price/performance ratio.  Oh, well you live and learn though this mistake was made about six or so years ago now so it doesn't sting like it would if it were yesterday.  The good part is that I will not make the same mistake when I need to replace the card next time which hopefully will not be anytime soon.

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

On 3/18/2021 at 9:29 AM, Coffee Pancake said:

That would be up to the viewer as unless provided, LOD models would be generated on demand. The viewer does have the ability to render different models based on screen real-estate distance etc. There is a lot of room to make the viewer smarter about what it renders and when, but ONLY if the LOD models are of a predictable complexity. 

The current situation allows creators to override that with what looks right to them, on their setup, with firestorm (and it's broken LOD handling left over from when creators jacked sculpts so hard it needed a viewer hack to make them render).

Right now we creators second guessing the viewer, and actively targeting firestorms bricked LOD handling. Garbage in. Garbage out.

Nope it would not be up to the viewer settings  the objects contain their own upload LOD specifics in regard to visibility at different distances in three bands  which can be configured currently with a fourth the rate given in the model built . Personally the removal of complex tasks options is damaging importability , I have a mesh dragon that i struggled to get uploaded with the changes implemented in 6.9.3.2  because some one thought it was good to remove crucial upload  and export problems or rename them . I believe your options will do much the same and are not required and only offer changes to new people learning the rest of us have already been made familiar with how to get our upload's to look visually at the lowest LOD settings  Hugs D

Link to comment
Share on other sites

There will always be edge case content that suffers in any system.

The point is to create a something that affects the bulk of SL content in a way that positively impacts the bulk of SL users.

Blind trust that creators will do the right thing does not work. it never has. Every trick and hack ends up an easily abused part of a skilled creators standard toolkit, and this has been demonstrated in SL over and over again.

Assuming people wont buy junk/ bad content is false. They totally do buy junk content, butcher SL performance to make it render and then apply social pressure for others to do the same.

The SL client is CPU bound and I/O bound. There is no magical hardware coming to make both of those problems go away. 

In the absence of a platform overhaul rebuilding from scratch for a fully threaded end to end vulkan pipeline (that would no doubt negatively impact far more content) imposing tighter content guiderails is essential.

tl;dr 

uLVfuxP.png

55 minutes ago, VirtualKitten said:

I have a mesh dragon that i struggled to get uploaded...

I'm sure you would have an easier time uploading your rigged dragon if you knew what the rules were and could design with them in mind. It would also be easier for people to assist you with specific solutions.

Link to comment
Share on other sites

On 3/19/2021 at 1:12 AM, Coffee Pancake said:

Back when sculpts were the bees knees, various tricks were developed to cram as much geometry / complex shapes into them as possible for a single prim/Li. These sculpts looked like screwed up hot garbage unless you were right on top of them -even with the object detail in the viewer maxed out. Refusing to admit they were pushing the format way past it's design intentions, creators started telling people to edit LOD related debug settings. In response, FS changed their object detail slider making it go to double what was included in the Linden client.

Is there a reason why this hasn't being reverted? It seem hardly a necessity anymore.

Link to comment
Share on other sites

1 minute ago, Kyrah Abattoir said:

Is there a reason why this hasn't being reverted? It seem hardly a necessity anymore.

There is so much content with terrible LOD because of it, furniture especially tends to be very badly affected.

Reverting it would create a support burden as users stuff is suddenly ugly, some would refuse to update due to 'worse graphics', affected creators would start telling people to tinker with debug settings again, and a tiny minority would take it as a personal affront to their liberty.

I can totally understand why there is radio silence from them and why once something's in FS, it's almost impossible to get it out.

If ever there was an argument for LL enforcing the shared experience, this should be it.

  • Like 3
Link to comment
Share on other sites

  

On 3/23/2021 at 3:35 AM, Coffee Pancake said:

There is so much content with terrible LOD because of it, furniture especially tends to be very badly affected.

Reverting it would create a support burden as users stuff is suddenly ugly, some would refuse to update due to 'worse graphics', affected creators would start telling people to tinker with debug settings again, and a tiny minority would take it as a personal affront to their liberty.

I can totally understand why there is radio silence from them and why once something's in FS, it's almost impossible to get it out.

If ever there was an argument for LL enforcing the shared experience, this should be it.

TL;DR (cos this turned out long even by my standards of blabbering)

I don't disagree that we want to encourage better content. I wander around shopping events checking LODs on items and generally facepalming. The number of pianos I've seen the crumple into a mess before you get more than a few metres away is ridiculous and that is WITH a LOD factor of 2. While I understand the argument, and the reality that anything in FS is kind of the de facto standard by weight of numbers, I don't think pointing a finger at a historical choice made by FS is either correct or the right answer to fixing it.

The Linden viewer default LOD volume is 1.25, in FS it is 2. The Upper bound on the Linden Viewer is currently unlimited I believe, but it was FS that took the lead to make it harder for the ill-advised practice of creators that tell their users to change settings. When we clamped LOD Factor to 4 we did so unilaterally to push the agenda forward. OTher followed suit. It was around the same time (I think perhaps a bit earlier) that I added the ability to view in the edit tools exactly what the LODs of a mesh were composed of, exposing poor practice, and working in conjunction with the other inspection tools that show texture density etc. I think we still had some whining remark about "nanny state" in the comments from our most recent release blog, from someone still sore and belly aching over that change 🙂 To get a taste of the kind of response and how some applaud it and some very much do not. You can read the replies on my blog from that older release. https://beqsother.blogspot.com/2018/01/for-lods-sake-stop.html 

The assertion that FS default (2) is somehow "wrong" and should be reverted requires a lot more justification than I have seen in this thread. I am not going to argue that it is right that we have 2, or contest the point, but I won't simply accept that 1.25 or 1 or any other magic number is right either. I would actually argue that the LL default (1.25) is not right at all and was based on typical screen resolution and rendering capability in 2010 (if I am being generous) and is a leftover from earlier times. The real point here is that the LOD Factor is simply one arbitrary input into an arcane, outdated and equally arbitrary calculation that is demonstrably flawed I think this thread is chasing the wrong beast entirely. Yes we need to reduce complexity in the HIGH LOD, and yes yes yes we need to encourage more and better lower LODs but as much as some might like to point the finger at our default for a setting it is not really a correct apportionment of responsibility.

The real problem lies in the unrepresentative cost imposed by the land impact algorithm which penalises the use of lower LOD geometry for more harshly than it should and this in turn prevents people using it and also in the layer upon layer of historic bugs that all viewers perpetuate (see later). The most extreme example of inappropriate cost is the Lowest LOD (aka the imposter) anything that uses more than a tiny handful of triangles  in that model will be hit with an increase in LI disproportionate to the load that it causes. for at least 4 years not we have been pushing to get the land impact calculation reviewed to better reflect this and allow creators to take advantage of less costly lower LOD geometry. The way that I and others have proposed is to allow a "free" quota at each LOD that does not incur anything above the base LI cost. Let's say we allowed 200 triangles "free of charge" in the lowest LOD, we could now actually block model a representation of the majority of use cases without incurring a significant penalty. On the other end of the scale you need the cost for abuse of this to go close asymptotic as it strays above a "reasonable" limit, this curve should allow people to push beyond the basic allocations accepting the cost of their choices but with a deterrent to going into the crazy spaces of just reusing the higher lods.

The proposal to define "reasonable" complexity in relative terms to the LOD above it is a false design directive (as indicated by "Target tris will be expected to be within +/-5%"). It rewards creators who push the HIGH LOD to it's limits and punishes those who follow good design practices such as Imposter rendering for flat surfaces. Any scheme that proposes that my Medium LOD MUST be within +/- X percent of the some fraction of the LOD above is encouraging mediocrity.

Consider, for example a model of small submersible, a bathyscaphe perhaps, it has a nicely modelled interior and portholes through which that interior is seen by anyone peering in (high lod), or sat inside. In the medium LOD, you are far enough from the object that modelling any of the interior is a waste and so you remove it entirely. The remainder of the object is basically just a metal sphere now and the LOD is a tiny fraction of its parent, and far better than anything autogenerated. This applies to all kinds of things that have interiors or which are seen from predominantly one perspective. A similar argument applies to all kinds of situations when building houses/stores, walls and large decor (trees are a classic example where low and lowest lods are perfect for impostering). As soon as you slip to Medium LOD anything interior or high detail is not longer relevant and anything that is ostensibly flat (windows, doors, paintings, curtains, or anything that is too small to warrant modelling) simply gets "impostered" and  reduced to a Billboard. This is good modelling practice and can be observed in the products of many of our more considerate creators, my go to exemplar for great quality modelling is Faust Steamer of Contraption whose buildings are an example to us all. 

It is entirely possible to force the LOD default back to 1.25, if the Lab felt the need to force this we would of course comply (it would be easier for us when dictated to do so), but without a well supported and qualified argument for the benefits of doing this I don't see that we would want to go down that path on our own. In moving the default you are just compelling the majority of people for whom the current default has been the de facto standard forever to change it after every update ( and we'd reignite the spread of misinformation by ill-informed creators that demand that you see their product in all its glory by hacking away at debug settings) but more to the point what does it achieve?

If you revert back to a LOD factor of 1.25 (the lab's default) then what actually happens? Objects decay to lower LODs sooner, meaning a little less geometry to render; this in turn means that the importance of those LODs increases, as is the objective of the "proposal". The problem is that underlying calculation of Land Impact based on the flawed LOD based equation charges excessively high for triangles in the LOW and LOWEST LODs in particular. It has long been the case that you cannot represent an asymmetrical model cost effectively because the land impact of Imposter (AKA lowest LOD) triangles is too high. By reducing the LOD factor we start to distribute display into the lower LODs, this means more people will see the lower quality models and creators will need to focus on those, this will drive up the land impact, and what impact on scene rendering (very little I suspect - see later). So we have lower quality being seen by more people, and higher land impact by creators who care about this. Who has won here?

What are the other side-effects of this? Those of us who try to create content that performs well and looks reasonable will typically exploit materials, taking a high poly model and "baking it down" onto a lower poly model with a normal map. The use of materials is a lower rendering overhead solution to get more visual detail into a model. But here's the thing... I've lost count of the number of creators who have told me that they MUST model every rivet and button and tooth in a zipper, because their customers don't use ALM (i,e have materials enabled). This can be a downward spiral, person A disables ALM because they go faster without it, so the creators add more geometry to compensate, making others slower.

The problem here is that many (and by general consensus with our support teams and the feedback I get from others that "many appears to be somewhere around 40-50% of us) have ALM disabled but not all do it for the same, or even the right reasons. ALM increases (threefold arguably) the amount of texture data you are using. you go from a simple colour image, to the colour image, plus a normal map, plus a specular map. If your personal viewer bottleneck is network, or disk IO, or RAM then this is probably going to be bad for you. For many people though those are not the bottleneck (as noted elsewhere CPU cycles are the most common resource issue) and while more textures does mean more CPU it is arguably lower than dealing with lots of rigged mesh. Other users incorrectly equate shadows with ALM and turn off ALM when the big performance hit for them is really just shadows and disabling those alone would help. 

I think the fallacy in all this is creators trying to excuse excessive detail, and poor modelling practice on their customers. At some point we have to accept that users on lower power machines are going to get a lower quality experience, nobody would be surprised at this. You don't expect to get in a ford fiesta and drive at 180 mph, why should a user on an ancient laptop realistically expect to get high quality performance or graphical fidelity? I am not saying throw them under the bus, far from it. But using their low end hardware and lack of materials as an excuse for bloated high detail models is not constructive and does not do anyone any favours.

Coming back to the issue of LODs and forcing the generation of "good" LODs. What exactly are we aiming to achieve here? What are we asserting is the problem that must be solved?

If we are saying that the rendering cost of static mesh content is causing significant drops in frame rate then I would strongly question that. The rendering of static mesh is a comparatively small proportion of the cost of what I would consider a "typical" scene. Then again my "typical scene" may not be yours. And as such your mileage will differ. There is no definition of "typical scene" that anyone would agree on. I would suggest that a typical scene is one with a mixture of avatars and some scenery. For others it might be their home, unchanging and crammed with high quality textures in photo frames but few avatars; for others it might be a shopping event, jammed full of avatars and vendor textures. For many (perhaps most) their "typical scene" is observed from a comparatively stationary POV, but for a significant minority it is whizzing around on a bike, car, boat. Each of these situations has different loads on the viewer and potentially different bottlenecks.

I digress though, the question is what are we trying to achieve by forcing the display of lower poly models? If your definition of a "typical scene" is like mine and includes a couple of mesh avatars, materials and shadows then frankly fiddling about with your static mesh rendering is a waste of effort. Rigged mesh rendering is far more expensive and the LOD system is broken at so many points that it is beyond a joke. 

1) Your items do not LOD based on their own scale but on the scale of the avatar bounding box. https://jira.secondlife.com/browse/BUG-214736
2) They do not obey the LOD decay equation, but instead more than double the distances involved.https://jira.secondlife.com/browse/BUG-40665
3) The complete lack of any real penalty for having an excessively complex avatar.  

You will note that on one of the other related Jiras (https://jira.secondlife.com/browse/BUG-11627) Andrey has stated that this type of thing is accepted as being an issue but is on hold pending "better content policies" which brings us into the scope of this discussion (yay)

In any scene that has shadows enabled and a handful of avatars in those abhorent alpha cut mesh bodies (that the majority of users wear in spite of more performant options being available), the cost of rendering those avatars and their shadows quickly dwarves the cost of all the scenery around them combined.  It is certainly possible to create a static scene full of gorgeous trees and buildings that hurts your frame rate, but you have to work pretty hard and have a lot of scenery. An easier way to get the same effect is to invite a small circle of friends round for a chat and watch the fps plummet.

The other problem that comes up time and again when we discuss adjusting build parameters and changing land impact is that people start running about with their hair on fire panicking that all their decades old crap content is suddenly going to be bulk returned. I would argue that the Land Impact calculation is so old now that even those users on tail end hardware should be capable of handling more than the perceived limits from back then, we certainly should not be setting future goals in that context.

As such I see no reason why any LI costs should go up in a way that forces the content to be returned, you simply rescale things. Don't make te old stuff "invalid" it has been valid for many years after all, simply make new stuff "more valid and more desirable". I think this is where @Coffee Pancake and I agree completely. The "fast mesh" sales pitch is a way to make thing more attractive, but in the end I think (if we can) a new land impact measure would be a far more resilient and motivating solution.

It should be feasible for an old bad item that cost 1LI to remain at the same relative cost in a new metric. New items would simply be lower cost if made well. To make that easier to understand you recalibrate everything that cost 1 LI today costs 100LI tomorrow (but you parcel limit is also 100 times larger so nothing gets hurt). We've now made space for new efficient content that costs <100LI (<1LI in old money). No ancient content is hurt in the making of these new rules. Of course this is far easier to write down than it is to actually define and implement, the new rules need to be rigorous, comprehensive and consistent. Of course, comprehensive and consistent in a world where no two users have the same set of constraints is near impossible. This latter fact is a large part of why @Vir Lindenand his team have pondered over the knotty issue of complexity and the ArcTan project for so long even when restricted to only the rigged mesh problem.  Getting a "right" answer is not a simple thing.

 

 

 

 

 

 

Edited by Beq Janus
trees added as an example of sensible impostering.
  • Like 3
  • Thanks 3
Link to comment
Share on other sites

2 hours ago, Beq Janus said:

The Upper bound on the Linden Viewer is currently unlimited I believe, but it was FS that took the lead to make it harder for the ill-advised practice of creators that tell their users to change settings. When we clamped LOD Factor to 4 we did so unilaterally to push the agenda forward. OTher followed suit.

From LL's viewer source:

image.thumb.png.8b494995b38c0c82eb6e99010faeb312.png

I have no idea what I am doing.  This may not even be what you are talking about.  I expected MAX_LOD_FACTOR to be equal to 2.0.

  • Thanks 1
Link to comment
Share on other sites

3 hours ago, Beq Janus said:

 The assertion that FS default (2) is somehow "wrong" and should be reverted requires a lot more justification than I have seen in this thread. I am not going to argue that it is right that we have 2, or contest the point, but I won't simply accept that 1.25 or 1 or any other magic number is right either.

There are two arguments why 1 - or 1.25 if you like - is right. One is that prims are optimized for it and we will always have prims around. The other is that the land impact calculation is based on the assumption that the scene is rendered at LOD factor 1. LI is shaky enough as it is, we don't really need more factors to throw the result off. Apart from that, there are no strong arguments for any particular LOD setting.

What is so totally wrong, however, is that the LOD factor exists at all. LOD can only be really optimized if all objects in the scene are based on the same standard and all visitors to the scene use that standard. The LOD factor makes this impossible.

If I understand the comments here correctly, the LOD factor was introduced by the Emerald/Firestorm team as a fix to the bodged LOD of sculpts. If so, it's a classic example how wrong things can go if you try to patch over a fundamental flaw with a crude hack rather than correct the actual problem. I won't blame them for it though since a TPV dev team wouldn't been in a position where they could do otherwise. It was LL who should have made sure sculpts had adequate LOD in the first place. The viewer already had another LDO factor that is different for different prim types and it shouldn't have been difficult for them to crank that up for sculpts and sculpts only. Maybe they could also have come up with a better decimation algorithm for sculpts - even GLOD would have been better than the crude decimation by numbers solution they implemented.

 

3 hours ago, Beq Janus said:

I would actually argue that the LL default (1.25) is not right at all and was based on typical screen resolution and rendering capability in 2010 (if I am being generous) and is a leftover from earlier times.

I do not buy that argument. The one and only purpose LOD has, is to eliminate geometry that isn't noticeable to the viewer and retain what is noticeable. It needs to be based on what we can see, not what the computer can handle, and as far as I know there haven't been any upgrades to the human eye recently. That being said, there has been a continuous trend towards larger screens and thisis a factor that probably should be taken into account in one way or another.

 

3 hours ago, Beq Janus said:

 The real problem lies in the unrepresentative cost imposed by the land impact algorithm which penalises the use of lower LOD geometry for more harshly than it should and this in turn prevents people using it and also in the layer upon layer of historic bugs that all viewers perpetuate (see later).

The real problem is that the LOD factor exists but yes, that is definitely a factor that makes things much worse.

Edited by ChinRey
Lots'a li'l tyops
Link to comment
Share on other sites

4 minutes ago, ChinRey said:

If I understand the comments here correctly, the LOD factor was introduced by the Emrald/Firestorm team as a fix to the bodged LOD of sculpts

Nope, it exists in the linden viewer. We never added it. We increased the default at some point in the past to deal with the poor experience of sculpts. 

6 minutes ago, ChinRey said:

The other is that the land impact calculation is based on the assumption that the scene is rendered at LOD factor 1.

I don't understand this assertion. Land impact has nothing to do with LOD numerically and is not affected by it. The land impact is based upon largely irrelevant evaluation of streaming cost, derived in large part from the fact that back in the day there was a literal cost to the region to "send" the mesh or other assets. This has not been true for many years as things are sourced from the CDN and typically reside on an Akamai edge server far closer to you than the region ever was. Moreover, the bandwidth available to the majority of users is radically different to what it was then too. If LI had a measure of true rendering cost in it then it would be a different beast again. LI captures some essence of that notion of rendering cost in the fact that the more triangles in an object then the larger the data that has to be rendered, it takes no account of the rigging overhead, the texture density or any of the other factors. The argument back in the day was that you didn't want to pull all the data for all the objects in a region because it was hogging both your bw and that of the server. In conjunction with LOD you'd only pull parts of the mesh data into cahce on demand. A similar scheme does the same (equally poorly) for textures. As noted above that network concern is no longer true to the same extent and is somewhat moot. LOD is stating what you as a viewer are willing and able to render. the LOD factor exists and gets fudged around with in all kinds of places. With prims it was never one. it gets adjusted based on the proportional volume of the primitive relative to the bounding box IIRC. It is too late at night to go on code archaeology. but as I recall the LOD factor of a sphere is higher (or is it lower?) than that of a cube, because a cube of "radius" 2m is visibly smaller than a sphere of radius 2m and the adjustment is "meant" to compensate so that they LOD at the visually appropriate point rather than the dimensionally accurate one.

29 minutes ago, ChinRey said:

I do not buy that argument. The one and only purpose LOD has, is to eliminate geometry that isn't noticeable to the viewer and retain what is noticeable

If back in the day a typical screen had say 800 vertical pixels and now people are frequently operating on 4K with most of us on or around 1200, then clearly we have more visual real estate. an object that was 10% of the screen high would have been 80 pixels and is now 120+. The screen, as you say,  can also be physically larger making low resolution models seem all the more coarse (not a problem I suffer mind you, like most of us, I am not inflicted with the burden of a 50 inch 4K screen 🙂) but it is rendering resolution, reducing overdraw etc that is of most value.

LOD is about eliminating geometry, my point is that I can handle a lot more geometry now that I could then. and I don't believe for a second that the LOD algorithm ever came close to managing to cull geometry as it approached the density limits of screen space. in fact that is one of the major flaws that it has. It has no concept of screen space whatsoever. It is a rough approximation of how much virtual view space it might take up, but no clue about your rendering resolution.

But the real point is that this is all blown out of the water by rigged mesh cockups. One of the major bottleneck in mesh processing is managing the the transformations from unit space where it is packed in the assets into world space and ultimately view space. to be drawn. A lot of that maths happens in the CPU. For static mesh the inflation and rotation are pretty simple. for rigged mesh it is compounded by the chain of bones to which it is rigged, thus rigged mesh has a considerably higher overhead, add to that the fact that mesh clothing is frequently very dense both to facilitate movement but also due to poor optimisation. Yes we can all point at poorly made, excessively dense, overly bevelled static mesh but it has a lower overhead than a comparable rigged mesh and yet there is a) no accountability for it whatsoever in terms of the revered "land impact" b) rigged mesh barely ever decays beyond the medium LOD due to the aforementioned bugs. If Land Impact is meant to protect us from some kind of rendering bogey man, it is a very poor choice of weapon.

1 hour ago, ChinRey said:

The real problem is that the LOD factor exists but yes, that is definitely a factor that makes things much worse.

Maybe so. I don't think LODFactor as such is the problem, at least not at the 2 vs 1 or 1.125 or whatever the LL default is. As I say it has reasons  to exist and I don't generally agree with the view around it being best left at an arbitrary number just because of some handwavy nostalgia. I am all for solid evidence based arguments and you know very well that I am very pro anything that pushes content in the right direction. I don't think that this is the demon that needs to be slain, not the first one at least. I do think that the LOD mechanism is flawed and should be screenspace based this removes some of the need for "factors" to correct between apparent and actual volumes but more importantly it respects the actual limits of your rendering based on personal hardware availability. 

 

 

 

 

 

Link to comment
Share on other sites

5 hours ago, Beq Janus said:

 

It should be feasible for an old bad item that cost 1LI to remain at the same relative cost in a new metric. New items would simply be lower cost if made well. To make that easier to understand you recalibrate everything that cost 1 LI today costs 100LI tomorrow (but you parcel limit is also 100 times larger so nothing gets hurt). We've now made space for new efficient content that costs <100LI (<1LI in old money). No ancient content is hurt in the making of these new rules. Of course this is far easier to write down than it is to actually define and implement, the new rules need to be rigorous, comprehensive and consistent. Of course, comprehensive and consistent in a world where no two users have the same set of constraints is near impossible. This latter fact is a large part of why @Vir Lindenand his team have pondered over the knotty issue of complexity and the ArcTan project for so long even when restricted to only the rigged mesh problem.  Getting a "right" answer is not a simple thing.

you wrote quite a lot which I find pretty informative

just on this last part, some thoughts

I think that Linden spend to much time listening to developers and content creators who build to professional standards. Linden should stop listening as much to these people. As when they do they end up paralyised, too many considerations. Paralysis is not good

Linden I think should listen more to the amateurs. Listen meaning observe and pay attention to what the amateurs do. Fix it so that the amateurs can make halfway decent stuff out of the box. And then the professionals can build on top of that halfway decent standard. Get as efficient as they prefer

the criteria for halfway decent is that our amateur-made stuff doesn't crumple. And when it does then amateur pays a penalty for that crumpling. And when so amateur goes: eep! how do I not pay that penalty? And professional goes: like this, like this and like this and that. Amateur goes: thanks!

amateurs do need a design metrics scale standard. As when there isn't then they are all over the place. The rule for amateurs is: Get your stuff within the metrics and you don't pay any penalty. Can feel some professionals shuddering already. o.m.g I am gunna pay the same cost for my super-efficient stuff as that halfway decent amateur. My answer to that is: yes. Because it is not all about you, is about the amateurs also. o.m.g! I am gunna flat all my stuff from now on and use materials for bumps! My answer to that is: Go for it, you can if you want. Lots of people do this already

if was me, and it isn't, I would break LOD adjusters in the viewer. Like from now on its 1.125 (pick a number). The only adjuster to be Render Objects Low to High. Where High is equivalent to (pick a number). So people on older computers can decrease it down to Low. And people on newer computers will leave it on High and can't increase beyond this. (This is kinda what Firestorm does now already)

this kinda change doesn't change existing LI costings. It just makes existing badly made stuff look like what is already, bad. New made stuff being made to the metrics scale standard will not crumple

quite a few people would howl about this if it happened. But after a bit they will go: Gah! blinking Linden. Oh! well.  I think I get some other trees/houses/clothes/stuff/etc that don't look quite so bad as my old stuff

  • Like 1
Link to comment
Share on other sites

58 minutes ago, Beq Janus said:

Nope, it exists in the linden viewer. We never added it.

OK. It's all LL's fault then. :) It was anyway because, as I said, if they could have been bothered to fix the actual problem, the LOD factor hack wouldn't have been neccessary.

 

58 minutes ago, Beq Janus said:

I don't understand this assertion. Land impact has nothing to do with LOD numerically and is not affected by it.

The LOD swap distances are some of the base factors to calculate download weight (and also render weight) and it's not really possible to get even a credible estimate of the actual weight the geometry adds when those are unknown. I do agree that the LI formula grossly overestimates the significance of geometry compared to textures but it's still a significant factor.

 

1 hour ago, Beq Janus said:

LOD is about eliminating geometry, my point is that I can handle a lot more geometry now that I could then.

Yes but why would you want to? Ignoring the screen size issue for now (I'll get to that later), a model that has poor LoD today, had poor LoD back in 2010, and 2003 - and 1990 for that matter. If it had good LoD back then, it still has today and it doesn't need more. It's much better to use the increased computer power to add other things you can actually see.

Screen size is a factor we haven't really discussed before and that's something that should eb taken into consideration. I'm inclined to say it would be better to base the LoD swap distances on the object's actual size on screen rather than it's nominal size but that may be a bit too complicated.

 

1 hour ago, Beq Janus said:

But the real point is that this is all blown out of the water by rigged mesh cockups.

Oh yes, that's a really ugly one. But we have to be careful not to try to tackle all problems at the same time because that would be too overwhelming.

 

11 minutes ago, Mollymews said:

I think that Linden spend to much time listening to developers and content creators who build to professional standards.

Yes, except they don't really listen to any content creators of any level. It's all based on the individual developers well intended but not always well founded assumptions of what is good.

 

14 minutes ago, Mollymews said:

quite a few people would howl about this if it happened.

To be absolutely honest, I would be inclined to agree with the howlers. This is mainly about blunders LL made back during the six dark years and you can't really put the genie back in the bottle.

Link to comment
Share on other sites

6 minutes ago, ChinRey said:

To be absolutely honest, I would be inclined to agree with the howlers. This is mainly about blunders LL made back during the six dark years and you can't really put the genie back in the bottle.

this is the question really. If you did stick the genie back in the bottle then how would you do it?

with pick a number then it could be 4. Which would do less immediate visual damage than 1.125 would. Taking the genie stuffing long view, that in 5 years or so then more people will be using computers that can handle 4 than there are now. So the Render Objects slider goes from equivalent 1 to 4

 

Link to comment
Share on other sites

I don't know the answer but I do know ordinary people shouldn't have to guess what this slider value should be or even have to set it at all.  The world should still render.  At this point if that means we have to homogenize mesh so that the damn world renders OK for everyone so be it.  I was reluctant before but I have come around to this.  I will throw away all the crap I have and start again if I have to.  I want to do this once and once only when this has a properly designed, workable fix that means I don't ever have to do this again.

Link to comment
Share on other sites

6 hours ago, Beq Janus said:

We increased the default at some point in the past to deal with the poor experience of sculpts. 

It's okay to admit that mistakes were made in increasing it instead of locking it down to 1.25.

But why not fix the mistake now and set a good example?

  

4 hours ago, Mollymews said:

with pick a number then it could be 4. Which would do less immediate visual damage than 1.125 would.


So essentially do "nothing"? At some point we have to stop assuming that creators are just misguided, if they've been doing business for any length of time they know exactly that what they are doing is wrong, they simply won't care unless it kicks them in the wallet.

Edited by Kyrah Abattoir
Link to comment
Share on other sites

8 hours ago, Mollymews said:

you wrote quite a lot which I find pretty informative

just on this last part, some thoughts

I think that Linden spend to much time listening to developers and content creators who build to professional standards. Linden should stop listening as much to these people. As when they do they end up paralyised, too many considerations. Paralysis is not good

Linden I think should listen more to the amateurs. Listen meaning observe and pay attention to what the amateurs do. Fix it so that the amateurs can make halfway decent stuff out of the box. And then the professionals can build on top of that halfway decent standard. Get as efficient as they prefer

the criteria for halfway decent is that our amateur-made stuff doesn't crumple. And when it does then amateur pays a penalty for that crumpling. And when so amateur goes: eep! how do I not pay that penalty? And professional goes: like this, like this and like this and that. Amateur goes: thanks!

amateurs do need a design metrics scale standard. As when there isn't then they are all over the place. The rule for amateurs is: Get your stuff within the metrics and you don't pay any penalty. Can feel some professionals shuddering already. o.m.g I am gunna pay the same cost for my super-efficient stuff as that halfway decent amateur. My answer to that is: yes. Because it is not all about you, is about the amateurs also. o.m.g! I am gunna flat all my stuff from now on and use materials for bumps! My answer to that is: Go for it, you can if you want. Lots of people do this already

if was me, and it isn't, I would break LOD adjusters in the viewer. Like from now on its 1.125 (pick a number). The only adjuster to be Render Objects Low to High. Where High is equivalent to (pick a number). So people on older computers can decrease it down to Low. And people on newer computers will leave it on High and can't increase beyond this. (This is kinda what Firestorm does now already)

this kinda change doesn't change existing LI costings. It just makes existing badly made stuff look like what is already, bad. New made stuff being made to the metrics scale standard will not crumple

quite a few people would howl about this if it happened. But after a bit they will go: Gah! blinking Linden. Oh! well.  I think I get some other trees/houses/clothes/stuff/etc that don't look quite so bad as my old stuff

I might be misunderstanding you here and if that's the case, I apologize. However, it's my opinion on the whole topic either way.

The thing is, most best practices talked about here are not difficult for an amateur to learn. If you're going to create stuff for any domain (be it your own game or a mod/content for an existing), you just have to read up on it a bit so you can create decent stuff. It's like when you're doing basic carving. Yes, shaving off flakes from your workpiece is not a difficult task to learn, but you'll have to know how wood behaves and how to deform it or you'll end up with scrap.

If you want to create a model for a videogame, you should be willing to learn how to model for a videogame. That includes designing with conventional tools (as opposed to sculpting the end result with a ridiculous amount of polygons and just uploading it), creating LODs (breaking your model down to its essentials) and normal mapping (to add details without it being too taxing on others hardware). You're going to negatively impact other people's experiences with inefficient work and then having the audacity to tell them to dial up their graphical settings lest they have to look at a scrambled mess is insulting. My point is not that high details are a bad thing, but as a content creator it's your responsibility to make sure your content looks good for the majority of people. It's not the job of the same people to buy a new graphics card because the creator couldn't be bothered to optimize their stuff even to a basic degree.

I'm not a professional modeller. In fact, this is merely a creative outlet for me. So I qualify as an amateur. Guess what? Before creating models for real-time rendering and game engines, I looked at best practices for a few hours. And if content-creation is your passion, you surely can invest those hours as well, right? If you take your time and create well-optimized, you should be rewarded. If you continue to learn and optimize your future work even more, you should be rewarded. If you churn out hastily sculpted topology that makes even forgiving renderers like Blender's Eevee cry, you should be penalized. Harshly.

To add a little rant, I watched numerous tutorials on Youtube about modelling hair for SL. Many well-done tutorials out there. But one of them seriously found it feasible to upload one single hairdo with a whopping 5300 tris. I'm working on a character model right now. Head, excluding hair, torso, legs and feet clock in at 5800 and optimization is still underway. We don't have to cater to these creators, do we?

@Coffee Pancake I disagreed with you earlier, but having looked at some more products and tutorials... you're correct.

Link to comment
Share on other sites

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

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

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...