Tweet
Hi,
Let me quickly explain what the issue actually is (was).
When a model is opened, V-Ray awaits OnEndOpenDocument() event to fire and then makes some important work to the scene (like migrations, etc). One particular task that needs to be done is material sync. That is Synchronizing material definitions between the V-Ray scene and the Rhino model.
However at the point of OnEndOpenDocument event, Rhino hasn't even started loading the rendering materials. So there is nothing to sync, it is guaranteed there are exactly 0 Rhino materials at that point. At some point Rhino RDKDocument starts loading the materials, but it never tells when it is finished. There is no OnEndLoadMaterials() event whatsoever. Furthermore McNeel has always refused to add such an event, despite all our requests.
So we had to invent some other mechanism to detect when the material table is ready for use. There are two ways. The RDK timer, and the OnIdle message.
The RDK timer is the natural choice. After all the RDK is the plugin that handles all that material stuff, so we put our syncing code there. The timer itself is just a simple callback-based timer that fires every 300ms.Since it fires on the main thread, it will not fire if the main thread is busy loading the materials. So far so good. However something changed in Rhino 7.20-ish. If you double click a file, the timer will fire right after OnEndOpenDocument and before a single material is read. If you used drag&drop or recent files menu, the timer fires somewhere in between the process of reading the materials.
Why that happens - I can speculate for the reason - probably they made something multithreaded. Or the RDK plugin got loaded after V-Ray plugin, and the events are served in the order of loading.. I don't know. Nevertheless, at that point everyone got a "disconnected" or "orphaned' materials problem.
So what we did first is to remove the auto-deletion. So people don't loose materials, but see a message box. At that point we're unsure of what causes the issue, because some users report that they actually opened their models without V-Ray and changed/deleted materials - hence the messages.
Things got quite a lot clearer, when we started experimenting with heavier scenes, where Rhino takes longer to read the materials, and the timer could potentially fire multiple times.
So we did another attempt to fix the world, by moving the syncing code out of the RDK timer and into the OnIdle message. The OnIdle event comes from the operating system. It basically says the application has no job to do, and awaits user input (like moving your mouse pointer). So the assumption is if the app does nothing, it has loaded the materials. This solution seem much more stable, and that is what we have in 6.00.02 onwards.
McNeel developers, argued that none of the two approaches are good and robust, but there is almost nothing to be done. They still refuse to add a dedicated end loading event, but took another action instead - the RDK plugin will be served first, always. In theory this means that at OnEndOpenDocument() event, the RDK plugin should have already loaded the material table. And when the RDK timer fires for the first time, the material table will be already good to use.
We're not going to move the syncing from the OnIdle message back to the RDK time, though, no matter what McNeel do with the RDK plugin.
Let me quickly explain what the issue actually is (was).
When a model is opened, V-Ray awaits OnEndOpenDocument() event to fire and then makes some important work to the scene (like migrations, etc). One particular task that needs to be done is material sync. That is Synchronizing material definitions between the V-Ray scene and the Rhino model.
However at the point of OnEndOpenDocument event, Rhino hasn't even started loading the rendering materials. So there is nothing to sync, it is guaranteed there are exactly 0 Rhino materials at that point. At some point Rhino RDKDocument starts loading the materials, but it never tells when it is finished. There is no OnEndLoadMaterials() event whatsoever. Furthermore McNeel has always refused to add such an event, despite all our requests.
So we had to invent some other mechanism to detect when the material table is ready for use. There are two ways. The RDK timer, and the OnIdle message.
The RDK timer is the natural choice. After all the RDK is the plugin that handles all that material stuff, so we put our syncing code there. The timer itself is just a simple callback-based timer that fires every 300ms.Since it fires on the main thread, it will not fire if the main thread is busy loading the materials. So far so good. However something changed in Rhino 7.20-ish. If you double click a file, the timer will fire right after OnEndOpenDocument and before a single material is read. If you used drag&drop or recent files menu, the timer fires somewhere in between the process of reading the materials.
Why that happens - I can speculate for the reason - probably they made something multithreaded. Or the RDK plugin got loaded after V-Ray plugin, and the events are served in the order of loading.. I don't know. Nevertheless, at that point everyone got a "disconnected" or "orphaned' materials problem.
So what we did first is to remove the auto-deletion. So people don't loose materials, but see a message box. At that point we're unsure of what causes the issue, because some users report that they actually opened their models without V-Ray and changed/deleted materials - hence the messages.
Things got quite a lot clearer, when we started experimenting with heavier scenes, where Rhino takes longer to read the materials, and the timer could potentially fire multiple times.
So we did another attempt to fix the world, by moving the syncing code out of the RDK timer and into the OnIdle message. The OnIdle event comes from the operating system. It basically says the application has no job to do, and awaits user input (like moving your mouse pointer). So the assumption is if the app does nothing, it has loaded the materials. This solution seem much more stable, and that is what we have in 6.00.02 onwards.
McNeel developers, argued that none of the two approaches are good and robust, but there is almost nothing to be done. They still refuse to add a dedicated end loading event, but took another action instead - the RDK plugin will be served first, always. In theory this means that at OnEndOpenDocument() event, the RDK plugin should have already loaded the material table. And when the RDK timer fires for the first time, the material table will be already good to use.
We're not going to move the syncing from the OnIdle message back to the RDK time, though, no matter what McNeel do with the RDK plugin.
Comment