So far the internal feedback we got from 3rd party developers was over all uncritical. One even told us he adapted 60K lines of polugin code in basically a day.
While the changes require some adjustments and recompile of all C++ plugins, they do not nearly require a rewrite. Maybe some developers will take the opportunity to do some more adjustments or retire some old code, but a “massive rewrite” should not be neccesary in any case.
One of the greatest benefits of using and compiling plugins using the R13 C++ SDK is that your plugin will run on ALL other future versions of C4D.
R13 is a special sweet spot in the SDK change curve.
The only down side is that you can’t use some of the new stuff added in later SDK’s (sculpting, Material Reflections, etc). But I find that I never need to use any of that stuff anyway.
That won’t be the case for a few of the bigger developers. But I think most of the small devs will never need anything more than the R13 C++ SDK.
I don’t know if that’s still going to be true for R20. The MAXON blog post talks about R12 code converters. So I’m hoping that my plugins will still work in R20.
I can’t tell you how nice it is for me to be able make plugins that run on every version from R13 ++ without any extra work. It’s truly wonderful.
If R13 plugins do still work in R20. Then maybe MAXON should consider selling R13 at a considerably reduced price as a special small developers version or something.
Maybe even (dare I say it) give it away? Not holding my breathe
The R13 Python SDK is a slightly different story.
There was a lot missing in R13 compared to R19. But it’s still not too bad for most things.
It’s really important for devs to get involved with the new Registered Developer Program. Our SDK support team is using the program as a means to communicate changes in the R20 SDK and provide resources (including prerelease builds) to help qualified developers ensure compatibility.
Sadly, this program only applies for commercial developers (proof required). If you’re just programming free plugins or plugins for your own use, or if you have not yet set up your business, you are excluded and have to wait for the official release.
You can get a newsletter but without a compileable environment that is pretty useless, IMO.
Sure, Maxon doesn’t want to bother with 10 000 programmers who’d need to get an NDA each. I can see that.
However, it means that ppl who rely on their own plugins are borked. They can’t adapt their stuff to R20 beforehand, which means they can’t use R20 productively for many months (depending on how large the changes really are), and they will probably stop all development on current stuff because R20 would break it all anyway. I wanted to finish the lip sync plugin recently, but I dropped the mouse the moment I heard the news; no point in dedicating major effort to code that is already obsolete the moment I write it.
Unless your plugin contains 100000s or millions of lines depending on the SDK, it won’t take you months to adapt.
R20 contains a lot of new stuff, but the old functionality is still in place, if you don’t want to use the new stuff (yet). The binary compatibility (offset of data structures, order of function pointers, naming, etc) has changed though - that 's part of a cleanup and a side effect of C++ not being binary compatible (when you add or remove methods or change the size of data structures). That 's why you can’t avoid a re-compile for C++ code.
If a programmer has ignored any API transitions for now, then the amount of work can be substantial; but that 's something you experience with any SDK where you neglect staying up to date with development - be it when connecting to other (3d) apps or when writing apps for completely different operating systems and use cases.
If you can’t apply to the registered developer program, then the advise is making sure that you’ve implemented the API transitions outlined in the latest SDK docs. This will allow a fast adaption to R20.
I’m currently compiling against the R19 API. And yes, in CollieMouse practically every second line is an API call or depends on specific API structures, which amounts to tens of thousands of code lines.
So, the impression is misleading (I assume you have this developer access)? No changes in the messaging system, the basic class hierarchy, the threading, the tool functionality? Viewport drawing, plugin integration, GUI handling? Where are the large changes located that Maxon currently implies, are they restricted to certain areas, and if so, which ones?
I f you read the content of David’s mail careful, then you see that his challenge was to serve new and old Cinema versions with his latest code - and I’d add that their plugins are on the big & complex part of the software spectrum (that 95% or 3rd party plugins don’t fall in).
Just to jump in quickly. The API changes MAXON did and help they’ve given to developers have been excellent, the new tools we have and API changes are going to be valuable to devs and users. You can’t do such a big change without some pain, but it won’t last long and is worth it.
As for XP and Cycles 4D, stay tuned, our solution to R20 is rather unique so we’ll be showing this off soon and at IBC.