|
|
|
Anyone with example content, please send it to me inworld. I'll also let Qarl Linden, who developed sculpties, know.
Nomasha - have you tried pre-loading your textures - and keeping them in use? (on invisible prims hidden within your horse, for example...)
when textures are out-of-use in the client - they get unloaded. i believe that's why you're seeing bubbling - the client is reloading the textures over and over and over and over.... Qarl - i've tried putting the textures on a pr-loader prim for another animated sculptie (the horse has nearly 100 so this one is easier). It does not solve the problem. SL (or my client) looses the texture somehow, the sculptie reverts to a sphere and the texture on the pre-loading texture prim goes black.
Torly - I will send you both a copy of the other animated sculptie which it will be easier to see this on. I have no idea if it will reproduce on your puters (Qarl - you said it did not on yours but it does on mine and many other clients).The problem is intermittent. I have noticed that since a few updates ago - sl is constantly loosing textures and the surface goes black or looks like a distorted coloured pattern even though the textures have already loaded fine. Ive been working with nomasha on this, what he cliams is true. textures do "de-rez" even if they currently "invieuw", i think it does help a bit but it doesnt solve the problem. since a few updates (like months ago) stuff started derezzing/ deforming. animated sculptures bubble even when you fly around the sim even with regular objects, this could perhapse be a "limmit" on textures i realy dont dare guesing how things work. being closer to it also effects it somewhat. also having the object in edit matters.
I also noticed that less powerfull systems have more problems, and playing with the vid settings effects it somewhat. it could be verry good somthing in the client witch bottlenecks this.. again i dont dare saying for sure. The mac version ive understood MAC is based on the windows one, both have it.. and not exsactly at the same time. but its clearly not working without problems.. even with workarounds like preloading textures on hidden faces. i doubt the texture pool for sculpties & textures are the same. if they where preloading on a loose face would work right? or is it just the sculpties being bottlenecked? workarounds like offsetting textures to a other part is not posible with sculptures as manny workarounds are not compatible. Thanks Nomasha, I got your objects.
I wasn't able to repro this on the following setup, which is high-mid range, but not terribly extravagant:
CPU: AMD (Unknown model) (2010 MHz) Memory: 2048 MB OS Version: Microsoft Windows XP Service Pack 2 (Build 2600) Graphics Card Vendor: NVIDIA Corporation Graphics Card: GeForce 7800 GT/PCI/SSE2/3DNOW! OpenGL Version: 2.0.3 LLMozLib Version: 1.1.0 (Mozilla GRE:1.8.0.12_0000000000) Packets Lost: 2/12738 (0.0%) Viewer Digest: 45026cd0-b4b9-de21-c598-2bbbb0ddf073 Altho I have been having general slow initial texture loading, recently... This is an example of a texture that repeatedly rezzed then de-rezzed. It is both a sculptie texture on the red prim and a surface texture on the square prim to the right. Next image shows both de-rezzed.
Notice both the sculptie and the texture on prim have gone black - despite having been stored correctly in cache.
This is a similar effect I often see whereby a texture seems to degrade into an unfocused coloured patter. No matter what the texture is, the effect is the same.
Sorry, my above three comments relate to the new screen shots I have uploaded. So many other residents I have spoken to have seen both these effects since a few updates ago. As I say, I suspect this has gone under the bug-reporting radar as it is not a critical bug, but it does completely preclude the use of good animated sculpties. All my sculpties (animated or not) will revert back to a sphere at some point, even though they might have already loaded successfully. Often they will take the shape (sculptie texture) of another sculptie already in cache - a horse leg will often pop into the shape of a shark I have made for instance.
For what it's worth (though it definitely happens on other systems, I am running a Dueal 2 GHz PowerPC G5, 2 GB DDR SDRAM, Mac OS X, ATI Radeon 9600 XT: Chipset Model:ATY,RV360 When viewing Nomasha's sculpites..I see the same thing he does. At first they appear normal but after a short time the begin bubbling.
Yes! Since a few updates ago, I've definately noticed that textures seemed to rez fine, but if I turn away and turn back again, they seem to have disapeared. The textures look like the first picture above in Nomasha's attachment.
@Nomasha and others affected: do you also see these undesired glitches when these sculpties are placed out in the middle of nowhere (e.g., an almost-empty island) with few other objects around?
I've been experiencing extremely slow sculptie rezzing recently... the textures can take 10-15 minutes to show up. Predictably, it's even longer for animated sculpties. I don't know if that's related. I'll keep an eye on this. Sorry Torley, my last comment was about the new movie i put up above ( a little big), it shows a texture de-rezzing in the act. Hadn't realized you had posted when I did.
Mmmm.. good question and the answer is cautious yes. I have been working on an empty corner of the sim making a 10 part sculptie and this has been having the same problems. I am absolutely certain that it is related to general textures de-rezzing, which seems to happen on so many clients. I have been asking people daily if it has happened to them and i reckon 80-90% say yes. Just my luck that you and Qarl are on setups that seem to handle it. Qarl mentioned possible Dram (Vram?) and i have been looking into this a little and seems to make perfect sense. I know that is a client side issue on the surface, but there is a server set-up problem surely as so many clients struggle with the problem. The new video above (if you can be bothered to let it load - be good if you could!) shows it actually happening - although it is a surface texture that disappears (on the chest of the second robot from the left). You can see it suddenly go black and this is while it is still in view. The usual trick of going into edit mode and selecting the object snaps it back in. However, this is NOT related to what you are describing I believe (slow loading textures) this is about them disappearing from cache after they have loaded - different thing i believe. The point is, that on the cube next to the robot, you can see that I have set out the sculptie textures for the robot's chest for pre-loading purposes. Very often, the sculptie will pop back into a sphere and the corresponding surface texture on the pre-loading prim goes black at the same time. I have not managed to catch that on video yet and I am sure you will take my word for it. It is unfortunate that this example is in a prim full area (relating to your question), but as i say, it seems to happen everywhere. Have you tried recreating in a very laggy areas perhaps? Anyhoos, the point is that there is lots of lovely suff i am chomping at the bit to get out into SL, but cant because of this. I know that it might not rank as a critical problem to most people, but it is seriously holding back very many good sculptie animations that SL has never really seen the likes of. ^ OK, great, thanks for the new info, I understand how this is a impediment to creating more dynamic sculptie content. I'll let Qarl know of your newest comments too!
hey Nomasha - are you still seeing texture de-rez as of the latest release? (specifically, textures going to garbage and/or black.)?
hey all -
i've asked around. this appears to be a texture corruption bug which we suffered from (and fixed) last month. since i haven't recently seen it myself in the last couple weeks - i'm going to close this issue. please re-open if you're still seeing either garbage or black in your textures (and/or sculpt maps.) Qarl, sorry, hadn't seen your comments. Afraid it's not at all fixed, textures still going black just as much and sculpties (esp. when animated) still popping back to spheres. Nom
let make sure we break these into two issues:
1) textures going black/garbage and 2) unloaded sculpt maps cause sculpted prim to be a sphere. if you've seen (1) recently, or can reproduce it, please send me a screenshot and/or location and/or script when it happens to you. (we may also need your system details.) now, let me be clear - we do not plan to address (2) at any time soon. we've had proposals to "leave the spheres", "keep the previous shape", "morph from the previous shape", "leave the shape invisible", "make the shape a mushroom." given that there is no community consensus - and that the current behavior is generally the most expected behavior, we're leaving it as-is for the foreseeable future. Thank you Qarl, let me be clearer:
This issue, as i stated above, is not about "unloaded sculpt maps cause sculpted prim to be a sphere" as these textures have already loaded into cache. The issue is about them not being drawn from cache once they have uploaded (vram/dram - not my area). Your 2nd point (above) is of no concern to this issue. If they don't load in the first place, I don't care what shape they assume until they do. The problem is they "unload" themselves somehow. Your point 1. (above) relates to the loss of the sculptie shape as is shown in the "Texture de-rezzed.jpg" & "Texture rezzed.jpg" above. When the pre-loaded sculptie texture on the face of the prim on the right of the image goes black, the corresponding sculptie (next to it on the left) looses it's map texture (the same texture) and reverts to a sphere. The prim with the sculptie texture preloaded on it goes black, at the same time, the sculptie itself reverts (which uses the identical texture). The crucial point is that the texture was already loaded on the screen and THEN it goes black/garbage. I have just posted a new example called "rezzed 1.jpg" & "derezzed 1.jpg". The textures highlighted in red marker had already rezzed and then disappeared, turning to black. When the texture is a sculptie, not a surface texture, the sculptie reverts. As explained above, the preloaded sculptie texture that is placed on a prim nearby turns black (see "Texture de-rezzed.jpg" & "Texture rezzed.jpg" again). This new example occurred at approximately 1.05pm (PDT) on "Nomasha Syaka 68,50,21" - I have already posted my system details, but here they are again - more detail. ATI Radeon 9600 XT: The example just given has a texture swapping script in the face of the tiger on the left, but not the ears, the cub on the right has no scripts in it. It happens without any scripts. Regarding the texture De-Rez issue, ive come across it many times with standard textures, i have one texture that i use on nearly everything i build and its on my attachments at all times so it should be pre-loaded all the time, but when rezzing it on a new item the texture comes on crisp, then a few seconds later degrades a little, not a total degrade just one level of blurryness
 .
