Hey Nic,
yeah, I also recall that I've read something along these lines quite some
time ago. Also couldn't find it anymore in the docs and sort of assumed
that it got solved in the meantime... :-)
The good news is: switching workgroups containing custom renderers seems to
work fine now on our side as long as we don't have the mentioned
xsirtcompounds in the same workgroup (which of course is not an option in
production...)
And by "working fine" I mean not just crash-free but also:
1.) ensured that rendertree presets all point to the correct folders/files
after the switch
2.) ensured that shader instances in scenes opened after the switch point
to the correct folders/files
3.) preview render images depending on the individual custom renderer's
features complete as expected.
So I am quite confident that we may be able to use crash-free in-session wg
switching at last as soon as this bug gets squashed. :-)
Cheers, Martin
--
Martin Chatterjee
[ Freelance Technical Director ]
[ http://www.chatterjee.de ]
[ https://vimeo.com/chatterjee ]
On Wed, Aug 15, 2012 at 2:01 PM, Nic Groot Bluemink <
[email protected]> wrote:
> Hey Martin,
>
> Though it's little help, I recall running across a warning in the SI docs
> that unloading custom renderers in-session could introduce instabilities
> back when I was investigating the same thing. I can't find the exact entry
> for you, it was weeks before I accidentally stumbled across it last time,
> but that's pretty much where I threw my hands in the air and wrote a
> workgroup switcher that would restart sessions instead here at Kettle.
>
> Nic
>
>
>
> On Wed, Aug 15, 2012 at 10:22 AM, Martin Chatterjee <
> [email protected]> wrote:
>
>> Chris,
>>
>> well, I wasn't implying that the bug I found is the cause for every
>> reported Arnold-related crash... :-) But all tests indicate that it is the
>> cause for our specific scenario.
>>
>> As a test I've removed all xsirtcompound files from actual copies of a
>> couple of our production workgroups and can happily switch between them
>> without a single crash. This is of course not an option/workaround for
>> actual production - but solid proof for my theory, I would guess.
>>
>> To answer your questions:
>>
>> 1.) I repro'ed this with three different versions of Arnold and 3delight.
>> In addition I asked a friend of mine to repro with VRay as well. So I'm
>> very confident in claiming that this is NOT a renderer-specific bug.
>>
>> 2.) I didn't state this specifically - but of course the crash is not
>> happening when no custom renderer is installed. If a custom renderer is
>> installed, but at a different location (e.g. in the user dir or in a
>> different workgroup) the crash also does not seem to happen.
>>
>> Cheers, Martin
>>
>> --
>> Martin Chatterjee
>>
>> [ Freelance Technical Director ]
>> [ http://www.chatterjee.de ]
>> [ https://vimeo.com/chatterjee ]
>>
>>
>>
>> On Wed, Aug 15, 2012 at 2:39 AM, Chris Chia <[email protected]>wrote:
>>
>>> Hi Martin,
>>> We seem to have some customers complaining about XSI crashes with Arnold
>>> plugin. I am not too sure whether this is the cause.
>>>
>>> Thanks for the repro steps! I will take a quick look!
>>>
>>> Which specific version Arnold and 3delight are you using?
>>> And since you felt that it might be because they were in your workgroup
>>> and unloading them causes crashes, have you brought them out of the
>>> workgroup and tried whether it still crashes?
>>>
>>> Chris
>>>
>>> On 15 Aug, 2012, at 12:05 AM, "Martin Chatterjee" <
>>> [email protected]<mailto:
>>> [email protected]>> wrote:
>>>
>>> Hi list, hi Support,
>>>
>>> as many other studios we've been suffering from fairly regular crashes
>>> when trying to switch workgroups containing custom renderers in an open
>>> softimage UI session.
>>>
>>> I've made several attempts to work around this issue in the past with
>>> mixed results.
>>>
>>> However this time I've been in a particularly stubborn mood and I think
>>> I've finally isolated the bugger! (Repro steps further down in this mail)
>>>
>>> Cheers, Martin
>>>
>>>
>>> --- Description ---
>>>
>>> Softimage UI will crash reliably on workgroup unload when this workgroup
>>> contains a custom renderer and at least on .xsirtcompound file
>>>
>>>
>>> --- Background Details ---
>>>
>>> When switching between jobs we are dynamically unloading the old job
>>> workgroup and then loading the new job workgroup in an open Softimage
>>> session without restarting the software.
>>>
>>> This has worked reliably for years - until we started to regularly
>>> install a custom renderer into these job workgroups (in our case Arnold -
>>> but I've verified that this bug is not Arnold related).
>>>
>>> Right now our workgroup switching leads to a crash in roughly 50% of the
>>> cases in a UI session... :-/
>>>
>>> BUT: the same workgroup switching code works on our farm absolutely
>>> flawlessly.
>>>
>>>
>>> --- This is what I think happens ---
>>>
>>> A workgroup unload will crash Softimage reliably if...
>>>
>>> 1.) a custom renderer is installed in this workgroup
>>> 2.) at least one .xsirtcompound file is part of this workgroup (either
>>> in /Data/RTCompounds, or as part of another addon)
>>> 3.) the Render Tree window was opened at least once in the UI session
>>> BEFORE the workgroup gets unloaded
>>>
>>> I think that when the Render Tree window gets displayed it refreshes its
>>> list of available shaders and rtcompounds.
>>>
>>> If this refresh gets executed before the attempted workgroup unload it
>>> will crash. You will achieve the same effect if you open the Preset Manager
>>> window.
>>>
>>> Please note that it already is enough to display the Render Tree window
>>> in an empty scene - the offending xsirtcompound must not be seen or used
>>> for the crash to happen.
>>>
>>>
>>> --- A few more remarks from my side ---
>>>
>>> 1.) I've run "unit tests" on my side (scripted UI sessions unloading a
>>> workgroup, loading a workgroup, rendering a preview frame, ... 50 times in
>>> a loop) without a crash. The minute I let the same test script also display
>>> the Render Tree window it crashes reliably. Removing the offending
>>> xsirtcompound file results in the same 50 loops of testing to finish
>>> reliably again.
>>>
>>> 2.) It is not important what xsirtcompound file it is - as long as it is
>>> a legal one. For my tests I just put a standard Mental Ray factory phong
>>> node into a compound and exported it into /Data/RTCompounds.
>>>
>>> 3.) We've seen this with many versions of Arnold - but to understand if
>>> this is a Softimage or Arnold issue I also tried this with the free version
>>> of 3Delight - same behaviour.
>>>
>>> 4.) I've tested this on Softimage 2012.SAP (x64) and 2013.SP1 (x64) -
>>> both on XP and Windows 7.
>>>
>>>
>>>
>>> --- Repro Steps ---
>>>
>>> 1.) Create an empty workgroup
>>> 2.) Install a custom renderer addon into this workgroup (e.g. 3delight)
>>> 3.) Place a legal .xsirtcompound file into Workgroup/Data/RTCompounds.
>>> (I just put a standard factory MentalRay phong node into a compound and
>>> exported it...)
>>>
>>> 4.) Start a fresh vanilla Softimage session and connect to this
>>> workgroup.
>>> 5.) Disconnect the workgroup again. --> This works
>>> 6.) Connect the workgroup again
>>> 7.) Disconnect the worgkroup again --> still no problem
>>>
>>> 8.) Now connect the workgroup once more
>>> 9.) Display a Render Tree Window
>>> 10) Now disconnect the workgroup again ---> crash...
>>>
>>>
>>> [ Repro'ed with Softimage 2012.SAP and 2013.SP1 (both x64) on both
>>> Windows 7 and Win XP64. ]
>>> [ Repro'ed with multiple versions of Arnold and 3Delight. ]
>>>
>>>
>>>
>>>
>>> --
>>> Martin Chatterjee
>>>
>>> [ Freelance Technical Director ]
>>> [ http://www.chatterjee.de<http://www.chatterjee.de/> ]
>>> [ https://vimeo.com/chatterjee ]
>>>
>>>
>>
>
>
> --
> Technical Pretty Picture Making Person
> Kettle <http://www.kettlestudio.co.uk/>
>
