the material texture error bug is real in Naboo

Ask questions about creating worlds, using worlds, etc.
User avatar
Ilan Tochner
Posts: 6503
Joined: Sun Dec 23, 2012 8:44 am
Has thanked: 4942 times
Been thanked: 4454 times
Contact:

Re: the material texture error bug is real in Naboo

Post by Ilan Tochner »

Tess Juel wrote:
Wed Jan 11, 2023 2:15 am
Mike Lorrey wrote:
Tue Jan 10, 2023 9:21 pm
a) the correct texture was already on another material of the neighboring mesh, so you are wrong. It took no time to download it cause it already had it
Ok. You didn't mention that and it makes a difference of course. Even so it must mean the viewer already had the right texture UUID so it can't be purely a server side issue.
To be specific the viewer had the mesh properly configured with a reference to a texture UUID that it had already downloaded from the server and cached with the correct asset UUID but for whatever reason only displayed on a different rezzed object that references that same asset UUID. Then, when the first object was touched and released the viewer switched to displaying that texture on the mesh which it could immediately do without needing to download the texture from the server because the asset was already present in its cache. In other words, the viewer had already gotten everything it needed to properly display the mesh from our system but didn't do so until Mike touched/released the object.
User avatar
Mike Lorrey
Posts: 361
Joined: Sun Sep 04, 2016 5:40 pm
Has thanked: 71 times
Been thanked: 269 times

Re: the material texture error bug is real in Naboo

Post by Mike Lorrey »

Tess Juel wrote:
Wed Jan 11, 2023 2:15 am
Mike Lorrey wrote:
Tue Jan 10, 2023 9:21 pm
a) the correct texture was already on another material of the neighboring mesh, so you are wrong. It took no time to download it cause it already had it
Ok. You didn't mention that and it makes a difference of course. Even so it must mean the viewer already had the right texture UUID so it can't be purely a server side issue.

I've seen something similar before so I can at least confirm that such a weird bug is possible. That was on a different grid running the very first distribution of opensim 0.9. What happened then was that the meshed showed up with the right testures but nest time I went to the sim, face 7 had swtiched to a texture used by another face of the same mesh. Clicking on the object didn't solve the issue then and the bug did not show up in everybody's viewer. Unfortunately we never figured out what was happening back then.
I have consistently had disputes with Ilan claiming that bugs dont exist when I show clearly that they do with photographic evidence. For instance, he claimed Kitely used the standard installation of Bulletsim physics, yet Kitely sims set to bullet had this unique bug that existed ON NO OTHER GRID IN OPENSIM that used bullet, that if you hollowed a prim, you could not stand in the hollow until after the region had restarted, and if you edited the prim, the hollow's physics would become solid again until the next reset. Ilan kept denying that it was real when I showed it to him personally and showed how it worked properly on other grids that were in fact using the standard opensim install with bulletsim. He tried then to blame it on my viewer, but he was using the same viewer, that somehow behaved differently on all other grids other than Kitely.

This is the type of gaslighting behavior that is the norm from Ilan, and why probably half of the people I've met in Kitely since I joined in 2016 are now on other grids, or started their own grids.

Fortunately we dont have to use bullet anymore, but for years these sort of bugs and Ilans refusal to fix the real reasons for them that made it impossible to operate a role playing group in Kitely.

Then early last year, I kept trying to bring Ilans attention to a bug that was introduced by the upgrade to 0.9.1.1, where mesh uploads, which previously would create sub-folders in the texture folder for the textures for the materials of the mesh, suddenly started dumping those textures into the main texture folder, quickly overloading the folder and making it impossible to access many textures due to the 1000 item per folder limit in kitely inventory. I had to go back through my inventory and document when the textures started getting dumped in the main folder correlated with the day that kitely upgraded to 0.9.1.1. and before that kitely produced subfolders for mesh upload textures. Until I showed him conclusively he was wrong, he rudely gaslit me, claimed I was hallucinating things, and simply denied. Of course, he never creates mesh himself so he has no clue how his own platform even functions for builders.

