Unity integration & delay on closing renderer

[andrew_mcnab]

Hi, I am not too clear on what the SDK does when rendering in terms of threading & background processes but I notice on the C# examples they have a big delay before closing, when you click to close the window - any explanation on what is still running and not immediately closing there? Seems like the renderer being disposed is far from the end of it.

I was trying to use the SDK in Unity which works with most .net dlls but I think the background processes created here lead to problems there as I have crashes and program hangs on exit.
Understanding the above might enable a quick shutdown of vray on exit or else perhaps someone in your team has tried Unity integration?

[stanislav.kirilov]

Hi Andrew,

"when you click to close the window" - what does that mean? Do you handle the VFBClose event and call VRayRenderer.Dispose() there? This is dangerous and it will indeed schedule the actual closing asynchronously sometime later. You should notify your main (or some other) thread and call Dispose() from there instead.

(The above scenario does not apply to Node.js where the user code is always executed in the main thread and the callback thread is always unblocked when .close() is called.)

Each VRayRenderer object creates its own callback thread where the events are pushed in a dedicated queue. All events you subscribe to are executed sequentially in that thread. That's why your event handlers should be as fast as possible. And also, that's why you should not close the renderer from that thread. If you try to, well, we'll keep the thread alive for a while and it will close the renderer asynchronously later. (Otherwise, a deadlock would occur.) Probably this is your case. We can think of some way to improve this case in the future but, currently, better just not do it.

You can also try to omit the Dispose() call. All VRayRenderer instances are auto-closed when V-Ray is closed in recent AppSDK versions.

Another thing to have in mind is that although the VRayRenderer is supposed to be thread-safe, it is always better to serialize the calls to it.

Best regards,
Stan

[andrew_mcnab]

Hi Andrew,

"when you click to close the window" - what does that mean? Do you handle the VFBClose event and call VRayRenderer.Dispose() there? This is dangerous and it will indeed schedule the actual closing asynchronously sometime later. You should notify your main (or some other) thread and call Dispose() from there instead.

Sorry to be clear I am talking C# [windows] and this happens just with the included examples - they run in a console window and when you close that there is some delay in it actually closing.

But outside of the SDK examples:
Unity/C# seems to be somewhat incompatible due to this closing down part as the SDK seems to be still closing things [when all threads are terminated perhaps?]. I removed all dispose calls for the renderer but I get a dll error such as:
0x00007FFE662D5944 (VRaySDKLibrary) (function-name not available)
0x00007FFE6631DE0B (VRaySDKLibrary) releaseVector
It may be the way Unity handles threading in any case, it's mono & not strictly .net windows...

Regards
Andy

[stanislav.kirilov]

Weird this is. I can see that we have a small memory leak because we never call the releaseVector() function in .Net. So why it crashes there is a mystery to me. But in spite of that I suspect the issue you have is something very small but I'm not sure how to chase and find it.

Best,
Stan