| Anonymous | Login | Signup for a new account | 2020-04-03 13:21 PDT |  |
| Main | My View | View Issues | Change Log | Roadmap | Summary | My Account |
| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
| 0008505 | opensim | [GRID] Other Service | public | 2019-03-23 05:36 | 2019-04-18 04:29 | ||||
| Reporter | ZauberParacelsus | ||||||||
| Assigned To | UbitUmarov | ||||||||
| Priority | normal | Severity | minor | Reproducibility | always | ||||
| Status | closed | Resolution | fixed | ||||||
| Platform | OS | OS Version | |||||||
| Product Version | |||||||||
| Target Version | Fixed in Version | ||||||||
| Summary | 0008505: Regression: Mesh Texturing Issue | ||||||||
| Description | 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. | ||||||||
| Steps To Reproduce | 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. | ||||||||
| Tags | No tags attached. | ||||||||
| Git Revision or version number | |||||||||
| Run Mode | Grid (Multiple Regions per Sim) | ||||||||
| Physics Engine | BulletSim | ||||||||
| Script Engine | |||||||||
| Environment | Unknown | ||||||||
| Mono Version | None | ||||||||
| Viewer | |||||||||
| Attached Files |  Test.dae [^] (16,924 bytes) 2019-03-23 05:36 | ||||||||
 Relationships |
|
 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. |
|
Notes |
|
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 |
|
Issue History |
| Copyright © 2000 - 2012 MantisBT Group |
 |