Prims Land Impact Whatever

[dustty]

I have a mesh which consists of ten boards .5m wide and 16m long .1 high.. (essentially 10 cubes) With no textures applied upload fee is 20L and land impact 5.. One texture app;lied and it goes to 21l and Land impact 5.1. With 7 different textures apllied it goes to 62L upload fee and land impact of 20.5.. Triangle c out goes from 120 to 122 vertices 200 to 244.

This is using sketcup and I havnt  built this same mesh with blender.. The vertice count does seem high..

I can do the same thing with 10 prims and not bother with mesh Comments?

[Drongle McMahon]

I uploaded 10 planks that size side-by-side with uv maps and eight different materials, all in one Blender object, using the high LOD mesh for all LOD slots and decomposed physics shape with 10 hulls, getting download weight 1.9, physics weight 0.36 and server weight 0.5. (If the planks were separate objects, I guess they would be 2.5 which would be the server weight).That is much cheaper than 10 prims.

So there is something strange going on with your numbers. Of course if they were in one object and layed out end-to-end, the download cost would be much higher. Were the planks arranged the same way in all your uploads? The upload cost was 15L$ without textures. Your texture uplaods seemed a bit cheap - 7 textures should be L$70, shouldn't it?

As far as the vertices are concerned, the triangle counts are 120 ans expected. The internal streaming format requires that vertexes are replicated each time they appear with different normals and/or UV coordinates and/or materials. The uploader count includes this replication. There are three planes with different normals at each vertex if the planks are sharp-edged. That makes 3 x 8 vertex table entries per plank, which is 240 in total. I don't know why yours would differ from that. I would certainly not expect an increase in download cost for adding textures. Did you try uploading without the textures and adding them inworld?

 

 

[dustty]

Those are textures I have not uploded they were quickly made in gimp for this deck experiment.  To be honest I am at the threshold of learning blender and it is not easy yet to build even simple mesh in blender export uv maps and and render. I am fairly proficient with gimp and photography. I did go thru the learning process with sketchup and became discouraged with trying to export to other platforms for exporting to SL I did learn some tricks like triangulation and thoght I weas making progress until this  I did make a mesh with 5textured  planks and the impact was only 3.That export was without sketcups tringulation and imported tpo blender where i removed doubles and recaculated. normals. That didnt make any difference with the 10 planks.and i tried it 3 tnmes from scratch.  When I can produce mesh the way I want wiyth  miniumum prim impact  i could care less about the upload cost Thats what threw me with 20.5 for 10planks. Like I said in the first post I need to try it it in blender. I have been in hight tech projects and have used many softwares.. blender totally frustrates the hell out of me ROFL

[dustty]

This is a photo of the mesh uploaded to opensim         http://s1141.photobucket.com/albums/n594/karyoker/?action=view&current=planks_001.png

[Chosen Few]

There's no reason your numbers need to be be that high.  The boards are just cubes, right?  A full cube has 12 triangles and 8 vertices, but considering no one's going to see underneath the deck, the undersides don't need to exist.  That lowers it to just 10 tris per board (vertex count remains at 8).  So, the total for all ten boards should be 100 tris, and 80 vertices.

Somehow you've got extra vertices in there that don't need to exist.  Sketchup is a funny little program, so I would imagine it's probably the culprit.  It's probably splitting UV's where it doesn't need to.

As for textures, why do you need seven?  You could easily do the whole thing with just one.

 

Here's one I just made, with the exact same measurements you listed:

It's got a land impact of 4, and cost me all of L$14 to upload (L$24, if you count the texture, which I uploaded separately).  It has just a single 512x512 texture on it. I used the same mesh for all four levels of detail.

The uploader considered the vertex count to be 200, which is in keeping with the formula Drongle laid out.  Each board has 8 real vertices, four of which are touching 3 planes, and four of which are touching just two planes (since I did not put faces on the bottoms of the boards).  4x3 is 12, and 4x2 is 8, for a total of 20 per board.  Ten boards equals a perfect 200.

