kiramanell

Imagin Illyar wrote: I've recently discovered the joy of motorcycles in SL I have a great track that has solid transparent walls to keep you from going off the sides. It works great at low speeds but I've noticed that when you go fast eneough you can go right through them and then actually get your bike trapped by them. To test I set up some ordinary solid walls on an empty building platform and tried thick, thin, doubled and even trippled solid walls - at high eneough speeds I can go right through them. Is this some kind of limitation of SL? Anyone know of a work-around for this problem? Come to think of it, with the aforementioned emDash HUD I'm using, I've noticed it becomes harder to dash thru an object, the thicker it is. So, maybe you could pad/overlay your walls with (100% alpha) prims, that are like 50m 'deep', as it were (and ensure the ultra-thick support wall is the first thing they touch upon collision).

Perhaps it's a shortcoming of the engine of some sort, but entire products are based on this (wanted) behavior, like the emDash HUD I'm wearing, Build up enough speed, and you can pretty much dash thru everything.

ObviousAltIsObvious wrote: kiramanell wrote: Out of sheer curiosity, how would they be able to delete a prim sticking over their land?! If the center of the root is on your land, they can't touch it at all. That's how Linden homes work: they have the root prim located off your parcel, so you can't return the home. it no longer works that way, you can now return any objects that overlap your parcels. the newer system uses a physics hack to check for encroachment. there are special exceptions in the system that the estate owner can set, that is why the Linden Homes, and Linden roads that overlap some mainland parcels, cannot be returned. Wow! Learn something every day! Didn't know that at all. Thx for the clarification!

beethros Karas wrote: edited: Thanks for the replies and the prims! I got what i needed! hello world lately i am trying to get a 127x127x127 prim from megaprim.sl but the site gives me "error All authentication servers are nonresponsive." If anyone has a 127x127x127 prim pls pass it to me, i have to redo all my skyboxes, because the 128x128x128 it touches in 0.00001 mm and so neighbours they have the rights to fly all the way up and delete one by one all whatever is simply tangent. (Take this as a hint for your future builds) Thanks in advance, beets Out of sheer curiosity, how would they be able to delete a prim sticking over their land?! If the center of the root is on your land, they can't touch it at all. That's how Linden homes work: they have the root prim located off your parcel, so you can't return the home.

Madelaine McMasters wrote: It was clear to Rolig, and to everyone else who understands the operation of the forum that pulled posts always involve a moderator. That is not to say that pulled posts always involve moderation. ;-). And it was clear to me, even after posting the last few days, that posts don't necessarily 'take', as it were: the other day one of my posts in this thread had disappeared after a few seconds as well, but stayed when I reposted it. And that's the last thing I'm gonna say about it, as this thread gets derailed this way. Back on-topic: a friendly person over at Jira just informed me that, apparently, Linden is already working on this. See: https://bitbucket.org/lindenlab/viewer-tiger/commits/8425f76bbb1de290c9c4956a2e0579d4a05a0112

