0008505: Regression: Mesh Texturing Issue

(0034957)
UbitUmarov (administrator)
2019-03-23 06:08

in fact something strange on one of the objects
looked to the dae in blender
one object has a material set per square.
but the other apparently had the same material on all
tested setting that object as the first, one material per square face, uploaded and all worked as expected.

(0034958)
ZauberParacelsus (reporter)
2019-03-23 06:15

"but the other apparently had the same material on all "

Yeah, that is the setup that is producing the problem. I know the workaround. However, this type of material setup was previously working in opensim, and now with the 9.1 dev version it is not.

(0034959)
UbitUmarov (administrator)
2019-03-23 08:33

at upload we get one face for than prim:
<map><key>instance_list</key>
<array>
  <map>
    <key>face_list</key>
    <array>
    <map>
    <key>diffuse_color</key><array><real>0.63999998569488525</real><real>0.63999998569488525</real><real>0.63999998569488525</real><real>1</real></array>
            <key>fullbright</key><boolean>0</boolean>
    </map>
   </array>

this is one face.
then follows rest of prim data

   <key>material</key><integer>3</integer>
...
then the next prim with 6 faces.

but as we actually see inworld, viewers see the mesh spliced in 6 separated bits, and contrary to what you designed and they did upload, it makes that 6 faces at rez time.

Our code uses 1 face only and even sends that encoded to viewer.

older versions assumed all meshs had 8 faces all the time but that was the cause of other issues.

