Rigged mesh LoD bug

[OptimoMaximo]

This has come out over and over again, and that's the bug undocumented feature that prevents low and lowest LoD from ever showing up in case it is a rigged attachment. Recently there has been a cool discussion about LoDs in another thread, and this issues has risen up again, but this time i had to really think about it. So i'm sharing with you all my observations, thinking and my personal theory as per why this happens.

So i started by exporting the SL default avatar from a meter scale based software, namely Blender but 3DSMax would be the same. Just to make sure to show 1) what the Avastar export scripts do for you 2) unbiased results due to the default scene scales mismatch between Maya and Blender (Maya's centimeter based)

So first off, i tried a FBX export and a collada export from Blender, the latter using Avastar. FBX came in with no warning, BUT it applied a scale perservation. Collada did the same, but the plug in threw a warning

So basically it's warning us that there are mismatches between the scales of various transforms and it's performing a scale preservation (baking into TRS aka transforms)

With slightly different hierarchies, they both came in as follow (this picture is about the collada file after import)

The highlighted Avatar group contains the skeleton, and you can see it's scaled up to 100. The SL default avatar for rigging is assumed to be scaled down to centimeters, so the containing group compensates. So far so good, however...

Also the meshes transforms have gone through a scale compensation. This happens because it's a rigged mesh and the skin cluster dependency activates the compensation to match the scale input from the Avatar group.

If we import a centimeter scale rigged mesh with no uploader rescale, we get a centimeter scale object when rezzed. Same goes with a meter scale object, it keeps its meter scale size upon upload. This means the scale has no meaning to the uploader, only the actual bounding box size of the geometry in the file does. 

So here is my theory about it:

Since the scaling operations aren't accounted, the bounding box size of the object is being wrongly calculated when skinning comes into play, basically moving the geometry to fit on the basic centimeter scale avatar, which is then scaled up inworld within the avatar controller. During such operation, the bounding box doesn't scale down to centimeter scale because it's a geometry action from the skin, but since it is attached to the avatar, the bounding box gets scaled up along with the character skeleton to stay in the avatar controller. What effectively happens is that the final rigged item bounding box results to be 100 times bigger than expected, and therefore setting the low and lowest LoDs distances really beyond any meaningful viewing distance.

 

Please share what you think and, possibly, what your theories are about this. Hopefully @Beq Janus and @Vir Linden can look into it

[arton Rotaru]

I never heard of that, that the low, and lowest LOD never show on rigged attachments. They show for me, just at much larger distances than they actually would as a non rigged item. AFAIK, rigged attachments use the bounding box size of the Avatar, instead of the items BB. Which can be quite handy if you have multiple pieces rigged, they all switch LODs at the same distances, instead of each on it's own.

But maybe you are referring to something else?

What is more concerning to me, is that a tiny rigged mesh, will only show a display weight of that small size, and not at the size it will have when it is actually attached.

Edited March 11, 2018 by arton Rotaru

[OptimoMaximo]

It came out on the other thread about LoDs, and i went on checking it myself. Once worn, a rigged mesh, at least for me, shows at most High and Medium LoD. I'm using Firestorm, btw.

[arton Rotaru]

9 minutes ago, OptimoMaximo said:

It came out on the other thread about LoDs, and i went on checking it myself. Once worn, a rigged mesh, at least for me, shows at most High and Medium LoD. I'm using Firestorm, btw.

What happens if you dail down the LOD factor to 0.5 or something like that? I'm always on the official viewer.

[Love Zhaoying]

27 minutes ago, arton Rotaru said:

What happens if you dail down the LOD factor to 0.5 or something like that? I'm always on the official viewer.

I assume “dail” rhymes with “fail”. I hope that answer suffices?

[arton Rotaru]

4 minutes ago, Love Zhaoying said:

I assume “dail” rhymes with “fail”. I hope that answer suffices?

Not without a lion picture.

[Love Zhaoying]

5 minutes ago, arton Rotaru said:

Not without a lion picture.

*facepaws*

Edited March 11, 2018 by Love Zhaoying

[OptimoMaximo]

9 hours ago, arton Rotaru said:

What happens if you dail down the LOD factor to 0.5 or something like that? I'm always on the official viewer.

Yes i-m sorry, i forgot to mention that even if i were on Firestorm, i tried it with the default LoDFactor at 1.25, but i didn't go lower than that. Later i will do this test.

[OptimoMaximo]

I did some testing using some rigged attachments i just finished.

I started by setting my LoD factor to 0.5, as Arton suggested.

So, when rezzed on ground, the low->lowest lod switching distance is around 20 meters. Once worn, this distance increases to approximately 200 (198 and 206, it's a left/right attachment) meters. Which is quite a lot longer distance. 

However, in order to even notice a lod switch, i had to cam out of my location and increase my drawing distance to 1024 meters to have the avatar being drawn back on screen.

Now, since it was stated that the attachments take the avatar's bounding box for their lod distances switches, i made one of the two attachments slightly bigger than my avatar, in order to get a bounding box of approximately the same size. In its rezzed state, the lod switch distance increased, going up to 30ish meters, not even close to when it is attached. And again, this described behavior happens at LoD factor 0.5. 

That's why i think there might be something else going on that induces this LoD distance boost. Might also be intended, i don't know.

Edited March 14, 2018 by OptimoMaximo

[Beq Janus]

On 11/03/2018 at 9:13 PM, OptimoMaximo said:

So here is my theory about it:

Since the scaling operations aren't accounted, the bounding box size of the object is being wrongly calculated when skinning comes into play, basically moving the geometry to fit on the basic centimeter scale avatar, which is then scaled up inworld within the avatar controller. During such operation, the bounding box doesn't scale down to centimeter scale because it's a geometry action from the skin, but since it is attached to the avatar, the bounding box gets scaled up along with the character skeleton to stay in the avatar controller. What effectively happens is that the final rigged item bounding box results to be 100 times bigger than expected, and therefore setting the low and lowest LoDs distances really beyond any meaningful viewing distance.

 

Please share what you think and, possibly, what your theories are about this. Hopefully @Beq Janus and @Vir Linden can look into it

This is a known issue that I reported https://jira.secondlife.com/browse/BUG-40665

There are two aspects at play here

1) a design feature

2) a bug