Rolig Loon wrote: Only a moderator can remove a post. Nobody else has that power. Also remember that the forum guidelines say We prohibit abuse of our moderation process, including the following: Posts that discuss or re-post material that has been removed or locked by a moderator Posts questioning a moderator’s decision Then it would behoove a moderator to have the courtesy to at least inform me that a post has been removed (and wasn't just eaten by the server). Although I can't for the life of me imagine why someone would remove a simple post with a link to a Jira in it. Also, no offense, but you are not a moderator. So, please don't tell me I can't question a moderator's decision when it's entirely unclear (to you as well) that a moderator was even involved to begin with

Okay, who keeps deleting my last post?! (In which I point to the Jira I filed about it), STOP DOING THAT!

arton Rotaru wrote: Right, there is a high amount of texture data going on. I'm not sure where the massive load is coming from actually. Maybe there are a couple of very bad objects around. Some which have plenty of 1024² textures on them? Idk. Even when I zoomed onto a single item, with just the object, and the sky in view, the "Bound" texture load stayed fairly high, at 250 MB. If I try the same in may own skydome, the Bound number decreases to something like 20 MB immediatly. So something strange is going on there perhaps. Though, I didn't had the unsharping/sharpening issue like shown in the video. Once my cam stood still, there wasn't any unloading/loading going on in the texture console. Of course, moving my cam around, I had to reload the highest texture LODs behind me again. For me the place worked kind off. Even if my Bias maxed out at 3.5 at times. The Viewer I used is Second Life MemPlugs RC, which adresses memory leaks in the viewer. The massive load is coming primarily from the home: blank out the home (like I did above), and the blurring stops. This home is from a very reputable builder, btw. So I don't think it's really a 'bad' object so much as a 'fancy' object: the building is simply high-res with materials. And my furniture is high-quality too. Bias, for me, becomes problematic when it starts getting way over 4 (which it does very often for me in this home). At 3.5, like yours, some blurring still occurs, but far less obnoxious. I'll try out that other viewer, but, in all honestly, I don't think a generic memory leak fix is gonna take care of my texture memory shortage.

arton Rotaru wrote: Yep, I would like to check this out by myself, if you don't mind. :matte-motes-nerdy: ^^ And he just did. I hope he doesn't mind me saying, but he confirmed that this is, indeed, a texture memory issue. He noticed some big 1024 textures on a table and some other things. And one could question the validity of using those for such pieces (they're non-transfer, so I couldn't export textures to make em low-res, even if I wanted to). Still, with the materials-enabled home, the viewer simply can't handle the load. His Bias was consistently lower for him than for me, but he was on a different viewer (experimental Linden?), so it may be I had still higher settings somehow. At any rate, he observed the issue too. At some point LL will simply have to acknowledge that the potential tripling of your texture memory needs, that comes with materials, means that 512MB simply isn't cutting it any more.

arton Rotaru wrote: I just wonder how such an environment is looking like? In that video there are only a couple of objects in view, which shouldn't result in such an amount of texture data. The environment is the simplest you can imagine: 6 hollowed/cut boxes, with a texture on each of the 6 inner facings, Indeed, there's a wicked amount of texture data going on -- for no apparent reason, far as I'm concerned (once the scene is loaded, no need to keep reloading things). I did blank all textures on the home and furniture, btw (just for test); and sure enough no blurring of the environment takes place any more. Kinda makes sense, of course, as only 44MB texture memory seemed occupied at the time, LOL. Full home, however, has texture memory tilt the 512MB limit, and often over it. And the latter is, of course, what's causing the blurs and reloads: the viewer just won't give it the memory it needs. Tried this with a 'mini' 64m3 environment too; same deal: it will blur too. You're free to inspect it for yourself, btw, if you want.

I had the same issue, the other day. A helpful person in chat explained me how to get rid of it. 1) For starters, use a *black* background layer (which you'll disable later on, of course), instead of white: that way you'll immediate see the halo-ing without having to upload first. 2) 'Adjust levels' is your friend! Use it to throttle down the 'white' slider, until all halo-ing is gone. It's actually surprisingly easy, once you know how. Hope it helps you too!

arton Rotaru wrote: kiramanell wrote: Like your tagline, I'm not as dumb as I look. So, not specifically aimed at you, but please, please, no more dismissals or just blaming it on my router or something. Could still blame it on your SL environment, which, perhaps, doesn't suit the current limits of the SL viewer. :matte-motes-tongue: Just out of curiosity, what is your draw distance, and your RenderVolumeLODFactor in that video? Precisely: it seems my SL environment doesn't suit the current limits of the SL viewer. I 'blame' the potenttial texture tripling of materials (until a better explanation comes along). My RenderVolumeLODFactor is at 4 (shouldn't affect blurring of textures on regular prims at all), My dd is set at 512m; but even at 256m I'm getting the exact same issue (as expected: there's simply nothing in a 512m3 radius around the home, besides the environment, to render anyway).

Rolig Loon wrote: I did. You may not be the only one with the issue. :smileywink: Then look closer at my video, please. You can clearly see Bias go from ca. 3.0 - 5.0, That is NOT a HTTP fetch issue, but irrefutable proof of texture memory shortage (cuz that's what the Bias is: it increases when not enough texture memory is available to keep all textures at full resolution). Also, as you can tell from the texture cache menu, you can witness textures getting (re)loaded like crazy, even when I'm virtually standing still. There's no good reason for that (there's nothing present in a 512m3 radius either), unless it constantly discards textures because of texture memory shortage. Like your tagline, I'm not as dumb as I look. So, not specifically aimed at you, but please, please, no more dismissals or just blaming it on my router or something.

Rolig Loon wrote: kiramanell wrote: [ .... ] Clearly the viewer is simply running out of texture memory.[ ... ] Or your router is being swamped by a massive flow of data. Take a good look at http://wiki.phoenixviewer.com/http_fetching_issues Or you could look at my first post in this thread, and see that others have visited my sim too, and noticed the same blurring.

