How can Linden Lab encourage better content?

[Theresa Tennyson]

2 hours ago, ChinRey said:

This avatar isn't even anywhere near "fully fitted up" with fitmesh and it still has three times as many active triangles as the scene around it:

Edit: Maybe there was a misunderstanding here. I shold have said "scene", not "sim". How many triangles there are at the other end of a sim well out of view, is of course irrelevant. My fault.

Also, that doesn't look to be rigged mesh hair. It definitely has flexis and is probably flexis with sculpts, which will give you mind-blowing polygon counts. When I was testing it with an avatar with a mesh body and head and older-badly optimized rigged hair, the hair had more polygons than the body and head, and it still would only have a fraction of the polygons of sculpts-and-flexis.

(Will you please say "rigged mesh" when you mean that, and not "fitted mesh"? They are different. Maybe it's just me - it also bothers me when people call concrete "cement.")

[ChinRey]

4 minutes ago, Theresa Tennyson said:

Also, that doesn't look to be rigged mesh hair.

Look mom, no hair!

ChinRey sighs.

 

5 minutes ago, Theresa Tennyson said:

Will you please say "rigged mesh" when you mean that, and not "fitted mesh"?

I will if/when I talk about rigged mesh which I didn't in this case.

[Theresa Tennyson]

2 hours ago, ChinRey said:

This avatar isn't even anywhere near "fully fitted up" with fitmesh and it still has three times as many active triangles as the scene around it:

Edit: Maybe there was a misunderstanding here. I shold have said "scene", not "sim". How many triangles there are at the other end of a sim well out of view, is of course irrelevant. My fault.

Got it... I was looking at the statistics bar which tells how many triangles are actually drawn in a frame.  If your camera isn't pointed at an avatar those triangles aren't reported as being drawn and the number drops dramatically, but they still appear in the charts you're looking at as "attachment object triangles." Meanwhile, the same number reports the Ktris per frame as being far higher than the "Region Object Triangle Counts - Visible" number you're looking at when you're looking at the region without avatars in the view, even when your own avatar is completely stripped of attachments.

[ChinRey]

37 minutes ago, Theresa Tennyson said:

Got it... I was looking at the statistics bar which tells how many triangles are actually drawn in a frame.

Ok. I got to try that too. As a baseline, here is a completely "clean" avatar in a fairly neutral scene (had to censor the pic a bit of course ):

 

30,984 triangles per frame

 

With the avatar from my previous hairless illustration:

317,325 triangles. So it's still almost 300,000 triangles drawn according to the stats.

 

Most important, if I move away:

It's lower but still over 200,000. So there is some culling going on but not very much. That's interesting.

 

51 minutes ago, Theresa Tennyson said:

If your camera isn't pointed at an avatar those triangles aren't reported as being drawn and the number drops dramatically

That's not what I get. Here I have moved the camera behind my avatar:

and it still shows up with a considerable number of triangles per frame.

But no matter how we look at it, a six digit number of triangles for a single avatar - a single object - is just too high.

And the number of active triangles is still significant because those are the triangles the gpu has to keep tabs on. Many of them may be culled before they get to the screen but that culling quite a bit of work too and since an avatar is a dynamic object with no predictable movement pattern, the culling has to be redone for each and every frame. The gpu can't reuse data from frame to frame the way it can (and hopefully does) with static objects.

[Theresa Tennyson]

1 hour ago, ChinRey said:

And the number of active triangles is still significant because those are the triangles the gpu has to keep tabs on. Many of them may be culled before they get to the screen but that culling quite a bit of work too and since an avatar is a dynamic object with no predictable movement pattern, the culling has to be redone for each and every frame. The gpu can't reuse data from frame to frame the way it can (and hopefully does) with static objects.

No "predictable movement pattern" - you mean like an animation? As opposed to a "static object" whose position on the screen will vary by the location of a dynamic camera?

Meanwhile, the figures on the drawn triangles in a typical background scene, which was what you were basing your original statement on, are conspicuously absent...

Edited May 26, 2018 by Theresa Tennyson

[ChinRey]

45 minutes ago, Theresa Tennyson said:

No "predictable movement pattern" - you mean like an animation?

That's right. Also with individual vertices moving independently and semi-independently of each other.

 

45 minutes ago, Theresa Tennyson said:

Meanwhile, the figures on the drawn triangles in a typical background scene, which was what you were basing your original statement on, are conspicuously absent...

I think the active triangles count in my first post answered that but if you ask:

278,801 triangles drawn.

Not much of a difference but keep in mind that this is a fairly heavy scene with several sculpts. And the avatar I used was a relatively low poly one: mesh body, three pieces of fitted mesh clothing and some fairly low poly fixed mesh jewelry that was small enough to be well and truly LoD'ed out in the pictures anyway. No mesh head and no hair at all. And before you ask: no, I'm not going to spend money on a mesh head and a fitmesh hair just to satisfy you and I have other use for them whatsoever.

 

Edited May 26, 2018 by ChinRey

[Coffee Pancake]

This thread risks leading off into the blind leading the blind territory. It's very easy to armchair the viewer doing it wrong with no concept of how the viewer works, or more importantly, why it works the way it does. SL's performance woes are deeply rooted in it biggest strengths. You can have a well performing static world or a terribly performing dynamic one, not both.

Likewise its super easy to blame content creators. We ALL knew how terrible onion skinned mesh bodies, heads and over detailed rigged clothing was right from day one, and we all buy more and more of it every single day, eyes wide open.

We also demand a contiguous world, dynamic object creation, prims, alpha on everything and models so detailed they are well beyond anything any other realtime platform even attempts to throw around .. AND it all has to be rendered in the same manner as a triple A game.

No single measurement in isolation any objective value. Be it vram use or triangle counts.

 

On the subject of Ktris per frame .. the raw triangle count is only half the story. How those triangles are rendered and lit accounts for a decent hit, how we get those triangles onto our screens in the first place accounts for even more.

 

The same scene. Look at the frame rate and the ktris count. All I changed was the object detail slider.

 

3060 ->1850 Ktris per frame ... and 5 fps. That's a 10% speed increase for a dropping 1/3rd of the triangles.

 

Is it my VRAM .. NOPE.

Is it the triangle count .. NOPE. 

 

It's my GPU sitting idle 50% of the time. SL has eaten all the CPU it can use and the graphics card is sat twiddling it's thumbs.Why? Because SL is a dynamic environment and the CPU has to hold the GPU's hand. Constantly. Every frame .. and to change this would require SL be broken in such fundamental ways that it wouldn't be Second Life anymore.

If I enable shadows the triangle count doubles to 6000, GPU usage jumps to 75% and my frame rate drops to 40. My GPU is still idle for this scene.

 

 

Can we do better .. for sure.

More people looking at the readily available open source viewer code is how we do it. 

Edited May 27, 2018 by CoffeeDujour
Correction .. <3 ChinRey

[Kyrah Abattoir]

One issue that we can't really troubleshoot is the draw call count, since for each object "face" that's at least 1 draw call since the texture/material parameters are going to be different.

I don't know how the SL viewer goes with instanciation but in SL instances are such a fringe case i'm not even sure of the benefit, if any.

Good client or not, we are in a specific 3D environment that behaves a certain way, a good creator should work with the environment their content is designed for, not ignore it and expect the system to bend over to accomodate them.

[animats]

6 hours ago, ChinRey said:

 You log on for the first time, go to a crowded place because you want to meet people and are met with a scene that takes two minutes to load and causes massive lag. Goodbye SL.

That may be a big part of SL's new user retention problem. The tutorials take new users through a reasonable intro, and then dump them into a space full of new users. When they get there, the experience sucks. It's a voice area full of crap avatars run by noobs. Like the popular virtual reality chat world ▉▉▉▉▉▉ , but with more lag.

SL gets about 11,000 new signups a day on the web site. Unfortunately, SL doesn't publish statistics on how far they get. How many launch a viewer? How many make it through the intro?  How many leave the arrival area and go someplace? Clearly the loss rate is huge; if even 10% of the new users stuck around for  a while, daily concurrency would be showing an uptrend instead of a downtrend.

6 hours ago, ChinRey said:

Indeed but let's face it, you need to be a diehard hardcore SL user to endure a single digit fps over a prolonged time. Even 20-30 fps may be too low for people who expect "modern game performance".

Yes. At some point, the viewer should take action to get the frame rate up at the expense of quality. A reasonable floor is maybe 16FPS, old silent film speed; below that it's time for automatic emergency action.

By the way, where was the club you tried? I went through the most crowded areas in "Destinations" with avatar impostors set to 3 and never got down to single-digit FPS values. I only have an NVidia GeForce 640 on this machine, which is modest graphics power today.

[Coffee Pancake]

The viewer should ... NO. STHAP.

WHY is the viewer slow when you TP to a new location. There are hundreds of MB to download and process. Downloading and processing is not free, has to be done, there is no shortcut.

Hacking the client o try and smooth this process out only serves to extend the amount of time it takes to process the required data. This is exactly how we ended up with draw-distance stepping.. and if you know anything about how the client and service works, you will understand why that is objectively a terrible idea for both the client AND the region AND everyone on it.

The best solution is ... LONGER TELEPORT SCREENS. Switching off rendering the world all-together for 30 seconds following a TP will have a dramatic impact on the actual time it takes to get content processed and on screen.

 

Edited May 26, 2018 by CoffeeDujour

[ChinRey]

1 hour ago, CoffeeDujour said:

3060 ->1850 Ktris per frame ... and 5 fps. That's a 1% speed increase for a dropping 1/3rd of the triangles.

Umm no. It's about 10% actually.

[animats]

1 hour ago, CoffeeDujour said:

This thread risks leading off into the blind leading the blind territory. It's very easy to armchair the viewer doing it wrong with no concept of how the viewer works, or more importantly, why it works the way it does. SL's performance woes are deeply rooted in it biggest strengths. You can have a well performing static world or a terribly performing dynamic one, not both. ...

More people looking at the readily available open source viewer code is how we do it. 

Having built Firestorm from source and made mods which are going into the production version, I wouldn't encourage people to dive into the source code unless they have serious C++ experience plus a good understanding of the graphics pipeline. It's a delicate mess inside - few comments, not much separation of mechanism from policy, and undocumented invariants. Plus grouchy Firestorm developers to deal with.

The viewer isn't really that bad. It has most of the right stuff. It's not state of the art right stuff; if you want to see that, download Unreal Engine and build the tutorial projects. But it's basically OK. It could use some policy improvements; rather than having all those manual graphics tuning parameters, it needs to be monitoring its own resource usage and self-adjusting.

The big problems are on the content upload and management side. The upload mesh reducer just throws away random triangles. There's no check to insure that uploaded assets aren't far too dense for the area they cover. There's no automatic imposter generation during upload. The official instructions to users insure that an uploaded mesh will be a bad SL model. Those instructions lead users to upload some random high-poly 3D model and let the uploader use that as the main model, while generating crappy low-LOD models.

Rather than trying to fix mesh reduction in the viewer's content upload, it's probably better to just nag there, and have some external tools available for that job. There are many tools for working on meshes. I've been playing with some of them. Anyone tried AssetGen? This is a free plug-in for Blender which does mesh reduction. It's better than the one that comes with Blender, and far better than the one in the uploader. 

I haven't found an billboard impostor generator for Blender yet. I think the uploader should generate billboard impostors. It already has the capability to render the mesh being uploaded with OpenGL, and does that in a little window. That code could be repurposed to generate the textures for impostors. Impostors are a huge win over the pathetic low-LOD models generated by randomly removing triangles from the mesh.

 

[ChinRey]

55 minutes ago, animats said:

By the way, where was the club you tried?

I can't remember the name. I did an inworld seach for "Dance" in the Places category and picked the one with the highest avatar count that wasn't a nude beach.

[Kyrah Abattoir]

13 minutes ago, animats said:

Unreal Engine

Unreal engine actually has serious performance issues with dynamic/live content. It's an engine that really prefers to work with "pre cooked" data.

[Coffee Pancake]

Eyerolls .... people have been spewing this rubbish since SL was first launched. 

Teh viewer has crumbly render engine .. why you no use <insert game engine name here> ... completely oblivious as to why that is impossible and if you managed to make it work .. it would almost certainly perform worse OR fundamentally break Second Life in the process. 

Please. If you think it can be done, get the source, get the free unreal SDK and try and smush them together. Hell, try unity while you're at it .. or Godot if you want a fully open source solution. 

 

[Kyrah Abattoir]

Impostors have a serious optimization problem, even avatars that are turned into jellydolls don't lead to a real performance boost.

[Coffee Pancake]

Kitty has been working on this for the next Catznip .. we have a reasonable speed increase for impostors and they animate at a slightly higher update rate than previously and a silhouette mode that offers a substantial boost and takes effect as early in the render-pipeline as possible.. both of which are affected by personal exceptions, such as rendering people nearby or friends. (also a couple of other options, but will have to wait for the release).

[Kyrah Abattoir]

I wish that "do not impostor friends or myself" didn't exist as an option, it's literally the equivalent of "lalala i can't hear you" in dealing with the problem

@animats I just tried the decimator included with AssetGen on one of my lowpolies. It's ...not very good.

Edited May 27, 2018 by Kyrah Abattoir

[animats]

1 hour ago, Kyrah Abattoir said:

@animats I just tried the decimator included with AssetGen on one of my lowpolies. It's ...not very good.

Yes. It blew up on some meshes and the results when it worked were disappointing. It's useful for getting some mega-triangle mesh down to 20K or so, but below that it starts to do the wrong thing. That's true of many of these tools.

Blender's built-in Limited Dissolve is good on smooth areas, but terrible on fine detail. It's trying to keep sharp edges in the mesh, so if you have something like a knurled knob, tooled leather, or jewelry, it tries to keep all those little edges. That's why, as Klytyna points out, fancy collars and cuffs tend to have way too many triangles. None of the algorithms which work purely on local mesh properties are very good.

The expensive good ones both rebuild the mesh and generate new textures. Fine detail in some area gets replaced with a flat surface, a bump map, new normals, and a texture image of what it looks like at high-res. The result is halfway between an impostor and a reduced mesh.

The big company in Redmond has a new cloud-based mesh simplifier and level of detail generator. You can either pay $25,000, or use it for free but they get to keep copies of your models.

[Kyrah Abattoir]

I can always hand reduce but I oscilate between too kind and too aggressive. My typical trick on cuffs and other body fitting items is that at a certain point i just strip out all the "inner" faces entirely and only keeps what faces outward when worn.

The result is sometimes invisible, sometimes very obvious.

Otherwise i just turn off edge display and gets rid of anything that doesn't make the model explode, it's not that long but it gets tedious when you do a change/fix to a model and have to redo all the lod models again for 4 different chests.

[Klytyna]

Back when I still made the occasional mesh for games mods that featured LoD's, if the object was going to be big enough, and ultimately detailed enough that it would NEED Lods, then I'd START with the LoD-3 mesh...

You'd set up 4 cameras in your scene in the modeling app, at the different LoD ranges you were going to set in the games config code for the asset, so, make the LoD-3, UV map it by hand, stick on some wip test textures, check that it looks ok in the LoD-3 camera, then take a copy, and subdivide it where needed, and detail.

That big flat area there, doesn't need any more polys, so leave it undivided, but this area here, subdivide and push verts and sculpt in some nice looking detail. Then add another piece of mesh here and here, then UV map the extra pieces.

Check the LoD-2 version in the LoD-2 camera, when its ready, take a copy and repeat the process for the LoD-1, then again for the super detail LoD-0.

You have all your Lod's made, they are all UV mapped, they use the same texture set, and the lower lods (with fewer separately mapped detail pieces attached) use less of the set than the high LoD version, so less texture thrashing at range.

That's how it's done, not by relying on damned dumb "Auto-Fail-Make-CGI-Art" buttons for looks-like-crap poly reduction, and memory wasting cookie-cutter UV mapping that results in "All-on-one-4096-texture-bake-with-Aerial-Squid-Storm-Pissing-Down-Ink-AO-Bake-Fail (tm)" textures, with the inevitable screams of rage when they try uploading their 4096 bake into SL, and it ends up as a fuzzy 1024 due to the use of really crap auto-image-resize.
 

[Willow Wilder]

On 26/05/2018 at 3:03 PM, animats said:

Plus grouchy Firestorm developers to deal with.

I'm taking exception to this comment. If by "grouchy" you mean you can't manipulate them, too bad. You don't run the team, so your demands of when things will be done, or suggestions that things need to be done next, or to suit your personal needs, do not carry any weight. No one is forcing you to deal with Firestorm developers. 

Willow (who can become grouchy when entitled users make a lot of noise)

[Kyrah Abattoir]

On 5/27/2018 at 11:05 PM, Klytyna said:

Back when I still made the occasional mesh for games mods that featured LoD's, if the object was going to be big enough, and ultimately detailed enough that it would NEED Lods, then I'd START with the LoD-3 mesh...

You'd set up 4 cameras in your scene in the modeling app, at the different LoD ranges you were going to set in the games config code for the asset, so, make the LoD-3, UV map it by hand, stick on some wip test textures, check that it looks ok in the LoD-3 camera, then take a copy, and subdivide it where needed, and detail.

That big flat area there, doesn't need any more polys, so leave it undivided, but this area here, subdivide and push verts and sculpt in some nice looking detail. Then add another piece of mesh here and here, then UV map the extra pieces.

Check the LoD-2 version in the LoD-2 camera, when its ready, take a copy and repeat the process for the LoD-1, then again for the super detail LoD-0.

You have all your Lod's made, they are all UV mapped, they use the same texture set, and the lower lods (with fewer separately mapped detail pieces attached) use less of the set than the high LoD version, so less texture thrashing at range.

That's how it's done, not by relying on damned dumb "Auto-Fail-Make-CGI-Art" buttons for looks-like-crap poly reduction, and memory wasting cookie-cutter UV mapping that results in "All-on-one-4096-texture-bake-with-Aerial-Squid-Storm-Pissing-Down-Ink-AO-Bake-Fail (tm)" textures, with the inevitable screams of rage when they try uploading their 4096 bake into SL, and it ends up as a fuzzy 1024 due to the use of really crap auto-image-resize.
 

Unrelated question, why do you always replace standard, clearly defined terms with replacements that ae basically your personal opinion on those things?

I rely on a mix of hand crafted lod and blender decimation (for the lowermost lods.) I use the lodding distances supplied by the viewer at 1.125 lod factor to get a good idea in blender how many pixels tall my object is at the lod change, and then I try to get it as low as possible while looking the same.

Decimation does a reasonable job for the lower lods but sometimes it need to be "nudged" in the right direction by getting rid of the geometry it gets too focused on.

[OptimoMaximo]

On 25/5/2018 at 6:50 PM, animats said:

If that's happening, there's something wrong. COLLADA files have a unit specification. Look in a .dae file (which is XML) and  you should find a line like

<unit name="meter" meter="1"/>

The uploader should import dimensions accordingly.

Read the viewer code, and you'll realize that Collada metric units get discarded and only THEN the scale is applied, in the third tab of the uploader, despite the size being displayed just next to the scale factor. Internally, the mesh is "translated" to fit a cube with 65535 coordinates values and the final size doesn't really matter.

[animats]

40 minutes ago, OptimoMaximo said:

Read the viewer code, and you'll realize that Collada metric units get discarded.

That's a bug. File a JIRA.

Everybody uses real-world units now. "Softimage units" and "Blender units" are from the era before computers had fast 64-bit FPUs and internal coordinates in 3D modeling programs were 32-bit integers.

Mis-scaling makes builds look tacky. A friend just bought a mesh gas station model. Looked OK on Marketplace. When she rezzed it in SL, the gas pumps had the nozzles at head height. "This is for giants", she said. We had to unlink the model and resize everything to real world sizes. We brought in some properly scaled cars as a scale reference. Now she has a good gas station and convenience store.

Edited May 30, 2018 by animats
Expand