The design feature is that all rigged Mesh LOD is based on the bounding box of the avatar

Whilst in some ways this makes no sense (why should my bento rigged finger nails LOD decay at the same rate as my torso?) it also is what you want when you consider that you don;t really want your head to switch before your body, which if it were based on normal scaling is what would happen. 

The bug is that the equation calls for the Radius of the BB to be used. but in Rigged mesh they incorrectly use the diameter. This doubles the effective radius used in LOD switch calculations which is why it is so far away. 

you can barely see it but the LOW LOD model does switch in at about 60m when my LOD factor is set to the ludicrous 0.125 (the lowest possible)

At a normal SL default that would be 255m

[OptimoMaximo]

4 minutes ago, Beq Janus said:

The bug is that the equation calls for the Radius of the BB to be used. but in Rigged mesh they incorrectly use the diameter. This doubles the effective radius used in LOD switch calculations which is why it is so far away. 

It makes sense, using the avatar's bounding box is useful to have consistent switch and i understand the design. But why use a different calculation? it's like having the render volume factor doubled on avatars at all times. I will further test, setting the rezzed object's bounding box to double the avatar's BB.

[Beq Janus]

43 minutes ago, OptimoMaximo said:

It makes sense, using the avatar's bounding box is useful to have consistent switch and i understand the design. But why use a different calculation? it's like having the render volume factor doubled on avatars at all times. I will further test, setting the rezzed object's bounding box to double the avatar's BB.

2

As I say, that part is a bug, or at least nobody has explained to me anywhere why it was chosen not to halve the value. My belief is that it was probably a straightforward mistake.

