high-tri mesh attachments, and performance

[Rhys Goode]

A recent thread featured the problems encounterd trying to load an attachement with abount 35,000 faces, and how this generates the MAV_BLOCK_MISSING.

Well, I  happened to be making a two chain attachement with 22486 tris, all on one texture face.  So simply splitting the mesh into two different texture faces solved that problem, but in the previous thread, some strong statements were made about the impact of that many tris on client lag.  Now it so happens that one of the things I want to do with this model is to try some normal mapping, but I am really curious with just how bad the full model would be.

Strong statements are one thing, I like to the effects for my self, so off to the test grid.......

The mesh is rigged to the collision bones.  In all cases, I chose the lowest physics, analyze and simplify.  

First I let the uploader to all the lower LODs, high/medium/low/lowest 22346/5608/1401/699.   LI 54.7, $L68.

Standing bald, with UV tattoo for clothes, and a few odd attachemtens, I show a rendering cost of 4645.  Put on my chain attachement rendering cost and the RC went to 10,381.  I put on my hair, RC went to [15,000 to 55,000, depending on the hair.  

I have a pretty strong laptop, so I am not sure how this applies to other setups, but I could not see any impact on my FPS for any of the hairs or for the chain attachement.  And I am all by  meself on an empty platform.

Next, I told the uploader to use the same LOD for High, medium, low, and 0 for the lowest LOD.   22346/ 22346 22346/21.  LI, 1.1 (here the download cost is actually a bit lower than the physics in this case), $L13.

Now when I wear the attachment, the RC goes from 4645 to 5517.  As in the other case, no visible impact on FPS.

The way I upload this mesh, has a huge impact on both the LI and the RC.  I usually do my attachments like I did the latter.  They are relatively small, so they only register as a small numvber of tri;s unless you are standing rather close.  It gives low LI, and costs less $L too.  Now I see the the RC is much less too.

Now 23000 tris is not the same as 35000, but it is in the same range.  And it looks like that range is right at the *low* end in RC for flexi hair.

How can I estimate the real impact of such an attachement, if not the LI and the RC?  I really do like doing things efficiently, I will be interested to see how the normal mapped, low-tri version looks.  I'd be even more interested to know if I had a way to accurately gauge what the impact of such a change really is.

 

 

 

[MIstahMoose]

I'll only say one thing

The average "next gen" game character model (clothes and all) sits around 10,000 tris.

[ObviousAltIsObvious]

this is a "what if everybody does it" problem. not much will happen if a single avatar has silly geometry but it is never a single avatar wearing these things in social spaces.

[Astrid Kaufmat]

The more polygons the more performant gpu would be needed.

LI is not important for worn mesh but high number of polygons yes and it has huge impact on your Rendering.

Take one of those standard models that quite often come with software start subdividing it a lot a lot of times At one point your Fan will be doing WOOOOOOOOOOOOOOO.

Take a concert or a public event put a lot of avatars with mesh made with old way they were started being made using displacement method  on high poly  rather than the actual normal maps some PC would overheat to shout down too.

In some softwares I used to make pics for some websites you could emulate a big number of objects with virtual caching methods, but this is not for SL. make a street and try to render that street with a lot of very detailed lights along it repeated more and more and more times.Sadly SL doesn't work that way all the polygons are and stay there.

In the post you mentioned a guy said something that is a good guide and more and less what I've been doing too. I extracted some game models just to study the geometries and stuff (you can do it as long as it is stays on your own pc and you don't send them around violating copyrights).

From a famous most recent  epic game that also allows mods  you wouldn't imagine how ugly the mesh looks like without the normals. Some warrior skirts use alpha channel together with normal and rather than being like striped skirts (kilts ) like those ancient Roman ones they  are more similar to SL skirt mesh .

Normal maps if properly applied would lead you to make your mesh much more stylized than they've been done till now at least for SL.

I know that some people would say that normal maps are something that nobody would see but that's relative to your pc.

Just today after all I did some check to my pc after that a silly guy decided to grief I got the chance to make some benchmarks on my stuff. The GPU was overheating I took it off,there was not much dust but the gpu after over 7 years of noble service it needed some maintenance I changed the  thermal grease and the temperature was half than before.Before 110 °C  (good to boil eggs) ,after my magic touch it's stable now around 60-70 °C

An old pc without maintenance that should be done least  every each 2 years for over used one could be put on kneels by bad mesh or silly griefers.

[Rhys Goode]

Yes, I know that I can wear high LI attachments without penalty to the local prim budget.  I use the LI of that attachment rezzed on the ground as an indicator of the computational overhead.  And indeed, the flex prim hair that adds about 10,000 to the avatar RC is about 109 LI, another that adds 20000 is about 190 LI.

