Same mesh shape & physics but different Land Impact!

[grezz360]

I made the following 3 stores. For each of these stores, I got a separate roof, floors and walls on each side. I first made the centre store, then made the right side and mirrored it to left. Applied the transformations, baked all textures & made all LODs. Those 2 sides have same number of materials, same number of vertices & tries (as per Blender). But somehow, I get two different Land Impacts on left & right roofs & 1st floors. Everything else matches.

Below are the LI when those are set to Prim (Physics Shape Type). Both have hole for stairway. Dimensions are same (both physics & mesh)

	Left (LI)	Right (LI)	Remark
Roof	3	4	Convex Hull LI (left - right): 3 - 4 Both have same physics, download & server weight. But more display weight is different (L)1826 - (R)1831 - Both side carries 3 textures. Only difference i found was 4 extra vertices on left (this side happens to give low LI than the other) All LODs have same vertices & tries (as on upload window) Both roofs have physics of 2 tries
1st Floor	3	2	Convex Hull LI (left - right): 2 - 2 Both have same download, server & display weight Somehow Mesh is high on left. Thus high physics - Both dimensions are same & I have double checked if it goes beyond boundary. all good. Only difference I found here was 1 extra vertices on right (this side happens to give low LI than the other) All LODs have same vertices & tries (as on upload window) This is after I managed to remove 2 physics tries from each. Before it gave 6 - 3 (left - right) LI (in Prim mode) Both floors have physics of 8 tries

 

Floor Upload Window

 

So I'm quite puzzled about this & curious to know whats the cause and how could it be fixed or at least a way to lower the LI.

[Beq Janus]

The cost of the physics is derived from the area of the triangles that make up the mesh with additional cost being assigned to triangles that are longer than they are wide (long thin triangles) this is because they increase the cost of collision detection. The extreme case of this being the degenerate triangle, which in mathematics is where two of the vertices are the same, but in the viewer it is signified by being a small percentage of the total length of the sides (if I recall correctly, though it might be a small percentage of the average length). Degenerate triangles result in the red highlights in the preview and the instruction to reduce the complexity/remove thin triangles.

I suspect that the small differences that you found were enough to skew a few of the triangles into a "longer thinner" category and thus incur a penalty.

Edited November 18, 2020 by Beq Janus
added a bit more description on degenerates

[Aquila Kytori]

Without having access to your .blend file it is differcult to say what may be poing on. So if you are still having problems you could, copy and paste the floor models (along with their Physics models) into a new .blend file and upload it somwhere so we can check the model and do some test uploads.   A Blender file sharing site :   https://pasteall.org/blend/

A couple of things that don't look quite right in your screen shots :

First, in the preview window, your collision surface is in the middle of the visual model instead of being aligned to the top surface of the floor.

Secondly, your, high LoD visual model seems to be using more triangles than is necessary, 76 instead of around 35 or so.

 

As the difference in LI looks like it is being caused by the Physics costs try rebuilding your Physics model.

Note:  when using "planes type" Physics, (not Analyzed in the uploader) if one or more of the  X Y Z dimensions of the models Bounding Box are less than 0.5m then even when you change the Physics Shape Type to Prim it will actually remain as Convex Hull and all opening will be closed.

There are different workarounds to this. One is to add an extra vertex to the visual and physics model to increase the size of their  bounding box and set this vertex as the first in the list of vertices in the .dae file. ( Loose vertices are usually deleted on upload but not if it is the first in the list of vertices).

In the example below the original floor is 15 x 15 x 0.2m. This 0.2 needs to be increased to something more than 0.5m.

For this floor using two collisions surfaces (upper and lower) make a copy of vertex A and move it up along the Z axis by 0.6m, (vertex B).

With this new vertex still selected, open the Mesh menu > Sort Elements > Selected.  The new extra vertex  is now the first in the list.

Note: if you modify your model again before exporting it is best to repeat the above again for the extra vertex.

Use the same method to extend the Bounding Box dimensions of the Physics model.

Note: If you are only wanting a single collision surface on the top surface then  the Bounding Box would be extended dowwards, the  extra vertex would be below the floor level.

