Jump to content

Nalates Urriah

Advisor
  • Posts

    8,853
  • Joined

  • Last visited

Everything posted by Nalates Urriah

  1. I disagree... it is possible. It gets complicated and ambiguous if one attempts to circumscribe the real subject. Which in these forums leads to arguments from and misunderstanding by those with a weak attachment to reality. SL to some degree is an escape from reality. So the less attached seem to like it here.
  2. No... it is not a legit question. It is a fantasy detached from reality. So you have any idea how much money Amazon makes from sex and porn?
  3. This is a shot for viewer DoF. Cinn's hair and the monarchs would be a difficult separation. I find even AI selection in a case like has problems when colors are similar. If I wanted a high quality editable image I would use freeze frame and take color and depth captures. Then do the depth in PS with Filter->Lens Blur. I would probably tweak the depth map to increase contrast turning Cinn and you into 100% black.
  4. Yes. Everything in SL is calaculated. The calculations happen on the server and client sides to distribute the work. Plus the work is highly optimized to reduce duplication and minimize the data needing to be transferred. Consider animations. Animations are localized to the viewer. The viewer moves the arms and legs doing all the calculations required. That movement is not transmitted to others. The amount of information needed for legs, arms, hands, fingers, tails, wings, face, and boobie bounce would overwhelm the system. Only which animation is being played is sent to others, well to the server which then tells everyone else which animation to use for your avatar. If you could see everyone's screen at the same time, you would see that we are not all in perfect sync. Each viewer, at any given instant, is showing a frame of the animation playing on your avatar depending on how long the animation has played on that specific viewer. The when is controlled by when they or you came into the region and when you entered their field of view. While control-S (Firestorm) will sync all animations in your viewer it does not affect what other viewers show. SL avatars have a collision... capsule... an oblong cylinder with rounded ends. Animations do NOT move the collision capsule. This is why avatars do not collide on the dance floor. To appear more realistic and avoid griefing, collisions with avatars and things, like walking on the floor, are calculated on the server side using the Havok collision engine, which is optimized for the type of math used for coordinate intersections. The viewer sends position/movement info and the Havok server decides if that is possible and sends the results to all people in the area. Thus our avatars do not walk through walls. If there is lag, we may see an avatar walk into a wall and then bounce back. Every viewer must render the entire world and all the avatars in it plus keep track of what all the avatars are doing. So the viewer advises the servers of what you are doing. The server aggregates all that info and advises all other viewers about what each avatar is doing. Each avatar in a region adds exponentially to the amount of data needing to be transmitted. For a time OpenSim and Microsoft were working to optimize the math and data flow to get more avatars into a region without lag. Last I looked, which has been years, they were up to 150+ per region. I suspect patents are why we have not seen that tech applied to SL. Desktop computing power is growing but we are nowhere near what is needed for a truly realistic virtual world where clothes and hair do not pass through the body or clothes are realistic and a full skirt can swish around our legs and not distort. Mobile devices are orders of magnitude behind our desktops. If you were to do all the calculations to render a single frame of SL on an abacus... it would take centuries. And yet it is the data transmission that is bottlenecking us.
  5. Add to your list of "how to Check" the wireframe mode of the viewer. Ctrl-Shift-R switches the viewer in and out of wireframe mode. You can see the triangles of an object. Look at your Classic avatar body while in wireframe, no mesh body or mesh clothes. Use the triangle density of the classic avatar you see as the density of a HIGHLY optimized mesh character for SL. Well-optimized stuff will be similar. Higher density is not necessarily worse. Also, graphics card manufacturers have been optimizing their hardware for decades. Polygons per second is now an old performance measure because the count was getting bizarre. How many 100 billion polygons do you want to render in a second? Is your mesh body 8,000 polygons or 80,000? And how much difference will it make in render time? I doubt you can measure it. It is too short a time. The download time of a vertex list is minimal. The time to load a defuse map (basic color texture), normal map (bump/3D surface map), and specular map (shiny) is significant. The memory used by those textures is significant. So it is by far the textures that drag down render time. But neither of these are issues in crossings or for server loads. However, the number of items and the number of scripts greatly impact crossings. Thus we are held to 38 attachments. We are pushed to keep a low script weight, 3 MB per avatar is considered reasonable. If you fly or sail fewer scripts and attachments are significantly better. The number of avatars and the number of items they are wearing affect the region server performance because of the data load. Much of the data is avatar movement information. I am not sure standing still lessens the load. Seems like it would but I suspect the code sends a continuous stream of position data. But, maybe they did some optimization. I do know that it is easier to cam through an event than to walk through one. You can optimize your experience by lowering the number of Non-Imposter Avatars your viewer renders, lowering your draw distance, and Max Particle count. Draw distance has an effect on the regions. Less draw distance means fewer regions need to send you information and the region you are in often sends less information to your viewer. Consider if you use 128m DD while standing at the edge of a region, only half the region (256x256m) you are in needs to send you information, and the same for the nearby region. So, 2 servers send about 1 region of data. Using a 1024m DD you have 9 regions sending you 9 regions of information. You are creating some serious lag and it is lag that affects everyone, not just you. Reducing lag and increasing performance in SL gets W A Y technical and complicated.
  6. I tend to store all my SL images on my computer. The ones I think are worth editing in Photoshop often make it to the SL Form in different places; landscapes, Tasteful Nudes, SL today, Avatar Looks today... I mostly avoid posting the same image in multiple places. I like finding the people from SL posting on Flickr. And there is the group FOCUS Art Magazine which ties Flickr and SL together. If I like the edited results of images and think they are interesting I'll post them on Flickr. If I think they are sexy enough I'll post them on Slushe.com. However, SL images are definitely looked down on at Slushe. Those posting there are talented and perverse.
  7. £50... 😲 ...well... MY suggestion would be ME!
  8. The change is the upgrade to the SL System to add PBR rendering. The Lab's PBR is in the early stages of development. Firestorm has an Alpha version of their viewer that uses PBR. You can talk to the Firestorm peps and join the Alpha-level testing team. They have an Apha viewer available. Beq just announced it in this section of the forum. You can learn how to change your water or... OR... help the FS and Linden devs fix the viewers to handle your water as it should.
  9. This is a common problem known as Texture Thrashing. You can search the net for help with Second Life texture thrashing. Specifiy your viewer brand for more specific help. The cause is your video card running out of video memory and discarding textures to render other textures. So a texture render starts blurry and progresses to sharp and clear and then reverts to blurry and re-renders repeating the process again and again. There are workarounds. One can reduce Draw Distance, remove HUDs not in use, turn off thumbnails in chat, restart the viewer, and pay attention to what you are wearing and your ACI/ARC. Depending on your computer's graphics system you may be able to make tweaks to get more video memory (VRAM). When using the CPU's built-in graphics one can assign system memory for use as VRAM. Which is not possible with a dedicated graphics card. One can add to system memory relatively easily. If you turn around, like 180 - stop a minute - turn another 180, and find textures previously rendered have turned gray, try increasing your viewer cache size to the max. The setting is in Preferences.
  10. Hummmm...... 🤔 NiranV has the same idea, make a better user interface. You can see his efforts in Black Dragon. Henri likes the old v1 user interface. You can see that in use in Cool VL Viewer. The Firestorm Viewer has multiple user interfaces a user can switch between. The SL Viewer has a UI designed by professionals trained in UI design. They have done considerable A-B testing with the SL Viewer. The Lindens think the SL Viewer is best for the new user. Debatable. The SL Viewer and third-party viewers have very similar features built into the viewer's foundation code. The major difference is in the UI. Firestorm makes many more features available in their version. Apparently, users prefer the more complex viewer as about 75% of users use the Firestorm Viewer. Your idea of editing the UI XML files is not something a newbie is going to do. Those making viewers already work with the XML files. I don't expect anyone to pick up your idea of editing and publishing a modified viewer. So, if you think it is a good idea, you'll need to do it yourself.
  11. @Mariocroft94 The Preview or Beta Grid is where we test things, as you have been told. It would help if you read up on using the Beta Grid in the SL Wiki. You'll find that you must enable Grid Selection in the Preferences panel (Advanced tab->Show Grid Selection at Login checkbox) to get a new option on your login screen. Then you'll have the option to log into either the main (aka Agni) grid or the beta/preview (Aditi) grid. If you use a third-party viewer, other non-Linden grids are available. As the Lindens test things they will copy parts of the main grid over to the preview grid. If you follow Linden's development UGs you'll know when that is happening. While there are permanent places in Aditi other places appear and disappear. You can run multiple copies of the viewer (Advanced->Allow Multiple Viewers) and be logged into the main and beta grids at the same time. That is the only time your avatar can be in different places at the same time. The main and preview grids use the same ID and password. The first time you log into the Beta grid you likely won't get in. You'll have to file a support ticket and give it a couple of days. They will set up your account on the preview grid and copy your inventory over from the main grid. Your beta grid inventory will update after you log into the preview grid. typically within 24 hours. If it doesn't update after a couple of logins and 48 hours, something has hung and support will have to help. I find I don't need most of my inventory in Aditi. So, I don't pay much attention to whether it updates or not. Your Beta grid inventory NEVER copies back to the main grid. There is a cost to upload to the Preview Grid... sort of. The Lindens give you free money for use on the Preview Grid... ONLY on the preview grid. You pay for uploads with free money that gets replaced if you use it all up. The Firestorm Viewer allows some preview features for use on the main grid. You are the only one that can see what is being previewed. But it is handy and for some scenarios, it saves logging into the preview grid. Get involved with Builder's Brewery, a group and location in SL, to learn more about building in SL.
  12. Look up who made the game in Properties. Ask them. You can find the creator of anything in SL in several ways. Often right-clicking and selecting Properties is the simplest.
  13. OMG! You need to go through the beginner tutorials again. Linden made SL Tutorials here. If you haven't been in SL since 2012... the changes are huge. You have a bunch to learn. If you haven't been in since 2018-2019 you'll have a clue but be really confused. And it will be confusing, no matter what, as there are tutorials for different eras of SL. There is the System Avatar era, the Fitted Mesh Body with Applers era, and the latest Mesh Body with BOM era. Any tutorial made before 2019 is going to likely seriously confuse you. Stay with newer stuff. This may help: Getting Ready for “Bakes on Mesh” Bodies which is a bit old but hopefully get you through the transition to the current way of doing things.
  14. @Violet TopHat You need to post your computer and viewer specs whenever you have a tech issue so we can have an idea of what is causing the incomplete render. Use the viewer's HELP->About... to collect the information. Without this information, we guess. Even with it, we may end up guessing. But often we'll see the problem. Our starting with the information can save you a lot of time and effort.
  15. The ONLY part you have to get from the SL system is the armature. Rigging to an armature you make will not work. Unless you exactly duplicate the SL armature.
  16. € € € € type Alt+0128 - hold ALT down and type 0128 then release ALT... More currency symbols are here. Gotta keep the SL residents better educated than the college students I see in 'man-on-the-street' interviews. 🙄
  17. I would guess some part of the page did not download as it should have.
  18. @Magnus McGettigan Also, try pressing Ctrl minus or Ctrl plus to change font size in the browser. Alwin is probably right. Look at your system font size.
  19. We need the info from your viewer's HELP->About... Paste it in this thread. That allows us to eliminate a large number of problems and hopefully get to the actual problem. Including the info saves you and us the time of stepping through all the common might-be this or that issues. The lack of information may be why it has taken a week for you to get any answer. When all else is failing and when you and those helping have no clue, look in the viewer’s log files. The viewer has various log files you can read to get an idea of what has gone wrong. Look at the log immediately after you crash or exit the viewer. Logs are replaced the next time a viewer starts. You’ll find the logs in: Windows: C:\Users\[Win_login_ID]\AppData\Roaming\SecondLife\logs\ Mac: /Users/<username>/Library/Application Support/SecondLife/logs You will change folder and file names (like: \SecondLife\) based on the viewer used... But, they are all similar. crashreport.log – This log is generated when the viewer crashes, the previous version of the file is overwritten. Rename this file if you plan to restart the viewer before examining the file. Otherwise, just read it with a text viewer (Notepad is good). debug_info.log – This file is internally formatted as an XML file. I never find it of much use. It is mostly the specs of your machine. SecondLife.log – This is the main log file. I find it the most useful. Start from the end of the file and work toward the beginning. Search for ‘WARNING’ and ‘ERROR’. With any luck, the messages there will give you an idea of the problem. Recent changes have added a section heading to parts of the file that can identify the general nature of the problem. There are lots of performance stats included. At the end of a non-crash log, there are secession stats; Run Time, Average Packet Size, Dropped Packets, Resent Packets, etc. The file is replaced and recreated for each viewer's secession. SecondLife.error_marker – I don’t know what information is inside. I don’t have a copy to examine as I write this. The presence of the file indicates where, when, and what error happened. I think this is a disaster backup file for crash reporting in which information about the crash is retained in the event the crash handlers are destroyed before they can create the other more complete crash files. SecondLife.start_marker – There is no information inside. The presence of the file indicates how far into the start process the viewer has gotten. Whether the file exists or not is the pertinent information. SecondLifeCrashReport.log – This is another file internally formatted to XML. It is created when the viewer crashes. I think this is the new version of the crash log. It is mostly text. stats.log – This is a short file containing network statistics. Similar information is in other log files. It is an easy-to-read set of stats that show how many packets were dropped and resent in a secession. I find the SecondLife.log is the most useful file for tuning and troubleshooting the viewer. It is verbose and reasonably easy to understand. There is a Debug Setting that allows you to increase or decrease the level of reporting. Most of these files are erased when the viewer starts. If you plan to send the files in with a trouble ticket or bug report, place copies in another folder before starting the viewer. Marker files are temporary and may or may not exist at any given time. Entries in the files associated with errors and warnings are labeled as such. That makes them easy to find by searching. Search and read through them starting at the end of the file and working backward. Warning entries are common and do NOT necessarily mean there is a problem. Some warnings are a part of normal operation. Some errors are trivial and do not indicate a ‘noticeable’ problem in the viewer’s operation.
  20. I'm not clear on what you are running. If you want actual answers rather than guesses post the tech info from your viewer's HELP->About... preferably collect the info while logged in. If you use a laptop, ensure the Windows settings are set up for performance. Ensure the laptop has not reverted to Intel Graphics integrated into the CPU.
  21. I understand the new models come with a fire-control computer for those l o n g 200yd shots... Awesome disguise... I'm still trying to figure out who these stealthy people are... 😳 😆
  22. AI support is not so much a good or bad thing. Good or bad will be determined by how the Lab uses it. If they train it well and use it to assist staff then I expect it to be a good thing. If they get sloppy in or shortcut the training and use it to reduce staff then it will be a problem for residents. The state of most bots in SL is VERY primitive. And in general, most bot support anywhere has been primitive. The programming and computers driving them have been minimal. New chips for AI processing and massive data sets are changing how well bots do or do not work. Interestingly, new AI bots can lie and make stuff up. This could make for some surprising answers from support. It would be like getting 'help' from someone in a 'Safe' Hub.
  23. Typical narcissistic sociopath in action... probably a politician in real life. I am glad you survived. I think the part that qualifies as 'toxic' is the destructive results of his actions and influence. Sadly, in this example, the toxicity is subtle and takes time to become apparent. I think the OP is complaining about the more immediately toxic personalities. Those we see and feel in current interactions. Not those taking time to develop to detectable levels. Both types are a problem. Google, now ABC - the umberla, wrote about Positionous People - I suppose toxic didn't work for their alliteration. In their many projects, they encountered volunteers who were derailing the projects. The article provided explanations for ways to detect and remove Persephone's type of toxic sociopath before the damage is too destructive.
  24. I don't see SL as toxic. Nor, actually, any online game. Monopoly, as a simple example, is not a toxic game but I've seen people get angry and venomous arguing while playing. So, should Monopoly be considered more or less toxic because of that? The world is how we perceive it... in New Age jargon it is a reflection of our self. A story of a gatekeeper from 3000 years ago illustrates the idea. It was the gatekeeper's duty to decide who could come into the city. Numerous people came to the gate wanting to enter. He would ask then 'why'? In some form or another, they would describe how bad the city was and the people they were leaving. He would tell them things were pretty much the same in his city and tell them to move on, refusing them entry. Then there were those who answered with positive reasons. Like one young man said he liked the city he was from and the people were great. But his family had grown and they needed to expand their business. So, he was sent out looking for a good city with friendly people to move to. The gatekeeper told him this city was pretty much the same and granted him entry. In all cases, the gatekeeper's city did not change. I do not consider SL or the SL Forum to be toxic. There ARE some toxic people in SL and the forum. Personally, I've met very few... actually I am not sure I can remember meeting any. I've met disagreeable, argumentative, poorly educated, poorly informed, apathetic, clingy, horny, delusional... and some really ANNOYING people. But toxic...
×
×
  • Create New...