Strange LOD transitions

[Vlad Soleil]

Hello,

I'm observing a strange behaviour on how the LOD levels are displayed. I'm using the official viewer and I've uploaded a different collada model for each LOD level, but it seems that the Lowest LOD model for two objects sized (XxYxZ) 1x1x1 meters and 1x1x50 meters is displayed more or less at the same distance, which is less than the distance at which the same Lowest LOD model is displayed for an object 1x2x1 meters. In addition, the Land Impact of the 1x1x50 meters object is higher than the Land Impact of the others.

So, if you double the Y size of the object you increase the Lowest LOD transition distance more than if you multiply the Z size by 50, and you get less Land Impact penalisation.

According to official documentation “To compute the distance at which each LOD is displayed, take the radius of the object's bounding box (R) and divide by the LOD ratios used in the viewer”. Should I therefore conclude that the “radius of the object's bounding box (R)” is the “radius of the XY projection of the object”?.

Maybe the behaviour is correct with regard to the documentation, but from a practical point of view it does not seem acceptable.

Has anyone had the same problem?

Thank you.

Best Regards,
Vlad Soleil

[Kwakkelde Kwak]

I have had a similair issue yes, not sure if it's the exact same thing though. In my case it had to do with rotation. A 0.5x4x24 m (I think, but something like that)  object switched LOD at less than the objects length, around 10 meters. Turned out the pivot was rotated by 90 degrees before uploading. I hope this helps. Weird thing was the object showed fine in the upload window, yet when rezzed it defaulted at a 90 degree rotation.

If everything works well, the bounding box is measured using all 3 axes.

[Vlad Soleil]

Thank you for your answer, Kwakkelde Kwak.

I've tried to rotate inside 3DSMax an object, and the attached picture shows my results.

The red object is 0.1x0.5x1.0 meters.
The blue object, which is the rotated red object, is 0.1x1.0x0.5 meters.
The yellow object, which is the resized red object, is 0.1x0.5x10.0 meters.

I've uploaded the red and the blue objects with the same High, Medium and Low models and I've set the Lowest model to 0 triangles.

This time I'm using the Phoenix Viewer and, as you can see, the red and the yellow objects collapse to the Lowest LOD before the blue object!

 

[Kwakkelde Kwak]

So that means it is fixed then i suppose:) The behaviour is odd, but it's not a SL bug I think. As I remember it, the weirdness is already there in the collada file. Anyway, you can stretch the blue one and get the proper behaviour right?

[Vlad Soleil]

I don't think it is fixed :matte-motes-smile:

That object is made of only 44 vertices and it shows an “odd” behaviour... what will happen with objects made with thousands of vertices !?

If it is not a bug (and I have no reason to think differently), I'd like to know what I'm doing wrong. I've simply rotated the objects in 3DSMax, resetted the transform matrix and then exported it.

[Kwakkelde Kwak]

Yes, the blue one right? So that one is good or am I missing something?

EDIT I think in the collada file one axis is negative, that would mean SL doesn't understand it's 10 meters, or 40 or 64.

 

[Vlad Soleil]

Yes, the blue one could be ok... but my problem is that I can't (and I don't want to) repeat all these tests for each mesh I upload, just to find the right way to get the best LOD behaviour.

The LOD behaviour should be the one described in the official documentation, and should depends only on “the radius of the object's bounding box ®”. If something else can affect that behaviour, as my tests seems to indicate, I think it should be documented as well.

[Kwakkelde Kwak]

The bounding box SL sees is based on what is in the collada file, not what's in your .max or.3ds file. You could write a JIRA on it though, since it sure can be fixed. I can say that because in the older viewers this bug didn't occur. However, even your 3D model in max has some "mistakes" when you run into this. Make sure the pivot is aligned to world. If you don't want to make any changes as far as rotating and mirroring go (which can be a pain I know) you can create a new object, attach the old one to it, then remove the new object from the model by vertex or polygon. That way the old object has the global properties the new one had.

