high poly = high lag?

[Charli Infinity]

Does a mesh with a lot of polygons means more lag in SL?

I notice when I wear a mesh with high polygons, it will start to lag and  the frame rate drops until it looks like a stop motion animation.

An example is mesh hair from Magika. If you rez it and select it in build, you can see it is made with a whole lot of polygons! Everytime I wear the hair it will start to lag. The hair also has color change hud script in it so I'm not sure if it's the script or the ammount of polygons in the mesh that's causing the lag.

So...does high polygon count means more lag?

[Frawmusl]

DUH!

Thats why they have land impact. The more poly a user has to render the harder it is to render and the more it takes a toll on their computers. I preach optimization with meshes, Proper LODs but people just want the nicest looking thing without realising that maybe its not the server whos always lagging, but rather the person whos wearing the 10,000 polygon ring causing lag :\ Its easier to download a 10 poly well optimized ring than a 10k one. You don't need to zoom and look at highly detailed rings, I mean you can do that... but you won't spend hours examining it..whats the point of it being 10,000 polys. Asidjasidjasfjsa

MESH MAKERS MAKE ME MAD.

(yay for alliteration?)

[Charli Infinity]

Ok. I'm not a maker so I don't know about this stuff. Magika hair is very popular... Obviously a lot people don't know about this either. All the high polygon meshes lagging up SL...

Maybe there should be a polygon limit for attachment like LI for land to reduce lag but a lot of people would be mad abou that.

[Maeve Balfour]

Definitely. As you have disovered, many merchants who create and sell mesh products haven't got much idea about proper optimisation for SL's realtime rendering environment. The more detail that needs to be created and displayed on your screen means the slower the framerate your PC can generate per second (the fewer times the screen can be "redrawn" means a laggier experience in that regard - hence your description of stop motion animation).

Ideally, meshes SHOULD be created with as few polygons as possible - only using the barest minimum required to get a required shape, AND have proper level of detail (LOD) meshes for when the the detail swapping occurs (as the camera pulls away, these lower detail meshes will swap in, reducing the detail needing to be rendered for that object - meaning better framerates when done well). I suspect some merchants have the full detail for each of the four LOD meshes, which will also hugely affect framerates and induce this laggy effect in extreme cases.

Sadly, I think a lot of merchants assume that MORE polys is better - and / or simply don't care about framerate issues.

So yah, wherever possible, it's always a better option to wear (and use) optimised, efficient meshes - it will mean a better experience for yourself and those around you as well. Unfortunately, from what I can ascertain on my general Marketplace searches of late, a great many merchants don't seem to understand or bother with mesh optimisation. By all means, be very fussy about which merchants you buy from - and when you find ones who DO care about efficiency, stick with them (they are out there, but you have to search hard at times to find them).

:matte-motes-smile:

[Madeline Blackbart]

There is a reason that games use lower poly's then moveis and why movies can take literally YEARS to render out each frame. A lot has to do with poly's. That said it's not just high poly's taht causes lag though it doesn't help. Large textures, heavy scripts, and a low end computer rendering them can also be causes of lag as well.

[Codewarrior Congrejo]

did i hear high poly and lag? 

to add to the other answers: *takes a deep breath*

Let's differenciate, lag can be caused by  different things: server lag and lag due to too many things summing up in the render pipeline and thus lagging your experience and controls , or other hardware based issues causing any type of lag.

But since we are on the topic mesh let's skip severside or connection based lags and get into the things that can lag you regarding graphical (GPU) and processor (CPU) impact.

Lag is allways an experiences that differenciates between one computer and another. Depending on how powerfull the hardware is. What lags one person with a slow computer doesn't need to lag another. 

But in general the rule stands: the more to render, the more lag potential is apparent.

The amount of polygons of course has an impact for your graphic card to render - the more polys - the more your graphic card has of course to do.

Even though it has to be mentioned that the polygons / faces themselve are these days rather the smaller problem, but the vertices are. And of course the more polygons a mesh has the higher the amount of vertices.

