Beq Janus

@arton Rotaruis likely right, use the scale control on the uploader to make the import larger, or scale it in your mesh editor before export. There are problems doing this because you cannot always easily scale it back down. It "might" be helpful to see the debug output of the log tab of the mesh uploader (though it might not shed further light) Mesh Asset Validation failures are ALWAYS because some part of the upload preparation has resulted in an invalid mesh. My guess (and that is all it is) is that in the case of the tiny parts you are using, the likelihood is that the quantising of the mesh coordinates has resulted in a zero-size object that fails to match when searching for LODs.

In blender, make sure that you are in object mode, then ctrl-A and select scale from the popup menu. saves all the faff later.

That is likely to be some form of FIRE-3260404 and FIRE-32613 which I am looking at at the moment. In local mesh we are not applying the visual scene transforms, that is the world space transforms. Mostly that is correct, we are loading individual meshes only (at this point) and so the world location and (arguably) the world space rotation are not relevant. However, the world space scale is important. In most cases (if you want consistent results) you should be exporting with a uniform and ideally a unit scale (1x1x1), my guess is that you have not "applied scale" to use the blender term (no idea what the term is in other tools but they will have something similar). My plan is to support the world space scale, but I may also give a warning as it is (most of the time) not what you wanted. In any case, the work-around for now is to apply scale in your tools before export. Hope that helps. Edited to add: If that doesn't explain it then a DAE file added to a new Jira describing the problem would be very welcome indeed.

I understand this, and help finding, exploring and resolving bugs is appreciated; which is why I have tried to extrapolate from the explanations you have given. So far I have not been able to reproduce what you have reported at all, and have suggested other reasons that might explain what you are seeing. I am not denying that there may be a bug (local mesh has I think 20 open bugs I am reviewing at present, some simple, some not so simple.). In this case, in the absence of being able to reproduce this myself, I am simply exploring the possible causes for what you see based on the information given. I am very keen to explore bugs but I cannot explore something that either, a) I cannot reproduce or b) those who can reproduce it cannot provide me with logs, videos etc. The steps I am using to try to reproduce the bug that you are seeing are as follows (please read and confirm, or improve):- a) open the local mesh floater b) add a mesh to the floater using the [add] button c) res the object using [rez selected], and clicking an appropriate place in world. d) clear the obect e) delete the object, noting that it appears in my trash f) relog If I understand correctly, then If the bug has occurred I should find the twisted misshapen surrogate prim back in the location from which it was deleted. Would you consider this a complete set of steps? If not, then please let me know what I am missing, so that I can try those additional steps.. I have tested this repeatedly and so far I have never seen a deleted item reappearing, so either I am missing some steps, misunderstanding the problem, or there is some specific dependency on your setup that triggers this behaviour, all these options are possible at this point. Additional questions: When you find that the deleted object has reappeared, has it vanished from the trash folder, or does it remain there? When you next try this, please copy the UUID of the object before you delete it. When it reappears please check the UUID again and confirm if it is the same UUID or a different one. This will help understand what is happening. Finally, while I am happy to carry on monitoring this thread it is not really the appropriate place for a proper bug investigation, I would request that you please raise a new bug on the firestorm jira https://jira.firestormviewer.org so that I can gather all the proper information, in the proper place. This also helps other people who might come across the bug.and helps build a pattern (if one exists) to explain why you can see this and I cannot.

