MantisBT - opensim
View Issue Details
0008263opensim[REGION] OpenSim Corepublic2017-11-07 19:562020-05-27 04:14
master (dev code) 
master (dev code) 
Grid (Multiple Regions per Sim)
.NET / Windows64
0008263: Very hard to apply normal or specular material textures consistently
As of commit 8479658cd0d395b3a91cb93821fac6166569df17 (remove a potencial (and silly) deadlock; let other texture parameters changes trigger Changed.TEXTURE event)

It is almost impossible to apply normal or specular map textures as well as their settings (Such as Glossiness, Environment, etc) to a group of prims / prim faces consistently.

Diffuse textures (Regular base textures) seem to apply with little to no difficulty but normal (Bump) and specular (Shiny) textures will seem to apply but then they'll revert back to what ever texture was set last (Or set itself to "None" if a texture wasn't previously set) on random prims and on random faces. If I take the object back or delete the object while it's in this state there will be a flood of messages similar to this "20:43:34 - [Materials]: SOP not found for localId: 2875653497" in the console.

Historically OpenSim has had this issue for a long time and the workaround was to simply repeatedly apply the texture(s) again until they "stick". Sometimes it would take a few tries but usually it would finally realize which textures are wanted on the prims and stick for the whole selection permanently. This technique still seems to work for diffuse textures but no longer works for normal and specular.

This issue does not seem to apply to scripted diffuse textures and is not applicable to scripted normal and specular since it isn't yet possible to set these materials via script.
1. Create a modestly large group of prims (I used a little over 100 cubes for the test)

2. Either select them all and edit as-is or link them first; Either way you will want to be editing them all at once for the remainder of Steps To Reproduce

3. Apply diffuse, normal, and specular textures to the whole group
    a. Diffuse will probably apply with little to no issues; if not, apply the texture again until the "Multiple" indicator in the texture preview box no longer shows.

    b. Normal and Specular will probably not apply consistently to the prim selection and the "Multiple" indicator will eventually show again. As with Step 3a try to get the "Multiple" indicator to go away by reapplying the same Normal or Specular texture; It will be impossible to do so if the issue is in effect.

NOTE: Sometimes the "Multiple" indicator will appear to go away for a few seconds; but then will show up again (Meaning that some prim faces have reverted resulting in some having your newly applied texture and some going back to the texture it had previously); and sometimes this won't happen until you stop editing the prim group for a few seconds and then start editing it again; but the goal is to consistently get this indicator to NOT show meaning that the textures have been applied to all prim/prim faces successfully.

See attached image for visible symptoms of this issue in action with the indicator and the reverted textures.

It is still possible to edit the prims individually that didn't take the textures and then apply the desired materials as well as their settings and it will usually not give much trouble in this case; But this is not a feasible solution for large builds and can be very difficult to track all the prims down that didn't take the textures properly.
See attached image for visible symptoms of this issue in action
No tags attached.
png 0c190e0fa3bde72e6c11ee485372df43[1].png (566,878) 2017-11-07 19:56
Issue History
2017-11-07 19:56mewtwo0641New Issue
2017-11-07 19:56mewtwo0641File Added: 0c190e0fa3bde72e6c11ee485372df43[1].png
2017-11-07 19:59mewtwo0641Steps to Reproduce Updatedbug_revision_view_page.php?rev_id=6489#r6489
2017-11-07 23:12UbitUmarovNote Added: 0032397
2017-11-07 23:15UbitUmarovNote Added: 0032398
2017-11-07 23:47mewtwo0641Note Added: 0032399
2017-11-13 14:15Gavin HirdNote Added: 0032425
2017-11-13 14:15Gavin HirdNote Edited: 0032425bug_revision_view_page.php?bugnote_id=32425#r6501
2017-11-13 15:31UbitUmarovNote Added: 0032426
2017-11-13 16:11UbitUmarovNote Added: 0032427
2017-11-13 22:16mewtwo0641Note Added: 0032429
2017-11-13 23:15Gavin HirdNote Added: 0032430
2017-11-14 00:28mewtwo0641Note Added: 0032431
2017-11-14 00:34Gavin HirdNote Added: 0032432
2017-11-14 00:51mewtwo0641Note Added: 0032433
2017-11-14 01:32Gavin HirdNote Added: 0032434
2020-05-27 04:14mewtwo0641Note Added: 0036516
2020-05-27 04:14mewtwo0641Statusnew => resolved
2020-05-27 04:14mewtwo0641Fixed in Version => master (dev code)
2020-05-27 04:14mewtwo0641Resolutionopen => fixed
2020-05-27 04:14mewtwo0641Assigned To => mewtwo0641

2017-11-07 23:12   
Recovered on master something I did lost on that change.
In my tests I do see them change.. slowly, and in a different way according with viewer.
Singulary 1.8.6 does like diffuse... shows "multiple" until all changed. (with apply now checked)
Firestorm 5.?? shows then very fast as soon we select, but when we deselect the objects by clicking elsewhere, most revert and then change back to the new selection. If we select back during this, "multiple" is displayed until all done. Once done they stay.
this tests where done on a 256 prims linkset. With a few prims all looks normal.
2017-11-07 23:15   
those error messages are the viewer actually sending the changes.. slowly...
2017-11-07 23:47   
I was testing the issue on Singularity Viewer and would notice that prior to the issue appearing that materials would more or less apply to all prims instantly, then some would revert back for a second, and then a couple seconds later the newly selected texture would come back all at once. Firestorm would do the same thing except the newly selected textures would come back one prim at a time, really slowly. When the issue was introduced the textures would just revert back and the new texture selection would never apply to random prims slowly or not.

I gave commit 8eb9bc a try and it seems like it's fixed now; or at least I can re-apply the materials now until it decides to "stick" (As was previous behavior).

Thank you!
Gavin Hird   
2017-11-13 14:15   
I tested this commit [^]

and the result was that llSetPrimitiveParam failed to apply full bright and color changes to faces on a mesh or primitive. So you probably need to test this a bit more.

One of the items that failed to update it's texture also is Kayaker Magic's PayPal vendor where the texture displaying the price no longer would update.

2017-11-13 15:31   
did this llSetPrimitiveParam started now, or was there already on 0.9?
bc does not seem related to this last code changes
2017-11-13 16:11   
tested with this script on a BOX
and seems fine ????

integer glowon;
        llSay(0, "Script running");
        glowon = 0;
    touch_start(integer nn)
        if(glowon == 0)
// llSetPrimitiveParams([PRIM_GLOW,ALL_SIDES,0.2]);
            glowon = 1;
            glowon = 0;
2017-11-13 22:16   
@Gavin - I can't seem to reproduce the issue you are speaking of with either llSetPrimitiveParams or llSetLinkPrimitiveParams(Fast)

Can you post the script that causes it to exhibit this behavior?


I am using this script to test it with in a linkset of 100 or so prims:

integer toggle = FALSE;

    touch_start(integer num)
        toggle = !toggle;
                PRIM_TEXTURE, ALL_SIDES, TEXTURE_BLANK, <1,1,0>, <0,0,0>, 1.0,
                PRIM_GLOW, ALL_SIDES, 0.1,
                PRIM_COLOR, ALL_SIDES, <0.0, 1.0, 0.0>, 0.5,
        else if(!toggle)
                PRIM_TEXTURE, ALL_SIDES, TEXTURE_DEFAULT, <1,1,0>, <0,0,0>, 1.0,
                PRIM_GLOW, ALL_SIDES, 0.0,
                PRIM_COLOR, ALL_SIDES, <1.0, 1.0, 1.0>, 1.0,
Gavin Hird   
2017-11-13 23:15   
The script failed specific to this commit and works again when the commit is reverted.

Initially I suspected the failure to be because of reverting MAINT-4773 [^]

But the scripts also failed on earlier viewer builds as did Kayaker's PayPal vendor.

Obviously I don't have access to Kayaker's scripts as they are no Mod, so he could also be using OSSL to update the texture of the face of that mesh rather than one of the llSetPrimitiveParams variants.

I see your test scripts updates ALL_SIDES, but the ones that failed for me updates a specific face, using statements such as:

2017-11-14 00:28   
I just tried the script you provided but I'm still unable to reproduce the issue even for setting parameters for specific faces. Tested with a single prim and also tested it as part of a link set both with the script in root prim as well as the script not in root prim; Also tested different faces as well.

Also wrote a little color randomizer script to further test setting faces but still was unable to reproduce.


    touch_start(integer num)
        integer i = 0;
        integer numSides = llGetNumberOfSides();
        for(i = 0; i <= numSides; i++)
                PRIM_COLOR, i, <llFrand(1), llFrand(1), llFrand(1)>, 1.0,
                PRIM_FULLBRIGHT, i, TRUE
Gavin Hird   
2017-11-14 00:34   
I see you are on .NET / Windows64, while my regions run on mono. There is a potential difference there...
2017-11-14 00:51   
Ahh that may be. I unfortunately do not have a Mono setup to test this with at the moment.
Gavin Hird   
2017-11-14 01:32   
I manually diffed my SceneObjectPart.cs with the one in the master repository and found that two statements had been placed in a wrong location in the file (but it still compiled).

This is not the first time merges with SourceTree 2.6.x does this, but it is hard to spot.
I see this almost daily with merges for the viewer made with SourceTree placing statements all over. This never happened with pre 2.6 versions. The issue has been reported to Atlassian.

Anyway, all is good now. Sorry about the fuzz!
2020-05-27 04:14   
Have not seen this issue in a while, seems to be fixed