forget it closed topic, go away

[OptimoMaximo]

4 minutes ago, ChinRey said:

We may misunderstand each other here.

I was phrasing it incorrectly i guess, my previous post addresses the method. I'm not saying it's taking all from your cache to make the conversion, it's taking the data from SL and the mesh construction is left outside, using the same meshes you would have had in your cache.

[OptimoMaximo]

13 minutes ago, ChinRey said:

It does work with dae file though - at least to some degree. One of the immediately noticeable differences between between a dae file generated by Mesh Studio and one generated by Blender, is that <library_materials> and <library_effects> elements are swapped. Mesh Studio lists the materials before the effects, Blender does it the other way round.

It's this type of fragmentation that is granted by Collada's format definition, to me causes the different LI: the uploader has to do the conversion and accepts all data it can convert in any order. It's when the object needs to be read back, that the differences between the fed parsing order and the native one can make a difference. If the description of the object is very messy, it may take longer to retrieve all necessary data in the necessary order for the viewer. Therefore a higher computational load and, consequently, a higher rendering cost.

Edited January 8, 2018 by OptimoMaximo
replaced L with rendering cost at the end

[ChinRey]

2 minutes ago, OptimoMaximo said:

It's this type of fragmentation that is granted by Collada's format definition, to me causes the different LI:

Yes, I suppose any apparent disagreement between us there was more about the choice of word than actual facts.

Except possibly for one detail: The download weight (and the land impact system as a whole) does not in any way take client side load into account. Download weight is all about the bandwidth required and the other two weights are all about server side load. The difference in download weight and land impact has to be caused by different file sizes, not different workload for the viewer.

 

Just now, OptimoMaximo said:

I was phrasing it incorrectly i guess, my previous post addresses the method. I'm not saying it's taking all from your cache to make the conversion, it's taking the data from SL and the mesh construction is left outside, using the same meshes you would have had in your cache.

Not exactly actually. I know TheBlack Box made his own formulas for how the various prim transformations affect the object's shape without referring to the SL software at all. It caused a bit of a problem at first since he got one of the formulas wrong (that was corrected long ago fortunately). The creator of Mesh Generator must have developed her own formulas too since she also got at least one primt wist wrong.

[OptimoMaximo]

6 minutes ago, ChinRey said:

The difference in download weight and land impact has to be caused by different file sizes, not different workload for the viewer.

a big file size is almost always cause of higher load. And now it's just a speculation i'm doing, but what comes to mind now is:

