LindaB Helendale
-
Posts
69 -
Joined
-
Last visited
Content Type
Forums
Blogs
Knowledge Base
Posts posted by LindaB Helendale
-
-
I repeated that test, I made two meshes, with dimensions
24.0000 4.0000 0.5000
10.0000 6.0000 3.0000and versions with dimensions flipped
0.5000 4.0000 24.0000
3.0000 6.0000 10.0000and 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 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.
-
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 toLI = triangles / MeshTriangleBudget * 15000and 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) istriangles = (bytes-MeshMetaDataDiscount)/MeshBytesPerTriangleThus the number of bytes isbytes = LI * MeshTriangleBudget / 15000 * MeshBytesPerTriangle + MeshMetaDataDiscountThe parameters can be found in the viewer debug settingsMeshBytesPerTriangle=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 158I 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 byteshi 160384 99803 10000 6214
40384 23780 2500 1462
10368 6292 624 369
low 5376 3212 312 177All the vertices in the mesh were unique, so the compression of the byte sizes in this mesh are not due to removing duplicates.
-
1
-
-
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.
-
I have a (strange) question about materials too.. currently the material definitions in the collada file don't matter, but the faces are defined in the <geometry> block: every <triangles> and <polylist> element produces a face, which is very handy for directly writing collada files, but I havnt found any documentation of this... would anyone know is this frozen design, or a side effect of how some tools like blender implement materials in the collada, and is there a risk that this will change in future?
-
Oh, I thought the LOD mixup problem was collada uploader issue, but from the thread it seems it's Blender issue. I have uploaded linksets of 65 parts, with all LODS and physics and i havnt observed any LOD mixups, but i make the collada files directly, with complete control over the order of the <geometry> elements.
I have other issues with the uploader though, with arbitrary root and link order, whined about in this thread
hmmm.. i can't get the link work.. in this thread
http://community.secondlife.com/t5/Mesh/Mesh-linkset-root-part-names-and-part-order/td-p/1173915
-
Luc Starsider wrote:Drongle McMahon wrote:You mean for uploading multiple objects? Each object has to have its own physics shape
Is that possible? How do you specify physics shapes for the individual objects in a multi object upload?Exactly the same way you specify the LOD levels for multiple meshes. I dont know how it's done in Blender but in the collada file they must be specified as separate <geometry> blocks.
-
Drongle McMahon wrote:You can also upload several objects at the same time. They will appear as a linkset after upload, with their relative positions conserved. However, you may find problems with getting the right LOD meshes for the cright objects, and there can be problems if you use autoLOD and some objects get decimated away. Also I have no idea what happens if the objects are too many or too big to be a linkset.
The meshes that are too far to be linked or too many are just left unlinked, so you get a coalesced object with one linkset and the rest separate.
However, the root object may be any mesh in the linkset. and only the root name is preserved, all others are 'Object', so bigger linksets require a lot manual work after uploading.
Edit: about the wrong LOD meshes.. i havnt confirmed this with any tests yet but i suspect the mesh uploader sorts the meshes in the linkset by some bounding box dimension (and that's why the linkset is not in the same order as your collada objects and the root may be any of the meshes) and if the sorting is done independently for each LOD, it may lead to different ordering and wrong associations. This needs experimental confirmation.
-
I can't find any decent (or even indecent) documentation of making multiprim meshes, but apparently every <geometry>...</geometry> block in the collada file produces a link to the mesh linkset. The name of the root prim comes from the ID attribute
<geometry id="myPrim">
When i have several geometries, only the root prim has the correct name, and all the others are 'Object'. I tested setting the names by the NAME attribute in <geometry> but as expected, it had no effect.
Would anyone have managed to upload a linkset with link names correctly set?
I would very much want to see how the names are defined in the collada file.Another problem with linksets: often the root will be the first <geometry> defined in the collada file, but as often the root is any random geometry. Also the order of the parts in the linkset is more or less random compared to the order in the collada file. I have the instances of the geometries in the <visual_scene id="Scene" name="Scene"> -block defined in the same order as they are in the <library_geometries> -block, in case it would matter.
I would either need to get the names of the linked parts right, or having the parts in the same order in the linkset as they are in the collda-file, to load several small parts as one upload, requiring only setting the LOD files once for the whole set. As a workaround I add offset to each part in the collada file and in-world use a script to sort the parts by the offset and rename but it feels really pathetic kludge :(
Any help or pointers would be much appreciated.
) 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. 
)
Facebook
Instagram
Twitter
YouTube
Flickr
Prims Land Impact Whatever
in Mesh
Posted
Thanks for the dae files Kwakkelde, i got the same result as you, both uploding the dae files, and also reading them in matlab and stripping the polygons out and loading as collada, the LOD changes points were very different.
The face lists in both meshes are identical, but in rotating the other mesh upright some of the polygons have flipped the direction, as if the vertices have been flipped along the long axis, reversing the surface orientation, and there's something wrong with the normals and/or inner/outer surfaces.
I dont have time to see it in more detail, but if i flip the long dimension in the test2 (test2.vertices(:,3)=-test2.vertices(:,3) ) and save as .dae, it behaves like the other one.