Reading your update, I think I understand where you are getting caught out. I am wondering if you are muddling the terms up, this would make sense of your observations, and I agree that the UI is far from ideal here, with too much ambiguity. In the original post you said that you were deleting the objects; however, in your last reply you stated that you tried to "remove, clear and delete". Those are very different operations and with the exception of "delete", do not remove the underlying object, and are not intended to do so. Remove - removes a collada file from the list of locally monitored files. It vanishes from the list in the floater. It has nothing to do with the inworld objects Clear - clear removes the "local data" from the donor, allowing it to revert to it "server" form. There is a '?' button on the local mesh floater that takes you to the help page. On that page we find the following description:- As noted the surrogate will revert to the server view, and in the server's eyes this was never a mesh and so it becomes unusable as a mesh, you cannot re-apply to it, you have to delete and create a new one. Under no conditions does "clear" remove the item from the region and I suspect the issue that you are having is the that you are using clear, the item becomes an unusable empty husk, which in some cases may not show up until you resize it/TP/relog. My assumption is therefore that you have been using "clear" to try to delete it. This would make sense and as noted in the help page, this is a known shortcoming and something I hope to improve upon in the future (quite what to do about it I have not yet worked out). As mentioned before, you can sidestep any issue with the "weird surrogate objects" by simply providing your own mesh target to apply to. This clip shows me using a mesh cube (literally blender default cube uploaded and named "surrogate" so I can find it easily. It is what I used during the creation of local mesh feature, before I had the "rez selected" option. you'll see me use remove and clear and note that they never delete the object, that is not their purpose. At the end of this clip I delete it. Thsi works and you can see that an extra "surrogate cube" object appears in my trash folder on the server. https://i.gyazo.com/7fb4c8ff1d91f9ee739bbcea7762cda1.mp4 I may have all the above wrong, this may not be the source of your confusion, if not, then please raise a Jira and attach a video clip so that I can investigate further. You can update here too but it is not an efficient way to handle bugs as I don;t spend much time trawling the forums as a rule. (click here for the firestorm JIRA ) Just to double-check matters, the above clip used a "normal" mesh and showed the deletion. The next clips show the same with a "rez-selected" surrogate. In the following clip, I have a collada file loaded into my viewer's local mesh floater. I use the "rez selected" option on the floater to create a donor rather than using my own. I zoom into the new object and fiddle with it briefly then delete it just like any other object. It is gone. https://i.gyazo.com/d098e35df31c5b495d747ec563823ee4.mp4 I then logout and return back to the same spot next login, as shown in this clip. There is no object and I drag select to find it if it is there but somehow hidden. https://i.gyazo.com/b346172a678395d0800fb173850c9ab3.mp4 A long-winded response as I needed to cover a few possible things that might explain what you are seeing. Bottom line: The "Rez-elected" surrogate is still a work in progress as noted on the help page. Apart from being a useless misshapen thing, it also becomes unusable when you clear it. The simplest solution is to not clear it. In the end the only way to remove the surrogate from the region is to delete it using the build tools like any other object. There is certainly rooom to improve in the UI and I have a number of features requested etc. You will also find a list of known bugs on the Jira (search for Local Mesh and you should find them). Hope this helps.

@Denise Domela Normally the best thing to do would be to ask in the suport groups but that's not helpful when you can't reach them. In this case I would suggest that you, please raise a Support ticket at our JIRA bug reporting system, that way the support team can see it and we can have your info collected in one place.

Added my observations that seem to align to yours @Henri Beauchamp to the jira. I think there are many things at play here, I definitely notice a tendency for objects whose centre would be offscreen being missing. This does not account for many of the scenarios we observe (or have had reported) and which frequently occur on TP like the floor we are standing on being missing (unless, of course, the initial lookat can be entirely spurious, and then not get properly updated for some reason)

There is a Jira assigned to me (and has been for a while now) to get around to trying to unify this. https://jira.firestormviewer.org/browse/FIRE-21534 It's a mess all over the place and sometimes it makes more sense in one zone than another. For me, sitting in the UK, having my teleport history report in SLT would be confusing and be a large chunk of a day out of sync with my own recollection of when I visited places. Likewise, forcing it to UTC, just shifts the problem the other way. Firestorm got to where it is (as it often does) by trying to accommodate a variety of views and the result (I think we all agree) is a bit of a mess. I'd like to say it is a bug that's high on the list and I'll get to it soon, but that would be a massive lie 🙂 I am not even convinced that 1 timezone representation will be the right answer. Some of us would be happy but I suspect that many people will want the time in SLT (as that is how all the events are published (and those are not necessarily timestamps that the viewer can change) but things like chat and TP history might be preferable in user local. I could probably ask 100 people and get at least 6 different common permutations that they'd want. Feel free to jump on the Jira with thoughts. I really would like to do something about it one day. Anybody who'd like to have a go at submitting a patch aligned to that Jira is very welcome to and I'd make time to look at that. Reality is that every time I look at it, a far more interesting/urgent/less frustrating squirrel appears for me to chase.