(Speculation ahead, i don't really know these details)

What if the encoded model can accept data types in, say like partitions, and the messier the order is, the bigger the file becomes to allow both a free order on the Collada file and still maintain a strict encoding order in their internal binary format? Missing chunks might be added later in a separate partition when the next related chunk is found, leading to a fragmentation. This fragmentation, when it comes to binary data dump, MUST be of fixed byte size, and if this chunk of file doesn't fill it all, the remainder is empty, but still there. Next chunk found and a new partition opens. Same if the chunk exceeds the partition size and the remainder is continued in the partition right after it, but just for a few lines, then again the remaining space contains zeroes. That's another reason for me to think of a specific parsing order being the most optimal rather than a random one.

[OptimoMaximo]

26 minutes ago, ChinRey said:

42 minutes ago, OptimoMaximo said:

I was phrasing it incorrectly i guess, my previous post addresses the method. I'm not saying it's taking all from your cache to make the conversion, it's taking the data from SL and the mesh construction is left outside, using the same meshes you would have had in your cache.

Not exactly actually.........

Ok, improvements to the base mesh confirm they have it on their servers, where they expanded the base library.

[ChinRey]

52 minutes ago, OptimoMaximo said:

What if the encoded model can accept data types in, say like partitions, and the messier the order is, the bigger the file becomes to allow both a free order on the Collada file and still maintain a strict encoding order in their internal binary format?

That's an intriguing idea. I assumed it was about the compression ratio the files could achieve but you may well be right. I tried the two most obvious differences in order (swapping the <library_materials> and <library_effects> elements and the normal and vertex arrays) but those changes didn't have any effect. I can't test all possible permutations but if the message board allows it, here are the three eight cube dae files in case somebody else want to give it a go:

<?xml version="1.0" encoding="utf-8"?>
<COLLADA xmlns="http://www.collada.org/2005/11/COLLADASchema" version="1.4.0">
  <asset>
    <contributor>
      <author></author>
      <authoring_tool>Mesh Studio</authoring_tool>
      <comments></comments>
    </contributor>
    <created>2018-01-08T16:22:46Z</created>
    <modified>2018-01-08T16:22:46Z</modified>
    <revision></revision>
    <title></title>
    <unit meter="1.000000"/>
    <up_axis>Y_UP</up_axis>
  </asset>
  <library_images>
        <image id="file2" name="file2">
            <init_from>default.jpg</init_from>
        </image>
  </library_images>
  <library_materials>
        <material id="blinn3" name="blinn3">
            <instance_effect url="#blinn3-fx"/>
        </material>
        <material id="blinn3m1" name="blinn3m1">
            <instance_effect url="#blinn3-fx"/>
        </material>
        <material id="blinn3m2" name="blinn3m2">
            <instance_effect url="#blinn3-fx"/>
        </material>
        <material id="blinn3m3" name="blinn3m3">
            <instance_effect url="#blinn3-fx"/>
        </material>
        <material id="blinn3m4" name="blinn3m4">
            <instance_effect url="#blinn3-fx"/>
        </material>
        <material id="blinn3m5" name="blinn3m5">
            <instance_effect url="#blinn3-fx"/>
        </material>
        <material id="blinn3m6" name="blinn3m6">
            <instance_effect url="#blinn3-fx"/>
        </material>
        <material id="blinn3m7" name="blinn3m7">
            <instance_effect url="#blinn3-fx"/>
        </material>
        <material id="blinn3m8" name="blinn3m8">
            <instance_effect url="#blinn3-fx"/>
        </material>
        <material id="blinn3m9" name="blinn3m9">
            <instance_effect url="#blinn3-fx"/>
        </material>
        <material id="blinn3m10" name="blinn3m10">
            <instance_effect url="#blinn3-fx"/>
        </material>
        <material id="blinn3m11" name="blinn3m11">
            <instance_effect url="#blinn3-fx"/>
        </material>
        <material id="blinn3m12" name="blinn3m12">
            <instance_effect url="#blinn3-fx"/>
        </material>
        <material id="blinn3m13" name="blinn3m13">
            <instance_effect url="#blinn3-fx"/>
        </material>
        <material id="blinn3m14" name="blinn3m14">
            <instance_effect url="#blinn3-fx"/>
        </material>
        <material id="blinn3m15" name="blinn3m15">
            <instance_effect url="#blinn3-fx"/>
        </material>
        <material id="blinn3m16" name="blinn3m16">
            <instance_effect url="#blinn3-fx"/>
        </material>
        <material id="blinn3m17" name="blinn3m17">
            <instance_effect url="#blinn3-fx"/>
        </material>
        <material id="blinn3m18" name="blinn3m18">
            <instance_effect url="#blinn3-fx"/>
        </material>
        <material id="blinn3m19" name="blinn3m19">
            <instance_effect url="#blinn3-fx"/>
        </material>
  </library_materials>
  <library_effects>
        <effect id="blinn3-fx">
            <profile_COMMON>
                <newparam sid="file2-surface">
                    <surface type="2D">
                        <init_from>file2</init_from>
                        <format>A8R8G8B8</format>
                    </surface>
                </newparam>
                <newparam sid="file2-sampler">
                    <sampler2D>
                        <source>file2-surface</source>
                        <minfilter>LINEAR_MIPMAP_LINEAR</minfilter>
                        <magfilter>LINEAR</magfilter>
                    </sampler2D>
                </newparam>
                <technique sid="common">
                    <blinn>
                        <emission>
                            <color>0 0 0 1 </color>
                        </emission>
                        <ambient>
                            <color>0 0 0 1 </color>
                        </ambient>
                        <diffuse>
                            <texture texture="file2-sampler" texcoord="UVSET0"/>
                        </diffuse>
                        <specular>
                            <color>0 0 0 1 </color>
                        </specular>
                        <shininess>
                            <float>0.3</float>
                        </shininess>
                        <reflective>
                            <color>0 0 0 1 </color>
                        </reflective>
                        <reflectivity>
                            <float>0.5</float>
                        </reflectivity>
                        <transparent>
                            <color>0 0 0 1 </color>
                        </transparent>
                        <transparency>
                            <float>0</float>
                        </transparency>
                        <index_of_refraction>
                            <float>0</float>
                        </index_of_refraction>
                    </blinn>
                </technique>
            </profile_COMMON>
        </effect>
  </library_effects>
  <library_geometries>
    <geometry id="o2jm1lib" name="o2jm1Mesh">
      <mesh>
        <source id="o2jm1libPos" name="position">
          <float_array id="o2jm1libPosa" count="195">-0.336249 -0.109254 0.250000 0.336249 0.109254 0.250000 -0.109254 0.336249 0.250000 0.109254 -0.336249 0.250000 -0.336249 -0.109254 -0.250000 0.109254 -0.336249 -0.250000 0.336249 0.109254 -0.250000 -0.109254 0.336249 -0.250000 -0.336245 -0.191586 0.983639 0.336245 0.012404 1.061944 -0.109252 0.224320 1.143291 0.109251 -0.403502 0.902292 -0.336245 -0.012404 0.516856 0.109252 -0.224320 0.435509 0.336245 0.191586 0.595161 -0.109251 0.403502 0.676508 -1.590290 -0.250000 0.250000 -1.090290 0.250000 0.250000 -1.590290 0.250000 0.250000 -1.090290 -0.250000 0.250000 -1.590290 -0.250000 -0.250000 -1.090290 -0.250000 -0.250000 -1.090290 0.250000 -0.250000 -1.590290 0.250000 -0.250000 -1.590288 -0.322984 0.933201 -1.090292 0.143801 1.112384 -1.590288 0.143801 1.112384 -1.090292 -0.322984 0.933201 -1.590288 -0.143801 0.466416 -1.090292 -0.143801 0.466416 -1.090292 0.322984 0.645599 -1.590288 0.322984 0.645599 -0.308757 1.326447 0.368405 0.126477 1.855858 0.542447 -0.354109 1.822766 0.408507 0.171829 1.359539 0.502344 -0.178457 1.377142 -0.111647 0.302129 1.410234 0.022293 0.256777 1.906553 0.062395 -0.223809 1.873461 -0.071544 -1.258311 0.567150 0.030489 -1.109288 1.249156 0.142960 -1.516901 0.994347 0.005414 -0.850698 0.821958 0.168036 -1.128012 0.617844 -0.449560 -0.720399 0.872653 -0.312014 -0.978989 1.299850 -0.337089 -1.386602 1.045042 -0.474636 -1.398600 0.435556 0.690090 -1.279095 1.071022 0.976262 -1.686710 0.816213 0.838715 -0.990985 0.690365 0.827637 -1.369625 0.635978 0.232938 -0.962010 0.890787 0.370485 -1.250120 1.271444 0.519110 -1.657735 1.016635 0.381563 -0.457352 1.181756 1.076899 -0.035022 1.690822 1.326850 -0.529006 1.636602 1.271769 0.036631 1.235976 1.131979 -0.428378 1.382178 0.619750 0.065606 1.436398 0.674831 -0.006048 1.891244 0.869701 -0.500031 1.837024 0.814621 -0.428378 1.382178 0.619750 </float_array>
          <technique_common>
            <accessor source="#o2jm1libPosa" count="65" stride="3">
              <param name="X" type="float"/>
              <param name="Y" type="float"/>
              <param name="Z" type="float"/>
            </accessor>
          </technique_common>
        </source>
        <source id="o2jm1libUV0" name="map1">
          <float_array id="o2jm1libUV0a" count="576">0.000000 0.000000 1.000000 1.000000 0.000000 1.000000 0.000000 0.000000 1.000000 0.000000 1.000000 1.000000 0.000000 0.000000 1.000000 1.000000 0.000000 1.000000 0.000000 0.000000 1.000000 0.000000 1.000000 1.000000 0.000000 0.000000 1.000000 1.000000 0.000000 1.000000 0.000000 0.000000 1.000000 0.000000 1.000000 1.000000 0.000000 0.000000 1.000000 1.000000 0.000000 1.000000 0.000000 0.000000 1.000000 0.000000 1.000000 1.000000 0.000000 0.000000 1.000000 1.000000 0.000000 1.000000 0.000000 0.000000 1.000000 0.000000 1.000000 1.000000 0.000000 0.000000 0.000000 -1.000000 1.000000 -1.000000 0.000000 0.000000 1.000000 -1.000000 1.000000 0.000000 0.000000 0.000000 1.000000 1.000000 0.000000 1.000000 0.000000 0.000000 1.000000 0.000000 1.000000 1.000000 0.000000 0.000000 1.000000 1.000000 0.000000 1.000000 0.000000 0.000000 1.000000 0.000000 1.000000 1.000000 0.000000 0.000000 1.000000 1.000000 0.000000 1.000000 0.000000 0.000000 1.000000 0.000000 1.000000 1.000000 0.000000 0.000000 1.000000 1.000000 0.000000 1.000000 0.000000 0.000000 1.000000 0.000000 1.000000 1.000000 0.000000 0.000000 1.000000 1.000000 0.000000 1.000000 0.000000 0.000000 1.000000 0.000000 1.000000 1.000000 0.000000 0.000000 0.000000 -1.000000 1.000000 -1.000000 0.000000 0.000000 1.000000 -1.000000 1.000000 0.000000 0.000000 0.000000 1.000000 1.000000 0.000000 1.000000 0.000000 0.000000 1.000000 0.000000 1.000000 1.000000 0.000000 0.000000 1.000000 1.000000 0.000000 1.000000 0.000000 0.000000 1.000000 0.000000 1.000000 1.000000 0.000000 0.000000 1.000000 1.000000 0.000000 1.000000 0.000000 0.000000 1.000000 0.000000 1.000000 1.000000 0.000000 0.000000 1.000000 1.000000 0.000000 1.000000 0.000000 0.000000 1.000000 0.000000 1.000000 1.000000 0.000000 0.000000 1.000000 1.000000 0.000000 1.000000 0.000000 0.000000 1.000000 0.000000 1.000000 1.000000 0.000000 0.000000 0.000000 -1.000000 1.000000 -1.000000 0.000000 0.000000 1.000000 -1.000000 1.000000 0.000000 0.000000 0.000000 1.000000 1.000000 0.000000 1.000000 0.000000 0.000000 1.000000 0.000000 1.000000 1.000000 0.000000 0.000000 1.000000 1.000000 0.000000 1.000000 0.000000 0.000000 1.000000 0.000000 1.000000 1.000000 0.000000 0.000000 1.000000 1.000000 0.000000 1.000000 0.000000 0.000000 1.000000 0.000000 1.000000 1.000000 0.000000 0.000000 1.000000 1.000000 0.000000 1.000000 0.000000 0.000000 1.000000 0.000000 1.000000 1.000000 0.000000 0.000000 1.000000 1.000000 0.000000 1.000000 0.000000 0.000000 1.000000 0.000000 1.000000 1.000000 0.000000 0.000000 0.000000 -1.000000 1.000000 -1.000000 0.000000 0.000000 1.000000 -1.000000 1.000000 0.000000 0.000000 0.000000 1.000000 1.000000 0.000000 1.000000 0.000000 0.000000 1.000000 0.000000 1.000000 1.000000 0.000000 0.000000 1.000000 1.000000 0.000000 1.000000 0.000000 0.000000 1.000000 0.000000 1.000000 1.000000 0.000000 0.000000 1.000000 1.000000 0.000000 1.000000 0.000000 0.000000 1.000000 0.000000 1.000000 1.000000 0.000000 0.000000 1.000000 1.000000 0.000000 1.000000 0.000000 0.000000 1.000000 0.000000 1.000000 1.000000 0.000000 0.000000 1.000000 1.000000 0.000000 1.000000 0.000000 0.000000 1.000000 0.000000 1.000000 1.000000 0.000000 0.000000 0.000000 -1.000000 1.000000 -1.000000 0.000000 0.000000 1.000000 -1.000000 1.000000 0.000000 0.000000 0.000000 1.000000 1.000000 0.000000 1.000000 0.000000 0.000000 1.000000 0.000000 1.000000 1.000000 0.000000 0.000000 1.000000 1.000000 0.000000 1.000000 0.000000 0.000000 1.000000 0.000000 1.000000 1.000000 0.000000 0.000000 1.000000 1.000000 0.000000 1.000000 0.000000 0.000000 1.000000 0.000000 1.000000 1.000000 0.000000 0.000000 1.000000 1.000000 0.000000 1.000000 0.000000 0.000000 1.000000 0.000000 1.000000 1.000000 0.000000 0.000000 1.000000 1.000000 0.000000 1.000000 0.000000 0.000000 1.000000 0.000000 1.000000 1.000000 0.000000 0.000000 0.000000 -1.000000 1.000000 -1.000000 0.000000 0.000000 1.000000 -1.000000 1.000000 0.000000 0.000000 0.000000 1.000000 1.000000 0.000000 1.000000 0.000000 0.000000 1.000000 0.000000 1.000000 1.000000 0.000000 0.000000 1.000000 1.000000 0.000000 1.000000 0.000000 0.000000 1.000000 0.000000 1.000000 1.000000 0.000000 0.000000 1.000000 1.000000 0.000000 1.000000 0.000000 0.000000 1.000000 0.000000 1.000000 1.000000 0.000000 0.000000 1.000000 1.000000 0.000000 1.000000 0.000000 0.000000 1.000000 0.000000 1.000000 1.000000 0.000000 0.000000 1.000000 1.000000 0.000000 1.000000 0.000000 0.000000 1.000000 0.000000 1.000000 1.000000 0.000000 0.000000 0.000000 -1.000000 1.000000 -1.000000 0.000000 0.000000 1.000000 -1.000000 1.000000 0.000000 0.000000 0.000000 1.000000 1.000000 0.000000 1.000000 0.000000 0.000000 1.000000 0.000000 1.000000 1.000000 0.000000 0.000000 1.000000 1.000000 0.000000 1.000000 0.000000 0.000000 1.000000 0.000000 1.000000 1.000000 0.000000 0.000000 1.000000 1.000000 0.000000 1.000000 0.000000 0.000000 1.000000 0.000000 1.000000 1.000000 0.000000 0.000000 1.000000 1.000000 0.000000 1.000000 0.000000 0.000000 1.000000 0.000000 1.000000 1.000000 0.000000 0.000000 1.000000 1.000000 0.000000 1.000000 0.000000 0.000000 1.000000 0.000000 1.000000 1.000000 0.000000 0.000000 0.000000 -1.000000 1.000000 -1.000000 0.000000 0.000000 1.000000 -1.000000 1.000000 0.000000 </float_array>
          <technique_common>
            <accessor source="#o2jm1libUV0a" count="288" stride="2">
              <param name="S" type="float"/>
              <param name="T" type="float"/>
            </accessor>
          </technique_common>
        </source>
        <source id="o2jm1libNorm" name="normal">
          <float_array id="o2jm1libNorma" count="147">0.000000 0.000000 1.000000 -0.453990 -0.891007 0.000000 0.891007 -0.453990 0.000000 0.453990 0.891007 0.000000 -0.891007 0.453990 0.000000 0.000000 0.000000 -1.000000 -0.000000 -0.358370 0.933580 -0.000000 -0.358370 0.933580 -0.000000 -0.358370 0.933580 -0.453993 -0.831824 -0.319310 0.891005 -0.423839 -0.162697 0.453993 0.831824 0.319310 -0.891005 0.423839 0.162697 0.000000 0.358370 -0.933580 0.000000 0.358370 -0.933580 0.000000 0.358370 -0.933580 0.000000 0.358370 -0.933580 0.000000 -1.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 -1.000000 0.000000 0.000000 0.000000 -0.358370 0.933579 0.000000 -0.933579 -0.358370 0.000000 0.933579 0.358370 0.000000 0.358370 -0.933579 -0.260601 -0.101389 0.960108 0.090704 -0.992643 -0.080205 0.961176 0.066184 0.267880 -0.090704 0.992643 0.080205 -0.961176 -0.066184 -0.267880 0.260601 0.101389 -0.960108 -0.260601 -0.101390 0.960108 0.517184 -0.854403 0.050151 0.815235 0.509622 0.275095 -0.517184 0.854403 -0.050151 -0.815235 -0.509622 -0.275095 0.260601 0.101390 -0.960108 -0.057949 -0.400846 0.914311 0.576224 -0.761320 -0.297252 0.815235 0.509622 0.275095 -0.576224 0.761320 0.297252 -0.815235 -0.509622 -0.275095 0.057949 0.400846 -0.914311 -0.057950 -0.400849 0.914309 0.143309 -0.909703 -0.389747 0.987980 0.108443 0.110163 -0.143309 0.909703 0.389747 -0.987980 -0.108443 -0.110163 0.057950 0.400849 -0.914309 </float_array>
          <technique_common>
            <accessor source="#o2jm1libNorma" count="49" stride="3">
              <param name="X" type="float"/>
              <param name="Y" type="float"/>
              <param name="Z" type="float"/>
            </accessor>
          </technique_common>
        </source>
        <vertices id="o2jm1libVert">
          <input semantic="POSITION" source="#o2jm1libPos"/>
        </vertices>
        <triangles count="96" material="blinn3o2jm1m1">
          <input semantic="VERTEX" offset="0" source="#o2jm1libVert"/>
          <input semantic="NORMAL" offset="1" source="#o2jm1libNorm"/>
          <input semantic="TEXCOORD" offset="2" source="#o2jm1libUV0"/>
          <p>0 0 0 1 0 1 2 0 2 0 0 3 3 0 4 1 0 5 4 1 6 3 1 7 0 1 8 4 1 9 5 1 10 3 1 11 5 2 12 1 2 13 3 2 14 5 2 15 6 2 16 1 2 17 6 3 18 2 3 19 1 3 20 6 3 21 7 3 22 2 3 23 7 4 24 0 4 25 2 4 26 7 4 27 4 4 28 0 4 29 4 5 30 7 5 31 6 5 32 4 5 33 6 5 34 5 5 35 8 6 36 9 7 37 10 7 38 8 6 39 11 8 40 9 7 41 12 9 42 11 9 43 8 9 44 12 9 45 13 9 46 11 9 47 13 10 48 9 10 49 11 10 50 13 10 51 14 10 52 9 10 53 14 11 54 10 11 55 9 11 56 14 11 57 15 11 58 10 11 59 15 12 60 8 12 61 10 12 62 15 12 63 12 12 64 8 12 65 12 13 66 15 14 67 14 15 68 12 13 69 14 15 70 13 16 71 16 0 72 17 0 73 18 0 74 16 0 75 19 0 76 17 0 77 20 17 78 19 17 79 16 17 80 20 17 81 21 17 82 19 17 83 21 18 84 17 18 85 19 18 86 21 18 87 22 18 88 17 18 89 22 19 90 18 19 91 17 19 92 22 19 93 23 19 94 18 19 95 23 20 96 16 20 97 18 20 98 23 20 99 20 20 100 16 20 101 20 5 102 23 5 103 22 5 104 20 5 105 22 5 106 21 5 107 24 21 108 25 21 109 26 21 110 24 21 111 27 21 112 25 21 113 28 22 114 27 22 115 24 22 116 28 22 117 29 22 118 27 22 119 29 18 120 25 18 121 27 18 122 29 18 123 30 18 124 25 18 125 30 23 126 26 23 127 25 23 128 30 23 129 31 23 130 26 23 131 31 20 132 24 20 133 26 20 134 31 20 135 28 20 136 24 20 137 28 24 138 31 24 139 30 24 140 28 24 141 30 24 142 29 24 143 32 25 144 33 25 145 34 25 146 32 25 147 35 25 148 33 25 149 36 26 150 35 26 151 32 26 152 36 26 153 37 26 154 35 26 155 37 27 156 33 27 157 35 27 158 37 27 159 38 27 160 33 27 161 38 28 162 34 28 163 33 28 164 38 28 165 39 28 166 34 28 167 39 29 168 32 29 169 34 29 170 39 29 171 36 29 172 32 29 173 36 30 174 39 30 175 38 30 176 36 30 177 38 30 178 37 30 179 40 31 180 41 31 181 42 31 182 40 31 183 43 31 184 41 31 185 44 32 186 43 32 187 40 32 188 44 32 189 45 32 190 43 32 191 45 33 192 41 33 193 43 33 194 45 33 195 46 33 196 41 33 197 46 34 198 42 34 199 41 34 200 46 34 201 47 34 202 42 34 203 47 35 204 40 35 205 42 35 206 47 35 207 44 35 208 40 35 209 44 36 210 47 36 211 46 36 212 44 36 213 46 36 214 45 36 215 48 37 216 49 37 217 50 37 218 48 37 219 51 37 220 49 37 221 52 38 222 51 38 223 48 38 224 52 38 225 53 38 226 51 38 227 53 39 228 49 39 229 51 39 230 53 39 231 54 39 232 49 39 233 54 40 234 50 40 235 49 40 236 54 40 237 55 40 238 50 40 239 55 41 240 48 41 241 50 41 242 55 41 243 52 41 244 48 41 245 52 42 246 55 42 247 54 42 248 52 42 249 54 42 250 53 42 251 56 43 252 57 43 253 58 43 254 56 43 255 59 43 256 57 43 257 60 44 258 59 44 259 56 44 260 60 44 261 61 44 262 59 44 263 61 45 264 57 45 265 59 45 266 61 45 267 62 45 268 57 45 269 62 46 270 58 46 271 57 46 272 62 46 273 63 46 274 58 46 275 63 47 276 56 47 277 58 47 278 63 47 279 64 47 280 56 47 281 60 48 282 63 48 283 62 48 284 60 48 285 62 48 286 61 48 287 </p>
        </triangles>
      </mesh>
    </geometry>
  </library_geometries>
  <library_visual_scenes>
    <visual_scene id="Scene" name="Scene">
      <node id="Root" name="Root">
        <matrix sid="matrix">1.000000 0.000000 0.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 -1.000000 0.000000 0.000000 0.000000 0.000000 0.000000 1.000000</matrix>
          <instance_geometry url="#o2jm1lib">
              <bind_material>
                  <technique_common>
                      <instance_material symbol="blinn3o2jm1m1" target="#blinn3m1">
                          <bind_vertex_input semantic="UVSET0" input_semantic="TEXCOORD" input_set="0"/>
                      </instance_material>
                  </technique_common>
              </bind_material>
          </instance_geometry>
      </node>
    </visual_scene>
  </library_visual_scenes>
  <scene>
    <instance_visual_scene url="#Scene"/>
  </scene>
</COLLADA>

 

<?xml version="1.0" encoding="utf-8"?>
<COLLADA xmlns="http://www.collada.org/2005/11/COLLADASchema" version="1.4.1">
  <asset>
    <contributor>
      <author>Blender User</author>
      <authoring_tool>Blender 2.78.0 commit date:2016-09-26, commit time:12:42, hash:4bb1e22</authoring_tool>
    </contributor>
    <created>2018-01-08T17:23:25</created>
    <modified>2018-01-08T17:23:25</modified>
    <unit name="meter" meter="1"/>
    <up_axis>Z_UP</up_axis>
  </asset>
  <library_images/>
  <library_effects>
    <effect id="blinn3m1-effect">
      <profile_COMMON>
        <technique sid="common">
          <phong>
            <emission>
              <color sid="emission">0 0 0 1</color>
            </emission>
            <ambient>
              <color sid="ambient">0 0 0 1</color>
            </ambient>
            <diffuse>
              <color sid="diffuse">0.64 0.64 0.64 1</color>
            </diffuse>
            <specular>
              <color sid="specular">0.5 0.5 0.5 1</color>
            </specular>
            <shininess>
              <float sid="shininess">50</float>
            </shininess>
            <index_of_refraction>
              <float sid="index_of_refraction">1</float>
            </index_of_refraction>
          </phong>
        </technique>
      </profile_COMMON>
    </effect>
  </library_effects>
  <library_materials>
    <material id="blinn3m1-material" name="blinn3m1">
      <instance_effect url="#blinn3m1-effect"/>
    </material>
  </library_materials>
  <library_geometries>
    <geometry id="o2jm1Mesh-mesh" name="o2jm1Mesh">
      <mesh>
        <source id="o2jm1Mesh-mesh-positions">
          <float_array id="o2jm1Mesh-mesh-positions-array" count="195">-0.336249 -0.109254 0.25 0.336249 0.109254 0.25 -0.109254 0.336249 0.25 0.109254 -0.336249 0.25 -0.336249 -0.109254 -0.25 0.109254 -0.336249 -0.25 0.336249 0.109254 -0.25 -0.109254 0.336249 -0.25 -0.336245 -0.191586 0.983639 0.336245 0.01240396 1.061944 -0.109252 0.2243199 1.143291 0.109251 -0.403502 0.902292 -0.336245 -0.01240396 0.516856 0.109252 -0.2243199 0.435509 0.336245 0.191586 0.595161 -0.109251 0.403502 0.676508 -1.59029 -0.25 0.25 -1.09029 0.25 0.25 -1.59029 0.25 0.25 -1.09029 -0.25 0.25 -1.59029 -0.25 -0.25 -1.09029 -0.25 -0.25 -1.09029 0.25 -0.25 -1.59029 0.25 -0.25 -1.590288 -0.322984 0.933201 -1.090292 0.143801 1.112384 -1.590288 0.143801 1.112384 -1.090292 -0.322984 0.933201 -1.590288 -0.143801 0.466416 -1.090292 -0.143801 0.466416 -1.090292 0.322984 0.645599 -1.590288 0.322984 0.645599 -0.308757 1.326447 0.368405 0.126477 1.855858 0.542447 -0.354109 1.822766 0.408507 0.171829 1.359539 0.502344 -0.178457 1.377142 -0.111647 0.302129 1.410234 0.02229297 0.256777 1.906553 0.06239497 -0.223809 1.873461 -0.07154399 -1.258311 0.56715 0.03048896 -1.109288 1.249156 0.14296 -1.516901 0.994347 0.005413949 -0.850698 0.821958 0.168036 -1.128012 0.617844 -0.44956 -0.720399 0.872653 -0.312014 -0.978989 1.29985 -0.337089 -1.386602 1.045042 -0.474636 -1.3986 0.435556 0.69009 -1.279095 1.071022 0.976262 -1.68671 0.816213 0.838715 -0.990985 0.690365 0.827637 -1.369625 0.635978 0.232938 -0.96201 0.890787 0.370485 -1.25012 1.271444 0.51911 -1.657735 1.016635 0.381563 -0.457352 1.181756 1.076899 -0.03502196 1.690822 1.32685 -0.529006 1.636602 1.271769 0.03663098 1.235976 1.131979 -0.428378 1.382178 0.61975 0.06560599 1.436398 0.674831 -0.006047964 1.891244 0.869701 -0.500031 1.837024 0.814621 -0.428378 1.382178 0.61975</float_array>
          <technique_common>
            <accessor source="#o2jm1Mesh-mesh-positions-array" count="65" stride="3">
              <param name="X" type="float"/>
              <param name="Y" type="float"/>
              <param name="Z" type="float"/>
            </accessor>
          </technique_common>
        </source>
        <source id="o2jm1Mesh-mesh-normals">
          <float_array id="o2jm1Mesh-mesh-normals-array" count="258">0 0 1 -0.4539903 -0.8910067 0 -0.4539903 -0.8910067 0 0.8910067 -0.4539903 0 0.8910067 -0.4539903 0 0.4539903 0.8910067 0 0.4539903 0.8910067 0 -0.8910067 0.4539903 0 -0.8910067 0.4539903 0 0 0 -1 -4.1038e-7 -0.358369 0.9335801 -3.04392e-7 -0.358369 0.9335801 -0.4539925 -0.8318248 -0.3193091 -0.4539916 -0.8318249 -0.31931 0.8910045 -0.4238409 -0.162696 0.8910054 -0.4238387 -0.1626971 0.4539917 0.8318252 0.3193092 0.4539924 0.8318246 0.31931 -0.8910053 0.4238393 0.1626954 -0.8910046 0.4238401 0.1626977 4.8188e-7 0.358369 -0.9335801 4.29197e-7 0.3583691 -0.9335801 0 -1 0 1 0 0 0 1 0 -1 0 0 0 -0.3583696 0.9335799 0 -0.3583697 0.9335799 0 -0.9335798 -0.3583698 0 -0.9335798 -0.3583698 1 1.53347e-7 0 1 1.21169e-7 0 0 0.9335798 0.3583697 0 0.9335798 0.3583698 -1 2.87225e-7 0 -1 0 0 0 0.3583698 -0.9335798 0 0.3583697 -0.9335798 -0.260602 -0.1013886 0.9601079 -0.2606001 -0.1013903 0.9601082 0.09070444 -0.9926428 -0.08020609 0.09070461 -0.9926427 -0.08020645 0.9611762 0.0661841 0.2678808 0.9611763 0.06618469 0.2678802 -0.09070467 0.9926427 0.08020645 -0.09070456 0.9926428 0.08020651 -0.961176 -0.06618463 -0.2678809 -0.9611763 -0.06618416 -0.2678803 0.2606001 0.1013903 -0.9601082 0.260602 0.1013885 -0.9601079 -0.2605996 -0.1013905 0.9601082 -0.2606025 -0.1013898 0.9601075 0.5171835 -0.854404 0.05015182 0.5171856 -0.8544028 0.05015057 0.8152346 0.5096226 0.2750953 0.8152344 0.5096231 0.2750949 -0.517185 0.8544031 -0.05015218 -0.517184 0.8544037 -0.05015015 -0.8152343 -0.5096231 -0.2750955 -0.8152346 -0.5096227 -0.2750951 0.2606025 0.1013898 -0.9601076 0.2605997 0.1013906 -0.9601083 -0.05794966 -0.4008471 0.9143103 -0.05794966 -0.400847 0.9143105 0.5762233 -0.7613201 -0.2972516 0.5762234 -0.76132 -0.2972518 0.8152347 0.5096219 0.2750964 0.8152348 0.5096219 0.2750962 -0.5762233 0.76132 0.2972515 -0.5762237 0.7613199 0.2972515 -0.8152348 -0.5096217 -0.2750963 -0.8152348 -0.5096218 -0.2750964 0.05794972 0.400847 -0.9143104 0.05794966 0.4008472 -0.9143104 -0.05795127 -0.4008477 0.91431 -0.0579493 -0.4008491 0.9143095 0.1433071 -0.9097036 -0.3897467 0.143308 -0.9097031 -0.3897476 0.9879801 0.1084414 0.1101629 0.9879799 0.1084443 0.1101617 -0.1433076 0.9097034 0.389747 -0.1433075 0.9097034 0.389747 -0.9879798 -0.1084435 -0.1101638 -0.9879803 -0.1084423 -0.110161 0.05794954 0.4008491 -0.9143096 0.05795133 0.4008477 -0.91431</float_array>
          <technique_common>
            <accessor source="#o2jm1Mesh-mesh-normals-array" count="86" stride="3">
              <param name="X" type="float"/>
              <param name="Y" type="float"/>
              <param name="Z" type="float"/>
            </accessor>
          </technique_common>
        </source>
        <source id="o2jm1Mesh-mesh-map-0">
          <float_array id="o2jm1Mesh-mesh-map-0-array" count="576">0 0 1 1 0 1 0 0 1 0 1 1 0 0 1 1 0 1 0 0 1 0 1 1 0 0 1 1 0 1 0 0 1 0 1 1 0 0 1 1 0 1 0 0 1 0 1 1 0 0 1 1 0 1 0 0 1 0 1 1 0 0 0 -1 1 -1 0 0 1 -1 1 0 0 0 1 1 0 1 0 0 1 0 1 1 0 0 1 1 0 1 0 0 1 0 1 1 0 0 1 1 0 1 0 0 1 0 1 1 0 0 1 1 0 1 0 0 1 0 1 1 0 0 1 1 0 1 0 0 1 0 1 1 0 0 0 -1 1 -1 0 0 1 -1 1 0 0 0 1 1 0 1 0 0 1 0 1 1 0 0 1 1 0 1 0 0 1 0 1 1 0 0 1 1 0 1 0 0 1 0 1 1 0 0 1 1 0 1 0 0 1 0 1 1 0 0 1 1 0 1 0 0 1 0 1 1 0 0 0 -1 1 -1 0 0 1 -1 1 0 0 0 1 1 0 1 0 0 1 0 1 1 0 0 1 1 0 1 0 0 1 0 1 1 0 0 1 1 0 1 0 0 1 0 1 1 0 0 1 1 0 1 0 0 1 0 1 1 0 0 1 1 0 1 0 0 1 0 1 1 0 0 0 -1 1 -1 0 0 1 -1 1 0 0 0 1 1 0 1 0 0 1 0 1 1 0 0 1 1 0 1 0 0 1 0 1 1 0 0 1 1 0 1 0 0 1 0 1 1 0 0 1 1 0 1 0 0 1 0 1 1 0 0 1 1 0 1 0 0 1 0 1 1 0 0 0 -1 1 -1 0 0 1 -1 1 0 0 0 1 1 0 1 0 0 1 0 1 1 0 0 1 1 0 1 0 0 1 0 1 1 0 0 1 1 0 1 0 0 1 0 1 1 0 0 1 1 0 1 0 0 1 0 1 1 0 0 1 1 0 1 0 0 1 0 1 1 0 0 0 -1 1 -1 0 0 1 -1 1 0 0 0 1 1 0 1 0 0 1 0 1 1 0 0 1 1 0 1 0 0 1 0 1 1 0 0 1 1 0 1 0 0 1 0 1 1 0 0 1 1 0 1 0 0 1 0 1 1 0 0 1 1 0 1 0 0 1 0 1 1 0 0 0 -1 1 -1 0 0 1 -1 1 0 0 0 1 1 0 1 0 0 1 0 1 1 0 0 1 1 0 1 0 0 1 0 1 1 0 0 1 1 0 1 0 0 1 0 1 1 0 0 1 1 0 1 0 0 1 0 1 1 0 0 1 1 0 1 0 0 1 0 1 1 0 0 0 -1 1 -1 0 0 1 -1 1 0</float_array>
          <technique_common>
            <accessor source="#o2jm1Mesh-mesh-map-0-array" count="288" stride="2">
              <param name="S" type="float"/>
              <param name="T" type="float"/>
            </accessor>
          </technique_common>
        </source>
        <vertices id="o2jm1Mesh-mesh-vertices">
          <input semantic="POSITION" source="#o2jm1Mesh-mesh-positions"/>
        </vertices>
        <polylist material="blinn3m1-material" count="96">
          <input semantic="VERTEX" source="#o2jm1Mesh-mesh-vertices" offset="0"/>
          <input semantic="NORMAL" source="#o2jm1Mesh-mesh-normals" offset="1"/>
          <input semantic="TEXCOORD" source="#o2jm1Mesh-mesh-map-0" offset="2" set="0"/>
          <vcount>3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 </vcount>
          <p>0 0 0 1 0 1 2 0 2 0 0 3 3 0 4 1 0 5 4 1 6 3 1 7 0 1 8 4 2 9 5 2 10 3 2 11 5 3 12 1 3 13 3 3 14 5 4 15 6 4 16 1 4 17 6 5 18 2 5 19 1 5 20 6 6 21 7 6 22 2 6 23 7 7 24 0 7 25 2 7 26 7 8 27 4 8 28 0 8 29 4 9 30 7 9 31 6 9 32 4 9 33 6 9 34 5 9 35 8 10 36 9 10 37 10 10 38 8 11 39 11 11 40 9 11 41 12 12 42 11 12 43 8 12 44 12 13 45 13 13 46 11 13 47 13 14 48 9 14 49 11 14 50 13 15 51 14 15 52 9 15 53 14 16 54 10 16 55 9 16 56 14 17 57 15 17 58 10 17 59 15 18 60 8 18 61 10 18 62 15 19 63 12 19 64 8 19 65 12 20 66 15 20 67 14 20 68 12 21 69 14 21 70 13 21 71 16 0 72 17 0 73 18 0 74 16 0 75 19 0 76 17 0 77 20 22 78 19 22 79 16 22 80 20 22 81 21 22 82 19 22 83 21 23 84 17 23 85 19 23 86 21 23 87 22 23 88 17 23 89 22 24 90 18 24 91 17 24 92 22 24 93 23 24 94 18 24 95 23 25 96 16 25 97 18 25 98 23 25 99 20 25 100 16 25 101 20 9 102 23 9 103 22 9 104 20 9 105 22 9 106 21 9 107 24 26 108 25 26 109 26 26 110 24 27 111 27 27 112 25 27 113 28 28 114 27 28 115 24 28 116 28 29 117 29 29 118 27 29 119 29 30 120 25 30 121 27 30 122 29 31 123 30 31 124 25 31 125 30 32 126 26 32 127 25 32 128 30 33 129 31 33 130 26 33 131 31 34 132 24 34 133 26 34 134 31 35 135 28 35 136 24 35 137 28 36 138 31 36 139 30 36 140 28 37 141 30 37 142 29 37 143 32 38 144 33 38 145 34 38 146 32 39 147 35 39 148 33 39 149 36 40 150 35 40 151 32 40 152 36 41 153 37 41 154 35 41 155 37 42 156 33 42 157 35 42 158 37 43 159 38 43 160 33 43 161 38 44 162 34 44 163 33 44 164 38 45 165 39 45 166 34 45 167 39 46 168 32 46 169 34 46 170 39 47 171 36 47 172 32 47 173 36 48 174 39 48 175 38 48 176 36 49 177 38 49 178 37 49 179 40 50 180 41 50 181 42 50 182 40 51 183 43 51 184 41 51 185 44 52 186 43 52 187 40 52 188 44 53 189 45 53 190 43 53 191 45 54 192 41 54 193 43 54 194 45 55 195 46 55 196 41 55 197 46 56 198 42 56 199 41 56 200 46 57 201 47 57 202 42 57 203 47 58 204 40 58 205 42 58 206 47 59 207 44 59 208 40 59 209 44 60 210 47 60 211 46 60 212 44 61 213 46 61 214 45 61 215 48 62 216 49 62 217 50 62 218 48 63 219 51 63 220 49 63 221 52 64 222 51 64 223 48 64 224 52 65 225 53 65 226 51 65 227 53 66 228 49 66 229 51 66 230 53 67 231 54 67 232 49 67 233 54 68 234 50 68 235 49 68 236 54 69 237 55 69 238 50 69 239 55 70 240 48 70 241 50 70 242 55 71 243 52 71 244 48 71 245 52 72 246 55 72 247 54 72 248 52 73 249 54 73 250 53 73 251 56 74 252 57 74 253 58 74 254 56 75 255 59 75 256 57 75 257 60 76 258 59 76 259 56 76 260 60 77 261 61 77 262 59 77 263 61 78 264 57 78 265 59 78 266 61 79 267 62 79 268 57 79 269 62 80 270 58 80 271 57 80 272 62 81 273 63 81 274 58 81 275 63 82 276 56 82 277 58 82 278 63 83 279 64 83 280 56 83 281 60 84 282 63 84 283 62 84 284 60 85 285 62 85 286 61 85 287</p>
        </polylist>
      </mesh>
    </geometry>
  </library_geometries>
  <library_controllers/>
  <library_visual_scenes>
    <visual_scene id="Scene" name="Scene">
      <node id="Root" name="Root" type="NODE">
        <matrix sid="transform">1 0 0 0 0 1 -4.37114e-8 0 0 4.37114e-8 1 0 0 0 0 1</matrix>
        <instance_geometry url="#o2jm1Mesh-mesh" name="Root">
          <bind_material>
            <technique_common>
              <instance_material symbol="blinn3m1-material" target="#blinn3m1-material"/>
            </technique_common>
          </bind_material>
        </instance_geometry>
      </node>
    </visual_scene>
  </library_visual_scenes>
  <scene>
    <instance_visual_scene url="#Scene"/>
  </scene>
</COLLADA>

 

<?xml version="1.0" encoding="utf-8"?>
<COLLADA xmlns="http://www.collada.org/2005/11/COLLADASchema" version="1.4.1">
  <asset>
    <contributor>
      <author>Blender User</author>
      <authoring_tool>Blender 2.78.0 commit date:2016-09-26, commit time:12:42, hash:4bb1e22</authoring_tool>
    </contributor>
    <created>2018-01-08T17:24:44</created>
    <modified>2018-01-08T17:24:44</modified>
    <unit name="meter" meter="1"/>
    <up_axis>Z_UP</up_axis>
  </asset>
  <library_images/>
  <library_effects>
    <effect id="blinn3m1-effect">
      <profile_COMMON>
        <technique sid="common">
          <phong>
            <emission>
              <color sid="emission">0 0 0 1</color>
            </emission>
            <ambient>
              <color sid="ambient">0 0 0 1</color>
            </ambient>
            <diffuse>
              <color sid="diffuse">0.64 0.64 0.64 1</color>
            </diffuse>
            <specular>
              <color sid="specular">0.5 0.5 0.5 1</color>
            </specular>
            <shininess>
              <float sid="shininess">50</float>
            </shininess>
            <index_of_refraction>
              <float sid="index_of_refraction">1</float>
            </index_of_refraction>
          </phong>
        </technique>
      </profile_COMMON>
    </effect>
  </library_effects>
  <library_materials>
    <material id="blinn3m1-material" name="blinn3m1">
      <instance_effect url="#blinn3m1-effect"/>
    </material>
  </library_materials>
  <library_geometries>
    <geometry id="o2jm1Mesh-mesh" name="o2jm1Mesh">
      <mesh>
        <source id="o2jm1Mesh-mesh-positions">
          <float_array id="o2jm1Mesh-mesh-positions-array" count="195">-0.336249 -0.109254 0.25 0.336249 0.109254 0.25 -0.109254 0.336249 0.25 0.109254 -0.336249 0.25 -0.336249 -0.109254 -0.25 0.109254 -0.336249 -0.25 0.336249 0.109254 -0.25 -0.109254 0.336249 -0.25 -0.336245 -0.191586 0.983639 0.336245 0.01240396 1.061944 -0.109252 0.2243199 1.143291 0.109251 -0.403502 0.902292 -0.336245 -0.01240396 0.516856 0.109252 -0.2243199 0.435509 0.336245 0.191586 0.595161 -0.109251 0.403502 0.676508 -1.59029 -0.25 0.25 -1.09029 0.25 0.25 -1.59029 0.25 0.25 -1.09029 -0.25 0.25 -1.59029 -0.25 -0.25 -1.09029 -0.25 -0.25 -1.09029 0.25 -0.25 -1.59029 0.25 -0.25 -1.590288 -0.322984 0.933201 -1.090292 0.143801 1.112384 -1.590288 0.143801 1.112384 -1.090292 -0.322984 0.933201 -1.590288 -0.143801 0.466416 -1.090292 -0.143801 0.466416 -1.090292 0.322984 0.645599 -1.590288 0.322984 0.645599 -0.308757 1.326447 0.368405 0.126477 1.855858 0.542447 -0.354109 1.822766 0.408507 0.171829 1.359539 0.502344 -0.178457 1.377142 -0.111647 0.302129 1.410234 0.02229297 0.256777 1.906553 0.06239497 -0.223809 1.873461 -0.07154399 -1.258311 0.56715 0.03048896 -1.109288 1.249156 0.14296 -1.516901 0.994347 0.005413949 -0.850698 0.821958 0.168036 -1.128012 0.617844 -0.44956 -0.720399 0.872653 -0.312014 -0.978989 1.29985 -0.337089 -1.386602 1.045042 -0.474636 -1.3986 0.435556 0.69009 -1.279095 1.071022 0.976262 -1.68671 0.816213 0.838715 -0.990985 0.690365 0.827637 -1.369625 0.635978 0.232938 -0.96201 0.890787 0.370485 -1.25012 1.271444 0.51911 -1.657735 1.016635 0.381563 -0.457352 1.181756 1.076899 -0.03502196 1.690822 1.32685 -0.529006 1.636602 1.271769 0.03663098 1.235976 1.131979 -0.428378 1.382178 0.61975 0.06560599 1.436398 0.674831 -0.006047964 1.891244 0.869701 -0.500031 1.837024 0.814621 -0.428378 1.382178 0.61975</float_array>
          <technique_common>
            <accessor source="#o2jm1Mesh-mesh-positions-array" count="65" stride="3">
              <param name="X" type="float"/>
              <param name="Y" type="float"/>
              <param name="Z" type="float"/>
            </accessor>
          </technique_common>
        </source>
        <source id="o2jm1Mesh-mesh-normals">
          <float_array id="o2jm1Mesh-mesh-normals-array" count="243">-1 2.64031e-7 0 0.4539903 0.8910067 0 0 0 -1 -1 0 0 0.8910067 -0.4539903 0 -0.8910067 0.4539903 0 0.8910045 -0.4238409 -0.162696 0.4539924 0.8318249 0.3193091 -0.8910045 0.4238408 0.162696 -0.260602 -0.1013886 0.9601079 0.05794948 0.4008491 -0.9143096 0.1433079 -0.9097035 -0.3897466 0.5762233 -0.7613201 -0.2972516 0 1 0 0 -1 0 1 0 0 0 -0.3583697 0.9335798 0 0 1 1 1.53347e-7 0 0 0.3583697 -0.9335798 -0.4539903 -0.8910067 0 0 0.9335798 0.3583698 0.2606 0.1013903 -0.9601082 -0.8152346 -0.5096226 -0.2750955 -0.9611762 -0.0661841 -0.2678808 0.09070444 -0.9926428 -0.08020609 0.8152346 0.5096226 0.2750953 4.8188e-7 0.3583691 -0.93358 0.5171851 -0.854403 0.05015236 0.2606024 0.1013898 -0.9601076 -0.4539925 -0.8318248 -0.3193091 -0.05795127 -0.4008477 0.91431 -0.1433076 0.9097034 0.389747 -0.98798 -0.1084415 -0.1101629 -0.0907045 0.9926428 0.08020645 -0.5762235 0.7613199 0.2972516 0.05794972 0.4008473 -0.9143104 0.8152347 0.509622 0.2750962 -0.05794966 -0.4008471 0.9143103 -0.8152348 -0.5096217 -0.2750963 0.9879801 0.1084414 0.1101629 -5.65084e-7 -0.358369 0.9335801 0.9611762 0.0661841 0.2678808 -0.517185 0.8544031 -0.05015218 -0.2605996 -0.1013905 0.9601082 0 -0.9335798 -0.3583697 -1 2.87224e-7 0 0.8910054 -0.4238387 -0.1626971 0.4539918 0.8318248 0.31931 -0.8910053 0.4238386 0.1626971 -0.2606001 -0.1013903 0.9601082 0.05795139 0.4008478 -0.91431 0.1433072 -0.9097033 -0.3897474 0.5762234 -0.76132 -0.2972518 0 -0.3583697 0.9335799 1 1.21169e-7 0 0 0.3583698 -0.9335798 0 0.9335798 0.3583698 0.260602 0.1013885 -0.9601078 -0.8152343 -0.5096232 -0.2750951 -0.9611762 -0.06618469 -0.2678804 0.09070461 -0.9926427 -0.08020645 0.8152344 0.5096231 0.2750949 3.89116e-7 0.358369 -0.9335801 0.517184 -0.8544038 0.05015003 0.2605996 0.1013906 -0.9601082 -0.4539916 -0.8318249 -0.31931 -0.0579493 -0.4008491 0.9143095 -0.1433075 0.9097034 0.389747 -0.9879799 -0.1084443 -0.1101618 -0.09070473 0.9926427 0.08020663 0.0579496 0.4008473 -0.9143103 0.8152347 0.5096219 0.2750965 -0.05794966 -0.400847 0.9143105 -0.8152348 -0.5096218 -0.2750964 0.9879799 0.1084443 0.1101617 -6.48805e-7 -0.358369 0.9335801 0.9611763 0.06618469 0.2678802 -0.517184 0.8544037 -0.05015015 -0.2606025 -0.1013898 0.9601075 0 -0.9335798 -0.3583698</float_array>
          <technique_common>
            <accessor source="#o2jm1Mesh-mesh-normals-array" count="81" stride="3">
              <param name="X" type="float"/>
              <param name="Y" type="float"/>
              <param name="Z" type="float"/>
            </accessor>
          </technique_common>
        </source>
        <source id="o2jm1Mesh-mesh-map-0">
          <float_array id="o2jm1Mesh-mesh-map-0-array" count="576">1 0 0 1 0 0 1 0 0 1 0 0 1 0 0 -1 1 -1 1 0 0 1 0 0 1 0 0 1 0 0 1 0 0 1 0 0 0 0 1 1 0 1 1 0 0 1 0 0 1 0 0 1 0 0 0 0 1 1 0 1 1 -1 0 0 0 -1 1 0 0 1 0 0 0 0 1 1 0 1 1 0 0 1 0 0 1 0 0 1 0 0 1 0 0 -1 1 -1 1 0 0 1 0 0 1 0 0 1 0 0 1 0 0 1 0 0 0 0 1 1 0 1 1 0 0 -1 1 -1 1 0 0 1 0 0 1 0 0 1 0 0 1 0 0 1 0 0 1 -1 0 0 0 -1 1 0 0 1 0 0 1 0 0 1 0 0 0 0 1 1 0 1 0 0 1 1 0 1 1 0 0 -1 1 -1 1 0 0 1 0 0 1 -1 0 0 0 -1 0 0 1 1 0 1 0 0 1 1 0 1 0 0 1 1 0 1 1 0 0 1 0 0 1 0 0 1 0 0 1 0 0 1 0 0 1 -1 0 0 0 -1 1 0 0 1 0 0 0 0 1 1 0 1 0 0 1 1 0 1 0 0 1 1 0 1 1 0 0 1 0 0 0 0 1 1 0 1 0 0 1 1 0 1 0 0 1 1 0 1 1 0 0 1 0 0 1 0 1 1 0 1 1 0 1 1 0 1 1 0 0 0 0 -1 1 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 0 1 0 0 1 0 1 1 1 0 1 1 0 1 1 0 1 1 0 1 0 0 1 0 1 1 1 -1 1 0 0 0 1 0 1 1 0 1 0 0 1 0 1 1 1 0 1 1 0 1 1 0 1 1 0 1 1 0 0 0 0 -1 1 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 0 1 0 0 1 0 1 1 1 0 0 0 0 -1 1 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 -1 1 0 0 0 1 0 1 1 0 1 1 0 1 1 0 1 0 0 1 0 1 1 0 0 1 0 1 1 1 0 0 0 0 -1 1 0 1 1 0 1 1 -1 1 0 0 0 0 0 1 0 1 1 0 0 1 0 1 1 0 0 1 0 1 1 1 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 -1 1 0 0 0 1 0 1 1 0 1 0 0 1 0 1 1 0 0 1 0 1 1 0 0 1 0 1 1 1 0 1 1 0 1 0 0 1 0 1 1 0 0 1 0 1 1 0 0 1 0 1 1 1 0 1 1 0 1</float_array>
          <technique_common>
            <accessor source="#o2jm1Mesh-mesh-map-0-array" count="288" stride="2">
              <param name="S" type="float"/>
              <param name="T" type="float"/>
            </accessor>
          </technique_common>
        </source>
        <vertices id="o2jm1Mesh-mesh-vertices">
          <input semantic="POSITION" source="#o2jm1Mesh-mesh-positions"/>
        </vertices>
        <polylist material="blinn3m1-material" count="96">
          <input semantic="VERTEX" source="#o2jm1Mesh-mesh-vertices" offset="0"/>
          <input semantic="NORMAL" source="#o2jm1Mesh-mesh-normals" offset="1"/>
          <input semantic="TEXCOORD" source="#o2jm1Mesh-mesh-map-0" offset="2" set="0"/>
          <vcount>3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 </vcount>
          <p>28 0 0 26 0 1 31 0 2 7 1 3 1 1 4 6 1 5 21 2 6 23 2 7 22 2 8 20 3 9 18 3 10 23 3 11 6 4 12 3 4 13 5 4 14 4 5 15 2 5 16 7 5 17 13 6 18 9 6 19 11 6 20 15 7 21 9 7 22 14 7 23 12 8 24 10 8 25 15 8 26 32 9 27 33 9 28 34 9 29 62 10 30 60 10 31 63 10 32 61 11 33 56 11 34 60 11 35 52 12 36 51 12 37 48 12 38 23 13 39 17 13 40 22 13 41 21 14 42 16 14 43 20 14 44 5 2 45 7 2 46 6 2 47 22 15 48 19 15 49 21 15 50 27 16 51 26 16 52 24 16 53 3 17 54 2 17 55 0 17 56 29 18 57 25 18 58 27 18 59 29 19 60 31 19 61 30 19 62 5 20 63 0 20 64 4 20 65 19 17 66 18 17 67 16 17 68 31 21 69 25 21 70 30 21 71 38 22 72 36 22 73 39 22 74 44 23 75 42 23 76 47 23 77 36 24 78 34 24 79 39 24 80 36 25 81 35 25 82 32 25 83 45 26 84 41 26 85 43 26 86 13 27 87 15 27 88 14 27 89 45 28 90 40 28 91 44 28 92 46 29 93 44 29 94 47 29 95 12 30 96 11 30 97 8 30 98 56 31 99 57 31 100 58 31 101 62 32 102 58 32 103 57 32 104 64 33 105 58 33 106 63 33 107 39 34 108 33 34 109 38 34 110 55 35 111 49 35 112 54 35 113 54 36 114 52 36 115 55 36 116 54 37 117 51 37 118 53 37 119 48 38 120 49 38 121 50 38 122 55 39 123 48 39 124 50 39 125 61 40 126 57 40 127 59 40 128 11 41 129 10 41 130 8 41 131 37 42 132 33 42 133 35 42 134 46 43 135 42 43 136 41 43 137 40 44 138 41 44 139 42 44 140 29 45 141 24 45 142 28 45 143 28 46 144 24 46 145 26 46 146 7 1 147 2 1 148 1 1 149 21 2 150 20 2 151 23 2 152 20 3 153 16 3 154 18 3 155 6 4 156 1 4 157 3 4 158 4 5 159 0 5 160 2 5 161 13 47 162 14 47 163 9 47 164 15 48 165 10 48 166 9 48 167 12 49 168 8 49 169 10 49 170 32 50 171 35 50 172 33 50 173 62 51 174 61 51 175 60 51 176 61 52 177 59 52 178 56 52 179 52 53 180 53 53 181 51 53 182 23 13 183 18 13 184 17 13 185 21 14 186 19 14 187 16 14 188 5 2 189 4 2 190 7 2 191 22 15 192 17 15 193 19 15 194 27 54 195 25 54 196 26 54 197 3 17 198 1 17 199 2 17 200 29 55 201 30 55 202 25 55 203 29 56 204 28 56 205 31 56 206 5 20 207 3 20 208 0 20 209 19 17 210 17 17 211 18 17 212 31 57 213 26 57 214 25 57 215 38 58 216 37 58 217 36 58 218 44 59 219 40 59 220 42 59 221 36 60 222 32 60 223 34 60 224 36 61 225 37 61 226 35 61 227 45 62 228 46 62 229 41 62 230 13 63 231 12 63 232 15 63 233 45 64 234 43 64 235 40 64 236 46 65 237 45 65 238 44 65 239 12 66 240 13 66 241 11 66 242 56 67 243 59 67 244 57 67 245 62 68 246 63 68 247 58 68 248 64 69 249 56 69 250 58 69 251 39 70 252 34 70 253 33 70 254 55 35 255 50 35 256 49 35 257 54 71 258 53 71 259 52 71 260 54 72 261 49 72 262 51 72 263 48 73 264 51 73 265 49 73 266 55 74 267 52 74 268 48 74 269 61 75 270 62 75 271 57 75 272 11 76 273 9 76 274 10 76 275 37 77 276 38 77 277 33 77 278 46 78 279 47 78 280 42 78 281 40 79 282 43 79 283 41 79 284 29 80 285 27 80 286 24 80 287</p>
        </polylist>
      </mesh>
    </geometry>
  </library_geometries>
  <library_controllers/>
  <library_visual_scenes>
    <visual_scene id="Scene" name="Scene">
      <node id="Root" name="Root" type="NODE">
        <matrix sid="transform">1 0 0 0 0 1 -4.37114e-8 0 0 4.37114e-8 1 0 0 0 0 1</matrix>
        <instance_geometry url="#o2jm1Mesh-mesh" name="Root">
          <bind_material>
            <technique_common>
              <instance_material symbol="blinn3m1-material" target="#blinn3m1-material"/>
            </technique_common>
          </bind_material>
        </instance_geometry>
      </node>
    </visual_scene>
  </library_visual_scenes>
  <scene>
    <instance_visual_scene url="#Scene"/>
  </scene>
</COLLADA>

 

[ChinRey]

10 hours ago, Love Zhaoying said:

Is this the new “post anything” thread?

Not yet. So far it has turned out to be the new "post dull technical data only the most hopelessly nerdy geeks can possibly be interested in" thread.

[OptimoMaximo]

12 minutes ago, ChinRey said:

That's an intriguing idea. I assumed it was about the compression ratio the files could achieve but you may well be right.

It has some correlation and affinity with compression ratios, because of each data type needs to be encoded in a C struct data type (U16, F32 and the likes) so that a number can be written with a value represented with 2 or 4 bytes, depending on the data type. This is done primarily for data compression, so you're right on this side. The missing link to me is the way LL managed to have a binary file (with fixed packets size and order to maintain) to allow a random parsing order. When dumping data to a binary file, to respect the given parsing order, data needs to be detected/read and immediately dumped as soon as it was collected, basically not collecting the data, reorganizing as needed and written out. Hence my idea (just speculation again) of those "partitions" as i have temporarily named, awaiting a better definition. It was designed with a particular set of data entries in mind, in a specific order the devs were given, so they based the internal mesh format to that standard. Then, allowance for the same data block to be created a second-third-N time to allow different parsing orders, leaving entire chunks of files full of zeroes. Which still counts as data, as per the file size/load go: needs to be fully parsed for the viewer to render it. Reading a lot of zeroes you could have avoided does add to file size (download) and computation time spent on reading the file. It's fractions of a millisecond maybe, but that's the time scale a binary file is meant to allow to work at.

For bvh animations at least it's how it works, i am not sure the mesh uploader does the same, but both are text files and i'm assuming the file reading happens similarly. I iwll dig in the viewer code as i did for the animation exporter when i have some more spare time.

[OptimoMaximo]

One thing i notice as a main difference is the Up Axis definition, in the Blender version is set to Z, from the mesh generator it's set to Y. It shouldn't make a difference, perhaps your linkset comes in sideways or rotated, i don't know. I would not be surprised if LL created the prims using the Y axis up, considering the already well known scene orientation and scale discrepancies there are between rigging skeleton and animation skeleton.

[ChinRey]

1 hour ago, OptimoMaximo said:

One thing i notice as a main difference is the Up Axis definition, in the Blender version is set to Z, from the mesh generator it's set to Y.

Yes, that's a very obvious one. It doesn't affect anything though, neither land impact nor rotation. There must be something somewhere else in the file that counteracts that apparently faulty axis definition.

You may notice btw that the Mesh Studio file is considerably bigger than the Blender ones -  they are 19 and 12 Kb respectively - so the amount of input data doesn't seem to matter much. Among other things, Mesh Studio defines a long list of matrials that aren't actually used and it uses five zero decimal floats where Blender simplifies to integers. The uploader doesn't seem to have any problems handling all this superfluous data.

 

Edit: I can't reply to reactions of course but Pamela, that's how a dae file looks fi you open it. Essentially it's a plain(ish) text building manual the uplaoder reads to build a lovely (or not) mesh thingy for Second Life.

Edited January 8, 2018 by ChinRey

[Anna Nova]

12 hours ago, ChinRey said:

Not yet. So far it has turned out to be the new "post dull technical data only the most hopelessly nerdy geeks can possibly be interested in" thread.

Call me names if you like, I am enjoying it.  You never know what you learn, nor when it will be useful.

[Love Zhaoying]

13 hours ago, ChinRey said:

Not yet. So far it has turned out to be the new "post dull technical data only the most hopelessly nerdy geeks can possibly be interested in" thread.

My 3? 4? Year old PC works just fine with SL. Could be due to SSD. No idea which graphic card I have, but fan does run with SL. Is that dull enough?

[OptimoMaximo]

13 hours ago, ChinRey said:

Yes, that's a very obvious one. It doesn't affect anything though, neither land impact nor rotation. There must be something somewhere else in the file that counteracts that apparently faulty axis definition.

I know it doesn't affect anything, i was just thinking how messy their assets have been created.

The faulty axis definition is what makes the rotation conversion internally, however. It's a reference to the input coordinate system so that the uploader knows what and how to convert the matrix to match the expected orientation. When i make a static mesh with Y up, i upload it just fine, rezzes just fine but when i select it, it's showing a rotation by 90 degrees on the X axis.

Another thing, which in terms of syntax shouldn't matter, but in terms of binary data writing it makes the file slightly bigger

 <unit name="meter" meter="1"/> this is Blender

 

<unit meter="1.000000"/> this is MeshStudio

Same type of data in a flexible parsing pattern that respect a syntax. In terms of code they're both accepted of course, but to encode strings in binary you've get to get a representation like this: (python 2.7 code): bytes(bytearray(joint,'utf8')),0) #where the last zero means LL encodes strings with a null character at the end