I figured it might probably be a good idea to illustrate the effect with a small video (see below). At some point you can even see the viewer (Firestorm) go into some sort of loading-loop. As outlined above, this only happens with certain scenes (in this case: a hefty, materials-enabled home), and not in general. Clearly the viewer is simply running out of texture memory. With the advent of materials (like I said, potentiallly tripling your texture memory needs) I was really hoping this doesn't get ignored, and that, at some point, the powers that be will increase viewer texture memory to accomodate for materials. And yes, I like high-graphics settings. To paraphrase Madonna: I'm a materials girl in a materials world. And I'm not throttling down on those (especially since my video-card offers 3x the amount of texture memory SL is willing to use).

Ren Toxx wrote: I've been using Firestorm for long, and this texture blurring (as related to the bias thing, and usually called “texture trashing”) problem has been a recurring one; almost for every new release it's changed, sometimes for the better, sometimes for the worse; the guys from Firestorm even came up with a few 'patches' of their own to try and solve this (namely, a flag for ATI cards that also made its way to the debug settings), but none has ever been quite definitive. I guess it's mainly because they have to get back to LL's ever-changing rendering code with each new release, and each time it somehow 'breaks' or makes the patch irrelevant. Which is why I always kept the TextureLoadFullRes setting in my quick preferences panel, to easily toggle it on the moment I needed to do HR capturing, and then off again without even needing to relog. Well, in all fairness to the FS team (who were very unwilling to discuss the matter, though), the official Linden viewer suffers from this just as much. Under normal circumstances, using a thing like TextureLoadFullRes is like messing with a process scheduler: rarely a good idea (even when ppl think it is). However, in this case, always blurring the farthest thing off isn't always a good idea either (especially with things like sky environments that are, by their very nature, meant to be persistent). So, I really wouldn't mind seeing a 'Persistent' flag on the texture options (like an individual TextureLoadFullRes=TRUE for the particular facing/texture of your choice in question). Still, in my stand-alone skybox (with nothing else in 512m3 range around it), Bias shouldn't have to swagger from 0.0 to (and inexplicable) > 4.0, when I'm not even moving. It's like textures have a ridiculously low TTL. When nothing new needs to be loaded, texture cache shouldn't go haywire all on its own (as if an entire new scene is being loaded).

