Mantis Bug Tracker
Main | My View | View Issues | Change Log | Roadmap | Summary | My Account
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0008505opensim[GRID] Other Servicepublic2019-03-23 05:362019-04-18 04:29
ReporterZauberParacelsus 
Assigned ToUbitUmarov 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOperating SystemOperating System Version
Product Version 
Target VersionFixed in Version 
Summary0008505: Regression: Mesh Texturing Issue
DescriptionThis 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.
Steps To Reproduce1) 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.
TagsNo tags attached.
Git Revision or version number
Run Mode Grid (Multiple Regions per Sim)
Physics EngineBulletSim
Script Engine
EnvironmentUnknown
Mono VersionNone
Viewer
Attached Files? file icon Test.dae [^] (16,924 bytes) 2019-03-23 05:36

- Relationships

-  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.

- 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

Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker