Intro to PBR GLTF Upload for Second life Using the GLTF Packer

[@luckbe]

Putting this here as well because it's been overlooked in the description~! When I say Creative Commons, I am referring specifically to the CC0 public domain license! ♥ A slip of the tongue on my part, and I apologize to anyone who took that to mean that I advocate just downloading whatever you want and using it any way you want. A way better description of Creative Commons and the CC0 (public domain) license: creativecommons.org/public-domain/cc0/ Tl;dr: public domain means no rights reserved, do what you want with it. I still don't advocate reselling these unaltered assets. You may, however, use them in your own work to create your own projects, and you are 100% allowed and encouraged to use them for personal use, retexture your own things, etc. In fact, someone very kindly already uploaded many to the Marketplace for Second Life users, for free, full perm, to help discourage resale: marketplace.secondlife.com/en-US/stores/258238

[@kirayoichi3113]

I'll be sharing this helpful video witj my crafty friends 🧡 Thank you so so much for taking the time to teach us SL residents old/new players 🙏 Youve got yourself a subbie! 👍

[@calaca076]

great video ty ❤

[@dianabrauhn2298]

My FAVORITE thing about this video is your detailed explanation of how to package glad of PBRs. Super helpful!

[@luckbe]

Super glad it helps!

[@amandadench7355]

Thank you for this. I've just started to use PBR textures as the Firestorm viewer is now PBR enabled. I've watched a lot of vids on it and without a doubt yours is the best. 🙂

[@luckbe]

Thank you so much! It means a lot to me to hear that I've helped someone

[@WilmaPhilbin]

I thought PBR materials in SL would be hard to figure out and it might have been if it wasn't for your tutorial. Thank you so much!

[@luckbe]

I am so glad to help! You are very welcome

[@debbiekenny8643]

Oh thank you so much!! I am a total rookie when it comes to this new pbr thing. I do not make mesh, I purchase the full perms mesh and customize the textures, build a hud and resale them no mod no trans. So Now I need to see how to take this information and apply it to my creations.hmmm....thats a challenge!

[@middiasplace3263]

Thank you so much for this video!!

[@luckbe]

I'm so glad it helped!

[@chrissyskydancer]

Thanks alot for showing us!

[@luckbe]

My pleasure!

[@isolte]

This was a very helpful tutorial, thank you, Luck!

[@luckbe]

You are so very welcome! I'm glad it helped!

[@jeffcovello4904]

This video was a perfect SL PBR intro. Helped me a lot. I'm looking for a video showing how to go from Materialize to GLTF packer then up to SL. I can't seem to get it to work right. If anyone has any info on that it would be quite helpful.

[@gihnraishin4019]

Thank you for sharing ♥

[@luckbe]

You are so very welcome!

[@pookab5905]

Thank you for the video , its really hepful

[@luckbe]

You are most welcome!

[@RobotShaz]

thanks for the tutorial video. It is very helpful.

[@luckbe]

You are so very welcome! I'm really glad it helps.

[@devriv8983]

Thank you

[@luckbe]

Welcome!

[@StrangeAssortment]

Fantastic tutorial, it's strange that only gltf textures are free from compression though. I thought I'd be fine uploading normally... guess not lol

[@luckbe]

Yeah, and only normal maps are spared from compression. You could still upload all your diffuse textures separately if you have multiple, and just plug them in to the initial material you uploaded (cheaper not to re-upload the same normals and metal rough, too)

[@topy706]

can you have both pbr textures and the old ones at the same time for people without pbr enabled?

[@bellcitah]

Yes you can! If you pause the tutorial at 12:58 , you can see a dropdown tab saying "PBR Metallic". Clicking on it will show the old texture mode and it will let you apply the old texture system as usual.

[@topy706]

@@bellcitah sure. but my question is if i could run both at the same time. like if the user doesnt have a pbr enabled viewer it uses the legacy textures instead of the pbr system. if you get what i mean.

[@bellcitah]

@@topy706 Yes, you can! It is possible to add both types of materials in the same object. When you have both PBR and legacy textures in the same object, it will show the legacy textures for non-pbr folks as usual. A lot of creators have been doing PBR + legacy fallback textures like that!

[@topy706]

@@bellcitah thats great. i dont think i would necessarily use pbr on everything but metallic objects finally look as such

[@tigerlilysapphire]

This didn't work for me. Worked first time I used it then stopped working, tried a redownload but still the same, what a shame. Will check back for updates. I am on windows 10.

