Jump to content

Normal & Specular Maps


You are about to reply to a thread that has been inactive for 3900 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

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

  • 2 weeks later...


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

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

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


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

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

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

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

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

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


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

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


Oz Linden wrote:

We now have a wiki page on how
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:

floor_diff.png

This is where we are going: tinted diffuse + specular + normal mapping:

floor_diffspecnorm.png

And this is where we should be: tinted diffuse + specular + normal + lightmapping:

floor_diffspecnormlight.png

The diffuse map: diffuse.png

The specular map: specular.png

The normal map: normal.png

The lightmap: light.png

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.

  • Like 1
Link to comment
Share on other sites

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


Masami Kuramoto wrote:


Oz Linden wrote:

We now have a wiki page on how
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: 
diffuse.png

The specular map: 
specular.png

The normal map: 
normal.png

The lightmap: 
light.png

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

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


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


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

You are about to reply to a thread that has been inactive for 3900 days.

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
 Share

×
×
  • Create New...