Materials Project Wishlist

[Ashasekayi Ra]

Ok, so mesh has been released officially. Yay! I know it is early and the LL devs will probably continuing working on mesh for quite some time before they move on to expanding the material/shader system. That being said, I can't help but be excited about seeing some new materials that will enhance mesh. I'm also curious to hear most people's top three material requests.

My wishlist includes normal, specular and AO pass maps. (Ok, I'll cheat and add lightmaps too.) :p

[Drongle McMahon]

I want to be able to apply a relatively low resolution AO on top of a tiled texture for high detail. That would allow huge texture dowload savings and should therefore be a priority. I don't care whether it's proper materials or a kludge. The important thing is to have different dimensions and repeats for the different maps. Otherwise the materials will just increase texture download lag instead of reducing it.

[Siddean Munro]

Yep normal/bump, specular and ao would do me just fine!!

[DanielRavenNest Noe]

If they want to limit the number of render passes (to maintain performance)  just having a second map, and a selection dropdown to use it as Ambient occlusion, additive detail, normal, or specular would be a big step forward.  Additive detail means you add the two texture maps, possibly with different UV tiling ratios.

And low shiny is still too shiny for many items, make that a number entry (% shine)

[Tarius Auxarmes]

---

DanielRavenNest Noe wrote:

If they want to limit the number of render passes (to maintain performance)  just having a second map, and a selection dropdown to use it as Ambient occlusion, additive detail, normal, or specular would be a big step forward.  Additive detail means you add the two texture maps, possibly with different UV tiling ratios.

And low shiny is still too shiny for many items, make that a number entry (% shine)

---

I was just thinking the other day how shinyness needs to be a value and not restricted to a mere 3.

[WADE1 Jya]

I would just like to see something (which to my nontechnical mind) seems like it would be simple to implement. More materials allowed per mesh than 8. Somebody else earlier was asking for this & I disagreed it was useful at the time, but now I'm thinking it would be highly beneficial.

Maybe it is just set this way because parametric prims ever only had 8 faces max (and mesh co-opts this), or maybe there is a very very good reason not to implement this, but to me it seems like a good idea now :matte-motes-impatient:

I'd also like to see a fuller materials system so we can do things like make realistic ice, snow, frosted glass, diamonds etc (whatever the technical jargon for that part of materials might be). Oh and lava too. I wanna make elemental fantasy animals.

Sorry I can't explain what I want better in proper terms... the way I work software I am like one of those weird musicians who can play the song but can't read the music.

[Tarius Auxarmes]

---

WADE1 Jya wrote:

I would just like to see something (which to my nontechnical mind) seems like it would be simple to implement. More materials allowed per mesh than 8. Somebody else earlier was asking for this & I disagreed it was useful at the time, but now I'm thinking it would be highly beneficial.

Maybe it is just set this way because parametric prims ever only had 8 faces max (and mesh co-opts this), or maybe there is a very very good reason not to implement this, but to me it seems like a good idea now :matte-motes-impatient:

I'd also like to see a fuller materials system so we can do things like make realistic ice, snow, frosted glass, diamonds etc (whatever the technical jargon for that part of materials might be). Oh and lava too. I wanna make elemental fantasy animals.

Sorry I can't explain what I want better in proper terms... the way I work software I am like one of those weird musicians who can play the song but can't read the music.

---

While limiting to 8 faces is...well...limiting, that many is enough for even moderatly complex things that might be created. Even the professionals dont use tons of textures per object and in many cases, they shove a bunch of stuff into one texture to optimize the amount of memory used.

With the materials like ice and frosting, you mean overlays which is basically a texture layer. Yes, it would be nice to have something like this rather than needing to use another prim.(although, thinking about using one of the mesh faces here...) I supposed you could think of clothing as the closest thing to this.

I understand the logic of software, but dont ask me to write code.

[WADE1 Jya]

I've seen stuff done with overlays inworld but not quite what I'm aiming for, i want materials to do something like these (images not mine, its random pics from net):

I've acheived sort of fascimiles to this appearance outside of SL, but wouldn't know what these effects are called to say --- hey Lindens please add ______ to the materials project.

Sort of an illusion given of internal depth & semi-opaqueness to the core of a semi-transparent object. Is it possible with overlays? Perhaps with the new lighting of Viewer 3.0 it could be done?

 

 

 

[Ashasekayi Ra]

I'd agree that an extra slot for an AO pass map would probably be one of the biggest helps. You could have the benefit of high resolution without the negative of large textures maps. It is win-win. I think the next map that would offer the next biggest benefit is normal maps. They can let you use far less polygons yet give the illusion of a model with a great amount of details.

As for the comment on 8 texture faces, I'd assume one of the reasons they limited that was because in traditional game art you'd rarely ever need that many material ids on one model. I mean even outside of game art when you look at high resolution human models, they only have three material ids max. So, the LL devs are probably trying to prevent people from loading tons of 1024 x 1024 maps on one model.

[DanielRavenNest Noe]

What you are asking for is translucency done as depth, not just surface texture, plus internal surfaces for the ice defects/inclusions.  We could get an approximation in SL, but to do it correctly you need a raytrace algorithm that follows the light as it goes through a depth of material, and that is too slow for a real time game.  Raytrace is used in commercial graphics, but it can take several minutes to do one image.  Second life renders muliple images (frames) per second.

The ashtray is also showing "Index of refraction", the bending of light that items like glass and water do.  SL doesn't have that feature in it's rendering engine.

[WADE1 Jya]

@Ashasekayi: yeah i can see the difficulties, i'd want to do sensible stuff with it, just LSL really, but I think you are right people would abuse it as you describe. Even a minor limit raise would probably just lead to all kinds of horrible applications popping up around the grid.... its cool i can get by quite fine without it too

Thanks Daniel! Raytrace is it eh I see... I've done it for logo and stuff outside of SL and yeah the renders took forever just to get a few seconds of video outputted. Guess that idea is out..... at least until maybe someday in future when we see major new technology change of graphic processing :smileyvery-happy:

Could "Index of refraction" ever be added you think, or is that also too sluggish for a real time environment?

[Jay Taggart]

2 texture slots:

First: Detail/Diffuse; alpha channel controls transparency

Second: Normal map; alpha channel as specular map (no specular color this way, but many rendering engines dont even use colored spec anyway)

And perhaps a third slot for emissive/glow/self-illumination map(maybe with a limit to 64X64 resolution or something).

Maybe some specular power % control, and a seperate glow strength for the self-illumination. You should also have the option for 'shiny' to only show on bright specular areas. I also agree with making a change to the low-med-high shiny option...make it a % number.

The AO thing sounds nice too, since many people still cant run shadows. It could effectively be the same as a lightmap(instead of just baking ambient occlusion, bake shadows as well). I also wonder if there would be a PE penalty added for additional textures on an object. They could probably apply this to regular prims and sculpts because it likely wouldnt break existing content (i.e. if your existing prim build doesnt use the 2nd or 3rd texture slot, it stays at the same weight).

Edit: It would be nice if there was a way to use shiny on alpha channel transparencies too(shiny glass effects etc)

Edit2: I also miss the "environment map" look shiny has when you dont have shadows enabled. With shadows on, shiny acts as more of a specular highlight, affected only by direct sun or light. I would like to have both, if possible. That specular highlight with shadows enabled is also nearly non-existent in most cases, unless your camera angle is *just* right. There should be more of an ambient highlight in addition to that somehow. Though I suppose that is more of a rendering issue than a material issue.

[Chosen Few]

What Drongle is referring to are properly called light maps.  I'd give my (avatar's) right arm if we could have them in SL.  I use them all the time on other platforms, and they're soooooo amazingly handy.  They're my number one must-have item.  (They don't have to be just for AO, by the way.  They can map any lighting scheme you'd care to put on them, with the only overhead being a small extra set of UV data, and very tiny 8-bit grayscale texture.)

