Emily Aries Posted August 22, 2012 Share Posted August 22, 2012 What I feel is really lacking from this updated material system is an Emissive/glow map for self illumination. This map would come in so very handy in SL for so many things. It seems a waste to do all this work and miss out something like this. They really need to go that extra mile. A few things that you could use an emissive map for: Glowing house windows in a winter town. Glowing logs on a fireplace Glowing lines or lights on Robot/Scifi avatars. (A proper tron suit anyone?) Lit buttons and fronts on a drinks machine (Or any machine) Img Img Img Img Sure we can do a lot of these things now but you always need to use more prims and so many prims is what we need to get away from. A self illuminated model would be so much cheaper to render than the options we have now. Link to comment Share on other sites More sharing options...
Oz Linden Posted September 4, 2012 Share Posted September 4, 2012 We've put up a wiki page that outlines the capabilities we're designing to support in the UI changes: https://wiki.secondlife.com/wiki/Project_Snowstorm/Normal_Specular_User_Stories Watch this thread for more updates soon on how the images will be interpreted. Link to comment Share on other sites More sharing options...
Darien Caldwell Posted September 6, 2012 Share Posted September 6, 2012 Qie Niangao wrote: I've mentioned it in another forum, but just to add here: It's critical that there be a scripting interface to the server side of this as soon as it's available in the viewer. At the very least, we need to be able to set the maps. Assuming they aren't locked to textures (and they sure better not be), they'll also need to be animated, aligned, and scaled by script, too. (Futile though it may be to mention: it's not necessary to further clutter-up the viewer's build tool with any UI for this. I don't actually expect that viewer devs (LL and TPV) will be able to stop themselves from hanging yet more floating complexity off what are already UI abominations, but it's an option to instead simply let scripts define how users manipulate these.) Agreed. For various items with texture changing needs, being forced to use the same Specular/Bump for every possible texture would be madness. At a bare minimum, Scripts need to be able to update these new attributes as well. Link to comment Share on other sites More sharing options...
Oz Linden Posted September 11, 2012 Share Posted September 11, 2012 We now have a wiki page on how Material Data is interpreted and used. Note that nothing there is final until it's all working... Link to comment Share on other sites More sharing options...
Drongle McMahon Posted September 12, 2012 Share Posted September 12, 2012 A couple of comments/queries... 1. The offsets are decribed as absolute displacements in meters. That is inconsistent with the current interpretation in default mapping mode, in the edit floater or LSL, which is a proportional offset (unit = face dimension). Can I assume that this as written applies in planar mapping mode only, and that the usual interpretation will apply in the more frequently used default mapping? 2. "Used only when Alpha Mode is Alpha Test (see description of that mode above)". Alpha Test mode appears not to be described above (or below) this statement. 3. The three maps each has "its own" position and scaling properties. This suggests that all the constituent parameters are independently adjustable. Can that be explicitly confirmed? Link to comment Share on other sites More sharing options...
Emily Aries Posted September 12, 2012 Share Posted September 12, 2012 Good to see emissive has made it in but it seems a bit hobbled. Why is emissive lumped in with the alpha channel and not a separate texture? The way I read it is that you can either use the alpha layer for transparency or light emission but not both. What if I wanted a transparent window in a winter build that only glowed where snow had accumulated around the edges/bottom. I would have to use another prim and texture, in which case why not just allow us to have a separate emissive texture so that we can use both transparency and emissive at the same time and then we don't need the second prim. Link to comment Share on other sites More sharing options...
Helium Loon Posted September 12, 2012 Share Posted September 12, 2012 Any chance the updates to the shaders can include the ability to mix shiny and transparent? The fact the two are mutually exclusive currently is a big limitation. Link to comment Share on other sites More sharing options...
Darien Caldwell Posted September 15, 2012 Share Posted September 15, 2012 Drongle McMahon wrote: A couple of comments/queries... 2. "Used only when Alpha Mode is Alpha Test (see description of that mode above)". Alpha Test mode appears not to be described above (or below) this statement. From reading the descriptions I think "Alpha Test" refers to "Alpha Mask (cutoff)" mode. That value would be the Alpha cutoff value used for 'cutoff' mode. I am curious about the statement: Color "a solid color for the surface; not used if a Texture is also specified" Is this color in addition to the usual "prim color" already available? And if so, this is a change in behavior. One was always able to tint textures using the color. Link to comment Share on other sites More sharing options...
Drongle McMahon Posted September 15, 2012 Share Posted September 15, 2012 Oh yes. That would certainly lose backward compatability. It could be a bit of ambiguity - Solid color only if ther's no texture, tint if there is? A more general question is whether the new system will apply to existing things, using just the diffuse map and defaults with no effect for the rest; or whether there will be a toggle new/old system. A toggle would guarantee not breaking anything and allow people to go on using the legacy system if they wanted to. I guess the biggest potential problem would be old shiny vs new specular. Link to comment Share on other sites More sharing options...
Qie Niangao Posted September 15, 2012 Share Posted September 15, 2012 I see nothing in the user stories about a scripted interface. That's unfortunate, if not surprising at this stage. It is crucial, however, that the spec for initial viewer behavior include how it is to respond to server messaging about texture animation (at the very least). Eventually, and especially if all -maps aren't locked to the same alignment and repeats as the diffusemap (as the draft Materials Data spec says they won't be), it's going to be necessary to control animation independently for each map. For the moment, however, it's important to determine compatibility decisions about how the other maps will respond to legacy messaging about diffusemap properties set with llSetTextureAnim(). Coincidentally, it seems that Tonya Souther is currently working on a very old universal viewer defect involving animation of non-default repeats and offsets, so she may have the most recent exposure to relevant code and its vagaries. Link to comment Share on other sites More sharing options...
Drongle McMahon Posted September 15, 2012 Share Posted September 15, 2012 I agree about the need for scripting interface. Of corse that requires a lot more server coding while the present proposal could be mostly viewer. UI access isn't specified either, so I wouldn't lose all hope yet. I'm not sure about the independence of the scaling etc "its own set of the same Positioning and Scaling properties" doesn't explicitly say they are not constrained to be the same, whether it's direct or through shared interfaces. You are probably right though. I think independence is potentiall very valuable, but it does introduce the complications you raised. I asked for clarification. Link to comment Share on other sites More sharing options...
Drongle McMahon Posted September 15, 2012 Share Posted September 15, 2012 Can anyone give, point me to, a clear explanation of how the RGB values in a tangent space normal map are converted into object/world normals (essentially asking, how are the G and B axes set in the tangent plane relative to object and/or UV map space?). Also, how exactly does Blender use the data in an image to affect the normals when you set it to "Influence" the normal, without checking "Normal map" in the sampling properties? Link to comment Share on other sites More sharing options...
Aribeth Zelin Posted September 15, 2012 Share Posted September 15, 2012 Will there please be plans to add additional materials in the future? That or get this right the first go around? The ability to make shiny transluscent items would be a godsend for jewelry makers, as well as glass for buildings, furnishings, etc. Please don't keep those two things mutually exclusive. Link to comment Share on other sites More sharing options...
Tomos Halsey Posted September 15, 2012 Share Posted September 15, 2012 Actually it is possible to have those effects on at the same time in the 3dsmax view port you just need to get it configured right. Just responding to something on like page 2 Link to comment Share on other sites More sharing options...
Tomos Halsey Posted September 15, 2012 Share Posted September 15, 2012 You can also make transparent shiny already using a "hackaround" that causes ultra mode to do both. Link to comment Share on other sites More sharing options...
Drongle McMahon Posted September 15, 2012 Share Posted September 15, 2012 Transparecy and specular exponent are in alpha channels of different maps. I think that means they are not exclusive as far as the input specification is concerned. I guess it still depends on the shader though. I would imagine realistic glass is fairly high on the wish-list for the people implenenting this. Link to comment Share on other sites More sharing options...
Darien Caldwell Posted September 15, 2012 Share Posted September 15, 2012 Drongle McMahon wrote: Oh yes. That would certainly lose backward compatability. It could be a bit of ambiguity - Solid color only if ther's no texture, tint if there is? A more general question is whether the new system will apply to existing things, using just the diffuse map and defaults with no effect for the rest; or whether there will be a toggle new/old system. A toggle would guarantee not breaking anything and allow people to go on using the legacy system if they wanted to. I guess the biggest potential problem would be old shiny vs new specular. I hope it's just a mistake or as you say an ambiguity. People like to have coloring options, and a very common way to do that is to use greyscale textures combined with color tinting of the texture. It's a very important tool. One could argue removing this functionality just means you have to make a texture for every color, but the lack of scripting interface would prevent that too. So it would certainly put creators in a bind. Link to comment Share on other sites More sharing options...
ac14 Hutson Posted September 15, 2012 Share Posted September 15, 2012 I really hope that the viewer settings have been changed to show these new mateirals but not the more advanced unlimited local light and shadows. I know many people whos computer is good enough to handle normal snd specular mapping but performance is crippled due to the other features packed in. Link to comment Share on other sites More sharing options...
Masami Kuramoto Posted September 16, 2012 Share Posted September 16, 2012 Oz Linden wrote: We now have a wiki page on how Material Data is interpreted and used. Note that nothing there is final until it's all working... I could write all day about why lightmaps are a must-have feature, but maybe a few pictures will help bring the point across. This is where we are now: tinted diffuse mapping: This is where we are going: tinted diffuse + specular + normal mapping: And this is where we should be: tinted diffuse + specular + normal + lightmapping: The diffuse map: The specular map: The normal map: The lightmap: Total texture size: 512x512. Effective texture size visible inworld for this example: 8192x8192. No blur, no pixelation, no alpha sorting issues, and the floor tiles can be reused elsewhere because the shadows are not baked in but kept separate. Furthermore, static lightmapping is much less taxing to low-end hardware than dynamic shadows. It's ideal for indoor scenes with multiple lights and soft shadows. Static lightmapping was a feature of the Quake game engine released in 1996. Please, for the love of Philip, give us access to this ancient technology, so that SL can finally look decent. 1 Link to comment Share on other sites More sharing options...
Drongle McMahon Posted September 16, 2012 Share Posted September 16, 2012 Yes. If we are correct in interpreting the wiki as saying that each of the maps is already going to have independent scaling and offset parameters, then I would guess it should not be difficult to add this, even if it's not there at the outset. People are going to go on using baked lighting, and the potential for saving total texture downloads is HUGE. Link to comment Share on other sites More sharing options...
Darien Caldwell Posted September 16, 2012 Share Posted September 16, 2012 Masami Kuramoto wrote: Oz Linden wrote: We now have a wiki page on how Material Data is interpreted and used. Note that nothing there is final until it's all working... I could write all day about why lightmaps are a must-have feature, but maybe a few pictures will help bring the point across. This is where we are now: tinted diffuse mapping: This is where we are going: tinted diffuse + specular + normal mapping: And this is where we should be: tinted diffuse + specular + normal + lightmapping: The diffuse map: The specular map: The normal map: The lightmap: Total texture size: 512x512. Effective texture size visible inworld for this example: 8192x8192. No blur, no pixelation, no alpha sorting issues, and the floor tiles can be reused elsewhere because the shadows are not baked in but kept separate. Furthermore, static lightmapping is much less taxing to low-end hardware than dynamic shadows. It's ideal for indoor scenes with multiple lights and soft shadows. Static lightmapping was a feature of the Quake game engine released in 1996. Please, for the love of Philip, give us access to this ancient technology, so that SL can finally look decent. I don't see how this is any better than baked lighting. From the looks of it, it's still static; if you moved the light to the other side of the rail, then what? You're going to have to explain why this is better than a baked shadow, when both don't move with changes to the light source. Link to comment Share on other sites More sharing options...
Drongle McMahon Posted September 16, 2012 Share Posted September 16, 2012 The effect is more or less the same as baked lighting. The important difference is that the detail is a small texture tiled, while the lighting is a small texture interpolated (blurred) over the larger area. So the entire texture data is much smaller. The whole lighted area is something like 20 x 20 tiles of the first three maps. So a normal baked lighting texture would have to be (20x256) x (20x 256) to achieve the same resolution of the detail. Instead, this is just four 256 x 256 images. That is a 99% reduction in the reqired data download (ignoring compression efffects). In practice, you can't have 5120x5120*, but you could use 25 box prims with a different 1024x1024 on each, with the same effect, or you can do tricks with mesh faces. If you compromise and use one 1024 x 1024, then you get 5-fold poorer texture resolution and still use four times as much image data. *of course, if you use specular and normal maps as well, it's three times that! Link to comment Share on other sites More sharing options...
Kwakkelde Kwak Posted September 16, 2012 Share Posted September 16, 2012 As far as I know it's only possible when you use a plugin. If 3ds max does it on default I think it's a bit childish to say it does, then don't say how Link to comment Share on other sites More sharing options...
Qie Niangao Posted September 16, 2012 Share Posted September 16, 2012 People are going to go on using baked lighting I'm sure that for a long time there will be folks using rigs for which dynamic lighting and shadows yield unacceptable performance. But similar to an earlier question: is deferred rendering required for these material effects to work, and if so, does that imply dynamic lighting and shadows will always be present anyway? Link to comment Share on other sites More sharing options...
Masami Kuramoto Posted September 16, 2012 Share Posted September 16, 2012 Darien Caldwell wrote: I don't see how this is any better than baked lighting. From the looks of it, it's still static; if you moved the light to the other side of the rail, then what? You're going to have to explain why this is better than a baked shadow, when both don't move with changes to the light source. To achieve the same look without lightmapping, you have to bake the shadows into the diffuse map and into the specular map. So instead of four 256x256 maps, you'll need a 8192x8192 diffuse map, a 8192x8192 specular map, and the 256x256 normal map. You'll waste 512 times more texture space than necessary. SL doesn't even support textures that large, so you'll either have to use multiple materials with 1024x1024 textures mapped to the floor, or an alpha plane hovering above it, or you'll have to settle for a blurry 1024x1024 floor texture (and still waste 8 times more space than necessary). Link to comment Share on other sites More sharing options...
Recommended Posts
Please take a moment to consider if this thread is worth bumping.
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now