Heads up to plugin developers regarding CRef

[Nicolas Burtnyk]

Hi everyone,

I just wanted to share a piece of information I discovered while developing our custom renderer for Softimage.

We were having an issue where Soft would hang when we were extracting the scene for rendering after deleting a light in the scene.

It turns out that the problem was cause by the fact that our plugin was holding CRefs to objects in the scene between renders for the purpose of determining what had changed between renders and therefore what data needed to be re-extracted/re-processed.  During extraction, once we determined that the light was no longer in the scene, we would delete our tracking object which included a CRef to the deleted light.  The destruction of the CRef was hanging Soft.  Apparently the problem is caused by the fact that CRef represents a *strong* reference to an object.  So, if you have a CRef to something (say a light) and you delete the light in Soft, the light doesn't actually get deleted because it is still being referenced by that CRef.  For whatever reason, I had assumed that a CRef was a weak reference and that the CRef would simply become invalid when the referenced object was deleted.  Instead, the light is only deleted when the last CRef is destroyed, which in our case was causing a hang because it was happening during our custom renderer's "Process" callback which Soft calls on a special render thread and not the main thread.  We eventually solved the problem by tracking objects by their object ID rather than using CRefs between renders.

Long story short - CRef is a strong reference.  I assumed it was a weak reference.  Don't make the same mistake!

Too bad this isn't documented and too bad the SDK doesn't provide an equivalent to CRef that simply becomes invalid when it's referenced object is destroyed.

-Nicolas

[alok.gandhi]

Wow ! That is scary ! Good find Nicolas and thanks for the heads up. No wonder soft also crashes sometimes when using Application.DeleteObj() command in python as well, I wonder if it is caused by the same reason. Maybe same happens for VB or Java but I am not sure. The only duct-tape solution that I found around this was to call Application.Refresh() in python before delete which resulted in a consistent behavior.

[Kamen Lilov]

On 6/18/2012 8:29 PM, Nicolas Burtnyk wrote:
> Hi everyone,
>
> I just wanted to share a piece of information I discovered while
> developing our custom renderer for Softimage.
>

Thanks Nicolas! We've hit the problem with "persistent" CRef / X3DObject
references before and invested a lot of effort in that, with little
result (to date). This is a precious little gem of information... And
the style / comprehensiveness of your explanation absolutely rocks.

[Stephan Woermann]

There is a DirtyList attribute in the renderes context, maybe that helps a little...

Stephan

[Steven Caron]

i believe he has been down this road already. its lacking...

[Nicolas Burtnyk]

Thanks Kamen -  To compound my frustration, Autodesk is being very closed about discussing this issue with me.

I wanted a simple conversation with the Soft dev guys to explain why this is a problem and suggest some solutions.  Unfortunately I'm not a "Enterprise Priority" customer (lol) so I have to go through the excruciating process of speaking via a support portal and waiting days for replies.

On Mon, Jun 18, 2012 at 12:54 PM, Stephan Woermann <swoer...@googlemail.com> wrote:

[Nicolas Burtnyk]

Don't get me started with the dirty list :)

I shouldn't be too hard on it though - it's actually come in handy for 1 specific case - it's the only good way that I've found to detect that a shader parameter has changed while scrubbing a slider *before* the renderer process callback is fired.  The OnValueChange event gets fired after the Process callback during a parameter scrub.

[pet...@skynet.be]

that’s a shame.

I was going to reply to your original mail, saying something like:

that’s all very interesting, but is there no better channel to get into contact with softimage developers than this mailing list?

 

3rd party developers should have a prime communication line to the target software’s dev team – even if it’s ‘just’ a free forum with active participation by people from the dev team.

Regardless of their size or investment in licenses.

 

3rd party developers invest their time, effort and knowledge, often without good prospects of return, at least not in line with that investment, especially with a small userbase like for softimage.

In doing so, they are strengthening the target software, overcoming some of its main weaknesses. Some that are still around after a decade - likely never to be adressed by the target software.

When that target app is becoming less compelling to keep investing in by itself (see: the price increases thread that going on right now) - 3rd party tools might well save it’s grace, and keep it alive way beyond it’s expiration date.

Should be obvious in the case of 3dsmax and FumeFX / Krakatoa / Vray for example - where would max be without them?

 

And it’s not like there is nothing left to whish for in Softimage.

Frankly this is precisely what’s going on at all Softimage based studios I am in contact with – each and every one of them considering ending Softimage use. The cost doesn’t seem inline with the improvements. The alternatives under consideration are being favored based on 3rd party tools.

If it wasn’t for binary alchemy / mootzoid / exocortex / solid angle and others, in no particular order – that decision would have been made a while ago.

 

I am convinced that limited third party offering is one of the main reasons why Softimage is the underdog software – together with unfavorable pricing/policies/marketing. Too bad, because it deserves better.

[Nicolas Burtnyk]

Well put Peter.

My company actually pays Autodesk a decent amount of money to be part of ADN (Autodesk Developer Network) so that we can use a handful of licenses of the various DCC tools for development purposes.  With that, we get access to support but the process of working through an issue from the reporting stage to actually getting usable information is so slow and frustrating.  You never interact directly with the devs.  Instead you typically play broken telephone via support personnel that rarely understand the problem resulting in several back and forth emails with typical turnaround times of more than 24 hours for every single email.  There are exceptions, I've been pleasantly surprised by the level of service from a few individuals on the support team, but more often than not, interacting with support leaves me swearing at my monitor.  For the issue I mentioned in my original message, once I had a working solution, I ended up throwing my hands in the air - f it why am I going to beg AD for the privilege to helping them improve their SDK?  It's sad because I know for a fact there are a ton of great people working at AD (I used to work at Alias prior to the acquisition) so the problem is more bureaucratic red tape than anything else.

When it comes down to it we need our ADN subscription.  Without it, we'd have to purchase licenses for Soft, Maya, Max, etc... for each of our developers which simply wouldn't be possible for us at this stage.  And while the support is way more frustrating and inefficient than it needs to be (IMO), it's saved us on a few occasions.

Thankfully, this list does a good job of filling in the gap for me.

[Kamen Lilov]

On 6/18/2012 11:06 PM, Nicolas Burtnyk wrote:
> Don't get me started with the dirty list :)
>
> I shouldn't be too hard on it though - it's actually come in handy for
> 1 specific case - it's the only good way that I've found to detect
> that a shader parameter has changed while scrubbing a slider *before*
> the renderer process callback is fired. The OnValueChange event gets
> fired after the Process callback during a parameter scrub.
>

You seem to have ended up with a combined solution for detecting changed
scene items :) - using both the Dirty list and OnValueChange (and, maybe
objects' last evaluation ID)

Good choice :)

You will be happy with this architecture. The "clean" approach - using
only the dirty list mechanism - would rely too much on the XSI Renderer
API, which was a valiant but hopeless attempt by Autodesk to prove that
XSI is not built around MR. (Hint: there are tons of scenarios where MR
is integrated in a way that is not even theoretically possible to
achieve through the Renderer API)