The art of texturing and it's absence in Second Life.

[AmberJoyBliss]

Here are some of the things that boggle my mind, even from the very expensive builds around the grid. In no particular order. I will not be around much to answer, so it is up to the community to discuss professional texturing further. Most of this information comes from the world of gamedev, shader programming, and my frustrations inside Second Life.

• Look into planar texturing for box shaped prims.
• Select each face and stretch them based on the size ratio of the face.
• Rotate textures and flip them horizontally or vertically with a minus value to make it somewhat seamless.
• Do not overlap textures and/or prims, as they will flicker from some angles.
• Do not just accept circular surfaces and that kaleidoscope effect, try planar or the default on that particular surface.
• When using one texture on multi-prim builds, get the stretching and tiling correct on each prim to avoid that cheap effect from a good texture on larger prims.
• If you have a normal map or an ao map, bring these into Photoshop, GIMP or photopea.com and but the normal or ao on a layer above the diffuse/albedo map.
  • For ao, leave as is and for normal, desaturate it to B/W and then invert the colors.
  • Choose softlight, multiply or any of those, even screen and blend it in.
  • Go wild here and try all sorts of things, roughness map, specular etc.
  • This will give you a single texture with depth.
• 2048 or 1024 texture are not always required. You can go as low as 32x32 for repeated patterns. Graphics memory optimisations are an art form you must get right.
• For non-repetitive grass planes, rez a thin plate just above the tiled grass and find a dirt texture from the library.
  • Stretch the dirt so it is much larger than the grass tile and bring up the transparency.
  • This will make it look like one huge grass plane without that rectangular repetition.
• Test your textures under different lighting setting, as they may look great in daylight, but look bad in the other settings.
• Consider making your textures B/W and then use colouring in SL to give them colour.
  • With this, you can reuse a single texture many times, move it around, stretch it, rotate it etc. and lower that lag and/or texture memory by a lot.
• Alphas and transparency, is heavier on the rendering.
• Use a professional source for your textures, who update their collections regularly. PBR packs, some of which are free and great, will include those extra maps you need to photoshop blend then into one great texture.
  • This can also work for wet surfaces, so if it rains on your sim and then the sun comes up and lag is no issue, it might results in a unique effect, without having to use an extra prim and transparent textures for the wetness effect. As well as snow, sand, blood etc.

[Fluffy Sharkfin]

46 minutes ago, AmberJoyBliss said:

If you have a normal map or an ao map, bring these into Photoshop, GIMP or photopea.com and but the normal or ao on a layer above the diffuse/albedo map.

• For ao, leave as is and for normal, desaturate it to B/W and then invert the colors.
• Choose softlight, multiply or any of those, even screen and blend it in.
• Go wild here and try all sorts of things, roughness map, specular etc.
• This will give you a single texture with depth.

 

No, just.... no!

You make some good points in your post (and some not so good ones) but blending normal maps with your diffuse in a photo editor to try and simulate lighting and shadow is honestly a terrible idea!

This short video explains exactly what normal maps are, how they work and why using them correctly will greatly improve the visual quality and detail of both mesh/prims.

 

[AmberJoyBliss]

On 11/10/2022 at 3:08 PM, Fluffy Sharkfin said:

You make some good points in your post (and some not so good ones) but blending normal maps with your diffuse in a photo editor to try and simulate lighting and shadow is honestly a terrible idea!

I know very well what normal maps are. Having used the Unreal Engine for a few years, trust me, I know. With Second Life however, as soon as you have just a few avatars in one place and render settings above the lowest, the lag becomes bad. If you have two textures, both with three color channels that is twice the texture memory and also twice the downloading data required to stream in the level. If you have a house with 10 textures and 10 normal maps and they are all at 1024x1024, you now have 20 textures at a few megabytes each.

This can work very well on a gaming PC and high speed internet, which many Second Life users do not have.

Someone said PBR rendering is just around the corner and my prediction is that most creators will just slam things into this "new SL technology" and not understand why the FPS suddenly dropped from 60 to 15.

What we need though, are packaged textures. That way we could have a diffuse, normal map and then roughness and specular on the alpha channel on either of these, or go further and put the entire thing into just one texture. I can't remember atm. exactly how that is done, but there are some ancient tricks still being used to day to lower GPU load.

 

[Quarrel Kukulcan]

2 hours ago, AmberJoyBliss said:

That way we could have a diffuse, normal map and then roughness and specular on the alpha channel on either of these

SL already packs roughness into the normal map alpha channel and skybox mirroring strength into the specular alpha channel.

[OptimoMaximo]

I would very much cheer on an implementation that would use the same texture packing that Unreal uses.

Base color, Emissive (optional) and normal map each as a standalone texture

Ambient Occlusion, Roughness, Metallic and Specular Level packed together into one texture