Tons of UV seams and smoothing groups or material groups can add to this.

The whole thing becomes even worse when those overly polygon'ed meshes are rigged. Because now also the CPU has more work. And Graphic Card and CPU have to update and render all the faces, keep track of all the positions of the vertices and much more.

As the others already stated: unfortunately not many 'creators' actually have a clue or are even interested in learning how to produce 'reasonable' content - fitting to the requirements and limitations of a certain engine (Secondlife in this case)

Thus what we see is a lot highly dense meshes, that drain unecessarily on the users graphics and render time.

so long story short > hilarious high amounts of polygons are of course one of the number 1 lag factors. (especially when you take into account that there is not only this 'one' object to be rendered, have 20 avatars with too heavy meshes in your view and your mashine has a 'lot' to do to render all this)

PS: i would like to add something at this point that often goes a bit under in the discussion about high poly vs low poly.

>>> Textures!

People already didn't really consider this back when they only had prims available. Texturing every little piece of an earring with a different 1024x1024 pixel big texture.. adding up like 20 Textures, that other games would use to literally texture a whole szene or landscape. And they now proceed doing it this way on meshes. Making high polygon objects with  way too many texture maps / materials.

 “draw calls“ is the magic word here.  Your graphic card can only handle so many of these per rendered frame and keeping this low is going to have a big impact on performance. A draw call is done for each material on a mesh every frame.  One mesh doesn’t equal one draw call. A lot of engines will actually limit the number of materials you can put on a single mesh. 

It also has to be mentioned that even instanced meshes with the exact same materials will require separate draw calls.

So if we add this up now with meshes in addition:
Means too many textures (drawcalls) and on top of that too many polygons and thus vertices in the renderpipeline > there we have our lag.

So yes, as you noticed yourself already that one dress can decrease your performance a lot. If you imagine 20 avatars wearing the same and appearing on your screen, the answer stays yes : )

 

[FlashFuchsia]

Mesh hair, by default is always pretty high poly, since it's such a complicated shape, but it really shouldn't be ridiculously high. Extra detailed hair is nice, but it's not worth the payoff for having your computer explode in a fireball that can be seen from space every time you decide to wear  the hair.

[Rahkis Andel]

Every time? I'd love to have a computer that could shoot fireballs into space repeatedly.

Better than fireworks.

[FlashFuchsia]

It really is. I save money on fireworks every year by just loading high-poly objects onto my computer. Different objects explode different colors too!

[Codewarrior Congrejo]

noooo !  not my beloved computer! please ! 

even though the thought my computer could send a visual signal all the way to outter space, sounds appealing.. just noooo!

[LepreKhaun]

Though the answer is "yes", high poly = high lag, the problem fashion puts on the user experiance goes a lot further than that.

 

I recently rezzed a male hair on the ground to examine. It was made some 5 years ago and consisted of 240-odd sculpties. Only 3 sculpt maps, mind you, but used repeated for each curl and lock. I also examined a female hair made around that time, it had a little over 100 flexie prims (a major source of client side lag).

 

So, yeah, one can rightfully say:

 

for the all those prims we wear, no one seems to much care.

[Codewarrior Congrejo]

for the all those prims we wear,
no one seems to much care.

nice rhyme ; )

[Chic Aeon]

Well I know you CAN quote something in this forum but the process seems to be evading me so here is the part I am confused over:

It also has to be mentioned that even instanced meshes with the exact same materials will require separate draw calls.

Everything else I got and agree with. Not sure what the above means though. Can you say in a different way perhaps.

Knowledge is power -- or at least has the potential to keep us out of trouble.

[Codewarrior Congrejo]