[@Ai.ify8]

Can you please make a tutorial on how we can take our own pbr creations from blender or substance painter and upload them to second life?

[@luckbe]

Unfortunately, I don't use Substance Painter or Blender for this, so I'll have to leave that to another creator! I use 3DCoat, and I did do a video for that already. But if you look up "blender gltf" or "substance painter gltf", those workflows should work great! The awesome thing about pbr is it's no longer second life specific. Any gltf export should work!

[@surig.5410]

Great vid - TY! what do you use for Mac?

[@luckbe]

Unfortunately, I'm not familiar with any similar application for Mac. The GLTF Packer was made specifically for our community by a volunteer because there wasn't already an application like this. You can do this using 3D Design software like Blender or Substance Painter, but the process is more complex and technical.

[@frankz22]

I do not get the "save" button on the packer

[@luckbe]

Double check that it's not just below the bottom of your screen- the packer is built for 1920x1080 size displays or larger and cannot be resized currently. It should have a 'save' and 'clear' button at the bottom above a link to Extrude/Ai'Ai's website and a toggle for 'always on top'. If you don't see any of those, they are probably cut off on your screen. If you have any more questions about the packer itself, please read closely through the documentation on their website.

[@Meoffroad76]

Hello the emission is cut and there are no save and clear visible how can i scroll down to save the texture

[@luckbe]

We have discovered the packer requires a resolution of at least 1920x1080, or the bottom will be cut off. I do not know a workaround, so you would want to reach out to Ai for help with that or to see if she will be making the packer resizeable in the future.

[@War450]

I'm getting into modeling and want to try and make clothes for personal use on SL, is PBR good for clothing items? Or only for like immaterial objects like furniture or environments?

[@luckbe]

Pbr is, imo, the future for all materials. Pbr fabrics are beautiful!

[@War450]

@@luckbe Fast response! Thank you, I'll keep that in mind as I learn to try and incorporate PBR materials into my models, though I'm still a far way away from that I figure it's best to do it right from the start. Thank you for your reply!

[@GwynethLlewelyn]

