a sims spare script time

[tabletopfreak Toocool]

so i have a goal of getting my spare script time to 2 or more ms.. its to help people help people with old hardware better enjoy my sim, i myself have a beast of s pc and run great any place with advanced lights i have a1080, i7 8700 (the new one), my rl husband has a 970 (end of 2014) and an i5-6500 (end of 2015) and he runs great as well with advanced lights 

iv been to an rp sim that has 4-6ms of spare script time even with 10-15 people on sim. i would ask him but with the ever shrinking pools of active users that is sl drying up ever steadily .. sim owners seem to guard their secrets even closer these days.. and who could blame them..i haven't asked hims as i dont want to get banned 

and in case you seen my other post my trees take up like 0.001 ms each i have about 50 of them.. i would need 100s for them to even be slightly considered laggy together they take up less ms then a  very basically dressed mesh avi with no huds and an ao..

would be more then happy to tip someone who hits me up and comes to my land for a walk through and help me reach this goal

my top scripters via debug menu are https://gyazo.com/d444312f629780a84a86c70d1c3bad5b

then its this https://gyazo.com/b550918826729dac544585fa5ff6d6bd

then   https://gyazo.com/4a11547a6e8b80d97fcfbc72cb346ac8

 

when i kill scrips my spare time goes up to 18

be removing scripts all day from items and not seeing my spare ms go up much at all

also reading that the land tool are rather use less  and not good representations of real script use so something that is laggy might be at the bottom of the list so some reason 

again.. i dont lag.. but i know alot of people are are 5 year old laptops that were never designed to play sl in the 1st place .. so iv been using smaller textures (most things on my land have custom textures i made) im just trying to do my part in sl by making it more accessible  to a wider rang of hardware..just need some help with the scripts as it seems no so cut and dry as with the textures 

[tabletopfreak Toocool]

well.. i guess nvm i did something and now my spare time is 5-7ms 

[Qie Niangao]

It's a great idea to have non-zero Spare Time as headroom for added scripts, especially including scripts attached to visiting avatars. When Spare Time falls to zero, scripts will start to slow down other scripts, and this can become quite noticeable to users operating HUDs, for example, or expecting smooth performance from any other scripts.

But all that has (nearly) nothing to do with viewer-side hardware, because scripts run on the sim, not in the viewer. It's a whole different kind of lag that arises from underperforming PCs, graphics cards, etc.

(Just in passing, the whole concept of "Spare Time" depends on a fixed-length "frame" which is how the simulation works, but not the viewer, where instead "Frames Per Second" can increase arbitrarily -- even faster than the graphics refresh rate -- not waiting on any fixed interval as does the simulation.)

So if folks with less performant hardware, specifically, are finding your sim challenging, you need to look elsewhere, and there aren't a lot of tools to make that easy. There are some consoles that may be useful (e.g., Develop / Show Info / Show Render Info) as you pan around the sim, but mostly it's a matter of looking for likely culprits: lots of blended alpha textures (some trees are very bad at that) and stuff with ridiculously complex meshes (high density when viewed in wireframe, toggled with Ctrl-Shift-R). 

If Crescent Springs is the region in question (guessing from Profile), one thing that will definitely lag newcomers (even with fairly good machines) is the sim-surround. You may want to keep it anyway, but it really (really) slows down the initial loading, and continues to affect rendering performance as long as it's within draw distance (which is pretty much always). In terms of network-affecting object updates (toggle Ctrl-Alt-Shift-U) the Jian Flamingos are the heavy-hitters, but even strictly viewer-side effects such as large-scale texture animation (prim water, waterfalls, the "flap-flying" birds), and smooth rotation (e.g., koi) have some effect on rendering performance -- but it's always a trade-off of visual interest vs rendering performance. Which is to say "there's no such thing as a free lunch" I guess.

[tabletopfreak Toocool]

33 minutes ago, Qie Niangao said:

It's a great idea to have non-zero Spare Time as headroom for added scripts, especially including scripts attached to visiting avatars. When Spare Time falls to zero, scripts will start to slow down other scripts, and this can become quite noticeable to users operating HUDs, for example, or expecting smooth performance from any other scripts.

But all that has (nearly) nothing to do with viewer-side hardware, because scripts run on the sim, not in the viewer. It's a whole different kind of lag that arises from underperforming PCs, graphics cards, etc.

(Just in passing, the whole concept of "Spare Time" depends on a fixed-length "frame" which is how the simulation works, but not the viewer, where instead "Frames Per Second" can increase arbitrarily -- even faster than the graphics refresh rate -- not waiting on any fixed interval as does the simulation.)

So if folks with less performant hardware, specifically, are finding your sim challenging, you need to look elsewhere, and there aren't a lot of tools to make that easy. There are some consoles that may be useful (e.g., Develop / Show Info / Show Render Info) as you pan around the sim, but mostly it's a matter of looking for likely culprits: lots of blended alpha textures (some trees are very bad at that) and stuff with ridiculously complex meshes (high density when viewed in wireframe, toggled with Ctrl-Shift-R). 

If Crescent Springs is the region in question (guessing from Profile), one thing that will definitely lag newcomers (even with fairly good machines) is the sim-surround. You may want to keep it anyway, but it really (really) slows down the initial loading, and continues to affect rendering performance as long as it's within draw distance (which is pretty much always). In terms of network-affecting object updates (toggle Ctrl-Alt-Shift-U) the Jian Flamingos are the heavy-hitters, but even strictly viewer-side effects such as large-scale texture animation (prim water, waterfalls, the "flap-flying" birds), and smooth rotation (e.g., koi) have some effect on rendering performance -- but it's always a trade-off of visual interest vs rendering performance. Which is to say "there's no such thing as a free lunch" I guess.

thanks for taking a look.. my trees are all alpha masking not sure if that is better or worse .. anytime i can use masking (which is most the time)  i due know in rare cases some people with really low settings will see alpha mask textures as having no mask cut off.. as to say with normally black where the clear should be  but iv only heard of that 2 times (once on my sim, ones els ware a while ago) so im guessing that 90% of people dont have that issue .. yeah sim surround is a must for me .. about the rotating objects does removing the scripts help ? cuzz they keep moving even with no script ..  you say the flamingos hit the network does that mean like people with slower connection speeds will be more effected ? is this my "net time"? that this would reflect in? not sure what all hits network but id ill use ctrl-alt-shift-u and see what i can remove or.. descript? to make up for the flamingos which as you might have seen are outstanding in their animation .. im im guessing youve looked at my statics bars? what values would you suggest i work on lowering 

[tabletopfreak Toocool]

 Ctrl-Alt-Shift-U , whats the red mean ? is that my sim surround ?

[tabletopfreak Toocool]

12 minutes ago, tabletopfreak Toocool said:

 Ctrl-Alt-Shift-U , whats the red mean ? is that my sim surround ?

i took up the sim surround just for testing 

still getting a hot spot here and there are no clear prim 

https://gyazo.com/95295c7e904a7269ecaf40e2eb06f733

 

[Qie Niangao]

Right, you can ignore those red squares; they simply mean that an object is rezzing into view (here for more details). That's a big deal only if the object is really rezzing in the sim, over and over again, such as temp-rezzed objects (which even then would only much matter if scripted), otherwise they just appear when cam movement causes the viewer to rez objects that have been in the sim all along.

The flow of object updates is one source of network traffic from the sim, but not the only one, and the whole SL architecture depends on some content streaming from sim to viewer (so some Network Time is inevitable).

I honestly didn't see anything obviously wrong in the brief time I was there -- and really nothing at all adversely affecting sim-side performance inasmuch as you even have some Spare Time. (And to the object update thing: the flamingos seemed fine to me, I mentioned them because they were the only things I saw sending many object updates at all.)

Yes, it's fine to remove scripts such as constant texture animation and smooth rotation because those are prim properties, set-and-forget (unless they vary over time or can be toggled on/off or something) -- but those properties aren't propagated to shift-drag copies. This isn't going to make a huge difference, though, even if the sim is script-bound, because such scripts don't process any events except when started or reset. (Technically, they still take up a tiny bit of memory and occupy a scheduler slot, but will almost never be noticed in practice.)

So I guess I wonder: are you really getting complaints from folks with lesser machines? I mean, mine is old and not that fast by current standards, and the only thing I noticed that really slowed me down was the sim surround (and I certainly understand that it's kind of necessary for the intended scene).

Other folks are way fussier about rendering lag, though, so maybe they'll take a look and weigh in with more useful suggestions.

[tabletopfreak Toocool]

36 minutes ago, Qie Niangao said:

Right, you can ignore those red squares; they simply mean that an object is rezzing into view (here for more details). That's a big deal only if the object is really rezzing in the sim, over and over again, such as temp-rezzed objects (which even then would only much matter if scripted), otherwise they just appear when cam movement causes the viewer to rez objects that have been in the sim all along.

The flow of object updates is one source of network traffic from the sim, but not the only one, and the whole SL architecture depends on some content streaming from sim to viewer (so some Network Time is inevitable).

I honestly didn't see anything obviously wrong in the brief time I was there -- and really nothing at all adversely affecting sim-side performance inasmuch as you even have some Spare Time. (And to the object update thing: the flamingos seemed fine to me, I mentioned them because they were the only things I saw sending many object updates at all.)

Yes, it's fine to remove scripts such as constant texture animation and smooth rotation because those are prim properties, set-and-forget (unless they vary over time or can be toggled on/off or something) -- but those properties aren't propagated to shift-drag copies. This isn't going to make a huge difference, though, even if the sim is script-bound, because such scripts don't process any events except when started or reset. (Technically, they still take up a tiny bit of memory and occupy a scheduler slot, but will almost never be noticed in practice.)

So I guess I wonder: are you really getting complaints from folks with lesser machines? I mean, mine is old and not that fast by current standards, and the only thing I noticed that really slowed me down was the sim surround (and I certainly understand that it's kind of necessary for the intended scene).

Other folks are way fussier about rendering lag, though, so maybe they'll take a look and weigh in with more useful suggestions.

so i just did a restart cuzz i removed my surround just for kicks to see what difference it made and now my spare time is less then 1ms.. when i was just getting 5-6 even 8 at times as it goes up and down... so what gives?? i know its not the sim surround not being there thats just why i did a restart to get the full effects of it being gone .. do our sims move each time we restart them and im not a server with a resource hog?

[Klytyna]

6 hours ago, tabletopfreak Toocool said:

so i have a goal of getting my spare script time to 2 or more ms.. its to help people help people with old hardware better enjoy my sim

Scripts are all run  server side, so a generous script spare time, won't do SQUAT for clients running on older pc's.

6 hours ago, tabletopfreak Toocool said:

in case you seen my other post my trees take up like 0.001 ms each i have about 50 of them.. i would need 100s for them to even be slightly considered laggy

Frakly, as far as de-lagging a sim for older hardware users was concerned, I'd be looking at removing as much alpha blend from the sim as I could, and unfortunately most trees and foliage/ground cover are still churned out with alpha blend all over the damn place, edit the greenery and switch as much as possible to alpha mask with a suitable cutoff level, 50-75 works well for most trees/bushes etc. Remove those grass mat things if you have any, they suck for gpu lag on older hardware.

1 hour ago, tabletopfreak Toocool said:

my trees are all alpha masking not sure if that is better or worse .. anytime i can use masking (which is most the time)

Good to know.

Classic "lag hits" on sims are alpha blend, excess physics time. prim critters wandering about, badly optimised pathfinding and pathfinding critters especially, physical set objects like vehicles, even physical projectiles in large numbers, discourage the use of ultra rpm miniguns and "anti projectile laser shields" for example.

Persistent temp re-rezzers also pretty much suck, they can cripple ther sims framerate if over used, seen a cloud of 'fireflies' that caused a 60% drop in sim fps rate every 30 seconds like a laggy heartbeat.

 

[tabletopfreak Toocool]

8 minutes ago, Klytyna said:

Scripts are all run  server side, so a generous script spare time, won't do SQUAT for clients running on older pc's.

well if nothing els it leaves head room for renters items and for times that 20 or more people are on the sim as they all have there own huds on even when they dont need them all the time but just leave them out of habit or not knowing better 

[Dean Haystack]

On 14/05/2018 at 7:10 AM, tabletopfreak Toocool said:

(...)its to help people help people with old hardware better enjoy my sim, i myself have a beast of s pc (...)

Scripts run on LL servers, they have nothing to do with personal machines people use to run SL, like someone else said..
What people loosely label as "lag" in SL is actually low frame rate, a person gets low frame rate when their machine doesn't have enough processing power to handle the geometry, or even more often than that, doesn't have enough memory for the silly amount of huge textures every creator put in the tinniest of stuff to label them as "high quality."

If you wanna improve the frame rate in your sim, hunt down high memory objects, the other day I saw some stairs that took 160MB of VRAM...

[tabletopfreak Toocool]

17 minutes ago, Dean Haystack said:

Scripts run on LL servers, they have nothing to do with personal machines people use to run SL, like someone else said..
What people loosely label as "lag" in SL is actually low frame rate, a person gets low frame rate when their machine doesn't have enough processing power to handle the geometry, or even more often than that, doesn't have enough memory for the silly amount of huge textures every creator put in the tinniest of stuff to label them as "high quality."

If you wanna improve the frame rate in your sim, hunt down high memory objects, the other day I saw some stairs that took 160MB of VRAM...

ok iv been working on resizing textures , is there a way to show how much memory something uses ? im guessing some ware in the advanced or in the dev tools/

[Coffee Pancake]

2 hours ago, Dean Haystack said:

Scripts run on LL servers, they have nothing to do with personal machines people use to run SL, like someone else said..
What people loosely label as "lag" in SL is actually low frame rate, a person gets low frame rate when their machine doesn't have enough processing power to handle the geometry, or even more often than that, doesn't have enough memory for the silly amount of huge textures every creator put in the tinniest of stuff to label them as "high quality."

If you wanna improve the frame rate in your sim, hunt down high memory objects, the other day I saw some stairs that took 160MB of VRAM...

First up, lag is not poor client-side frame rate. Lag is almost always caused by a regions inability to track and send object/avatar updates in a timely manner, this may be caused by time dilation on an overloaded region,  more often than not, it's bottle-necked UDP traffic (and the bottle neck is typically at the clients end).

As far as hunting VRAM heavy objects goes .. if you are even equipped to do such a thing, keep in mind that mesh geometry also occupys VRAM. So your avatar, all that decorative gatcha tat ... Meshes are supposed to drop down to lower LOD models .. but that doesn't work so well when you crank the LOD factor in the viewer though the roof so poorly made objects don't fall apart when you're "arbitrary distance" from them.

Textures in SL are streamed to the client in increasingly higher resolutions. the resolution rendered on screen is in part dependent on how much screen real estate the object occupies. If you have spare VRAM then the viewer will try to keep it full. You see this in action when the viewer swaps textures out, it's doesn't always pick the best texture to derez, swaps out something like the floor that then get puts right back because it's occupying a lot of screen space.

--

if you want to improve the frame rate & user experience on your region, open the linden viewer, set the LOD to medium and adjust your build so that object deconstruction is taken into account - ie, no long views from one side of the region to another, small contained spaces, lots of occlusion. This is the most basic kind of optimization.

Three words - Visible Object Density.

Think of your build as a series of "scenes", keep each one limited to content needed for that scene, and build your scenes far apart.

Spread your build out by putting interior spaces into dedicated skyboxes and using experience tools to port people about when they pass though doorways - Try to keep the loaded scene limited to the scene at hand - if you're in room, does a viewer really need to care about the trees outside? No .. then don't build your room near to the tree, or near to those other 4 rooms the user can't see.

It's not the experience we are used to in SL where the world is a contiguous space, but this building practice alone is responsible for most performance woes.

 

 

[tabletopfreak Toocool]

On 5/17/2018 at 10:11 AM, CoffeeDujour said:

First up, lag is not poor client-side frame rate. Lag is almost always caused by a regions inability to track and send object/avatar updates in a timely manner, this may be caused by time dilation on an overloaded region,  more often than not, it's bottle-necked UDP traffic (and the bottle neck is typically at the clients end).

As far as hunting VRAM heavy objects goes .. if you are even equipped to do such a thing, keep in mind that mesh geometry also occupys VRAM. So your avatar, all that decorative gatcha tat ... Meshes are supposed to drop down to lower LOD models .. but that doesn't work so well when you crank the LOD factor in the viewer though the roof so poorly made objects don't fall apart when you're "arbitrary distance" from them.

Textures in SL are streamed to the client in increasingly higher resolutions. the resolution rendered on screen is in part dependent on how much screen real estate the object occupies. If you have spare VRAM then the viewer will try to keep it full. You see this in action when the viewer swaps textures out, it's doesn't always pick the best texture to derez, swaps out something like the floor that then get puts right back because it's occupying a lot of screen space.

--

if you want to improve the frame rate & user experience on your region, open the linden viewer, set the LOD to medium and adjust your build so that object deconstruction is taken into account - ie, no long views from one side of the region to another, small contained spaces, lots of occlusion. This is the most basic kind of optimization.

Three words - Visible Object Density.

Think of your build as a series of "scenes", keep each one limited to content needed for that scene, and build your scenes far apart.

Spread your build out by putting interior spaces into dedicated skyboxes and using experience tools to port people about when they pass though doorways - Try to keep the loaded scene limited to the scene at hand - if you're in room, does a viewer really need to care about the trees outside? No .. then don't build your room near to the tree, or near to those other 4 rooms the user can't see.

It's not the experience we are used to in SL where the world is a contiguous space, but this building practice alone is responsible for most performance woes.

 

 

thanks iv taken your advice and moved the dance club, strip club (was a "problem area of some") the smoke shop and hair salon up to the skin you simply click the door to to to them.. and in those sky boxes my frames are 80-150 .. over kill i know but it used to be 45s-60s at best.. so clearly this has basically doubled the frames witch will be a great help to people who before where in the teens and even some under 10.. i was trying to hunt down vram heavy items and i found one.. but the others on the top list i could not find in area search even if i got close to them.. and the vram  list for what ever reason doesn't let you tp, zoom or select the item.. i guess its showing my object names and not link set names so sometimes the object that is high vram is part of a link set of a different name.. suggestions ?