Skip to content
This repository has been archived by the owner on Mar 28, 2024. It is now read-only.

[BUG-233438] Larger particle size limits #10534

Closed
sl-service-account opened this issue Feb 21, 2023 · 1 comment
Closed

[BUG-233438] Larger particle size limits #10534

sl-service-account opened this issue Feb 21, 2023 · 1 comment

Comments

@sl-service-account
Copy link

sl-service-account commented Feb 21, 2023

How would you like the feature to work?

A simple expansion of the maximum size of a particle produced by llParticleSystem and llLinkParticleSystem from 4m², to at least 10m².

Why is this feature important to you? How would it benefit the community?

With the expansion of prim size caps, link distance caps, and other things, the 4m² size cap of particles seems increasingly arbitrary. Worse, it hamstrings effects for larger projects, forcing the use of more particles to compensate for lack of volume, impacting the performance cost of those effects, while often making them look terrible anyway, due to the small constituent particle sizes in the smoke/fog/whatever giving it a blotchy or grainy appearance.

 

Larger particle sizes would allow creators to use less particles for any given effect, as lack of volume would no longer need to be compensated for by numbers of particles produced.  In addition, the visual effect of those particle effects would be better, as they could be made to scatter wider, while still maintaining overlap (such as in a smoke plume). 

 

Raising the maximum usable range for particle size in llParticleSystem and llLinkParticleSystem to at least 10m² will allow creators to produce better looking products that are, at the same time, more efficient with particles, and thereby less laggy.

Attachments

Original Jira Fields
Field Value
Issue BUG-233438
Summary Larger particle size limits
Type New Feature Request
Priority Unset
Status Closed
Resolution Unactionable
Reporter Iexo Bethune (iexo.bethune)
Created at 2023-02-21T18:43:17Z
Updated at 2023-02-22T19:48:20Z
{
  'Build Id': 'unset',
  'Business Unit': ['Platform'],
  'Date of First Response': '2023-02-22T13:48:20.025-0600',
  'How would you like the feature to work?': 'A simple expansion of the maximum size of a particle from 4m², to at least 10m².',
  'ReOpened Count': 0.0,
  'Severity': 'Unset',
  'Target Viewer Version': 'viewer-development',
  'Why is this feature important to you? How would it benefit the community?': 'With the expansion of prim size caps, link distance caps, and other things, the 4m² size cap of particles seems increasingly arbitrary.  Worse, it hamstrings effects for larger projects, forcing the use of more particles to compensate for lack of volume, impacting the performance cost of those effects, while often making them look terrible anyway, due to the small constituent particle sizes in the smoke/fog/whatever giving it a blotchy or grainy appearance.',
}
@sl-service-account
Copy link
Author

Kyle Linden commented at 2023-02-22T19:48:20Z

Hello, and thank you for your feature request.

Incoming suggestions are reviewed in the order they are received by a team of Lindens with diverse areas of expertise. We consider a number of factors: Is this change possible? Will it increase lag? Will it break existing content? Is it likely that the number of residents using this feature will justify the time to develop it? This wiki page further describes the reasoning we use: http://wiki.secondlife.com/wiki/Feature_Requests

This particular suggestion, unfortunately, cannot be tackled at this time. However, we regularly review previously deferred suggestions when circumstances change or resources become available.

We are grateful for the time you took to submit this feature request. We hope that you are not discouraged from submitting others in the future. Many excellent ideas to improve Second Life come from you, our residents. We can’t do it alone.

Thank you for your continued commitment to Second Life.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant