Jump to content

Ai Austin

  • Posts

  • Joined

  • Last visited

Everything posted by Ai Austin

  1. The massive space taken up by the SL logo and search area title at tge top if the entry page is problematic... as the actual content is way down and scrolling is likely to be needed... especially if, as by default, you view the search web pages inside the viewer. The left hand three tabs take up relatively too much space too. Thus means that the denser elements of content to the right hand columns are sometimes clipped, e.g. the maturity rating description is likely to be clipped when viewed inside the viewer.
  2. Whoaaa.. I have just installed with the UI change... the removal of the ability to right click on your own avatar and see the Friends and Groups option is not helpful. Its buried too deep. Even to select and activate a group now you have to have the menu showing, and know to go to the Communicate menu and bring up the Friends or Groups. Can this be discussed, and hopefully the options put back on the right click your own avatar menu? And perhaps for uniformity with right click on other avatars, return the View Profile (for your own profile). I logged this "New Feature" suggestion as https://jira.secondlife.com/browse/BUG-230894
  3. We don't really want landmarks created to appear by default in "Favorites" I would think. Its preselected and the landmark even appears in the Favourites bar until you manually select OFF that,. A better default would be the TOP level "Landmarks" and then people can star of select Favorites if they wish. Most would leave the default and would quickly end up with everything in Favorites otherwise. Not good.
  4. As Theresa said the Bakes button has appeared for texture selection for avatar attached items since BoM was introduced. Since the Love Me Render release candidate this bake button also appears to allow items rezzed in world to be textured with BoM so when worn they have BoM applied. The Love Me Render #4 release candidate became the default viewer a week or two ago. Its now a drop down menu chooser rather than a radio button. See https://jira.secondlife.com/browse/BUG-227553 Firestorm EEP Beta incorporated the Love Me Render #4 code from LL from Firestorm 6.4.10.
  5. @Maitimo glad your mesh content still works. Ruth2's (unrigged) mesh elf ears still work with BoM too. But I hope the restriction to not allow BoM texturing on prim (and scuplt perhaps) parts in attachments is removed so it behaves as it was up to 6.4.6. Current viewers do not work for me with flexi-prim tails 🙂 I can live without allowing BoM texturing on HUD elements, though would like to know the reason for that restriction. @Kyle Lindenpointed us at a JIRA entry but I don't have permission to view it to see the rationale. https://jira.secondlife.com/browse/DRTVWR-501
  6. The fix is in LL viewers from 6.4.7 up to current version. Its also already in Firestorm Beta test versions now including the current FS6.4.10 EEP Beta Wulfie. And rightly the FS team have said we should address this via the SL JIRA and Linden Lab as we can't have rendering look different between the official viewer and Firestorm or it would just not work for everyone and make BoM content rendering consistent.
  7. Thanks @Dan Linden I will tidy up the description. Sorry for the edits I made in a stream yesterday, they all appeared as separate items in the issue timeline! .I could not work out a better way to ask for the JIRA to be reopened. Also @Gabriele Graves and @Maitimo I just tried to attach a simple mesh item, which I THINK is unrigged.. and it DOES texture correctly when set to a BoM face. So you may be in luck with your mesh item attachments even though the fix back in May seemed to require isRiggedMesh()
  8. Hopefully @Dan Lindenwill reopen BUG-229508 so people can relate their use cases there. Dan... the issue is not about the temporary server bakes issue. https://jira.secondlife.com/browse/BUG-229508
  9. Current released Firestorm is 6.3.9 and an EEP Beta version 6.4.5.. and those will work fine as they both predate the change made at LL viewer 6.4.7. But that change is now incorporated into the version being prepared as the next Firestorm release. The change was incorporated into Firestorm in May 2020. See https://vcs.firestormviewer.org/phoenix-firestorm/changeset/b654330f51dea8d5b6b3afd0440a10b2f623bcdd
  10. Check it out in the latest viewer Gabriele. I did not test unrigged mesh attachments myself. I was testing prim attachments, and while investigating attached also a simple sculpt to show that was also was not now being rendered with BoM. The related classic avatar parts though are still hidden if you texture any face of any attached part even if its a prim, a sculpt or in a HUD. So things are in a bit of a broken state at the moment anyway. I was just going on the code change which indicates the change was from allowing anything attached to the avatar to a tighter restriction that for BoM to be rendered on a face of an attachment that the item must be attached to an avatar && rigged mesh && not be a HUD.
  11. I would say it should allow that if the creator or user wishes to apply a BoM texture to those. Elf Ears for example might be attached and not necessarily be rigged mesh.
  12. Yes Tazzie, things works fine when you mix classic clothing, tattoos, normal worn attachments that are normally textured (mesh or prim based) and even alpha masks (so long as you select a suitable alpha mode for the mesh that is BoM textured). My use case though is different... its an attachment that I want to apply a BoM texture to (in the case of the tail a part of the lower texture) but where the attachment includes a prim element rather than all the attachment being all (rigged) mesh. In fact anything attached to the avatar that you want rendered with a BoM texture that is not (rigged) mesh is now rendered with the colour fall back texture.. this includes prims, sculpties, and I assume unrigged mesh.. though I did not test that. My tail case includes a cylinder and a cone shaped flexi-prim.
  13. Here is an image of a flexi-prim tail attached to an avatar showing the skin tone from BoM as it worked in LL viewers up to 6.4.6 (and Firestorm viewers up to 6.4.5) alongside how it now appears with the (yellow LOWER) fall back coloured texture when seen in LL viewers from 6.4.7 to the current versions (6.4.10) and Firestorm 6.4.10 Beta.
  14. Can I raise an Issue on the types of attached items that can render with a BoM texture... I appreciate this may have been discussed back in April and May 2020 and have been looking back to try to find the reasons that @Vir Lindenmade a change between 6.4.6 and 6.4.7 to limit the BoM textures to be applied to only rigged mesh worn on the avatar and to exclude HUDs. Previously the behaviour was just to check it was an avatar attached item of any type. The change means that prim (and sculpt) parts of worn attachments no longer are rendered with BoM and fall back to the coloured backup textures. The actual examples I was retrying after a gap in use was a flexi-prim tail that was meant to be textured the same as the worn skin. It worked great up to 6.4.6 but not in the latest viewer, and going back I found the change was introduced in 6.4.7. The actual line of code is inindra/newview/llviewerobject.cpp ... if (avatar && isRiggedMesh() && !isHUDAttachment()) prevIously this was just if (avatar) There are two parts to this... whether BoM should work on prim items that may be attached to an avatar (whether as part of a multi-element attachment or separately) and whether BoM should work on HUD elements.. Unless there is some overriding reason to disallow BoM applying to prim parts of worn attachments it would be good to remove the && isRiggedMesh() element of the change. That would allow things like flexi-prims to receive BoM textures as they did up to 6.4.6. https://jira.secondlife.com/browse/BUG-229508 I filed a JIRA on this. [But at the moment @Dan Linden closed it thinking it is related to the temporary bakes issue in the servers. Maybe @April Linden , if she spots this, can ask him to reopen it as I can't find a way to ask Dan to do that except via editing the issue description!] The exclusion of the HUD from receiving BoM texturing may be for a good reason. Good to know what it was though if so. I have used that previous capability to create a HUD control panel/visual feedback of what the BoM currently applied looks like. No big deal if that functionality is lost, but it would be worth knowing why. Bakes on Mesh really is a VERY powerful capability and its usage can go far beyond it initial intended usage. I hope this limitation in usage can be (partially) reversed to make available useful features going forward. P.S, as the change also made its way into Firestorm in its EEP Beta test version this also restricts Firestorm which worked fine in the current released 6.3.9 and 6.4.5 EEP beta, but the LL code change after 6.4.6 made its way into the currently being prepared 6.4.10 EEP Beta, so that too now restricts what can be seen in both SL and OpenSim. https://jira.firestormviewer.org/browse/FIRE-30418
  15. Its also being reported in Firestorm 6.4.10 Beta as a major bug. But as noted in this Forum, the issue is actually one of the LL core code "fixes" from the Love Me Render #4 changes. The LL folks attempted to fix an issue and have made things worse for many use vases for people trying to use EEP. See https://jira.firestormviewer.org/browse/FIRE-30410
  16. @Vir Linden I wonder if you can get whoever looks after the Wiki to update the UUIDs for the BAKES channels/fallback textures to the up to date ones... and add the extra 5 added BAKES? https://wiki.secondlife.com/wiki/Internal_Textures
  17. More UUIDs and fallback textures would be a bit of overkill don't you think? Better if it can be done to have a (one bit boolean) flag (default "on" for compatibility) to let you turn off alpha hiding of the relevant part.
  18. @Vir Linden can you point us at the JIRA number? I was not sure which seemed to be related to this issue.
  19. A good example of something that would benefit from @Henri Beauchamp 's suggestion of allowing a tick box to disable making the underlying body parts transparent when applying an attachment with a BoM texture would be elf ears. You might want them to have the HEAD bake texture applied, but leave the head visible.
  20. If default was that the tick box was ticked and all existing items had it set to on, but a user could edit/texture any face to set it off for new items and change previous previous items, then Henri’s idea would be compatible with all existing content too
  21. Just to be clear Vir, I was not expecting a HUD itself to be seen by other avatars at all. Its the side effect of the HUD on the visual appearance of the avatar I was talking about. As other users can see something very different to what you see yourself. And a HUD that is rigged would just be weird... mind you I have seen mesh body HUDs that have the head attached! You add the HUD and the rigged head part plonks on top of your body... take it off and you are decapitated! First thing I do, if I have modify permissions, is unlink the head from the HUD part. The HUD I was using to expose these issues is simply 11 linked prims textured to monitor the BAKES texture contents...
  22. I think the best route would be the fix of “avatar-hiding is not done for HUD-attached non-rigged elements of objects which have BoM textures set”. I can see many useful use cases for HUDs that show the current bakes textures in HUDs that can also apply textures directly on Mesh body parts, and HUDs that are used for monitoring purposes. I have already fixed several long term issues with basic body parts such s the classic feet, some skin issues, etc by seeing they were not baking as I expected.
  23. Just to be clear Vir, I was not expecting a HUD itself to be seen by other avatars at all. Its the side effect of the HUD on the visual appearance of the avatar I was talking about. As other users can see something very different to what you see yourself.
  24. Sean.. try this. Remove all BoM attachments and mesh body parts and any alpha... stay as classic avatar underlying that. Now add your HUD... and observe that in your viewer the part(s) of your avatar corresponding to those BoM textures you have included in the HUD will be hidden. BUT, look at the avatar via a second avatar login, whether on same system or another system it turned out) and for that second avatars view the avatar parts that are hidden still show. Vir, I understand what you say, but the difference in behaviour I think is a bug. unless its just my setup. Can you gve me the JIRA URL fir the report you mentioned? As well as in the official viewer, the same thing happens with test builds of Firestorm 6.3.1 with BoM included. Which of course us probably the sane code merged in.
  25. A HUD that may have parts BoM textured when attached to a HUD position will locally make the relevant parts of the underlying classic avatar transparent in the view of the avatar that attached such a HUD, but that does NOT show to other users. Its probably a viewer bug to have this difference in behaviour?
  • Create New...