Then there were the bugs where you couldn't use the default transparent and blank white textures on normals and speculars, the Kitely Marketplace would reject your use of those textures. Again he denied it was my fault.. etc etc.

In December, when I was uploading the parts for my Victorian Pot Belly Stove, the marketplace claimed there was another illegal texture on my meshes even though they all were uploaded with the collada file by me, and the texture the system claimed was on the mesh did not actually exist on the mesh. I had to remove all textures from all materials on the mesh down to plain plywood and then retexture everything from scratch, to clear out a texture that was never there in the first place.... and of course Ilan gaslit me about it.

These are just the most eggregious cases of rudeness. My annoyance is not unfounded.
User avatar
Mike Lorrey
Posts: 361
Joined: Sun Sep 04, 2016 5:40 pm
Has thanked: 71 times
Been thanked: 269 times

Re: the material texture error bug is real in Naboo

Post by Mike Lorrey »

Ilan Tochner wrote:
Wed Jan 11, 2023 2:36 am
Tess Juel wrote:
Wed Jan 11, 2023 2:15 am
Mike Lorrey wrote:
Tue Jan 10, 2023 9:21 pm
a) the correct texture was already on another material of the neighboring mesh, so you are wrong. It took no time to download it cause it already had it
Ok. You didn't mention that and it makes a difference of course. Even so it must mean the viewer already had the right texture UUID so it can't be purely a server side issue.
To be specific the viewer had the mesh properly configured with a reference to a texture UUID that it had already downloaded from the server and cached with the correct asset UUID but for whatever reason only displayed on a different rezzed object that references that same asset UUID. Then, when the first object was touched and released the viewer switched to displaying that texture on the mesh which it could immediately do without needing to download the texture from the server because the asset was already present in its cache. In other words, the viewer had already gotten everything it needed to properly display the mesh from our system but didn't do so until Mike touched/released the object.
That speaker grill texture WAS NEVER ON THAT MATERIAL. You lie.
User avatar
Tess Juel
Posts: 267
Joined: Sun Sep 11, 2016 4:24 pm
Has thanked: 249 times
Been thanked: 438 times

Re: the material texture error bug is real in Naboo

Post by Tess Juel »

Mike Lorrey wrote:
Wed Jan 11, 2023 4:02 am
You lie.
Whenever I feel like posting something like that - or something in all capital letters - at an internet forum, I usually go for a walk and enjoy some RL first. When I return, I've found a more diplomatic or sometimes more toxic way to put it.
These users thanked the author Tess Juel for the post:
Chris Namaste
User avatar
Mike Lorrey
Posts: 361
Joined: Sun Sep 04, 2016 5:40 pm
Has thanked: 71 times
Been thanked: 269 times

Re: the material texture error bug is real in Naboo

Post by Mike Lorrey »

Ilan Tochner wrote:
Wed Jan 11, 2023 2:36 am
Tess Juel wrote:
Wed Jan 11, 2023 2:15 am
Mike Lorrey wrote:
Tue Jan 10, 2023 9:21 pm
a) the correct texture was already on another material of the neighboring mesh, so you are wrong. It took no time to download it cause it already had it
Ok. You didn't mention that and it makes a difference of course. Even so it must mean the viewer already had the right texture UUID so it can't be purely a server side issue.
To be specific the viewer had the mesh properly configured with a reference to a texture UUID that it had already downloaded from the server and cached with the correct asset UUID but for whatever reason only displayed on a different rezzed object that references that same asset UUID. Then, when the first object was touched and released the viewer switched to displaying that texture on the mesh which it could immediately do without needing to download the texture from the server because the asset was already present in its cache. In other words, the viewer had already gotten everything it needed to properly display the mesh from our system but didn't do so until Mike touched/released the object.
Annnnnd the other shoe drops. I had Karima Hoisan come to SPACE FORCE region to look at this Dejarik chair and tell me what she sees. She sees the speaker grill texture on the wrong material just like I do. SO IT ISN'T MY VIEWER. ITS YOUR ASSET SYSTEM. FIX IT.