In all cases the Bounding Box dimensions of the Physics model should match the BB dimensions of the visual model. If there is a difference then the SL mesh uploader will stretch or squish the Physics BB to that of the BB dimensions of the visual model. This will result in offset collision surfaces !

Now you can try upoading again.

When rezzed inworld the extra vertex will not be seen. In this example the Physics cost for a double sided floor is 0.5. 

 

 

 

Edited November 19, 2020 by Aquila Kytori

[grezz360]

Thank you @Beq Janus & @Aquila Kytori for that awesome & quick reply.

12 hours ago, Beq Janus said:

skew a few of the triangles into a "longer thinner" category

 

11 hours ago, Aquila Kytori said:

As the difference in LI looks like it is being caused by the Physics costs try rebuilding your Physics model.

As you both mentioned about a possible auto-generated thin triangle on uploading process, I looked into the one I have uploaded already (below is a pic of auto-generated physics of the Floors in in-world).

Then tried manually converting physics quads to tries in Blender, making both have same size tries. But still, somehow Land Impact vary.

 

11 hours ago, Aquila Kytori said:

A couple of things that don't look quite right in your screen shots :

First, in the preview window, your collision surface is in the middle of the visual model instead of being aligned to the top surface of the floor.

Secondly, your, high LoD visual model seems to be using more triangles than is necessary, 76 instead of around 35 or so.

It is because, I got some more mesh for side woods :3 (see the links to files below)

So, the walk-able surface is just about the center of Mesh. I have removed that 2 thin tries on sides (next to stair way) as there will be a wall that goes over it which has its own physics. Made it 1 triangle instead to cover height (its visible on above pic). I could eliminate this triangle as well with above method right? by adding 2 vertices (for top and bottom)

Links to Blender Files

High LOD & Physics  |  Med LOD  |  Low LOD  |  Lowest LOD

Somehow roofs match now after I reduced few tries on low LOD.

Floors: when i export & upload from the newly saved file I have attached, it gives (L) 4 - 2 (R) LI. When exported from original file it gives (L) 6 - 3 (R) LI

[Chic Aeon]

@Aquila Kytori   So  this isn't an issue with CUBE physics models?  

[Aquila Kytori]

5 hours ago, Chic Aeon said:

So  this isn't an issue with CUBE physics models?

Remaining Convex Hull if less than 0.5m?  No this not a problem for Cube physics. 

 

@grezz360

For the Floors I believe the issue is with the little vertical triangle that you are using to keep the BB Z dimension of the physics model equal to the BB of the visual model. (the triangle by the stairway opening)

I have had problems using a vertical triangle this way not so long ago and the answer was to use a much bigger triangle!

 

But if we use the extra vertice method as mentioned in my previous post then this is not necessary.

I haven't looked at the roof models yet so the following is only for the two floor models :

1: For the Physics model of the floor first add a new big plane aligned to the under surface (cieling) of the visual mesh. This will be used to keep the lower limit of the BB box matched  to the visual model.

2: Delete two of the vertices of the little vertical triangle by the stairway opening, keeping only one of the upper two vertices.  This will be used to keep the upper limit of the BB   matched to the visual model.

3: Make this floating vertice the first in the list as mentioned in my previous post. Vertex selected > Mesh > Sort Elements > Selected.

BTW you can see the order of the vertices in Blender if you open the Viewport Overlays dropdown > Developer > and enable the Indices option. The first in the list is numbered 0.

 

Then export as .dae.

 

I did this mod for both floor physics models and when uploading found  only a very little difference in the Download costs and final LI when rezzed.  Floor left  LI 1.7 and Floor right1.8.

 

 

 

An example of the modified Floor Physics can be downloaded from here :  https://pasteall.org/blend/d4248ae99f914a4b940e5962bc1dcf62

 

I will take a look at the roofs later

Edited to add :

5 hours ago, grezz360 said:

I could eliminate this triangle as well with above method right? by adding 2 vertices (for top and bottom)

