arton Rotaru

I would consider overrides as overrides, regardless of they are being set by script or manually.

I just tried it, it looks like you can't drop a texture as an override on PBR materials if it isn't full perms. The texture has to be full perms.

Yes, that is the problem of perms and getting the texture UUIDs.

Overrides are what makes this flexible without creating a new asset everytime someone does change a param of the PBR material on an object.

Checkout the link I have posted in the reply above yours.

It's true that there is no way to get the params of a PBR asset by script. What can be get are the overrides of a PBR material. Setting params to an empty string will set the values of the original PBR asset. So you either get an empty string for a base color texture, which will set the original assets texture, or the UUID of the override texture. If perms does allow this. https://wiki.secondlife.com/wiki/GLTF_Overrides

Right, it just is an event that makes controller inputs available to LSL. It doesn't add universal game controller support.

I don't think it's magically, but it is what you would expect on how a game pad would work. And that's what it does. Works pretty well so far. My only gripe with it currently is that it drops inputs on region border crossings. And sometimes button presses don't make it through reliably. Anyhow, It will revolutionize vehicle handling in Second Life, that's for sure. https://wiki.secondlife.com/w/index.php?title=LSL_Game_Control_Beta https://wiki.secondlife.com/wiki/Game_control

Yeah IDK, as I said, I didn't watch it. 😇 As a side note, I used to choose the .glb to upload the materials in the beginning as well. But I switched over to the .gltf file. The difference is, the glb has the textures embedded while the gltf is just referencing the textures. So if I want to manipulate individual maps of a material, lets say I want just the ORM (Occlusion, Roughness, Metallic) map of a smaller size than the other maps, I do that in Photoshop, and just save the texture to the same name/location it already has. By uploading the gltf it will use this resized texture instead of the original embedded one in the glb.

I did not watch the video. I just took a look at it's chapter titles. Could be that it "just" covers how to fix the material if it's having an undesired setting? Adding a comment that it can lead to confusion as shown is a good idea, though!

This is where I remove the Opacity channel from the material.

I see Opaque when I have exported the glTF without opacity. Otherwise when the base color does have an alpha channel, it defaults to Blend. IMO that is the correct behavior. It's just the same as with what we do with textures, don't have transparency, don't upload a texture with an alpha channel.

Hm, I don't have that problem. I just remove the opacity channel from the material under Texture Set Settings in Painter so it doesn't export a RGBA base color.

Could be that your mesh has negative scaling. Always Apply Rotation & Scale to the mesh in Blender before exporting.

Here is a GIF that demonstrates how darkness is done with the recent PBR builds. Note the Ambiance setting I change from 0.0 to 0.5 to 1.0. (And sorry Henry for derailing your topic. But now that you took it to the Jira it is in good hands. My count on the Jira for the GLTF viewer is 29 by now.)

Darkness inside a room is now achieved by setting the Ambiance option of a manual reflection probe >= 1.0. This will 100% override the ambient color of the Windlight. From 0 to 1 it's a mix of the ambient color and the refelction probe. So, darkness is an opt-in feature now.

Existing content will remain the same (well, almost) as it always has been. It's only that everybody will see blinn-phong material maps aka legacy Spec-Gloss and PBR materials. There is no option to disable material maps anymore. If your content is diffuse map only, it will only show the diffuse map as it always did. (well, almost)

While with the PBR viewer we now have a synced workflow using MikkT for normal maps, there are 2 things to keep in mind as well. 1) Normal maps that are uploaded as a GLTF file will use lossless compression. Hence we don't suffer from lossy compression artifacts on those. 2) To achieve the synced workflow the mesh will have to be uploaded using the GLTF viewer on a GLTF region. in the past, meshes were stored internally packed into a unit cube. Tangents are generated on the fly in the viewer, but they were generated from that internal unit cube scale. Means, if the mesh doesn't have a cubic shape to begin with, the tangents were generated wrongly. To correct that a change to the mesh asset format was necessary to store the original scale along with the mesh. This leads to slightly higher land impact because more data is stored.

You could add a paint layer on top of the stack. Set it's blending mode to Passthrough. Add a Color Correct, HSL, Levels whatever filter to it.

It went like this. PBR materials were implemented. To fix some issues with PBR materials, ACES Tonemapping was added. People started to complain that now legacy content is too saturated. Developer did his magic and split legacy content and PBR into 2 groups. Where only the pixels that had PBR Materials were rendered with ACES and the rest with Linear. Worked quite well, but turned out to be too performance heavy. So that got removed again and the tonemapping options menu got removed as well, because the Lab wants us to create PBR materials that are calibrated to the ACES tonemapping. Inbetween the Auto-Exposure got implemented as well, which was/is another area of concern on it's own. The problem that we are facing now is, any attempt to bring legacy content back to the current (old) looks (without introducing performance hogs), will render PBR materials that have been made with ACES in mind desaturated. I don't know FS, but all I can say is, it took me roughly a week to get used to the ACES tonemapping look. When it got removed for legacy content it took me also roughly a week to get used to the old look again. And same procedure when it went fully ACES again. Same with the Auto-Exposure, took a while to get used to it. It's not the end of the world, people just need some extended period of time to get used to it. If there is an easy way out, like disabling ACES, people will stick with that forever, because they don't need to get used to something new. I can't confirm that this is a general view there. This are actually very few people who might be among the verbally loudest out there.

IIRC Blender required the Primstar 1.0 scripts from Domino Marama. Old Blender versions can be downloaded from the Blender archives. However, IDK if Primstar 1.0 is still available.

I don't, as I never used prim composer myself. But it's all in that previous thread. Checkout the mediafire link in this post: (As Heb Drexler explains further down, it is possible to download 1 file at a time without a premium account.)

The answer to this will still be the same as what is posted here.

I love this movie. Now that you posted this, I read in another article that the outside views of the structure are just matte paintings. Never realized that while watching the movie. For sure, I'm going to watch it yet another time tonight.

Tyiler did that actually. It's status has been set to Accepted, but no further response as of yet. https://jira.secondlife.com/browse/BUG-233843