Profaitchikenz Haiku

It's a method I use quite a lot, because it's more efficient in term of upload costs and display usage to have a single texture rather than 16 smaller ones. Let's assume you want to make a visible counter with your texture to display numbers from 0 to 99. That's two faces, and 10 individual digits. One 1024x1024 subdivides into 16 areas of 256x256 10 individual 256x256 textures don't require quite so much space in terms of bytes, but they require more resoruces on the server to store, entries, indexes, perms, uuids, etc. In terms of usage, the real gains come with the effecitve preloading you get by using a single large texture with varying offsets , the unseen digits are already loaded and when you flip from a 1 to a 2 on a face, there is no need to load a new texture, it's not just cached on disk, but already in the GPU. The cinema slideshows I used had four 512x5112 screens on a 1024x1024 texture and worked very wel, the individual sections were perfectly readable and didn't blur hen zoomed into.

Out of our control. Also out of our control. In fairness to the Lindens I have previously criticised for this attitude, they may well be under constraints of limited budgets, resources, or de-prioritised for reasons we are unaware of. This is something I think we should be doing ourselves, creating newbie-friendly places and steering newcomers to them. We can make our own mentor group with volunteers and get that activity going again. One thing though we have to get right is to make sure the destinations we select are usually populated. There's nothing worse for a hopeful newcomer than to arrive at a recommendation to find it empty. This means we are going to have to get people from a selection of timezones involved. I don't see that as a problem, I see that as a challenge. Also out of our control Also out of our control while the server code is proprietary. So there's two areas we can do something about. I'd suggest people get working on the Newcomer activity Plan and the implementing required systems ideas. It's something we can do and probably get a lot of enjoyment and satisfaction out of, but griping about the areas we have no control over is a path to misery.

OK, surely though it's the directory block(s) that have such information rather than the areas containing the file data and they're going to be frequently updated this way anyway? Would there be any benefit to splitting up the cache so that the textures (and other fast-frequent access files such as animations) could be stored in Ram disk rather than the whle cache?

On reflection, looking at the past additions to SL such as Bento, Animesh, BoM, EEP, these are signs of incremental improvements. That's a good sign. The one thing I would absolutely hate would be SL rewritten to try and look like something else. It's unique, and it should stay that way. Similarly, I would hate for somebody like FB to buy SL and "turn it into the soclal platform you've always dreamed of". Sansar was an experiment to try and build a new SL from scratch, let's not go into why it failed, but the way ahead must therefore be incremental improvements of what we already have.

Based on my limited knowledge of the Dutch folklore I was waiting for one of them to try and plug the leak with his finger.

I wonder if the GPL-series of licences accommodate this? It does sound like a feasible way forwards.

I did try this option back in 2010, I copied the cache to the ram disk at startup, and back to disk after logging out. It worked well enough back in 2010 when 512M was sufficient for the cache, but doing it now with 1-2G would be tedious. I have also noticed this but I think it is showing up the time it takes to locate and fetch a specific file in a mass of others on a spinning platter, with the network download this searching time is eliminated.

OK, you get the non-sequitur of the year award.

I'm interested to know just how much an SSD is likely to have it's operating life shortened by being used for the cache: once you've visited all your normal spots, there's not going to be a lot of writing to the cache, mostly it's going to be reads? I admit my views are based on what is effectively black-box testing, and there is one area where I might just be wrong about the cache being used for reads: after some TP-crashes there is such a turmoil reloading the scene that I have a suspicion the crash resulted in the cache being marked as faulty and every texture is being fetched again. I'm currently switching my cache folders as well as some train-simulators to an SSD: both SL and the simulators do a lot of disk reads but comparatively little disk writes. I can do this getting quite small SSDs, perhaps 250G, so replacing them won't be too much of a hit, but if I am wrong about the majority of access being reads I would like to know. My understanding is that disk writes to an SSD are heavy in that they require an entire strip of adjacent cells to be written rather than one single component of them, and it is this strip-re-writing that ultimately causes the SSD failure?

