"Shininess" suggestions from a shiny car builder

Shininess is great, even though half the time I have to remind people to turn it on (it's just not that big a deal performance-wise). Or I'll get an IM from someone who bought one of my cars weeks ago, telling me they just turned shiny on, and WOW! Anyway, I could turn this into a bender rant about how no two clients see the same thing, but I won't.

Here's two suggestions I have about shiny objects:

1. Allow separate gain control of the main texture layer and the shiny layer. Right now, if you set a surface to "medium" shininess, you only get about 50% of the usual contrast range you could get with that surface. This means your colors are forced to be dark. Yellows end up being brownish. More importantly, high-contrast details on textures end up barely showing up.

So instead of just "None/Low/Medium/High", I think it should be "Main layer RGB" and "Shiny layer RGB". This would be backwards compatible for scripts: Shininess "none" is the same as "main 255,255,255 / shiny 0,0,0", shininess "medium" is the same as "main 128,128,128 / shiny 128,128,128", etc.

This would effectively solve the problem of texture contrast. Having R,G,B independently scalable would also allow us to approximate effects such as pearlescent paint.

2. Allow shininess on transparent surfaces. This should be available in two different modes:

- Alpha blended (as usual), shiny layer appears over both solid and transparent areas
- Alpha tested, shiny layer appears only on solid areas, but partial transparency is no longer possible

The first mode would allow shininess on textured car windows; the second mode would allow shininess on cars that use textures for body shape (such as SteveR Whiplash's Thunderbird, or any of Neo Virgo's). The latter is much more exciting, since it offers countless ways to visually cheat the 31-prim limit.

Of course, ideally, we'd be able to specify our own attenuation, normal, and specular maps for each surface, but I thought I'd propose something simpler.

You gave Torley Sr. good advice early on regarding some of what you just posted and about textures with an alpha channel (transparencies), and I thankya for that.

That reminds me... alpha testing by itself would be a pretty useful feature, if it meant transparent textures (of the all-or-nothing variety) could be properly sorted on the Z buffer.

I wanted to make the same suggestion myself re: shininess on 32-bit textures. I wouldn't mind it forcing the alpha to be either 1 or 0.

Endorsed. Anything for cooler shininess would rock. Transparent shiny objects would be awsome as well.

I was surprised to find no proposal for this feature request, so I went ahead and created one (actually, I just proposed transparent shiny to keep it simple for now): http://secondlife.com/vote/index.php?get_id=1115

Can't believe we STILL don't have this.

Ya know, I've never ever turned on Shiny because my first week someone told me how horridly slow it makes SL...as well as Local Lighting. I was never brave enough to try it out. Are these options still lag makers?

shiny does eat alittle bit of system performance, most of the time its so little you cant tell

local lighting is still SLOOOOOOOOW

I have never seen any noticable lag effect with shininess turned on. Local lighting, on the other hand, causes major lagging on the same machine when turned on.

Well this is good to know, I shall try the Shiny later in world. Thanks!

Also, many, many objects depend on shininess to look good. It's the difference between a matte gray color on an outfit and a nice shiny one. Personally, I find that the performance hit is negligible, and I like building with shiny, so I leave it on.

Local lighting, on the other hand, has very little use-- it slows down or crashes the client, and is too unresponsive to contribute to visual quality.

Too bad shiny's so overused I turn it off... because so much stuff looks better without shiny than with.

What I'd like is to have the shiny levels nerfed:

* slight shiny
* low shiny
* medium shiny (current low shiny)
* high shiny
* super shiny (current medium shiny)
* turbo shiny
* mega shiny (current high shiny)
* insanely shiny

That is, anything currently "low shiny" would be set to about 2/3 of current "low shiny".

Anything currently "medium shiny" would be set to "low shiny"

Anything currently "high shiny" would be midway between current "low" and "medium".

Any levels above "super shiny" would requite a L$10 fee.

The object editor would allow changing the "shiny levels" even for no mod objects, so if someone had a high shiny object they really wanted to remain high shiny, they could do it.

Wait, we're going to be charged for getting the full range out of the object editor? This is absurd. Sure, shiny has some problems, but that doesn't mean it should become a new sink for L$. Editing prims doesn't cost anything, editing color doesn't cost anything, and neither should shiny. Texturing makes sense, because you don't usually need to use a bunch of different textures, but still-- that's a one-time fee.

You already are, unless you have some sekrit scheme for uploading textures without paying.

OK, OK, that bit's not serious. Really, you wouldn't be able to set objects to higher levels of shiny without passing a mini-quiz on optics!

Actually, I'd almost support that. It reminds me of another game I play, a satirical RPG, in which you have to pass a literacy test to join the public chat channels.

You'll take my shiny from my cold dead hands.

But yes, there are often cases when low shiny is better than medium or high.

Shiny is ... Shiny!

well, if you're going to base the shiny levels off of RGB values, it wouldn't be a difficult thing methinks to just drop in support of shiny/specular maps (with the option of making it blank, of course) and it could also signifigantly free up the levels of detail (for example, your car has scratches (higher spec) and mud (lower spec)

not sure what kind of processing power that would eat up, but a lot of game engines like CoH support them so i can't see it being too huge a drain.

Its funny to me. To see how well received this item seemed to be, even by Lindens. Yet its full functionality as discussed from years ago, never got executed. Will this ever be added exactly as discussed or better? I'm thinking no considering the age of the initial suggestion.