You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 28, 2024. It is now read-only.
Currently the presence of a script only adds 0.25 to server cost per link up to a maximum of 0.5 per link no matter how many additional scripts exist in the link.
This means if there are 2 or 500 scripts in a single link object it will still only cost 1 for land impact.
Since scripts are part of the server cost component, their cost is "lost" within a high prim count linkset or complex mesh linkset due to the generic max(server cost, physics cost, streaming cost) formula for land impact. This means that the resource impact on the actual server in these environments theoretically is not even counted.
For example, if an unscripted, complex mesh object or animesh object has a land impact of 150 mostly due to streaming cost being the dominant of the 3 components, even if you add scripts, there will be no increase in land impact even though you are actually adding resources that now affect the server.
Scripts need to be separated from server cost and have their own added(+) cost on TOP of this generic formula. Scripts need to have a more equal ratio of land impact versus count and/or memory.
We are at a point where script overload occurs in almost every sim grid-wide.
There has been discussion into possibly preventing idling scripts from using script time, but the problem with this is there is no way to know how critical the application is of an idling script. Delaying performance with idling script "startup" could hurt potential critical applications.
At a time when ArcTan will change land impact for content based on tri counts and texture memory, I feel this is the best time to also address the issue with scripts.
I propose the following "additional" land impact formula for scripts only:
Max(# of running scripts,RoundUp(total bytes of all running scripts / 65536))
This will be added on TOP of the generic server, physics, streaming cost calc.
This ensures that no matter how simple or complex the mesh/prim host is, that an actual resource cost to the server will not get lost among rendering costs or physics costs.
So with the above additional calc, here are some examples of how this will change some content:
A 1 land impact single prim box with 500 scripts will now have a land impact of 501.
A 17 land impact sculpty breedable with 8 scripts will now have a land impact of 25.
A 150 land impact Animesh object with 10 scripts will now have a land impact of 160.
A 1 land impact single prim box with 4 large scripts(256 KB each) will now have a land impact of 17.
A 1 land impact single prim box with 4 large scripts each using llSetMemoryLimit(131072); will now have a land impact of 9.
A 1 land impact single prim box with 2 LSO scripts & 1 mono script will now have a land impact of 4.
Other Information
Please accept this Jira at least to have material to discuss amongst yourselves and with the community. If this is acceptable, please set to Needs More Info so it can be continually discussed here. Thanks.
Original Jira Fields
Field
Value
Issue
BUG-227584
Summary
[ArcTan] Scripts need a new formula for land impact.
Type
New Feature Request
Priority
Unset
Status
Needs More Info
Resolution
Unresolved
Reporter
Lucia Nightfire (lucia.nightfire)
Created at
2019-09-04T10:13:31Z
Updated at
2019-09-05T15:43:53Z
{
'Build Id': 'unset',
'Business Unit': ['Platform'],
'Date of First Response': '2019-09-04T14:20:33.985-0500',
'How would you like the feature to work?': 'Currently the presence of a script only adds 0.25 to server cost per link up to a maximum of 0.5 per link no matter how many additional scripts exist in the link.\r\n\r\nThis means if there are 2 or 500 scripts in a single link object it will still only cost 1 for land impact.\r\n\r\nSince scripts are part of the server cost component, their cost is "lost" within a high prim count linkset or complex mesh linkset due to the generic max(server cost, physics cost, streaming cost) formula for land impact. This means that the resource impact on the actual server in these environments theoretically does not even exist.\r\n\r\nFor example, if an unscripted, complex mesh object or animesh object has a land impact of 150 mostly due to streaming cost being the dominant of the 3 categories, even if you add scripts, there will be no increase in land impact even though you are actually adding resources that now affect the server.\r\n\r\nScripts need to be separated from server cost and have their own added(+) cost on TOP of this generic formula. Scripts need to have a more equal ratio of land impact versus count and/or memory.\r\n\r\nWe are at a point where script overload occurs in almost every sim grid-wide.\r\n\r\nThere has been discussion into possibly preventing idling scripts from using script time, but the problem with this is there is no way to know how critical the application is of an idling script. Delaying performance with idling script "startup" could hurt potential critical applications.\r\n\r\nAt a time when ArcTan will change land impact for content based on tri counts and texture memory, I feel this is the best time to also address the issue with scripts.\r\n\r\nI propose the following "additional" land impact formula for scripts only:\r\n\r\nMax(# of running scripts,RoundUp(total bytes of all running scripts / 65536))\r\n\r\nThis will be added on TOP of the generic server, physics, streaming cost calc.\r\n\r\nThis ensures that no matter how simple or complex the mesh/prim host is, that an actual resource cost to the server will not get lost among rendering costs or physics costs.\r\n\r\nSo with the above additional calc, here are some examples of how this will change some content:\r\n\r\n- A 1 land impact single prim box with 500 scripts will now have a land impact of 501.\r\n- A 17 land impact sculpty breedable with 8 scripts will now have a land impact of 25.\r\n- A 150 land impact Animesh object with 10 scripts will now have a land impact of 160.\r\n- A 1 land impact single prim box with 4 large scripts(256 KB each) will now have a land impact of 17.\r\n- A 1 land impact single prim box with 2 mono scripts each using llSetMemoryLimit(32768); will now have a land impact of 2.',
'Original Reporter': 'Lucia Nightfire (lucia.nightfire)',
'ReOpened Count': 0.0,
'Severity': 'Unset',
'Target Viewer Version': 'viewer-development',
'Why is this feature important to you? How would it benefit the community?': '?',
}
The text was updated successfully, but these errors were encountered:
Information
Currently the presence of a script only adds 0.25 to server cost per link up to a maximum of 0.5 per link no matter how many additional scripts exist in the link.
This means if there are 2 or 500 scripts in a single link object it will still only cost 1 for land impact.
Since scripts are part of the server cost component, their cost is "lost" within a high prim count linkset or complex mesh linkset due to the generic max(server cost, physics cost, streaming cost) formula for land impact. This means that the resource impact on the actual server in these environments theoretically is not even counted.
For example, if an unscripted, complex mesh object or animesh object has a land impact of 150 mostly due to streaming cost being the dominant of the 3 components, even if you add scripts, there will be no increase in land impact even though you are actually adding resources that now affect the server.
Scripts need to be separated from server cost and have their own added(+) cost on TOP of this generic formula. Scripts need to have a more equal ratio of land impact versus count and/or memory.
We are at a point where script overload occurs in almost every sim grid-wide.
There has been discussion into possibly preventing idling scripts from using script time, but the problem with this is there is no way to know how critical the application is of an idling script. Delaying performance with idling script "startup" could hurt potential critical applications.
At a time when ArcTan will change land impact for content based on tri counts and texture memory, I feel this is the best time to also address the issue with scripts.
I propose the following "additional" land impact formula for scripts only:
Max(# of running scripts,RoundUp(total bytes of all running scripts / 65536))
This will be added on TOP of the generic server, physics, streaming cost calc.
This ensures that no matter how simple or complex the mesh/prim host is, that an actual resource cost to the server will not get lost among rendering costs or physics costs.
So with the above additional calc, here are some examples of how this will change some content:
A 1 land impact single prim box with 500 scripts will now have a land impact of 501.
A 17 land impact sculpty breedable with 8 scripts will now have a land impact of 25.
A 150 land impact Animesh object with 10 scripts will now have a land impact of 160.
A 1 land impact single prim box with 4 large scripts(256 KB each) will now have a land impact of 17.
A 1 land impact single prim box with 4 large scripts each using llSetMemoryLimit(131072); will now have a land impact of 9.
A 1 land impact single prim box with 2 LSO scripts & 1 mono script will now have a land impact of 4.
Other Information
Please accept this Jira at least to have material to discuss amongst yourselves and with the community. If this is acceptable, please set to Needs More Info so it can be continually discussed here. Thanks.
Original Jira Fields
The text was updated successfully, but these errors were encountered: