Kwakkelde Kwak

Jenni Darkwatch wrote: [...] but considering LLs historic refusal to add anything a TPV has developed... I'm not holding my breath for its appearance in the official viewer. Sad, really. How about avatar physics and the ability to attach multiple objects to one attachment points? They certainly adopted that, both in a better way than the original I think.

Penny Patton wrote: SL has abysmal framerates even in the most hideous or plain looking environments, even on computers that can run Crysis at a smooth 60 frames per second. Why? SL is pushing millions of entirely unceccessary polygons, often because the tools encourage low-prim over low-poly. There's no incentive for users to create objects with smaller, more efficent texture maps so SL eats up texture memory and there's another damper on framerates! Why do I get the feeling I am quoting myself here? Bigger avatars with cameras hanging another meter or two above and behind them require much bigger buildings than little old 5'7"/173cm me with my game-like custom camera! Those bigger builds eat up more sim space meaning less room for content. Those builds also eat more prims, meaning more polygons being rendered despite less detail! Up until the recent upgrade to 64m prim sizes prims were limited to 10m to a side, so older builds cover SL, eating up even more prims for little return in detail or content! Size doesn't matter I'd like to say, regarding graphics quality. Imagine the avatars are 10 times smaller than yours...(or mine for that matter, I'm not quite as small as you I think, but my avatar height is set at 31) Then the sims would be 100 times bigger, with the same 15 000 prims available. We could have more houses, more trees, more whatever on the same sim, but we'd also need them, to make the sim look like anytjhing besides a desert. So there wouldn't be a single prim left for any details. 10 meter prims? Yes that's the way it was, but not anymore. If people use two 10 meter boxes now instead of a single 20 meter one, that's their mistake, not LL's. For existing builds which aren't mod, again, builder's mistake not to set them mod. That's the biggest nono in my book. I only use no mod permissions on items that are likely to be broken when the shape is altered, maybe 1% of my objects. I'm not expecting all residents to rebuild their old homes in a more efficient way, or even the builders, but in a matter of time the 10 meter limit will be forgotten. An uglier SL becauseo f poor design, not a lack of capability. Women avatars have freakishly short arms, why? Because once you go over about 6' tall it becomes impossible to stretch a woman avatar's arms out long enough to be proportional. LL then starts all new women avatars off at about 6'4" or taller.Avatars pushing 9' are more common than avatars around 5'. The lack of consistency even at that extreme scale means animations will almost never line up properly, either. Another hit to SL's graphics quality. If graphics quality includes animations, appearance, proportions etc. I agree. I read the OP once more and that was indeed included in the question. Graphic quality to me means the technical part, sharpness, framerates, anything that involves putting the given data from the servers onto your screen. The rest is aestatic quality to me. So I can't argue with you on this. All of this is avoidable. Sure, you can blame some of it on user generated conent being made by people with enthusiasm but no skill, but it's silly not to point out that the tools LL provides make creating better quality visuals in SL an up-hill battle even for those of us that are professionals and know what we're doing, let alone the casual users just banging prims together for the first time. I love the fact enthusiastic noobs can build anything they like. I just hope the now optional calculations on weights will at some point be mandatory on new objects. I think LL is very well aware of the issues you describe and with mesh they made a huge leap into something more fair. On a sidenote, thanks for figuring out those camera settings (that WAS you right?) Makes my SL experience a lot better, not my graphics quality though:)

Drongle McMahon wrote: So if an object has a texture on ot, it gets charged because it will have to be rendered at some point. Just the same as the LOD or hidden triangles for meshes. The LI doesn't change when the mesh is hidden or when the LOD changes. Yes good point... A bigger problem is that It would be unkind when the same texture is used on 100 objects! We are already charged the same for each of 100 instances of the same mesh, but I think that is more justifiable because of the rendering load. Again the same for Mesh, I can't imagine duplicated geometry gets sent twice from the sim to the viewer. Mono scripts don't, textures don't. This is where the higher price for a big texture can be helpful (for big builds with duplicates, not for a single build, duplicated many times by the end user). If you are going to use a 1024 texture four times, it has the same impact as using four 512s once. So the price could be the same. For mesh we get charged by resource use in the upload, or at least estimated (yes it's calculated, but not nearly 100% accurate in a lot of cases) resource use. As it stands, stretching a mesh changes the physics shape, and all the physics is on the server. I suppose you could have new things like llTargetOmega where it's only on the client. Yes that's how I would think it should work, or at least have a toggle for that. Never looked very closely, but as far as I know, avatars physics don't change when animated. The same could be done for other meshes. Then if you want accurate physics on an animated mesh, add a factor 10 or 20 or whatever is reasonable to the physics cost (or download cost?).

Jenni Darkwatch wrote: Nope they do not pick up on that. Thanks for verifying that. Now I also bet when (or if) script limitations are going to be introduced, the sim WILL pick up on that. In other words, there has to be a way to sense the duplicates. Maybe it's time for a better script function than the one currently available for fetching memory use by avatars. Or maybe LL is already working on that as "a next step" towards the limitations (which I sincerely hope will be implemented at some point).

Ok...I was going to say mono scripts seem to use three times more memory than LSO scripts.... so the script would have to be either pretty small or pretty big to be better compiled in mono (for memory use). But I looked the mono benefits up in the wiki and if you use more than one, the script data is shared and only used once, so in for instance a store with a LOT of duplicate vendor scripts, mono is preferred easily. This brings me back to the lagmonitors.... I bet they don't pick up on duplicate scripts. Anyone who wants to comment on that and enlighten me?

hibit Spad wrote: When you link mesh objects with anything else all items start being counted as if they were mesh. So prims, which are in fact vertice heavy, have their costs go skyhigh. the same result for sculpts. So don't link mesh items with anything else. Not completely true. If you link "vertice low" objects to your mesh, you will benefit. Boxes have a landimpact of 0.5 prims for example. The behaviour described by the OP when objects get bigger is also correct. The bigger an object, the further away you need to be for the LOD to switch to a lower model. So more people will have to render the object. Hence the higher count. Sculpts are very inefficient in almost all cases. 2048 triangles with almost 1000 vertices is not often needed for the shape they make. So if the sculpt is smaller than 64 meters, better replace it with mesh. If it's bigger, do not link. (And don't overuse).

The not so practical and fair bit is the viewer doesn't know if the 1024 texture needs to be rendered or not and on how many faces. The unfairness isn't as big as with the single alpha triangle I bet (1 face or 1000, the texture needs to load), but it's still there. As for animated mesh lag... I would think all that animating is done on the clients side, whether worn or rezzed mesh, so it shouldn't have to be that bad. The sculpt animating by script is another story since that involves moving around and changing actual geometry in most cases. Now if a mesh was rigged everything could be client side I guess.

Plus it would be very hard to implement. I hope LL is rethinking it, but the way it is now, any glow, any alpha channel, any shine etc returns a multiplier for the display weights. This means a single triangle with some transparancy on an object 1000s of faces big will raise the objects weight by a factor 4 (I think it was 4, but it's not the point what the factor is anyway). I can understand why LL does this, it would cost a lot of resources to check check and recheck all the faces on such an object every time there's a change. The same is the case for texture size, well not entirely, but it would still require constant checks. It would be fair, but very unpractical. Right now it is practical but unfair...and inaccurate for that matter.

Jenni Darkwatch wrote: 0.3ms for scripts on an avi is somewhat in the upper range of "acceptable", IMO, considering one frame on a simulator only has 22ms. Since SL is a social platform the way I see it, using half the available 22ms for avatars sounds lowish to me. If everyone was at 0.3 that would allow almost 40 avatars without any throttling. I wouldn't call that on the upper range of acceptable, I'd call that well within reason. Memory... yes, that's a problem. Any measure of script memory is going to be skewed for mono scripts, as it is right now. The suggestion about using llSetMemoryLimit()... I really should start using that myself. Even dynamically adjusting memory limits should be fine IF it's not done every second or so. Just IMO, haven't tested it. Yes I was thinking of something like that myself, executed not on a timer, but before or after certain script commands. It's a lot of work though, only to give more accurate figures to the sim (so also to the lag monitors) without actually saving any resources.

Charolotte Caxton wrote: I think bandwidth has something to do with lag and that the setting in preferences does make a difference. So do I, I never said it didn't. Again, the reason is not the connection speed per se, but the insane amount that has to make that trip from the server to the viewer. The topic here was graphics quality, although it's indeed something we all have to deal with, I don't think loading time after a teleport has got anything to do with that. Once everything is loaded the bandwidth drops. I was at a rather full sim today and checked my numbers, I had a constant 60 or so kbps with the occasional spike to 200. This can't be any problem for the vast majority of the residents. If people would stop using more resources than needed for textures, geometry, physics and scripts, everything would benefit. Rezzing time after a teleport would be shorter, framerates would be higher, sim framerates would be higher etc. It would certainly make my SL a lot nicer, but the threshold for new residents to participate in building and scripting would be a lot higher. Drongles proposed experiment sounds interesting, but I wouldn't want to participate with the sim that holds my store. I really do not want to answer IMs from people saying "Hey why do I have to undress to enter your store? I am getting messages I am not allowed in because I am too laggy!" However I do think there's a market and if I didn't have a store I'd even be willing to use such a server. I can imagine the raised performance would do wonders for combat or game or racing or whatever kind of action sims.

Pamela Galli wrote: The last entry I have from SecondLife.log is Oct 2009. Am I supposed to turn it on somewhere? In that case is it possible you are using a third party viewer with its own logfile? the thing is updated every time you use SL....

Even if datatraffic between servers or server and viewers over the internet is a big part of lag in SL (which I doubt)...the underlying issue is still the fact people can built what they want, how they want. Professionals wouldn't use the insane amount of 1024x1024 textures used in SL. In our little virtual world, everything is designed as a single object opposed to a part of a whole. It's a problem that will always be here. I personally don't understand why a 32x32 texture costs as much to upload as a 1024x1024 one. if a 1024 costs 100 times more, a lot of people will think twice if they really need it. I also don't understand why LL isn't pushing harder on script limits. I also don't understand why you can in theory wear over a billion triangles. Eeeehh..I do understand actually... as I said earlier, it's what makes SL such a great place, but a laggy one. (a bit more restrictive wouldn't hurt though) As for bandwidth.. you can set your bandwidth in your preferences, although I never got the impression it really made a lot of difference.

As I said, for me, last time it was cured after a relog, same viewer, no changes..it could be corrupted cache maybe.

I have had that aswell. I think always in the coolviewer when it was first released with mesh and this week once on an older version of the RLV. With me it was my hair, different ones the two times. The first time (with coolviewer) I just decided to use another viewer, the second time it was cured after a relog. So I don't think it's your graphics driver. It is 2 bit alpha instead of 8 bit alpha, or something like that. ( every pixel on a texture with alpha is either invisible or visible, nothing in between) There was some talk about it earlier on these forums, if I recall correctly it happens on very dark textures and in phoenix there was a switch for it... I know this doesn't solve anything, but it might put someone into the right direction.

I guess we were talking about two different things then...thought you made a box in blender, added the other object that was corrupted to it then removed the box again..that will reset some weirdness in the original object (such as a negative volume as a result of mirroring or negative scaling) ... nvm:) Since you apparantly didn't find a satisfying solution...can you post the error(s) from the log?

Nifty, I guess I need to play around with that analyse thing a bit..great stuff!

Hmm guess you got negative values here and there then:) ...adding and removing a box is my fix for that anyway...

Alisha Matova wrote: This should result in the same LI and let people bump into the tree. That depends really, adding another object doubles the server weight. In this particular case it will probably work, I'd use something simpler than a box though, a bottomless threesided pyramid should do the trick, or even two crossing triangles. No need to use 12 triangles for something as basic as a physical post. Anyway, if using two objects instead of one is no issue, I think your way is preferred over the one I proposed...

It's the SecondLife.log file, force the error then read the file. Last changes are on the bottom, so you'll find the errors there. Finding Log Files

In the RLV viewer, there's a slider for avatar offset on top of the screen. You need to move that slider from side to side all the time when changing poses often and the effect is limited. Maybe other viewers have the same or a similair function? Anyway, I use it all the time. Not the perfect solution, but it works on all animations.

Hey I mentioned streaming! I think this is a minor problem compared to the rendering though, and to the script load on the sim. If you open the statistics bar, you can see the bandwith. Only on sim entry do I see 3 digit numbers, in most cases I see low 2 digit figures. Dial up is not sufficient no, but for what is it, besides reading your email these days? I don't consider my 5-8Mb line very fast, yet I haven't seen SL using the full line. SL loads textures and geometry to your local cache. This means once it's loaded you only have to up- and download any changes made to that and the communication between avatars. I do have to mention I don't use voice and usually I have streaming music and media turned off.

Thanks for that, it actually rings a very small bell yes... I'll keep that in mind in case a 16k mono script gets errors....

The "bounding box" of all LOD models and physics model are set to the same size of the highest LOD, so make sure all models are the same size before exporting. You could make a single triangle plane for the bottom. If your leaves are higher than your trunk, make a plane for this aswell. You could also put both planes on top, so people can rezz the tree on a sloped hill or something.

As long as...hehe..yes. Well either way it might be good practice to use the limit anyway, as Kelly said, it's a next step towards script limits and I'm sure that limiter will use the same numbers as the current monitors... Some things confirmed, some things learned...not a bad thread for me!

Script limits as proposed in the past (as far as I know) have got nothing to do with this. Those limits would be per avatar or per sqm or parcel or something. Not per script. The scripts already have a limit, 16k and 64k. So what you are saying is you can only use 2 mono scripts on that hypothetical 128k sim/core? I find that very hard to believe really.