This is expected behviour. In order for the temporary objects to be able to be used with scripts and so forth some form of server side instance is required. I create an object that can house your local mesh when you use the built in Rez Selected option and those are the remains of the surrogate objects currently created. They look like that as a side effect of the object settings I apply, it is not ideal and I hope to be able to create a more obvious placeholder in future. For now, if you want something more visible then use your own donor mesh object (a simple mesh cube will be good enough, (it must be a mesh, not a prim).

Hi @Jackson Redstar, Assuming that you have asked in the proper places (Firestorm Support group) and not progressed this, can you put this into a JIRA please. I can't manage issues that appear in the forums in any sensible manner. It is worth noting that from the initial performance update to today there has only been one viewer change. the release of 6.6.8 (which is mostly a maintenance update in terms of rendering). You have not noted the viewer version, I'll assume 6.6.8 for now. You noted in other posts (prior to the latest release) that performance has changed for the worse, those would have been on 6.6.5 and presumably with the same viewer code. this would suggest something has changed outside of the viewer code itself. This could be many things, of course, Windows updates, network degrading (typically easily solved/dismissed by a router reboot) & AV changes being the most common external factors, then of course we have the weird and wonderful world of view settings, caches and so forth. I am sure you have checked the obvious, normal first steps for all "slow" and "non-rezzing" which is that your whitelisting exclusions are stil being properly applied, this is not your first rodeo. However, as this accounts for well over 90% of the performance issues we troubleshoot; it is always worth double checking and even briefly disabling all your AV and Malware protection just to exclude those from the equation.

They cannot be culled efficiently, backface culling is simple, is the normal pointing away from the camera, yes, great nothing to do here. In some cases that may be done on CPU avoiding it at the earliest possible opportunity or in other on the GPU. With double-sided faces you have no such test, with rigged mesh we cannot rely on depth sorting ot come to our aid and with alpha blend we'd not even have that anyway, so overall it will result in more overdraw, more time wasted, more unwanted load on the GPU. It is entirely possible that there is something more cunning planned that will alleviate this; my fingers are crossed in anticipation. As I have implied before, I don't disagree that there are cases where this feature has benefits, but as always we have chosen to add new footguns to the creators' arsenal and loaded them, without putting in place any gunlaws or guidelines on how they should be properly used. The end state will be an overall increase in time wasted due to poorly defined assets and a loss of scene performance that goes hand in hand with it, all for a rather niche feature.

It varies by avatar. If you enable the "Inventory" debug logging (through logcontrol.xml) you will see the start and end of the writes. You need to zap it in between those and keep in mind that there's a good chance you won't notice. Take a look at the number of items written to the cache on a good exit. Then on a failed, it will be smaller, how much smaller depends on how badly it got interupted and whether you "care" about the items "missing" is entirely chance. The original bug manifested if the shutdown (or the restart) occurs while the <your avatar UUID>.inv.gz is being constructed, this takes a few forms as we write to a plain text version, then pass it off to be zipped. When the viewer starts it tries to carry on as best it can and can end up with a truncated inventory cache. Times will vary, the larger your inventory, the slower your disk, CPU, etc.

Coming back to this thread after what feels like a lifetime. The forthcoming Firestorm will no longer be prone to this issue. The basic fix was simple enough but it turned out to be a merry dance that consumed most of the Christmas period. The basic issue was as I mentioned in my 1st December post. However that fix itself uncovered a veritable nest of vipers that resulted in the final fix being somewhat different (in some ways simpler). To recap, the issue was that the new "fast shutdown" was in fact snake oil, the speedy closing of the main window was I think not really an intended result, but was perhaps seen as a nice side-effect, of moving many of the ancillary functions of the viewer into separate threads of execution (allowing the viewer main thread to spend more time drawing stuff). However, intended or not, the vanishing of the window just hid the fact that the viewer was still busy scurrying around in the background writing the caches out to disk and cleaning up. In Windows, the "premature shutdown" defence only applies to processes that have a UI and thus having killed the UI the operating system consider it fair game to kill the viewer and this was resulting in corrupted inventory files. Furthermore, the lack of a UI also signalled to us, human(-ish) operators, that we were free to restart another instance and that could also trigger issues. The original "fix" resolved the inventory issue, but led to a number of people see the viewer hanging during the logout process. Not being able to reproduce this problem I relied on the valuable and patient assistance of @Rick Daylightand a couple of others to help test various iterations of fixes and debug builds as I tried to locate the hanging. This is now complete, the fix overall is underwhelming and simple compared to the journey taken to find it! But the result is that we should now find that inventory caching on shutdown is far more reliable. There is a downside, the so-called "fast shutdown" myth is no more. The viewer will now pause as it always used to while it writes out the various caches. There may be scope to speed this up in future, but for now you will see the extended pause at shutdown, but remember that this is telling you that the viewer is still busy. Addendum - for those technically minded readers The hangs I had to fight were as a result of the shutdown order of the many event queues used and the fact that they were shared between threads that had potentially different life spans. In particular, the windows thread would continue to read and produce events (mouse movements, clicks etc) that get forward to other queues to be processed by parts of the viewer (including the main thread) when those threads stop reading then the queues fill up, the windows thread then blocks waiting for space to be made, space that will never come. Meanwhile the main thread is waiting for the windows thread to finish so that it can exit, resulting in a classic deadlock.

The requested Undo is not at all simple to do because these are not viewer operations. All inventory changes are transactions that need to be sent to the asset server and as such unwinding them would require an inverse set of transactions to be performed, in the meantime, the network is carrying other updates that may also change the state of the inventory, potentially clashing with the history that the viewer window is aware of. There are data processing mechanisms used in real world systems to give more robust rollback semantics, they typically require either a journaling system (where each change applied is recorded as a distinct operation) or at its simplest level versioned inventory, that would invalidate your "undo" history should any external events occur in the intervening period. None of these mechanisms exist, and would require explicit implementation on the server side as the viewer cannot be aware of all the updates. I've not thought too long and hard on this, perhaps there is a simple and limited way that simple fat-finger errors can be rolled back and I'm happy to hear thoughts on that, but I for one would be rather wary of heading too far along that path without express Linden Lab support. As always, a feature request Jira on the SL Jira, especially one that fleshes out the desired use case would be the best start.

Actually this is not true, though I guess you may be considering what is a "mesh" as different to what I consider a "mesh" to be. In the Viewer every material face is a separate mesh, thus an object composed of a single item (no links) and 6 materials is 6 separate meshes. By definition, making the material double-sided makes that entire mesh double-sided. This is in contrast to have individual triangles replicated where necessary by a creator that is doing their job properly. ETA: The Quote says it was @ChinRey but I think I quoted her quote of @arton Rotaru (sorry both)

That is the point, for this to be done on the GPU means that those triangles that would previously have been culled earlier in the pipeline now have to pass all the way through. You cannot simply say "oh but its GPU" that is not how it works. I don't disagree with Arton's point that there is darkness and light in all. Until I see otherwise my belief is that this path leads to more shadow than sunshine. In an environment where content quality control is nonexistent and creator skill and conscience is highlyt variable, the downside to this seems greater than the potential upside. I hope the creator community will prove me wrong.

What ticket number?

Not mandatory, in fact not even within control of the mesh creator which is why the glTF spec seems to me to have this arse-about-face. Ultimately you get the most efficient solution when the mesh is aware of how it should be rendered, not dictated by the "paint" that you apply to it. However, that is how glTF has expressed it and thus that is where we are heading. It is clear that the last thing we want is LL creating arbitrary specifications of their own and reinventing wheels that were already there. However, we appear to have taken "a standard for transmitting assets" and munged that with the rendering of them, and it is in that grey area that the demons are lurking.

Yes, this has been requested, it is entirely out of the hands of the viewer devs though.

Yes, an "assumption" of usage that has become enshrined in a "standard" for transporting material information and which is entirely detached from the application of the material. In a more usual scenario, the creator is responsible for and accountable for the efficiency of their content. In SL, sadly, there is absolutely no accountability for shoddy, laggy creations, and we also have the situation where we are creating a secondary market for materials where the end use cannot be guessed by the creator and unless the platform enforces modify capability on materials we will end up with double sided materials being the norm "just in case". No doubt it will be the fault of the viewer that everything grinds to a halt again.

Removing HUDs is good advice, so many people run around with the worst of all huds their head and body alpha huds constantly consuming space. If you really want quick access to those use the "favourite wearables" shortcut to have them no more than two clicks away. alternatively use alt-shift-h to simple not render huds. I don't agree with the "avatar weight" nonsense as a reliable guide to anything, never have done, unlikely I ever will; however HUDs are a demonstrable consumer of render time and will affect your FPS especially in texture heavy areas where the always texture hungry HUD has to compete with the scene for VRAM and other resources.

Double-faces are a double-edged sword, be careful what you wish for. In theory the way that it works toady the creator doubles up the mesh faces to create an inside /lining. The viewer can (in theory) eliminate these when they are not visible by back face culling. This also means that as in the real world we can have a different appearance on the inside than on the outside as the mesh is separate. With the (apparently) much wanted, double faced solution in PBR we have (as I understand it at present) the worst of all worlds. The unseen faces cannot be culled because they are double-faced. thus we have increased overdraw and wasted effort. The PBR solution is wed to the rather braindead GLTF standard view that the "faced-ness" of an object is an attribute of the material and not of the mesh itself. Thus if I am making a material for "tarnished copper" and I decide that it should be double-sided in case someone wanted to make (for example) a copper bucket that was a single mesh skin, then every time I make a tarnished copper object with that material it will (by default) have a backface even if that face was entirely occluded. End-users will be buying materials and applying them unaware of this. The "solution" is to ensure that the "double-sided" attribute is always no-mod so that wise creators can use it appropriately. However, what we are really doing is making it easier to make poor performing content and removing options to optimise this in the viewer through automation. I fear that we are about to make content even less efficient to render. Ho hum

Hi all Very quick reply as it is stupidly late/early and anything I write will probably be turned to gibberish by my fingers. 1) Physics crashing on SL (and FS). I have recently fixed this bug. It turns out that the code in the uploader has always assumed that the physics shape has weights on it (even though that makes no sense at all in SL), it does not check for this and as a result if you pick the cube shape or the "bounding box" option in the LL viewer, then the viewer will explode spectacularly when you calculate the costs. This is fixed in the latest FS preview (join the FS preview group to get access) and should be released soon-ish. 2) rigging of LODS, I'm not entirely sure what we are aiming for here, first thing I will note, from the images above we can see that the joint offsets were not being displayed in the preview for some of the LOD images. That could well just be a mistake while documenting the issue however. As for rigging of LODs, I can't recall right now the exact nature, I'll review it when the christmas visitation of relatives cease and normality returns. IIRC (and I may well not do so) we have just one set of weights that we abide by, and these are loaded with the high lod; all lower lod models are assigned weights using an algorithm that finds the nearest vertex in the lower lod models. I am casting doubt on my own recollections here though as I cannot with any certainty say if it does this for custom LODs that have weights with them or only for generated LODs. Given the ridiculous bug-ridden state of LOD switching with rigged mesh most people only ever use auto lods because the other LODs are highly unlikely to be seen. I applaud anyone trying to do the job properly, but it would not surprise me to find that things are not quite as you'd like/expect but that nobody has noticed!