This snapshot was taken by her this evening.
Snapshot _ Space Force Sandbox, SPACE FORCE (216, 360, 24) - Ge.png
Snapshot _ Space Force Sandbox, SPACE FORCE (216, 360, 24) - Ge.png (371.76 KiB) Viewed 9495 times
User avatar
Ilan Tochner
Posts: 6503
Joined: Sun Dec 23, 2012 8:44 am
Has thanked: 4942 times
Been thanked: 4454 times
Contact:

Re: the material texture error bug is real in Naboo

Post by Ilan Tochner »

Mike, OpenSim is an evolving open-source platform, the nature of bugs on each grid depends on which version it uses and which additional OpenSim patches it applied (from OpenSim dev branch or its own). Kitely may have issues that were patched after we rolled out our latest system update and other grids have issues we already created propriety patches for.

Regarding your specific complaints:

BulletSim had various issues that were patched over the years. Some of them included the hollow problem you mentioned. Then, as in the many other times when you complained about issues, I asked you for details and took steps to create a fix when we determined the problem was on our end. You, however, fail to mention that the great majority of times that you complained about things the problem was not with Kitely itself. It was either a known OpenSim issue that existed with the OpenSim version we were using, a problem with the viewer you were using or a change that was intentionally made by OpenSim that was incorporated into Kitely when we upgraded to that OpenSim version. For those who weren't here when we upgraded, I'll just link to this Kitely forums thread that discusses our efforts to fix various issues that we found following our last major OpenSim version update: viewtopic.php?f=12&t=5379

The issue you mentioned about where the material textures are stored when importing meshes was created when we upgraded to OpenSim 0.9.1.1 because that is the code that is included in that OpenSim release. You asked for our previous code to be patched into our updated system and we did so, as can be attested by the people who were part of the Kitely Community meetings where this issue was discussed. As for the inventory limit per folder, those reading this forums thread should read: viewtopic.php?f=9&t=1050.

Issues relating to missing assets that are reported by Kitely Market have to deal with the data that is stored by OpenSim. In the particular case you've mentioned, you complained, we said we'd fix it the following day when we recognized that our system wasn't whitelisting some asset UUIDs that are included as part of OpenSim, and we developed a fix for this problem less than two weeks later. As for some of the other issues you've had with your listed items being flagged with listing errors due to missing assets, I suggest you reread the forums thread where we discussed these issues. Your recollection of how I handled your complaints, the explanation I gave you for what caused the issue and how that explanation enabled you to fix the problem may need some refreshing. Both these issues are included in this forums thread: viewtopic.php?p=21403

I believe that people reading those forums threads will see how each of us acted when you filed complaints and how the issues were eventually resolved. I believe most people will agree that I took your complaints seriously and that I wasn't being rude to you, even when confronted with your choice of language when you blamed us for issues that were not our fault.
These users thanked the author Ilan Tochner for the post:
Shandon Loring
User avatar
Ilan Tochner
Posts: 6503
Joined: Sun Dec 23, 2012 8:44 am
Has thanked: 4942 times
Been thanked: 4454 times
Contact:

Re: the material texture error bug is real in Naboo

Post by Ilan Tochner »

Mike Lorrey wrote:
Wed Jan 11, 2023 4:30 am
Annnnnd the other shoe drops. I had Karima Hoisan come to SPACE FORCE region to look at this Dejarik chair and tell me what she sees. She sees the speaker grill texture on the wrong material just like I do. SO IT ISN'T MY VIEWER. ITS YOUR ASSET SYSTEM. FIX IT.
Both you and Karima are now using Firestorm-Releasex64 6.6.3.67470 and it's therefor to be expected that barring networking issues and cache status differences you should both be seeing the same thing. In other words, the viewer issue that is causing you rendering problems is also causing her the same problems. A good test would be for you to click the object inworld to cause the texture to be properly rezzed in your viewer then see if this change also happens in her viewer without her touching the object. If it is then your touching the object causes some message to be sent from your viewer to OpenSim and from OpenSim to her viewer and that message causes her viewer to then properly display the texture. That won't mean that the issue isn't with the viewer (it should be rendering the object properly without this supposed message) but it would give us a strong indication that the rendering issue is not localized to each user's viewer. Are you able to run this test?
User avatar
Mike Lorrey
Posts: 361
Joined: Sun Sep 04, 2016 5:40 pm
Has thanked: 71 times
Been thanked: 269 times