In the C structs each piece of data gets a slot, and there i can see 2 strings to encode instead of one. Spread this behavior across the whole file and it ends up with unnecessary bytes slots occupied that could be summarized in less slots. here you can see the bytes equivalencies between regular scripting data types to C struct data types https://docs.python.org/2/library/struct.html

Note that by default every 3D software, internally, encodes floats as type double (8 bytes) as opposed to the simpler float (4 bytes); also the type of integers can vary between 2 and 4 bytes.

Hence i suppose that:

- introducing a specific order in which this data is being fed;

- introducing a better representation of these values as strings in the Collada text (for both strings and values, you said Blender uses integers where MeshStudio uses floats) so that the uploader parses it reading the values as it would expect to avoid conversions or silent equivalencies

Should reduce the amount of compatibility operations on parsing orders and syntax equivalencies. I see what you meant about flexible syntax, but that's not real flexibility: delete a < or > and the file doesn't validate anymore (see Collada validation docs). Indentation doesn't count, which makes it a syntax flexible file type because of this; make a wrong indentation in Python and it won't work. The raw text you input though MUST follow a rigid syntax. Again, remove quotes or punctuation and the file goes to the trash.

About the Collada version you were talking about earlier, i'm not using fCollada because i'm on Maya. I don't use the Collada exporter in there because it takes ages to export (at least rigged stuff does), the LI and DL are higher in my case, and it doesn't always work for Second Life. What i do is to export to fbx version 7.1 (2011), the same version LL used to implement mesh at the time, then convert it with another software called FBX Converter (from Autodesk, free), which ensures the official Collada conversion. Otherwise i might install the OpenCollada plug in, but then every time i upgrade to a new version i have to wait for the Khronos group to update the plug in too. With the conversion method from fbx 7.1, i always get the lowest LI and DL, tested across different fbx versions converted to Collada using the same model.

Edited January 9, 2018 by OptimoMaximo
added text about axis conversion

[ChinRey]

3 hours ago, anna2358 said:

Call me names if you like, I am enjoying it.  You never know what you learn, nor when it will be useful.

When it comes to usefulness, what I think is important here is why the land impact of identical meshes vary depending on which program the dae files generated by. Hopefully it's possible to figure out the most optimal way to encode a dae file to make it as edible for the uploader as possible and maybe come up with some sort of preprocessor that can convert dae files from various source to minimize the land impact - or maybe convince LL to upgrade the uploader to handle different variants of dae files better. That ought to be useful for everybody in SL of course but I'm afraid getting there is a rather complicated and nerdy process.

It may seem a bit pointless to worry about minute differences like these but they do add up and of course sometimes you're right on the border between two land impact values. One of the builds made last week is a good example. It's this group of five small trees:

With decent LoD models and at the size in the picture, it ended up with a  download weight a fraction over 1.5 the way Blender exported it at first. That is rounded up to 2 LI. Using the little I already know about optimizing for "edibile" dae, I was able to shave off just enough weight to get it below 1.5 so the LI is rounded down to 1. That's a 50% reduction of the nominal land impact and although a case like this isn't common, it's not unusual either.

Edit: It's not only about a nominal LI reduction btw. We're talking about genuine allbeit small reductions in the bandwidth requriements here and that is something both LL and the SL users should benefit from.