Wonderful tutorial! I just wanted to add a small note; at about 4:00 or so, you explain very carefully that SL can only use 1K, i.e. 1024x1024 textures, at best (and even those, LL frowns upon... they would love that everybody used 256x256 textures at most :) but, alas, you just can't use those for any serious project these days...). However, you also mention that it's worth to use 2048x2048 textures, do whatever work you need on them, and upload them anyway - since SL will properly reduce them to 1024x1024 anyway. In general, this is good advice - start your work at twice the resolution, and scale it down for the final version - but I would suggest (as of 2024) _not_ to let SL do the downscaling for you. SL is notoriously bad at doing so. AFAIK, LL is still using ancient graphic libraries from the noughts, which aren't really a match to the kind of sophisticated tools we have today (including AI-based re-scaling!). It's far, far, far better to let your graphics software do the scaling down to 1024x1024, as opposed to rely on SL for that. While there is a slight possibility that SL's own rescaling algorithms _might_ get a good result every now and then (as the old saying goes, "even a broken clock gives the right time twice a day"!), it's always better to trust your own graphics software to do the rescaling. This is most certainly true of Adobe Photoshop (if you can afford it), Krita (which is free and has a 20-year track record of producing a reasonably good and sophisticated open-source "clone" of Photoshop), and ImageMagick (if you're a fan of command-line tools 😆). It might also be true for uncountable other tools out there, which I haven't experimented with. There are also plenty online resizing tools out there, each with different results (most are based on ImageMagick anyway); the only one that I've found to be consistently good at doing resizing is TinyPNG. Also: if you have the option to save the resulting file as Targa (.TGA), it _still_ gives slightly better results in SL than uncompressed PNG, in spite of claims to the contrary. LL's original Targa import tools (and subsequent internal conversion to JPEG2000) were far more sophisticated; once they added the option of PNG, whatever tool they use cannot _consistently_ get the same results. It's worth taking that also in account!

[@luckbe]

Hiya! Thank you for your well-thought out and detailed comment. :3 On the subject of texture resizing, I have personally found in my experience, that the viewer itself does actually produce resampling of a quality comparable to what I can do in external software. If there is a difference, these days it's quite negligible, and has resulted in me mostly not bothering unless I was working in 1024 to begin with, or I purposefully want to use a smaller texture size like 512x512. YMMV of course, but since I haven't really seen any difference, I've taken that step out of my workflow. Some tests by other creators even suggest that the compression applied by the viewer & server on upload, produces fewer artifacts when fed a larger texture to begin with vs one at its intended final size. One cool new thing about PBR viewers that you might have missed hearing about, is the introduction of a much more robust and performant mip-mapping solution! That means that textures are only loaded in at their full size when the situation actually calls for it. When you cam away from that 1024x1024 textured earring, the viewer drops the larger sizes and uses the smallest it can to maintain graphical fidelity, based on the size of the object on the screen. This feature is one of the reasons why PBR viewers perform so well, and it is (for me at least) one of the most exciting parts of the development! It's SO effective... LL is considering letting us have 2048x2048 textures at some point in the future, rumor says!

[@GwynethLlewelyn]

Oh! I stand corrected, then. Indeed, all the tests I made was on a Mac (things might be different on Windows) and on the pre-PBR viewers. Hmm. I should try to re-upload some of the more problematic textures and see how well the viewer deals with them; and experiment with 2048x2048 textures as well as 1024x1024 ones. I might be just viewing "old" textures (i.e., uploaded on pre-PBR viewers!), which looked grainy and/or blurred before, and obviously they remain at the same quality I've uploaded them in the past, of course. I mean, there is no magic tool that re-processes textures and makes them "better"; you really need to upload textures instead. Oh well - it's definitely worth a try, and thank you for clarifying this! As to the cool new thing regarding how the renderer is much better at shuffling textures around, depending on what we can see - no, I had absolutely no idea that LL had implemented that! Kudos to them! After all, the whole argument about still sticking to JPEG2000 is that this format allows sending textures in different sizes, starting with the smallest size first (so it loads quickly) - a bit like the early-days "progressive" image downloads would work (nowadays, we have so much bandwidth and such fast machines & browsers that images effectively load "instantly"), but in a much cleverer way. LL's reasoning was simple: if your avatar is moving around (or camming around), it will load a of textures, but all of these might be dropped very quickly, as the user is looking for something to watch at leisure - thus, during that camera travel, textures wouldn't need to be completely downloaded anyway, at least not as a . Once someone places their focus on an object (including avatars, of course!), by, say, hovering the mouse cursor over said object, the renderer would use higher-quality textures, downloading those at need. This sort of reflects how our RL vision actually works: only a tiny fraction of our eyes' viewport is sharp, and the rest is blurred; it's just our brain that tricks us in believe that everything around us is "instantly sharp". Thus, under ideal circumstances, LL's earlier tech, mimicking how the human eye works, seemed like an interesting way of prioritising the texture download queues. The drawback, of course, was that the viewer - at least, AFAIK - once it had fully downloaded a texture, it would remain at its maximum size in texture memory, even if we zoomed out of the object, and the texture would therefore have excess information (which would need to be thrown out of the rendered scene anyway). Since LL capped texture memory at 500 MB (Firestorm generously gave us twice that much), this would very quickly exhaust the available memory, and require constant swapping textures in and out of disk cache, with the results we all know. No wonder, then, that the PBR viewer has so much more performance: it's not only the ability of using the graphic cards' available memory, but also a much cleverer way of just picking the "right" image resolution, depending on the camera distance. That certainly explains a of the "boost" in performance we get these days, and I speak as the owner of a 9½-year-old Mac PowerBook, which features an Nvidia card with only 2 GB of RAM. At the settings - which is what I essentially use all the time, and also what the built-in adjustment wizard recommends - I get gorgeous images, fabulous avatars like I never seen before, and most definitely quite decent performance compared to the olden days (at the cost of not having shadows, for instance, and a less accurate overall lighting model - but still way, way, way better than what I get in pre-PBR viewers!). In fact, those who stick to Firestorm have no clue about how much performance is wasted by Firestorm's now-obsolete engine. Nothing against Firestorm, mind you! When they introduced the dynamic graphics adjustment wizard, performance went up like crazy (it was already quite good, mind you!); I understand that this was a tool which LL was reluctant to introduce for reasons that only LL knows - and their own version, IMHO, is not really so good as what Firestorm has done for theirs, possibly because it's not to aggressive at dynamically changing so many parameters. Nevertheless, Firestorm, for a while, was the leader in innovation and stability, churning out new versions featuring all the latest and greatest patches and bug fixes that LL requires years - if not decades! - to implement. Today - and this will be true at least until March/April 2024 - the reverse is true: it's LL that is driving the technology further and further, giving us not only breathtaking image quality, but also a much-welcomed overall performance boost, on a viewer with short release dates. Aye, it's true that their notion of UI remains stuck to outdated concepts and is, by far, not so advanced - nor intuitive! - as Firestorm's, and I can guess that LL's viewer is also far less stable overall (I cannot really say). Nevertheless, the "arms race" is good for both, and for us, end-users - we get better and better viewers over time, with a substantial improvement in graphics quality performance... Thanks for that little-known feature - it should be given much more credit and recognition, and not thrown in as a minor footnote in the release notes. I have no doubt that, combined with far more texture memory being available, it explains the dramatic increase of raw image processing output from the PBR viewer, possibly at the cost of requiring a much more complex algorithm to "fit" as many images - with different resolutions! - as possible in the graphic card's VRAM. But contemporary hardware is so much faster at running garbage collectors that the required additional complexity is by far outweighed by the dramatic performance increase (maybe it's all done at the GPU level anyway - and does not even require anything running on the CPU). One question remains - are they running the renderer the network driver logic on the same thread? This was the case last time I checked, and accounted for a lot of issues such as getting the renderer "stalled" while it awaited the many textures (and object data!) to be fully downloaded. I'd guess that the current system is now fully multi-threaded to reduce (or even eliminate!) the constant "hiccups" when teleporting to a new region and having to be patient and wait for the (relevant) textures to be loaded the UI is "resp onsive" again...

[@luckbe]

​@@GwynethLlewelyn A couple of articles for you on the subject! This debug setting is available in most TPVs, I'm not sure if it's in the default viewer as well as I don't use it. The tl;dr is that you can also rescale images yourself, and if you use bicubic resampling the results are comparable, but as the results are also similar when using a larger base texture to begin with, I just really don't bother. You can also upload any arbitrary size file, in any viewer, when using the 'bulk upload' option. It bypasses the size check. Of course all textures are still reduced to 1024x1024, and when possible, it's still useful to use smaller textures when applicable, though the new mipmapping algorithm in pbr viewers reduces the importance of this quite significantly. beqsother.blogspot.com/2019/02/compression-depression-tales-of.html nwn.blogs.com/nwn/2019/02/high-res-textures-firestorm-second-life.html Sharpening images before upload is also supposed to help, but again, for the type of texture work that I personally do (furry skins, cosmetics, and garment textures), this really just doesn't seem to matter overly.

[@lis5344]

Do you know, why its just black if i applying it on a mesh?

[@luckbe]

I haven't seen this issue personally, unfortunately, but it could be a matter of an incorrectly set up material. I'd suggest trying again from the beginning in case you missed a step.

[@sweetcat3531]

I click to open GLTF Packer but it just doesn't open, it doesn't do anything, no message, what can I do? This also happens with AudioForSLv2.0 I have Windows 11

[@luckbe]

If you have issues with the GLTF packer itself, I suggest reading through their site and possibly reaching out to the developer!

[@pookab5905]

So with this method do you not need to use an Orm ?

[@luckbe]

You do not, because it CREATES the ORM for you by packing the occlusion, roughness, and metalness textures correctly for you :3

[@megabaustelleneu]

i dont get a gltf file.

[@pookab5905]

For some reason it wont work on my computer so I use materialize and gimp then upload to S/L

[@Cynos_3D]

I would caution anyone wanting to upload CG marketplace materials from sites such as Artstation, etc. The license most likely prohibits resale of the assets as is. This could actually get you in legal trouble if you resell them as full permission materials on SL, especially since LL basically gets free reign on the use of what you've uploaded, be responsible.

[@luckbe]

CC0 licensed materials are public domain, and you can do with them as you please. I strongly advise anyone using other assets to read their license agreements and follow them. In most cases applying them to your own personal items is permissible, and selling items with them applied will generally be permissible on commercially licensed assets, but each license will vary and one should absolutely adhere to it. I do discourage resale of raw pbr assets standalone regardless of source unless one created them themselves, however. Share your source and let the artists who created them get credit and/or sales, please!

[@TheJovialBrit]

I've been a 3D model artist, working with games engines, for 22 years now. Been using SL for 17 years and know all that there is to know about PBR and mesh. A God amongst men.. A God amongst men... 🥲🥲

[@luckbe]

I am genuinely so glad to help. I hope to do some more tutorials in this vein in the future, now that PBR is further along in its development and more mature.

[@Makanamation]

Thank you