(yeah the quotes sometimes seem to not like us, that's why I also mostly just copy and paste it manually)

But to answer your question: (I'll try to make it understandable .. Quotations on 'try' lol)

- an instance of an object is  basically like a 'live link' between  those 2 objects. Which means:
  the original is always equals the instance and the instance is always equals the original

- Instances are being used when the exact same object appears more then one time on a scene. 

Note: that is nothing you can control it's defined by the engine. Unless an engine allows to deliver instances of objects to be flagged as such and imported (i'll come to that later in this answer)

(also some 3D programs allow internally to create 'instances of objects' to easily address them to do something all at the same time and in the same way, like changing all of their textures at once and so on)

- lets say you have a landscape and there are rocks all over the place, then it's beneficial to have them as 'instances'.
  If you need to change their textures you can do that by simply changing the texture on the original.

- Some engines make use of optimization and use of the fact that it's the same object with the same properties to lower the drawcalls. (when the instanciated objects meet the requirement of having 100% the exact same properties)
This process is called Drawcall Batching.

- Regularly every object (mesh / model) is one drawcall, no matter if texture or not, but without batch optimization, every instance of an object is also one drawcall. With optimization however, if you would change the instanced object just in the slightest way (i.e.. scale it uniform or non uniform  or anything else that would change it) you break this 'connection' of optimization and it will create an own drawcall again.
Hence  - my sentence : that even instaciated objects can have each one own drawcall > even when having the exact same texture.

- About drawcalls: 
Your video card can only do so many of these per rendered frame and keeping this low is having a big impact on performance. A draw call is done for each material on a mesh every frame.  One mesh doesn’t equal one draw call. A lot of engines actually limit the number of materials you can put on a single mesh. The old Nvidia Series 600 could handle 600 drawcalls per frame. Newer series can do 1000, and so on.

- In secondlife all objects are editable / scalable / texturizeable, thus SL did never intend this kind of batch optimization for the render and streaming pipeline. (and as being said, the slightest change on the instance of the object already breaks this anyways and creates a new drawcall)

- All you can do is to change the diffuse  / the texture map being applied to an object. (and in future the normal and specular map, but its still just one shader) the shader stays the same.

As of 2011 it was mentioned that SL respects instance flags in uploaded collada files, but the resulting instances would be able to be scaled / modified / limited independently from each other. Using the same model multiple times in a build can thereby save downloading / loading times. But this only affects the downloading time, and not the drawcalls or rendering pipeline.

- SL offers on the other hand a version of drawcall batching: in the advanced settings : RenderMaxTextureIndex this controls how many textures can be combined into a single batch (Setting it to 0 will effectively give you 50% more draw calls. On certain systems, this can result in a fairly big performance break-ins)

But  > to quote the SL wiki about Culling here : ..."The other major limiting factor for performance in SL is the small batch size. On average, SL draws about 70 triangles per drawing call. In theory, increasing that number to 200 triangles per drawing call could improve rendering performance by 200%. The primary reason the draw size is so small is because we have to break batches to switch textures and to sort transparent objects to be rendered in depth order. "

That is (as he states there too, one of the reasons) why modern game engines (the game: RAGE was one of the first ones to do that)  are so much into something called 'megatextures'  - by making huge textures of 8000 pixels² and even more , they combine i.e.. a whole landscape or scenery onto one texture / texture atlas, to optimize the drawcalls. So that the whole geometry can be rendered in one single draw call.


And to quote once more one of the LL Devs stating this : 

Since textures in SL are streaming, though, generating atlases for your builds will result in ugly artifacts as textures load, so the correct solution is probably something between megatexturing and atlasing, where atlases are generated on-the-fly by the viewer and tailored to align texture borders within the atlas along mip borders according to the amount of the texture that's been downloaded so far.

We've (somewhat intentionally) done a very poor job at Linden Lab of educating builders on how to be performance conscious, which I think plays a large part in the overall sluggishness of the viewer. This is part of a philosophy that says it should be possible to build a content authoring system where artists don't need to care about performance implications, as the software should just deal with whatever comes its way appropriately. What we've seen, however, is that people (even technically minded people) consume as many resources as are available to them until performance reaches a level they deem is unacceptable, so the more efficient your renderer becomes, the more ludicrous the demands become. In SL, this usually means the performance becomes that of the lowest common denominator in terms of what is acceptable.  <--- my personal opinion: a wise guy saying this ^^

Long story short : Textures are still one of the big banes of our 'graphical' existence and in the render pipeline. (next to vertices) And people are completely unaware or not interested in thinking about this.

Even though it should have made them wonder when they have ever seen textures of game props or character texture skins, why the game artists cluster as much as humanly possible onto one texture.

The amount of drawcalls some item creators force onto users graphic cards by immense amounts of drawcalls for even the smallest items (as in my example putting  1024x1024 textures  on every single prim of an earring, causing 20 drawcalls just for that little thing - where others would have created a full landscape by using that) instead of using 125x125 pixel textures for those small parts to minimize  - if not the drawcall itself - then a least the memory the texture takes up in the rendering process. (textures have to be redrawn, and rewritten into the graphics memory / cache very often - the smaller they are the faster it goes of course)

This is at least one of the reasons why there is and has always been so much graphics and in some cases still bandwidth based lag.

Here is another interesting article I keep referring too, regarding what actually goes into the render pipeline, and why too many vertices are bad, and too many UV seams and materials etc. http://www.ericchadwick.com/examples/provost/byf2.html

And since the whole drawcalls and UVs kind of can go hand -in-hand on mesh models something to take into consideration when creating UVs for models:
http://answers.unity3d.com/questions/14578/whats-the-best-way-to-reduce-draw-calls.html

Regarding the use of the same texture space several times from the same texture when a certain pattern or area can be repeated on a model or subparts of a model. (Overlapping UVs in order to 'reuse' the same texture space etc) .

And here is a full PDF about drawcalls and instanciating: 
http://http.download.nvidia.com/developer/SDK/Individual_Samples/DEMOS/Direct3D9/src/HLSL_Instancing/docs/HLSL_Instancing.pdf

I am not sure if I could make it understandable enough for you - but I tried =)

