Does Size of Club Directly effect LAG

[xDJTechx]

ok a question came up the other day in reference to amount of Lag produced in club i manage. here's the question i have to forum  if i have say 25 guest in club and the size of the club has them somewhat "packed in". would making the club Larger reduce the amount of Lag in said Club? just as a note club is pretty much stripped of scripts so thats not the issue.

Thanks in advance for your suggestion

[Maitimo]

No, 25 guests closely packed together or the same 25 guests spread further apart won't make any difference, unless they are so far apart that they are outside of each others' draw distance. Clubs that are too big are annoying anyway, because if the dance floor is more than 20m across, you miss half the chat.

Does your club have neighbours? It might be scripts on other people's parcels. Clubs in skyboxes tend to be less laggy than ones at ground level, simply because there's less stuff nearby that has to be rendered, but even that won't help if your neighbours' scripts are hogging all the region's script time.

But the majority of the lag is the avatars themselves. 

[Lindal Kidd]

There is one special case where size affects performance.  Or, more precisely, where LOCATION affects performance.

Let's say a region can support 50 avatars, but it starts getting laggy at around 25.

If you put your club at the intersection of four such regions, each region is only supporting 1/4 (on average) of the club attendees.

This technique has occasionally been used to support large events with a large expected attendance.

[Orwar]

   It's not the amount of space, but the stuff and people in the space.

   Club-goers on average tend to wear a lot more scripts than they need to, and have little regard for avatar complexity and texture usage, especially since people (in certain types of venues more often than others) choose to just hide bits they aren't using and wear the HUD (as I wrote in the script statement of my sister's club: "Did you know that your genitalia can have more lag impact than your dance partner?").

   Likewise, a lot of furniture contains a disproportionate amount of scripts, textures and triangles to what they add to a place. Poorly optimized mesh with high-resolution textures for minute details (just the same as many clothes and accessories) all add to the performance of the people who have to load or cache it all just to see the club. A very popular furniture brand in SL has teacups with more than 16,000 KB of VRAM - to compare, the sofa that I have in my house has 4,200 KB (can't remember what the TMem looked like, but the teacup had 12 faces, my sofa has 2).

   If your venue is sharing region with another venue with a lot of script lag, there isn't all that much you can do about it (unless you're renting the land and the landlord has a policy on script limits). You may also be in close enough proximity of high-poly stuff that's heavy to render - reducing the draw distance so that your club is covered but that you have as little overlap as possible with neighbors' builds may help, but again, this is on the user's end. 

   There are a lot of things you can do to optimize your venue's performance, both by looking at the stuff you've put in it, and by asking your patrons and staff to be mindful of others (and themselves). If you have neighbors who cause a lot of lag, either approach them and see if anything can be done about it, or consider moving.

[Wulfie Reanimator]

Bit annoying when people keep saying just "lag"  without describing it when there are many kinds with totally unrelated causes.

Framerate? Reduce mesh/textures.

Unresponsive scripts? It's complicated.

Hard to move? Possibly physics / agent updates. 

And that's not all. 

[Arduenn Schwartzman]

Just these two things: 

1. Put more people in a smaller space and your framerate will drop.

2. Put more people in a Region and the lag will rise.

[Qie Niangao]

The problem with packing avatars close together is that more of them are in view -- not merely within draw distance but also in the fields of view as the avatars' cams are oriented. That's pretty much purely viewer-side, frames-per-second rendering lag.

In a crowded venue, scripts will definitely run slowly, and the more of them in the sim the more they'll slow each other down. But because it's crowded, there are other sim resources that will expand first, preventing all scripts from getting the normal amount of time. Put another way: script performance will get worse first, in order to make time for other, higher priority sim processes. That would happen even if there were no increase in the number of scripts.

[Lindal Kidd]

Down with clubs!  Up with beaches, parks, and forests!

[Janet Voxel]

Be up in da SL club movin like...

 

Edited February 3, 2020 by janetosilio

[Tolya Ugajin]