I also bought nomashes sharks wich are the funkyprim ones.. the animation of the sculpty randomly turns into spheres sometimes, not all the time though, sometimes it will work ok for a fwe hours at a time and other times not. I deeply suspect the cause of this is that the sculpt maps are not correctly being timestamped in the texture cache.
As an empirical test, if you place the sculpt textures on a cube sitting near the animated sculpty- If its not the texture cache, my next less likely guess would be an order-of-operation\race condition between setting the sculpt map UUID and setting the sculpt mode. Oh... one other thought... what are the priority of sculpt maps in the cache? Is it possible something is bumping them?
No Zora, thanks for the comment, but you are wrong and the problem is most definitely no resolved this way. Pre-loading textures, as has been mentioned a few times in this jira issue, does not solve the problem in anyway. In fact the matter is expensively discussed in conjunction with photos of pre-loading above (4. Texture de-rezzed.jpg 5. Texture rezzed.jpg). You can see the pre-loaded texture on the box and then see it disappear.
Hi All,
I had just posted under VWR-1153 and will repeat here that I think animated sculpty issues do need to be addressed. It seems if the shape is recently used (less than a few seconds) it loads normally. Longer time periods seem to cause the sculpted prim to show as a sphere (the default shape of the sculpted prim). Quarl & Torley, I'll send a copy of my most recent animated sculpted object. The offending behavior is caused by nothing more than calls to llSetPrimitiveParameters with a PRIM_TYPE_SCULPTED command. Is it at all possible to load a sculpted prim shape without re-defining it's prim type and would that solve the default shape being displayed? Just a quick update, I feel a bit late to the party here as I've postponed really utilizing sculpted prim animations until last month to let the new technology mature for a few months after release. I agree with the previous posters that the switch to default prim shape (as shown in the horse video) is occuring with shape data that has previously been loaded & displayed. Switching between shapes within a second or two does seem to work fine, (at least on my setup) but longer delays between shape calls seems to cause the default bubble to show.
This appears to be related to the client's handling of shape data rather than a problem with the lsl code itself (although there may be a variety of ways to address it). This also appears to be much much worse for some people than others, as my PC desktop (4400 AMD 64x2, 2GB DDR2 RAM, 320GB SATA HD) & Mac laptop (MacBook Pro) both see this behavior only occasionally as described above but I've heard from a few residents that their animated sculpted prims are nearly always ball-shaped. I note the fix pending status, would love to know any details if Qarl or Torley could post a quick note. Would be nice to have something to tell content users if they're experiencing this problem as it can be very frustrating. If there's anything I can do to help just let me know... looking very much forward to using sculpted prims more as time goes by! They don't care about this anymore - no posts from a Linden for nearly 6 months.
this is caused by your client running out of texture memory. if a texture is unused (even for just a few seconds) it is unloaded. if you want to prevent your textures from unloading, merely keep them in-world (on a hidden prim, for example.)
nomasha - the problem you saw earlier (textures going black) was fixed long ago. if you're still seeing that same behavior (i.e. you can recreate the problem above) then please reproduce the problem.
also, i'd like to mention that if you are infact using all your texture memory for the animation - there's nothing we can do to fix it. buy more vram. Qarl - I am not using all my texture memory for the animation. If I place the animation out in the sky with nothing else around, the problem is still there. It has not improved one iota, nada, not at all. As far as trying the pre-loading textures on a prim is concerned, assuming you are suggesting this (again) as a fix for animated sculpties, we are going over old ground, it does not work - which makes me understand that the matter has never been given any real attention. This problem is simply not fixed and is not being addressed anymore. The issue was posted in June 2007. To suggest that I need more Vram is a cop out - if LL are providing a feature that most (if not all computers) cannot handle, it is not everyone's Vram at fault. I have shown this horse to very many people now and have not come across anyone who does not see chronic bubbling after a while - though inevitably, you will find someone who it works fine for. I myself have viewed it on three computers, all fail.
normasha -
please send me (via email) all the textures for the animation you're having trouble with. i'll debug the problem when i return from my leave of absence. Hi Qarl & Nomasha,
>>if a texture is unused (even for just a few seconds) it is unloaded<< ... I do tend to call texture shapes out of sequence, and this does appear to be what is happening. Like Nomasha I test in an area with little/no textures and still see this, and as I've mentioned previously I am running on very new hardware here. So long as the textures are in vram the animations appear to be smooth & predictable. When you say "unloaded" Qarl, am I correct to understand the texture is still present on the hard drive or RAM? If so, the default shape is being displayed while the client loads the texture to texture memory? I think what us animators are looking for is some way for the client to handle textures that are present on the computer but not immediately available. If the textures are being removed altogether and need to be re-downloaded from the server what may eliminate this for 90% of the users would be to save the data someplace easily accessable to the client until the resident leaves the sim (if that's at all possible). Nomasha - i've created a sculptie animation demo located here: http://slurl.com/secondlife/Q/95/70/35
 it preloads the sculpt textures on hidden prims - it consists of 50 frames. i do not see any trouble on the three machines i tested with. please let me know if you see any problem. Cloud - i hear what you're saying - you'd like for some way to keep assets available for immediate use, even if they are currently unused. currently we have a mechanism for audio files (via LSL) but nothing for textures, sculpt textures, or animations. someday we'll likely add this - but seeing as there's a decent workaround right now (see the sculptie animation above) it's a low priority. Hmmm, I get a lot of feedback from people that this is a real issue for them. I'll try the prim face solution, although reading back through this post others have said that has not been entirely effective.
