Why I Don't Like PBR

[Porky Gorky]

50 minutes ago, Zalificent Corvinus said:

Hmm, games mod level design, decals, right ?

Thanks! The decal analogy is a good one.

I guess creators who want to sell prefab buildings with realistic AO and higher resolution materials have 2 choices:

1. The decal approach which will optimize material usage but cost extra Li due to all the extra polys.

2. The baking AO directly into materials approach which would optimize Li but would result in a performance cost as it would require many more custom made materials.

Option 1 is the responsible approach to take. I think Option 2 is maybe the easier approach to take and content may look better. I can see a scenario where creators choose option 2 in order to keep the Li count down and pass the performance issue on to the end user.

Maybe there is a balance to be found between the two.

Edited February 21 by Porky Gorky

[Extrude Ragu]

In general you want to be creating trim sheets to get the best out of PBR

I recommend studying this:-

https://www.beyondextent.com/deep-dives/trimsheets

The AO channel should be reserved for material AO, ie AO maps that came with your material, rather than from the object.

In general, triangles are cheap so long as they belong to the same material (as it's a single draw call) but texture memory is not cheap

Under PBR you shouldn't be baking any lighting data including AO.

I recommend checking out Alchemy's new club region, which is fully PBR and demonstrates materials used well

http://maps.secondlife.com/secondlife/Fractal/128/42/12

[Frionil Fang]

11 minutes ago, Porky Gorky said:

1. The decal approach which will optimize material usage but cost extra Li due to all the extra polys.

Has also the downside that SL doesn't actually do "decals", you are just slapping down separate alpha blended geometry which is just asking for blending order problems. I'd imagine a more specialized game engine might have a decal mode that renders in a predictable manner so the bullet holes and blood splatters on a wall are displayed at the wall's depth instead of on top of other alpha blended objects in front of the wall.

[Porky Gorky]

2 hours ago, Frionil Fang said:

Has also the downside that SL doesn't actually do "decals", you are just slapping down separate alpha blended geometry which is just asking for blending order problems

 

Yeah I was calling it the decal approach as it simulates slapping down separate alpha blended geometry, but it’s obviously a poor substitute for actual decals.

Please speak more about the blending order problems?

Thanks

[Porky Gorky]

3 hours ago, Extrude Ragu said:

Under PBR you shouldn't be baking any lighting data including AO.

I recommend checking out Alchemy's new club region, which is fully PBR and demonstrates materials used well

The Alchemy club seems to be a mixture of PBR materials with occlusion shadows, maybe baked from the original model and tiled PBR materials that lack shadows from the environment, These seem to work well in some areas and not so well in others. This opinion was formed after I spent 10 mins moving my camera around specifically looking at shadows though. When I step back from that and look at the build from a holistic perspective it looks great.

When I came back to SL a few weeks ago Alchemy was the first place I visited to see an example of PBR and on that visit I didn’t notice any issues with shadows because I was not looking for any issues. That being said I can see how various elements could be improved by adding shadows on alpha blended polys layered on top if thats an option. I guess the question is do they need to bother as it already looks good?

Edited February 21 by Porky Gorky

[Scylla Rhiadra]

3 hours ago, Frionil Fang said:

just asking for blending order problems

If I understand you -- and it's entirely possible I don't! -- this is something I was thinking: that this approach might create all sorts of alpha glitches in rendering where a backed-in AO, which generally would not need alpha, would not?

[Frionil Fang]

1 hour ago, Porky Gorky said:

Please speak more about the blending order problems?

Alpha blended surfaces are often be displayed in the wrong order. Imagine you had those occlusion-shadows as a "decal" on an object, then a person with alpha blended hair stands in front of it; it's very possible for the hair to be drawn *behind* the occlusion shadow. It's aggravated by the objects overlapping or at least being close to each other in some sense: my neighbor has alpha blended palm trees far outside my window and I can't find an angle where the order goes wrong, but the prefab glass of the window that I covered with a blended effect layer will display the dull grayish glass on top about half the time, and my own enhancement the other half.

It's not a SL fault, alpha blend sorting is a hard problem in general (making the sorting reliable is expensive, and usually not worth it) and if you pay attention you can see it happening in many games. More modern games can do different tricks to mitigate/circumvent the issue, but they're probably not very applicable to SL.

4 minutes ago, Scylla Rhiadra said:

If I understand you -- and it's entirely possible I don't! -- this is something I was thinking: that this approach might create all sorts of alpha glitches in rendering where a backed-in AO, which generally would not need alpha, would not?

If there're no multiple alpha blended surfaces occupying the same pixels on your screen, then there won't be unstable ordering.

[Love Zhaoying]

1 hour ago, Frionil Fang said:

If there're no multiple alpha blended surfaces occupying the same pixels on your screen, then there won't be unstable ordering.

So, next time some doofus proclaims they are "Alpha!!!", I can reply:

"Yes, you do appear to be composed of multiple blended surfaces with unstable ordering."

 

[Scylla Rhiadra]

1 hour ago, Frionil Fang said:

If there're no multiple alpha blended surfaces occupying the same pixels on your screen, then there won't be unstable ordering.

Right, but this is my point, as you describe in your response to Porky: if one is using separate mesh pieces with alpha to produce the AO effect on the walls, rather than baking it in to the diffuse texture, you're going to increase the chance of misordered alpha rendering -- i.e., glitches.

I get that these are small pieces, generally only covering the corners and edges of the wall, but I can still see it causing problems.

I guess I don't see a way around this, unless there was some way to change the AO map of PBR materials without the computer having to render the entire material as a "new" texture. In other words, if it re-used (that is, didn't have to reload) the diffuse, norm, and emission maps on faces that employed different AO maps, thus saving the rendering costs of the other three components.

But I assume that is not how this works? Changing the AO in a PBR material essentially makes it a brand new texture that needs to be loaded separately?

[Frionil Fang]

1 hour ago, Scylla Rhiadra said:

Right, but this is my point, as you describe in your response to Porky: if one is using separate mesh pieces with alpha to produce the AO effect on the walls, rather than baking it in to the diffuse texture, you're going to increase the chance of misordered alpha rendering -- i.e., glitches.

Yes, that was my gist, sorry I'm a bit extra verbally challenged today.

1 hour ago, Scylla Rhiadra said:

But I assume that is not how this works? Changing the AO in a PBR material essentially makes it a brand new texture that needs to be loaded separately?

The unfortunate design here is that the ambient occlusion is packed into the same texture as roughness and metallic, with no way of separately tiling/offsetting the different packed parts, so they're permanently stuck to each other. You're not changing only one without having to create a new texture asset. Personally I'd love to have a separate scale/offset for each of the packed ORM channels, but probably not going to be a thing.

[Porky Gorky]

1 hour ago, Scylla Rhiadra said:

I get that these are small pieces, generally only covering the corners and edges of the wall, but I can still see it causing problems.

Maybe it could be considered an acceptable problem to live with, given the shortcomings of the platform and the problem discussed in the last few pages regarding shadowed tiled materials. SL must have many thousands of examples already where multiple alpha blended surfaces are visible to people, @Frionil Fang mentioned two examples just looking out the window of their prefab. It’s certainly worth testing in a building I think to see how prevalent the blending order problem is.

Edited February 21 by Porky Gorky

[Scylla Rhiadra]

7 minutes ago, Frionil Fang said:

Yes, that was my gist, sorry I'm a bit extra verbally challenged today.

The unfortunate design here is that the ambient occlusion is packed into the same texture as roughness and metallic, with no way of separately tiling/offsetting the different packed parts, so they're permanently stuck to each other. You're not changing only one without having to create a new texture asset. Personally I'd love to have a separate scale/offset for each of the packed ORM channels, but probably not going to be a thing.

RIGHT! I'd forgotten this. Hence ORM . . . although, in theory, instead of exchanging just the AO map, you could create separate ORM maps for each instance with the AO component swapped out as needed. But, again, I guess that's still creating an entirely new asset to be loaded?

2 minutes ago, Porky Gorky said:

Maybe it could be considered an acceptable problem to live with, given the shortcomings of the platform and the problem discussed in the last few pages regarding shadowed tiled materials. SL must have many thousands of examples already where multiple alpha blended surfaces are visible to people, @Frionil Fang mentioned two examples just looking out the window of their prefab. It’s certainly worth testing in a prefab I think to see how prevalent the blending order problem is.

Yeah, this is true: alpha glitching ain't going anywhere, and is already something of an issue in even commonplace contexts.

[Porky Gorky]

On 2/20/2024 at 1:50 PM, Qie Niangao said:

So I went to Scarlett Creative to inspect the two PBR models I found (search aided by highlighting reflection probes 😛 )

BTW, learning that you could highlight reflection probes is a top tip! I never realised you could do that. I highlighted the probes at the Alchemy club and was really surprised by how many they used. Spheres within spheres, all the spheres overlapping to some degree. It was a sight to behold and very interesting.

[Qie Niangao]

49 minutes ago, Frionil Fang said:

The unfortunate design here is that the ambient occlusion is packed into the same texture as roughness and metallic, with no way of separately tiling/offsetting the different packed parts, so they're permanently stuck to each other. You're not changing only one without having to create a new texture asset. Personally I'd love to have a separate scale/offset for each of the packed ORM channels, but probably not going to be a thing.

Yeah, I think this whole discussion of needing AO at object-scale in addition to material-scale is heresy, but it's already in the suggestion box:

Quote

PBR - Allow separate upload and/or change of AO

Rheia Silvercloud

Currently, the Ambient Occlusion is stored in the red channel of a single texture containing AO, Roughness, and Metalness. While this is useful for saving file space, there are times when one might utilize the elsewise-same PBR Material across multiple models, with the sole difference being the AO for the model. Currently, this necessitates every Material to be separately uploaded when it is elsewise fundamentally unchanged.

Adding the ability to upload a new AO map and separating it from the Material would increase the versatility of the Material while simultaneously lessening the chance of file bloat server-side and inventory-wise.

As a possible solution, perhaps the AO can instead be vertex-encoded, a method used by many programs currently, and available in most if not all 3D software, most notable of course being Blender.

January 25, 2024

If SSAO did what I thought it was supposed to, it would do all this automatically. As it stands, I'm really not sure it's doing anything at all.

[Charlotte Bartlett]

On 2/21/2024 at 8:29 PM, Porky Gorky said:

Hi @Charlotte Bartlett thanks for the encouragement / pep talk. It's genuinly appreciated.

I’ve been testing sphere probes in non rectangular interior spaces and I am achieving more acceptable results. Spheres seem to allow some level of overlapping. Do you know how overlapping probes work in SL with regards to their importance? We can’t assign importance values to probes. Unity documentation says “By default, Unity calculates the intersection between the reflective object’s bounding box and each of the overlapping probe zones; the zone which has the largest volume of intersection with the bounding box is the one that will be selected.” Do you know if this how it works in SL?

Also I seem to be using a lot more probes, do you know how costly probes are on performance? I’ve used many and haven't noticed any performance loss, but I am using a workstation built for rendering, so not your average rig.

Thanks

There are not any specific docs for SL to glean this info from, so it is a case of try and test for performance. Using the advanced menu for data as needed.  In overlap from memory yes I would search on the old JIRA and also some past posts as I believe similar questions were raised. 

I have been using 3-4 probes for a larger house but again best practice will come from testing and evolving as we all get more used to PBR and limitations.

I have been away for a few weeks so haven’t progressed further but am looking to do more testing during March 

 

 

[Porky Gorky]

8 hours ago, Charlotte Bartlett said:

I have been using 3-4 probes for a larger house but again best practice will come from testing and evolving as we all get more used to PBR and limitations.

Since realising I could highlight reflection probes I've been more nosey, looking at them in public spaces as well as poking around a few build platforms looking at WIP’s. I’ve seen a broad spectrum of usage ranging from single box probes around an entire building to numerous overlapping spheres as well as more considered usage focusing on individual spaces. Not much consistency yet in the usage I’ve seen. 

I’ve also noticed some weird effects with moving objects, for example a door opening inside the probe would cause the probe to recalculate the reflection capture which had a notable effect on the materials within the probe for just for a few seconds. Has anyone else noticed this?

[Qie Niangao]

7 minutes ago, Porky Gorky said:

I’ve also noticed some weird effects with moving objects, for example a door opening inside the probe would cause the probe to recalculate the reflection capture which had a notable effect on the materials within the probe for just for a few seconds. Has anyone else noticed this?

That's interesting, but I haven't played enough with moving objects to notice that yet.

What I have noticed is the (same?) several second re-lighting of the scene when the cam moves enough to confuse the viewer, even if it doesn't actually move outside the reflection probe volume. I've seen this when 1) selecting an object, 2) entering the Appearance editor, or 3) sitting anywhere near the boundaries of the reflection probe. (This is why I've avoided having multiple reflection probe volumes in builds, but that may be superstitious: I can't say I've actually tested whether overlapping probes trigger the same recalculations.)

[Charlotte Bartlett]

28 minutes ago, Porky Gorky said:

Since realising I could highlight reflection probes I've been more nosey, looking at them in public spaces as well as poking around a few build platforms looking at WIP’s. I’ve seen a broad spectrum of usage ranging from single box probes around an entire building to numerous overlapping spheres as well as more considered usage focusing on individual spaces. Not much consistency yet in the usage I’ve seen. 

I’ve also noticed some weird effects with moving objects, for example a door opening inside the probe would cause the probe to recalculate the reflection capture which had a notable effect on the materials within the probe for just for a few seconds. Has anyone else noticed this?

I had an open Jira on the overlaps.  It can def go wonky.  They fixed the issues when rezzed at height.  But I still see some weirdness eg when a probe almost “fails” and will stop reacting.

 

i recommend anything you see raise (now not on Jira, but the new system) if not already raised. 

[Nagachief Darkstone]

On 2/21/2024 at 11:17 AM, Porky Gorky said:

The Alchemy club seems to be a mixture of PBR materials with occlusion shadows, maybe baked from the original model and tiled PBR materials that lack shadows from the environment, These seem to work well in some areas and not so well in others. This opinion was formed after I spent 10 mins moving my camera around specifically looking at shadows though. When I step back from that and look at the build from a holistic perspective it looks great.

When I came back to SL a few weeks ago Alchemy was the first place I visited to see an example of PBR and on that visit I didn’t notice any issues with shadows because I was not looking for any issues. That being said I can see how various elements could be improved by adding shadows on alpha blended polys layered on top if thats an option. I guess the question is do they need to bother as it already looks good?

I appreciate the feedback, there's a few areas that do likely look a bit strange from resolution, such as the areas near the windows where the interior parts of the front wall are bespoke textures, rather than tiled. This hopefully will be improved when 2k textures come around do the sheer size of the object.

I'm hoping at some point we get a good solution to mixing tiled and bespoke mesh textures since there are probably some areas that indeed don't work quite well due to how AO and SSAO behaves. Since both effects are removed by direct light, it can look wildly different depending if shadows are on or not. I know glTF scenes can support multiple UV maps, so that could be a solution in the future.

[Porky Gorky]

I was enticed back into SL by the introduction of PBR and have spent a few hours a week over the last month being a PBR tourist. Alchemy is definitely one of the best examples of usage I've seen. Well done on being a PBR pioneer!

10 hours ago, Nagachief Darkstone said:

This hopefully will be improved when 2k textures come around do the sheer size of the object.

Are LL actually planning to introduce 2k textures or are you just wishful thinking? I think I remember right at the start of SL that we could import 2k textures but LL put a stop to that  for obvious reasons. 

Maybe it’s finally time for 2k to shine. (apologies for the bad PBR pun).

[Extrude Ragu]

2 minutes ago, Porky Gorky said:

Are LL actually planning to introduce 2k textures or are you just wishful thinking? I think I remember right at the start of SL that we could import 2k textures but LL put a stop to that  for obvious reasons.

They have been experimenting with it. There's a test viewer and stress testing currently going on on the beta grid.

It is also on their public roadmap ( https://feedback.secondlife.com )

[Zalificent Corvinus]

24 minutes ago, Extrude Ragu said:

They have been experimenting with it. There's a test viewer and stress testing currently going on on the beta grid.

It is also on their public roadmap ( https://feedback.secondlife.com )

But, most of the more informed comments are NEGATIVE, and apparently LL haven't seen a "use case" for that nonsense that justifies the time , effort, and cost of rolling that out across the whole grid.

 

One of the early comments typifies the "2k/4k stupidity" mindset.

"But why would you upload different textures for different faces, when you can have a single massive texture with everything on it as little islands."

Why?

Because with that style of UV mapping, it's COMMON for 40-60% of the texture map to be OUTSIDE the UV islands and basically wasted, loads in to VRAM, never gets used.

Because "island mapping" some wooden window frames to a 1/16th of a 2k texture gives a LOWER TEXEL density than having it "tiled mapped" to it's own 512 texture.

And of course, somebody will say "but... but... 1 massive texture for everything means one draw calls, not 8" despite the fact that draw calls are NOT the big lag maker in SL

 

Fun Fact.

The over use of 4k textures in Skyrim mods, has become so common, that somebody released a "modding tool" to DOWNSIZE all those 4k dds files to lower resolution, so peoples copies of Skyrim don't run like molasses in wintertime with massive problems with loading content.

 

Why the hell would I want 4k texture on say an armchair, that takes up about 1/10th of a 1920x1080 screen, when that 4k texture is basically 8 times the size of the whole screen. That is NOT "more efficient".

 

[Extrude Ragu]

A lot of creators don't know how to effectively use trim sheets. Actually, this is something I didn't learn about as a novice creator for a very long time. Second Life has a bit of an education issue. Ironically, what ultimately 'taught' me was when Second Life got its internal discord and creators had somewhere to talk and learn from each other there.

Also, because the Second Life renderer up until recently sucked balls at reflections, creators couldn't use trim sheets because of the need to bake lighting information which PBR removes. If we can get people to learn how to use trim sheets, we up texel density massively.

4 minutes ago, Zalificent Corvinus said:

And of course, somebody will say "but... but... 1 massive texture for everything means one draw calls, not 8" despite the fact that draw calls are NOT the big lag maker in SL

This I don't agree on - Draw calls are a big lag maker in Second Life. Especially when it comes to mesh bodies. Beq Janus the lead firestorm developer made several blog posts with detailed information/research about this.

Performance with 2k textures is obviously a concern. I have bought it up myself. The answer I usually get is that because images in Second Life are JPEG2000 encoded, they will use the discard level feature to basically do texture LOD's and you'd rarely have the full resolution texture in memory. Whether this really works is yet to be seen, I just hope they're right..

 

[Zalificent Corvinus]

15 minutes ago, Extrude Ragu said:

The answer I usually get is that because images in Second Life are JPEG2000 encoded, they will use the discard level feature to basically do texture LOD's and you'd rarely have the full resolution texture in memory. Whether this really works is yet to be seen, I just hope they're right..

Dream on, JPEG2k "progressive previews" are NOT "mip maps" or "LODS". They are "previews of the full size image with more aggressive jpeg lossy compression.

 

It's a piece of fail-tech designed a quarter century ago, that was obsolete before they launched it.

original jpegs had an option for "interlacing", so when you downloaded a web page on a 9.6k modem it would load every other line of pixels, so you could hopefully see if you wanted the WHOLE 640x480 image before you'd wasted more than a min or two downloading the first1/3rd of the file.

Almost nobody used that mode.

for jpeg2k, the committee decided to "improve" that unused feature with progressive previews, with extra lossy compression.

Basically, you get sent a super sh*te version of the texture, then a sh*te version, then a bad version, and THEN the actual texture. That's why slow loading textures look as bad as they do in-world when loading or reloading. It's why "texture thrashing" makes objects super blurry, then blurry, then sharp, then supper blurry again and again and again.

 

It's HARD to think of a WORSE file format they could have chosen for SL's texture storage and transmission

 

Couple the bad file format with massive textures, and for a lot, probably most, SL users, the texture thrashing will go off the charts

 

32 minutes ago, Extrude Ragu said:

This I don't agree on - Draw calls are a big lag maker in Second Life. Especially when it comes to mesh bodies. Beq Janus the lead firestorm developer made several blog posts with detailed information/research about this

As I recall, most of the "mesh bodies cause lag" info they posted showed it was the RIGGING that caused most lag, not "draw calls". Processing all the joint bounding boxes etc.

 

34 minutes ago, Extrude Ragu said:

A lot of creators don't know how to effectively use trim sheets.

Realistically, "trim sheets", island UV Mapping is inherently inefficient.

But speaking of "cretin creators", 2 days ago I was downsizing the 4k textures on a skyrim mod, before installing it.

ALL the textures were 4k .dds files, with 13 levels of mip mapping, 22mb file sizes, including one called simply "black".

This "black" texture, a 22mb file, was a plain black flood-fill, with no alpha layer, just "use this to paint some SMALL detail black", like the BACK of a belt buckle.

 

SL's new "Pretentious Bloody Rubbish" theoretically uses 4 textures per gltf materials preset. How much do you want to bet "cretin creators" will upload 2k or 4k textures in all 4 slots, even when at least one of those will be blank black flood-fills?

 

There's an old expression.

 

"Never give a monkey the keys to a banana plantation."

[Porky Gorky]

3 hours ago, Zalificent Corvinus said:

"Never give a monkey the keys to a banana plantation."

Hasn't this already happened though? Just yesterday I was in a store looking at a PBR chair, basic wooden frame, with a fabric seat. The creator was using 8 materials on the chair, so that would be 32 x 1k textures which is absurd.

If 2k textures are rolled out maybe LL could offest the impact by heavily reducing the number of surfaces/faces available on each piece of new mesh.

Edited February 27 by Porky Gorky