Material.SetTexture - Access Violation Exception [UrhoSharp]

We are using UrhoSharp, and are wanting to toggle the Texture of the material to toggle between two images – Normal and Bold.

The first time we toggle the image, it works. The 2nd time, it throws an “AccessViolationError”.

It’s acting as though it’s disposing the Texture that gets replaced, so that we can’t set that Texture again. We aren’t disposing of anything and are holding a reference to both textures, and not releasing the references.

Is there some sort of auto-dispose that occurs in Urho when you swap textures (i.e. if the previous texture is non-null, then maybe it calls Dispose()?).

I had a similar issue with managing off-screen render buffers in Lua. Even when creating the texture with :new() function it would still delete the texture anyway once I assign it to anything and that thing gets removed.

Form what I know Urho3d manages memory using the Scene so if you want to be absolutely sure, it might be worth it to create hidden nodes and give it the texture you want to use.

1 Like

Sounds like a situation where you’ll want to use SharedPtrs to keep the texture alive.

1 Like

Avagrande, thank you, this worked for me. So for cases where I need to swap the textures, I need to make sure that some node in the scene keeps a reference to the texture, and that prevents it from being disposed.

Note - I think Modanung’s solution (SharedPtr) should also work – except UrhoSharp does not expose the SharedPtr class, so I am unable to use it.

Is it impossible to switch to Urho3D?

Modanung - yes, we are unable to switch. Our project is being developed using Xamarin and XAML forms for 3 platforms, all in C#. UrhoSharp is currently the only recommended OpenGL graphics engine recommended for Xamarin Forms. That’s why we are here.

Here we recommend Urho3D.

Yeah, but Xamarin Forms apps MUST use UrhoSharp, not Urho3D.

Does Urho3D itself support C# programming? (where your app can be fully .NET/C# which uses Urho3D for it’s rendering) My understanding is that any C#/.NET app really needs to use UrhoSharp as well.

The issue is that you’re using this forum as a support forum for a product that is not from here, that is apparently obsolete and abandoned, and that most of the users here are not that familiar with. For example, this question. SharedPtrs are the means by which Urho3D manages the lifetime of resources. They’re used internally, and they’re intended to be used by the user. Had you been using SharedPtr, this question never would have needed to be asked, and the answer to this question has nothing at all to do with Urho3D itself, and everything to do with UrhoSharp not correctly exposing the basic lifetime-management tools that Urho3D employs. It’s annoying to have the forums cluttered with issues and problems that are not relevant to Urho3D.


JTippetts1 - UrhoSharp may be updated in the future. Currently it’s the ONLY recommendation for Xamarin Forms for 3D graphics rendering support. Egorbo made sure it works, and it does work.

So there are a number of people likely in my boat - as Xamarin Forms is quite mainstream, especially for those who want to write C#/.NET apps for all 3 main platforms – Windows, Android, and iOS.

So for these users, it’s good for them to know the “Urhosharp version of the solution”.

I hope this forum will continue to support me on this. I think these answers will be helpful to others, and in the end, may drive some fixes and a re-release of UrhoSharp.

This thread is off-topic.

Try to get support from the people you are listening to, or listen to the people you are getting support from.

Instead of shutting the door for all the UrhoSharp related topics, I am considering creating another category for UrhoSharp in the forum so that people can segregate the topics easily. A topic will only get the responses from the community on best effort basis anyway. Having a separate category does not change anything else.

My only concern is the “amount of traffic” it would generate. As long as it does not exceed (from the past historical trend it should not) the quota of our free Discourse account then I am OK with it.


Maybe Xamarin should open their door instead?

…oh they have, but there’s nobody home?

Or will you track UrhoSharp issues too? Nobody here is going to provide “full support”, and I don’t think we should create categories that suggest we do.

The purpose of the category is to, well, just to put the topics in the respective category. We don’t claim to provide support either way.

Frankly speaking I need the traffic, just not that much. Some of their issues are Urho3D issues too, not all of course.

It doesn’t take a claim to allude to a suggestion.

I disagree. We also don’t claim we provide full support of Urho3D for free.

True… furthermore “we” doesn’t speak. “We” does not exist, really.

Well, except I am the owner of the domain. So, I could say “we” to indicate I have the authority and final say here.

If you still want to discuss this further, I suggest you open a separate topic and invite all the members of the staff to discuss. Thanks.

Yes, but if this domain turns totalitarian, it’s time to move.