Just adding a note here that with this particular bug, it isn't possible to create a working Unity player. I'm available to perform any/all troubleshooting necessary to resolve this issue, as it is a release blocker. Thanks.

The original issue w/ detail is here: https://www.noesisengine.com/bugs/view.php?id=2453

I tried a fresh Unity build but that did not work. This is happening in Unity 2022.2.1f1.

Is this using D3D12?

Initialize engine version: 2022.2.1f1 (4fead5835099)
Direct3D:
Version: Direct3D 11.0 [level 11.1]
Renderer: NVIDIA GeForce RTX 4080 (ID=0x2704)
Vendor: NVIDIA
VRAM: 16064 MB
Driver: 31.0.15.2802

I think this raises an important question -- what is it that I am doing that is different, even potentially incorrect compared to other Noesis users?

1. Is it specific to Unity version, meaning that other Noesis users have not released a build using Unity 2022.2.x or later?
2. Is it due to the quantity and type of images I am referencing in my image resource dictionaries?
3. Is it a Unity bug that manifests rarely?

Jesus, should I run the scirpt the looks for texture pointer changes again, and have it dump to the log file within a build executable?

So far, I don't know why this is happening on your project and not in others projects.

I have been testing different scenarios today, I am unable to break anything (even using hundreds of textures).

So, first thing we need to do is making sure we are in the same scenario as 0002453, so yes, please, run the script to search for pointer changes and let's focus in one texture only for now.

Are you using more plugins that could interfering with us?

I'm not aware of any plugins that might affect texture handles. I'll run the previous script and report back here.

I'm working on this right now and I have some questions that might help me better identify a cause.

• When is the texture memory address assigned? i.e. is this a real memory address that is assigned upon load to GPU memory, or is this a Unity handle assigned on import?
• If the address is loaded incorrectly from the start, would I be able to detect a change?
• These textures currently exist in a folder within assets. They are not in \Resources, and they are not part of an asset bundle. Is this OK?
• Is there a way to get the texture handle from a Noesis ImageSource? This would let me cycle through all textures used in the UI and scan for handle changes.

The texture pointer does not appear to be changed -- but incorrect textures are shown. i.e. instead of a weapon I see a player's hat as a rectangle's image source.

Is there a way to reliably iterate through the resources in a resource dictionary?

Your answers to these questions will definitely help me out. In the interim, I am going to send over a stripped down project.

OK, the problem only manifests when images are created within a visual tree containing a top-level ViewBox which is programmatically sized. Still researching.

This is likely not a Unity pointer issue. I think it is related to Noesis pointer arithmetic and how images (and underlying textures) are displayed in a visual tree with a transformation matrix.

My reproduction workflow is to have a visual tree with the following:

NoesisView -> UserControl -> ViewBox -> CustomUserControl -> WrapPanel -> { 100 Rectangles }

• CustomUserControl sets its width/height based on a desired size and scaling ratio. I don't use Noesis scaling because it wasn't available when I built my UI.
• If the rectangles have no brush set the compiled binary does NOT crash
• If the rectangles are assigned textures the compiled binary DOES crash. This occurs in the editor, sometimes. However, it is consistent in binaries.
• It appears that if the wrap panel does not exceed a certain dimension a crash does not occur.

** edit. This is not it. I have no idea why it selectively fails.

Thanks for the time creating this repro!

Were you able to reproduce the behavior with the test project?

It appears that disabling mipmap generation stops texture commingling and crashes.

We have been extremely busy with 3.2 Beta2 (planned for releasing today).

After that, we will start testing your project.

Thanks for your patience

I'm working on your repro project, building the player with our library in debug.
Let's see if this provides some useful info.

I'll keep you informed.