arabellajones

Looks as though people are confused. The viewer all use some of the RAM on the graphics card for storing textures, the rest gets used for image generation. There days the top end graphics cards have huge amounts of RAM, I see some have 6GB, and Firestorm, long since, increased the maximum possible to use for texture storage. It's a trade-off. It would be nice to have the choice, but if your graphics card has less that 1GB of RAM this old limit isn't your problem.

Isn't the big problem with high avatar complexity that it implies the avatar needs more data to be downloaded? The impression I get is that avatar data doesn't stay in the cache for very long, if at all, compared to other types of data. That's something that isn't affected by display settings or the processing power of the computer. I try and run a low-complexity avatar for the big events, such as SLB, and my usual "furry" AV comes in at around 10k. A friend has a Mesh avatar that is usually running at under 20k, with full clothing. And yesterday I saw an AV running at 250k, totally naked. I know the Lindens introduced complexity, but it still not mentioned on the Marketplace, people still use complicated avatars, and I have to wonder where it was worth all the trouble to set up.

That web page is looking horribly out of date, with rather questionable solutions involving installing specific, outdated. versions of Adobe Flash Player. This is a security risk and, honestly, it's talking about a very old version of Firestorm. I am not disagreeing with the point about wanting the specific details, such as OS and viewer details, but neither Firestorm nor Linden Lab do a good job of keeping their web sites up to date as the software changes. Too many of the old and obsolete web pages never change, and don't even get links to more recent information. In particular, older Firestorm viewers are explicitly blocked from connecting to SL, and the block would have taken effect on v4.7.7 at about the time that Lindal Kidd posted. While that viewer can still connect to OpenSim grids, the page is specifically saying it's specific to Second Life. It's now six months since Firestorm v5.0.7 came out, a beta of v5.0.9 is being tested, and I am wondering if this web page has stopped even being wrong.

I'm seeing other problems, but any texture changes over the weekend seem to be getting forgotten. So an alpha layer for a particular outfit will have the changed texture showing as grey in the editor, giving no effect, but the original texture is in my inventory, and a drag-and-drop restores it instantly. Detach and re-wear seems to work normally, but after a login, or a teleport to a busy sim, the connection to the texture is often lost. Use the JIRA, they'll say. What's the point? They're all on holiday. But at least I know this is happening to other people, so it's not my connection.

I have been hitting problems with scaling a texture on a an item of mesh clothing. The default normal map is a 1024x1024 texture, which I reckon to be a bit large. As near as I can tell, it's a simple normal map, no fancy work to fit the UV map, and the UV map is a simple front-back view of the standard T-pose. So I tried a simple 256x256 texture, a normal map of basic knitting. On the body it looks OK, on the sleeves it's misaligned. On a real knitted sweater, when the wearer's arms are down, any ribbing is vertical on sleeves and body. That's not a huge problem, and if the UV map was big enough and detailed enough, you could align the texturing to get the look. I don't think even a 1024x1024 is big enough. And you need to scale a 256x256 to get the knitting small enough. But let me put in the texture. That should be scaled to about 1.5cm wide, 60 or 70 repeats per metre, and you can set that in the editor, texture tab. normal map, and Repeats per Meter is an option. This is where I hit the problem. You can set Horizontal or Vertical Scale with no problem, and this gives a calculated Repeats per Meter. Small changes in scale give small changes in Repeats per Meter Remember, both the texture and the UVmap coordinates are rectangles. The tricky part of the job isn't scaling the texture, it's doing the interpolation between the mesh vertices, which have defined coordinates on the UV map. But I found that if I changed the Repeats per Meter value in the editor. typed in something suck as "20.0" and hit Enter, it jumped to something slightly more than 96.01. If it had jumped to 20.5 or even 21.0 I would have written it off as some sort of rounding error, but this is a 480% change. OK, so I work with the horizontal and vertical scale settings. But the conversion works both ways for prims, while seeming to jump to rather arbitrary values for some meshes and sculpts. It has to have been going on for a long time, and it seems to be Linden code, and, frankly, I've given up on JIRA as handled by Linden Lab. It seems to depend on an alien language. And. earlier today, I had two different people in-world say they "couldn't replicate the problem" while I'd been describing on mesh, and they'd been trying with prims. Side thought, guys: look at how a sewing pattern is made. It's doing some of the same flat-to-curved stuff as a UV map does. Something like a shirt as 4 or 5 vertical panels, neck to hem, tapered so you get the shape-change between shoulders and waist. Use that in the UV mapping. and a check shirt will look right. I'll throw in a pic from Wikipedia. You'll need polygon edges in the right places.

