search

secondlife / jira-archive

2 stars 0 forks source link

[BUG-228317] [ArcTan] Complexity overhaul suggestion / Including PoC #6428

Open sl-service-account opened 4 years ago

sl-service-account commented 4 years ago

How would you like the feature to work?

Greetings.

I have been working and testing an overhaul of the complexity system for the last year, which fixes multiple dire issues with the system as it is currently in place, and makes for a much more accurate representation of complexity and performance hits on the viewer side in general. For the sake of structure, I will be dividing this writeup into multiple sections.

I will provide a recap of all solved problems in the second field.

==== MESH

Attachments

Original Jira Fields | Field | Value | | ------------- | ------------- | | Issue | BUG-228317 | | Summary | [ArcTan] Complexity overhaul suggestion / Including PoC | | Type | New Feature Request | | Priority | Unset | | Status | Accepted | | Resolution | Accepted | | Reporter | Chalice Yao (chalice.yao) | | Created at | 2020-03-15T09:09:55Z | | Updated at | 2020-03-25T18:51:35Z | ``` { 'Build Id': 'unset', 'Business Unit': ['Platform'], 'Date of First Response': '2020-03-15T09:33:10.757-0500', 'How would you like the feature to work?': 'Greetings.\r\n\r\nI have been working and testing an overhaul of the complexity system for the last year, which fixes multiple dire issues with the system as it is currently in place, and makes for a much more accurate representation of complexity and performance hits on the viewer side in general.\r\nFor the sake of structure, I will be dividing this writeup into multiple sections.\r\n\r\nI will provide a recap of all solved problems in the second field.\r\n\r\n\r\n====\r\nMESH\r\n====\r\n\r\n* Problem 1: The current mesh complexity calculations have a huge bug, where due to their logic of punishing LODs, the absolutely lowest LOD has an insanely huge impact on complexity, while the highest lod barely has any - in a social environment where the most complex meshes tends to be on Avatars, in social venues where avatars usually are close enough to show at least the mid to high LODs. The calculation does not match the reality of SL use and situations at all.\r\n\r\nTo elaborate, the current calculation essentially has the logic of taking a region\'s worth of space, placing a theoretical mesh in the middle, and drawing certain circles of different radiuses around the mesh. The weighting happens according to the in-region camera space that gets encompassed by those radiuses. The radiuses of the high, middle and even low LODs are tiny compared to the region space left for the low LOD calculation, and it gets punished the highest. Creators all over have abused this by just scrapping the lowest LOD altogether, while pushing the highest LOD to extremes.\r\n\r\n* Problem 2: Rigged mesh always displays in its highest LOD while worn, due to a bug. Combined with Problem 1, you can see how the calculation above completely allows creating rigged meshes with absolutely false (read: Way too low) complexity ratings: Set all LODs to \'1\' on mesh upload except for the highest. Insane geometry can be created while the complexity system labels it as ridiculously low.\r\n\r\n* Problem 3: Rigged mesh is vastly more performance-draining on the viewer side than unrigged mesh. This is in parts due to all the transformation and animation calculations in the viewer, which are also slowed down due to the fact that they are very Object Oriented instead of using a modern Data Oriented Design approach. The avatar shadow calculations intensify this, as they take rigged mesh and perform these transformations again, in multiple passes, due to how the shadow render code is stacked. Rigged rendering (and its shadows) is one of the absolutely highest hotspot for CPU cache misses in the entire viewer.\r\nThe current complexity calcualtions completely neglect the performance differences between the two types of mesh - it gives a bare 1.2 times multiplicator to complexity, which does not represent the performance impact of commonly sold rigged mesh vs. unrigged at all. Combined with Problem 1 and 2 above, and the overall problem case is complete.\r\n\r\n\r\n* Solution:\r\n I have changed and simplified the calculations as follows:\r\n Every triange in a mesh causes a complexity gain of \'1\' instead of the previous \'5\', to make for the simplest, smallest, base. 1 triangle = Complexity of 1.\r\n However the LOD calculations were adjusted as follows:\r\n \r\n Rigged Mesh: Always only consider the highest LOD as the triangle count.\r\n Unrigged Msh: Lowest LOD + (Low LOD / 2) + (Med LOD / 3) + (HighLOD / 4).\r\n\r\n This makes Rigged Mesh complexity calculations account for the higest LOD always showing, making the faking of low complexity through dropping the other LODs impossible. Also, the triangle calculations of unrigged mesh follow a much simpler calculation that, while still giving the lowest LOD the highest impact, makes the relation between the Lowest LOD and Highest LOD much closer - accounting for the fact that most social events in SL are happening at a smaller scale, with people usually seeing meshes in higher LODs. This also accounts for the fact that most lowest- and low-LOD situations are also usually occluded and not rendered.\r\n \r\n Finally, rigged mesh gets a flat \'4X\' multiplicator over unrigged mesh after these calculations are complete. While still actually conservative, this roughly represents the performance drain of rigged mesh over unrigged, including the various shadow passes.\r\n \r\n* Example number in the changed system:\r\n\r\n The numbers resulting from this system are rather high, as you will see in a moment. I found this to be fine, as the overall scaling of the complexity system simply shifted to a new set of good vs. bad numbers due to its finer granularity and more linear scaling:\r\n \r\n - A rigged mesh with 100k triangles in the highest LOD would, in this system, have a complexity of 400k.\r\n - An unrigged mesh with a resulting 100k triangles according to the above LOD formula would have a complexity of 100k\r\n\r\n\r\n=======================\r\nMULTIPLIERS AND OLDER FEATURES\r\n=======================\r\n\r\n* Problem: The current complexity system actually has a math error that causes its multipliers to have a HIGHER punishment than it should. Yes, I\'m also taking care of too high results with this :)\r\n\r\n In the current system, each multiplier caused by certain texture settings, the presence of alphas, the presence of glow or flexis gets multiplied by the next. This causes horridly high punishments on objects, despite the actual performance hit of a single, say, flexi object in the linkset being nearly neglectible.\r\n \r\n Example:\r\n - Multiplier for having 1 flexi object: 5x\r\n - Multiplier for having 1 shiny face: 1.6x\r\n - Multiplier for having 1 alpha face: 4x\r\n \r\n Result:\r\n 5 x 1.6 = 32\r\n A 32x multiplier of the whole object\'s complexity rating. Combine with the fact that flexi hardly takes a toll at all on even older CPUs compared to any higher mesh, and the multipliers currently just don\'t represent a realistic approach to performance punishments.\r\n \r\n* Problem 2: The current system overly pushes simply features that have neglectible impact (like the traditional shiny setting or flexi) while completely ignoring things like materials. Completely.\r\n\r\n\r\n* Problem 3: Faces get alpha punishment, even if they are completely invisible and should not get rendered at all.\r\n\r\n \r\n* Solution:\r\n\r\n The simple solution for the multiplier problem is to *add* the multipliers up before applying their final rating to the complexity of an object.\r\n\r\n Example:\r\n - Multiplier for having 1 flexi object: 5x\r\n - Multiplier for having 1 shiny face: 1.6x\r\n - Multiplier for having 1 alpha face: 4x\r\n \r\n Result:\r\n 5 + 1.6 + 4 = 10.6\r\n A 10x multiplier instead of a 32x. In my opinion, the multiplier is still a bit high compared to the impact of other factors like high LODs and textures, but at least this approach fixes the very base problem of the current multiplier system. After this, the multipliers could get adjusted accordingly.\r\n \r\n Also, I have completely dropped the Bump and Shiny multipliers, in favor of directly adding material texture calculations into the texture-complexity system.\r\n Likewise, alpha faces do not get punished if they are 100% invisible, like on rigged mesh.\r\n \r\n\r\nWhich brings us to...\r\n\r\n\r\n======\r\nTEXTURES\r\n======\r\n\r\n* Problem 1: The standard texture cost calculation does not in any way match actual texture scales\r\n The current texture calculations work by taking width/128 times height/128 and adding a fixed value of 256, per texture. The resulting numbers are ridiculously low and in no way match the added resource use of larger vs. small textures. Example ARC numbers by the current system:\r\n \r\n 64x64 texture: 256\r\n 1024x1024 texture: 320\r\n \r\n I don\'t think more numbers are needed than this. The current system makes essentially no difference between a tiny texture and the largest possible.\r\n\r\n\r\n* Problem 2: Material textures are completely neglected in the current complexity calculations. I..don\'t have to add more to this problem description.\r\n\r\n\r\n* Problem 3: The same texture gets punished multiple times if set on the same object, as of right now. With a new, more accurate texture complexity calculation, this would be really nasty - and is illogical in the first place as each texture only gets loaded once.\r\n\r\n\r\n* Solution: I applied a completely linear calculation to the complexity value of textures. My calculation uses "100 + ((width x height x 64) / 1000)"\r\n\r\n 64x64 texture: 1262\r\n 1024x1024 texture: 68108\r\n \r\n This is a MUCH better representation of the impact of large vs. small textures. It also pushes the texture complexity values to be more in-line with the higher values that the new mesh calculations cause, giving us a much much better weighting of mesh complexity vs. used texture space in the overall complexity calculation result.\r\n \r\n Likewise, I applied the same calculations to any additional material textures - normal maps and specular maps both.\r\n \r\n Finally, each individual texture only counts against complexity once in the same linkset. This is still not optimal as technically a texture should only be counted once pere whole, say, avatar setup, but this is a good start.\r\n \r\n\r\n==========\r\nFINAL RATINGS\r\n==========\r\n\r\nDue to these changes, the complexity numbers turn out to be higher than before - and thus also need a new scaling.\r\n\r\nI found these overall complexity scalings on Avatars (not individal pieces) to be quite accurate with this system:\r\n\r\n0,000,000 to 1,000,000 = Absolutely excellent\r\n1,000,000 to 2,000,000 = Good\r\n2,000,000 to 3,000,000 = Okay\r\n3,000,000 to 4,000,000 = Needs improvement\r\n4,000,000 to 5,000,000 = Bad\r\n5,000,000 to 6,000,000 = Really bad\r\n6,000,000+ = No\r\n\r\nThe new system provides a good even weighting of mesh complexity vs. texture use.\r\nFor example, an arrangement of rigged meshes with 500k triangles in the highest LOD would cause a 2 million rating on the scale - leaving about 1 million for textures to stay in the good range. Which equates to about ~14 1024x1024 textures...or 56 512x512 textures.\r\n\r\nLikewise, a lower total triangle count of, say, 200k rigged mesh would cause a rating of 800k, leaving plenty of space for more textures before the rating gets pushed into bad levels. Likewise, an insane amount of rigged geometry will already be punished, before textures come into play.\r\n\r\n\r\nVice Versa is also true - good use of textures allows for more mesh geometry to be used, and an abuse of textures will already push the numbers high, before any mesh geometry adds to the equation.\r\n\r\n===\r\nDIFF\r\n===\r\n\r\nPlease see the attached diff file for my changes. It is made against the latest state of the LL \'viewer\' repository\'s llvovolume.cpp', 'Original Reporter': 'Chalice Yao (chalice.yao)', 'ReOpened Count': 0.0, 'Severity': 'Unset', 'Target Viewer Version': 'viewer-development', 'Why is this feature important to you? How would it benefit the community?': 'This feature is DIRELY needed, as the current complexity system is near-useless. The impact of textures gets ignored, there are severe bugs in the Mesh complexity calculations that are actually getting actively abused to circumvent any realistic complexity calculation, and old features that barely have any impact compared to the current state of SL assets get punished severely.\r\n\r\nThis new approach\r\n - Fixes rigged mesh complexity calculations, accounding for the higest-LOD bug\r\n - Fixes overall mesh LOD calculations vs. complexity impact\r\n - Fixes tiny vs. large texture complexities\r\n - Makes invididual textures only count once in linksets\r\n - Fixes the Multiplier math by turning multiplication of multipliers into addition, fixing their ridiculously high impact\r\n - replaces barely noticable legacy Bump/Shiny multipliers by actual inclusion of material textures into the texture complexity calculations\r\n - Makes complexity a much more linear result according to the actual impact of mesh and textures\r\n - gives a much more weighted complexity relation between mesh geometry and texture use\r\n', } ```
sl-service-account commented 4 years ago

