Some unfortunate plugin developers will have an obligation to support their plugins on both Rhino5 and Rhino6. Some of the RhinoCommon SDK changes require a bunch of #ifdef RHINO6 conditional statements to get a piece of code to compile under both SDK’s. May I suggest making it easy for plugin developers to support both SDK’s?
For example…
AddPersistentRenderContent could be implemented as…
public static bool AddPersistentRenderContent(RenderContent renderContent, RhinoDoc document = Rhino.RhinoDoc.ActiveDoc);
layer.CommitChanges() could simply do nothing.
I’m sure there are many more changes to come down the line, so just raising this as early as possible
Also, what are the flags in TextureEvaluator CreateEvaluator(uint evaluatorFlags) pls?
A way to get around this without ifdefs is to use dynamic and not invoke certain methods depending on sone runtime bool. Not ideal either but at least you don’t need multiple build flavours.
I agree with Paul and we need to try and do our best to minimize change in the (at least) the RhinoCommon SDK.
@pkinnane, The Layer.CommitChanges() removal was a mistake on my part. I’ll make sure to add it back with an obsolete attribute and have it do nothing.
@andy, @JohnM, and @johnc, it does seem that we should try our best to keep the old functions in place for the other items that Paul calls out.
I used to think that it was going to be okay to break the SDK and force developers to recompile for RhinoCommon based plug-ins because we couldn’t tell exactly what a plug-in was going to call in our SDK. This has changed and we are currently working on a system that inspects .NET plug-ins and makes sure that all of their calls into RhinoCommon (and other .NET assemblies we provide) exist. If we get this system in place and working, we should be able to have the potential for forward and backward compatibility. Plug-ins that use functions that have been removed will not be loaded, but we could provide a message as to why Rhino will not load that plug-in.
Some functions may just have to be removed or replaced in RhinoCommon, but if we can minimize the occurrences of this the more V5 plug-ins we could potentially load into V6.
Thanks for the replies Davd and Steve. I’m not too fussed about having separate builds of my plugin for Rhino 5 and Rhino 6 - it’s more an issue of the code readability and maintainability.
It looks like AddPersistentRenderContent is still there in WIP. There are two versions of it now, but the original declaration still exists. It’s now marked Obsolete though.
For CreateEvaluator, the uint will be changed to an enum in the next build, and an obsolete version of the function with no arguments will call the new one with “Normal”
[Flags]
public enum TextureEvaluatorFlags : int
{
Normal = 0x0000,
DisableFiltering = 0x0001, // Force the texture to be evaluated without filtering (the implementation gets to decide what that means).
DisableLocalMapping = 0x0002, // Force the texture to be evaluated without local mapping - ie, Repeat(1.0, 1.0, 1.0), Offset(0.0, 0.0 0.0), Rotation(0.0, 0.0, 0.0).
DisableAdjustment = 0x0004, // Force the texture to be evaluated without post-adjustment (greyscale, invert, clamp etc)
DisableProjectionChange = 0x0008, // Force the texture to be evaluated without any projection modification (ProjectionIn == ProjectionOut)
};
