Proposal - FAST MESH

[Gabriele Graves]

42 minutes ago, Coffee Pancake said:

Attachments are just collections of objects, the more objects you have the more things need to animate.

So being able to cut down on the animations by being able to wear just one all combined attachment would yield a significant performance boost over wearing say a dozen attachments that give the same visual look?

I ask because if the savings are significant then perhaps some way can be found to auto-combine all the attachments into one temporary logical object when worn so that only one thing is animated.

Edited March 29, 2021 by Gabriele Graves

[ChinRey]

21 hours ago, Mollymews said:

there isn't a more suitable decimation method than what there is now for this particular use case.

Maybe not "more suitable" but there certainly are several less unsuitable ones.

Blender's decimate modifier for example. I would be the last to recommend it as the solution to LoD generation but at least it's not nearly as bad as GLOD. Mesh Lab's simpilifcation alogrithm is a step above Blender's. Both of these are fairly old and created by a single developer in their spare time. I don't think it's unreasonable to expect a team of well paid developers working for a multimillion dollar software company to be able to come up with soemthing to match.

[Coffee Pancake]

Also remember, hand making LOD models once you have the final full detail model is not hard.

It's more time consuming than pointing something with a slider at your work and hoping for the best, but the end results is models that degrade in detail with no visible loss of quality from the users perspective.

The hard part is knowing what the target tris count for your model needs to be at each detail level in order to achieve a certain Li value in SL. Right now this requires iterative trial and error poking the uploader. The proposal in the OP includes having the viewer provide these targets (with some leeway) for each LOD.

It's not a hard or time consuming to iteratively make LOD meshes.

[Kyrah Abattoir]

5 hours ago, Coffee Pancake said:

It's not a hard or time consuming to iteratively make LOD meshes.

It is still an aspect that is considered as "I'll do it sure, but you have to pay for it" by mesh contractors (who are responsible for a lot of the content brands pump out on a weekly basis).

Education of end users is also an issue as they rarely turn against bad creators when confronted with bad LODs, it is usually not considered by the end user until it stares at them in the face. And then it will usually be rationalized as "LL's fault/my computer is *****".

Pretty hard to get people to write honest reviews too given how some creators react to criticism.

[Profaitchikenz Haiku]

2 hours ago, Kyrah Abattoir said:

Education of end users is also an issue as they rarely turn against bad creators when confronted with bad LODs,

Probably because there's a hint of cutting off one's nose to spite one's face there

(your wedding dress looked like a stick-insect at 10 metres so I chose to get married in a potato sack that stayed the same even when viewed from the neighbouring region)

, but most likely because it's easier to use whatever workaround brushes the problem under the carpet, and notching up a slider or bumping up a debug figure takes seconds and doesn't then risk the person getting a diatribe because they left a poor MP review.

[FinnfinnLost]

14 hours ago, Coffee Pancake said:

Oh they are. Animated avatars covered in stacks of rigged objects is why we can't have nice things (with more than 2 friends at a time). The performance hit explicitly due to avatars in groups is staggering and is explicitly due to rigged mesh.

Would enforced LOD targets help this?

yes

I suspect it's less about the rigged mesh and more about the amount of triangles rigged to it. But that's rather pedantic at this point and yes, enforced LOD targets (with enforced custom LODs probably being a good start) would solve it well.

Inspired by this thread, I've been investigating how other games handle modular characters. You know, characters with clothes and equipment and whatnot. No, SL was not one of them. I put special focus on one particular MMORPG, since that genre tends to have a LOT of player characters on screen which, as opposed to NPCs, are not easily baked into one single mesh. Here are some particularly interesting aspects in the context of this thread:

- Clothes and weapons are indeed separate objects. No surprise there. I could not extract the rig or weights since I didn't reverse engineer any game files, but the clothes deform with the character's movements which really only leaves rigged clothes. Live physics would murder performance due to the sheer number of suspected animation layers.

- In some contexts which I could not discern because, again, no reverse engineering took place, every piece of visible clothing is present twice. While this could be due to technical limitations in the method used, the pieces are placed to prevent z-fighting. Don't know what this is about, but it increases rendering load.