This proposed solution also introduces new issues. Right off quick I can create a prim with 8 sides. Using this hack, your single prim, 50 frame object would need to become 8 prims, which somewhat defeats the purpose of using a sculpted prim with multiple frames, especially if users want to have multiple copies out - and I'm still young enough to remember just how little a 512 plot can hold. The alternative - having a standalone object with textures is equally troubling - will new users understand how & where & why this extra object needs to be placed out? Will content owners want to rez multiple objects every time they pull out their animated sculptie? The workaround (if it does perform as stated for the masses) is really still problematic from a practical point of view. I'll see what I can do, but I'm getting tons of feedback... "do more animated sculpties" and "the balloon shape is really annoying, how do I fix this??" Content users are pushing for this functionality, as a creator I'd love to see a preload function for shapes. Without that functionality us creators are going to be held back from doing some really cool stuff for SL. Nomasha - i'm still curious to hear how the preloading test went. i do believe the trouble you had was because you had accidentally missed some of your textures.
Cloud - again - i hear you. but like i said before - there is a perfectly good workaround (yes, you need a prim for every 10 frames of animation) so this feature has a low priority. Qarl - just got back to the UK, give me a few days to get sorted and i'll run a test on a couple of puters.
Hi Qarl,
After some testing it appears the preloading does work, however I believe it has some serious security issues. I can discuss this offline if you like (so as not to expose a potential security issue), but if my experience is correct content creators should be made aware that this method may leave their sculpted works open to copying. Considering how many hours go into some of these models that alone would make this workaround unusable. I'd be glad to have someone verify this as I have only tried it on the Apple, I'll try the desktop PC in the morning in case it's a platform specific viewer issue, though I doubt it is.
Good Morning, I just verified the workaround security flaw problem is platform independent. So, it's back to using 30 prims with 30 or more scripts for me until this sculpted prim bug is fixed - I really enjoyed working on more efficient builds though. I don't know how to up the priority on this other than to send content users here to vote & post that this is important to them. It's unfortunate because with the preloading test fixture and the sculpted prims working like they are supposed to the results are fantastic, it's jut too bad no one else in SL is going to be able to see content running like this anytime soon.
While I am not a very efficient scripter, I have done extensive testing of this issue for cloud insoo. The issue of ballooning of objects animated by sculptie shapes is real. The workaround solution of presenting all sculptie textures nearby does in fact work, but then, there is a severe security problem with doing so, even with hidden prims. I have tested on sims that were extremely laggy, and the animations work fine if texture maps stay near the observer (not the animated object). When textures are removed, ballooning returns. Having several animated objects the same, running together helps a small amount, but does not eliminate the problem. The ballooning of texture animated sculpties makes them useless. This needs to be fixed if animated sculpties are to be useful in SL. Just for info, I'm running a dual processor (not dual core) 3.2 gHz with a 512 nvidia card, 3 gig of ram. Right now SL is using 622,552 of my ram (and growing, of course)
please do let me know about any security concerns. but if it's merely the issue of "the sculpt texture is visible in the tool window" this is a known issue, and it too has a workaround: use the alpha channel to hide the image.
Yes I was referring to the tool window issue, though strangely I don't seem to see it listed in JIRA. I'm implementing the fix for this as well, however the practicality of implementing these fixes still leaves much to be desired.
Yes, I have tested pre-loading on both my old and new macs and it now appears to solve the problem. Loading textures as alpha is an awkward but doable work around for the security issues, likewise, pre-loading is awkward but doable. I hope that this does not mean that the issue is dropped for a very long time, but it is a viable step forward for the short term. To this end, I would suggest that this jira issue is not closed.
I'd like to second Nomasha's recommendation that this issue remain open with (I can hope) an eventual actual fix for the problem. I've implemented a preloading device for content users and provide it with their sculpted objects. I still get many, many IM's from people that don't understand the mechanics of animated sculpted prims and don't understand why they need preloading. And regardless of whether the preloading is done externally or in-situ we are being forced to add prims to the sim that otherwise would not be needed. The workaround does always make the sculpted prims perform properly, but it's an unweildy solution for both content creators and users alike.
One way to address the security of having the sculptmaps visible on a prim, is to have them on multiple prims that intersect (same size same rotation same location) and make them all semi transparent. the result is that the background bleeds through (making sculptmaps capture useless) and also preventing determined buggers from useing 'hide selected' and other advanced render features from lifting your hard work.
Qarl:
In regards to your comment about the alpha channel work around - I personally have been telling everyone NOT to do that because of the possibility that this workaround will be broken in the future when you implement flexi-sculpts. The idea is that any sculpt map that has alpha channels could turn to jelly when flex is implemented, causing everyone who used this technique to a forced re-upload to get their products working again. Please correct me if I'm wrong about this, but I do remember your comments on the Wiki: "yes, we're thinking about how to do the flexible version. currently - flexible objects have a 1-dimensional spine that drives their motion - i'd like to make the sculpties a 2d spring system (if possible.) also - we have this unused alpha channel, which would be perfect for adding flexi information (how stiff/springing is this section of the object, etc.)" --Qarl Linden 09:52, 28 April 2007 (PDT) Perhaps I am looking too far in the future... or maybe you have found a better way to do this that does not involve the Alpha channel? Nulflux -
you are right - but no it's not a serious issue. because so many people use the alpha for other reasons - if/when we decide to use it for flex/skinweight data, we'll use an additional flag on the prim to indicate such. (otherwise we'd break a lot of content, which is BAD BAD BAD.) one other thing to go is keep the texture visible in world at all times. A cut hollow box can display 9 sculpt map. make the box 100% alpha so it is not visible but the client it not send the sculpt map to the trash. I have seen this used in many places and I use this concept in my builds as well.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Reopened
Major
Animated sculpties are intermittently not working
Can you please provide a repro object? Feel free to send it to me inworld; if you can, rename the object to have "MISC-333" in its name. Thanks.