Chalice Yao commented at 2020-03-15T09:57:44Z

As an additional note, if anybody thinks of testing out the .diff, make sure to

1) Disable complexity reporting of your viewer to the sim, so the changed numbers do not mess up the sim's complexity reports. THIS IS IMPORTANT. 2) Make sure that if you are jellybeaning by complexity, to either unlock the according sliders or in some other way raise your values.

sl-service-account commented 4 years ago

Beq Janus commented at 2020-03-15T14:33:11Z

Hi Chalice,

This is a great start, I will try to have a look at the patch, Liz (polysail) and I have been looking at different calculations in the past though we put it on hold a while back when ArcTan was mothballed and haven't revived it. It will be interesting to see how this correlates to our use cases.

 

One thing worth noting is that the rigged mesh High LOD bug is not quite so simple as you summarise and perhaps you left it that way to keep the summary brief. The underlying problem is layered, firstly mesh LOD distances are based upon the bounding box of the avatar and not of the object, this makes sense if you consider that you might not want your hands/head to LOD swap at a different point to your torso however for items such as piercings (nose, nipple, belly, whatever) rings and other tiny attachments it makes no sense at all. It is the subject of other Jiras though and not for this one.  The second layer is a straight-up bug that I reported a couple of years back where the method used to get the radius for use in LOD distance calcs (binradius IIRC) actually returns the diameter for rigged items and thus doubles the already inflated LOD distance. These combine to effectively mean that the LOD swap distance is vastly more than it should be and the impression that rigged mesh "never" LOD swaps.

