I have started to prepare the plugin to run under OSX (from windows). It was quite easy to set-up the work environment under OSX:) which is good, but it doesn’t work as expected.
The plugin builds fine but the Render components are not registered correctly by Rhino. Or I don’t really know what is happening.
It seems that the render components are not running.
My first problem is:
under Windows inside OnLoad() I have this call
RenderContent.RegisterContent(this);
under OSX this call blocks my code run.
in the render plugin class I use this funtion to filter out features
protected override bool SupportsFeature(RenderFeature feature)
This function is called by Rhino, but has no effect on the available render settings
protected override List RenderSettingsSections()
This one is never called
my custom environment and custom material components are not available
All of these show that my render plugin doesn’t behave as a render plugin under OSX.
Any idea?
This is the code for Cycles to be a render plug-in - code is used both on Windows and Mac:
This plug-in depends on the RhinoCycles plug-in to be loaded though. The latter loads the content:
You should be running the RegisterContent. You see I load a bit differently, but your RegisterContent(this); // where this is your Plug-in class implementation should just work fine.
What does that mean? The call never returns?
Not sure about that - @andy or @JohnM may know more about that.
If the RegisterContent call fails then there will be no custom render content no. Did you get in the debugger any useful output that could tell what is going wrong during the registration of your custom render content?
Interesting thing. I have now updated my Rhino 6 for Mac, and the mentioned problems have disappeared…
RenderContent.RegisterContent(this); runs fine now!
Actually it is strange but in case I comment out this line, still my render contents are visible and working under Rhino (WIN and OSX too) - I don’t really understand the role of RegisterContent. It should register the content but it seems these are registered without this call too.
Two things are not working yet and not sure what to do with them.
My own plugin panel is not visible under OSX. I know the OSX version works a bit different but the panel should be there right? (also the menu)
Under Windows Rhino copies the plugin rui file into the McNeel\Rhinoceros\6.0\UI\Plug-ins\ folder. Where is this folder under OSX?
I can add page for my own plugin settings to the Rhino Preferences dialog (using the class OptionsDialogPage). Should it work under OSX too? (It doesn’t seem so…)
EDIT: Ok, it seems it was only an icon problem and now I can see my plugin settings. The only problem is, that under WIN my settings tab has sub-tabs, and under OSX I see only the main tab.
For a RenderPlugIn any implementations of RenderContent will be automatically registered. The function is useful for when you have for instance a utility plug-in, that provides a viewport integration, but not an actual Render integration. In that case you need to explicitly call the function.
I don’t know if RenderSettingsSection is supposed to work yet on OSX. @maxsoder, do you know if this is already possible?
Not sure, @dan, where do these go to? Are RUI files even supported on the Mac?
Not sure why that would be. For Raytraced I have the Cycles options dialog. I use collapsible sections there for the options. I do have a tab page for device selection though.
Please check the following two files:
These are the two top-level code files for the options dialog implementation. The tabs I have in the DeviceSection class.
No, .rui files are not supported in Rhino for Mac. However, the .rui can be converted to a .plist. We have a guide to that process here: Loading Tool Palettes (Mac).
I have to ask for permission for ScreenShots but I think it will be OK:)-
Is there a difference between how Rhino uses OpenGL under Windows and OSX?
Our custom Interactive viewport uses OpenGL accessed via native code (C++) under Windows. It works fine and fast so I tried to do the same for the OSX version but any call to OpenGL functions (for example glLoadIdentity()) causes full black viewport - so something is not good.
I guess it depends. If you are creating your own windows and managing your own OpenGL contexts (doing everything yourself), then you should be able to choose to either support the legacy GL or the modern GL. If you are using Rhino’s viewports for drawing and interacting with the Rhino display pipeline, then you need to have everything be shader based.
I am using the Rhino viewport and after changing my code to “modern” GL it works fine! Thx.
I still have two issues I have discovered with Rhino OSX. Maybe these are known limitations… both are related to the Rhino Command handling…
This command works fine under Win, but does nothing under OSX:
RhinoApp.RunScript("_NewFloatingViewport Projection=CopyActive", false);
Even by hand I can not write commands under Rhino OSX in full form, only to write the command and select the options - so maybe it works different under OSX?
This one also works under Windows
var go = new Rhino.Input.Custom.GetObject();
go.SetCommandPrompt(“Select the object(s)”);
go.GeometryFilter = Rhino.DocObjects.ObjectType.AnyObject;
go.GroupSelect = true;
go.SubObjectSelect = false;
go.DisablePreSelect();
go.GetMultiple(1,0);
but under OSX after selecting the geometry I can not accept it.
I have tried pressing Enter or clicking on the Done button. Also Cancel button doesn’t work but Esc key works…
EDIT:
And I think there is a bug under OSX - gem material guid is wrong
public static Guid GemMaterialGuid => UnsafeNativeMethods.Rdk_RenderMaterial_Plaster ();