hypershade no longer opens without octane

[Wenneker]

I have a project that I'm working on that is not using octane. When I try to open my hypershade without the octane plugin loaded I only get an empty window and the following error.

// Error: line 0: Cannot find procedure "octaneInsertNodeDir". //

Since this project will be rendered in the cloud it would be best to not have octane loaded because the rendernodes won't have the plugin.
When I load Octane into an existing project as a workaround so I can at least still use my hypershade it keeps giving me errors every time a camera is selected.

// Error: line 1: deleteUI: Object ' octCamPPenabledOctColumn' not found.

[JimStar]

I have a project that I'm working on that is not using octane. When I try to open my hypershade without the octane plugin loaded I only get an empty window and the following error.

// Error: line 0: Cannot find procedure "octaneInsertNodeDir". //

Since this project will be rendered in the cloud it would be best to not have octane loaded because the rendernodes won't have the plugin.
When I load Octane into an existing project as a workaround so I can at least still use my hypershade it keeps giving me errors every time a camera is selected.

// Error: line 1: deleteUI: Object ' octCamPPenabledOctColumn' not found.

It's a result of really ugly way in Maya to make the plugin have something inside hypershader... Not only is it ugly, but even in this ugly mechanism Maya has a bug which is not fixed through several last versions (including 2015). The same option-variable is called by different names in Maya's startup scripts:

Code: Select all

// If there is a user initialize procedure defined, then call it
if (`optionVar -exists "renderNodeTypeTreeInitializeUserProc"`)
{
    string $userInitProcedure = `optionVar -query "renderNodeTreeInitializeUserProc"`;
    ...
}

Try to run in script editor:

Code: Select all

optionVar -remove "renderNodeTypeTreeInitializeUserProc";
optionVar -remove "renderNodeTreeInitializeUserProc";

[matrix2012]

Hi JimStar

The problem is on Windows and Maya.
On Linux and Maya is Hypershade without Octane to load without error.

This is really strange?

sorry for my bad english.

all the best
matrix2012

[Wenneker]

Thanks. That does resolve the main issue of not having a working hypershade.

[jangwee]

Sorry to resurrect an old thread but my question is for Jim,
- Is this problem likely to be fixed any time soon?

I often have to use either MentalRay or VRay depending on projects and clients preferences and neither of those renderer plugins cause this problem. I don't want to resort to uninstalling Octane or hacking scripts every time I start a new project or scene if I'm not sure I'm going to be using Octane in that new scene/project.

[Wenneker]

My "solution" was to add the lines to my userSetup file so they are automatically run every time Maya starts.

If you don't have one already just extract the attached file to: Documents\maya\scripts
Otherwise just add them at to that file.

[RickToxik]

I often have to use either MentalRay or VRay depending on projects and clients preferences and neither of those renderer plugins cause this problem. I don't want to resort to uninstalling Octane or hacking scripts

It became a serious problem for me too. I could not open the hypershade without the plugin, and when the plugin was unloaded some Arnold scenes were crashing because of conflicts with remaining octane nodes or attributes in objects.

I was very sad that I had to remove completely octane from my system but I did not have any choice because of fast turnarounds times for clients' projects that were not using octane. I tried optimizing my scenes, deleting history, cleaning nodes and stuff but at the end the only fix was to uninstall octane for maya and trash all my preferences.

[jangwee]

Yeh I had similar issues with Maya crashing while working on another project that wasn't rendering with Octane.
My solution so far is to just add the 2 lines of code to a custom shelf button for temporary quick fix until Jim finds a way to fix this properly.
Every plugin update I kinda hope it's in the fixes list but sadly not yet.

[rslaverne]

Just curious, what were the two lines of code you used to temporarily fix this? If you don't mind sharing.

-Will

[JimStar]

The only way how it can be fixed properly - is fix this on the Maya side, as this is nothing to do with the plugin. Maya must not use the option variables here for plugin's hypershader API - as the option variables save the state between sessions. To be present in hypershader the plugin sets above mentioned variables in "initializePlugin()" API callback, and expects Maya calls its "uninitializePlugin()" callback later where the variables are cleared (it's logical way isn't it?)... But Maya never calls the "uninitializePlugin()" callback if you just exit Maya. It only calls it if you unload the plugin explicitly from the plugins manager (which is impossible if the scene has Octane data already). So in this case this option variable stucks.
Moreover it's impossible to clear this option variable in general "Maya is going to exit" callback - as Maya saves all the option variables before this time, so any change to any option variable here does nothing.
And this API is still unchanged through all the Maya versions...

The only way how it can be hacked - another ugly way which I already described on this forum before. I can just hack this part of internal Maya's startup code (during the plugin initialization) and fix this API in Maya's system script, it's easy. But this will affect the other plugins too, just the other way: if you have some plugin which hacks the same Maya's chunk of code - either its changes will be rewritten by Octane's hack of the same chunk, or Octane's changes will be rewritten by this other plugin (whatever makes these changes last). If some plugin will change the same chunk of Maya's system script during installation (not during every initialization) - its changes will be always rewritten by Octane plugin (as I will do this during every plugin initialization).

I can switch to this second approach in the next version. Let's hope this second way will do some less harm to your workflow...