Edited January 9, 2018 by ChinRey

[ChinRey]

42 minutes ago, OptimoMaximo said:

I know it doesn't affect anything, i was just thinking how messy their assets have been created.

My thoughts exactly but even so, the uploader handles that mess slightly better than the apparently cleaner output from Blender.

Come to think of it, I would presume the conversion from dae to SL's internal mesh format is done client side. Maybe a TPV developer - like @Beq Janus - knows a thing or two about it?

(About integers vs zero decimal floats):

48 minutes ago, OptimoMaximo said:

Another thing, which in terms of syntax shouldn't matter, but in terms of binary data writing it makes the file slightly bigger

I tried to change the integers in one of the arrays of the Blender file to Mesh Studio style floats and that didn't affect the result at all.

 

54 minutes ago, OptimoMaximo said:

About the Collada version you were talking about earlier, i'm not using fCollada because i'm on Maya. I don't use the Collada exporter in there because it takes ages to export (at least rigged stuff does), the LI and DL are higher in my case, and it doesn't always work for Second Life.

Ok. According to wikipedia, ColladaMaya is based on fCollada and I thought that was the one that is the standard for Maya.

It would be very itneresting to see what the various dae export options from Maya would make of my test mesh. Do you have time to laod my Mesh Studio dae into Maya, export it in different ways and see what the result is?

[OptimoMaximo]

5 minutes ago, ChinRey said:

Ok. According to wikipedia, ColladaMaya is based on fCollada and I thought that was the one that is the standard for Maya

i'm sorry to add to the confusion, i need to phrase better. I meant: the fact i'm using Maya doesn't include my use of fCollada, exactly because that's Maya's default. OpenCollada is based on MayaCollada with slight differences afaik. To avoid using that, export to fbx and then conversion with fbx converter.

When importing a mesh with some properties in Maya through Collada, properties get baked into TRS (transforms) and, as a result, the export procedure outputs the same file structure it got in input, regardless of the native Maya structure, as long as the file format doesn't change (and switching to fbx and back to Collada isn't a file format change for what these data structures are concerned, apparently). I could witness this behavior while testing the mesh "layers" bug to reproduce it from Maya. A working-bug collada imported and re-exported worked as intended; making it anew in Maya didn't, until i found the node combination and structure causing said bug to be exported as a correctly working-bug from Maya.

[OptimoMaximo]

What i'm thinking is that LL might want to do as they did with the animation formats, and perhaps be able to upload a mesh in SL native binary format directly from our softwares, it would be the really ONLY way to ensure an output that is the slimmest version possible of the required data.

[ChinRey]

6 minutes ago, OptimoMaximo said:

i'm sorry to add to the confusion, i need to phrase better. I meant: the fact i'm using Maya doesn't include my use of fCollada, exactly because that's Maya's default.

That's how I understood what you said but I wasn't sure so I had to ask.

But does that mean fCollada sometimes generates dae files that are unreadable by the SL uploader? That doesn't seem to make sense at all and it's certianly worrying.

 

4 minutes ago, OptimoMaximo said:

What i'm thinking is that LL might want to do as they did with the animation formats, and perhaps be able to upload a mesh in SL native binary format directly from our softwares, it would be the really ONLY way to ensure an output that is the slimmest version possible of the required data.

Yes, that would be the ideal solution. I doubt it's going to happen though.

[OptimoMaximo]

1 minute ago, ChinRey said:

But does that mean fCollada sometimes generates dae files that are unreadable by the SL uploader? That doesn't seem to make sense at all and it's certianly worrying.

I have had instances with lots of troubles: really LONG export time (my personal Hall Of Records about this states 22 minutes to complete the export as longest export time, and it wasn't even a rigged item), ridiculous LI even hammering the mesh LoDs to death, parsing errors and LoDs not generating in the uploader, is my experience with FBX_DAE (how the plug in reads among the options for the Collada export, because it's part of the fbx plug in). But this was long ago, with Maya 2011, which was supposed to be the version of Maya LL used to develop mesh, at the time. I don't recall where i read this, but i later found the info about exporting fbx and convert it to Collada with fbxConverter to have it perfectly functional with no mistakes. Which indeed changed the whole experience i had importing the same objects that, previously, had an unjustified too high LI. I never tried the native collada exporter again since then, by now it's part of my workflow, and it's easy to use: just drag and drop multiple files into the input window, choose Collada and click export. Flawless WYSIWYG Maya -> SL results in way less time. Except for rigged meshes that take a little longer anyway, and with quite high number of vertices the export time increases dramatically, it's still better than waiting overnight for the native Maya Collada export in my opinion, also considering the uncertainty of a good import arising from my previous experience.