Re: the material texture error bug is real in Naboo

Post by Mike Lorrey »

Ilan Tochner wrote:
Wed Jan 11, 2023 5:37 am
Mike Lorrey wrote:
Wed Jan 11, 2023 4:30 am
Annnnnd the other shoe drops. I had Karima Hoisan come to SPACE FORCE region to look at this Dejarik chair and tell me what she sees. She sees the speaker grill texture on the wrong material just like I do. SO IT ISN'T MY VIEWER. ITS YOUR ASSET SYSTEM. FIX IT.
Both you and Karima are now using Firestorm-Releasex64 6.6.3.67470 and it's therefor to be expected that barring networking issues and cache status differences you should both be seeing the same thing. In other words, the viewer issue that is causing you rendering problems is also causing her the same problems. A good test would be for you to click the object inworld to cause the texture to be properly rezzed in your viewer then see if this change also happens in her viewer without her touching the object. If it is then your touching the object causes some message to be sent from your viewer to OpenSim and from OpenSim to her viewer and that message causes her viewer to then properly display the texture. That won't mean that the issue isn't with the viewer (it should be rendering the object properly without this supposed message) but it would give us a strong indication that the rendering issue is not localized to each user's viewer. Are you able to run this test?
See, here is where you are contradicting yourself: this mesh I rezzed in SPACE FORCE was the copy I took in Naboo that clicked back to the original proper texture in Naboo. When I rezzed the copy in SPACE FORCE, it had the proper texture on it. I left the region so it would have to restart, i.e. it would have to load all the assets FROM THE ASSET SERVER. It was ONLY WHEN I RETURNED TO A REBOOTED SIM that the wrong texture appeared on the wrong material. I had literally looked at that mesh 5 minutes previously, SAME VIEWER LOGIN SESSION, with the proper texture on it. The only thing that changed was that the mesh was reloaded FROM THE ASSET SERVER when the region rebooted when I returned to it. The cache in my viewer had last seen that mesh five minutes earlier with the proper texture on it. This is NOT a viewer problem, and now we see its not a region problem. IT IS AN ASSET SERVER PROBLEM..

The real problem here is that you have Oren working on your Project X, to the detriment of your customers in Kitely. You dont want to distract him from working on that, so you are making excuses and gaslighting your customers and disregarding the truth they are trying to tell you about the problems they are having, and you are LOSING CUSTOMERS because of how you are behaving, rather than doing your responsibility, doing your duty, to actually have Oren troubleshoot this problem and figure out why the asset server is delivering buggy content to region boot-ups.
User avatar
Ilan Tochner
Posts: 6503
Joined: Sun Dec 23, 2012 8:44 am
Has thanked: 4942 times
Been thanked: 4454 times
Contact:

Re: the material texture error bug is real in Naboo

Post by Ilan Tochner »

Mike, I consulted with Oren about this and you have a misunderstanding about how the viewer works. The way it works when it connects to a server is (I'm leaving out parts that are irrelevant to object rezzing and simplifying some of the steps):

1) Query OpenSim for a list of the objects that are rezzed in the sim (i.e. the list of objects in the scene).

2) The list the viewer gets includes objects and the assets they reference (using asset UUIDs). Those assets can include meshes, textures, etc.

3) The viewer then goes over the list of assets and checks which assets are not already in its cache. It then starts requesting those assets that it doesn't already have from the asset server (it does this in stages as some assets have LODs that are downloaded separately).

4) Once the viewer has downloaded the minimum LOD levels it needs to render a certain object it uses them to rezz that object while it continues to download higher LODs for those assets.