Nope, you can only have 1 loose vertice, "the first in the list" vertice. (The other will be deleted). That is why a big plane was added under the floor instead. (The uploader likes to find big tris in the physics model. Part of the physics equation cost is the average area of the all the tris in the physics model, Larger the average size lower the cost. Adding a big plane can actually lower the physics cost). Take a rezzed model using non analyzed physics, scale it up and watch how the Download cost increase and the Physics cost decreases.

 

 

 

Edited November 19, 2020 by Aquila Kytori

[Aquila Kytori]

I didn't find any noticeable difference between the two roofs in Download or Physics costs in the Uploader or when rezzed.

I should mention that I brought all the models into a single Blender file and this resulted in multiple versions of the materials, different materials for each model. So rather than sort all those out I simply deleted them all so they would be accepted by the Uploader but I don't think this will have made much difference to the Downlod costs.

If need be you can have much more accurate physics for these roofs and still have a Physics cost of 0.5 when set to Prim.

 

For the roof models the  Download costs are higher than the Physics costs so its these that you need to work on to lower the final Li cost.

A quick check in the Uploader shows that if you can reduce the tri count of the Medium LoD to between 20 and 25 this would result in a Download/LI cost of less than 2.  For an object this size the Low and Lowest LoD models have little if any effect on the Download cost.

 

[grezz360]

Using the single vertex method, I have managed to reduce physics from 2.5 to 0.5 on mid floor. But the sides are going way out the roof. 17K to 53K of LI! 🥺

Mid Floor Physics with Triangle to cover Z axis in BB

Mid Floor Physics with Single Vertex Method (with a big plane on ceiling surface)

 

Side Floors Physics with Single Vertex Method (with a big plane on ceiling surface)

Top View

Bottom View

 

Uploading only one side (the side @Aquila Kytori have redone the physics)

Physics made in my original file, following the vertex method steps

The same mesh & LODs but physics changed to the physics model made by Aquila

 

Cross-checking My Physics (left) & Aquila's Physics (right)

All the dots seems to be in same position. Single vertex is the number 0 on both. I did even redo the physics and tried. Still don't work on mine!

 

15 hours ago, Aquila Kytori said:

I didn't find any noticeable difference between the two roofs in Download or Physics costs in the Uploader or when rezzed.

Correct, its physics was low. The problem was in Download which had a difference until I reduced few tries from Low LOD on both side before I posted 2nd time. I tried to keep the shape without loosing too much details as it is a building.

15 hours ago, Aquila Kytori said:

For the roof models the  Download costs are higher than the Physics costs so its these that you need to work on to lower the final Li cost.

In your example, it seems to me that it works pretty much like box physics method where number of tries don't really matter! I did want to have a plane on all sides, so no one can get in and out of the roof 😄. In my mind the less tries on physics, it cost less on physics cost. That is why I lowered it 2 tries.

I got few others that needs to correct Download without loosing its shapes (see below). 3LI for a small door and 13LI for front wall on ground floor (the 1st floor front wall also have a hole but it is 4LI. both these have 3 materials). Physics is now below 0.5 on all the parts, except the 2 floors. Is there any way I could lower Download Cost other than reducing tries from the LODs? and does physics effect download?

[Aquila Kytori]

1 hour ago, grezz360 said:

Side Floors Physics with Single Vertex Method (with a big plane on ceiling surface)

Top View

This crazy high Physics cost happens sometimes . The fix that usually works is to make sure the coplaner surfaces are perfectly flat.

In the Physics model, select the faces of the top surface 'floor) and scale them to zero along the Z axis.

S Z 0 validate.

Then repeat for the faces on the underside (cieling).

 

[grezz360]

Sweeeeeet! That worked out perfectly! Its 2LI each now. Brilliant. Thank You. I have learned a lot from this thread, appreciate it

Edited November 20, 2020 by grezz360

[Aquila Kytori]

2 hours ago, grezz360 said:

I got few others that needs to correct Download without loosing its shapes (see below). 3LI for a small door .....

As a general rule, before making any lower LoD models, load up your High LoD model into the SL mesh uploader then play around with the variables of each LoD to find out what triangle count you need to be aiming for for each of the LoD models .