The rest of my list, in no particular order, includes bump and spec channels, normal maps, and a standard assortment of basic shader materials (lambert, blinn, and phong, at the very least).

[Chaos Borkotron]

I'd like a setting that stops the sun/moon light from affecting the texture/prim while still allowing local lights to affect them

[leliel Mirihi]

---

Chaos Borkotron wrote:

I'd like a setting that stops the sun/moon light from affecting the texture/prim while still allowing local lights to affect them

---

Could you give us a usage case for that which doesn't involve faking indoor environments.

[Charlar Linden]

Thanks everyone for discussing your ideas and desires here. Please do try to keep it focused on the idea of a Materials system, as it'll be easier for us to review it when the time comes.

As I said in the Usergroup, I can't make any promises as to when this project fits in our timeline. Currently we're focused on Stability and Quality; making SL work for more people more of the time.

Cheers

 

Charlar

[leliel Mirihi]

I only have two hard requirements for a materials systems. First the wire protocol should be extensible. We should be able to add new options to the system without having to update every viewer in the world (i.e. a viewer will ignore anything it doesn't understand). Second the sim should do absolutely no verification of the materials data at all. We should not need to beg for server updates just so we can implement viewer features.

[DanielRavenNest Noe]

@leliel - If I understand what you are proposing, then maps besides color would still be uploaded as JPEG 2000 files (which is what everything is stored as right now).  So normal maps, specular maps, etc. all are treated as simple textures are now, which means no change to the asset database system.  But when used in the viewer edit window, we have some means of flagging "this is a normal map" when you apply it to an object.  The set of maps a viewer can render depends on the shaders it uses, but I assume would be a superset of whatever is in the official viewer.

I can think of two ways to flag what kind of map is being used.  One is a naming convention, where you have a string like "[normal]" in the inventory name to identify it as a normal map. The other is a list in the edit window where you select the map type.

[leliel Mirihi]

I had more in mind something like a text file that lists asset UUIDs and their purpose. There can, and should be a fancy UI for creating the text file, but I want the actual wire protocol to be plain LLSD, XML or whatever. This way TPVs could add new material types without breaking old viewers or needing server side support. After a material is widely used and supported LL could make it "official". This would let us users try out new things freely and LL could just pick up the best ones that win.

[Chosen Few]

From a developer's perspective, your proposal makes perfect sense, Leliel. Give developers as much freedom as possible to develop, unhindered by any need to wait for LL support.  Let progress progress.  Excellent.

But when I also look at it from a user perspective, I can't help but worry about fragmentation.  I'd really hate to end up in a situation where creators are all developing different content for different viewers, or perhaps even worse, where it becomes somehow trendy for a large amount of creators to make content that can only be seen properly on one particular viewer, leaving everyone else who might not want that one out in the cold.

Any thoughts on how best to bridge that potential gulf?

[leliel Mirihi]

I will admit that fragmentation and vendor specific extensions would be somewhat of a problem with this system, but I don't think insurmountable. I intentionally modeled this system after the extension systems that are used in OpenGL and web browsers. Both of them have been doing it this way for over a decade but still managed to keep things together (for the most part). 

First and foremost, the viewers are open source, there's nothing stopping viewer X from incorporating an extension from viewer Y if it's good. That is in fact the goal of this system, the features will prove their worth by the fact that people request their favorite viewer pick them up and the developers responding accordingly.

Second of all it would allow time for user feed back to improve the extension before it gets set in stone by LL and required to be supported forever. Viewer X adds experimental extension N, early adopter content creators try it out and give feed back, Viewer X comes out with a new version that works well and proves to be popular, viewer Y picks it up and so on.

Third it's content creators that are going to be using these features, but it can be hard to know what will work best until you try things out. If we went through the normal process LL could end up implementing features that a year or two down the line we could end up regretting. This would give us a chance to experiment to figure out what works first.

Granted I will admit a material system doesn't necessarily need to be all that grandiose. But it's the only way I can think of to maintain both backwards and forwards compatibility without having to regret past choices in hind sight.

[Tiberious Neruda]

Here's a few basic ones that nobody seems to have mentioned yet:

 

1. Tiling option for diffuse textures (what we in SL know as textures right now) with UV mapping outside the normal space. Default would be 'Repeat' (normal SL behavior), with 'Extend' (extends edge color past boundaries) and 'Flip' (mirrors texture past boundaries), possibly with separate Horizontal and Vertical options.
2. 'Sprite' option. This would need documented, but would cause the geometry facing a certain direction (say, positive X, like avatar meshes) to render similar to a static, unfading particle. Unlike a particle, though, this could be textured like a prim or mesh, allowing for animation, or other prim face effects.
3. Change Shiny (old style) to Reflection, adding a space for a texture to be used, instead of the procedurally-generated reflection texture currently used. Add the 0-1.0 or percentage option to replace Low, Medium and High.

Now, this other one, is a little more complex, so allow me to explain.

 

I'd like to have a variable-width 'line' geometry available as a per-'face' (in SL terms, meaning a mesh material) option. It would be generated by the hard/sharp/unsmoothed edges in any given mesh or prim, and be viewable from all angles (when selecting the 'Line' option, the thickness would be half the chosen width on each side of the edge). The face/material would also accept UV mapping for as much texture area is shown.

[Angeleos Hoffnung]

Something that would be very useful would be to improve alpha rendering options not only in the materials system. I have big problems doing  alpha textures even if i do a hard alpha of my translucent texture. It would be great to have an option to set a primmaterial as hard alpha material so it doesn´t have the translucency glitch (flickering and sorting problems).

It would improve grafics and i guess it would also be a benefit to the rendering overhead costs on fps.

Something like this in the Texture option :

Use Hardalpha = True

To all other developments, please do it linden lab. It would bring more options to improve performance since normalmapping , bumpmapping and so on can fake many polygones which in turns would give more options to create richt detailed world without having EXTREME polycounts.

 

[Chosen Few]

---

Angeleos Hoffnung wrote:

It would be great to have an option to set a primmaterial as hard alpha material so it doesn´t have the translucency glitch (flickering and sorting problems).

---

What you're referring to is properly called a 1-bit alpha map, as opposed to the 8-bit alpha maps that SL currently supports.  1-bit alphas are pure black and white, no grayscale.  The transparency per pixel is either full on or full off, no blending.

The lack of blending prevents the sorting glitch, as you mentioned.  There is a big downside, though.  All diagonal edges end up jagged, since there's no anti-aliasing in the alpha map.  Things can end up looking really ugly.  1-bit alphas are great for things like rectangular window frames, but as soon as you need diagonals or curved shapes, they become problematic.

I don't know enough about how SL actually handles imagery under the hood to know how much of a technological leap it would be to get it to support 1-bit images.  Maybe someone more knowledgeable could comment on that?

 

I've never seen it referred to as a "hard alpha" before, by the way.  Out of curiosity, where did you pick up that term?

[Kwakkelde Kwak]

SL already supports 1 bit alpha. Since "the olden days"  it has linden trees. Since more recently SL turns 8 bit alpha channels into 1 bit sometimes. Someone explained when and why, I'm sure someone will respond again. It's not a setting you can turn on and off though and I think it only works with either certain viewers or certain display settings.