I'm having the login problems, but this is working OK, as is the Marketplace. I did a Speedtest check to Phoenix which shows the usual results, so I have a suspicion that the problem is pretty close to the Grid's servers. Nothing definite, though.

Looking at how that SLUniverse thread continues, Starlight looks dead. Respectable people have asked about about later viewer versions, and there have been zero replies. I gather it's officially too much work for the Lindens to bother with. At least, that's how I read the jargon they use in the JIRA.

The Starlight skins haven't been updated since February, and I haven't been able to get them working with the previous viewer version. I find the standard colour scheme to be horrible. Is there an alternative source to this webpage? Or is the system dead? http://wiki.secondlife.com/wiki/Viewer_Skins/Starlight

This is my answer too. It's partly my internet connection, I suppose, as well as the computer, but switching off ALM can double my frame rate. I seem to remember a claim that ALM didn't hit frame rates much, back when it was introduced, but that doesn't seem to be true any more.

Blender tries to do everything, which makes it hell to learn. Get it anyway. I use Wings3d myself, but I've had glitches with the Collada export. So I export from Wings3D in Wavefront (.obj) format, import that to Blender, and export from Blender in the Collada (.dae) format. There are things that Blender can do which are pretty useful, but they can be hard to find. Import and Export are in the file menu SL will notice the hard/soft setting on edges, but it looks as though the SL render engine does some strange things to the mesh to handle that. A hard edge is turned into two adjacent edges, and a mesh cube would become six squares.

I can think of one thing to check on, and the Lindens didn't explain it clearly. A mesh or prim surface can use three textures, Diffuse, Normal, and Specular, each with an alpha map that does different things I posted this a few months back, summarising what the alpha maps do. Using the alpha channels for the normal and specular maps could make the eye area non-reflective, while the rest of the surface has some texture and specular reflection. It doesn't need a huge texture map

I've noticed, a time or two, that people have been confused over the two different Blue Galaxy mesh figures, but it looks as though you're talking about the "Solarian Feline" rather than the older "Blue Galaxian" There are a few clothing items available for free, and some stuff that you can get completely outside SL, as an uploadable mesh and texture files. It's quite common to be able to at least be able to change the textures. There was something wrong with the main authorised download source, you need to ask in the in-world group to get the current source. I do use a few generic mesh clothes. Depending on the shape you're using, there are some which fit the Solarian Feline well enough that only a few body sections need to be turned invisible. There is some rigged-mesh hair that works well, but I've had some odd things happening with hair that is described as Bento-rigged. Check with a demo. I set up a Bento tail for the Solarian Feline, works well.

The point is, which none of you seem to even notice, is this is the forum specifically for server technical issues. And you didn't even bother to mention the issue here. Neither did the Lindens. What you possessed you all to totally ignore this forum?

So I observe a specific problem which appears to be linked to a particular version of the server code, and I check the form called "Second Life Server" in the Technology Forum, and there's nothing about it. Nothing recent posted. There's nothing mentioned in Status So I post what I hope was a clear description of what I saw, and you pop up and say, "Talk about it over here, in General Discussion". And then you say it's the LI calculation leading to objects being returned, when the objects are still there, but the physics is broken. Maybe you should use one of the alternatives to Google Translate. At least I am sure I am a native English speaker