[say Moo]

When normal map support kicks in (finally), most mesh objects can be lowered in tri counts (since you can bake the high details as normal map and apply it to the low tri mesh. Inworld this low tri mesh looks like a high detailed one, without the lag tax.).

I'm impatiently awaiting the support of normal maps. (a wonderful world is near)

[Kwakkelde Kwak]

---

say Moo wrote:

When normal map support kicks in (finally), most mesh objects can be lowered in tri counts (since you can bake the high details as normal map and apply it to the low tri mesh. Inworld this low tri mesh looks like a high detailed one, without the lag tax.).

I'm impatiently awaiting the support of normal maps.

(a wonderful world is near)

---

Call me sceptical, but going by the current SL content, it won't help performance all that much.

Skilled mesh builders will be able to make "better" mesh, but the unskilled builders will just keep their high poly objects and add 8 1024x1024 normal maps to all of them, lagging SL even more.

Oh well, we're used to it

[Coby Foden]

---

say Moo wrote:

I'm impatiently awaiting the support of normal maps.

(a wonderful world is near)

---

There is already materials project viewer available to play with.

Here's the link (in case you didn't know):

http://wiki.secondlife.com/wiki/Linden_Lab_Official:Alternate_Viewers

Scroll down to "Project Materials Viewer"

 

Main grid (Agni) has the support for materials in all regions.

It appears that in beta grid (Aditi) the support is not yet on in all regions.

I played with that a bit and the results look really great.

[Charli Infinity]

I've heard about this but what is a normal map? when is it coming? Is it more work to make?

[say Moo]

Oh that i didn't know. I shall try this viewer.

But normal support is not officially supported as we speak on the agni grid, since it's alpha (very alpha).
They will introduce it with big fanfare announcements when it's stable enough to call it supporting. Also the viewer has to be made ready (official one that is).

Still thank you Coby.

[Kwakkelde Kwak]

---

say Moo wrote:

 

But normal support is not officially supported as we speak on the agni grid, since it's alpha (very alpha).

---

It is very very much beta. Why else would it be on the beta grid?

I think we can expect it pretty soon.

[Theresa Tennyson]

---

Kwakkelde Kwak wrote:

---

say Moo wrote:

 