For example, your door, lest say you have in mind a LI (Download cost) of 1.

A single door is a small object so the Medium LoD probably has little effect on Download cost so you can set that to "Use LoD above". Then play around with the Low and Lowest triangle counts to find out what  numbers you need (tri count) to get a download cost of around 1. To me it looks like you are using way to much geometry in the Lower LoD model .

2 hours ago, grezz360 said:

......and 13LI for front wall on ground floor

For the front wall it looks like it is the Medium LoD you need to be work on to reduce the tri count.

2 hours ago, grezz360 said:

Is there any way I could lower Download Cost other than reducing tries from the LODs? and does physics effect download?

Download cost is depended on number or tris/vertices and the size of the model. The more complex the higher the Download cost, the larger the BB the higher the Download cost. Smooth shading / Flat shading, UV's and material bounderies also effect the download cost but the by far the most important is the complexity of LoDs and size. Once you have your high LoD model optimized as much as possible then all you are really left with to reduce Download cost are the lower LoDs.

I am not 100% sure of this  (perhaps someone like @ChinRey or @arton Rotaru can correct the following)  but  for the the size it is the Bounding Box radius that is used.(?) The distance from the center to the outer edges (corners?). So sometimes it can be more advantageous to upload all four walls of a room instead of each wall separately.

For small models it will be the Low and or Lowest LoDs modesl that have a big effect, for larger objects it will be the Medium and for huge objects it will be only the High LoD model.

Sometimes you can get away with using "billboards" / "imposters" (images on planes) for one or two of the lower LoDs. If you can do this then this can really reduce the Download costs dramtically.  

page 2 third post down  

 

Physics has no effect on Download costs.   

Edited November 20, 2020 by Aquila Kytori

[ChinRey]

5 hours ago, Aquila Kytori said:

I am not 100% sure of this  (perhaps someone like @ChinRey or @arton Rotaru can correct the following)  but  for the the size it is the Bounding Box radius that is used.(?)

That's not too far off. The size element of the weight calculations is actually √(x²+y²+z²), that is the square root of the sum fo the size along the three axises squared.

I've stayed away from this thread since I didn't have that much to add to what Aquila and Beq have already said but since I'm posting here anyway now, keep in mind that a difference of only a single LI may well be just a combination of compressability and rounding. The download weight is based on the size of the transferred file and since that is a gzip file there will always be a slight difference between the two mirrored files even if they contain exactly the same amount of raw data. Let's say one ends up at 3.499 and the other at 3.500. That's only 0.001 difference yet one is rounded down to 3, the other up to 4.

[Aquila Kytori]

@ChinRey Thankyou

I had vague memories of Drongle mentioning that it was the radius of the bounding box that was relevent for the size part of the Download calculation so now after spending over an hour searching through very old threads found the one I was looking for. (Before that I was searching Google to find out what your √(x²+y²+z²) was generally used for. Maths is not my thing ).

Anyways, now I think I was correct in saying (guessing) that it was the radius, distance from the center of the BB to one of its corners and that you forgot to add the divide by 2 at the end of √(x²+y²+z²) ?

Check out Drongle's second paragraph here  :

 

 

Whatever happened to Drongle ......................?

 

 

Edited November 20, 2020 by Aquila Kytori

[ChinRey]

14 hours ago, Aquila Kytori said:

Anyways, now I think I was correct in saying (guessing) that it was the radius, distance from the center of the BB to one of its corners

The question is how is the "radius" of the bounding box - which of course is a cube, not a sphere - defined. I got the formula here from a later post by Drongle and it's been later confirmed by Kyle Linden and also by tests I've made.

 

14 hours ago, Aquila Kytori said:

and that you forgot to add the divide by 2 at the end of √(x²+y²+z²) ?

I only included the part of the formula direcvtly related to the object size. The complete formula for LoD swap distances should be:

• For cylinder prims:
  • Dmid=√(x²+y²)*n*Lf
• For all other prims, sculpts and meshes:
  • Dmid=√(x²+y²+z²)*n*Lf
