also pbr- random notes on scripting/image handling details. separate textures of gltf imported DO each also get imported as actual textures (this is great, you may need them).

those images are uploaded as they are in the gltf- this makes a difference for normals. MOST OF THE TIME it doesn't matter, but the i'm going to assume jpeg2k part of the import mulches textures a little bit including normals, when you have a very picky (mostly a super clean one) normal, this shows on straight upload, but it keeps the correct details on

gltf imported normal (you can import it in gltf, then use the superior detail version in the gloss/enviro workflow as well).

if your normal is that picky though, you'd better be VERY DAMN CAREFUL on creating it, seams get reeeeal problematic if they aren't just right to begin with (any of your bleed that gets picked up must be perfect- by design bleed isn't perfect, it's just a guess- so keep an eye out for problem spots)

gltf appears to support 16 bit color (png does, tga does not- i have other functional issues using pngs in SL so i have not done testing on how/if the expanded color depth works on textures. it's almost never anything you can see), which in very VERY touchy normal cases may be useful, however the compression will take care of that almost always first.

(if your norms are that picky, you probably already have run into the issue that you'd better cut all of your quads into tris before you even bake it- that gets you into issues well before it gets to stray pixels.)

UUIDs of materials change on save. this is unlike a) textures which can't really be altered and thus have no reason to change UUID and b ) notecards which you aren't using this way because they are some slow bullshit to read but can be edited post distribution of a scripted object to update that object without sending anything out.

this means that you can save a material, send the uuid to a script, edit the material and then no longer have access to the material in the script outside of a scripted object. it also means you can't save over a material in use in a scripted object and fuck up everything using that script down the road. (which you can with a notecard)

materials want to be full material assets, and for the entire asset to be replaced. materials can have each part of them edited on the fly in a script. a lot of variables beyond just filling each texture slot are saved in that asset, but not all so you may have to run multi part llsetprimitiveparams to set what you think of as the "same" part.

gltf files on your computer appear to be xml that points to the separate image assets. a) they are text files, and text files can be edited: you can select which images of a gltf file to remove on import so if you need just one part (like the normal), or you can go into the gltf file with a text editor and remove it before it gets to SL's importer.

b ) you must keep ALL of the files together to keep that data functional on your computer. do not just move the .gltf file to a different directory and expect it to work. (this is only for your own archiving or moving before import, it doesn't matter once it's in SL)

if you are assembling your own metal/roughness image, it is ambient occlusion in the red channel (note: AO only shows in shadow here which was news to me, the "ambient" part means it only does ambient), roughness in green channel (which still feels inverted to me though it makes technical sense), metalness in blue channel. you CAN set layers in photoshop

layers properties to only effect singular channels, so you can build in a folder and continue to easily edit each channel with more layers etc.

antialiasing still halo fucks with you at on/off, as 0 and 1 are entirely different things- just as with gloss.