Height map as a single 1 channel 16 bit texture for Parallax Occlusion, optional.

 

[arton Rotaru]

20 minutes ago, OptimoMaximo said:

I would very much cheer on an implementation that would use the same texture packing that Unreal uses.

Base color, Emissive (optional) and normal map each as a standalone texture

Ambient Occlusion, Roughness, Metallic and Specular Level packed together into one texture

Height map as a single 1 channel 16 bit texture for Parallax Occlusion, optional.

 

The GLTF project does the Unreal map packing. Just no height, or parallax support.
https://releasenotes.secondlife.com/viewer/7.0.0.576331.html

Edited November 12, 2022 by arton Rotaru

[Fluffy Sharkfin]

11 hours ago, AmberJoyBliss said:

I know very well what normal maps are. Having used the Unreal Engine for a few years, trust me, I know.

And yet your proposed method for compositing normal maps with diffuse textures is remarkably crude.  Even the basic information contained in the video I posted provides clues to a more reliable and accurate method for transferring the lighting information to a diffuse texture (not to mention the multiple correct ways in which you could use a normal map to fake lighting on a diffuse texture).

11 hours ago, AmberJoyBliss said:

Someone said PBR rendering is just around the corner

As is the possible removal of forward rendering, which leads me to question why on earth you would try to convince people to go to such lengths to create content which is incompatible with the new features LL are planning to implement.

11 hours ago, AmberJoyBliss said:

What we need though, are packaged textures.

As has already been pointed out, SL has already implemented them (for several years now) and the new PBR materials will have them too.  Regardless of what you claim to know about normal maps you seem quite unfamiliar with the current materials system in SL, perhaps you should refrain from offering advice on how to (mis)use it?

11 hours ago, AmberJoyBliss said:

my prediction is that most creators will just slam things into this "new SL technology"

On this we can agree, which is why it's important to try and educate creators (and residents) on the best way to utilize the new PBR materials system and why advice like "just load your normal map into photoshop and tweak the blending mode until it looks pretty!" is so counter-productive!

[arton Rotaru]

59 minutes ago, Fluffy Sharkfin said:

As is the possible removal of forward rendering

That's a done deal already in the GLTF PBR viewer. 🙂

Edited November 12, 2022 by arton Rotaru

[Fluffy Sharkfin]

2 minutes ago, arton Rotaru said:

That's a done deal already in the GLTF PBR viewer. 🙂

I noticed it was listed under the Resolved Issues section of the release notes but I assumed that LLs original caveat concerning performance still applies and the decision to remove it hadn't been finalised yet.

[arton Rotaru]

A lot of work has been done improving performance as well. The whole texture streaming pipeline has been overhauled for example. 

There will still be some options for potato laptops to disable certain features like reflection probes. Limits on how many local lights will be rendered. 

[Fluffy Sharkfin]

Yeah, I assumed that performance would be high on the priority list and that, since the project is still in early alpha stages and the list of known issues includes "downgraded performance & stability", improvements in that area are still very much ongoing.

My own PC is kind of a potato so I'm curious as to how it will cope but haven't gotten around to testing it as yet.  I'm also very excited about the new reflection probes so may have to go and experiment soon (assuming I can still get onto the beta grid, it's been a while since I tried).

[arton Rotaru]

To be honest, following the project was quite a ride on a rollercoaster. The current viewer has indeed some serious issues. But looking on Bitbucket, they have done so much the past few days that I expect the next viewer to be really enjoiable. Probably early next week is a good time to hop on the train. 

[Fluffy Sharkfin]

Thanks, I'll definitely take a look once some of the more serious issues are resolved.  I'm currently using a mini tower which is limited to a 230w power supply which in turn means a 2GB GT1030 with passive cooling is the best option available so I'm not expecting miracles.  It will certainly be interesting to see how well the new viewer performs on a $100 graphics card in a $250 refurbished office PC. 😅

[ChinRey]

11 hours ago, Fluffy Sharkfin said:

And yet your proposed method for compositing normal maps with diffuse textures is remarkably crude.

AmberJoyBliss' method may be crude but the example she showed us in a previous thread is quite impressive. All those programs that attempt to generate maps from composite textures are rather crude too and it's not always possible to get a good result from them no matter how much you tweak the parameters.

More to the point: there is a need for a way to conflate surface maps into a static texture for several reasons. If AmberJoyBliss' method is too crude, she still deserves a lot of credit for bringing up the topic and if somebody has a better solution, let's hear it!

[Fluffy Sharkfin]

38 minutes ago, ChinRey said:

if somebody has a better solution, let's hear it!

Apply the diffuse and normal map to a flat plane in any 3D app that supports texture baking, set up your desired light sources and bake the additional lighting information to the diffuse texture!

Even isolating the directional lighting information contained in the red and green channels of the normal map and then using it to create masks in order to manually apply highlights and shadows gives you more control over the end results than simply desaturating, inverting the colors and playing with blending modes.

I'm not even sure how you can call "Go wild here and try all sorts of things" a method, but frankly if that's the best solution you can find then far be it from me to stop you, "go wild" and waste as many hours trying it as you like!

[AmberJoyBliss]

16 hours ago, Fluffy Sharkfin said:

As is the possible removal of forward rendering,

I only know the difference from Unreal and the framerate difference is quite high on a low spec machine. By the end of the day, a great looking place that does not Rez and lags, is not as enjoyable as a crude design that has at least 15fps with 20 grey avatars and your friends rezzed. Not to forget the main culprit, ourselves and lack of wardrobe optimisation, but good luck with getting people on board with that.

[AmberJoyBliss]

4 hours ago, Fluffy Sharkfin said:

I'm not even sure how you can call "Go wild here and try all sorts of things" a method

It took me about 15 minutes to get this right on the first go, and no more than 2 hours to establish my own method, but then again, I am not new to this. Diffuse and then AO map on soft light blending alone made a huge difference. I use this on full perm clothes as well to create depth. 

[OptimoMaximo]

23 hours ago, arton Rotaru said:

The GLTF project does the Unreal map packing. Just no height, or parallax support.
https://releasenotes.secondlife.com/viewer/7.0.0.576331.html

I don't see a specification of the packing in that page. However, from the list I saw in previous posts, specular level is missing, as well as height map. Reason why I was saying I would really much cheer on such exact implementation.

[arton Rotaru]

7 hours ago, OptimoMaximo said:

I don't see a specification of the packing in that page. However, from the list I saw in previous posts, specular level is missing, as well as height map. Reason why I was saying I would really much cheer on such exact implementation.

The specification is the GLTF standard, which is pointed out on that page quite obvious. This project is laying the groundwork to implement the GLTF standard into second life. This is the GLTF 2.0 materials standard for this project. Have to start somewhere, right? Once that is done the addition of GLTF extensions such as khr_materials_specular is no big deal.

Edited November 13, 2022 by arton Rotaru

[Fluffy Sharkfin]

11 hours ago, AmberJoyBliss said:

I only know the difference from Unreal and the framerate difference is quite high on a low spec machine. By the end of the day, a great looking place that does not Rez and lags, is not as enjoyable as a crude design that has at least 15fps with 20 grey avatars and your friends rezzed. Not to forget the main culprit, ourselves and lack of wardrobe optimisation, but good luck with getting people on board with that.

I'm not going to deny that SL has major performance issues and a large part of that is simply down to the way people use the platform and a general lack of understanding when it comes to how best to manage resources in order to optimize performance.

I'm also in agreement with you that, without access to proper resources and clear examples of how to use advanced features like materials, the majority of residents are just going to cause more performance issues.

11 hours ago, AmberJoyBliss said:

It took me about 15 minutes to get this right on the first go, and no more than 2 hours to establish my own method, but then again, I am not new to this. Diffuse and then AO map on soft light blending alone made a huge difference. I use this on full perm clothes as well to create depth. 

As you pointed out in your previous thread on the subject...

On 10/15/2022 at 1:37 PM, AmberJoyBliss said:

Update: The easiest way to achieve this effect is with only the diffuse and ao textures.

This is because the AO map contains no directional lighting information and out of all the maps in both the existing and upcoming materials systems it is the easiest to composite since the AO map contains (lack of) lighting information which can be easily interpreted visually.

Of all the other maps the normal map is unique in that, unlike the diffuse/albedo, roughness and metalness maps, the normal map doesn't contain information about the intensity of surface properties, it contains information about the angles of surface details (i.e. geometry) which, while under certain circumstances (seamless tiling textures for example) can be used to fake additional texture detail, is really only useful when correctly converted from tangent space into world space and combined with information about the surfaces to which its applied and the lights being reflected off that surface.

In the case of seamless tiling textures, since they are created by baking geometric detail onto a flat plane where the initial surface normals are all facing the same direction, it's a little easier to manipulate the data contained in the red and green channels of a normal map to produce potentially useful results and with a little creative use of blending modes and adjustment of the levels and curves of each channel you can even isolate specific ranges of surface angles in order to apply directional lighting and shading effects.

However the truth is, like it or not, SL is about to get an update that will cause normal maps to be visible to everyone which means that you'll get far greater benefit from simply using them as intended than you will using even the most advanced techniques to try and fake the same effect on a diffuse texture.

Anyway, I could go into great detail about the various ways normal maps & PBR materials could be used to actually improve performance but I don't want to hijack your thread any further with this tangent ("tangent", get it... like "tangent space"!?... okay, nevermind... ).  As I said previously some of the other points you made were good and I think we've spent enough time focusing on normal maps when there's a ton of other good advice which could be shared in this thread.

For example, it would be nice if we could find a way to educate some of these creators who insist on using ten 1k textures for a single house on the benefits of modular design and trim sheets, they could save themselves some production time and everyone else a whole lot of VRAM.

 

[Marvin Benelli]

To me this thread is very interesting and needs to evolve in the current best practices for texturing in SL. Can we plz store the result in the knowledge base for better persistence and easier to find?

 

[OptimoMaximo]

15 hours ago, arton Rotaru said:

The specification is the GLTF standard, which is pointed out on that page quite obvious. This project is laying the groundwork to implement the GLTF standard into second life. This is the GLTF 2.0 materials standard for this project. Have to start somewhere, right? Once that is done the addition of GLTF extensions such as khr_materials_specular is no big deal.

OK I found it, it's a link contained in that page but... That's not the Unreal Engine standard, nor the exact type of implementation it does, which, quite obvious, is not what I would cheer upon as I already said. Specular Level in Unreal is just one texture, and not two for intensity and color. PBR in general is about consistency of results given a certain lighting setup on material specific features. Being able to tamper how the specular light gets tinted defeats the purpose of pbr...

Oh well...

[arton Rotaru]

12 hours ago, OptimoMaximo said:

OK I found it, it's a link contained in that page but... That's not the Unreal Engine standard, nor the exact type of implementation it does, which, quite obvious, is not what I would cheer upon as I already said. Specular Level in Unreal is just one texture, and not two for intensity and color. PBR in general is about consistency of results given a certain lighting setup on material specific features. Being able to tamper how the specular light gets tinted defeats the purpose of pbr...

Oh well...

I'm sorry that I pointed you to a project that is currently in active development, that I assumed you might be interested in, but not yet familiar with.  How could I dare!

[OptimoMaximo]

4 hours ago, arton Rotaru said:

I'm sorry that I pointed you to a project that is currently in active development, that I assumed you might be interested in, but not yet familiar with.  How could I dare!

Alright Arton, let's bring this back into context, shall we? My initial comment was about what I would cheer upon, that's the exact same type of implementation that Unreal does.

OH so sorry to have missed a link contained in the page you linked to. We'll might have as well given the correct link in the first place, pointing directly to gltf project. How could I dare to expect that, though.

OK then finally, after finding the link in the LL project page, I see the implementation, that is not what I stated I would have cheered upon, came back to the forum and say it, and that's your reply... Yeah...

Well aside from the fact that in productions nobody uses gltf, rather every single studio I know is working towards using USD, I don't see how you (or someone else in some posts above, I can't bother to verify who was it) could claim that the new system uses the same implementation that Unreal does, unless you don't have a clue about what implementation actually that is.

OH well...

Edited November 14, 2022 by OptimoMaximo

[arton Rotaru]

45 minutes ago, OptimoMaximo said:

Alright Arton, let's bring this back into context, shall we? My initial comment was about what I would cheer upon, that's the exact same type of implementation that Unreal does.

OH so sorry to have missed a link contained in the page you linked to. We'll might have as well given the correct link in the first place, pointing directly to gltf project. How could I dare to expect that, though.

OK then finally, after finding the link in the LL project page, I see the implementation, that is not what I stated I would have cheered upon, came back to the forum and say it, and that's your reply... Yeah...

Well aside from the fact that in productions nobody uses gltf, rather every single studio I know is working towards using USD, I don't see how you (or someone else in some posts above, I can't bother to verify who was it) could claim that the new system uses the same implementation that Unreal does, unless you don't have a clue about what implementation actually that is.

OH well...

Alright OptimoMaximo, lets see.

On 11/12/2022 at 1:47 AM, OptimoMaximo said:

I would very much cheer on an implementation that would use the same texture packing that Unreal uses.

Base color, Emissive (optional) and normal map each as a standalone texture

Ambient Occlusion, Roughness, Metallic and Specular Level packed together into one texture

Height map as a single 1 channel 16 bit texture for Parallax Occlusion, optional.

 

Lets check the GLTF , KHR_materials_specular Spec.

Base color, Emissive and normal map each as a standalone texture. ------ Check

Ambient Occlusion -> Red channel ----- Check
Roughness -> Green channel ----- Check
Metallic -> Blue channel ----- Check
SpecularFactor -> Alpha channel ---- Check

Is Specular color a reqirement to stay compliant with the GLTF spec? ------ No ---- Check

Looks like a perfect match to me. All you would have to cheer upon would be the addition of the SpecularFactor if you could be bothered to get involved with this project. But apparently you are not interested.

Did I mention in that one liner post that height maps aren't supported? ---- Oh yes I did.

Such a fuzz about such a non-issue....

 

Edited November 14, 2022 by arton Rotaru