[Vlad Soleil]

Whatever the bounding box is, if you double the Y size or the Z size, you should double the bounding box.

The original problem I noticed was that (on the red object) “if you double the Y size of the object you increase the Lowest LOD transition distance more than if you multiply the Z size by 50, and you get less Land Impact penalisation.”.

Honestly, I can't believe to a such level of oddities in a DAE file for an object made of only 44 vertices.

The llGetScale() function for the mesh returns correct values, so SL sees the correct measures in that DAE file.

 

[Kwakkelde Kwak]

---

Vlad Soleil wrote:

 

The original problem I noticed was that (on the red object) “if you double the Y size of the object you increase the Lowest LOD transition distance more than if you multiply the Z size by 50, and you get less Land Impact penalisation.”.

---

Yes since an axis is one dimensional and the bounding box is three dimensional. So it makes perfect sense that stretching along one axis doesn't have the same impact as stretching another. This is ofcourse the case if the axes aren't equally long.

In your case this doesn't apply, but an axis is borked. That's what causes it. I have had the very same thing. I could stretch an enormous amount without the landimpact following.

---

Vlad Soleil wrote:

 

Honestly, I can't believe to a such level of oddities in a DAE file for an object made of only 44 vertices.

---

Wrong axis data can occur in an object built out of 3 vertices, or 65000, the amount is completely irrelevant.

---

Vlad Soleil wrote:

 

The llGetScale() function for the mesh returns correct values, so SL sees the correct measures in that DAE file.

---

Yes probably because that function takes the difference between the extreme values.

 

My question is did you check your pivot in 3ds max? Is it rotated? Is it mirrored even? (I think that was what happened with my model a couple of months ago) if it is that can be considered a "mistake" and even though LL can undo that mistake in the upload process, I don't think it is something they have to do.

Previous Thread, where my model was discussed

You can read some more about it here...

[Vlad Soleil]

Thank you for the info. That thread about your model was really interesting.

However, the pivot of my object in 3DSMax is aligned with the scene.

I've checked the transformation matrices for the collada models, and they are:

<matrix sid="matrix">1.000000 0.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 0.000000 1.000000</matrix>

so, for what I understand, there is nothing strange in them (coordinates are kept unchanged).

In your previous thread you wrote that “it could be very possible the uploader counts x and y far heavier than z for LOD”, which is *exactly* what I think now.

[Kwakkelde Kwak]

As I remember the numbers in my matrix or matrices had minus signs here and there, corresponding with the borked pivot.

It has been a while, but it kind of makes sense that x and y count more than z for LOD, since avatars as human beings are usually on the same level as the objects they are looking at or interacting with. Something definately worth looking into some more, not only because of your issue, but also because of the potential "cheating".

Anyway, if x and y are indeed heavier on the primcount an LOD distance, the documentation is indeed not correct. But as I recall several people looked into it and found no way to duplicate the issue.

No time to test right now, but I might and I'm sure so will others....

[Vlad Soleil]

The problem seems to be related to the number of materials in the model.

The original model had 4 materials and now, after removing them, the object shows a completely different (and more conventional) LOD transition behaviour.

[Kwakkelde Kwak]

This seems to be a hard one to tackle.

The behaviour you had is the exact behaviour I had. However the reason behind it is not clear, I thought I had it worked out with the pivot, but you clearly have a normal one. In my case the materials couldn't have been the problem, as I said in the other thread, my models were identical and with the pivot reset it behaved like it should. Very strange...

[Vlad Soleil]

Now I'm able to reproduce the issue even with a single box, with 3 materials applied on it (same material on opposite faces, I've not tried different combinations).

When I rez the object inworld, it is 0.1x0.1x0.1 meters.

Then I create 3 new boxes (inworld, with a copy & resize from the original one):

a)  1x0.1x0.1 meters
b)  0.1x1x0.1 meters
c)  0.1x0.1x1 meters