I hear lots of anecdotes, about the huge impact of high poly count on rendering, with PC's melting into puddles as a result. And I have no doubt that it all adds up, so the lower the poly count the better.  But I would really like to be able to gauge the impact of the things I make against realistic measures. I have a very strong preference for data over opinion, even expert opinion.

I added a third chain to my bauble, got the tri count up to just under 30000.   Its a small object, with the lowest LOD is set to be just 3 tri's (one for each texture surface).  The rezzed LI is 1, and it increases my RC by about 500.   Because is small, it is invisible to anyone more that a few meters away, yet highly detailed for my dance partner.  Every tool I have in SL tells me this piece has much less impact on my neighbors clientside lag that a typical flexy hair or dress.  But people with far more knowledge and experience than I seem to be saying that using more than a few 1000 polys for an attachment is inherently evil. Frankly, I am confused.  

 

By the way, I know a bit about normal maps, I have deconstruced some of those game charcters, and a well done normal map can do amazing things.  Free, public domain models can be downloaded from http://tf3dm.com/   Very instructive.  

[Connor Nowles]

I think this is very interesting, since i have often thought about it when people say that meshes must be so low poly...

No one really talks about LOD... Because at the end of the day when everyone is done argueing about it all, it all comes down to how many polys you have in your view at once, no matter if you have zoomed in and see a few objects or zoomed out and see many...
Two, lets say miniskirts, one with 10.000 faces and one with 3000 faces.. Well, the one with 10.000 faces can be alot better and have good detailes if it has good lod, because when cammed out, it only renders as 200 faces...
While the one with 3000 faces is "LOD optimized to looks good at all distances" uploaded with all lod's at max, and has 3000 faces to render unless you tp to another sim.. :-)
But no one really complains about that, they look at faces and if there are many it is a bad build, so the one with 3000 faces wins even thoug it sucks the most.. :-)

[Drongle McMahon]

The logic behind the calculations for the download weight (usually the same thing as LI) are based on the areas in which the LOD models are seen given a renderVolumeLODFactor (RVLF) setting of 1, a draw distance od 181m, and more or less assuming independent random distribution of objects and cameras in a 2D distribution. It's a good attempt to represent real cost, but these assumptions are not very convincing. First, it seems most people now use higher RVLF, so they are exposed to the higher LODs within much greater areas. Second, and more importantly, real object and camera distributions are highly non-uniform, especially with attachments, because avatars (and therefore their cameras) tend to cluster, and static objects tend to be concentrated where avatars are likely to congregate. Consequently, the apparent reward (in resource saving) of using very low detail lowest LOD is substantally overestimated. That means that this trick does not produce the resource savings that the LI appears to indicate, especially for attachments. Therefore is it not reasonable to regard the technique as a subterfuge to undermine the intent of the LI system, by consuming more resource while incurrring only an underestimated cost?

 

[arton Rotaru]

Still no reason to make the 10k poly skirt, only because of there could be an even more bad object with less polys.

Two wrongs don't make a right.

[leliel Mirihi]

Put a 100lb weight in the trunk of your car and drive around for bit and I doubt you'll even notice it. Put 40 100lb weights in the trunk of your car and drive around for a bit and you'll notice a massive difference. Your tests are completely unrealistic since nobody stands around in an empty sim only wearing one attachment. You're approching the problem from the wrong angle, think about how this item will actually be used in the real world. People wear lots of attachments and they also tend to congregate.

Lets do some quick calculations to see how things can add up fast. Say the average avatar wears 10 attachments (shirt, pants/skirt, hair, shoes, feet, hands, breasts/butt, jewelry, head, more jewelry, ears, tail, guns) and they're all 22486 tris like your object. Now lets say you're in a club with 20 such avatars which isn't that uncommon. So already we're at 4.4 million tris just for the attachments. I don't really feel like going on since this is actually a pretty complicated example so I'll just stop here and let you think about these numbers so far.

[Connor Nowles]

Well, i did a little test.. As far as i know everything is made of triangles in sl, and it all depends on how many Tris the computer has to render per sec.. So high poly mesh = more Tris = more to render = more lag.. right..?

I made a cube in blender.. "Yes i have skills" :-)  And i subdivided it untill it had 12288 Tris.. :-)
Then i uploaded my little lag infested cube and set as many lod's to max as i could without gettint an error message...

Then on a platform in the middle of nowhere, with draw distance set to 32 i was very excited to see how many Tris my computer would actually draw per frame with that object..
So i rezz it and take a close look at it, i make it fill up all my screen, cam around it and so..
But no matter what i do, i can't get the computer to draw more than 28 Tris per frame looking at that object..?
And yes my computer can draw alot more Tris in a scene than that per frame.. :-)

So only 28 Tris drawn per frame with a 12288 triancle object..??   How can that be..??

[Drongle McMahon]