For the physics mesh, I went with a simple cube.  Had I used the model itself, the upload cost would have been L$3 higher.  The land impact would have come out the same, either way.

Obviously, land impact of 4 is a hell of a lot better than 10 prims.  It's also got less than 10% of the poly count that 10 SL cubes would have.  The display cost, including the texture, is 699, which is less than that of two SL cubes with default texturing.  And of course, one texture beats the hell out of seven (and demolishes the total 60 textures that a 10-cube object could potentially have on it).

This is one heck of a cheap object, on all counts.  There's no reason you should have to suffer a land impact of 20.5, just for such a simple item.

 

By the way, If you're wondering how it is that each board appears to be uniquely textured, even though there's only one texture applied, it's because of how the model is UV'ed.  Each board occupies its own space on the texture canvas.  Here's what the UV map looks like:

The texturing looks decent, but it would look considerably better if I'd spent any actual time on it.  However, I wasn't about to do that, just for this exercise.  I made the model in about 60 seconds, and then just slapped a generic wood texture on it that I already had. For all of one minute, 4 prims equivelency, and $L14, I think we can call this one good enough. 

[dustty]

Oh Ill be tickled pink when I can get those results. I know I can with blende..r I can unwrap and get a uv map and use gimp but my last attempt when i went to camera view i couldnt see anything lol Thats a simp-le mesh its just learning all settings and steps which isnt that hard when i can get back to it  Yea I have a texture with 5 planks on it i can stretch across the uv islands easy enuff.. Thnx At least now I iknow what it should be and I can guage my progress

[Drongle McMahon]

Hmm. I was surprised to see your bottomless planks costing more LI than my solid ones. So I did some experiments. The results are interesting. All were 10 bottomless planks 0.1x0.5x16, arranged as in your picture with 0.1m gaps. All used the same mesh in all LOD slots using the "Use LOD above" option. Physics shapes all used the high LOD without decomposition. Here is a table of the results. Differences were 1 or 8 materials (m1,m8), uv maps superimposed (u1) or separated like yours (u10). Multiple materials were used one to a whole plank. Finally, the planks were made into separate objects (sep) as I expect this is what Sketchup does. Numbers fom "More info" inworld...

 

object	upload cost	download wt	physics wt	server wt	display wt
m1u1	L$ 15	2.2	0.4	0.5	444
m1u10	L$ 16	3.6	0.4	0.5	564
m8u1	L$ 14	1.6	0.4	0.5	394
m8u10	L$ 15	2.4	0.4	0.5	459
sep	L$ 16	0.6	3.6	5.0	314