What happens is that the box c (made from a resize on the Z axis) has the same behaviour as the original box and collapse before the other ones (even setting the size to 0.1x0.1x10 meters !)

No, the concept of “bounding box” is not enough to explain this and for sure there is something strange...

 

[Kwakkelde Kwak]

Mindboggling stuff this:) how on earth did you find it? hehe

I got the same results you have, the place where the materials are, doesn't seem to be relevant.

I tried it with your setup, then with two connected sides of the box with the same material (top-side, side-side, side-bottom), then with one on top, one on the bottom and one for all sides. All give the odd behaviour.

My object (the one from the older thread) also had three materials.

[Drongle McMahon]

Yes. Reproduced with the three-material simple box from Blender 4.29 too. Using auto-LODs and high LOD analyzed for physics shape. I'm sure this must be a bug. The LOD switch code is not as simple as suggested in the mesh wiki, where it looks like r/0.24, r/0.06, r/0.03 (*renderVolumeLODFactor). It has some extra adjustments added. How it can be affected by the number of materials is not obvious though.

The number of triangles in the automatically generated LODs are different with different numbers of materials, I suppose this is because of the need to accomodate all the materiuals at the lower LODs. That requirement was supposed to have been removed when it was changed to requiring a subset of high LOD materials, but a regression put back the requirement for the number to be the same too. So it could be something to do with the shape/dimensions of the lower LODs rather than directly of the materials. Still doesn't make sense though.

[Kwakkelde Kwak]

I did the upload with a couple of different custom LOD models, one with three triangles, one for each material, then one with four triangles, same results. then one with the same number of faces as the highest LOD, but a different shape... all give the odd behaviour.

So... do we have enough for a JIRA?

I think it looks like the calculation on the z-axis is borked when there are three materials. (the z-axis IS calculated, both Vlad and I found stretching it enormously does affect landimpact a bit. This allows cheating the system....)

I know Viewer 3.0.0 did NOT have this issue.

 

[Drongle McMahon]

"do we have enough for a JIRA?"

I think so. I think putting it on the Content/Mesh agenda and taking along simplest examples might be good idea too. I'm going look at the source code if I can find the right version, but it might not be anything obvious enough for me.

[Drongle McMahon]

Hmm. I made six simple 1x1 cubes, with from 1 to 6 materials, uploaded with autolods and no physics shape. I rezzed them and stretched 10x either along y axis or along z axis. The z axis ones were then rotated so that the long dimensions were parallel. Here are one to five materials - each pair is z-stretched then y-stretched, going left-to-right. The material counts are 1 to 5, left-to-right. The panels are snapshots at different values of renderVolumeLODFactor, which has the same effect as moving away, but keeps them the same visible size. The values, top-to-bottom are 0, 2 and 5. The six material one behaved the same as the five material one. So the z-stretch bug is seen only on the ones with three or four materials.

I also made highly subdivided versions of all of these, so that they had measurable download weights. The LOD bug can be seen with these using wireframe view (same layout as before), so it happens just the same with these. However, there was no difference in download weight or land impact for the three-material model when it was stretched in the y or z dimensions. Maybe that's not surprising as the weights are now calculated by the server, while the LOD switch distances are calculated by the viewer.

ETA: if you are wondering why the lowest LOD meshes are different for the z-stretched 3 and 4 material models, while their high-LOD geometry is identical, it's because the auto LOD generator is non-deterministic - that is it can give different results each time it is applied to the same input mesh.

 

[Vlad Soleil]

... and I decided to stop working with Sculpted Prims just because I thought it was too difficult to predict their LOD behaviour :matte-motes-big-grin-squint:

However, thank you Kwakkelde Kwak  and thank you Drongle McMahon for your help in classifying this as a bug.

[Drongle McMahon]

OK. I did the jira. Please add comments/examples as you feel needed.

[Kwakkelde Kwak]

Anyone have news about the project?