Normal & Specular Maps

[Abu Nasu]

"However, the thing I remain confused about is how the directions of X and Y (R and G) are set in the tangent plane. Without that, the diagrams could be spun around the normal without changing anything. What decides which direction is the X axis here? My guess would be that it's the U and V axes of the UV map. So I want to know if that's true."

 

I think what you are looking for is the TBN matrix. Tangent, Bi-normal, Normal. It correlates local object space with uv space and eventually into world space. This is how I am able to do faux lighting effects with normals maps right in Photoshop. Not sure if that will answer this particular quandry, though.

[Masami Kuramoto]

http://modemworld.wordpress.com/2012/09/19/upcoming-sl-projects-update/2/

---

Lightmaps, however, will not be a part of materials processing. There are a number of reasons for this, which Geenz outlined at the CCIIUG meeting on Tuesday 18th September:

“First off, never store the UVs for your lightmap in the same texture channel that everything else is based off of; they need to be in a separate texture channel where there’s zero overlapping faces. Second, in order to economize on texture memory, a batch of objects’ UVs would need to be “packed” to the point that you’re using as few lightmaps as possible. Then of course there’s the handling of lighting on dynamic objects; light maps only account for lighting being received on a static surface. So there’s a lot of issues that would need to be worked on if we were to do it.; but given the amount of work that would have to go into light mapping in order to do it “right”, it probably won’t be happening for a while.”

---

Geenz is wrong there. Support for multiple UVs is indeed useful for a few things but not required for lightmapping.

As explained earlier, lightmapping is so efficient because it separates the low-detail shadows from the high-detail surface definition. The result is a small "global" lightmap and one or more small (but tileable) "local" surface textures, instead of a huge global surface texture with all the shadows baked into it. Since a lightmap can be shared by multiple materials, it would be possible to use up to 8 different surface textures per mesh or prim without loading a new lightmap every time. Imagine a mesh house where the owner can use arbitrary texture tiles for the floors and walls without ever worrying about losing the nice prebaked shadows and ambient occlusion effects provided by the creator.

All these things would work just fine with a single non-overlapping UV layout.

And frankly, this must be the first time I hear someone dismissing lightmaps because they are static. Even the latest 3D computer games still use static lightmaps because shadows are essential to communicate depth and because there is still no way to achieve the same visual quality with dynamic lighting alone. And unlike dynamic lighting, static lightmaps actually work on low-end hardware without slowing it down to a crawl.

[Kwakkelde Kwak]

---

Masami Kuramoto wrote:

All these things would work just fine with a single non-overlapping UV layout.

---

 

As far as I can see there shouldn't be a problem with one UV for both lightmap and diffuse map. I made a simple room with four walls, two randomly placed columns and a light. The four walls have one UV map.

If one wants to use 4 different diffuse maps for the 4 walls, their UV maps would be a part of this particular UV map. So material 1's UV would cover "face 1", material 2 "face 2"  etc.

The only small catch is one might have a hard time lining up the textures, a 1x1 repeat in SL won't show the entire texture applied. In this case that's easily fixed though, all 4 faces can go side by side on the UV map.

 

EDIT... This ofcourse only works if you can do the UV mapping yourself. On sculpties or on SL prims you won't be able to do that. Maybe that's what was referred to.

[Drongle McMahon]

Proposition (probably ignorant) for which refutation is invited ...

For each SL face: Assuming the lightmap has no useful repetition, it has to use a non-overlapping UV map. Since SL only has one UV map, that means the diffuse/specular/normal (dsn) maps also have non-overlapping maps. That prevents the huge economies possible with UV stacking and limits the pixel resolution of the sdn maps, EXCEPT in cases where the UV map can be laid out so that the sdn textures can be tiled. In the latter case, we get the savings Masami pointed out.... tiny dsn and light maps instead of huge baked map.

On top of that, the application of the lightmap helps to hide the obviousness of the repetition. Furthermore, in a big build, the same tiny dsn maps can be reused on hundreds of items, each with thier own tiny light maps, instead of using hundreds of unique baked maps. Objects that can take advantage of this with tiled dsn maps are very widespread, all sorts of walls, woodgrain stuff, ground, trees, etc., so that there would be large savings in spite of the limitations for those other objects which would require multiple UV maps to achieve as great savings with light maps. So I think it is a pity that the limitation resulted in the decision not to implement light maps. I imagine the light map could easily default to all white (and/or be ignored) for objects where it isn't suitable or wanted.