Indeed it does.  A larger club is much harder to swing around quickly, and the resulting lag makes it easier for your quarry to dodge the blow.  There will also be a lag any time you miss, as you will be thrown more off-balance with a bigger club than if you miss with a smaller club.  This is very much the same with all weapons - you can miss all day with a light and nimble blade such as a rapier and never be off balance, whereas a club will always take you those critical extra microseconds to recover.  This is why Club and Rapier Play (CaRP) sims are always dominated by rapiers.  However, a good solid club, if you connect, will do far more damage, even if your opponent manages to parry.  As Hercules once said, there's no more manly feeling than wrapping both your hands around your big, hard club and pounding away.

Hope this helps.

Edited February 3, 2020 by Tolya Ugajin

[Wulfie Reanimator]

42 minutes ago, Tolya Ugajin said:

Indeed it does.  A larger club is much harder to swing around quickly, and the resulting lag makes it easier for your quarry to dodge the blow.  There will also be a lag any time you miss, as you will be thrown more off-balance with a bigger club than if you miss with a smaller club.  This is very much the same with all weapons - you can miss all day with a light and nimble blade such as a rapier and never be off balance, whereas a club will always take you those critical extra microseconds to recover.  This is why Club and Rapier Play (CaRP) sims are always dominated by rapiers.  However, a good solid club, if you connect, will do far more damage, even if your opponent manages to parry.  As Hercules once said, there's no more manly feeling than wrapping both your hands around your big, hard club and pounding away.

Hope this helps.

I was so confused until the halfway point...

[Tolya Ugajin]

On 2/3/2020 at 2:56 PM, Wulfie Reanimator said:

I was so confused until the halfway point...

I must day I was sad nobody else laughed.

[Drayke Newall]

Technically if LL's 'fix' years ago worked (well was supposed to load things in front of the object first then behind others after) where things weren't rendered behind other objects, you could design a club so that line of sight would come in handy and block avatars or objects from rendering when you are in a booth or standing behind an object. Similar to occlusion planes in other game engines etc.

Unfortunately this "fix' did absolutely nothing and still renders everything in the view so such things are impossible. Why on earth LL haven't introduce occlusion planes or something similar to help is beyond me.

Edited February 5, 2020 by Drayke Newall

[Wulfie Reanimator]

1 hour ago, Drayke Newall said:

Technically if LL's 'fix' years ago worked (well was supposed to load things in front of the object first then behind others after) where things weren't rendered behind other objects, you could design a club so that line of sight would come in handy and block avatars or objects from rendering when you are in a booth or standing behind an object. Similar to occlusion planes in other game engines etc.

Unfortunately this "fix' did absolutely nothing and still renders everything in the view so such things are impossible. Why on earth LL haven't introduce occlusion planes or something similar to help is beyond me.

Occlusion exists in SL, you can even watch it via Developer > Render Metadata and you can read more about the specifics here. That page hasn't been updated since 2011 so it doesn't mention how mesh is handled. Do they occlude based on visible tris, bounding box, or what? It seems to be visible tris, at least partially, but I'm not 100%.

It's also easy to test. Go to mainland, max out your draw distance, and put your camera inside of a solid room with no gap or transparent window outside. Your FPS will increase significantly. For example, in a "busy" area I go from ~10 FPS to ~20 if I'm in a dubious mesh hut. About ~25 if I cover my camera with a prim cube.

[Drayke Newall]

4 hours ago, Wulfie Reanimator said:

Occlusion exists in SL, you can even watch it via Developer > Render Metadata and you can read more about the specifics here. That page hasn't been updated since 2011 so it doesn't mention how mesh is handled. Do they occlude based on visible tris, bounding box, or what? It seems to be visible tris, at least partially, but I'm not 100%.

It's also easy to test. Go to mainland, max out your draw distance, and put your camera inside of a solid room with no gap or transparent window outside. Your FPS will increase significantly. For example, in a "busy" area I go from ~10 FPS to ~20 if I'm in a dubious mesh hut. About ~25 if I cover my camera with a prim cube.

I know there is a system implemented and is why I mentioned it in my post. That said, it is no where near the capabilities it should be which is also why I said it doesn't work. Additionally as far as I was/am aware (which is also proved in the article you mention and I quote "Since the network load of a prim is much less than a texture, occlusion culling saves bandwidth by never requesting texture data for occluded objects.") it has always been textures that are occluded and not mesh objects. The system was first looked into when sculpts were all the rage and hence sculpts generally were occluded due to them being a texture file. That said they could have updated it to include objects, I'm not sure. The article also mentions and shows its limitations as far as terrain, water and sky goes (for example the water ALWAYS runs and is rendered under the terrain even if you cannot see it due to the terrain being over it).