The "radius" used in the LOD calculation is calculated in the following code

	if (mDrawable->isState(LLDrawable::RIGGED))		// If this is a rigged mesh
	{
		radius = avatar->getBinRadius();		// get  the radius (see comments in thread below)
	}
	else							// for non-rigged mesh
	{
		radius = getVolume() ? getVolume()->mLODScaleBias.scaledVec(getScale()).length() : getScale().length();
 								// Here we use a thing called the LOD Bias * the scale....(see below)
	}
	

For Rigged mesh we use "binRadius" which you'd think seems sensible...until you look at what binRadius does

Here is the function getBinRadius()
 

F32 LLViewerObject::getBinRadius()
{
        const LLVector4a* ext = mDrawable->getSpatialExtents();        [ Get a vector array of the extents of the bounding box (the coordinates of the corners) ]
        LLVector4a diff;                                                                                  
        diff.setSub(ext[1], ext[0]);                                   [ subtract the lower, back corner, from the upper right corner giving the diagonal length of the BB ]
        return diff.getLength3().getF32();                             [ Return that value....effectively the diameter, in spite of the name. ]
}

For non-rigged we use getScale() which also returns the size of the avatar hitbox (a diameter) BUT we use the scale bias. this is setup based on the object type (historical adjustment for certain prim shapes). It defaults to 0.5 (it can be slightly more but that's beyond the scope here)

	mLODScaleBias.setVec(0.5f, 0.5f, 0.5f);

So taking the scale (diameter) and multiplying it by the bias gives the radius.

My guess is the developer who wrote the rigged mesh saw "binRadius" and decided it was already a radius.

 

 

 

 

[OptimoMaximo]

I've just run some more testing. Render volume factor still down to 0.5. This time i set my rezzed rigged mesh bounding box to be double than the avatar's. what i'm getting is still that the rigged mesh switches to lowest LoD at approximately double the distance than the rezzed, avatar-double-BB sized item does.

I've run the example script found here http://wiki.secondlife.com/wiki/LlGetBoundingBox and doubled the size when the primitive parameters are applied. Perhaps the bounding box that LSL gets is the size of the hitbox (as it appears to me when running this script), while the viewer code takes the static mesh's BB instead? Which would explain why this difference in distance: an avatar in TPose has a quite larger Y axis size.

[Beq Janus]

9 minutes ago, OptimoMaximo said:

I've just run some more testing. Render volume factor still down to 0.5. This time i set my rezzed rigged mesh bounding box to be double than the avatar's. what i'm getting is still that the rigged mesh switches to lowest LoD at approximately double the distance than the rezzed, avatar-double-BB sized item does.

I've run the example script found here http://wiki.secondlife.com/wiki/LlGetBoundingBox and doubled the size when the primitive parameters are applied. Perhaps the bounding box that LSL gets is the size of the hitbox (as it appears to me when running this script), while the viewer code takes the static mesh's BB instead? Which would explain why this difference in distance: an avatar in TPose has a quite larger Y axis size.

Trying to look at this now and I think it may have been made worse "recently". Before, I only looked back at the binRadius call and the fact that it is not divided through. If the input binRadius is also wrong then it would be worse still. You can see the actual scale in use using my Mesh Info tool. where that scale comes from is more involved, I've gone back two levels (shown above) and illustrated that it's broken but I've not gone back any further than that. That radius is "very wrong"

 

 

[ChinRey]

This may illustrate a few details that aren't obvious in Beq's example. Here is a lovely top:

When rezzed, it 's so small you can hardly see it. It's right at the minimum 1 cm size allowed in SL. That big prim it's on top of is actually an unedited 0.5x0.5x0.5 m cube. Render cost when rezzed is 2768 but that doesn't take into account that it's fitted mesh. When worn, the render cost is 3040.

When worn, it scales up of course and the LoD Swap distances are determined by the avatar's size multiplied by not 2 but approximately ... something between 3 and 4 it seems:

(Firestorm's LoD swap table seems to be very accurate btw).

This means at any "normal" view distance, the top will have 52080 triangles but the render cost is calculated as if it only had 202.

According to the official description, base render cost is "weighted by the count of triangles at each LOD and the area each LOD is visible from". The calculation for this particular top assumes that the mid-to-low switch point is 0.2 m while it actually is 69.6 m (or even more if you have increased your LoD factor - the render cost calculation doesn't take that into account at all).

Judging by a quick test with a static mesh with a similar triangle count and switch points, the actual render cost of the top should be around 30,000 if the formula had been applied correctly according to the official description. I think we all agree that is a significant error.

Most of this is due to the binRadius mistake Beq mentioned. Changing the size to that miniscule it was uploaded at to the actual size of the item or an avatar's bounding box does increase the render cost a little bit but not very much. It's only when we get to sizes above 2 m or so, the triangle count of the high and mid model really becomes significant and the render cost starts to skyrocket.

An example here. if we have an avatar with mesh body, mesh hands, mesh feet, mesh head, fitted mesh hair and three pieces of fitted mesh clothing, that's 10 pieces of fitted mesh. Let's say the calculated render cost is a nice and sensible 80,000. Add 25,000 for each piece of fitted mesh and we end up with 330,000. In reality it's probably not that bad but it's serious enough.

The dilemma Linden Lab has is of course that it's so big they have to do something about it but at the same time it's so big they can't do anything about it. If they change the switch points to match the calculated render cost, practically all fitted mesh on the market will be broken. If they change the render cost calculation to match the actual switch points, the nominal render cost of a mesh avatar would go through the roof and up where it belongs. That's not going to be popular either. I do think they take it seriously though and I wouldn't be surprised if this is the real reason why @Oz Linden's avatar's hair is gray.

And if Beq is right, it's all because of a poorly chosen name for a variable. Let that be a lesson to all us scripters and programmers.

 

Edited March 14, 2018 by ChinRey

[Beq Janus]

So I believe I have got to the bottom of this. 

It is not that something has changed "recently" as I had intimated, or rather it is, but it was not the viewer ... it was ME.

Remember the Jira I linked (https://jira.secondlife.com/browse/BUG-40665). It is correct 2x the BB radius appears to be consistent. However what was confusing me is that if you look at the photos in the Jira, each one shows my avatar as applying a Radius of 2.8(ish) m, my BB diameter. 

When I was making the post earlier today my BB was a whopping 16m....Could it be the Bento had changed the bounding box size?

Well no actually, at least not directly.

Watch this.....(static photos follow which show this more clearly)

https://i.gyazo.com/153e2dedd5ec39322eaa202d4fe45267.mp4

we start with plain old headless Beq... who is modelling a rigged mesh dress the pulsing pink box is the bounding box. Which is not the same as the hitbox, or related to the scale of the avatar per se, but is instead the visual extents of the drawable objects that make up Beq as we know her. The BB is around 3m diameter

I add a rigged mesh bento head and ... BOOM... 16m BB

why is this? well, it is not the rigged mesh, it is not even the bento... it is the scale of the attached object overall as a link set. 

There are a number of green boxes pushed many meters away from the head that force up the effective Bound Box size. The result is that in combination with the rigged mesh radius bug, and what I am now considering the avatar scale "bug" (though it is arguably a feature) we have an avatar that will NEVER LOD swap below medium and rarely LOD swap to medium.

The Jira that I created was an addendum to a Jira raised by @polysail on the reason that ARC is broken because the ARC is based on the actual size not the "LOD size". So here we have an extreme, I can wear a 150,000 triangle rigged mesh bento ring, and my bento head and that ring will be "costed" at 0.1m radius for ARC, and yet be fully "visible" across the entire region.

oops?

A new Jira will appear in the next few minutes.

EDIT: Jira for this - https://jira.secondlife.com/browse/BUG-214736

 

 

 

 

 

Edited March 15, 2018 by Beq Janus

[arton Rotaru]

1 hour ago, Beq Janus said:

There are a number of green boxes pushed many meters away from the head that force up the effective Bound Box size

Sounds like a clever trick to prevent rigged mesh from switching LODs.

[Beq Janus]

6 minutes ago, arton Rotaru said:

Sounds like a clever trick to prevent rigged mesh from switching LODs.

intentional or not, that is certainly the effect it has

[arton Rotaru]

1 minute ago, Beq Janus said:

intentional or not, that is certainly the effect it has

So what are those objects infront of the head, which I guess will also have to be rigged to the skeleton to make that work? Do they have any eligibility on that head, other than pushing out the BB?

[ChinRey]

3 hours ago, Beq Janus said:

There are a number of green boxes pushed many meters away from the head that force up the effective Bound Box size. The result is that in combination with the rigged mesh radius bug, and what I am now considering the avatar scale "bug" (though it is arguably a feature) we have an avatar that will NEVER LOD swap below medium and rarely LOD swap to medium.

I was afraid I exaggerated in my first post but this is actually far worse than I could possibly have imagined.

 

2 hours ago, Beq Janus said:

intentional or not, that is certainly the effect it has

There's intentional and then there is intentional.

The maker of the top in my example wasn't aware of it at all, he just had a habit of uploading in small size and couldn't understand why people complimented him for the low ARC until I told him.

Other makers know that you can lower the nominal ARC of fitted mesh by reducing the upload size but they don't seem to understand that they are just exploiting a loophole - they genuinely think that reducing the ARC that way actually reduces the render load. Maybe they should have known better, maybe not. Everybody have to make up their own mind about that.

[Beq Janus]

5 hours ago, ChinRey said:

I was afraid I exaggerated in my first post but this is actually far worse than I could possibly have imagined.

 

There's intentional and then there is intentional.

The maker of the top in my example wasn't aware of it at all, he just had a habit of uploading in small size and couldn't understand why people complimented him for the low ARC until I told him.

Other makers know that you can lower the nominal ARC of fitted mesh by reducing the upload size but they don't seem to understand that they are just exploiting a loophole - they genuinely think that reducing the ARC that way actually reduces the render load. Maybe they should have known better, maybe not. Everybody have to make up their own mind about that.

The fact that Maya defaults to a mm scale and thus maps everything smaller into the SL metre scale means that for many that reduction is just the default. Which in fact is worse, if the default "no action" behaviour is the bad behaviour then people have to try hard to be "good" citizens.

[OptimoMaximo]

2 hours ago, Beq Janus said:

The fact that Maya defaults to a mm scale and thus maps everything smaller into the SL metre scale means that for many that reduction is just the default. Which in fact is worse, if the default "no action" behaviour is the bad behaviour then people have to try hard to be "good" citizens.

Apparently i've shaken a wasps nest with this. The whole problem sits in the scale, in my opinion. Maya's default linear units is centimeters, and it's how big the avatar actually is, as proved by the Collada import scale on the Avatar container group AND the meshes! That file was exported from Blender Avastar to prove the point of what the dev team had to do for compatibility. The scaling up to meters, on the avatar, happens at runtime in SL. However, in Maya you can, and should, model up to scale (meters) and you can rig the same with a scaled up avatar. Anyway, even when i can't manage to work up to scale on a couple of devkits, i make sure to import the item with a 100 scale, just to avoid the deformations due to the minimum prim size in SL. But i wonder: are we sure that the meter scale rigged attachment is the correct one for calculations, given that the real size of an avatar at its beginning is centimeters scale. So here i'm back to the scale factor. If the meter scale attachment snaps to rig and then the avatar scales up, the distances in the linkset scale up as well, giving you a 16 meters bounding box: what previously was 16 centimeters distance, scaled up by 100 gives you 16 meters. Because, as i was saying in my theory, the ITEM (transform node) scale isn't reduced to centimeters, the skin does it on the geometry (shape node), then the avatar goes to meter along with all the hierarchy's children, including the item transform, which size didn't actually change to centimeters. Hopefully i made my theory clear

[OptimoMaximo]

I guessed that adding some illustration to the theory might help

So i started with a meter scale avatar and rigged 2 cubes to the head to have a linkset

Notice the Avatar node is scaled up. Local Scale is intended as visual scale on screen

The flat cube in fron is 16 cm away from the original one

Export it as it is, notice the scale on my selection

I then scaled it down to natural centimeters scale, nothing changed in the scale and the skin made the cube shrink down accordingly. Next step, i detach the skin...

...and the cube goes back up where it was when it was first bound to the skeleton. Step back, so the skin turns back active and the two cubes go back to the avatar. 

Notice where the Transform node (the pivot point location) is when attached to the skin

I then set all to centimeters, recentering the pivot point to the new scaled position and exported. Upon import, same behavior as for the Collada's from Blender Avastar (except for the avatar meshes rotation)

Both FBX and Collada report consistent scale compensations upon import in both Maya and FBX Converter's viewer. Thing that i don't think is happening in SL, which i would represent likely the picture number 7. The item transform node is placed there with its size, parented to the avatr object and further scaled up to render it at meters scale. The attachments distance from both avatar and between them scales up as well, pumping up the inworld avatar's BB size.

Edit> Also notice how, in picture number 2, the vertical location of that cube is around 170 centimeters when rigging to the meter scaled avatar. Scale up that distance by 100 and we get near (a bit beyond actually) the 16 meters that @Beq Janus reported.

Edited March 15, 2018 by OptimoMaximo

[OptimoMaximo]

On a side note, a bit of a derail. I think LL initially designed SL to work in centimeters, but then they realized how big a sim would be (land sales loss) and how crappy a terrain would look with a so small heightmap texture (in comparison to the perceived sim size with a so small avatar). So the solution! Scale everything up to meters and put a limit to the number of prim on each sim, even if they can support more! And limit the prim size, so that land is never enough! In such a case, good thinking...

[Beq Janus]

21 hours ago, OptimoMaximo said:

 But i wonder: are we sure that the meter scale rigged attachment is the correct one for calculations, given that the real size of an avatar at its beginning is centimeters scale. So here i'm back to the scale factor. If the meter scale attachment snaps to rig and then the avatar scales up, the distances in the linkset scale up as well, giving you a 16 meters bounding box: what previously was 16 centimeters distance, scaled up by 100 gives you 16 meters. Because, as i was saying in my theory, the ITEM (transform node) scale isn't reduced to centimeters, the skin does it on the geometry (shape node), then the avatar goes to meter along with all the hierarchy's children, including the item transform, which size didn't actually change to centimeters. Hopefully i made my theory clear

8

I think I understood, and it would be a bug if true - and very worthy of a Jira - but I have a problem with the theory. Why do you state that the real scale of an SL avatar is cm? Unless I am missing something (which is entirely possible, I've poked @polysail as she is my skeleton and rigging guru and hopefully she will confirm); internally models (the skeleton included) are in normalised units (floating point 0.0-1.0 quantised into a 16bit integer - actually in this case -0.5:0.5 but you get my point). All unit based conversion happens prior to uploading and human scale units cease to exist thereafter. The models are then scaled based on either their object's input scale in world coordinate (metres) or for rigged mesh, the avatar shape's scale. So there is no input scale to be lost at this point. The same applies to any attachment. 

When a weighted item is applied to the skeleton it is transformed to fit to the skeleton. This is not the same as scaling because each vertex has a different weight, moreover, the models were all converted to normalised object space coordinates (those pesky 16-bit integers) on upload.

In a link set. each object has its own object space, and its own bounding box,  but the relative positions of objects to one another are maintained in world space, this is where I get a little more patchy as I don't have time to go check the code here, but given that with a script we can alter the relative positions of components of a link set it would appear to make sense that these are in world space, or at least in an independent space (hence the 64m linking range?). I think the point here is that rigged vertices are weighted and thus do not affect the BB very much, but object positions and unweighted/non-rigged objects do.

Edited March 16, 2018 by Beq Janus
minor clarification on input scale for non-worn items.