so well.. dunno :(

(0034961)
ZauberParacelsus (reporter)
2019-03-23 08:37

The DAE itself lists six material slots for each of the two meshes it contains:

  <library_visual_scenes>
    <visual_scene id="Scene" name="Scene">
      <node id="Plane" name="Plane" type="NODE">
        <matrix sid="transform">1 0 0 0 0 1 0 -7 0 0 1 0 0 0 0 1</matrix>
        <instance_geometry url="#Plane_001-mesh" name="Plane">
          <bind_material>
            <technique_common>
              <instance_material symbol="Material_001-material" target="#Material_001-material"/>
              
<instance_material symbol="Material_001-material" target="#Material_001-material"/>
              
<instance_material symbol="Material_001-material" target="#Material_001-material"/>
              
<instance_material symbol="Material_001-material" target="#Material_001-material"/>
              
<instance_material symbol="Material_001-material" target="#Material_001-material"/>
              
<instance_material symbol="Material_001-material" target="#Material_001-material"/>
            
</technique_common>
          </bind_material>
        </instance_geometry>
      </node>
      <node id="Plane_001" name="Plane_001" type="NODE">
        <matrix sid="transform">1 0 0 3 0 1 0 -7 0 0 1 0 0 0 0 1</matrix>
        <instance_geometry url="#Plane_002-mesh" name="Plane_001">
          <bind_material>
            <technique_common>
              <instance_material symbol="Material_001-material" target="#Material_001-material"/>
              
<instance_material symbol="Material_002-material" target="#Material_002-material"/>
              
<instance_material symbol="Material_003-material" target="#Material_003-material"/>
              
<instance_material symbol="Material_004-material" target="#Material_004-material"/>
              
<instance_material symbol="Material_005-material" target="#Material_005-material"/>
              
<instance_material symbol="Material_006-material" target="#Material_006-material"/>
            
</technique_common>
          </bind_material>
        </instance_geometry>
      </node>
    </visual_scene>
  </library_visual_scenes>

(0034962)
UbitUmarov (administrator)
2019-03-23 08:55

the dae is irrelevant.
what we get from viewers is what I showed

(0034963)
UbitUmarov (administrator)
2019-03-23 09:28

spent a few lindens and tested your dae at sl

and all seems to work fine..
we can change the texture of each piece ( lets forget the "normal" prim
and all seens to work..
we relog, and the changes are all gone, all pieces have the texture of one of the extrem parts
another avatar sees no change at all
one of the extrem prims does change all textures.

Somewhat different, the region just ignores wrong face numbers and sends no feedback, so viewer keeps displaying what you selected.
as we see, there also only one face is valid for the region, as it needs to be from the uploaded data.

other changes are just viewer bugs, due to the mesh splited into isolated islands without proper defined faces.

guess the solution is making it like the other prim, since that is what the viewer will endup doing

(0034964)
UbitUmarov (administrator)
2019-03-23 09:35

to make more clear what I see,
- sl regions refuse to do anything if they get a invalid ( >1) face number...
- current we will change the valid face, only sending that back
this is possible because the way changes are sent.

(0034966)
UbitUmarov (administrator)
2019-03-23 16:36

<cia-opensim> opensim: ajlduarte * r33986aea5e2c OpenSim/Region/ClientStack/Linden/Caps/BunchOfCaps (MeshCost.cs):
<cia-opensim> mantis 8506: parse highlod mesh and compare its number of prim faces to the number of faces provided and warn mismatch
(the 8506 there is a mistake, means this 8505)

with this extra code is clear that viewers at upload do create a mesh with 6 faces, but only declare one.

not sure we can work around this on all cases, ideas?

(0034969)
UbitUmarov (administrator)
2019-03-23 19:36

changed the code again
your dae should now work fine on git master.

wonder what I did break, but sure people will tell ;)

(0035141)
UbitUmarov (administrator)
2019-04-17 05:30

is this better now?

(0035150)
ZauberParacelsus (reporter)
2019-04-17 19:51

Yes, the issue is fully resolved.

Issue History
Date Modified	Username	Field	Change
2019-03-23 05:36	ZauberParacelsus	New Issue
2019-03-23 05:36	ZauberParacelsus	File Added: Test.dae
2019-03-23 06:08	UbitUmarov	Note Added: 0034957
2019-03-23 06:15	ZauberParacelsus	Note Added: 0034958
2019-03-23 08:33	UbitUmarov	Note Added: 0034959
2019-03-23 08:37	ZauberParacelsus	Note Added: 0034961
2019-03-23 08:55	UbitUmarov	Note Added: 0034962
2019-03-23 09:28	UbitUmarov	Note Added: 0034963
2019-03-23 09:35	UbitUmarov	Note Added: 0034964
2019-03-23 16:36	UbitUmarov	Note Added: 0034966
2019-03-23 19:36	UbitUmarov	Note Added: 0034969
2019-04-17 05:30	UbitUmarov	Note Added: 0035141
2019-04-17 19:51	ZauberParacelsus	Note Added: 0035150
2019-04-18 04:29	UbitUmarov	Status	new => closed
2019-04-18 04:29	UbitUmarov	Assigned To	=> UbitUmarov
2019-04-18 04:29	UbitUmarov	Resolution	open => fixed

Notes
(0034957) UbitUmarov (administrator) 2019-03-23 06:08	in fact something strange on one of the objects looked to the dae in blender one object has a material set per square. but the other apparently had the same material on all tested setting that object as the first, one material per square face, uploaded and all worked as expected.

(0034958) ZauberParacelsus (reporter) 2019-03-23 06:15	"but the other apparently had the same material on all " Yeah, that is the setup that is producing the problem. I know the workaround. However, this type of material setup was previously working in opensim, and now with the 9.1 dev version it is not.

(0034959) UbitUmarov (administrator) 2019-03-23 08:33	at upload we get one face for than prim: <map><key>instance_list</key> <array> <map> <key>face_list</key> <array> <map> <key>diffuse_color</key><array><real>0.63999998569488525</real><real>0.63999998569488525</real><real>0.63999998569488525</real><real>1</real></array> <key>fullbright</key><boolean>0</boolean> </map> </array> this is one face. then follows rest of prim data <key>material</key><integer>3</integer> ... then the next prim with 6 faces. but as we actually see inworld, viewers see the mesh spliced in 6 separated bits, and contrary to what you designed and they did upload, it makes that 6 faces at rez time. Our code uses 1 face only and even sends that encoded to viewer. older versions assumed all meshs had 8 faces all the time but that was the cause of other issues. so well.. dunno :(

(0034961) ZauberParacelsus (reporter) 2019-03-23 08:37	The DAE itself lists six material slots for each of the two meshes it contains: <library_visual_scenes> <visual_scene id="Scene" name="Scene"> <node id="Plane" name="Plane" type="NODE"> <matrix sid="transform">1 0 0 0 0 1 0 -7 0 0 1 0 0 0 0 1</matrix> <instance_geometry url="#Plane_001-mesh" name="Plane"> <bind_material> <technique_common> <instance_material symbol="Material_001-material" target="#Material_001-material"/> <instance_material symbol="Material_001-material" target="#Material_001-material"/> <instance_material symbol="Material_001-material" target="#Material_001-material"/> <instance_material symbol="Material_001-material" target="#Material_001-material"/> <instance_material symbol="Material_001-material" target="#Material_001-material"/> <instance_material symbol="Material_001-material" target="#Material_001-material"/> </technique_common> </bind_material> </instance_geometry> </node> <node id="Plane_001" name="Plane_001" type="NODE"> <matrix sid="transform">1 0 0 3 0 1 0 -7 0 0 1 0 0 0 0 1</matrix> <instance_geometry url="#Plane_002-mesh" name="Plane_001"> <bind_material> <technique_common> <instance_material symbol="Material_001-material" target="#Material_001-material"/> <instance_material symbol="Material_002-material" target="#Material_002-material"/> <instance_material symbol="Material_003-material" target="#Material_003-material"/> <instance_material symbol="Material_004-material" target="#Material_004-material"/> <instance_material symbol="Material_005-material" target="#Material_005-material"/> <instance_material symbol="Material_006-material" target="#Material_006-material"/> </technique_common> </bind_material> </instance_geometry> </node> </visual_scene> </library_visual_scenes>

(0034962) UbitUmarov (administrator) 2019-03-23 08:55	the dae is irrelevant. what we get from viewers is what I showed

(0034963) UbitUmarov (administrator) 2019-03-23 09:28	spent a few lindens and tested your dae at sl and all seems to work fine.. we can change the texture of each piece ( lets forget the "normal" prim and all seens to work.. we relog, and the changes are all gone, all pieces have the texture of one of the extrem parts another avatar sees no change at all one of the extrem prims does change all textures. Somewhat different, the region just ignores wrong face numbers and sends no feedback, so viewer keeps displaying what you selected. as we see, there also only one face is valid for the region, as it needs to be from the uploaded data. other changes are just viewer bugs, due to the mesh splited into isolated islands without proper defined faces. guess the solution is making it like the other prim, since that is what the viewer will endup doing

(0034964) UbitUmarov (administrator) 2019-03-23 09:35	to make more clear what I see, - sl regions refuse to do anything if they get a invalid ( >1) face number... - current we will change the valid face, only sending that back this is possible because the way changes are sent.

(0034966) UbitUmarov (administrator) 2019-03-23 16:36	<cia-opensim> opensim: ajlduarte * r33986aea5e2c OpenSim/Region/ClientStack/Linden/Caps/BunchOfCaps (MeshCost.cs): <cia-opensim> mantis 8506: parse highlod mesh and compare its number of prim faces to the number of faces provided and warn mismatch (the 8506 there is a mistake, means this 8505) with this extra code is clear that viewers at upload do create a mesh with 6 faces, but only declare one. not sure we can work around this on all cases, ideas?

(0034969) UbitUmarov (administrator) 2019-03-23 19:36	changed the code again your dae should now work fine on git master. wonder what I did break, but sure people will tell ;)

(0035141) UbitUmarov (administrator) 2019-04-17 05:30	is this better now?

(0035150) ZauberParacelsus (reporter) 2019-04-17 19:51	Yes, the issue is fully resolved.

Relationships