But normal support is not officially supported as we speak on the agni grid, since it's alpha (very alpha).

---

It is very very much beta. Why else would it be on the beta grid?

I think we can expect it pretty soon.

---

SERVER support is in beta at least. VIEWER support is in alpha. Think of it as the basketball court has been built but the team has just started practicing. And they're kind of clumsy right now.

[Rahkis Andel]

---

Coby Foden wrote:

---

say Moo wrote:

I'm impatiently awaiting the support of normal maps.

(a wonderful world is near)

---

There is already materials project viewer available to play with.

Here's the link (in case you didn't know):

http://wiki.secondlife.com/wiki/Linden_Lab_Official:Alternate_Viewers

Scroll down to "

Project Materials Viewer

"

 

Main grid (Agni) has the support for materials in all regions.

It appears that in beta grid (Aditi) the support is not yet on in all regions.

I played with that a bit and the results look really great.

---

No way. That would be like childhood on a Christmas morning and you can unwrap your presents but never touch any of the toys.

I think I'll just wait for it to actually be released. I don't fancy torturing myself.

[Coby Foden]

Three days ago I made some tests with materials in then main grid.  The viewer still has some glitches.  It didn't crash but applying normal map and diffuse map does not work excellently yet.  Often one needs to apply those many times before it "sticks on".

Here is a default prim box with materials applied on it:

• Diffuse map
• Normal map
• Specular map

Pretty awesome effect.  The flat prim surface does not look flat any more.  Magic.  :matte-motes-big-grin:

[Kwakkelde Kwak]

---

Theresa Tennyson wrote:

 

SERVER support is in beta at least. VIEWER support is in alpha. Think of it as the basketball court has been built but the team has just started practicing. And they're kind of clumsy right now.

---

No need to nitpick over a term too much, but the fact we can download a viewer and try it out means it is out of alpha already. Alpha is inhouse testing.

The basketball court is more or less done, the rules of the game are written, now it's up to the clumsy team to see if the court is bumpy and if the rules make it a playable and fair game. There will be some players that have played the game before elsewhere and know what should work and what not.

[Drongle McMahon]

"As of 2011 it was mentioned that SL respects instance flags in uploaded collada files, but the resulting instances would be able to be scaled / modified / limited independently from each other. Using the same model multiple times in a build can thereby save downloading / loading times."

I don't think I have understood wht you are saying here. What do you mean by "instance flags"?

If you upload collada files with (1) the same <geometry> ID in two <instance_geometry> tags in one <node>, (2) two different <geometry> IDs in the same <node> or (3) the same <geometry> ID in two different <nodes>, the results are always the same; that is you get a linkset with two prims. Now since the characteristic of a <node> is the same as that of a prim, independent transformations (translate, rotate, scale), this means that the <instance _geometry> tag is used to decide what is in a prim, without reference to the loss of independent transformability in the <node>. Did you mean something else?

When I constructyed a "fractal" tree , whose trunk and branches were all instances of the same <geometry> with each in it's own <node> for different transformations, the upload weight was the same as when the tree was constructed with multiple copies of the same single trunk mesh. I suggested an option toggle to use this sort of instancing on rezzing after download, sacrificing the separation into a linkset, to save download volume (at that time that was seen as the major concern rather tha rendering overhead). This would have made a huge dowload time saving for all meshes with extensive internal repetitions. However, it was considered too complicated to implement, and anyway, it would hav meant more cpu time and no saving in rendering resource.

So we are left with instancing where the same model is used in many replicates in a region. That clearly is used, as you can see by the simultaneous reappearance of multiple replicates after a cache clear, bu that isn't banything to do with the collada file.

Meanwhile

Concerning vertex splitting, as discussed in one of the links you gave - In SL, this all takes place before the model gets uploaded. That's why people often ask about the unexpectedly high vertex counts in the uploader. The effects are thus already reflected in the download weight, which should incentivise people to make exactly the kind of optimisations suggested in the linked page. That is one beneficial result of the internal upload format. It makes for a good correlation between download weight and render resouce use.