The viewer uses the Viewer Object Cache mechanism that Second Life developed, that is included in Firestorm and that Ubit added support for in OpenSim. It is quite complicated and involves a viewer-server protocol that has bugs in OpenSim 0.9.1.1 and the viewer. We were forced to disable the server-side part of this cache on Kitely (it's an OpenSim.ini setting: "SceneObjectGroup.IsViewerCachable") to overcome some of the bugs we found that we couldn't fix without making changes to the viewer (see: viewtopic.php?p=26884). The memory-based parts of the Viewer Object Cache mechanism are only valid for the current session and uses time-to-live information to decide when the viewer needs to check the object again even in the current session. The memory-based parts of this cache are cleared when you close your viewer but there is a separate disk-based cache where the viewer stores the assets that the objects reference and the viewer object cache itself may have a disk component as well (it's been years since we looked at that viewer code).

Now let's look at the scenario in your last comment:

1) You entered SPACE FORCE and the viewer got the object information from the object that includes the mesh and the textures it references from our server. It's possible it got them from the Viewer Object Cache instead of contacting our server again if you rezzed the object in SPACE FORCE in the same session you got it from Naboo or within the same hour (I'm not sure about the details as the last time we looked at the viewer code to try to debug issues with this cache was years ago and it's likely this mechanism has been updated since then).

2) Your viewer then loaded the asset files that belong to the assets that this object references from the viewer disk cache that had already stored them during your visit to Naboo. Note that the viewer didn't need to contact our assets system again to do so. As it had the object and the assets data it needed it could render the object without doing so.

3) The next time you visited SPACE FORCE after you restarted your world the viewer needed to contact our server again to get the object information but not the asset data (that remained stored in your viewer cache). However, it didn't use the information that it got from the server to render the object properly. Only after you interacted with the object again did the viewer change what it rendered. Oren's guess is that the problem is similar to the one we encountered years ago where the viewer "forgot" object properties until it was forced to "remember" them after receiving an ImprovedTerseObjectUpdate packet from the server that caused it to update its internal object cache.

This is a viewer bug Mike. A bug that is possibly effected by how OpenSim implemented the Viewer Object Cache mechanism protocol. A mechanism which we disable on Kitely using a standard OpenSim.ini setting to eliminate the various issues that it creates in OpenSim 0.9.1.1.

As a last note, I've now spent hours dealing with your complaints in this forums thread. I've addressed all your complaints with detailed information and without delay and you continued to throw accusations my way about how bad I'm supposedly treating you or how I'm oblivious to our customers' concerns. That's uncalled for and isn't helping your cause. We're not going to debug viewer code again, the solution lays with Firestorm devs. If they ask us for it, I can give Beq our findings from our investigation of similar issues when we upgraded to OpenSim 0.9.1.1.
These users thanked the author Ilan Tochner for the post:
Ada Radius
User avatar
Mike Lorrey
Posts: 361
Joined: Sun Sep 04, 2016 5:40 pm
Has thanked: 71 times
Been thanked: 269 times

Re: the material texture error bug is real in Naboo

Post by Mike Lorrey »

Ilan Tochner wrote:
Wed Jan 11, 2023 4:06 pm
Mike, I consulted with Oren about this and you have a misunderstanding about how the viewer works. The way it works when it connects to a server is (I'm leaving out parts that are irrelevant to object rezzing and simplifying some of the steps):

1) Query OpenSim for a list of the objects that are rezzed in the sim (i.e. the list of objects in the scene).

2) The list the viewer gets includes objects and the assets they reference (using asset UUIDs). Those assets can include meshes, textures, etc.

3) The viewer then goes over the list of assets and checks which assets are not already in its cache. It then starts requesting those assets that it doesn't already have from the asset server (it does this in stages as some assets have LODs that are downloaded separately).

4) Once the viewer has downloaded the minimum LOD levels it needs to render a certain object it uses them to rezz that object while it continues to download higher LODs for those assets.