The observation on the rigged mesh costs, I totally agree with. Rigged mesh is far and away the single greatest hog of framtime. You can make a region very laggy with static content if you try hard (mostly this is textures in my experience) but you need only invite a handful of mesh-bodied buddies to do it with rigged mesh! This is also why I want to double down on incentivising mesh body makers and users to ditch the alpha cuts bodies. 

We'll take a look and have a play and no doubt have some feedback, hopefully this can then help the Lab in bringing their ArcTan work to release sooner.

 

 

sl-service-account commented 4 years ago

Arcane Portal commented at 2020-03-15T22:24:53Z, updated at 2020-03-15T22:30:12Z

Myself and a hand full of other users have been using this complexity overhaul since its first inception over a year ago, and have found it to be a fairy accurate metric which to gage an avatar's actual impact on performance. The current complexity system Second Life uses had its heart in the right place, but the severe problems pointed out in this JIRA have long made its usefulness questionable. 

Second Life is currently in a very bad state when it comes to performance; it is one of the most common complaints people have, especially among new users. The first part of this issue stems from bad internal code that is not up to par with modern game design. Another large part of the issue is the sheer amount of inefficiently made content out there, with much of the worst offending content attached to avatars. It's a huge problem that is impacting literally everyone in a very bad way. The two relevant things to point out here are the mentioned flaws in the complexity system itself, and the fact that complexity based jellydolls are entirely optional. It is very important to realize that when you make limitations optional, people *will* ignore and skirt around them every chance they get. This, unfortunately, is exactly what has happened.