"i can't get the computer to draw more than 28 Tris per frame"

I'm baffled. How do you obtain that figure?

Here I am looking at your 12288 triangle cube (two LODs full detail, then auto), on Aditi, with surface patch, sky, water an avatars turned off (Advanced->Render Types)*, and with draw distance 64m (won't go lower). Using the Develop->Consoles->Scene Statistics console to see how many visible triangles there are. It says 12760. I have no idea where the extra 480 come from.

* Actually, that's not necessary - they don't get counted anyway.

[Connor Nowles]

Well i have no idea, thats why i asked.. :-) It was the number it said it displayed when looking at KTris per frame..
But maybe the K infront of Tris means 1000.?? :-)

That could ofcourse be it, my mistake.. :-)  But i also did a quick test with another thing.. When you look at your avi without shadows enabled it renders a certain amount of KTris.. If you enable shadows it is a very different number of KTris it renders..
So i almost thought that maybe the computer was smart enough to only render the Tris i actually needed to display the 2d frame on the screen, like god knows how many Tris is not needed for a flat surface so it just didn't render them.. :-)
Like if you then turn shadown on, i thought maybe it has to render more "shape" inorder to process the shadows on the body and ground to display it correct on the 2d image frame.. :-)

But again, i don't know.. :-)

[Drongle McMahon]

I need to know where you are getting the numbers of (K)Tris/frame that you are telling us about. Otherwise I can't really work out what we are talking about. How do you get that number? (Yes K=kilo=1000).

[Connor Nowles]

From the statistics window in the firestorn viewer.. the one you get when you press Ctrl + Shift + 1.. :-)

[Drongle McMahon]

Hmm. Same in LL viewer - statistics bar. I'm not sure how good an indication it is because it doesn't seem to take account of occlusion or of LOD (at least in the LL viewer). It stays at 12K for me even with RVLF = 0, when you can see in wireframe that it's the lowest LOD that's being rendered (see ETA note though). I see the same huge increase in triangles (12K->61K)* when turning on shadows. It seems to be a multiplier of about 5x, because a mesh with fewer triangles gives roughly proportionall fewer shadow increase. No idea why that should be, but it would certainly explain the effect of sgadows on fps if it's actually rendering thast many extra triangles! Does anyone know how the shadows are made?

*That's with surface patch etc off - so there isn't anything to put the shadow on.

ETA. Ah! Now it IS changing with LOD switches. There must have been an updatiing problem when I first looked.

[Connor Nowles]

Yeah, the first time i saw shadow enabled vs KTris rendered i also thought no wonder i lag.. I'm no expert in how it all works when it gets that technical, but my conclution was that without shadows enabled, the computer only rendered the Tris facing the screen to create the frame...
And with shadows enabled it also had to render the "backside" that you can't see anyway inorder to create shadows.
Just a theory of course. :-)

If i test it at a place with some people dancing around, the number of KTris doubles 2x when turning on shadows.. Therefore my theory..

But then again, your test with the cube show that it always render all the Tris, so that cant be..
It would actualy be smart if the computer did not render the Tris on the backside of an opject that can't be seen anyway and is not needed to calculated shadows or something else, and maybe also not rendered un needed tris on flat surfaces.. :-)

[leliel Mirihi]

---

Drongle McMahon wrote:

It seems to be a multiplier of about 5x, because a mesh with fewer triangles gives roughly proportionall fewer shadow increase. No idea why that should be, but it would certainly explain the effect of sgadows on fps if it's actually rendering thast many extra triangles! Does anyone know how the shadows are made?

---

Shadow maps are just depth maps from the point of view of the light. When you render the scene you transform the fragment by the light's projection matrix and do a depth test, if it fail the frag is shaded, if it passes it's lit. The 5 maps would be the 3 shadow casting lights SL supports plus sun and moon. This is why shadows cost so much, you have to render the scene from the point of view of each light that casts shadows. Altho it's just an untextured depth render so doesn't cost as much as say reflections would.

[Drongle McMahon]

I'm pretty sure it doesn't render (most) invisible triangles. So I think the figure shown in the statistics bar must just be the number of triangles before invisible face culling. However, looking again, it is now changing with the LOD, which makes it much moew useful. I can't imaginw why it wasn't doing that last time I looked though. Maybe an updating problem.

[Drongle McMahon]

Thaks for that explanation. Here's some interesting info though. Again I can't explain...

I am standing on an Aditi mesh sandbox looking down at our favourite 12288 triangle cube. I turn of everything in Advanced Rendering Types. Sure enough, I can't see anything and the statistics bar triabgle count is 0, whether shadows are enabled or not. Now I turn back on just Volume. I still can't see anything, but the triangle count says 50 with shadows enabled and 0 with them disabled. What are those 50,000 triangles I can't see? I can't see anything by looking around, although the blackness changes to dark blue if I look upwards.

