Jump to content

Duplicate mesh objects and lag


ChinRey
 Share

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

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

Recommended Posts

I have been told that tow or more identical mesh objects in a sim share memory and that it's possible to reduce lag quite a lot by by replacing similar meshes with ones that are identical.

I can't fins any specific information about this anywhere though. Can anybody confirm this? And where can I find official documentation?


Also, if it's true, do the meshes have to be absolutely similar or can they have different sizes and/or textures as long as they're copies of the same upload?

Link to comment
Share on other sites

Depends on what you mean by "lag".

If you mean framerate, no, having duplicates makes little to no difference for that. There's exceptions to that, but with any halfway modern computer made in the last 5 years it makes no noticeable difference.

Load time? Yes. The entire scene loads faster if you have multiples of a single object. One load vs. multiple loads.

Laggy chat, movement and such? Nope, no difference.

Lag is a very ambiguous word.

  • Like 1
Link to comment
Share on other sites


Monti Messmer wrote:

Can the viewer determine copies of the same ?

If yes then by name or .... because even copies have their own UUID.

Would be interesting to get insights from the programmers. LL or maybe Firestorm.

Monti

Intersting question. Is there maybe hidden id telling the viewer that object is allready once downloaded from the server? Maybe Firestorm developers would answer that .

 

 

Anyway, theoretically thinking, after all the assets have been downloaded from SL servers to the viewer:

The actual object is more like graphic card's problem at this point. For graphics engine there no difference with object being duplicate in SL or not - it has to draw the polygons in the scene anyway as separate objects. So..thinking this as pure graphics lags...there is no difference.

  • Like 1
Link to comment
Share on other sites

There's definitely an improvement in rezz times, but once rezzed they seem to be treated as separate objects in terms of rendering.

I too would be very interested in actual documentation of a technical explanation on what's going on. All I have is anectodal evidence - a shop full of modular building components and an observation that all pillars, for example, load at the same time.

 

  • Like 1
Link to comment
Share on other sites

I have no info as how SL treats multiple mesh copies, BUT reading this had me remembering Cloud Party --

 

THERE once you "paid" for an object (kind of like land impact but a whole different system) it was thereafter FREE (again somewhat like land impact). So only ONE tree counted against the download for the scene. You could have as many as you wanted.

So in SOME systems that can be very true.

 

Just a FYI thing :D

  • Like 1
Link to comment
Share on other sites

As Arton says, during the beta, the mesh data was a separate asset, so that using it repeatedly, even with different scaling and textures, required only one download. So there was instancing (at the whole mesh level, not, unfortunately, for repeated structure within one mesh). It was like the sculpty map for sculpties. I would be surprised if the system doesn't still work that way, with the mesh asset still there but not accessible by the user, especially not in LSL.

  • Like 1
Link to comment
Share on other sites


Jenni Darkwatch wrote:

Depends on what you mean by "lag".

...

Lag is a very ambiguous word.

It is indeed. But the one thing all kinds of lag have in common is that we want as little of them as possible :matte-motes-wink:

 


Jenni Darkwatch wrote:

Load time? Yes. The entire scene loads faster if you have multiples of a single object. One load vs. multiple loads.

Great! That's good enough reason for me.

 

 


IvanBenjammin wrote:

I too would be very interested in actual documentation of a technical explanation on what's going on. All I have is anectodal evidence - a shop full of modular building components and an observation that all pillars, for example, load at the same time.

 

 I've made similar observations. I have this town made largely from a few standardized modules with different textures and sizes for variety. I did it that way to reduce build time, not lag but others have commented on how fast the build renders compared to other pure mesh builds and I've noticed that all copies of the same module tend to load or (on rare occasions fortunately) misload together. The town spans across a sim border and that doesn't seem to make any difference in this case.

 


arton Rotaru wrote:

There used to be a mesh asset UUID, which is hidden to prevent mesh asset swapping via LSL. (The asset UUID is not to confuse with an object UUID, which is assigned to objects on rez.)

 I suppose that counts as a firm confirmation. If SL had such a system to start with, there's no reason why it would have been changed later.

But... wouldn't it have been nice if we could actually swap mesh model through LSL the same way we can swap sculpt maps? Oh well, I guess that's just wishful thinking.

Link to comment
Share on other sites


Drongle McMahon wrote:

As Arton says, during the beta, the mesh data was a separate asset, so that using it repeatedly, even with different scaling and textures, required only one download. So there was instancing (at the whole mesh level, not, unfortunately, for repeated structure within one mesh). It was like the sculpty map for sculpties. I would be surprised if the system doesn't still work that way, with the mesh asset still there but not accessible by the user, especially not in LSL.

That would make sense, and fit the observations.

It has no bearing on land impact though, and it would be really great if we could access the functionality. I'd love to be able to replace 50 different pillars with a new mesh, or change textures on them all at once.

 

Link to comment
Share on other sites

I would be good. LI, at least the download weight part of it, was originally designed and calculated to account for the use of bandwith, downloading it to everyone who needed to see it. Hence the name. However, when it was realised that rendering resource was of similar importance, there was thought to be sufficient correlation between that and the download weight so that it could be used to control that too. Because of that, it must be unlikely that instancing will ever be rewarded with lower LI, since it doesn't help with the rendering load. It's still a good idea to use it as far as possible to minimise lag. Same with textures. The more they can be re-used the better. Unfortunately, the ever-increasing use of use of oject-specific baked textures ans normal/spec maps works against this.

Link to comment
Share on other sites


Drongle McMahon wrote:

...

It's still a good idea to use it as far as possible to minimise lag.

The lag issue is why I started this thread in the first place of course and yes, anything we can do to reduce lag without reducing content quality is good. I've only been in SL for a little more than a year and it's amazing how much laggier the place has become only in that short time period.

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 3569 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...