Even if many end consumers are making use of jellydolls, the vast majority of content creators on the grid disregard complexity completely and are uploading content that has no business being anywhere near a virtual world that must download and render assets in real time. As a result the average modern human avatar is usually well over a million triangles, and can fill up 1/4th of your allowed texture memory *by themselves*. This is not an exaggeration either, this is every day Second Life right now, and it is getting exponentially worse.

The sad part is that it doesn't have to be this way. Avatars can very easily look just as good with massively lower complexity ratings (read, better performance, less loading, and less bandwidth used) if people, especially content creators, just have strong incentive to actively use the complexity system in the first place, such as not being jellydolled. Again, resource usage limitations should *not* be optional.

Those of us who have been using this overhaul daily for the past year or so are a mix of both content creators and pure consumers, and everyone has managed to adapt to things nicely while staying within the better avatar complexity ratings listed above. Most have ended up with avatars that have notably lower rendering impact than before. It takes some work and getting used to, either shopping smarter, or improving work flows to consider efficient resource usage, but it is very doable. Limitations to how much resources a single avatar can use in no way translates to limited creativity or loss in visual quality. Both of these are complete non-issues.

This complexity overhaul, or one very much like it, is an absolutely critical first step to fixing one of Second Life's most important problems, and I hope its implementation will be seriously considered.