I thought I ought to check up on who Linda Spadero is before accepting that what they have said is true. Artist? I wonder if she mixes her own pigments in the way the artist who forged Vermeer did? That was brilliant research. I then thought, I ought to check up on Molly before accepting what she's relaying about Linda Spadero, but I'm a bit too old to stalk people now so I suppose I'd better put out a contract... For years the internet has had a bad name for being a hotbed of cut-and-paste unconfirmed information, but in fact it offers us the ability to do a lot more checking that we were previously able to do Example: Lyall Watson's book Supernature contained some stuff about pyamids: How they would sharpen razor blades, how they would prevent meat from decaying... And because it was a published book that had obviously gone through editorial scrutiny, it was accepted as fact. It took Mythbusters to do some actual testing to turn up the fact that the author had been publishing anecdotes not evidence. Sadly though, we tend not go delve too deep into information given us. That's not always such a bad thing, Molly, for example, is going to feel relieved that I'm going to take what she says on trust ...

Bellies too, I've noticed, they tend to reach the limits of the envelope quickly... Going back to design efficiency/inefficiency, I have used several languages during my working lifetime and I've noticed that, although any language can be used in a good as well as a clumsy way, certain languages encourage a better coding practice than others. Forth is one example, code tends to be more compact, more able to be re-used or incorporated into other bits of code. The languages I think lead one into less elegant coding styles are Assembler, for obvious reasons, and C. The language with the biggest failings I found to be Fortran, for although it was supposed to allow direct translation from formulae into code, I would often spend ages on explaining to the users just how their formula had actually ended up in the resultant code and why it couldn't look exactly as they were used to understanding it. What isn't often realised is that, despite our high-level code looking very elegant and concise, the conversion by the compiler front-end or byte-code generation results in some extremely messy code, which nevertheless is just as fast when it comes to execution. There are two distinct audiences we have to perform to, other coders and reviewers who see one thing in a high-level construct, and the compilers/execution hardware, who see something quite different.