Not quite what one might have expected? I must say I have a hard time trying to explain the download weights. About a third saving for superimposing the UV maps - I think that must be because the repeated numbers make the data more compressible. But why does it cost less with more materials? And 0.6 for the separated objects?! (It's 0.1 each when they are unlinked - so why is it so much more when they are one object?). For the separate objects of course, the server weight predominates. Separation is never good for such simple objects.

The display weights are interesting. These are all without textures, just colours for now (m1u10 is 620 textured). The proportional differences are more or less in line with the download costs, which is consistent with the triangle count being estimated from the download data size, which was the case when the code was in the viewer. I guess it's still that way in the server. This means the compressibility affects the triangle count input to the display weight calculation. I think these should all have exactly the same display weight if it were to reflect real resource use. But why is ten separate plank meshes less display weight than ten planks in one mesh?

I made a jira about this ... https://jira.secondlife.com/browse/VWR-27401

[Chosen Few]

Curiouser and curiouser.

Looks like you got basically the same results I did with your m1u10.  Upload cost is slightly higher, but that's probably because you used a different physics mesh.  Display weight is a bit lower, which is harder to explain.  The download weight of the 3.6 is identical.

I'm quite puzzled as to why 8 materials should cost less across the board (no pun intended) than just 1.  I wonder if it's factoring in the number of faces a to which a material is assigned, or something like that. 

I'm as perplexed as you are as to why ten separate meshes should weigh less than one.  Is it perhaps somehow smart enough to realize that the ten are all identical in size and shape, so it's able to compress the data?  I wonder if it would yield the same results if each of the ten were radically differently from the each other.

(Or maybe the conspiracy theorists are right, and this is all just a diabolical plot to drive people like you and me crazy!)

 

[Ashasekayi Ra]

I just tried your experiment and got more or less the same results. I find these numbers seriously confusing, especially how material assignments affected the results. Could you add the questions from your post to the mesh office hour agenda? I'd really like to know if the LL devs can shed some light on the numbers.

[Drongle McMahon]

Yes. If they don't respond here, I could do that. I have a few more experiments to do first though.

[Ashasekayi Ra]

Thanks much

[LindaB Helendale]

Drongle McMahon wrote:

 But why is ten separate plank meshes less display weight than ten planks in one mesh?

---

I think the download wt 0.6 is for one prim only, the linkset costs more (in my tests at least).

I made similar planks as you guys, 16 x 0.5 x 0.1 with 0.1 m gaps, and 5 faces (so you can put 5 textures on them, in the test 2 planks sharing the same texture), thus  80 vertices x 120 triangles, and the download weight was 1.23. As all the LODs were the same as the high LOD, the PE also stays the same 1 for any size. 

 

[Drongle McMahon]

"I think the download wt 0.6 is for one prim only, the linkset costs more (in my tests at least)."

I don't think so. When I unlinked them, the individual planks had download weights of 0.1 (rounded). The linkset downloadweight was 0.6. So that is much more than a single plank. Presumably the individual plank is 0.06 which gets rounded to 0.1 because the More Info display only uses one decimal place.

[Drongle McMahon]

OK. I did my last experiment. The Blender 2.49 Collada exporter is rather inefficient in terms of collada file sizes. In this case, the bottomless planks only have five distinct normals between them, but there are 50 in the list in the collada file. There are ten identical normals for each distinct one, presumably from the ten planks. So I wondered iof this kind of inefficiency in the input could be affecting the upload data size. I edited the Copllada file for m1u10 so that there was no repetition of identical normals or UV coordinates in these lists in the collada file. It made absolutely no difference. So that cannot account for the unexpected observations.

[LindaB Helendale]

The mysterious part in the PE/LI download cost is the size of the mesh in bytes on each LOD, as all the other parts of the LI equations

http://wiki.secondlife.com/wiki/Mesh/Mesh_Streaming_Cost are known. Pity the uploader won't tell the byte sizes, it would help optimizing the mesh, and it would be in the interest of LL too. 

There's an almost handy way to get the byte size, though. The LI is calculated  as weighted average of 'number of triangles', weighted by the realtive area where the LOD is visible. If you set the same mesh for all the LODs, the sum over area term vanishes, and the LI won't depend on the size any more. Then the equation simplifies to

  LI = triangles / MeshTriangleBudget * 15000

and the triangles (which is funny variable name in the equations, as it is not the number of triangles but something like equivalent triangles if all bytes were used for triangles) is

 triangles = (bytes-MeshMetaDataDiscount)/MeshBytesPerTriangle

Thus the number of bytes is

  bytes = LI  * MeshTriangleBudget / 15000 * MeshBytesPerTriangle + MeshMetaDataDiscount

The parameters can be found in the viewer debug settings

MeshBytesPerTriangle=16;         
MeshMetaDataDiscount=384;
MeshTriangleBudget=250000;
MeshMinimumByteSize=16;

and with these  values

  bytes = 267 * LI + 384

 

The  MeshBytesPerTriangle value looks odd, 16 bytes per triangle... maybe it's some average, with 3 vertex indices 2 bytes each and 0.833 non-shared vertices per triangle 3*4 bytes each would give 16 bytes / triangle... no idea, but it does not affect much in seeing the overhead / compression of the meshes.

 

----- rather useless experiment on the LOD byte sizes --------------------------------------------------------------------------

I made some more tests on the byte sizes, by recording the LI as function of the size,  and then finding byte values for all LODs to match the calculated and observed LI's. As an example, a sphere with LODs (sorry i dont know how to make tables in this forum editor )

LOD triangles vertices
hi 10000 5390 
    2500 1255 
     624 314
lo   312 158

 

I had 13 sizes from 1 to 64 m and 4 LOD byte values to match so it's well defined parameter fitting task.The resulting byte values, compared to 'non-compressed values' where each triangle would count for  MeshBytesPerTriangle bytes:

 LOD non-compressed fitted to LI   triangles  triangles used in LI equation
     bytes          bytes 

 hi  160384         99803          10000      6214
      40384         23780           2500      1462
      10368          6292            624       369
 low   5376          3212            312       177

All the vertices in the mesh were unique, so the compression of the byte sizes in this mesh are not due to removing duplicates.

 

 

  

[Kwakkelde Kwak]

According to the streaming cost page the viewer will calculate with the radius as a base for LOD distances.... I am very curious how the radius of a box is measured... I'm having some terrible results with very narrow objects (especially trusses in my case where LOD medium is already shown as close as the objects length, but also columns) and good results with objects which are more cube like (cars or sitting avatars)

Does the viewer take an average of the x, y and z dimensions? or is there a more complicted formula used? faking the width of the truss by adding some data costs very few "land impact", but makes the LOD distances much much bigger.

The workaround does the trick for me, but it feels like cheating or fooling the system....

[Drongle McMahon]

The radius is the distance from the center of the bounding box to one of its corners. If the dimensions in the edit dialog are x, y, z, then the radius = sqrt(x*x + y*y + z*z)/2. For a cube, that is 0.866 times the edge length, for a flat square, 0.707 times the edge, and for a thin rod, 0.5 times the length. You can minimise the radius by ensuring the mesh is aligned with its longest span along one axis etc., since the uploader does not rotate it to find the smallest bounding box.

[Kwakkelde Kwak]

Thanks for that Drongle, but I am pretty sure in that case the wiki page is not how it works since the algorithm change.... I don't understand btw how changing the orientation makes a difference if the viewer measures from the center to a corner, all corners are equally far away from it. (I get it now:))

The object I am having the biggest issues with is a truss 24 meters long, 4 meters high and .5 meters thick. LOD high breaks at 27 or so meters. In versions before 3.1 that was more like 100 meters (which is also not quite right in my opinion), other objects behave pretty much the same as they did before the change, some even slightly better. The car I am working on hasn't got as big a radius as the truss (not even close), still LOD high pops to medium much much later (further).

 

Edit - I messed up the orientation of the truss btw, 24 meters is the z axis..I'll look at it when i can, maybe that has got something to do with it, although it wouldn't surprise me they now use the actual volume of the bounding box, or at least take it into the equasion. The truss is 24 x 4 x .5 = 48 cubic m, the car is something like 10 x 6 x 3 = 180 cubic m (it's a truck...)

[Drongle McMahon]

I did look again in the latest viewer with a few objects when you first mentioned this. I didn't find anything different from the expected LOD switch points. Your dimensions should give the first switch at 51.75m*renderVolumeLODFactor from the object center. So 27 is about half of that. Two immediate possibilities are (1) what is renderVolumeLODFactor (lookup in Advanced->Show debug settings) with the graphics settings you have in the new viewer ? The defaults were changed. It could be 0.5. (2) IOs your truss all one mesh pbject? If it's divided in two parts along the long dimension, it would switch at half the distance. Components of a linkset each switch independently according to their own radii. Similarly, any small parts that are linked and not part of the same mesh would switch at a closer distance. Could it be either of those effects?

[LindaB Helendale]

---

Kwakkelde Kwak wrote:

 

Edit - I messed up the orientation of the truss btw, 24 meters is the z axis..I'll look at it when i can, maybe that has got something to do with it, although it wouldn't surprise me they now use the actual volume of the bounding box, or at least take it into the equasion. The truss is 24 x 4 x .5 = 48 cubic m, the car is something like 10 x 6 x 3 = 180 cubic m (it's a truck...)

---

The download cost / streaming cost component of PE/LI (Lindens are not good in choosing terms they use ) is based on the area of a circle with radius equal to half the bounding box diagonal. If it were volume high LODs would be even much much more expensive than now.  The cost tries to estimate the mount of bytes transferred to the viewers, and they assume most objects are on a flat surface.  

Follow-up to my previous experiment:

If you fit the byte sizes of the LODS, the equations http://wiki.secondlife.com/wiki/Mesh/Mesh_Streaming_Cost  match the actual download costs to 4 decimals (in my case 13 cost values, with 4 byte sizes to estimate so it's not just overfittig quirk), but the resulting byte values are not even multiple of 4 or 2, and in my  experiment the matching result was the only byte value set that matches the observed values to 3 decimals, so if the uploader shows the download cost correctly to 3 decimals and if the equations at the wiki page are correct, there seems to be some non-trivial compression in storing the meshes.

 

Btw, the download cost is based on default renderVolumeLODfactor, and increasing the LODfactor uses higher LODs on longer  distance than the resource estimate thinks without matching the cost to the resource usage.... and we know most people have set the LODfactor to 4 to see sculpties that mostly have poor LOD performance, so basically there's a potentially large difference in the calculated LI of meshes and the actual land impact. If the designers will take advantage of people using higher than default LODfactor , and reduce the high LODS even more (since they affect the LI but wont be used by the viewers) I think LL may have to do something about the formulae. 

 

 

 

[Kwakkelde Kwak]

No the RenderVolume is at 2.000 in all cases, I always check before I start building. Object detail always slided to the far right.

It is one object no doubt.

The Lindens did change the algorithm, it was mentioned in the release notes of V3.1.0 and a Linden also said they changed it in august, so he thought it was very possible that those changes were first included in the V3.1.0. As I said earlier, LOD med wouldn't pop until 100 meters or so, now 27. Both are rediculous if you ask me.

 

EDIT ... I uploaded the truss again with the correct rotation (and the old one again to make sure it wasn't a bugged model I used), it now works. With the y axis now being very long and the z not.. it could be very possible the uploader counts x and y far heavier than z for LOD. Turns out the volume I suspected isn't causing it anyway... I think I will be rotating my columns onto their sides from now on hehe.

[Kwakkelde Kwak]

---

LindaB Helendale wrote:

The download cost / streaming cost component of PE/LI (Lindens are not good in choosing terms they use

) is based on the area of a circle with radius equal to half the bounding box diagonal.

 

---

This doesn't at all explain why the truss which is narrow yet long, pops to LOD medium at a much shorter distance than the truck which is wide and short.

EDIT ... I uploaded the truss again with the correct rotation (and the old one again to make sure it wasn't a bugged model I used), it now works. With the y axis now being very long and the z not.. it could be very possible the uploader counts x and y far heavier than z for LOD. The strange thing is however the landimpact is still the same, so this isn't related to LOD in a very direct way. Strange..strange, I'm happy it works now though, I wasn't going to make 22 prim equivalent trusses...

[LindaB Helendale]

 

I repeated that test,  I made two meshes, with dimensions

24.0000 4.0000 0.5000
10.0000 6.0000 3.0000

and versions with dimensions flipped

0.5000 4.0000 24.0000
3.0000 6.0000 10.0000

and the first one, long thingy, changed from high LOD to mid around  51-53 m and the other one at around 25 m as expected  on both dimension permutation. The theoretical LOD change distances would be 50.7m and 25.1 m, but since the LOD change has hysteresis and delays it's difficult to measure exactly.

Also the LI was independent of the directions (18  & 9.1) , so it seems the dimensions are not handled diffrently... otherwise it would be pretty odd since for the visible triangle cost the actual rotation with respect to the viewer is wat counts.

 

[Kwakkelde Kwak]

Thanks for looking into this, although I suspect You're more curious than helpful hehe...

Very strange you can't replicate it, I could send you the models if you want to have a look, either inworld or the DAEs. It's especially strange since the same thing happened with columns, meaning it isn't just this particular object.

 

Here are the numbers on my three items:

truss 0.600 x 24.000 x 4.109: LOD high to med at 24 m, LOD med to high at 25 m

truss 0.600 x 4.109 x 24.000: LOD high to med at 117 m, LOD med to high at 157 m

truck 3.317 x 4.632 x 10.247: LOD high to med at 46 m, LOD med to high at 61 m

Object detail maxed out, RenderVolume at 2.00,

Second Life 3.2.0 (243986) Oct 27 2011 14:02:26 (Second Life Beta Viewer)

And:

truss 0.600 x 24.000 x 4.109: LOD high to med at 90 m, LOD med to high at 144m

truss 0.600 x 4.109 x 24.000: LOD high to med at 90 m, LOD med to high at 144 m

truck 3.317 x 4.632 x 10.247: LOD high to med at 53 m, LOD med to high at 68 m

Object detail maxed out, RenderVolume at 2.00,

Second Life 2.8.4 (0) Aug  6 2011 09:54:37 (RestrainedLove viewer v2.07.03.02 (2.8.0.20010))

(These last are the same results I got with V3.0.0)

[Drongle McMahon]

"The Lindens did change the algorithm, it was mentioned in the release notes of V3.1.0 and Charlar also said they changed it in august, so he thought it was very possible that those changes were first included in the V3.1.0. As I said earlier, LOD med wouldn't pop until 100 meters or so, now 27. Both are rediculous if you ask me."

I can't find that in these release notes. Can you give some more accurate pointers? I can't find a change in the places I know of in the source either, but I don't know all the possible places.

Anyway, I installed the same viewer version that you used and tried uploading simple boxes with your dimensions of 0.6, 4.109, 24.0 in all six possible combinations with the axes. They all switched from high to medium at the same distances, retreating or approaching. The distsnces were (rendeVolumeLODFactor: retreating/approaching)...  0.5: 31/28 ; 1.0: 68/56 ; 1.5: 108/79 ; 2.0: 173/127. 

The radius is 12.178, which means the approach switches are not too far off the expected values*, but the retreating ones are larger. However, I see no sign of the axis-dependent effect you reported. Did you try this with a new upload of the old truss?

------------------------------------------------------------------------------------------------------------------------------------------------------------

* this is from the following strange function switch_distance = radius*f*30 / 0.24*pi*(10-f), where f is renderVolumeLODFactor. It gives 26, 54, 88 and 121 as the switch distances for rvlf= 0.5, 1.0, 1.5, 2.0 for these objects. This compares with 25, 51, 76, and 101 for the simple radius/0.24.

this is derived from the following initialisation code in llapviewer.cpp...

LLVOVolume::sLODFactor       = gSavedSettings.getF32("RenderVolumeLODFactor");
LLVOVolume::sDistanceFactor  = 1.f - LLVOVolume::sLODFactor * 0.1f;

(and the update handler for renderVolumeLODFactor) and the following in LLVOVolume::calcLOD, which modifies the distance before it is fed to the simple function computeLODDetail.

    distance *= sDistanceFactor;
    distance *= F_PI/3.f;

Please don't ask me why these are there! I have no idea. Also, that is a simplification - there is more that changes it again when you are "very close" to the object.

However, I can't really believe this is right because the dostance would become infinite for rvlf=10, and negative if it was larger. There is certainly something I have missed here.