[ChinRey]

3 minutes ago, OptimoMaximo said:

But this was long ago, with Maya 2011, which was supposed to be the version of Maya LL used to develop mesh, at the time.

Yes and that's of course exactly why I say it doesn't seem to make sense.

[OptimoMaximo]

4 minutes ago, ChinRey said:

Yes and that's of course exactly why I say it doesn't seem to make sense.

Figure how outraged i was at the time, to make me switch to Blender for my SL activities.

Edited January 9, 2018 by OptimoMaximo
punctuation, missing verb

[OptimoMaximo]

1 hour ago, ChinRey said:

Yes, that would be the ideal solution. I doubt it's going to happen though.

Why not? I mean, before the ability to upload .anim files, only bvh could be used. Earlier there was no interest. Arising interest might be of use. And it would be much easier (for me at least) to write an exporter for that than managing the Collada text format. Plus, they would ensure that content would be uploaded properly and as clean and performant as it possibly can be

[ChinRey]

36 minutes ago, OptimoMaximo said:

Why not?

I'm not absolutely sure but I believe it's a propriatary file format because it has too many quirks to fit any open format I know of. That means that even if they made it public, somebody would still have to write exporters, not just for Maya but for every single 3D modelling software.

You can always fie a JIRA suggesting it of course but don't hope for too much.

[OptimoMaximo]

1 minute ago, ChinRey said:

I'm not absolutely sure but I believe it's a propriatary file format because it has too many quirks to fit any open format I know of.

For what matters, .anim format is also proprietary to LL, no other company uses this specific type of .anim. It is a hardcoded summary of a text file like bvh, which wants a specific order for the data to be read. It's just a matter of taking the data in the wanted order, write it down with the values arranged as per LL's binary compression specs (LLSD if i'm not mistaken). Right now the viewer repository on line https://bitbucket.org/lindenlab/viewer-release/src/8579cefad3049e139efaa1b40a94f0357fcd0274/indra/ appears to be unavailable at the time of this writing, however they have docs about the mesh format out there http://wiki.secondlife.com/wiki/Mesh/Mesh_Asset_Format what is missing is an uploader that accepts outsourced content in that format

[Beq Janus]

9 hours ago, ChinRey said:

Come to think of it, I would presume the conversion from dae to SL's internal mesh format is done client side. Maybe a TPV developer - like @Beq Janus - knows a thing or two about it?

I can talk a bit about it. People with sleep disorders have often come to me for help for that reason

The SLM format is indeed proprietary and we produce the SLM from the DaE. The SLM is designed to be very lightweight and suited to streaming.

The size differences can come from a number of sources, most typically they arise from people using generated LOD models. The GLOD library that is used to produce the simplified meshes has some random seed in it (for reasons I have never understood, nor really investigated) and as a result, the generated LOD models can vary a bit with each upload. This becomes worse as the models become more complex, given that you can place an entire linkset in a DaE along with all the LOD models for said linkset, the permutations become fairly horrendous. Most of us though tend to keep it simple, a DaE per LOD.

@Drongle McMahon made an excellent summary of the Mesh Upload format back in the day and I referenced that extensively when I blogged a description of the work I was doing to understand that (before I was working on Firestorm) when I was writing a plugin for Blender. 

The SLM format is a simple hierarchical list of meshes. Each "Material face" in the Mesh sense not the SL sense is extracted as a separate mesh, thus an 8 face object is composed of 8 separate "meshes" in the upload format. Where a mesh is a self-contained list of vertices, edges and UVs. Each set of these "material meshes" is packaged as a mesh unit (effectively a mesh primitive) and an array of these (1 or more) is combined into a LOD Model. Then we have a repeat of that for each LOD Model, a decomposition block for the various physics shapes and the texture info.

A hopefully better description is in my blog, though I probably understand it better now than when I wrote these (which was part of the point of writing it of course) but I think for the most part what they say still holds true.

An initial waffly blog about why things are not always the same LI

A more thorough walkthrough of the Mesh streaming format.

On 08/01/2018 at 11:28 PM, ChinRey said:

Yes, that's a very obvious one. It doesn't affect anything though, neither land impact nor rotation.

The above quote related to the Axis in the mesh. In theory, it could change the LI.....in theory...

When the material meshes are made they are individually compressed using an equivalent of "gzip -9". Zip compression works on repeated patterns and some data is more compressible than others. in some objects it is plausible that a mesh rotated by 90 degrees is more easily compressed. That said, it is hard to arrange that arbitrarily and it does assume that the vertex coordinates are different not just that the axis annotation in the DaE is different, as I don't think that is even used (though I have not checked...).

Anyhoo, very late. Bedtime.

Beq