Another advantage ocurred to me ... in contrast with baked lighting, it would be possible to have a toggle that could turn the light map off when the graphics settings have lighting and shadows turned on (at the creator's discretion). That would allow a single set of material textures to work without conflict when shadows etc. are on but still provide lighting effects when they are off. This would be good even for objects not able to take advantage of tiled textures.

All that aside, it is Geenz who is doing the work, for which we must all be very grateful, and thus it is up to him to make the decisions. I fully support his efforts, whatever he decides.

[Kwakkelde Kwak]

---

Drongle McMahon wrote:

In the exceptional case, we get the savings Masami pointed out.... tiny dsn and light maps instead of huge baked map.

---

 

I don't think those cases are so exceptional. As far as I can think of, the vast majority of builds in SL can either be mapped like in my example above OR there is no tiling/overlapping at all like in clothing. In both cases a single UV can be used for a high res (either by size or by tiling) diffuse map and a low res light map.

[Drongle McMahon]

I agree. By exceptional, I meant not included in the category just decribed, not rare. In fact, I go on to say they are common. I will clarify that.

[Masami Kuramoto]

---

Drongle McMahon wrote:

That prevents the huge economies possible with UV stacking and limits the pixel resolution of the sdn maps, EXCEPT in cases where the UV map can be laid out so that the sdn textures can be tiled.

---

Whenever you can stack, you can tile as well. It just takes a separate material/face.

However, once the shadows have been baked into the diffuse map, you can neither stack nor tile because the redundancy is gone. So you're still better off with a lightmap than without.

[Kwakkelde Kwak]

---

Masami Kuramoto wrote:

Whenever you can stack, you can tile as well. It just takes a separate material/face.

---

And sometimes some serious mindboggling UV mapping and tiling/offsetting, things can be a lot more complex than a four wall room.

You could keep that pretty simple if you used a new material for every face you'd normally stack, but then 8 materials are a real limitation.

I see more benefits than drawbacks really, but I'm not so sure if this is the case for the average user. Don't forget not everyone can use a 3d program like you can. One of the nicest features of SL is still the "do anything you please" environment. When things get so complicated only experienced builders can use new features, SL loses what sets it apart.

[Masami Kuramoto]

Baking shadows is not rocket science. Many SL creators already do it, and they know that it usually takes a non-overlapping UV layout. This feature, if added, will not raise the bar at all.

[Masami Kuramoto]

---

Drongle McMahon wrote:

All that aside, it is Geenz who is doing the work, for which we must all be very grateful, and thus it is up to him to make the decisions. I fully support his efforts, whatever he decides.

---

Maybe he just wants to keep the goodies for himself. :matte-motes-wink-tongue:

http://forum.unity3d.com/threads/59077-Geenz-s-Shader-Stuff-Now-with-more-lightmap-shaders!?p=390518&viewfull=1#post390518

It seems that he does realize the value of lightmapping and knows how to implement the shader. Now all we need to do is convince him that SL is worthy of this feature.

(And we're not even asking for advanced stuff such as RNMs.)

[Kwakkelde Kwak]

---

Masami Kuramoto wrote:

Baking shadows is not rocket science. Many SL creators already do it, and they know that it usually takes a non-overlapping UV layout. This feature, if added, will not raise the bar at all.

---

No, baking shadows is not rocket science, but you can stack a texture once baked.

[Masami Kuramoto]

---

Kwakkelde Kwak wrote:

No, baking shadows is not rocket science, but you can stack a texture once baked.

---

Only if the lighting supports the stacking. If it does, you can as well stack the lightmaps. It makes no difference.

[Kwakkelde Kwak]

Yes you're right, forget that last post.

That's not what I ment in the post prior to that though. What I ment was with a UV map like in my example, you can have the single lightmap for everything in a 1x1 repeat, that will fit nicely. The problem will occur where the walls meet. Matching the diffuse map in the corners when you tile can be real tricky.

The UV for the lightmap can be placed any way you want, but if you do that more or less randomly, like in the UV map I made, the diffuse map doesn't match. This problem will get worse when you start tiling the diffuse map. There's no problem when the wall has a stucco texture, but with bricks or bigger tiles, even in the best case only some repeats will work. You can't offset per face since that would affect all faces. So you'd have to use a lot of different faces and with only 8 per object. That can be a true pain. The other option would be to map out the walls on the UV on a grid, that's what I ment by some serious UV mapping. I agree it's not rocket science, but it takes some careful planning or it could result in big patches of unused texture space for the lightmap. (Not a real issue if this is limited to let's say 256 or 512)

[Drongle McMahon]

"The other option would be to map out the walls on the UV on a grid"

If I am understanding correctly ... It's relatively easy to get the alignments right by hand-editing the UV map while watching the textured display (at least in Blender). Of course it then only works for the same texture, unless the maps are aligned to repeat boundaries, in which case it works for anything with same repeat density.

[Kwakkelde Kwak]

Yes getting the textures to align isn't that difficult for a diffuse map, but...

Since you can't stack any UV space, you're very limited to how you can use the canvas. An example with three adjacent brick walls of different size. I don't think that's a very uncommon setup.

In the top picture I set the texture repeat to 2x2, this means you can use a texture repeat of 2x2, 2x4, 4x2, 4x4 etc. To line up the three walls, the left lower corner of the wall needs to be on the left lower corner of the texture, or you will get half bricks in the corner when you start tiling. Also the dimensions in model space and UV space need to match. So the biggest wall can be scaled to fit within a quarter of the UV space. The two smaller walls are..well smaller. For diffuse mapping this is not a problem, since it's set up for tiling, but look at the enormous amount of unused UV space, space that can't be used for baking light.

If you can use two UV maps however, you can stack the three walls, which is a little less work than the way it's done above. The big difference is, you can randomly place the walls on the canvas of the second UV for light baking. I admit it's not the prettiest of UV maps, but it's a lot more efficient than the one above.

[Masami Kuramoto]

The 2x2 layout is not ideal because a quarter of the UV space is wasted:

Fortunately 2x2 is not the only available option. You can use 1x3 instead:

Now your UV map looks much better:

Of course I agree that a secondary UV map would make things easier. But diffuse + lightmap with a shared UV layout is still much better than no lightmap at all.

[Kwakkelde Kwak]

Eh it was just an example Masami, to illustrate the "grid option"

2x2 is nice though, because you do not need to calculate anything, if x has a 12.34953 repeat, so does y. Again not rocketscience to make the y repeat 3 times bigger than x ofcourse, but an extra step for a potential buyer nonetheless.

For a brick wall you don't even need to use the "grid option". You could place the islands side by side and push them against eachother wasting even less. But even then you are leaving valuable UV space unused for the lightmap, especially when the wall varies a lot in height.

I'm just trying to grasp why LL doesn't want the lightmap because it would need its own UV map. Personally I'd say include it, in a lot of cases it would work just fine.

 

[Masami Kuramoto]

---

Kwakkelde Kwak wrote:

I'm just trying to grasp why LL doesn't want the lightmap because it would need its own UV map. Personally I'd say include it, in a lot of cases it would work just fine.

---

I wonder whether LL cares at all. As usual, the whole process is as opaque as it gets. There is no communication beyond the weekly CCIIUG meetings. I cannot attend these. All I can do is post examples to demonstrate the potential texture space savings.

[Jay Taggart]

In 3dsmax, I can crank up the "bumpiness" of my normal maps, to make them pop out more or less. I think something similar would be nice in SL, so we can tweak the 3d effect on the fly. The same feature would be useful for the specular map.

This way you dont have to tweak the map in an external program, upload, check, repeat.

I'm super stoked about all this btw, I even went ahead and started making normal and spec maps for many of my textures (yes they will need tweaking and alpha channel stuff done, but I'm too excited not to!)

[TwiFi Shamen]

This should greatly assist builders in achieving better-looking creations, along with variations, without increasing the face count. Normal mapping is a great way for adding the extra detailing without having to add in those extra faces. It will help with saving on prim count, thus increasing server (and probably viewer depending on how complex the mapping) performance, and reducing cost of having to re-upload something to add more detail to the model.

However, even though it is a great add-on to second life. I think it should be set that normal mapping occurs at LOD0 (closest to the object). This way not normal map needlessly added to the query for people to load when not even get close enough to notice the difference from the applied normal mapping. This in turn helps with decreases the reduction of viewer side performance from possible overly complex normal mapping having to be needlessly calculated.

The feature would most likely take some time to implement and make stable sever side (as it has been a few months already). It would probably be along with another major update due to it most likely requiring a remake of the in-world editing sections. I believe that it should have its own tab, and not added to the texture tab. Each section should have its own tab: General, Object, Features, Texture, Normal, Specular, and Content.

Normal Mapping and Specular Mapping needs to be separate from the already existing texture tab. Having them added to the already existing texture tab would make it extremely long and/or abnormally wide when compared to the other tabs. It would also reduce future possibility of expansion for the new features if clumped together. If not done in the beginning of implementation, it would become required when expanding the feature customization. Feature expansions such as the level of strength, and default or planer mapping (of using a design normal or your own).

[powerdance]

this is perfect, absolutelly amazing.thank you for great news!

[powerdance]

Rendering Performance Video looks so amazing . Its so charming.

I play it again :cathappy:

[Lorek Eusebio]

So what's going on with this project? Is it dead in the water? There doesn't seem to be any update on the JIRA since it was created back in August... The workflow chart thing says that it hasn't even been started. Does anyone know what's going on?

[Ronald Greybeard]

any updates?

[Kwakkelde Kwak]

---

Ronald Greybeard wrote:

any updates?

---

Most certainly, from the Second life Server forum:

Second Life Server (main channel)

The main channel is getting the interest list improvement project which has been on Magnum for the past few weeks.

In addition to the interest list changes, this version adds support for normal and specular maps.  This blog post has more information about the project.  The next step is to release a project viewer, which will allow users to try out this new functionality.

https://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Server/13#13.02.08.270166

Scheduled Wednesday 2013-02-20 05:00-12:00 PST