The viewer uses the Viewer Object Cache mechanism that Second Life developed, that is included in Firestorm and that Ubit added support for in OpenSim. It is quite complicated and involves a viewer-server protocol that has bugs in OpenSim 0.9.1.1 and the viewer. We were forced to disable the server-side part of this cache on Kitely (it's an OpenSim.ini setting: "SceneObjectGroup.IsViewerCachable") to overcome some of the bugs we found that we couldn't fix without making changes to the viewer (see: viewtopic.php?p=26884). The memory-based parts of the Viewer Object Cache mechanism are only valid for the current session and uses time-to-live information to decide when the viewer needs to check the object again even in the current session. The memory-based parts of this cache are cleared when you close your viewer but there is a separate disk-based cache where the viewer stores the assets that the objects reference and the viewer object cache itself may have a disk component as well (it's been years since we looked at that viewer code).

Now let's look at the scenario in your last comment:

1) You entered SPACE FORCE and the viewer got the object information from the object that includes the mesh and the textures it references from our server. It's possible it got them from the Viewer Object Cache instead of contacting our server again if you rezzed the object in SPACE FORCE in the same session you got it from Naboo or within the same hour (I'm not sure about the details as the last time we looked at the viewer code to try to debug issues with this cache was years ago and it's likely this mechanism has been updated since then).

2) Your viewer then loaded the asset files that belong to the assets that this object references from the viewer disk cache that had already stored them during your visit to Naboo. Note that the viewer didn't need to contact our assets system again to do so. As it had the object and the assets data it needed it could render the object without doing so.

3) The next time you visited SPACE FORCE after you restarted your world the viewer needed to contact our server again to get the object information but not the asset data (that remained stored in your viewer cache). However, it didn't use the information that it got from the server to render the object properly. Only after you interacted with the object again did the viewer change what it rendered. Oren's guess is that the problem is similar to the one we encountered years ago where the viewer "forgot" object properties until it was forced to "remember" them after receiving an ImprovedTerseObjectUpdate packet from the server that caused it to update its internal object cache.

This is a viewer bug Mike. A bug that is possibly effected by how OpenSim implemented the Viewer Object Cache mechanism protocol. A mechanism which we disable on Kitely using a standard OpenSim.ini setting to eliminate the various issues that it creates in OpenSim 0.9.1.1.

As a last note, I've now spent hours dealing with your complaints in this forums thread. I've addressed all your complaints with detailed information and without delay and you continued to throw accusations my way about how bad I'm supposedly treating you or how I'm oblivious to our customers' concerns. That's uncalled for and isn't helping your cause. We're not going to debug viewer code again, the solution lays with Firestorm devs. If they ask us for it, I can give Beq our findings from our investigation of similar issues when we upgraded to OpenSim 0.9.1.1.
Ok you have this sequence wrong. Firstly, my cache was clear.

1) When I rezzed the object in SPACE FORCE (after taking it as a copy from Naboo, at which time the texture snapped to the right texture somehow from the wrong texture), the object had the RIGHT texture on the material in question. So when the object rezzed it should have, and did, rez it with the right texture as was the case on the object when I left Naboo.
2) I then went home, which is another point in naboo, 2000 meters away from where the original object is, so the viewer would not have rezzed it even if the original object had reverted to the wrong texture at that point.
3) I waited 5 minutes, and returned to SPACE FORCE to find the object I had rezzed there had reverted to the wrong texture.
4) I IMd Koshari, who had never seen this object in SPACE FORCE before. She came and saw the object identical to what I saw. If this was a bug with my viewer, she should not have seen what I saw. Furthermore, if you are going to blame the 6.6 version viewer we were both using, you have a problem because you originally told me that the bug was with my 6.4 viewer version and said it was buggy and causing this problem, I had upgraded and cleared cache and the bug was still here, which is why I got Koshari to verify that she's seeing the same thing.

I cannot imagine how you can continue to squirm and blame multiple peoples computers for this problem where the only common nexus in the whole thing is the asset server. Not the same viewers, not the same regions, only the asset server is the common factor. This is how you trouble shoot problems. I get you are heavily invested in your server and you don't want to actually put time into fixing a bug and admit its buggy, but really, Ilan, your asset server is the best thing you have to market Kitely about and you aren't interested in fixing it? You'd rather lose customers instead? If you gaslight people you think they'll shut up and just keep paying? Why would people stay if they cannot trust the asset system to not destroy their property? It is already bad enough that you won't upgrade the scripting engine, which cause scripted devices we need to use across the hypergrid to lose their scripts. Your mismanagement is destroying peoples property.
Post Reply