I got: fixes, fixes, fixes and MORE FIXES.
First the boring stuff: the Poser has gotten some under the hood changes none of them active at the moment but i'll build upon them in the future, i got some plans to extend the Poser with more fancy stuff.
Flycam has seen a slight change in how the flycam smoothing works and all controls needed some... tweaking to accomodate for that, these tweaks have now been made, the new Xbox360 controller defaults should once again feel decently enough as starting point to be used if you don't feel like sitting there and tweaking them for hours, also the max smoothing value for avatar smoothing has been increased to allow making the avatar rotation sharper and more responsive, zoom and roll should hopefully work properly again.
Now to the more interesting stuff: I experimented a bit with multithreading, multithreading is a big thing, everyone keeps saying "just multithread that shit and it will improve performance". Well yes... and no. Spawning extra threads has a huge impact, spawning an extra thread has to outweight the impact you improve, if you incurr more impact with spawning threads than you are solving you're essentially just slowing down stuff and making it crazily unstable too. How unstable... i got to see live in action and it was a crashfest and all i did was just a simple list fill, it was crashing left and right, at random, seemingly for no reason, all over the place. Multithreading requires careful managment of resources, you cannot read and write onto the same thing at the same time, infact you shouldn't probably be writing to something being read somewhere anyway, best case you should be writing to something entirely different and thats where the problems start. While SL is technically very modular and theoretically it should be easily splittable into parts that run simultaneously, having to make sure that the other threads are not writing into the same memory at the same time its being read or written into somewhere else or making it write into a new thing and merging those later is a huge undertaking, it requires writing lots of extra stuff and rewriting some parts completely to make sure they can work while the other thread is doing its job, rendering especially is very... fragile there. I think the image decoding is probably one of the biggest performance impacts all around and probably the easiest and safest to multithread since the Viewer can already work with all states of a texture, whether it is loaded, still loading, still decoding or missing, it will just require lots of careful shoving textures around, this could drastically improve performance while textures are being worked on and they are worked on most of the time. Back to what i did with multithreading, i multithreaded the Avatar Render Settings, the list will now be collected and created in a seperate thread and then written into the actual list in the main thread when the heavy work is already done, this completely eliminates the huge freeze when opening the tab for the first time or when it updates if your list is decently sized (like mine), i'd throw around a few numbers but going from a few seconds freeze to "what? its over already?" is pretty much an infinite improvement. In any case, this was a very interesting experiment and some valuable experience that i hope to be able to use on other stuff later down the line, we'll see... and if you consider the Viewer not multithreaded (even tho it averages around 20 threads at all times) it now is officially multithreaded, at least as long as your preferences window is open haha.
Single-threaded
Multi-threaded
That's a big improvement as you can see.
Another quite small but interesting change is the falloff for Volumetric Lighting, rather than it being a straight falloff it is now using the distance squared, this should make the falloff gain intensity much faster towards the end, the side effect is that falloff now requires much higher values, the sliders have been increased to accomodate for that. It's overall a very miniscule difference and hardly noticable but i think it looks a bit more like what i initially wanted, i might implement an option to scale this later on.
Onto the most interesting part, the reported issues: About Land should no longer show a scrambled price label, profiles should once again allow creating and deleting picks (tested it and it works), clicking the description field in other people's profiles should no longer kill the formatting, clicking the X is online/offline message in IM should no longer throw a "invalid slurl type" error and finally.... FUCKING (speaking of fucking) FINALLY, the cock-magic bug is fixed. FIXED! I know you all loved being a magician but sadly as South Park has shown cock-magic is illegal and you should stop doing it... but what was the issue... ohboy... here we go...
This issue started surfacing somewhere in the last few releases, i spent a few days trying all versions up and down, trying to find out which version introduced this bug, soon enough i found out it was 3.4.2+, much sooner than expected. I went through all changes i made trying to limit the troublemakers down to just one change, bad for me this change was a masive one, it was a massive bunch of extra stuff for animesh so i had to drop this for a while. The issue started appearing in other Viewers too, reports from Firestorm and Official Viewer (i was able to reproduce it in Official as well) started appearing, all of them past LL code 6.0.2 which was the version this big change was included in. Black Dragon however was able to reproduce this issue 100% of the time, on the same obejct at all times. So on the last meeting i had a small but interesting talk with Beq Janus (from Firestorm) about this issue and what it could be, this lead me to investigate something and soon enough i ended up at the introduction of the new bounding box code that came with 6.0.2. I remembered that i changed something there, luckily i left an option to control the fidelity of said bounding box calculations so it was super easy and fast to see whether this was actually the cause and to my not-surprise it was. My overly aggressive attempt to optimize the bounding box calculations back to pre-6.0.2 performance surfaced this issue in a 100% reproducible manner, reading its code revealed an interesting tidbit which i think might be important on how to fix this issue for all Viewers. The Viewer creates a small box around the center of the object, then extends it with several factors, the base object bounding box, bones etc. In my case the bounding box was reduced to its first stage, the small box at the center of the object and that is exactly why the dick kept vanishing, due to the rigging putting it far off-center, the center (and thus the bounding box) goes out of screen when you zoom closer, the actual bounding box was somewhere above the actual visible dick, which explains why it reappeared when you looked up and why you could zoom closer before it disappeared again and you needed to look further up to make it reappear. This is also the reason why it didn't happen on avatars, they often have a decent center, unlike these genitals. In the code it states that it could possibly happen that the rigged bones are not initialized properly or at all, this could cause exactly what i just described just randomly, it would explain why it happens so rarely on other Viewers and why its fixable with a relog. Needless to say i re-enabled the full calculation for animesh but still left the second and third (the heavy ones) out for avatars, avatars seem to do just fine without these, animesh on the other hand don't, they need all three stages. So this issue should be fixed for now and should only appear randomly, very rarely just like in other Viewers. I explained the case in the Jira and hope that LL will find a fix for this rare case, maybe just revert to the old bounding box calculation (which worked just fine) in such a case, its better than having your dick vanish right?
 |
| by Loverdag |
 |
| by Books |
 |
| by Kissmebaby Allen |
 |
| by Spiritus |
 |
| by Jeremy |
 |
No comments:
Post a Comment