There's an overlap with another topic here about porting 32-bt code to 64-bit. Somebody codes integer ii = 1; while(ii++ < 0) {/* do stuff like check ii is prime or whatever */} They're happy with the result which is nice and terse and will go through all the positive integers. Very efficient. Saves testing for an upper value. (testing if something is or ain't 0 is typically optimised to a register operation). You'd see it used when checking for primes or examining memory. Recompile that on a 64-bit system where integers by default are 64 bit and see how long it takes to complete. I have an intrinsic distrust of terse code for the very same reason I distrust the macros in c, what you read in the source isn't what gets given to the compiler. Sadly, with out 64K memory limit in LSL, we're pushed towards trying to do the same compact codings that caused early programmers to develop thhis memory-saving tricks...

But with the TPV devs, they can get it for free? (This is the second dangerously sarky post in uder 5 minutes, I think I'm over-tired)

why can't you be both?

I can never understand why the official viewer and the V3-derivatives set the minimum to 64m. But the question here is what does the OP have by way of Ram, GPU, and settings? My own experience is that if I go somewhere and there's a dozen avatars within a few metres of me, everything slows, but I am using rather aged hardware.

This is very reminiscent of the 2010 Emerald viewer bouncing breasts: Fractured Crystal said that he found the code was already there in the viewer, just commented out, so he turned it on, and the rest is history. My thoughts are though, suppose FS does indeed manage to get this working, all of a sudden their viewer becomes the must-have, and what are the other TPVs and the Linden Viewer team supposed to do? The bouncing breasts code was there for everybody to use so effectively it was a shared resource.

Just to try and expand a little on what I posted and give an explanation of how to try and deal with it: There are 21 avatars in the region, including yourself. A quick guess is that it's a club and they're all within chat range, so draw-distance is only worth dropping if it's set to reach the boders of the region. All those other 20 avatars probably have mesh bodies, probably with 1024x1024 textures on skin , clothes, jewellry, ... Your viewer is therefore being given loads of updates from the region to process, and the most of it is mesh objects and large textures to be thrown at the GPU. Since the bare minimum you need to be in control is the ability to read and type in local chat plus move around, you have to reduce the amount of avatar and object-generated graphics load. After the obvious initial advice I gave regarding Draw distance and graphics sliders, try reducing the avatar complexity setting to jelly-doll some of the more extravagant creatures around you. You'll still be able to see where they are and move around them, but obviously you won't be able to compliment them on their appearance. Dropping all that graphics will then at least allow your typing to become visible in a less jerky manner. Oh, and turn off shadows...

Ping Sim 583 msecs is a bit ominous, but the other figures such as 21 agents are pointing to a busy place. Your internet speed isn't the issue, although from the ping sim time I'd be tempted to log out of SL and back in a few times to see if I could get something closer to 120mSec

I asked about this at one of the meetings and Oz replied that everything, including typing, is reduced to texture drawing, so the busier the region you go to, the worse that will get. The only way to manage it without buying better hardware is to turn off ALM, reduce your draw distance, and if necessary start dragging some of the other sliders such as quality, object detail etc back. If your viewer has graphics presets, make up some to flip between high and low quality modes.

I've noticed two quite distinct classes of profile. One says in effect "This is who I am". The other is a little more confusing because it's saying "This is who I aspire to be". It's very easy to get jaded with the second type and do a "stop dreaming, wake up and STC", but that's overlooking the fact that SL is all about dreams and alternatives.

So I understand, (the information came from the Server User Group via Animats in a discussion about increasing the amount of script memory available ) By itself, 32-bit software isn't intrinsically bad, the viewers are mostly 64-bit now not because it's better, but because target PCs are 64bit, the build systems (Visual Studio/Mono) are 64-bit, the support libraries are 64-bit, etc. And the amount of memory a viewer is going to require shoots past the 4G limit of 32-bits quite rapidly with mesh-loaded regions. The processes which actually run those regions don't have to be 64-bits, they obviously work well enough at 32-bit since the many processes are only handling a fraction of the total memory load that the viewers see. Up through version 0.8.2.1 Opensimulator also was 32-bit, but with the release of the 0.9.0.0 version they moved to 64-bit executables. There goes the reason for my keeping my old 32-bit Windows XP machines running. Porting a 32-bit program to 64-bit isn't just a case of feeding the code to a new build system, there are various little traps to be hunted out through the code, for example, a programmer might have been happily incrementing a register variable knowing that once it exceeded a certain value it would then become negative or at least revert to zero and so needed no additional checking, a 64-bit register is going to take significantly longer to achieve the same result, and so if such a coding tactic has been used, usually to slim down the code or speed up execution by removing the odd instruction here or there, the missing instructions then have to be put back, which leads one back into the same problem scenario that caused the original programmer to leave hem out in the first place... Just one of many little issues.

Yes. If they're short of that many people, how on earth are they managing to keep anything going? Being cynical, advertising that many positions doesn't mean they want to recruit that much staff, it might be a sign of ambition with the intention of attracting investment. The only thing I've heard recently that has me slightly worried about SL's future is that they're still running 32-bit processes. Upgrading to 64-bit isn't a trivial exercise. (As the Arianne rocket team found out when they went from 16 to 32 bit a few years ago).

0.001% Oh in that case I'd go because it's exclusive.

I hadn't realised this, and you know what? It's actually made me love SL even more. If it had all been planned from the start I would just be yet another consumer forever attached to their tar-baby product.

Sometimes I have the same feeling about RL, but then I realise the starting-over is just anecdotal. Most of us are doing option 1. I see a few people with profiles - "Not a new avi, I've been here xx years, just starting over", but I think "Why say so? You're not starting afresh, just anchoring yourself to what remains of your past." I'm learning to live with what I've got in both lives.