-
Posts
103 -
Joined
-
Last visited
Content Type
Forums
Blogs
Knowledge Base
Everything posted by Kristy Aurelia
-
Any idea what would happen, if I went into the viewer source code and change it to be lossless for all textures? Would the asset server then reject the upload for being lossless?
-
Normal maps when uploaded as part of a PBR material do use lossless compression, everything else uses lossy compression. I might be wrong, but I think: it is the viewer that does the downsampling, but I do not know whether the viewer or the asset server does the encoding to Jpeg2000. So you'll get some loss of quality from downsampling, and some from compression. But as I mentioned before, I think, something like Photoshop or Gimp might be able to downscale at better quality than the viewer, so then SL upload procedure only incurs compression quality loss.
-
Sure, if your source material is larger, but I'm also sure you can downscale images to 1k yourself with a better algorithm/software than what SL viewer uses, resulting in a better native 1k upload.
-
Uhm... yes. That's exactly what 2k texture support does. It increases the downscaling maximum from 1024x to 2048x, and it does render them at that resolution too (when appropriate, as in - it won't use 2k for piercings of someone standing on the other side of the room). Uploading 2k textures without rendering wouldn't make much sense... And as mentioned in post above, currently only very specific viewers/versions support it. If you use older viewer than those mentioned, it will still downscale uploads to 1024 and will only download 1k versions of the already uploaded 2k textures.
-
It is coming in the next update (within weeks hopefully), there is a test version of the LL viewer that should be able to do it ( https://releasenotes.secondlife.com/viewer/7.1.8.9103842320.html ), but Alchemy merged those changes into their main release already.
-
That's already available. However only latest version of Alchemy viewer can upload them at the moment. Other viewers - coming soon™.
-
That's partially because the stuff you're looking at doesn't have PBR materials applied. Also, those surfaces are not very reflective either. The actual differences will depend on materials, the most drastic difference will be between on metals. Results on fabrics or dry dirt/sand will be a lot more subtle.
-
Cute stuff always catches my eye - especially lolita/gothic dresses, for example: Altair, Hime*Dream, Rosier. After an item passes a 'cute'/'my style' factor, come the technical requirements: has to be mod, as others mentioned - has to fit well (bonus points for fitting perfectly without any alphas), big penalty for baked reflections, big bonus for PBR. Quite a lot of items tend to fail on the baked reflection front... I'd rather have somewhat dull lights (pre-PBR) from the room I am in, rather than some static picture of a photo studio or Mediterranean village, and with PBR - real reflections look great without any baking. However... release of LaraX made things more complicated... now I'm also looking for stuff that either supports Lara5 and LaraX or Lara5 and Reborn as managing multiple bodies is annoying, and I don't want to discard huge part of my wardrobe... but it feels like I'll have to at some point and Reborn is looking like the body that's going to take over.
-
In this specific example, primary use case for why people would want mod, is to be able to link multiple trees together, and potentially save LI. Or maybe use the tree in a rezzer system so they can swap it out for a different tree in summer/winter. Or resize it, or have multiple slightly different sized trees for a more natural forest. And to delete the resizer script if there is one, there's not need to have a script if 99.9% if sits idle.
-
is there a built-in ao in the official viewer?
Kristy Aurelia replied to CaerolleClaudel's topic in Second Life Viewer
If you want built in AO in the official viewer - vote on this Canny https://feedback.secondlife.com/feature-requests/p/build-in-ao-like-in-firestorm LL review and prioritise feature requests based on how many people are interested in them. -
I was really happy when I found out that there even is an event themed on 'Mod stuff'... I can't remember the event name right now... but then I was sad as it was mostly furry stuff... maybe I should grow a tail... I've recently updated the one item I've made for SL, and because I don't know how to make textures myself, I did my best to UV map the mesh so tiled textures look good enough, and I've used some CC0 PBR materials, which I've included in the box, as well as the raw textures and I did provide the link too -> https://marketplace.secondlife.com/p/AmbientCG-PBR-Material-Megapack/25595913
-
I don't really know. I would imagine it allows creators to do various things based on current texture being set and so on. (in cases where there is no worries about textures being used by someone else). It also could be because of the way the overrides are changed, as the script can only read/write it as a whole set - including texture, UV scale/offsets, rotation, tint colour, alpha mode and so on. There currently are no LSL functions to set the various properties individually, but that is being worked on for the future.
-
I'm not sure... I've gathered all my knowledge from multiple sources over time. The main product I'm making is scripts, and I want to make sure that when people put my scripts into their mod stuff, my scripts are not going to accidentally override textures and so on Some of the places/ways I've learned about all of this: https://wiki.secondlife.com/wiki/GLTF_Overrides - A notable line in there is "A glTF override is a collection of changes applied on top of a glTF material asset" asset being "material object" I referred to. https://feedback.secondlife.com/scripting-bugs/p/pbr-colour-data-is-lost-when-setting-pbr-overrides - An issue I ran into when trying to change only alpha, and was unable to read the colour value from the material. There also was a JIRA, but the page is no longer available, where I asked about how to safely change PBR properties without losing existing textures, that did cover some details of how the overrides work. When I was writing my 'Mod vs No-Mod' argument doc https://docs.google.com/document/d/1Kosnx9oPTZMrMixtH35zvKUhDC2XlVt2HKZ-uH7csOM I've had someone send me bunch of basic materials with the mix of permissions, so I've tested to see what can and cannot be changed or viewed. The relevant parts would be: [mod perms] For PBR Materials: Allows - Textures to be replaced/removed. Allows - Settings to be adjusted. Does not allow - Pulling out texture UUIDs of applied textures. This might be viewer dependent (I’ve used Firestorm Beta 7.1.7), no-mod materials preview the textures when clicked, while mod materials bring up the texture picker dialog. So technically, one could screenshot the texture preview on a no-mod material, but not on a mod material. Does not allow - Transferring modified materials if part of the textures or settings were changed. If I remember any other sources, I'll edit this post.
-
That depends on how the material is applied. PBR actually makes them even more secure. Just like Linden Lab told you - script can only read/change the overrides. To put it in layman's terms: PBR materials are applied in two "layers" - Material object as a whole, as in the inventory material item you have. And Material Overrides - the part that scripts can read/write and also the part you change when editing PBR properties on item itself. So what that means, if you make a material item in your inventory, set the texture in it, and apply the material to the object - you'll be only setting the Material, which is the PRIM_RENDER_MATERIAL field. It is a single UUID that points to the whole material item. Scripts cannot read any individual parts of that. From script point of view that field is a single UUID, which usually will return blank, as I believe it follows the old rules of permissions (I think Maestro got it the wrong way around in the reply? I asked to clarify), so unless the object is full perm, or the material object is in the inventory, it will just give you blank value. In any case, if you do provide a material in the inventory of a prim, or along side your item. Opening the material in the viewer, does not allow reading UUIDs of the textures the material contains either. Also materials on their own have permissions too. When you edit the materials on the item itself, or via scripts, you're editing 'Material Overrides' or the 2nd layer... which as the name suggests, overrides whatever values are provided by the base material. So for example, if your material has tint colour set to green, and you edit it on the item to red, the override will be set to red and the viewer will load the material with the original green colour, and swap it to red. Scripts can read/write this new red value. But, if the red was never set, attempting to read the original tint colour will give you white and not green (which is the default for not-set/not-available), same rule applies to texture UUIDs or other parts that are set within the material object. This also allows the scripts to set a custom texture in the overrides and then set it to blank without losing the original texture, if the original texture is part of the "Material Object" layer. Edit: And to elaborate on the Maestro's answer. If you make materials as overrides, you can save them to your inventory as an object later, which might be easier in some cases than editing just the inventory item directly. After you save the material as an object, you can then clear any PBR materials and just apply the Material Object directly, which will leave all overrides blank. Also, clearing the material beforehand should not be required, as the action of applying material object should also clear any overrides. The same is true if a Material Object field is changed by the scripts - the overrides will be cleared. So in short, if you want to be safe, have your HUD change the PRIM_RENDER_MATERIAL with a different material object, rather than changing individual material override fields. Edit 2: Textures do have some extra weirdness when being applied into materials too - for example, if you have a copy/mod/no-trans texture, you can apply it as a legacy texture, but you cannot set it to any of the material fields. Only full-perm textures can be set. Which is a bit odd... but I think it has something to do with setting overrides and then saving them out as materials - it stops people converting no-trans textures into full perm materials I think... or something like that... I'm not too sure, but it is still worth being aware of that there are some differences.
-
So if you think the avatar looks like: a child (17 or younger) then react with a like, for an adult (18 and over) use thanks, and use confused if you can't tell based on physical appearance alone. Please don't respond to individual posts with written comments just use the reaction icons.
- 150 replies
-
- 67
-
Also, I think I caught up with main points of the thread now. Composition vs Build Kit is an interesting one, I personally would prefer building kits. Also I don't mind paying extra for mod. That might be different to other people. I guess this would depend on your business model, but I can see the same argument from Singles vs Fat Packs be applicable here - you could set 2-3-4 however many cheaper prefab no-mod homes, but also sell a kit that is mod, more expensive, but also designed to be used as a kit. So if I want to move a sofa to the other side of the room, it doesn't leave an ugly baked shadow on a wall. Also, I have quite a few items that are 3-4 years old, a lot of them I can DIY PBR myself, it would be a lot of work for the creators to go through their entire catalogue and update all their creations. Mod is what enables me to do it myself. From a creators point of view - I have only released one item, and nearing towards completion of my second one. I am completely talentless when it comes to making textures, so I've UV mapped the meshes in such a way that it looks decent with a tiled texture and I can use a CC0 licensed texture, which I am also including in the package, and if people want to change it - they can. In terms of creative vision, I have seen some people fail at resizing it... So I've facepalmed... and I will be adding a resizer script in an update. I also gave them some tips on how to resize it properly. But yes, it did annoy me a bit that they made it look worse, but if they're happy with it, I'm happy too. I've also seen someone remove a few parts completely to achieve a different look which made me think "Huh, that works I guess, I didn't think of that". Also, in the circles I hang around, quite a few items we use have show/hide parts based on states. Old scripts do not support PBR, so me and my friends who wanted to PBR-ify those items, couldn't.... except... I made a helper script, that does make legacy and PBR alpha synchronize, which works okay for now, until LL do implement a proper fix. And we can just stick that script into any mod item we want, and mod PBR to our wishes, with old scripts functioning as intended.
-
This actually raises the point against people stealing textures, if someone acquires a UUID for a texture that only works on a specific mesh, they still need to buy the mesh. One of my main use cases is removing textures with ugly baked reflections and highlights as PBR now provides actual real reflections (where people setup probes that is, we really need more sim owners to update their sims, but that's for a completely different topic.). (I really hate baked reflections/highlights, but that's also a different topic) I'm hoping this is not too NSFW... but here's an example of how I updated one of my outfits with PBR: Before, with baked in white blob specular reflection: After just plain PBR material: Also especially with PBR, I wish creators provided normal maps as well, so I could DIY PBR stuff properly. Since it is the normal map that holds most of the detail. This is one of the reasons I've mention metals specifically in the google doc, as most metals tend to be smooth and do not require a normal map. Also quite a lot of objects work really well with tiled textures like buildings, or any objects that have large enough details define by vertexes rather than specific normal - a flat floor in a house is really easy to swap from tiled tile texture to tiled wood texture and so on. I have also updated my doc to mention what no-mod does to PBR materials, since I originally wrote it before PBR was released. And I've also added that I believe, and based on my friend circle: vast majority of yes-mod supporters are concerned about mod clothes, furniture, houses. And we understand that there are things like vendor systems, various game related HUDs and so on, do need to be no-mod.
-
I've made a google doc a while back listing all the reasons why stuff should be mod (at least all the ones I could think of, I'm sure there's more): https://docs.google.com/document/d/1Kosnx9oPTZMrMixtH35zvKUhDC2XlVt2HKZ-uH7csOM Since I've only noticed this thread now, I'll have to go through it later and add a few more points about stuff I noticed while skimming through it. Edit: Also worth noting, I only buy mod stuff, with very very rare exceptions, such as a body, or something that does need tampering prevention - like a board game or a gift card. And my own creations are mod-mesh, no-mod scripts and the scripts are even designed to not use specific link IDs, to allow people to do whatever they like with them.
-
my balls aren't working correctly
Kristy Aurelia replied to HorizontalEight's topic in LSL Scripting
Just FIY, sensors now scan up to 32 items: https://releasenotes.secondlife.com/simulator/2024-03-18.8333615376.html