Rick Nightingale

Yes, I noticed script performance is low; hovers around 50% scripts run on the stats panel, and there's a touch of time dilation. Doesn't seem to cause any issues for me (well, assuming the animesh isuue isn't related to that). Max avatars is at 30; there certainly aren't that many skeletal things here. The stupid trees are still behaving! That's the first time in three days (since I rezzed the trees) that they haven't vanished more often than not.

Very quiet. It's a homestead I rent a third of. Hardly ever see anyone and there's not much around (except a gazillion snow rezzers someone on the opposite side rezzed; it's blacklisted/blocked).

I'll try next time. I've removed most of them but will put some back for testing. The animations can be turned off in the menu; I'll see if that helps too. Wish I could untick 'Animesh'. Edit: Who told my trees they're being watched? They are behaving now, lol. It won't last (unfortunately).

Nope. Unusually for trees from this creator, they are no mod.

Hmm... good idea (although it would be a shame to lose the nice animations.) At least I could still use the trees. I'll try shortly...

Some interesting points: I can select the trees even though I cannot see them. Render Metadata shows their collision skeletons. When selected, the Object LOD Behaviour details in FS's edit window are not what the trees should be. It's currently telling me an object radius of 0.966, first LOD switch at 4.1m and similar extrememly low switch points (for a 25m high group of trees) on the rest. By contrast, selecting a group of them which is currently visible gives an object radius of 58.754 and first LOD switch at 275m. It's like the object is just collapsing to some minimum 'thing'.

Yep, definitely. Thinking about it, I might have seen it before with other things too. Not often though. These trees though... are unfortunatley useless to me. They are missing as often as they are there, leaving gaping holes in my landscaping. I'm about to replace them. Shame... they are really good trees, fantastic LOD behaviour, nicely animated, exactly what I needed for long distance (and closer) trees on my land. Would be perfect if not for this issue.

After a chat with the maker (who is very helpful) it seems there is an issue; they've seen it too. I can only think there are issues with the viewer code that cause the trees to not be displayed. There's nothing wrong with the trees themselves. (I've made a little animesh, like an animated mermaid... I can't think of anything you could do wrong with it to cause this effect). They did have one comment I hadn't thought of that might be relevent to others... Maximum Avatars setting. Since Animesh is effectively an avatar, that might cause problems if set too low. LL... you need to look at animesh rendering!

Yep, doing that. (I hate that viewer). The issue seems to reproduce on initial testing. The trees have vanished competely twice; once when I TP'd out and back and once just when I turned around. Both times I was only about 50m away (Ultra settings, 250m draw distance). All other (non-animesh) trees around the same place were there. Both times though the missing animesh trees suddenly appeared after a few seconds. I'll have to just do 'normal stuff' with the viewer and see how they do, since the issue is random. Urghh. Linden viewer. Edit: yes, definitely repeates in a fresh install of the Linden viewer. I'm looking at my land right now after TPing away, waiting a few minutes, and going back. Both rezzed sets of the animesh trees are missing, everything else around them is there. I can even see the animating shadow of one set of the trees on the side of the hill. But not the trees. I'm cammed right up to where one set should be and can clearly see the animating shadow. Still not there after walking and camming around for five minutes, trying to provoke them to appear. I've walked right through where one set should be. I'm stood underneath them now, seeing animating shadows on the ground of phantom trees.

I'm sure it's not LOD switching; it happens stood next to the trees and the first switch point (from high to medium) is 500m at LOD factor 3! Even the lower LOD models on these trees have enough left to see the tree is there. Lowest model has 308 triangles, unlike many other trees around here which drop to one or two for the last two LODs. Yes, I know. I spend hours tweaking low LOD models myself to make sure the object still works as far as it can be seen as more than a point on the screen :) Even if it reduces to a photo on a crossed plane, which is remarkably effective if the thing isn't meant to be retextured.

I've recently bought some large animesh trees. (20m high, group of five animated trees as one animesh item). They are constantly vanishing, and sometimes flicker very rapidly visible/invisable when I look at them. Even cammed right up to them. It's just these trees; nothing else. It's random when it happens but is frequent enough that there must be a problem. My LOD factor is usually 3, draw distance well beyond the trees and I'm well within their first or second LOD switch point. The effect happens even if I'm stood right next to them. They can be visible one moment, I'll turn around and they are gone. Highlight transparent does not show them. Sometimes I'll TP in to my land, and the trees are not there. Sometimes the shadow of them remains, while the trees are invisible. TPing out and back sometimes brings them back, camming far out and back (to try to get the viewer to redraw them) does not. The flickering was the weirdest thing; I thought my viewer had crashed (latest available Firestorm) and relogged. Then it happened again the next day. Graphics settings are Ultra on a decent PC with a GTX 1080, I've not tweaked anything in debug settings and I can see other animesh items without a problem. (I've even been expermenting making some myself - no problems seeing those either). Any advice? I've also contacted the maker of the trees; awaiting a reply.

Ahh... My mistake, there were one or two(!) particle emitters in the region, albeit on the very opposite side and double my 96m view distance. I thought particles outside my view distance wouldn't have effect... clearly that's wrong. By one or two, I mean someone had so many snow rezzers over their house that the text shown by Render Metadata filled the screen when I cammed over. I wonder if they've noticed hardly any of them are emitting... or perhaps they just rez another when there's not enough snow! Anyway, mystery solved. Derender/Blacklist saves the day.

There aren't any. I know about particles. The objects I'm talking about that are failing are mostly my own made; I know the particle rates (well, I don't off hand, but I know it's not much). There's nothing else anywhere near me with particles. I'm in the middle of my third slice of a region.

Yeah, should have said... maximum 8192. I'm using a 'gaming' rig. It's not being overloaded and everything works just fine back on my old mainland parcel, and everywhere else. Even looking at just one thing with a little particle sparkle in this place shows the intermittent firing.

As the title... on my new home(stead), all my particle effects fire only intermittently. I can't see why that should be. Surely particles are just a viewer-side thing (once put in the prim properties)? They'll fire a few particles, then stop for several seconds, then fire a few more. All the objects are working properly and work as normal elsewhere. Scripts are not interfering. Just at home, my fireplaces no longer burn, the snow particle emitter I'm currently wearing for my own personal snowstorm barely does anything and my twisted protocubes (I make them) don't sparkle. So, is this expected behaviour? Edit to add: This happens with Firestorm and official viewer, and on two very different PCs.

Interesting discussion, thanks folks. I tested like crazy in Aditi and I think it's turned out OK. Almost everything is traingle physics, with just a few bits that worked out better (from my point of view) to use hulls for. I tried really hard to break through walls etc. without success, lol. There are a few places left that, if I try hard, I can caatch a triangle edge and walk up a little, even with a lean-in, but I've hidden those in corners no normal person should be mucking about in. I designed my house as external and internal 'shells', rather than by making walls as such, so using hulls would have been much more troublesome to design after the fact. Anyway, it all works well, even my spiral staircases. Now I'm playing with assorted texture ideas... something I'm even less good at. Plus there's still some small mesh details to add (like roofing fascias) which I'm doing as I feel like. Everything you see except the unicorn and the bench seat is mine:

Ahh... that would work perfectly on the part I was doing just before I posted. It has an overhanging edge anyway; I nearly did incline the physics there to save a few triangles. I'll give it a go after I've finished the current part. Thank you

I've been unable to find any mention of this phenomenon anywhere, which surprises me, so I'm mentioning it and asking for comments 😀 I much prefer to make my physics models from triangles, instead of using the non-touching cube method. If I make a vertical wall though, say for a house, it will work perfectly in every regard except that I can walk up the wall. It seems that I'm walking up the edges of the vertical triangles defining the wall's (flat, vertical) physics. I have to lean slightly into the wall as I walk along it to do this, but it happens everywhere there's a triangle edge near me and I end up walking diagonally up the wall as if there's a hidden ramp. I've even been able to climb all the way to the top of a 10m vertical wall like this and stand on the roof. If I analyze the mesh into hulls this doesn't happen of course, but then the attached roof or floor has the floaty-walk issue. Is there anything I'm doing wrong here, or is that expected behavour from vertical triangle physics?

Ooh... I'll give that a try once I finish texturing the thing, which I'm in the middle of right now.

I have a large amount of custom normals in my house big East European style castle/mansion build. I use either data transfer modifiers or, more often now, 'hardened normals' when bevelling. (I don't recall that option of Blender in the past... maybe I missed it but I've found it now and I love it!) Unticking Triangulate when exporting causes the uploader to mess up the triangulation, with open spaces in the ngon mesh (like a doorway cutout in a wall) being filled in incorrectly. Ticking Triangulate and letting Blender do it causes the custom normals to upload badly, with odd shading effects on the bevels. Is there any way to avoid both these issues, other than my plan of manually triangulating the whole build before uploading (with Triangulate unticked in Blender)?

I'm guessing about the hidden triangle because on my first test, deleting the last material triangle removed two vertices from the vertex count in the uploader details (one vertex was shared) but the number of triangles stayed the same. Hence, a triangle added back in. I could be completely wrong of course. Whatever... I'm impressed. I was impressed when I came back to making stuff and found that I can select 'cube' in the physics panel. Saves ages during testing and anoyingly having to count all the cubes I need when uploaded a large linkset (usually a house).

This one took me by surprise... does everyone else know about it, and when did it happen? I uploaded a simple model for testing, a window, and then remebered that I had deleted all the faces for one of the materials in the lowest LOD model. Then, I realised it had uploaded without complaint. Surely I had made a mistake and missed deleting a face, but no. To my shock, another test without *two* materials also uploaded without complaint. I'm guessing the uploader is automatically adding in the missing material/triangles and somehow hiding them in the mesh, since I cannot find them on the lowest LOD model in-world. (Can you have a triangle with one vertex for all corners?) So... is this just Firestorm? When did it happen? It saves me from that annoying 'material in not a subset' or whatever it says when I get careless, lol. Edit: OK, slighly misleading topic heading I realise. You still do need them eventually, but can leave them out of the model and let the uploader take care of it.

Really sorry for the late reply - I did check my thread but somehow missed that you had answered me. The error is definitely linked to having the lower LOD level models parented to the first model. I've reproduced it loads of times and given up on using parenting now. All the models are named correctly; there's nothing amiss with them. If I unparent them them before exporting from Blender, everything is fine. If I export them (individually still) while they are parented, I get the error. In the uploader in Firestorm, I notice that the 'number of vertices' etc shown for the models says the same for the lower level models as it does for the LOD 1 model, as if it is loading the same level 1 file... but it isn't and the file sizes certainly look right for the lower models. I've no idea if it's Blender or the uploader that has a problem, or if I just should not be exporting models while they are parented for some reason; i.e. it's user error If I get chance I'll make a very simple test case for you and send it on; I'll let you know.

This has driven me batty... I've made a simple archway, starting with my LOD-2 model and parenting the others to that so I can duplicate and manipulate them all together easily. The LOD-1 model then adds beveled edges to a duplicate of the LOD-2 (and parented to it). I use either "harden normals" on Blender's bevel tool, or the usual data transfer modifier to make the custom normals and give a smooth shading to the bevel. Fine so far, and hardly my first rodeo. I've spent hours trying to figure out what was wrong with my (very simple) mesh because the uploader refuses the very first, LOD-1, file instantly I browse to it. It says, "LOD level has no parent" or similar, and the error log has almost nothing. It seems it simply rejects the file immediately it sees it, and then complains that there is no LOD-1 model at all. Turns out there's nothing wrong with it... If I unparent the mesh, it uploads perfectly. If I parent it again, it fails as above. It's as simple as that. Has Anyone seen this, and am I doing something wrong? EDIT: Not sure the above is strictly accurate as to what is happening now. There's more to it. Investigating...

https://jira.secondlife.com/browse/BUG-231269