Now, looking downwards again, I turn Volume off and Simple on. Nothing visible, triangle count zero whether shadows or not. Turn Volume on, so I now have just Simple+Volume. Now the cube appears, and the triangle count is 12 without shadows and 62 with shadows. So that's just the expected 12,000 extra in either case.

Now I add a single projected light shining at the cube. Count is 12 with no shadows, 62 with just sun and moon, 74 with sun moon and projctor shadows. So that fits - one extra set of triangles for the projected light. Duplicate the projected light and the count goes up to 88 - not too far off the expected 86, only if projector shadows are on. Duplicating more has no effect (it looks like there can only be two projectors more than whatever is already there - I can only get two shadows if I turn the surface patches back on).

Now I delet the cube. The triangle count goes back to zero. So the unexplaned 50 does belong to the cube. It would be just right for four sets of triangles. Does sun+moon take up two sets of triangles each, even when they aren't in the sky? (this was all at noon).  I suppose there vmay be two light somewhere I don't know about, but then I can add two, which would make six altogether.

Need to sort out what's going on here to know how to use the triangle count for estimating the burden of triangles. Meanwhile, I guess the moral is to only do the measurem,ents with shadows off.

You can also get the triangle count of an object you can select by Using Develop->Show Info->Render Info. Near the bottom it gives the KTris forv the scene, but if you selkect something it changes to the KTris of the selection. It changes with LOD too (done by changing RVLF or moving away). The advantage of this is that you don;t have to subtract the count in the scene without the object.

[leliel Mirihi]

First off You right SL only supports 2 shadow casting lights, I was wrong about that.

As for the extra triangles I suspect some of them are full screen quads used for multiple render passes. In a deffered renderer on the first pass you write out the data to multiple targets (normally diffuse + alpha, normal + spec, depth + stencil for 3 "framebuffs" total, altho other arrangements are also used). Then on the second pass you draw a "full screen quad", this could either be one triangle scaled up to cover the whole screen or two triangles that cover the screen, and the texture you map to the quad is the framebuff from the previous pass. Then in the fragment shader on the 2nd pass you do the lighting calculations using the depth and normals. Post proccessing effects (SSAO, DOF, motion blur, etc.) are done in the same manor with a full screen quad for each one (some times more).

Of couse that can't acount for all the extra triangles you're seening, you'd have to dig in the viewer source code to find out exactly what's going on. I suspect the viewer is doing some dumb things here and there. The shadowing code especially looks rather naive and full of low hanging fruit that could be better optomized.

[Drongle McMahon]

And of course, it could always be a problem with the metering rather than the truth! A question for Nyx at the cc meeting perhaps.

[Connor Nowles]

The Develop->Show Info->Render Info seems to work very well, thanks for that info.. :-)
Have often thought there must be a way to see the tri count of a mesh inworld, and you can actually do it that way.. :-)
And it is also a very good way to se the lod when camming away.. :-)

I think many people would have a lag problem there, since many are told to set lod to max in the viewer by creators who made sculpts that will deform fast to save primcount... :-)  The lod setting in the viewer can make quite a difference about how many tris the comp has to render in a scene.. :-)
But then again many low poly things to save li will distort.. So i guess in some sence low poly things can be just as bad as high poly things.. There are so many ways to look at it, guess i will just have some coffee and think sl is sl.. :-)

[Connor Nowles]

I don't know if this is a stupid idea or even technical possible.. :-)
When looking at the object and sculpt lod slider it controls the lod of all object both worn and in the landscape..
There is also a Avatar lod slider, but it only controls the avatar...

In a really crouded place, i set my draw distance to 32 trying to limit my render to mainly the avatars, and i set avatar imposters to 10 "so i render 10 avatars"..
Then i play with the lod slider.. Setting the lod slider to 1, and then to 4, i saw a difference of up to 1.500.000 Tris the computer had to render.. "and that is per frame"...
And the effect has to come from the avi's, because it changes compared to how many avi's i set to render...

I don't know if it is tecnically possible for the program to see avatar attachments as part of the avatar, and other objects in the landscape as other parts..
But if it was possible, there could be a avatar attachment lod slider.. That would gain alot of preforamce in crouded places when lowering lod on it, without distorting sculpts in the landscape..

And by the way, when set to 1, all the prim hair, sculpted shoes and things people wear still look just fine.. :-)

[arton Rotaru]

Distorting sculpts should simply be replaced with properly made mesh models with usable LOD models. Then your entire scene will look fine with the default RenderVolumeLODFactor settings. It might cost a few prims more, but cramming hundreds of objects onto tiny parcels will kill performance anyway.

[Rhys Goode]

Thats what avatar imposters are all about.  WIth LOD set properly, I can only see a few of them, and most of them cannot see me.