I've already opened a support ticket on this, but there are problems with Mesh physics on Magnum servers. Enclosed spaces, such as buildings and caves, have become inaccessible. You cannot walk through an open doorway, and if you get inside the building by some other means, such as camming in and sitting on a visible chair. the floor sometimes has no physical presence. I suspect that may depend on whether the floor is mesh, a prim, or normal ground. I have had similar problems with mesh models I have made that have not had a specific physics model included, as though the physics model was a single large cube. Since these mesh structures have been in use, without problems, for months or even years, and this is happening in multiple regions, I doubt that it is an example of either careless building, or of malicious action by a "griefer". It may not be happening in all Magnum regions. I am rather surprised that there have been no other reports here. It might be that the servers just need restarting, but the places I have seen it in seem to be full of avatars, standing around with their hands in their pockets, apparently unaware of their surroundings. Has the Linden Lab Help system become so intimidating, or do people believe it is so useless? I'll admit that "user friendly" is not a phrase that springs unbidden to my mind.

I am getting horribly confused by all this, but the wording of the Status message suggests far more than just a roll-out of a known-good server version is happening. The bug was maybe in the server code, but maybe it broke far more than the Lindens are admitting.

MRDA

Why am I using Firestorm? Because the LL Linux viewer doesn't work at all, and because I never had reason before to think Firestorm was behaving differently in the number of SLPlugin instances used. "Four shalt thou not count, nor either count thou two, excepting that thou then proceed to three. Five is right out!"

I'm using Linux Mint 18.1 No zombie processes. It's one of the things I checked for. I don't expect you to know the details of how Linux works, but I have four SLPlugin instances from Firestorm appearing before login, while you see two under Windows, and I am starting to worry about what they're doing. Well, I can check that. There are a plethora of GNU tools to track this sort of stuff, though it looks as though I shall have to write a shell script. I joined SL after the Emerald business, but some people were still warning newcomers to be careful about the Phoenix project. Summary: Firestorm starts more SLplugin instances than other browsers, and is slow to cull them. When Firestorm starts off using more RAM than any other viewer I know of, this huge of extra RAM doesn't look good.

Ah, I was mistaken about Cool VL Viewer It did open a single SLplugin instance when the viewer started. This was promptly culled when I logged in, vanishing within seconds of my login location becoming visible on my screen. That may be why I missed the use. This is still different from Firestorm's behaviour, with multiple instances at viewer start, and no culling.

So I start 64-bit Firestorm. Without even clicking on anything, four instances of SLPlugin have started. On your description it only needs one. for the login screen image. All the other examples you give appear to depend on an active connection to Second Life. So what is Firestorm connecting to that you don't appear to know about, and why? Oh, current software. Try Cool VL Viewer. There are regular updates, and it doesn't use SLPlugin. It also made busy places at SL14B usable for me. Fewer features than Firestorm, but it does seem to release RAM before the heat-death of the universe.

It doesn't seem to be in every TPV, so I find it hard to believe it's essential, but what does it do? I suppose it might be a quick and easy way of taking advantage of multi-core processors, but I see Firestorm loading four instances before I ever log-in, and using huge amounts of RAM, more than Firestorm itself is ever reported as using. This is with 64-bit Firestorm. I can see how it would allow more RAM to be used under 32-bit Windows, but that's not what I am using. I'm guessing that a lot of the RAM allocated is as pointers to the same blocks of read-only code and the 7GB total for four instances of SLPlugin is misleading, but, as I said, other TPVs don't even use it.

Read Amon's original post. The reason he sees for multiple JIRA entries being closed doesn't seem consistent with your suggestion. JIRA is essentially a time management tool for a programming team. Why it gets used as it is around SL, I have no idea. As a bug-reporting tool, there end up being huge numbers of duplicate entries, and there's no way of merging the entries. I once worked through a chain of four entries before getting to the one being used for active progress reporting. It sort of works, if the people in control do their job, but it doesn't work well. What Amon reports looks like the people in control not doing their job. (From other contacts, I get the impression that the JIRA system is not regarded with unalloyed enthusiasm by programmers, it seems to be a tool associated with a particular management style.

What's the current state of support on the Linux version of the SL viewer? It will not run on my system, though other TPVs will, and I am being told that I can only get support on a problem if it doesn't occur with the SL viewer.

The problem would be the folder used for settings and cache and stuff, even if the library lets you use your own software. I think Windows split these things between several locations, but I don't use it, and the details are OS-specific. It's the sort of thing that a lot of software can do, it can be very useful (you can run a test version without clashing with the older versions), but I have a dread fear that SL viewers just can't do it.