Jump to content

Ai Austin

Resident
  • Content Count

    45
  • Joined

  • Last visited

Everything posted by Ai Austin

  1. @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
  2. 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.
  3. @Vir Linden can you point us at the JIRA number? I was not sure which seemed to be related to this issue.
  4. 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.
  5. 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
  6. 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...
  7. 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.
  8. 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.
  9. 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 6.3.0.53155 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.
  10. 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?
  11. I just tried using 6.3.0.53155 across two separate computers and the same sort of thing happens... so its NOT a multiple viewers on same system issue. I must be doing something wrong here! Possibly HUDs that use BoM textures are not meant to make the relevant parts of the avatar transparent, and that only applies to attachments on the avatar iself rather than the HUDs? So the issue might be that the local viewer for the avatar wearing a HUD that includes BoM textures sees the relevant parts of their avatar go transparent, but all other users don't? If anyone has an insight please post a note.. meanwhile I will continue to see if I can pin down what is happening.
  12. Has anyone tried logging in with the new BoM viewer 6.43.0.530155 using two (multiple in other words) viewers on the same desktop at the same time? I think there might be an issue... when I wear a BoM equipped HUD and the underlying classic avatar parts are meant to go transparent. They don't for the OTHER user even after doing a "Rebake Texture". The avatar parts continue to show for the OTHER user. Can someone else try things and see if there might be a glitch before I look at identifying the specifics to make a JIRA issue if necessary? 1. make sure Preferences -> Advanced -> Allow Multiple Vierwers is on. 2. Log on with one avatar - stay classic for now. 3. Log on with a second user and go to same location. 4. Try adding a HUD for avatar one which has BoM faces set. Observe that view changes for avatar one. Observe that the view for avatar two of avatar one does NOT change. Try Texture rebake and observe no change. 5. Try adding a BoM textured attachment or HUD for avatar two. Observe that view changes for avatar two. Observe that the view for avatar one of avatar two does NOT change. Try Texture rebake and observe no change. I am also seeing a second avatar stay as a cloud forever even after avatar rebake in some cases.. possibly related.
  13. Could be the greatest thing since sliced ... (mesh) 🙂 Seriously, it will take some time for adoption, but as one of the developers of the open source Ruth 2.0 and Roth 2.0 mesh bodies its a development that I think will very much simplify the use of mesh bodies with skins, tattoos, undergarments and some tight to body clothing.. reducing the use of onion layers and improving efficiency. BoM texturing can also be offered as one option for mesh texturing and alpha slicing, alongside or within HUD appliers.
  14. Suggestion to allow bake button on textures selection for in world editing as well as worn attachments put on JIRA... https://jira.secondlife.com/browse/BUG-227553
  15. Thanks for that suggestion Digit... I dashed to my computer to try it... but there is a problem… the LL Official Viewer does not have the edit option on right clicking Inventory items. That's a Firestorm viewer feature. And at the moment Firestorm does not support BOM. It would be great if LL could think about some of the use cases where allowing the bakes textures to be applied would be useful. I hit such use cases right away as I reported before and I dare say anyone preparing items for the marketplace that will make use of BOM will find it useful. It would be good if the Firestorm folks allows the bake radio button on their edit too.
  16. Hi Vir, testing the Bakes on Mesh proper release now, having tested out earlier release candidates. Most things work great... but... one thing I was hoping would be fixed before release... Can you enable the bakes radio button to apply one of the BOM textures to faces of objects in normal build mode , not actually attached at the time. Its there for the texture selector in the UI but greyed out. The use case is that you want to prepare items intended for BOM use as attachments and HUDs but create them in world. I have also found that some mesh attached parts like bento heads seem not to be able to be selected when worn, so are difficult to BOM texture unless that is done in world.
  17. Does logging into the Second Life account web page (at https://secondlife.com/my/ ) count as an "activity" on the Tilia account? Or must a check be made on the $US balance explicitly in some way (e.g. by clicking through to https://secondlife.com/my/account/ ) or going even deeper specifically to some Tilia web site? Its one more thing to remember to do annually in any case, and altering the inactive period to a little MORE than one year would be helpful to premium account fee payers using their $US balance to pay annual fees to make this clear to future users anyway.
  18. Hi... could you change the notice period for inactivity to one month rather than 3 days to allow for users travelling or away from their systems for typical vacations, etc. Could you also address the issue for those of us with a US $ balance set up to fund annual premium payments. So payments are only taken from that balance once a year and the exact date can vary a little depending on when @Linden Lab do the billing. Hence it can go over the 12 months of inactivity period. Can you adjust the inactivity period a bit to allow for such a variance, or only record inactivity after, say, a one month notice of such inactivity has been sent?
  19. Just to clarify something... I understand from the @Linden Lab community post that once the Tilia accounts are created they can be accessed with our current SL account user names and passwords. If the Second Life password is subsequently changed does the Tilia account also use the new SL password via authentication through SL, or is it separate after creation?
  20. I appreciate that paying an annual premium fee from a US dollar balance is MEANT to count as activity within 12 months. But can I point out that actually such payments depend on the exact date that Linden Lab processes the payments via Tilia... and experience tells me that this can vary by a few days each year. Hence the payment may be LONGER than 12 months. As an example I have left a US dollar balance that covers a couple of years of premium fees in my account. This ought to continue to be possible without hitting the account inactivity issues. Also, the 3 day notice period for inactive accounts to allow the account holder to take appropriate steps is WAY too short. Anyone travelling or away from their usual place of activity needs longer. Please inform one month in advance of making the account inactive. A small adjustment to the T&C to either make the inactivity period be 13 months (to allow for annual payments with variation of billing) or adding a grace period of one month before inactivity fees are charged after notification has been sent to the account holder.
  21. Patch, does this mean that anyone entering the monitored area gets a warning instantly and then gets ejected if they have not passed through within 15 seconds (or as set)? That might mean that people see a lot of pop up messages as they fly through.. most nice trips are lower than 400m to see the view as you travel along or at sea level its easy to clip the outer edges of houseboat dock areas. I hoped that the security system might have a delay before activating the warning... say a minimum of 10 seconds, then a short delay before the kick off... say a minimum 5 seconds... so same minimum limit of 15 seconds but avoiding lots of pop ups from anyone flying over in under 10 seconds. Maybe in version 2 if that is not already the process? I will test with a second avatar to see how it currently works later today. Thanks.
  22. Excellent improvements. Thanks. I wonder if the home contents pack could include a controlled lighting item(s)... maybe toggled off/soft/bright via the home control panel?
  23. VorpX just shows the Second Life viewer as a 2D cinema screen in front of you, not a 3D/VR scene you can "enter". Use Shift+mouse scroll wheel to zoom the viewer window away from you to see all the menus.
  24. I hope that LL can take another look at their Oculus project Viewer code. There was just something badly wrong with the build that was put out last time. It had all sorts of issues and did not look like the code that was emerging. Even the settings were not connected to the 3D/VR mode of the viewer, yet commits just ahead of the project viewer build release were handling some issues in that. It would be good if LL could try again. Meanwhile CtrlAltStudio was updated to work with Oculus SDK 1.5.0 by David Rowe. CtrlAltStudio is based on a version of Firestorm 4.6.9 from December 2014. Frame rates are good, and perfecty acceptable for exploring Second Life (and OpenSim) regions in VR. Some testing and feedback is in these blog posts... http://blog.inf.ed.ac.uk/atate/2016/07/18/testing-ctrlaltstudio-viewer-1-2-6-43412/ http://blog.inf.ed.ac.uk/atate/2016/07/20/oil-rig-training-environment-in-vr/ http://blog.inf.ed.ac.uk/atate/2016/07/24/roller-coasters-in-vr-using-ctrlaltstudio/
  25. Oh that is very sad. This really was working well with the DK2 and the earlier Oculus SDK and certainly enough for some very impressive and immersive training experiences, small group meetings, etc. I even attended a virtual graduation for distance education students in VR on the Vue regions in Second Life very successfully. You have massive advantages in VR when it comes to the whole linked up social platform and content that is in Second Life. It would be really helpful to know what went wrong with this latest release as the graphics were really low quality even on a really top end rig. Basics like the mouse cursor not showing and all the UI not wired up to the settings panel was just odd. This all worked fine before and surely that's not changed by altering things to move to the later SDK. The 1st July 2016 version seemed to reverse all the inputs given and the progress made by internal and external testing that was taken on board by VoidPointer Linden for the previous release. I hope your team can figure out if this was just a glitch for this release and a quick fix gets you back to the previous state. Don't even think of trying to go for 90fps with distant scenes and all that. We all understand that's not what the aim can or should be.
×
×
  • Create New...