- With about 30-50 people taking part in some engagements simultaneously and omitting any characters from rendering not being feasible due to gameplay mechanics (although several generic models exist), this clocks in at ~8 layers of rigged equipment per character, plus equipment that is attached but probably merely parented to a bone. While SL characters can go beyond that, if properly modelled their load should not be anywhere near the one of said MMORPG.

So, what can we take from that? There's two possibilities why avatars can bog down performance this bad. Either the SL engine is incredibly terrible to the point where a few characters are enough to bog it down while others can handle 50 while being at least playable. I am absolutely positive that this is not the case. Unless I missed something, this leaves but one possibility. A boatload of avatars and their clothes and attachments are TERRIBLY optimized. As mean as it sounds, it's indeed the fault of lots of creators, which is unacceptable.

I'm aspiring to create content and am struggling with LODs and LI. And I'm sure this will make it harder for me as well, but enforcing a minimum of knowledge in the LOD and complexity departments is absolutely necessary. As mean as it may sound to some. I hope some of you found this interesting.

[Penny Patton]

3 hours ago, FinnfinnLost said:

A boatload of avatars and their clothes and attachments are TERRIBLY optimized. As mean as it sounds, it's indeed the fault of lots of creators, which is unacceptable.

This is the issue, yes. But it's really the fault of LL for expecting content creators, largely amateurs with no experience outside of SL, to be responsible and optimize their work like professionals do. Most SL content creators don't even understand the need to optimize. You see it a lot here in the forums. People stating, without irony, that modern videocards can handle 10-20GB worth of textures without flinching. Laughing at the idea of limiting the triangle counts on avatars. Many of them honestly believe content isn't the issue and all of SL's woes could be solved if only LL would finally "fix" SL's code.

 These people will never change their bad content creation habits unless LL steps in and makes them change. Which LL will not do. They've had several opportunities to do it without affecting existing content, but chose not to. I have trouble imagining another opportunity coming by any time soon.

[Kyrah Abattoir]

5 hours ago, Profaitchikenz Haiku said:

and doesn't then risk the person getting a diatribe because they left a poor MP review.

Which is infortunate really. Call me an envious jerk but I sincerely believe that at least a couple high profile SL creators do not deserve most of the 5/5 stars they receive given the awful support they provide and their shoddy craftmanship (and that's even assuming they aren't just contracting it out), I would even go as far as saying they don't even deserve the profits they make.

"But it's pretty and I don't want to get banned from the store so... I guess I'll either 5 star, or not review at all?"

  

6 minutes ago, Penny Patton said:

without affecting existing content

That's not entirely accurate, they are perfectly happy breaking content when they deem that content unimportant.

I really wish they would fix rigged mesh lodding. despite the huge content breakage, it is one of the big reasons why our avatars are so heavy.

Edited March 30, 2021 by Kyrah Abattoir

[FinnfinnLost]

1 hour ago, Kyrah Abattoir said:

Which is infortunate really. Call me an envious jerk but I sincerely believe that at least a couple high profile SL creators do not deserve most of the 5/5 stars they receive given the awful support they provide and their shoddy craftmanship (and that's even assuming they aren't just contracting it out), I would even go as far as saying they don't even deserve the profits they make.

"But it's pretty and I don't want to get banned from the store so... I guess I'll either 5 star, or not review at all?"

  

That's not entirely accurate, they are perfectly happy breaking content when they deem that content unimportant.

I really wish they would fix rigged mesh lodding. despite the huge content breakage, it is one of the big reasons why our avatars are so heavy.

Thing is, optimization doesn't pay. People look at screenshots, not at specs. You chuck your sculpt up there, set LODs to minimum and post screenshots with, if applicable, an emphasis on the low LI. Besides, the stuff you don't see might be terrible, but some of those models are simply gorgeous. And if you don't know anything about the more intricate stuff, that's all you'll care about. Heck, some creators of beautiful models might not know what they're doing wrong themselves. Tools like ZBrush, Marvelous Designer and others I'm surely forgetting make it easy to create without ever touching more in-depth topics. Not saying they're not to blame, but it's something to think about.

I don't blame LL for being reluctant about it. They're not a charity organization and a large part of their income is due to people churning out pretty things others want, who then buy L$ and/or have a premium subscription. But complete inaction will make things worse in the long-term.