Ok, who deleted my 5th post??! (posting it again) ChinRey wrote: It is highly unlikely that your problem is caused by cache overload. Even the most powerful computer would probably lag down to a crawl long before the cache gets overloaded by a single environment. Besides, a cache overload should cause textures to turn gray, not blurred. A more likely explanation is a bug in Project Interesting (see https://jira.secondlife.com/browse/BUG-5978 ). That's easy to check. When the problem occurs, open Develop Menu -> Consoles -> Texture Console and look at the Bias number. If it's stuck at 5, it's the Project Interesting bug. If it is, please add acomment to the Jira with any info you can provide. The case is currently listed as "Needs More Info" and anything we can do to help LL solve it would be greatly appreciated. Regardless of that issue, I agree with you about cache size. The more files we can store locally, the less load we place on the servers and the network and the less lag we get. Today even the smallest computer tend to have plenty of storage room to spare and it just makes sense to give everybody the option to use that unused resource to improve SL. :-) You should post a Jira about it. That's where suggestion for new features are supposed to go. Interesting post! My Bias seems to be at 0.0, most of the time, and sometimes jumps to 0.25. Highest I've seen it go is a whopping 3.75 (at which time blurring occurs). Nothing stuck at 5.0, though. Funny thing, though, is that just having set TextureLoadFullRes=TRUE (and relogging to undo it) still had a significant effect on the blurring, in that it suddenly happens far less, Still happens, but it seems to have had an odd revitalizing effect on texture performance as a whole. So, I went to another (busy) sim, to have my cache be filled with new textures; then TP-ed back, but the blurring is still significantly less. Most peculiar.

Ren Toxx wrote: kiramanell wrote: [...] there should be some way to override the viewer's rather crude way of blurring everything that is fartherst away. Some sort of texture 'persistent' bit. Debug settings > “TextureLoadFullRes” = “TRUE”. But it's not a persistent setting (it'll go back to “FALSE” on next relog), and I've found it makes the viewer a bit too crash-prone, so I only activate it for HQ photography. Yeah, I'm familiar with that setting. Granted, it stops blurring (discard = 0), but makes SL unplayable: FPS drops to about 3fps. Interestingly, bound texture memory is around 900MB that way (nearly twice what the viewer is normally willing to commit). So, basically, the scene is telling SL it needs 900MB, instead of 512.

I own several high-quality, materials-enhanced mesh homes. Whilst beautiful, I'm beginning to eperience issues with the limited texture cache of only 512 MB, in that stuff around such a materials-enabled builds has a tendency to bur like crazy. After enduring being relegated to many helpdesk documents, telling me it's probably my router, HTTP-fetch issues, and what not, I was persistent enough to get some reputable builders come over, and witness how, indeed, my 512m3 sky environment (with just 6 basic textures) keeps blurring for them too. At long last we concluded what I had suggested all along: that the materials-enabled homes (potentially tripling your texture memory needs) keep pushing everything else out. I brought up the matter in several online support groups, where it met less than enthusiasm (to put it mildly). Fine. Like always, though, sticking one's head in the sand rarely makes an issue go away. The matter remains that 512MB is just beginning to be too little. Especially since any half-way decent card has 1.5G to begin with. So, why not raise the limit to 1.5G? If your card has the room, why not use it?! (Cards with less would simply use less). The 512MB limit is not hard. And it's viewers limiting themselves. Bao Linden said (emphasis mine) "This cap is a soft cap. It tells viewer it is good to make the total amount of textures to follow this cap. But if this cap needs to be overflown to make all necessary textures sharp enough, and viewer has resource to overflow the cap, viewer will do it. Of course VIEWER WILL IMMEDIATELY REMOVE UNNEEDED TEXTURES to follow the cap if the situation changes." Even if it is not possible to raise the limit that high, there should be some way to override the viewer's rather crude way of blurring everything that is fartherst away. Some sort of texture 'persistent' bit.

Can't log in either. Getting persistently "Unable to connect to a simulator." error. What the heck is going on?!

A far better explanation than anything in the FAQ: http://blogs.msdn.com/b/shawnhar/archive/2009/02/18/depth-sorting-alpha-blended-objects.aspx

Okay. It involves an opportunity. I have to say it's a huge opportunity. That's more than I should say but there it is. Lemme guess... I *may* already be the lucky winner of an Audi A8, and all I have to do is fill out the card and send it back quickly to find out, right?

P4NDOR4 Quintessa wrote: That is really freaking HANDY. I am a sim builder who, only after packaging a sim build realized there was something weird about the linkset distance, and now, I have to some how magically be able to measure the distance between prims so to make sure I don't overstep the linkset distance, all because you FAILED to notify all people building on the grid this can happen. And how am I even supposed to be able to measure the damn distance, you just wasted 4 weeks of my freakin time and a months teirs, not to mention the 2 people I have waiting for sim bulds that I can't do till this is fixed. Thanks a freakin lot. I say you are being a bit unreasonable here: as an experienced builder you relied on a behavior you knew was too good to be true; and instead of asking for confirmation, like the topic starter was wise enough to do, you just hoped 'they' wouldn't notice. Well, they did.

Syrah Xue wrote: A similar problem has ocurred on my parcel, it has become impossible to edit linked items they simply spring back to their previous state after adjustment. Making it impossible to add the finishing touches to a large build. Actually, I can confirm this part: I rezzed a home the other day, and whatever part I tried to edit/move, it kept snapping back to its previous position (consistently, over days). Very weird. Only way around it was to unlink each item which needed moving first, then move it, and then link it back. This was a somewhat older home, btw (re-rezzed from inventory). An adjacent home next to it wasn't afflicted at all. Also, I noticed a similar effect on trying to change prim color, recently: color has a tendency to persist, and keeps reverting to previous color (unless you try it several times). One gets the impression these things are all related somehow.

valerie Inshan wrote: You would have to link all the elements (house, plants, objects...) but it's gonna be tricky, plus a linkset is limited to 256 prims. The easiest way would be to derezz your house (simply delete it, assuming it is copyable as 99% of houses are) and rez a new version at the chosen point on your land. If it came with a rezbox, don't delete the box until the house is the position you want. Select the rezbox in edit mode and use the directional arrows to move it: it will move the whole house altogether. Once the house is where you want, save and take the rezbox back to your inventory. If the plants and objects do not come with the house, you may link them and move them to the house's new position. (Or pick them back one by one to your inventory and simply put them in their new position). Here's about linking objects; http://community.secondlife.com/t5/English-Knowledge-Base/Build-Tools/ta-p/700039#Section_.5 Sorry, but this isn't particularly good advice. Arbitrarily linking furniture and homes together is never a good idea, and may have very undesireable side-effects (the least of which is making it a lot harder, in the future, to treat them as separate objects; worst case: you may break the furniture and/or your house). Also, make sure all objects inside are all *unlocked* first. Then do as Tamara said above. If the furniture is mod, you can try a packager like rez-faux too.