/me takes a bow and grins. I chose that name, not as a cruel joke, but for a lack of better words to describe it. The reason I settled on reliable is because (whether you like the results or not - I am certainly not suggesting they are good) GLOD reliably produces something that is close to what you told it to aim for, and is what you have used in the past. It will reliably adhere to your request to crate very low poly (awful looking) LODs. MeshOptimiser on the other hand is bloody awful in about 2/3 of all cases that I tested, often resulting in excruciatingly bad LODs that cost the unobservant creator vast amounts of Lindens for unusable uploads. It almost completely ignores the target numbers, taking them as a guide rather than a limit. GLOD is also (typically) far more reliable when it comes to retaining UVs, whereas both auto (which is really just a wrapper around precise and sloppy) and sloppy pretty much destroy your UVs. I am happy to explore other options that people feel are worth having. They need to be freely distributable of course, and be able to be used from within the viewer. MeshOptimiser is not a bad library, the way that the uploader is setup to use it though is far from ideal, to the point where I requested it not be released with the performance viewer update, but kept separate so that people could focus on it as a beta and perhaps nudge it in the right direction. I did not feel it was ready, which is reflected also by my decision to reinstate the GLOD library.

As @Wulfie Reanimatorsays, attach to your skull, chin or nose. somewhere near where you want it and importantly a place that moves with your head. Being unrigged the hat will not follow movement in the same way as a rigged mesh one would. The hat may not be correctly positioned. right click on the hat, and select edit. You will see arrows that will allow you to move it to where you wold like it to be. This movie clip shows me editing a random old prim hat. https://i.gyazo.com/1fea6bf74e50cc9675df5904bd36ff8b.mp4 by default the arrows will move the item, if you hold the control key down, you will see rings appear allowing you to rotate it. you may also need to resize it, hold down ctrl and shift and you'll see white blocks on the corners, dragging these will stretch and shrink the item.