[Coffee Pancake]

5 hours ago, FinnfinnLost said:

But complete inaction will make things worse in the long-term.

People have been sounding the performance alarm for years, and here we are. 

Only now there isn't any meaningful CPU/GPU advancement coming of the kind that will benefit SL.

So, pending some miracle new render pipeline it can only get worse. There is no long term, we're out of road and Linden's that authorize major works probably still believe the free market will fix it.

[Mollymews]

a thought about helping people make LODs

suppose that the upload process had a function to export LODs generated by the Linden decimator. Export coming before Pay The Fee. Then we could open up the exported LODs generated, do a tidy up as we like, then combine with the original file and Upload again with Includes LODs. Uploader calculates the fee according to pricing schedule, we pay the fee and done

[Wulfie Reanimator]

37 minutes ago, Mollymews said:

a thought about helping people make LODs

suppose that the upload process had a function to export LODs generated by the Linden decimator. Export coming before Pay The Fee. Then we could open up the exported LODs generated, do a tidy up as we like, then combine with the original file and Upload again with Includes LODs. Uploader calculates the fee according to pricing schedule, we pay the fee and done

The auto-generated LODs don't preserve quads at all, though. I don't think there's any way you could take something even slightly decimated and "tidy it up" from there without more effort than you would need to create LODs from the source mesh.

I don't think there exists a group of creators that would be encouraged to create custom LODs by being able to export the auto-generated ones. If they wanted a quick way to simplify their mesh, they could for sure do that in the modeling program they used to create the original model.

Edited March 31, 2021 by Wulfie Reanimator

[Quarrel Kukulcan]

On 3/29/2021 at 1:53 PM, Coffee Pancake said:

The performance hit explicitly due to avatars in groups is staggering and is explicitly due to rigged mesh.

Due to rigged mesh following different LOD display rules and not downstepping, or due to rig-weighted meshes costing more than static ones? Because I've run around with my LOD display factor deliberately set to, like, 0.001 so everything shows at the lowest LOD and I see only a small performance increase -- much smaller than, say, turning advanced lighting off.

[Profaitchikenz Haiku]

6 hours ago, Quarrel Kukulcan said:

Because I've run around with my LOD display factor deliberately set to, like, 0.001 so everything shows at the lowest LOD and I see only a small performance increase

Funny you should say that, because I've often done the opposite, wandered around with rendervolumeLODfactor up around 3.5-4.0, and not noticed any real performance decrease.

But, I rarely go into regions with more than 4-5 avatars present.

[ChinRey]

56 minutes ago, Profaitchikenz Haiku said:

Funny you should say that, because I've often done the opposite, wandered around with rendervolumeLODfactor up around 3.5-4.0, and not noticed any real performance decrease.

Me too. On other occasions the cranked up LoD factor is absolute murder. The relation between LoD factor and lag isn't linear.

[Coffee Pancake]

Benchmarking the viewer without specialist tools is almost impossible, the load placed on the client varies in the extreme depending on settings, location (location location location), avatars present, etc.

Full impact of all settings can't be observed on the fly, in general use or anecdotally. 

If you're not using external profiling tools, the procedure to judge a configurations performance is to get the area as cached as possible, then relog back to that location, touch nothing (don't move camera, open no new UI, use alt with no friends or groups) keep the cursor out of the 3D rendered window, give it several minutes to settle and finish texture decodes / asset fetching, observe FPS. Repeat. Any changes to scene, new avatars etc, invalidates test. Average multiple runs. Unless specifically testing shadows, disable them before starting.

The bulk of the work the viewer does is CPU based (and why performance can only be assessed after all texture decodes & asset fetches have completed). Most heavy loads (such as rigged mesh) are of the death-by-a-thousand-cuts variety with the bulk of the work happening way before the GPU. 

The CPU or GPU will be bottlenecking performance (one always will be). If GPU bound (slow GPU, low VRAM, etc) then rendering only changes have a far greater impact. A large proportion of SL's users are GPU bound presenting a very different outcome. Avatars are bad both ways.

 

[FinnfinnLost]

1 hour ago, Coffee Pancake said:

Benchmarking the viewer without specialist tools is almost impossible, the load placed on the client varies in the extreme depending on settings, location (location location location), avatars present, etc.

Full impact of all settings can't be observed on the fly, in general use or anecdotally. 

If you're not using external profiling tools, the procedure to judge a configurations performance is to get the area as cached as possible, then relog back to that location, touch nothing (don't move camera, open no new UI, use alt with no friends or groups) keep the cursor out of the 3D rendered window, give it several minutes to settle and finish texture decodes / asset fetching, observe FPS. Repeat. Any changes to scene, new avatars etc, invalidates test. Average multiple runs. Unless specifically testing shadows, disable them before starting.

The bulk of the work the viewer does is CPU based (and why performance can only be assessed after all texture decodes & asset fetches have completed). Most heavy loads (such as rigged mesh) are of the death-by-a-thousand-cuts variety with the bulk of the work happening way before the GPU. 

The CPU or GPU will be bottlenecking performance (one always will be). If GPU bound (slow GPU, low VRAM, etc) then rendering only changes have a far greater impact. A large proportion of SL's users are GPU bound presenting a very different outcome. Avatars are bad both ways.

 

If we need an isolated testing environment for stuff like that, someone may create "Benchmark Island". Although I'd like to throw in that we don't know whether the netcode influences the "effective FPS", as in frames that are indeed drawn to the screen. Sure, this might sound silly, but we still get games that suspend drawing if the network connection acts up to this very day. While I don't think LL's developers are bad, SL's old age makes remnants of old practices likely.

[Kyrah Abattoir]

2 hours ago, Coffee Pancake said:

The bulk of the work the viewer does is CPU based (and why performance can only be assessed after all texture decodes & asset fetches have completed).

Yup it is so CPU/throughput bound that the GPU is basically doing nothing most of the time. I get no framerate difference even if i limit my GPU's TDP to 50% (much cooler card tho).

