Jump to content

Serious drop in fps with mesh


Icarus Lytton
 Share

You are about to reply to a thread that has been inactive for 4042 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

I built a house using regular prims with a few mesh windows and stairs inside. Everything was very smooth until my sisters (it's a family house) started to furnish it. When I turn towards certain parts of the house, my fps drops from 50-80 to 1-2 fps and my viewer almost freezes. This won't go away - I have to turn away for this to work. The odd thing is, if I derender all the mesh items and restart my viewer, everything is smooth. Once I get the lag and I teleport to other places, I get lag whenever mesh is in view over there as well.

It seems to me that there's some bug in the code with how it handles and loads mesh but I don't know what - I use the latest Firestorm viewer and it has me stumped. Does anyone have any ideas?

Link to comment
Share on other sites

A secret you'll never hear on this forum or any other forum inhabited by "creators" and those who bring it up are generally ganged by the mob and shut down. MESH LAGS. And yes it can nearly freeze you if you're close to it with an older PC especially. Mesh aircraft..you know the ones uploaded fropm turbosquid and resold here as original work... (not all mind you but at least one "popular" jet builder has been caught at it) with rotating mesh blades are the worst.

 

Unless you desire some odd shape that only LLMesh can provide, then try using legacy prims/scuplts since everyone can see those. Many can not even see mesh still because the mesh viewer LAGS and not everyone is wealthy enough to go buy a new computer everytime the mob here tells them to. This goes double for clothing. If you want to be seen by everyone in SL, instead of as a half-naked blob by many, the wear legacy prims. Mesh looks no better than any other clothing or build.

It..is...not...."better".......except for the "builder" (Uploader).

Link to comment
Share on other sites

From what you say, it is not a bug in how mesh is loaded.

If that were the case, it would happen to everyone and it would only affect you while the mesh was loading. Meanwhile, you say it doesn't just go away.

My guess is that it is isolated to one or more items in your house. Unfortunately, content creators have an unprecedented freedom to upload things that completely disregard the limitations of a game engine (much less an online game). It is possible the item has an okay LI too; LI says nothing about how the item is handled by your graphics card.

Check the wireframe of every item in your house and you'll probably find one that is much denser than the others. Or maybe it is something about the item that has nothing to do with the fact that it is mesh, like a lot of large materials or inefficient physics shapes.


It's a bit of a laundry list of things to look for, but that's why you must be careful when purchasing things, mesh or otherwise.


Edit: Regarding what the person above me said while I was typing my response, I have largely already said my peace, but I will expand it a bit.

This issue is complicated by ignorance and human error. The plain fact is, mesh doesn't specifically lag anything. To say that "Mesh Lags" or to imply that there is a conspiracy by builders to impose mesh to make Second Life lag for those who don't have  expensive computers is rediculous and frankly, stupid.

The truth is that content creators are not usually knowledgable game asset designers. An ignorant content creator can and usually will create an item that is much less resource efficent than a prim.

Prims are a rediculous concept if you think about it -- All you can do is keep mashing them together and adding textures to them until they look the way you want. Meanwhile, modeling for a game engine is all about preserving as much geometry as possible while still getting the shape you want. It basically contradicts good game design.

It's frankly impressive that Second Life could ever run on anyone's computor. In fact, my experience is that it hasn't. I had to buy a new computor for Second Life to run anything close to smoothly and that was before mesh was introduced. Since then, every mesh item that I've personally bought has loaded much faster than prim objects, has had lower LI and I have never singled one out as the cause of lag. What does that say to you?

Experienced mesh creators can and do make items that look and perform infinitely better than prim products. Unfortunately, the ignorant ones I mentioned above are probably more the norm right now.

So, what does this all mean? Buyer beware: If you can't demo it before you buy it, don't buy it.

Mesh is something that needs to be embraced so that the ignorance that causes the "lag" can be cured by experience and new knowledge.

Cheers.

*Edited again to remove some irrelevant hyperbole.

Link to comment
Share on other sites


RangiUtu wrote:

A secret you'll never hear on this forum or any other forum inhabited by "creators" and those who bring it up are generally ganged by the mob and shut down. MESH LAGS. And yes it can nearly freeze you if you're close to it with an older PC especially. Mesh aircraft..you know the ones uploaded fropm turbosquid and resold here as original work... (not all mind you but at least one "popular" jet builder has been caught at it) with rotating mesh blades are the worst.

If you don't know what mesh is, it would be the right thing to do not to comment. You are misinforming a lot of people here.

Every object you see on your screen in SL is mesh as far as your graphics card is concerned. That includes a legacy (prim) box and that includes sculpties. And it of course includes "mesh". So if you say mesh lags then you are saying all objects in SL lag. You're kind of right if you say that, but your fps won't drop more from a 2048 faced mesh than from a sculpty.

The problem with some "mesh" items is people uploading models ment for single frame or movie renders, not real time renders. Another problem is some builders are focussing on landimpact rather than common sense let alone some responsible behaviour. Make a model that is insanely detailed and the LI is too high. Oh wait, we can set LoD med, low and lowest to 3 verts and 1 face. Oh it looks distorted now, let's advice people to dial up the RenderVolumeLoDFactor. That is not the way to do it but is unfortunately the way many residents think and work.

So this is where you need to look for "lag". Not the "system", but the user. Not mesh, but the creator. It doesn't take a lot of efford to lag any sim using a handful of prims, sculpties OR mesh.

I rebuilt a good part of my sim in mesh and the polycount on the objects done is in the region of 10-100 times smaller than the old prim/sculpt mix. Performance obviously went up, not down.


Unless you desire some odd shape that only LLMesh can provide, then try using legacy prims/scuplts since everyone can see those. Many can not even see mesh still because the mesh viewer LAGS and not everyone is wealthy enough to go buy a new computer everytime the mob here tells them to. This goes double for clothing. If you want to be seen by everyone in SL, instead of as a half-naked blob by many, the wear legacy prims. Mesh looks no better than any other clothing or build.

You don't need to be wealthy, my SL business partner uses a Pentium 4 and reasonable graphics settings and gets about 20 fps on our sim. Pricerange of that setup? I don't know...fifty bucks if you can find such an old computer?

Ever tried to rig prims or sculpties? That's the big visual difference mesh brings. If you compare non rigged clothing, it's mainly the performance that benefits from mesh, as long as it is built right.

My best advice would be to look at demo models before you buy any mesh item. Then again I'd advice the same for prim and sculpt builds.


It..is...not...."better".......except for the "builder" (Uploader).

Please explain.

 

 

Link to comment
Share on other sites

Stating that critics on mesh are ganged up and shut up by a pro-mesh mob is a cheap shot, RangiUtu. If you make comments others disagree with and debate then deal with it, don't play the victim. if used well, mesh use far less faces than any prim can ever do.

It's not mesh on the whole that causes lag, it's the way some creators make models. But this is true for anything created in SL. Build something with an excessive number of prims with lots of high resolution textures and you'll have lag. I am pretty sure that the problem reported by Icarus can be tracked down to one or more items made by a specific creator, and replacing those items with better modeled items would solve the problem. What Rahkis suggests is the right way to identity the problem.

Link to comment
Share on other sites


Icarus Lytton wrote:

It seems to me that there's some bug in the code with how it handles and loads mesh

As others have already well stated, the problem you're describing can only be the result of one or more improperly created models. It's absolutely, positively NOT indicative of any sort of bug in SL, or problem with mesh itself as a medium.  Let me state a few facts about how it works, and then let's talk about how to solve your problem. :)

You mentioned both handling and loading.  Let's talk about each.

The first thing you MUST understand is that every single item in SL (and in every video game you've ever played) is a mesh object.  Prims are mesh objects, trees are mesh objects, avatars are mesh objects, even the land, the sky, and the sun are mesh objects.  The fact that SL now has the capacity to import and use externally created models, whereas before it could only use that small set of models that had already been built into it, does not change how the system works at the base level. 

In other words, the "new" mesh cannot and does not handle any differently from the old items, in terms of live performance.  They're all the same thing, as far as your computer is concerned.  It cannot be otherwise. This is a fundamental principle of how computer graphics works.

As for loading, all assets load pretty much the same way.  But even if they were somehow to load in different ways, that wouldn't affect your continuous FPS.  Loading of an item only happens once, after all.  It's not an ongoing thing.

 

(It's astounding, by the way, how some SL users are under the ipression that mesh is this newfangled thing that LL invented.  The truth is mesh is everywhere, and has been since the dawn of modern graphics.  It's been in use for at least 30 or 40 years now, and likely will remain in use for the next 300 to 400 or more.  It's as intrinsic to computer graphics as oxygen is to breathing.  The word "fundamental" is actually an understatement to just how elemental it is.  It's the core of just about everything.)

 

All that said, the trouble you're experiencing is obviously very real.  So let's talk about the causes for it, and how you can solve it.

The "new" mesh in SL can be used wisely or unwisely, just as anything else can be. When mesh models are properly made, they'll actually increase your FPS, rather than decrease it, relative to equivalent prim or sculpty builds.  But when they're improperly made, then yes, they can and often will act as FPS vampires, lagging the hell out of everyone around. 

An unfortinate fact of SL is that a lot of content is badly made.  That vast majority of content creators, and content consumers, have absolutely no idea what they're doing.  Those who know how to optimize their builds properly will expreience consistently high frame rates, while those who don't will suffer.   When models are not made correctly, it's not SL's fault, not the model's fault, and certainly not mesh's fault.  It's the fault of the person who made it, and the person who bought it.

In other words, poor performance boils down to simple human error.  That's the good news.  It means you can take steps to fix it.

I picked oxygen as an analog a moment ago.  Let's stick with that, to illustrate this point.  Used correctly, oxygen keeps you alive.  Used incorrectly, it burns down your house.  If the latter were to happen, would you say there must be a bug in how the house handles oxygen?  Or would you put the blame where it belongs, on the whatever human idiot did whatever humanly idiotic thing that sparked the fire in the frist place?

The moment LL flipped the switch to allow import of arbitrary mesh models in SL, they basically handed a giant box of matches to a group of six-year-olds.  Some of the kiddies will learn to handle the power responsibly, but a certain percentage are just going blow things up, and that's that.

Modeling for realtime environments like SL is all about finding ways to do more with less.  But some people in SL just don't get that.  They pile on the polygons, by factors of ten, a hundred, a thousand, or even ten-thousand times more than necessary, and then they say, "Look what a great artist I am!"  What these people don't realize (as I've said before, and I'll keep saying) is that they're the laughing stock of of the 3D modeling community at large.

I don't mean to be rude, but really, when someone uses 50,000 polygons to express a shape that could be made just as well from 500, we absolutely do laugh at them, and rightly so!   Seriously, it comes up in conversation far more often than you might think.

Don't get me wrong; anyone who's been on this form for more than a day or two has seen the lengths I go to to patiently educate people, without judgment.  I'm here to help.  My point is simply that if I of all people can't help but join in the industry-wide laughter about this, it speaks volumes about just how deep the problem goes.

 

As a consumer, the best thing you can do for yourself is look before you leap.  If you're interested in a model that is for sale, look at the actual model, not just the picture, before you buy.  Examine not just its land impact, but its display cost.  Take a look at its wireframe.  If it's nice and sparse like it's supposed to be, then go ahead and buy.  If it's overly dense, then steer clear of it.

Remember, LL's primary focus is on land impact, because land is how they make their money.  Land impact is a direct analog to server resources, and LL is, more than antyhing else, a server host.   YOU, on the other hand, are an end user, not a server host.   YOUR focus, therefore, should be first and foremost on client side performance.  The ONLY way to ensure good performance is to make sure the poly counts in the models you buy are never any higher than they need to be.  If a model is very poly-heavy, just don't buy it  Look for an alternative that is better made (or better yet, learn to make it yourself, and you'll never ever have this problem again).

Link to comment
Share on other sites


RangiUtu wrote:

A secret you'll never hear on this forum or any other forum inhabited by "creators" and those who bring it up are generally ganged by the mob and shut down. MESH LAGS.

Sorry, RangiUtu, but that statement smacks of so much deliberate ignorance on the topic, it almost defies description.

First, saying "mesh lags" as an absolute is like saying "cars crash" as an absolute.  Fact:  Cars only crash when they're driven improperly or poorly minatained, and mesh models only cause lag when they're made iproperly or used unwisely.

As I said a moment ago in my reply to the OP, a properly created mesh model will ALWAYS create LESS lag than an equivalently shaped prim model.  Prim models, by definition, are chock full of extra polygons that do not contribute the models' outward appearance.  Arbitrary mesh models can eliminate all that waste, thereby greatly reducing lag.

Second, you seem to be completely oblivious to the fact that EVERYTHING you see on your screen in SL is a mesh model.  That includes all prims, avatars, trees, land, sky, sun, moon, everything.  The only difference is that those items happen to already be loaded into the system, whereas newly created models have to be imported first.  Once they're in, they're all the same thing.

This is a basic fact of graphics.  It cannot be otherwise.

 


RangiUtu wrote:

And yes it can nearly freeze you if you're close to it with an older PC especially.

If it's badly made, sure.  If it's well made, that will never happen.

 

 

The problem is that not all content creators in SL understand how to make their models correctly.  From the attitude you're expressing here, it seems clear that you fall squarely in with that crowd, and that's where you want to stay, which is really unfortunate for you.  If you'd just open your mind a little toward learning how this stuff actually works, you could make your lag problems disappear tomorrow.

 


RangiUtu wrote:

Mesh aircraft..you know the ones uploaded fropm turbosquid and resold here as original work... (not all mind you but at least one "popular" jet builder has been caught at it) with rotating mesh blades are the worst.

I don't know what models in particular you're referring to, but it goes without saying that not everyhting for sale on Turbosquid is meant for use in realtime environments. 

The fact that it's an aircraft, or that it as rotating parts, has nothing to do with it.  If it's an inefficient model, it's an inefficient model, no matter what it looks like.

Once again, if the model is properly made, it will cause far less lag than its prim-based counterpart ever could, whether we're talking about airplanes or anything else.

 


RangiUtu wrote:

Unless you desire some odd shape that only LLMesh can provide, then try using legacy prims/scuplts since everyone can see those. Many can not even see mesh still because the mesh viewer LAGS and not everyone is wealthy enough to go buy a new computer everytime the mob here tells them to.

Sorry, but you're once again ignoring the facts.  The vast majority of SL users are now using mesh-capable viewers.  I believe the latest published statistic was well over 90%.  For any creators to invest in the past in order to cator to those few stubborn holdouts would be unwise at best, and utterly ridiculous at worst.

You've clearly got some kind of irrational bias against mesh, which I'm not going to try to pretend to understand.  Your words don't change the facts, though.  As a wiser man than you or I once famously stated, "Facts are stubborn things."

 

As for this "mob" you claim goes around telling people to buy new computers, they must be really effective as secret societies go, because I've never seen or heard of them.  I've been here on a regular basis for well over 9 years, and I honestly can't remember the last time any person suggested that any other person buy a new computer, in any of the content creation forums. 

That's not to say it's never happened, of course.  It's probably happened many times.  People talk about all kinds of things.  But it certainly doesn't happen often enough to be of note.

That said, the fact (yeah, facts again, I know, annoying, right?) is SL is not an easy program for any computer to run.  It never has been, and likely never will be.  Even state of the art, ultra high end gaming rigs have their share of troubles with it.   If you want decent performance, you should have a machine that is up to the task, and there's nothing wrong with saying so.  If you can't afford one, so be it, but nobody's in the wrong if they happen to suggest you'd have a better experience with a better machine.  I'd have a better driving experience if I owned a Ferrari instead of a Dodge, but is that really worth making a stink about?

Plus, if you really do have an under-powered machine that's all the more reason to embrace mesh.  As I've said umpteen times now, a properly created mesh model will be friendlier to your machine than an equivalently shaped prim model.  Again, this is just a fact.

It's unfortunate that so many SL content creators are so ignorant of how to properly optimize their creations for good performance.  You'd do well to aim your rhetoric toward that subject, if you really want things to improve.

 


RangiUtu wrote:

This goes double for clothing. If you want to be seen by everyone in SL, instead of as a half-naked blob by many, the wear legacy prims.

I'm fine with being a half naked blob to the extremely small percentage of people who refuse to use a modern viewer.  As I said a minute ago, investing in the past is just silly.

 


RangiUtu wrote:

Mesh looks no better than any other clothing or build.

While it's true that a bad artist will produce bad looking work, whether it's made from mesh or prims or what have you, a good artist can produce far better looking (and better performing) results with mesh than with prims or sculpties.

If you happen to be under-capable as a mesh artist, so you personally have not been able to reap the visual benefits, that's your problem.  It's got nothing to do with mesh as a medium.

 


RangiUtu wrote:

It..is...not...."better".......except for the "builder" (Uploader).

Not sure what you mean by that.  Care to explain?

 

 

Link to comment
Share on other sites


Chosen Few wrote:

 

 The ONLY way to ensure good performance is to make sure the poly counts in the models you buy are never any higher than they need to be.  If a model is very poly-heavy, just don't buy it  Look for an alternative that is better made (or better yet, learn to make it yourself, and you'll never ever have this problem again).


How can a consumer find this information though? How can a consumer gain the knowledge to know what to look for when shopping for products?

Link to comment
Share on other sites


RangiUtu wrote:

 

Many can not even see mesh still...

Do you know how many actually is this "many" you are referring to?

Here's the latest figure:

"On February 28, 2013 mesh viewer adoption has reached 96.7 per cent."

So we can safely say that by now the great majority of SL residents can see mesh.  Naturally it is a pity for those remaining ones who just cannot afford to upgrade their computers so that they would also be able to use mesh enabled viewers.  But that's how things are with computer technology.   New things need newer hardware.  There is nothing what can be done about it.  Should SL stop feature development because of those remaining 3.3 per cent of users who cannot see mesh?  For how long time?  When would "all" see mesh?  After one year, two years, three years... or even longer?  Surely you understand that the great majority would not want to wait.

 

Well designed mesh is great.  There are already many examples of this in the grid.  It can look amazing, it can be very low lag too.  All kinds of shapes what can be imagined - not possible with prims - can be created with mesh.

If mesh lags then it is a mesh what is not created well, it is most certainly mesh with insanely high polygon count.  That kind of mesh has no place in real time environment like SL.

 

Link to comment
Share on other sites


Ciaran Laval wrote:


Chosen Few wrote:

 

 The ONLY way to ensure good performance is to make sure the poly counts in the models you buy are never any higher than they need to be.  If a model is very poly-heavy, just don't buy it  Look for an alternative that is better made (or better yet, learn to make it yourself, and you'll never ever have this problem again).


How can a consumer find this information though? How can a consumer gain the knowledge to know what to look for when shopping for products?

That is an excellent question.

 

Honestly, I think that there are some simple and not so simple things LL could do to help guide the consumer in the right direction, but I just woke up from a nap, so I'm not really lucid enough yet to propose such ideas seriously.

 

Long story short: In the case of Second Life, It's in the hands of the end user to educate itself...

 

I think I speak for all software developers simultaneously when I say "We're doomed."

Link to comment
Share on other sites

Okay I'm going to write a nice and long reply to this:

I tested a lot of different viewers - Singularity is the only one that didn't have the problem. Areas that would lag massively on Firestorm, run butter smooth on Singularity. The fact that it runs on V1 code kinda shows me the problem lays with the viewer code and how it handles mesh in memory.

Also, I don't really buy that whole "mesh has always existed so it shouldn't be different" etc. Why?

- prims are saved in memory with text - what is saved is the UUID of the textures and all the settings of said prim. The viewer basically applies these settings to the prim and since the prim is hardcoded, it doesn't have to be cached as mesh

- sculpties = cached as a texture, NOT polygons.

- avis and everything else mesh = hardcoded into the viewer.

User-made mesh is loaded in memory as mesh - not as text, not as textures - so it IS the first time the viewer has to constantly load and unload mesh into memory.

 

I also did quite a few tests with my friend and we found out the following:

It's not about how complex the mesh is. It's a problem with how it caches it. I spawned about (and I'm not kidding) 500 mesh items with each item having over 30k polygons. that's 15 million polygons and I got 45fps. I THEN zoomed in, hiding my avi (and its mesh hair, boots, etc.) and zoomed back out and the exact same scene suddenly saw my fps drop to 0.8fps. And it remained there indefinitely. Please someone explain to me how this is NOT a viewer problem - because it seems to me that when I zoomed out and it had to load the mesh on my body, it started to spaz out.


I've tried a million different settings, all sorts of stuff, and it all boils down to this: the performance is completely random and when I get 80fps one minute, I'll get 1fps another minute when nothing new has appeared. My graphics card isn't taxed, my memory hasn't run out - yet my entire PC is down to a crawl. It's like some bad code in the viewer is sending stuff in an endless loop.

So does anyone have any ideas now? I do appreciate all the answers but it's not the solution and this lag shouldn't happen so drastically.

Link to comment
Share on other sites

Trying to make rhyme or reason of this stuff sometimes is mind boggling.

When Mesh was introduced it brought my computer to a crawl also.  A 75% plus hit in performance.  I did good to get 5 FPS on some SIMs.

Several JIRA's with many people here and a Linden Dev trying to find a solution.  No one was ever able to discern a cause or a solution.  I probably did 20 clean installs trying all kinds of Viewers.  The Dev even obtained the exact same GPU I have and could not duplicate my problem.

So I limped ahead with Firestorm Beta (pre-mesh) for at least 6 months, maybe longer.

Last winter I decided to upgrade my computer from Win XP to Win 7.

All my problems vanished.

And I now get higher frame rates then I did before Mesh was introduced.

Same exact hardware.

It really can drive a person nuts!

 

 

 

Link to comment
Share on other sites


Icarus Lytton wrote:

Okay I'm going to write a nice and long reply to this:

I tested a lot of different viewers - Singularity is the only one that didn't have the problem. Areas that would lag massively on Firestorm, run butter smooth on Singularity. The fact that it runs on V1 code kinda shows me the problem lays with the viewer code and how it handles mesh in memory.

Also, I don't really buy that whole "mesh has always existed so it shouldn't be different" etc. Why?

- prims are saved in memory with text - what is saved is the UUID of the textures and all the settings of said prim. The viewer basically applies these settings to the prim and since the prim is hardcoded, it doesn't have to be cached as mesh

- sculpties = cached as a texture, NOT polygons.

- avis and everything else mesh = hardcoded into the viewer.

User-made mesh is loaded in memory as mesh - not as text, not as textures - so it IS the first time the viewer has to constantly load and unload mesh into memory.

 

I also did quite a few tests with my friend and we found out the following:

It's not about how complex the mesh is. It's a problem with how it caches it. I spawned about (and I'm not kidding) 500 mesh items with each item having over 30k polygons. that's 15 million polygons and I got 45fps. I THEN zoomed in, hiding my avi (and its mesh hair, boots, etc.) and zoomed back out and the exact same scene suddenly saw my fps drop to 0.8fps. And it remained there indefinitely. Please someone explain to me how this is NOT a viewer problem - because it seems to me that when I zoomed out and it had to load the mesh on my body, it started to spaz out.

 

I've tried a million different settings, all sorts of stuff, and it all boils down to this: the performance is completely random and when I get 80fps one minute, I'll get 1fps another minute when nothing new has appeared. My graphics card isn't taxed, my memory hasn't run out - yet my entire PC is down to a crawl. It's like some bad code in the viewer is sending stuff in an endless loop.

So does anyone have any ideas now? I do appreciate all the answers but it's not the solution and this lag shouldn't happen so drastically.

Not to say you don't have a potentially valid point, but your experiement wasn't exactly scientific. You didn't use a controlled setting, you're not giving us all the variables, such as how you set your LODs and you have no point of comparison to prove or disprove that the mesh makes a difference.

It's possible that when you zoomed back out, it tried to switch to the highest level of detail on all the items at once and crashed. That isn't exactly an unexpected consequence of doing what you did in that test case. Did you reuse the highest LOD for each item or did you generate different LODs for each?

Would you have gotten the same result with sculpties?

 

Did you try this test on all of the viewers you have?

I don't know -- It's possible that it is a viewer issue, but I can't corroborate that with personal expeirence, so I'm not really able to offer much as far as ideas asides from my initial thoughts.

Link to comment
Share on other sites


Perrie Juran wrote:

Trying to make rhyme or reason of this stuff sometimes is mind boggling.

When Mesh was introduced it brought my computer to a crawl also.  A 75% plus hit in performance.  I did good to get 5 FPS on some SIMs.

Several JIRA's with many people here and a Linden Dev trying to find a solution.  No one was ever able to discern a cause or a solution.  I probably did 20 clean installs trying all kinds of Viewers.  The Dev even obtained the exact same GPU I have and could not duplicate my problem.

So I limped ahead with Firestorm Beta (pre-mesh) for at least 6 months, maybe longer.

Last winter I decided to upgrade my computer from Win XP to Win 7.

All my problems vanished.

And I now get higher frame rates then I did before Mesh was introduced.

Same exact hardware.

It really can drive a person nuts!

 

 

 

Unless you were using Windows XP 64 bit, you transitioned from a 32 bit to a 64 bit operating system which greatly expands your system memory potential. If you had a pretty decked out system, you may have had more ram/vram/etc. than WinXP could address and after upgrading to Win7, all of a sudden you had all this unused potential unlocked.

Asides from that, very true. There are just so many variables at play in Second Life that it really can drive you nuts.

Link to comment
Share on other sites


Icarus Lytton wrote:

 

I also did quite a few tests with my friend and we found out the following:

It's not about how complex the mesh is. It's a problem with how it caches it. I spawned about (and I'm not kidding) 500 mesh items with each item having over 30k polygons. that's 15 million polygons and I got 45fps

I'd say this would indicate it IS a polygon issue, assuming you rezzed 500 duplicate items.

If LL isn't completely insane, the raw data is only read from cache once for the 30k object, not 500 times. The full 15M polygons do have to be rendered of course.

For prims or sculpts, which use a different format before they reach your graphics card (or even a few steps before, I don't exactly know how that works), the data would also be read once. Compared to the render time, the converting time from either "prim text", "sculpt colour" or "mesh text" to geometry should be very short. After the converting the data should be a bunch of vertices, faces etc for all objects.

It would be interesting if you could expand your test, as it's not very complete yet. Without a good comparison with prims and sculpts,  nothing can be concluded other than "this set of mesh items lowers my fps this much".

- Try the same with prims, 15M polys is possible. I managed to get a deformed torus to 19.758 triangles on the highest LoD, so 759 of them would add up to 15M. Settings are:

Path Cut 0.000-1.000

Hollow 95.0

Hollow shape Square

Twist 360/-360

Profile Cut 0.020-1.000

Revolutions 4

- Try the same with sculpties, 15M triangles translates into 7324 of them.

One thing to keep in mind, as has been said, is the LoD. You can see how many triangles are actually processed through the development menu. Develop -> Show Info -> Show render info. With nothing selected you will see the number of (K)tris three lines from the bottom. If you select an object, you can see the individual number of (K)tris. Also keep in mind that opening this console will lower your fps drastically, I estimate it about halves the fps. They will go back up as soon as you close the console. I didn't try, but I think if you set your RenderVolumeLoDFactor to 4 (or maybe a bit higher?), you'll only see the highest LoD.

Link to comment
Share on other sites


Icarus Lytton wrote:

- prims are saved in memory with text - what is saved is the UUID of the textures and all the settings of said prim. The viewer basically applies these settings to the prim and since the prim is hardcoded, it doesn't have to be cached as mesh

- sculpties = cached as a texture, NOT polygons.

- avis and everything else mesh = hardcoded into the viewer.

User-made mesh is loaded in memory as mesh - not as text, not as textures - so it IS the first time the viewer has to constantly load and unload mesh into memory.

Your apparent definition of "saved in memory" in this context is very incomplete, and phrases such as "cahced as mesh" or "constantly load and unload mesh into memory" are potentially misleading.  If I'm reading you right (which I very well might not be), you seem to be implying that parameter lists and file formats that are used for storage and network transfer somehow play a direct role in what's going on in the graphics pipeline.  I can promse you, they don't.

Before we go any further, let's make sure we're comparing apples to apples.  By the logic you seem to have outlined, if prims and sculpties are not "cached as polygons", then neither is an arbitrary mesh.  Allow me to explain. 

The file that describes a user-made mesh is just a text file, fundamentally no different from the text file that describes the parameters of a prim or a sculpty.  At that point in the pipe, it's all just text.

Further down the pipe, the data that gets sent to your graphics card is always the same kind of data, whether the object being described is a prim, a sculpty, or an arbitrary mesh (or an avatar, or a tree, or anyhting else).  At that point, it's all geometry to be drawn, not files to be stored.  Your graphics card does not know or care about prim parameters, or sculpt maps, or anything else along those lines.  Its only concern is for the actual polygons and pixels that make up the 3D scene.

Here's a more accurate (yet still drastically over-simplified) description of the process:

slAssetPipeline.jpg

All of the parameter lists and mesh descriptions in the first stage of the chart are text files.  In the second stage, the infomration from those files is compiled into somehting graphics pipeline can use.  That process happens in the exact same way, regardless of wherever the various components from the first stage happened to have come from.  And of course, by the time it gets to the third stage, it's purely graphics data, which no longer has anything directly to do with anything from stage one.

I did not include texture files in the chart, in the interest of keeping it simple.  For those, just add another box to stage one.  The rest of the chart remains the same.

I hope this makes a little more sense now. :)

 


Icarus Lytton wrote:

I also did quite a few tests with my friend and we found out the following:

It's not about how complex the mesh is. It's a problem with how it caches it. I spawned about (and I'm not kidding) 500 mesh items with each item having over 30k polygons. that's 15 million polygons and I got 45fps. I THEN zoomed in, hiding my avi (and its mesh hair, boots, etc.) and zoomed back out and the exact same scene suddenly saw my fps drop to 0.8fps. And it remained there indefinitely. Please someone explain to me how this is NOT a viewer problem - because it seems to me that when I zoomed out and it had to load the mesh on my body, it started to spaz out..

Unfortunately, anecdotal experiments like this can lead to all sorts of false conclusions, based on the experimenter's preconceptions about how things MIGHT work. As others have stated, your experiment as described was unscientific.  Where's your control, for example?

You rezzed 15 million polygons worth of mesh models, but you did not rez an equivalent amount of prims or sculpties for comparison.  For that you'd need 7325 twisted toruses, and then 7325 sculpties.  Then you'd need to ensure that the LOD's for the mesh models are created such that the total poly count at each level will be equivalent to the poly count of the pirms and scupties at the same level.  Also, for best accuracy, you really should be working with the same amount of objects in each case, which means 7325 mesh models, each with 2048 faces, and the correct number of vertices and UV points at each level.  (I think it's 1056 for both, at highest LOD, but don't quote me on that, as I don't have it in front of me right now to double check. I don't recall off hand what the lower LOD's are, and frankly, I don't recall off hand what all the lower LOD's are.)  Finally, each set shoud contain the same assortment of object sizes and polygon sizes, in the same configuration, as in each other set, to ensure that the LOD switching happens at the same point for all.

Once you've repeated the experiment several hundred times, with all three types of objects, then and only then will you be able to say you've got something you can actually learn from.  Until then, all you've got is anecdote, which could mean anything (or nothing).

 


Icarus Lytton wrote:

Okay I'm going to write a nice and long reply to this:

I've tried a million different settings, all sorts of stuff, and it all boils down to this: the performance is completely random and when I get 80fps one minute, I'll get 1fps another minute when nothing new has appeared. My graphics card isn't taxed, my memory hasn't run out - yet my entire PC is down to a crawl. It's like some bad code in the viewer is sending stuff in an endless loop.

So does anyone have any ideas now? I do appreciate all the answers but it's not the solution and this lag shouldn't happen so drastically.

The randomness only underscores the non-science in your experiment.  Your assumption about "bad code in the viewer" and "endless loop" is just a speculative and untested hypothesis, as I think you know.  I wouldn't even go so far as to call it an educated guess; it's just a guess at this point.

As for a solution, there's a fairly obvious one, right of the bat.  Don't put 15 million polygons in a scene! :)

  • Like 1
Link to comment
Share on other sites


Rahkis Andel wrote:


Perrie Juran wrote:

Trying to make rhyme or reason of this stuff sometimes is mind boggling.

When Mesh was introduced it brought my computer to a crawl also.  A 75% plus hit in performance.  I did good to get 5 FPS on some SIMs.

Several JIRA's with many people here and a Linden Dev trying to find a solution.  No one was ever able to discern a cause or a solution.  I probably did 20 clean installs trying all kinds of Viewers.  The Dev even obtained the exact same GPU I have and could not duplicate my problem.

So I limped ahead with Firestorm Beta (pre-mesh) for at least 6 months, maybe longer.

Last winter I decided to upgrade my computer from Win XP to Win 7.

All my problems vanished.

And I now get higher frame rates then I did before Mesh was introduced.

Same exact hardware.

It really can drive a person nuts!

 

 

 

Unless you were using Windows XP 64 bit, you transitioned from a 32 bit to a 64 bit operating system which greatly expands your system memory potential. If you had a pretty decked out system, you may have had more ram/vram/etc. than WinXP could address and after upgrading to Win7, all of a sudden you had all this unused potential unlocked.

Asides from that, very true. There are just so many variables at play in Second Life that it really can drive you nuts.

I'm running Win 7 32 Bit.  And not a decked out system. 

CPU: AMD Processor (3000.17 MHz)

Memory: 3328 MB

OS Version: Microsoft Windows 7 32-bit Service Pack 1

Graphics Card Vendor: NVIDIA Corporation

Graphics Card: GeForce GTS 250/PCIe/SSE2/3DNOW!

 

 

What ever was going on, it was a real pain in the hootch at the time and I'm glad it's over.  :)

 

But it is also why even though I know the Viewer and the Platform (servers) have problems, I don't automatically jump on the SL is the suxors band wagon. 

Link to comment
Share on other sites

In addition what all the others already answered and stated greatly (so no reason to repeat all these valid points);

Just one thing to repeat: all your graphic card sees is vertices and tris. No matter what it had been before. (text in asset-files, or information placed into an image)

In Terms of geometry all your graphic card receives is this, it doesn't care if this data was placed as text-file or image-data or as mesh asset data (which is btw. also just 'text'),   within the data transfer that leads the graphics towards the output. It cares about Texture Maps (not talking sculpty maps here, they are simply also just stored along as every diffuse or texture map in the cache), vertices, tris, and shaders etc.

I think Chosen's little image-table should make this fact clear enough.


So even if the i.e.. default avatar is hardcoded into the viewer code, your graphic card still yet has to render its tris and verts.

Lag and FPS drops can come from a variety of reasons. (server lag, graphical lag, memory lag, CPU limits etc)

To get to your question on 'how this can happen' (as in viewer X runs better then viewer Y):

The fact that one viewer does it better for you then another does not necessarily depend on one of them being buggy or badly coded.

I.e.. Singularity is based on an older SL viewer as you figured (Viewer 1.23 to be precise). Thus supports also older hardware that the newer LL viewers do not support anymore. Shader versions and OGL Versions also vary within the different viewer architectures. It is not needed that your hardware is old and outdated thus not running good with the newer viewers. Even with up to date hardware, it is still a question of which shader models are supported, which driver sets are installed and what certain capabilities or limits these have.

Also technologies such as multithreat. , 64 bit technology and many more can make quite a difference in how certain things are computed and how well received based on the technologies a certain client addresses and another maybe not.

And the fact that you receive more 'lag' in one viewer opposed to another is thereby rather a question of which one obviously suits better for your hardware and driver combination (and as the example of Perrie Juan shows sometimes even the OS version). And don't need to imply generally that there is something terribly wrong with the other viewer. They are still based on the same viewer code, just with different stages of technology being addressed. And some have developements towards features they found helpfull or even trying to develope for technologies like specualirity etc.

The newer Viewers also have higher system requirements. And thus might require 'different' settings for you to work out. And not the exact same that worked well for you within another viewer based on an older version.

To do your tests you have to really understand the architecture of the viewers and your hardware / software. And would need to bring their settings to the best responding with your hardware / drivers, for each of them individually.

As you can see in Nvidia's article on how to fight lag (http://www.geforce.com/Optimize/Guides/how-to-get-rid-of-lag-guide#1 ) it's mostly a combination of settings for your drivers as well as the software (game / viewer) settings. Rather then the game-code itself being all crippled.

And one important thing to understand: what works for game A, doesn't need to work the same way for game B. Which is the same with the SL Viewers.

You see there is much more to take into account and consideration, before being able to point fingers and say this viewer's build is fail. (And generally spoken: the mesh integration used across all viewers is basically the same: they all have to grab the data from the mesh-asset file, and send it to the graphic card which receives it's vertices and tris again)

PS: also a crash or low FPS after zooming out fast from several million polygons apparently does not only happen in SL alone. Even in Programs made to display such amounts and to work with them (Like Zbrush, Mudbox etc) you will encounter such fatal issues, depending on the view angle you had on the model, and how fast you did it, how much geometry it had to refresh and redraw is responsible for such impacts. (because when you are zoomed in everything out of your field of view is hidden, when you return fast and have to redraw several million vertices and faces plus shading, materials and more.. Well in (insert random number here) %  tries this will result in the software crashing or your computer being heavily slowed down. It has to keep track of endless strings for locations for all of these vertices and the other mentioned data, and often simply looses track or even data within such an action, and in worst case even keeps being stuck at one string, not being able to proceed.

Means: one time you might be happy and able to do that, but next time it just causes big problems. So also this is no valid indication of a viewer being more messy then another one.

Maybe that helps you to understand a bit better : )

PS: i denie to make any comments on RangiUtu's imaginary answer lol. 

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 4042 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...