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

[BUG-230551] [Rendering] Add some way to strip an object face from rendering completely. #8203

Open
sl-service-account opened this issue Apr 11, 2021 · 10 comments
Open

[BUG-230551] [Rendering] Add some way to strip an object face from rendering completely. #8203

sl-service-account opened this issue Apr 11, 2021 · 10 comments
Labels
project:BUG

Comments

@sl-service-account
Copy link

How would you like the feature to work?

I'm not entirely sure but here are some approaches:

Option A: Add a new default texture ( TEXTURE_STRIP for example ).
Option B: Allow to set the alpha value of a face to a value superior to 100%.
Option C: Add a new parameter to PRIM_ALPHA_MODE: PRIM_ALPHA_MODE_STRIP

The idea is to allow builders, (but mainly scripters) to completely exclude a given face of an object from rendering, not just make it invisible, but also exclude it from touch raycast selection, and more importantly, from transform operations (especially on avatars).

These would remain visible when "highlight transparency" is on, maybe in their own unique color?

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

It is common for scripted objects in SL to have "hidden" parts, accessories, hidden "slices" on mesh bodies.

For a lot of those being clickable, or even having them go anywhere near being rendered is just a waste of resources (why have hidden options of your mesh body render at all when you don't use them? and unfortunately it is rare that those bodies allow modding)

It would be a bad idea to use this in place of 100% alpha because a lot of hidden objects still require clicking, but having a specific option to explicitely mark a prim/mesh face as "do not render this" would be immensely useful for content optimization.

Original Jira Fields
Field Value
Issue BUG-230551
Summary [Rendering] Add some way to strip an object face from rendering completely.
Type New Feature Request
Priority Unset
Status Accepted
Resolution Accepted
Reporter Kyrah Abattoir (kyrah.abattoir)
Created at 2021-04-11T08:22:11Z
Updated at 2021-04-21T17:48:51Z 
{
  'Build Id': 'unset',
  'Business Unit': ['Platform'],
  'Date of First Response': '2021-04-14T12:54:12.326-0500',
  'How would you like the feature to work?': 'I\'m not entirely sure but here are some approaches:\r\n\r\nOption A: Add a new default texture ( TEXTURE_STRIP for example ).\r\nOption B: Allow to set the alpha value of a face to a value superior to 100%.\r\nOption C: Add a new parameter to PRIM_ALPHA_MODE: PRIM_ALPHA_MODE_STRIP\r\n\r\nThe idea is to allow builders, (but mainly scripters) to completely exclude a given face of an object from rendering, not just make it invisible, but also exclude it from touch raycast selection, and more importantly, from transform operations (especially on avatars).\r\n\r\nThese would remain visible when "highlight transparency" is on, maybe in their own unique color?',
  'Original Reporter': 'Kyrah Abattoir (kyrah.abattoir)',
  'ReOpened Count': 0.0,
  'Severity': 'Unset',
  'Target Viewer Version': 'viewer-development',
  'Why is this feature important to you? How would it benefit the community?': 'It is common for scripted objects in SL to have "hidden" parts, accessories, hidden "slices" on mesh bodies.\r\n\r\nFor a lot of those being clickable, or even having them go anywhere near being rendered is just a waste of resources (why have hidden options of your mesh body render at all when you don\'t use them? and unfortunately it is rare that those bodies allow modding)\r\n\r\nIt would be a bad idea to use this in place of 100% alpha because a lot of hidden objects still require clicking, but having a specific option to explicitely mark a prim/mesh face as "do not render this" would be immensely useful for content optimization.',
}
@sl-service-account
Copy link
Author

Vir Linden commented at 2021-04-14T17:54:12Z

We do already have a built-in texture called IMG_INVISIBLE. If a face is set to use that texture, it will be skipped very efficiently. What if we had a texture like SUPER_INVISIBLE which also causes clicks to be disabled? Would that address what you are shooting for?

@sl-service-account
Copy link
Author

Vir Linden commented at 2021-04-14T17:54:40Z

I'm not saying the name would really be SUPER_INVISIBLE, by the way :-)

@sl-service-account
Copy link
Author

Kyrah Abattoir commented at 2021-04-15T08:39:22Z

Wait when was IMG_INVISIBLE added? the only mention of it that i found is from a kokua comment:

const LLUUID IMG_INVISIBLE ("3a367d1c-bef1-6d43-7595-e88c1e3aadb3");

It's also not recognized as a script constant or anywhere in the build tools.

 

"SUPER_INVISIBLE" (working title) would probably do the job, but most creators tend to only change the alpha value of an object, so that they don't have to touch any other visual parameter, which could have been adjusted by the owner of the object.

@sl-service-account
Copy link
Author

Vir Linden commented at 2021-04-15T13:22:18Z

IMG_INVISIBLE was added at the same time as we added alpha and tattoo wearables - maybe around 2011? If you set part of an alpha wearable to fully invisible via the checkbox, IMG_INVISIBLE is the UUID that gets used. I'm not sure if it's exposed as an LSL constant anywhere.

@sl-service-account
Copy link
Author

Kyrah Abattoir commented at 2021-04-15T17:34:09Z

Yeah I just tested it but on regular object it does "appear" to behave as just another alpha texture, I did see the specific checks related to it in the viewer sourcecode, but is it actually implement for prims and mesh objects too? Or just system avatars at the present time?

@sl-service-account
Copy link
Author

Vir Linden commented at 2021-04-15T19:53:11Z

I believe it should successfully make a face invisible with any prim, including meshes and avatars. Whether it's doing efficient skipping in all those cases would require some code review.

@sl-service-account
Copy link
Author

Kyrah Abattoir commented at 2021-04-16T11:18:28Z

Well yeah it is a 100% alpha texture, but it appears to react normally when you set alpha mode, so I'd be tempted to say its "special" properties aren't applied on regular objects.

If this could be implemented, along with "super invisible" (in addition to having them as script constants and exposed on the viewer texture UI and have a special color in highlight transparent to avoid confusions) it would be a great addition, there are quite a fews applications i can think of.

Scripted attachment touch zones (currently uses alpha blending, as alpha masks can't be clicked reliably)

SLRR Rail guides (can be alpha masked, but there is no real reason for them to be rendered at all, or clickable)

Volume detects (can be alpha masked too, but has no actual need for rendering, doesn't usually need to be clicked either)

Hidden prim faces It's not much but on an entire build, it can be substancial rendering wise.

@sl-service-account
Copy link
Author

Vir Linden commented at 2021-04-16T13:16:57Z

I'm not sure what you mean by reacting normally when you set alpha mode. What is it doing now and what would you want it to be doing?

@sl-service-account
Copy link
Author

Kyrah Abattoir commented at 2021-04-17T13:16:20Z

On prims and meshs it behave like a regular alpha texture when you change the alpha settings (no alpha/masked alpha) unless that is intentional it doesn't look like it is doing any stripping on regular objects?

I'm not even sure how to check that these faces are indeed being rendered or not.

@sl-service-account
Copy link
Author

Vir Linden commented at 2021-04-21T17:48:51Z

This seems like a potentially useful and not too complex feature. Specifically the proposal would be:

  • Make sure IMG_INVISIBLE optimizes graphics wherever practical
  • Add a new magic ID like IMG_INVISIBLE but that also sets the object to no click
  • Add both these IDs to LSL when setting textures there

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
project:BUG
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@sl-service-account