arton Rotaru

Check out the UV-Tiles (aka UDIMs) workflow. https://helpx.adobe.com/substance-3d-painter/features/uv-tiles.html Once you are done painting, assign a second material to one of the UV tiles.

Sure there is everything alright with the normal map on the PBR version? The face piece looks kinda odd compared to the other one.

All 3 of those images have the Orange-Teal color grading which pretty much every Hollywood movie has since the past 10 years. That's why they look so pleasing to the eye.

Looks like you became a victim of these obscure bugs. https://jira.secondlife.com/browse/BUG-11333 https://jira.secondlife.com/browse/BUG-8715

Me neither! But if someone would point a gun at me to give an answer, I'd say it almost looks like as the reflection probes were broken, not there at all, in that previous screenshots. There are a few bugs left in the viewer where reflection probes stop working.

No the AO map does not have to be inverted. The AO map in the glTF PBR material will only be shown in areas that are actually occluded from light. When you place your inverted AO map object in shadows, it's likely rendering completely black. So that won't be the solution. The sheen is likely coming from the sky of the midday environment. We don't like it that much as well, so we are hoping some tweaks will be made to the default midday environment to lessen the effect. See. https://jira.secondlife.com/browse/BUG-234789

The blue is indeed coming from the new midday environment in SL compared to the recommended HDRi. See: https://jira.secondlife.com/browse/BUG-234789 Further than that there are no point lights in painter like the sun in SL. The tonemapping in SL is a mix of 2/3 ACES and 1/3 Linear. Where in Painter it is 100% ACES tonemapping when enabled. This has been done to prevent legacy content with Blinn-Phong materials from being too saturated and contrasty due to the ACES tonemapping. Then there is the autoexposure in SL which isn't present in SP either. We are trying to nudge the developer to make some tweaks to the default SL midday environment to get the sky more inline with the recommended HDRi. Best to add your concerns on the Jira. Because it's super unrealistic to have the sun dead on like the legacy midday. Indeed, any aspect of this new look of SL requires some time to get used to.

Glow is not part of the glTF Spec. Hence it got removed from functioning on PBR materials altogether. The creator community was quite unhappy about that, though. So we voiced that and the developer was willing to enable it, but not as part of the glTF PBR material. Hence, it's also not on the PBR material editor itself. PRIM_GLOW can be used as usual with PBR materials, though. It's using the emissive map of the pbr material as a "mask". Hence, the emissive map and the emissive tint color of the PBR material have to be something other than black to make glow work.

Oh and here is another thing. We are most likely going to see a lot of foliage (possibly other stuff) taking advantage of the Double Sided feature of a PBR material. Can't fake that with a Blinn-Phong fallback texture. So such stuff would render broken anyways on non PBR viewers.

Right, the wording is ambiguous. I think if the mobile client doesn't do PBR materials in a world full of PBR materials it's a failed product. On Desktop my stance is like this: PBR is gridwide already, the default viewer is PBR. TPV will follow soon with non beta versions. So it's everybodys own fault to not pick a capable viewer. ¯\_(ツ)_/¯

Last info I remember to the question; "if the mobile client will support PBR materials?", is a reply of a Linden that was something as follows. "We expect the mobile client to support the features of the desktop client." (Don't quote me on the exact wording. pls! Nor do I remember where I read that information.) Although that isn't a "clear" answer, but enough for me to certainly skip blinn-phong materials in any future build I do.

The glTF Specification supports only JPG and PNG. So for lossless textures we are going to use PNG files for PBR materials. I never was a fan of PNG either, always worked with TGA, but it is what it is. What can be done is to pack the targa textures into the metallic-roughness map yourself in an image editor. red channel = occlusion, green channel = roughness, blue channel = metallic. upload the images into SL as textures and drop those into a new material that can be created in-world as well.

Thinking of it, the viewer does strip alpha channels when the alpha channel is just plain white all over. Something to check for as well.

It does mean that the texture doesn't have an alpha channel. I'd double check my export settings.

Maybe https://aiaicapta.in/gltf-packer/ something you are looking for? You just insert the texture maps and it will make a glTF file. (I haven't used the packer myself, but it is made by a Second Life resident, and what I hear is that it does work great.)

I did not read the entire thread, nor can I claim I fully understood what you were trying to do here, but it could be that you are seeing what is explained here under the Resolution and Texel Density section of the page. https://creativecloud.adobe.com/learn/substance-3d-designer/web/the-pbr-guide-part-2?locale=en

When downsizing a 1024x1024 to 256x256 you are going from 1048576 pixels of color information to 65536 pixels. That are almost 1 million pixels less. So it's not surprising that it can destroy textures severely, especially if it has small-ish patterns,

Set Transparency to 1% on that face and see if that does help.

I'm not sure if I'm allowed to post the link to the GitHub repo of the required viewer in here. But you can find it on Discord in #scripting. The viewer itself can be downloaded from the wiki page I linked above. Unfortunately the game_control server version has been removed from Aditi entirely to make room for an upcoming server release QA. It will be back next week within a new server version.

If you check who has written those wiki pages, it's mostly a few Residents and Cosmic Linden, who is one of the Devs of the project, so far. 🤷‍♂️

Yes, this won't make it in this initial release, as the code of the GLTF viewer is basically frozen by now.

What we can conclude at least, is that there is much more that can be done with PBR materials and LSL than one would expect at first glance.

Object Copy/Mod/NoTrans PBR asset No-Mod/Copy/Trans Could be send to an Alt and the Alt was able to edit the PBR materials overrides. I'm not sure what to think of this, and I will stop right here. I HATE dealing with these permissions stuff.

PBR will set the values stored in the original asset by setting the params to an empty string. You don't need to llGet those params beforehand.

I was unable to drop an object on an Alt when the PBR asset applied to a face is no mod.