Also, the very fact that the article mentions a transparent window being a problem and shouldn't be designed in a building is utter rubbish. The article even mentions games such as WoW etc doing as such, however this sort of occlusion system is hugely out dated as generally most games are developed with a combination of occlusion planes as well as bounding boxes and linked portals now which enable objects outside of the bounding box to not be rendered except through a portal which would be at a door or a window. Some even forgoing such things entirely with modern engines.

To throw back to Linden Lab their own statement in their article "I'd encourage any LL Employees to take a good look at how professional level designers layout environments in video games.". No game for many years probably post 2010 uses the system they describe COD 4 (a game from 2007) of using. If I look through a window I can see what's inside and outside complex or not in any modern game. Heck, even games pre 2007 (using fps's as the precedent set in the article) allowed this to happen including the original call of duty and battlefield 2 with battlefield BC extending this further with destructible buildings. Once again this goes to show how lax LL are at keeping their own system up to date and current. It was once again a half implemented system that has been forgotten about for over 10 years and never updated despite it potentially having a huge impact on performance. Not to mention is probably the reason why many textures (and possibly objects) bug out and don't load at the moment (shown in other threads) due to failed culling prioritisation.

The flaw in the system implemented by Linden Lab is the fact that their render engine and code system that implemented the basic occlusion system is a stop all (to some degree). This means that the system blocks all texture rendering (at first) irrespective of line of sight. This is why it doesn't fix issues as it doesn't allow the freedom of design of line of sight which, is a prime reason why occlusion planes should be implemented as a user implemented system. That is to say, click a button and allow the sim designer to place their own occlusion planes that block both textures and mesh objects where they want it to. The introduction of user placed bounding boxes and portals would also significantly improve performance as well as design as, then you can restrict floating objects as well the water under the terrain.

I will give you an example or two, if I have a rock or tree that is large enough to block objects behind, despite in most gaming environments, those objects would be rendered due to it being within the scene, the second life viewer doesn't render those as the system decides what is and isn't rendered. This means that if the client is rendering other areas and hogging the resources those objects wont render. Another example, suppose I have a very tight spaced timber slat screen that whilst having gaps aren't big enough to see through. LL's system will render anything behind that object due to having gaps in it, where as a user placed occlusion plan could be placed there instead to help performance.

Just because a system exists within second life doesn't mean its the same system that should have been implemented or updated to. 

To add to this further, and I'm not sure if this is the case or not but I was almost certain that the culling system was a prioritisation system whereby all objects in view render first and any blocked render after. This means that all textures are eventually rendered and are always rendered. If this is the case and my understanding is correct then that is vastly different to occlusion planes whereby the textures might be loaded and in the cache but the plane stops them from rendering within that space entirely.

Edited February 5, 2020 by Drayke Newall

[Scylla Rhiadra]

17 hours ago, Tolya Ugajin said:

I must day I was sad nobody else laughed.

I was too busy groaning.

[rasterscan]

On 2/3/2020 at 5:07 PM, Lindal Kidd said:

Down with clubs!  Up with beaches, parks, and forests!

Each to their own, Lindal, c'monnn   

[Kimmi Zehetbauer]

On 2/3/2020 at 12:12 PM, Tolya Ugajin said:

Indeed it does.  A larger club is much harder to swing around quickly, and the resulting lag makes it easier for your quarry to dodge the blow.  There will also be a lag any time you miss, as you will be thrown more off-balance with a bigger club than if you miss with a smaller club.  This is very much the same with all weapons - you can miss all day with a light and nimble blade such as a rapier and never be off balance, whereas a club will always take you those critical extra microseconds to recover.  This is why Club and Rapier Play (CaRP) sims are always dominated by rapiers.  However, a good solid club, if you connect, will do far more damage, even if your opponent manages to parry.  As Hercules once said, there's no more manly feeling than wrapping both your hands around your big, hard club and pounding away.

Hope this helps.

Why I had a smaller club. If someone released some gas --- the avis be flying out the door! 🤣

[ItHadToComeToThis]

Mid thread challenge :

Write a haiku about lag