As a point of reference, these are the VRChat content creation recommendations (keep inb mind vrchat treats avatars as whole objects (i only took what was relevant to our tools):

• Reduce the amount of meshes on your avatar: VRChat recommends that you have one Skinned Mesh Renderer at maximum, and 3 static mesh renderers at maximum.
• Ensure that you're not using an excessive amount of triangles: The SDK will warn you if you're trying to upload a model that exceeds 70,000 triangles for PC or 20,000 on Quest. The most effective optimization tends to occur during initial design and avatar creation. In other words, you're going to have problems if you try to take a 120,000 made-for-rendering model and squeeze it into 20,000 polygons. Don't make things harder than they have to be-- find a model that starts low! 20k is quite a large amount of leeway.
• Reduce the amount of material slots you use: Each additional material slot is also a draw call, which eats more processor time! If you have a lot of materials (more than 10), look into Texture Atlasing.
• Alpha Transparency: Alpha transparency is also another expensive part of shaders-- typically you want to be using Cutout or Opaque modes on shaders. Transparency can be quite expensive, so only use it if you know what you're doing!
• Reduce the amount of bones: Even if you have a bunch of bones sitting in a scarf, skirt, or your hair that you're not using for anything, they can incur additional costs during skinning calls that your GPU has to worry about.

Edited March 31, 2021 by Kyrah Abattoir

[Kyrah Abattoir]

In a way VR is much less forgiving than SL and so they have to be much more strict about resource consumption, since you will render the scene twice (once for each eye) every frame, and that low framerate in VR means instant nausea.

[Extrude Ragu]

Not long ago I created a JIRA to allow the upload form to autofill from _postfixes

The feature was since implemented in Firestorm although curiously the notes didn't mention it, in a folder with the following files:

• Cube.dae
• Cube_LOD2.dae (Medium)
• Cube_LOD1.dae (Low)
• Cube_LOD0.dae (Lowest)
• Cube_PHYS.dae (Physics)

If you select Cube.dae, the rest of the form is autofilled, you don't have to browse for each file.

Since this makes it possible to fill out the entire form without filling it out at all, perhaps a utility to be able to quickly generate those LOD files within Blender (decimate modifier?) could be made

[Beq Janus]

21 hours ago, Extrude Ragu said:

The feature was since implemented in Firestorm although curiously the notes didn't mention it, in a folder with the following files:

The change would have been covered in the referenced notes from the lab rather than our own. I implemented the change for FS but when I came to commit it, it had already been added (slightly differently) by the lab so I discarded mine and went with theirs 🙂

I'm still inclined to revisit this and support file names  _MED _LOW and _LOWEST mostly because the backwards LOD naming of SL drives me nuts.

Edited April 1, 2021 by Beq Janus

[Profaitchikenz Haiku]

One thing I haven't seen mentioned in this thread is the "does it matter?" approach to LOD.

For example, consider a hangman's game I created, using one of the inworld generators where you bang the prims together and let somebody's web-page do the surface calculations to throw you back a DAE.

I could have gone through all sorts of calculations at upload time to generate LOD values for varying distances of view, but there was only one distance that made sense,  and that was the diagonal dimension from where the board was to be mounted on the pub wall to the two farthest corners. I only wanted one LOD, "be visible at 8 metres". Anything more than that is outside the pub and therefore not a legal viewpoint (Sorry, cammers-in, learn to walk).

The approach to the more general problem where it does matter that I have been most familiar with over the years comes from the train simulators, where there are varying LOD models with a name suffix that specifies the distances at which the LOD model should be loaded. No distance suffix, one model, loaded as soon as the world tile containing it detects the camera has entered that tile. Other than that, it's a matter of computing the distance to the object and selecting the suffix that most closely approximates that distance subject to the condition of increasing or decreasing distance.

 

Edited April 1, 2021 by Profaitchikenz Haiku

[Coffee Pancake]

2 hours ago, Profaitchikenz Haiku said:

I only wanted one LOD, "be visible at 8 metres". Anything more than that is outside the pub and therefore not a legal viewpoint (Sorry, cammers-in, learn to walk).

This would only work if everyone was on the exact same viewer with the exact same LOD settings. You don't get to specify a distance at which another users viewer decides to use a lower LOD model. You only get to specify the sequence of models.

Oh .. and 'cammers-in' are still be able to see your model by moving their camera into your building, irrespective of where their avatar is parked. 

So yes, it does matter, because that's how SL works.

[FinnfinnLost]

1 hour ago, Coffee Pancake said:

This would only work if everyone was on the exact same viewer with the exact same LOD settings. You don't get to specify a distance at which another users viewer decides to use a lower LOD model. You only get to specify the sequence of models.

Oh .. and 'cammers-in' are still be able to see your model by moving their camera into your building, irrespective of where their avatar is parked. 

So yes, it does matter, because that's how SL works.

To elaborate, this is something very common in videogames in general. Some games offer LOD settings directly, some include it in the "model quality" settings, blending it together, but handling LOD is one of the biggest factors in performance. In fact, there exist a few games that allow the player to ONLY render lower LODs even at close range. Looks terrible, but that's how they can run on a potato.

This is why content creators should never rely on "eh, low LODs won't be visible anyway". While lower LODs do not have to look good, the object and any states it might be in should be possible to identify as long as the object is within rendering distance. Which is another aspect

Yes, I'm sure your fancy dress/object looks very nice when I get up close, but why should I approach your mass of mangled triangles in the first place? And, in case someone doesn't render high LODs due to system limitations, why did the owner of that pub pin that same mass to the wall?

[NaomiLocket]

On 3/31/2021 at 2:29 AM, Penny Patton said:

People stating, without irony, that modern videocards can handle 10-20GB worth of textures without flinching. Laughing at the idea of limiting the triangle counts on avatars. Many of them honestly believe content isn't the issue and all of SL's woes could be solved if only LL would finally "fix" SL's code.

That seems to be a gross overstretch of the imagination. There is nothing wrong or incorrect with expecting a developer to actually do software engineering. That is what professionals do as fundamentally proven by ID software. They accepted the criticism that 2016 doom in all its technological marvel and success in preventing many issues with memory via a texture buffer, didn't give enough detail clarity in its current state. So they changed it for doom eternal like grown ups.

In contrast when developers don't quite get it, you have Fallout 76's idea of code reuse and OOP, propagating vulnerabilities all over, causing their customers to lose money - and "it just works" as a meme.