sl-service-account commented 4 years ago

Iki Akiri commented at 2020-03-16T00:44:12Z

I have been using Chalice’s complexity system for a year now and changing my pipeline and workflow to support it accordingly. The system has forced me to go back to a “Best Practices” way of working; and gives me a good overall picture of how my items impact Second Life and its users as a whole. This has not been detrimental to my business in any way, and I still see a healthy exponential growth and profit despite the shift to a more efficient workflow.

I am fairly certain the reason this complexity limit was not implemented sooner is due to LL’s anxiety regarding the impact on current content creators and their inefficient content. We have adapted positively to large scale changes in the past (ie. Mesh, Bento, Fitted Mesh) and I have no doubt we have the ability to adapt to this; especially considering the base knowledge for efficient content is not SL specific and has more than enough documentation on the internet to support a shift. This has to happen all at once and in a way that will not allow creators to bypass it. We can no longer rely on “Good will” and assume all content creators will take efficiency to heart, because from experience; most won’t - SL is only as good as its most inefficient creators.

LL can support this adaptation for content creators by starting with enforced caps at a higher limit, then tapering down. Couple this with an easy to follow, long term public roadmap on the project and designers will have a lot of room and time to improve with a full awareness of the long term limitations.

Tacking onto Arcane Portal’s comment; It is widely known that SL’s new user retention much lower than it could be, and current user enrichment is very lacking. We have seen a huge overall shift from people exploring and “Hanging out” in public spaces to remaining on their own platforms or land. I would be willing to bet money on the reason (Or at least the main reason) for this is due to poor performance of the system. The lag is obviously caused by content creators who have no incentive or reason to optimize their items. The widely agreed “High Poly/VRAM = High Quality” mantra that so many content creators follow is not only detrimental to Second Life as a whole; but it is also forcing some designers starting off on a good base to increase their poly counts and Vram usage to compete in the market; effectively making the issue worse. Without being held accountable for this; or having more accurate complexity limits in place; designers will continue to bypass best practices in favor of higher poly counts and Vram usage, repeating the cycle and continuing to hurt SL’s usability and even the economy long term as new users turn to other, more efficient virtual platforms.

This complexity overhaul coupled with better documentation on more efficient pipelines is sorely needed to ensure that content creators are all on the same page; and while some creators are knowingly bypassing any efficiency steps they may have done in other studios or projects; the vast majority are simply unaware or have never learned the core pieces of knowledge that are integral to make a “Game” run as lag free as possible.

I implore LL to make the ArcTan project more of a priority and start holding content creators accountable for the greater good. Any of OUR hard earned money put into user retention, marketing or user enrichment will be fundamentally wasted without a solid, lesser lag experience. As a business and platform the detriment of lag causing items is not worth it in the long term. We want to retain new users and enrich our current ones from now into the future.

TL;DR: Rush the ArcTan project alongside Uplift. We’ll adapt for the greater good.

sl-service-account commented 4 years ago

Chalice Yao commented at 2020-03-17T09:40:17Z

I updated the issue text a bit - I misremembered the texture handling as implemented. The .diff actually takes care of identical textures shared between different worn attachments. That is, if the same texture is present on two different attachments, this code will take care of it; The texture will not be counted twice in the complexity calculations.

sl-service-account commented 4 years ago

Kyle Linden commented at 2020-03-18T18:19:19Z

Deferred until next triage.

sl-service-account commented 4 years ago

Vir Linden commented at 2020-03-25T18:51:21Z

Bringing this in for possible suggestions in the ARCTan project. Thanks!