• For all prims, scultps and meshes:
  • Dlow=Dmid*4
  • Dlowest=Dmid*8

Lf is the RenderVolumeLODFactor the viewer is set to

n is probably the constant you had in mind when you talked about dividing by two. It's not the same value for all objects though. If I remember correct, it's 0.48 for cube and prism prims and c. 0.6 for all other prims, sculpts and meshes.

Please don't ask me how this relates to the "explanation" in the official documentation. The official documentation is obviosuly wrong in  that it doesn't take RenderVOlumeLODFactor into account but apart fromt hat, it may well be another even more convoluted way to describe the same thing. I'm not going to decipher that mess.

  

14 hours ago, Aquila Kytori said:

Whatever happened to Drongle ......................?

Good question. I always assumed he just got fed up and left. I really hope all is well with him.

Lots of people have contributed to the unravelling the Big SL Mesh Mystery of course but he's the one who did the most work by far and I'm not sure we'd ever managed if it hadn't been for him.

Edited November 21, 2020 by ChinRey

[Aquila Kytori]

 

The furmula  √(x²+y²)  is used to find the  diameter (length of the diagonal through the center, corner to corner,) of a rectanglar box shape, (our Bounding Box), and  √(x²+y²) /2. gives the radius.

 

8 hours ago, ChinRey said:

For all other prims, sculpts and meshes:

• Dmid=√(x²+y²+z²)*n*Lf

 

So instead of simply dividing by two (= radius) they use the *n* ( a scale bias* ) instead. Which is the almost the radius but not, AND this  n "constant" value can change between 0.48 and 0.6 ! depending on .......

8 hours ago, ChinRey said:

If I remember correct, it's 0.48 for cube and prism prims and c. 0.6 for all other prims, sculpts and meshes.

To a non techie person this seems just silly.

Writing this down here will hopefully help me remember it better so thanks again for filling in some of the details. 

 

 

* scale bias :

"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) "

 

 

Edited November 21, 2020 by Aquila Kytori

[ChinRey]

31 minutes ago, Aquila Kytori said:

To a non techie person this seems just silly.

As a certain "YT Game Guru" once said, Second Life was made by developers for developers.

In this particular case it does does make a bit of sense since prims without curves don't really need as strong LoD as the ones with. You may even argue they should have made the difference bigger. But in general, yes, it is a problem that LL's developers so often don't understand the practical application of all those wonderful new features they develop.

[Beq Janus]

On 11/21/2020 at 4:15 AM, ChinRey said:

The question is how is the "radius" of the bounding box - which of course is a cube, not a sphere - defined. I got the formula here from a later post by Drongle and it's been later confirmed by Kyle Linden and also by tests I've made.

 

Sorry, got distracted away on other things. The radius of the BB is indeed defined by the equation you cited. except for the divide by 2 that @Aquila Kytori noted. It is an extension of the basic Pythagorean equations to get the hypoteneuse of a triangle (the long edge) is the square root of the sum of the squares of the two sides (opposite and adjacent)  a²⁼√(b²+c²). This extends to three dimensions by adding the third length into the right hand side. When we are using the overall dimensions of a box, this gives us the full diagonal, and thus we divide by two to get the radius. 

Don't be thrown by the bounding box being a box. what you are calculating is the radius of the smallest sphere that would completely enclose the bounding box.

All the rest is mathematical shenanigans that are to some extent lost in time. The volume modifiers are I believe intended to compensate for the BB/radius issue. The human brain does a pretty good job of assessing size and volume, given a ball and a box of similar sizes we would expect the two to behave similarly over distance (LOD swap at the same time) however the BB radius of the cube is larger than the "similar size" ball and thus the ball would swap before the cube. There are all kinds of issues with such simple rules, but I hope this explains where the idea comes from. 

 

[Beq Janus]

On 11/23/2020 at 3:29 PM, Beq Janus said:

 a²⁼√(b²+c²)

Ugh typos plague me. As it won't let me edit..a²=b²+c²  OR a=√(b²+c²)