MantisBT - opensim
View Issue Details
0008505opensim[GRID] Other Servicepublic2019-03-23 05:362019-04-18 04:29
ZauberParacelsus 
UbitUmarov 
normalminoralways
closedfixed 
 
 
Grid (Multiple Regions per Sim)
BulletSim
Unknown
None
0008505: Regression: Mesh Texturing Issue
This is a bit of an unusual case. If, in blender, you create a mesh object with multiple material slots, but then have every slot have the same material, then the object will not be properly texturable in-world.

Textures do not apply initially except to the first texture slot, and when shift-copied the textures will revert. I had another person test the same mesh I was using, and I did not see any of their texturing changes go through at all. Additionally, scripted changes to textures do not function except for the first texture slot.

This issue occurs in 0.9.1 Dev, but it does not occur in 0.8.2.1 Post_Fixes, so it appears to be a regression.
1) Download the attached example file, Test.dae
2) Login to an opensim standalone or grid running 0.9.1 Dev
3) Upload Test.dae
4) Rez it the mesh. You will see two rows of six squares. Each row is a separate link.
5) Attempt to apply a texture to the entire linkset. One row will texture properly, the other row will have textures revert for all but the first square.
6) Apply the texture a second time. It will appear to work.
7) Shift-copy the object. Textures on one row will revert.
8) Repeat steps 5 and 6, then set transparency to any amount, and change it back to 0 if desired.
9) Shift-copy the object again. After having changed transparency in step 8, the textures will not revert after having set transparency.
10) Repeating steps 5-7 again will continue to exhibit the problem.
No tags attached.
? Test.dae (16,924) 2019-03-23 05:36
http://opensimulator.org/mantis/file_download.php?file_id=4850&type=bug
Issue History
2019-03-23 05:36ZauberParacelsusNew Issue
2019-03-23 05:36ZauberParacelsusFile Added: Test.dae
2019-03-23 06:08UbitUmarovNote Added: 0034957
2019-03-23 06:15ZauberParacelsusNote Added: 0034958
2019-03-23 08:33UbitUmarovNote Added: 0034959
2019-03-23 08:37ZauberParacelsusNote Added: 0034961
2019-03-23 08:55UbitUmarovNote Added: 0034962
2019-03-23 09:28UbitUmarovNote Added: 0034963
2019-03-23 09:35UbitUmarovNote Added: 0034964
2019-03-23 16:36UbitUmarovNote Added: 0034966
2019-03-23 19:36UbitUmarovNote Added: 0034969
2019-04-17 05:30UbitUmarovNote Added: 0035141
2019-04-17 19:51ZauberParacelsusNote Added: 0035150
2019-04-18 04:29UbitUmarovStatusnew => closed
2019-04-18 04:29UbitUmarovAssigned To => UbitUmarov
2019-04-18 04:29UbitUmarovResolutionopen => fixed

Notes
(0034957)
UbitUmarov   
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   
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   
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   
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   
2019-03-23 08:55   
the dae is irrelevant.
what we get from viewers is what I showed
(0034963)
UbitUmarov   
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   
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   
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   
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   
2019-04-17 05:30   
is this better now?
(0035150)
ZauberParacelsus   
2019-04-17 19:51   
Yes, the issue is fully resolved.