Jump to content

Beq Janus

  • Content Count

  • Joined

  • Last visited

Community Reputation

540 Excellent


About Beq Janus

  • Rank
    Advanced Member

Recent Profile Visitors

700 profile views
  1. I wanted to pop back here and give you all an update on this little bug hunt. As of last weekend I have committed a change to both the viewer CPU code and the GPU shaders that addresses the underlying issue that causes the issues that @ZedConroy raised. En-route to fixing this I also fixed the broken and misleading Render Normals debug control that you can find by enabling the Developer-> Render MetaData -> normals overlay. Let's start with that. The debug was simply not performing the correct set of transformation to correctly rotate the normals It now correctly observes shape changes and the normals reported match those reported by the server via LSL. A short clip of the new debug in action is here https://i.gyazo.com/a079875e9ee1ee929d00b15517d6a60e.mp4 Key differences: * yellow normals and blue tangents. * only selected objects by default (a debug setting can be used to revert to the old global view) * in face select mode, only the the normals and tangents of highlighted faces will be drawn (useful when the tangents and normals of neighbouring faces overlap) OK, so on to the underlying bug that @polysail and I pursued. Our investigations showed that there was no issue with the import of mesh. This is provable on a TPV that has a "save as collada" function, as you can import, and re-export a sample mesh, then compare the before and after to find that they are identical. All normals and scale preserved. To further illustrate this, the rendering of normal maps placed on prims exhibit the self-same bug. This video illustrates it a liitle, you can see that when at default proportions the cylinder looks fine. When flattened it is harder to see but the flat surface continues to behave as if it were curved. https://i.gyazo.com/044d26873ac068f479a7333bebcd9368.mp4 We finally traced the problem to two specific points. To properly explain this I'll briefly cover "the life of a mesh" (though this generalises to the life of a prim/sculpt too) when a mesh asset is first imported from collada it is converted from floating point to integers. the mesh is normalised such that it is centralsied around the origin, thus if it is 12m high and 4m wide , it will be transformed to be ranging from -6 to +6 in Z and -2 to +2 in X. it is then scaled into a unit cube with the extents ranging from -0.5 to +0.5 in each dimension (XYZ). The unit cube is then quantised into integer form, -0.5 mapping to 0, through +0.5 mapping to 65535. All points are represented in this way. This is the form that the viewer send to Second Life and which Second Life creates as the base asset. Note that the dimensions of the original are retained in terms of proportional factors that are part of the mesh asset. When the unit cube is later requested by a viewer, (note this is never directly requested, the underlying mesh is always subordinate to a parent object that dictates its in-world scale etc) it is unpacked back into floating point form but retains its unit form. When the parent object is drawn the viewer first expands the unit cube in a relative transform, into the scale of the parent object. It is at this stage that the first occurence of the bug is found. Normals (in spite of their name) are special when it comes to transformations. the move contrary to the scaling of the vertices. To correctly transform a normal you use a special derivation of the transformation matrix known as the inverse-transpose matrix. The problem is that the tangent was also being transformed using the same matrix. At this stage our mesh has been inflated from it's unit form into the local object scale. All of this happens in the viewer, on your CPU. It is then passed to the GPU for further work. The shaders on the GPU, take the local mesh and rotate it through a combined transformation so that it is aligned to the camera viewpoint that you are observing it from (and is ready to be drawn on the screen) this transformation (using a matrix known as the Model-View-Projection tranform) also has to adjust the normals, and again it employs the inverse, transpose, and once more the tangents were also having this applied to them. As a final treat, the legacy bump map code also exhibits the same problem and has been corrected as well. In closing I should note that rigged mesh is a whole other ball game. Firstly it does not share te same kind of behaviour, however it is also not correct. There are threads here and Jira's @Beev Fallen has recently raised that cover this. The rigged mesh issue is however (as best I can tell) planned and known "approximation" which is pretty much accepted in realtime 3d games (or at least ones of Second Life's generation) see this Jira (https://jira.secondlife.com/browse/BUG-228823) for a little more background. And so... here we are. The following image shows the before and after, using my earlier example of a standard cube and a flattened cylinder, that, allowing for minor deviations in UV should otherwise behave the same under lights because the normals SHOULD point in the same directions. LEFT is release Firestorm (and you should see the same on other viewers going back 9 years or so). RIGHT is the fixed Firestorm And there we have it. A real mish-mash of technical and non-technical stuff. I tried not to go off too far into techno babble land, butI hope I didn't dumb it down too much for those who were following the details. Here is a video clip of the side by side old and new https://gyazo.com/91d35910208bf657988f57b3fbc16f97 Any mistake, I blame on it being 3:15am 🙂
  2. Yes, don't forget that the mesh asset is effectively read only, but the inworld objects can be stretched and squashed to any proportions. As such the normals have to be stored relative to their intended proportions (the actual scale is probably irrelevent but the relative proportions are required. As @polysail alludes to, there is more to this bug than meets the eye, while the fix I applied fixes the scaling that is evident today. It is only papering over a deeper problem with the normals inside the viewer. I've bundled up everything I learned from this exploration and passed it to the lab, via jira and emails and we'll take it from there. I've also moved the fix applied in FS to a debug setting, this is because I hope that havinmg done all this work to demonstrate the issues we can get a proper fix, at which point mesh uploaded with my fix look different. By making a debug setting people can take an informed choice as to whether they want to fix it this way in the short term or not. If the lab decide that this won;t be fixed for any number of reasons then we can change the settings default later too.
  3. As Liz stated above (and this explains also why @Wulfie Reanimator's repro failed) the problem lies in the conversion process applied at upload. As per my note, all mesh undergoes a normalisation process that force aligns to an origin point central to the mesh geometry bounding box. This is done by determining the min and max extents and from those a scaling fact is derived. This is used to squish the mesh coordinates into the 0:1 domain, unfortunately it appears that during this transformation an incorrect scaling was applied to the mesh normals. The result is that any non-cubic meshes will have some degree of taint to their normals. Liz has created the following Jira https://jira.secondlife.com/browse/BUG-228952 I have applied my fix to Firestorm, so it should be fixed for FS in the next release, and added the appropriate patch for others.
  4. We still have testing to do butI worked through the viewer code and confirmed Liz's theory. I have fixed a test version of FS and @polysail and I have tested that fix and it appears to work. Bad news, if it does turn out to be right then there's 9 years of bad mesh normals out there 🙂
  5. Number 4 is entirely expected behaviour I believe. At least it makes sense to me in those terms. Number 3 probably also. Number 2 is interesting and worth investigating a little more. Here is why I think much of this is expected behaviour. All mesh imported into SL is quantised to signed 16-bit values, thus you get 65536 increments to a side in the bounding box, or to put it another way your coordinate space inside the BB is -32768 to + 32767 (Note for the observant: This also underlies why your pivot is in the centre of the BB, which if and when we fix it might have repercussions on effective resolution). These are the same irrespective of the relative size of the BB dimensions. thus there is an effective higher resolution along your Y axis (based on the images). The scale that you applied in 4, effectively made the BB cubic. I would also advise taking care with observations based on the DAE export. DAE export is rudimentary, it takes the mesh that is being rendered and converts it to Collada. It is not, therefore, operating on the asset, but on the post-processed VBOs that get drawn. Given the bias in the BB I can see how the normals might be compressed but at the same time others are not seeing this, suggesting to me that there may be something assumed in the original asset (an unapplied scale as per previous suggestions would also have been my first guess) that we're overlooking. If you are willing/able to raise me a Jira on the Firestorm jira (jira.firestormviewer.org) and add the assets above to it, I can have a play. If you do not wish those to be publicly visible then you could email them to me directly, or perhaps the best solution, recreate a subset of this that we can share without violating your IP. A simpified model perhaps just a quarter slice of this should be plenty. @polysail your 3ds max knowledge might uncover something here?
  6. You'd be best to ask in the scripting forums. You just need to add a touch script to one of the buttons in the HUD
  7. Or to put it another way, make sure the lowest LOD is not showing 100s of tris and you'll be a lot wealthier. As @arton Rotaru notes, this typically happens because the LOD software fails to reduce the complexity while retaining a valid asset, you end up with a lowest (and low) LOD model that are extremely expensive.
  8. I have just created a new feature request. This is not the answer we want, there are all kinds of holes in the thinking, but perhaps it can start helpmove things forward. Here is the Jira https://jira.secondlife.com/browse/BUG-228780 The basic premise is that while we acknowledge that too many things are being drawn by the viewer and this has a significant impact on our performance we are caught by old bugs and old content that was unaware that they were even bugs. By creating a small number of "safe slots" we can introduce more aggressive and correct rendering behaviour while allowing users to select certain items to retain. I have suggested a single attachment point with a limit to the attachments but it can of course be implemented in other ways, concerns about stacked attachments are valid still. I picked 5 as a somewhat arbitrary number but it seems plausible. A typical human could safeguard their head hands and feet (the bodies ought not really need it they have the large volume to stay whole longer already. in non-humans the bodies tend to be in a few parts only too. As the Jira says, it enables the user to fix their own problem and choose which items in their outfits to protect. I have no doubt it will cause untold cries and I do fear for the poor viewer support teams that would have to explain such a scheme, but if we want to get good, consistent rendering performance we need to stop sending so much unnecessary crap to the pipeline. In discussing this with my partner Liz (@polysail) her concern is that by fixing this we encourage other bad behaviours. I don't doubt that. As consumers we demand levels of detail and fidelity from our creators that require abuse of resources (over use of large textures, high detail meshes rather than materials, etc. ) and at the same time whinge and moan at the viewer support when our viewers run slow. We all need to accept some responsibility here.
  9. individuals can that's the beauty of open source. Anything more than that is likely a breach of the shared experience rule, it is certainly something I would avoid in general. Offering debug settings to override expected behaviour is a pth that has cost us all dearly, (look at the number of places you shop that still tell you that it is not their product that is bad, but you vewier settings). That said, some TPVs give a middle digit to the lab and do take things into their own hands. These tend to be viewers that have a specialist or niche market and thus sail under the radar; viewers that have a larger user base however get called to account far more strenuously than others. What I would say is that your theory seems very human biased and anything that assumes proportions derived from a human form is not reflective of a lot of the edge cases in SL. Creators repurpose bones all the time, while there are limitations (you must retain the hierachy, bones do not have to be located in human form.
  10. This is well established and I raise it often at CCUG and other meetings. The chances of it getting fixed are however small as the amount of content breakage that would occur is significant because pretty much every mesh clothing creator out there know that adding LOD models is a pointless task and therefore does not do more than the minimum. You can see my original Jira on this matter here https://jira.secondlife.com/browse/BUG-40665 There are further twists and turns along this path such as https://jira.secondlife.com/browse/BUG-214736 As for the general behaviour where a rigged item is linked to the body scale rather than the item scale I personally think that this is the correct behaviour. At least in an ideal world. If items were to LOD swap according to their scale then we'd find that hands and feet would deform when seen from across the room, heads too perhaps, certainly not much further away. This is not desirable, you want your body to swap as one. However, while that makes sense in the general case for bodies it does not make sense for jewellery, having the wedding ring on your finger render at high LOD half way across the region is not useful to anyone. It is however where we are at the moment.
  11. There are lots of tools which can be applied in different cases. limited dissolve and decimate are broad brush ways to attack a mesh but you can use dissolve on selected edge rings to reduce complexity locally. One of my favourite tricks is selecting alternate edge loops to effectively reduce the number of sides on a cylinder or other curved surface. to do this you select a single edge, then ctrl-alt-select, to select the entire edge ring, then use checker deselect so that only alternate edges are highlighted, then select edge loops (from the select menu), finally dissolve edges. This works on all kinds of surfaces with good quad based edge flow and can be more predictable than an angle based limited dissolve. https://i.gyazo.com/25947281a775fdcdde74af184dd99f47.mp4 The other important thing to do is to remove all hidden faces. This is especially true of lower LODs, once you are moving further from the object the chances of need all the interior faces and any thin edges etc are increasingly unlikely. Funnily enough I recently published a blog and a video on cleaning up mesh exported from SL using the Firestorm/TPV save as collada option. It almost didn't see the light of day, it is a long post and I was not very happy with it, but you may well find a couple of tricks in there. https://beqsother.blogspot.co.uk/2020/04/cleaning-up-your-act-how-round-trip.html The video is not a tutorial as such, more a guide to how I work (and the mistakes I make, etc) I chose a particularly clumsy ancient prim build as an example. Not my best but it does show a few techniques that might be useful (and doubtless a few to avoid).
  12. ALM enables them. The impact on you will depend a lot on the machine you are using and where the bottleneck exists. It is important to ensure that you remove shadows as a first step when you are comparing the ALM on and ALM off. I just did a little test for myself to demonstrate: ALM on, AO off, shadows None 29fps ALM off, (which disables shadows and AO anyway) 30 fps So a negligible change. Enabling AO for me gave a small further reduction to about 28, though that's within the error of the reporting anyway. Adding shadows has a far greater hit. in my case for the same indoor scene, with 3 avatars, furniture etc. that resulted in a drop to 20-21fps One thing I noticed when testing this is that when I re-enabled ALM after this test I dropped to 13fps, but moving my camera into the distance so everything went grey and then back to the same place again restored the ALM to 29/30 level again. So be sure to move the camera around or even relog when testing to get clear results (also keep in mind that the viewer reduces you frame rate when it is not focus so typing on here my FPS will automatically drop. When testing and recording the results I often catch myself be surprise and forget that. As for how many, in a recent discussion across a number of groups of people my estimate is that around half of users have ALM on. This is confused by the fact that some people will toggle ALM off in a busy scene and re-enable later. I'd guess (and this is a total guess) that if you assumed 40% had it on most of the time and 40% did not then the remaining 20% are in the "sometimes" group. Ironically, one of the problems that ALM being turned off invokes is that creators resort to using mesh detail instead which of course has a further impact on performance so the argument becomes a little chicken and egg.
  13. Yes! Exactly that (probably). Are we allowed to yet @NiranV Dean? I'm never sure, and as I've never seen a "limited editiion" viewer before I have no idea what that means for TPVs and "shared experience". My guess is we probably can, I really don't know though. As for the conspiracy theories that to to get conjured up, this is just, as Niran, pointed out, a "rush" release of the updated CEF viewer, brought forward like this to enable the Lab to promote this event. This is a positive step in the general health and vitality of the grid, drawing in more people. It is a little sad that people will have to use an unfamiliar viewer and that it does (by definition) exclude Linux users but it is undoubtedly a positive step for SL. We'll have these changes in TPVs as and when they are available for us (which may or may not be now). For FS that means we will sweep it into one of our normal scheduled releases, for viewers like Niran's with a higher release cadence (more frequent updates) it'll be there as soon as he is happy that it plays nice with other things and feels a new release is warranted. @Ardy Lay there have been two separate issues and it sounds like that thread conflated them, on one hand "older" CEF has a history of security vulnerabilities that get patched but of course unless you are tracking those updates you won't have the fixes, hopefully this version cleans that up a biut by bringing things to a mroe recent version (who knows?) the other problem is broken video content, which is down to the explicit restriction of the codecs that could be used due to legal concerns over copyright infringement. The Lab have been working to find an appropriate way to ensure that video content can be played with legal codecs and this viewer is the first exposure of that. Irrespective of the status of TPVs and this "special" it will be promoted to a standard release at some point soon(tm) after which TPVs will definitely be able to start to include it.
  14. As both @Bitsy Buccaneer and @ChinRey have noted, the process of determining a "nice" LOD is dictated by the object you are working with. One of the common failings observable when people use auto generated LODS, is the loss of "silhouette". Where possible a good lower LOD loses the details and keeps as much of the shape and volume of the original as it can, this way switches become more transparent to the user.
  15. Models have to share the same bounding box. they will get stretched to match. Same applies to physics as well. To fix this you need to place a single triangle at the extent of the BB where there is no other mesh to pad to the correct size. It can be a pain in the posterior but for now it is all you can do.
  • Create New...